In January, members of the MOZART SSH team attended the International Production & Processing Expo in Atlanta. In our first post, we described why we went. This time, we want to explain what we learned.

MOZART is developing a modular robotic surface for handling variable, soft, and irregular food products (not only). The SSH team studies the human side of that system: for example, trust, relationships among stakeholders and users, interaction, as well as technology acceptance.

Before going to IPPE, much of our thinking about interaction focused on what an operator might need while working alongside the system. The conversations in Atlanta, however, pivoted around another question for the application of the system in the poultry industry:

What if the most important interaction from our application perspective does not happen while the system is working, but when it stops working?

We spoke with 29 people over three days, of whom 25 provided material that will contribute to a data set we will subsequently use in our analysis. The conversations took place at exhibition stands and in the aisles of the trade fair. They were deliberately short and informal. We knew the participants were there mainly to do business, not to talk to researchers. That does not make the conversations less useful.

We asked, for example, what would make a system such as AUTOMAT viable in practice, where automation tends to struggle, what it should not be asked to handle, and what people would need to understand before allowing it to operate.

We mainly spoke with exhibitors, suppliers, sales representatives, managers, and system integrators. We analyzed the material using reflexive thematic analysis (Braun & Clarke 2022) and affinity mapping (Lucero 2015).

Three broad conditions recurred: confidence in the organization behind the machine, compatibility with the plant’s physical reality, and the ability to understand and recover the system when something goes wrong.

Trustworthiness of automation? Trustworthiness of a partner

When we asked what would make a system trustworthy, respondents often moved immediately away from the robot itself:

“The most important thing we build is trust. What is it? Dependability and service. You need to be there if they need you.”

Others mentioned vendor stability, service contracts, spare parts, and the ability to obtain support when production cannot stop.

“Serviceability. If I can’t swap parts fast, it won’t last.”

“If it’s a prototype that disappears, we can’t buy it.”

“Who fixes it at 2 a.m. when production can’t stop?”

This shows that the system’s trustworthiness was linked not only to the robot, but also to its supplier, the maintenance arrangement, and the availability of service and parts. Also, respondents in our research required some kind of guarantee that the organization behind the system would exist several years after installation. Our dataset suggests that for an industrial customer, a robot that performs well but cannot be repaired quickly may not be trustworthy or useful in any practically meaningful sense.

This does not mean technical performance itself is unimportant. We also see that performance is evaluated as part of a wider sociotechnical arrangement. Showing a video of a novel system as we did may work well to start the conversation, but it is not so attractive to industrial partners unless the partner behind it answers questions about downtime, maintenance, integration, or long-term responsibility.

The commercial side was just as direct: “People want innovation, but then they want payback soon.” And: “Nobody wants to be the first to deploy something totally new.”

Design for messiness

A second theme was the physical reality of the factory floor. This was also not new for MOZART: these considerations were part of the project from the beginning, but the conversations at IPPE reinforced how central they are to practical deployment.

Food-processing plants are tightly regulated environments, which are often extremely humid and cold. Equipment must withstand repeated cleaning, water, chemicals, contamination, and generally harsh conditions of the food production plants. Respondents treated these conditions not as “something special” but as ordinary production reality.

“If this thing can’t handle water, chemicals, and constant cleaning, it’s dead on arrival.”

“If the surface can harbor bacteria or can’t be inspected properly, it won’t pass internal audits.”

For MOZART, this should be addressed directly in the system’s design. All the tiles, the deformable surface connecting them, edges, seams, controls, or other components must remain cleanable and easily inspectable. One respondent summarized the gap between demonstrations and deployment particularly clearly:

“People show videos of perfect product, but plants are messy.”

Therefore, it is not enough for the system to only demonstrate that it can perform the task it was designed for. In this specific setting, performance and successful technology adoption also include surviving sanitation procedures. Variation in production was also where respondents expected automation to struggle:

“Automation usually works fine until there’s variation, size, shape, something like that. Then people step back in.”

Interaction? As little as possible

Respondents we spoke with also described normal system operation and how they expect it to run. Their perspective was clear: the system should run with minimal attention. Interaction begins only when an exception occurs: a system fault, debris blockage, or a similar problem.

“Typically, it just runs by itself. So it is only when something goes wrong, when we really need to intervene.”

“Operators won’t babysit a smart surface. They need a clear status and an obvious stop/recover.”

Another respondent described a packing line where the interface “is only for monitoring,” and where in normal operation “no one has to touch anything.”

From our respondents’ perspective, the interface for this setting should be designed primarily as an exception-handling system. One respondent asked the same questions before even considering a purchase: “I’d want to know what happens when it fails, does it fail safe, can we bypass it, how fast can we recover?”

Several respondents emphasized that this does not require showing the operator everything the system knows.

“Give me diagnostics that make sense. Not fifty alarms. Tell me what to check first.”

Transparency, in this context, is not the maximum amount of information. It is information that supports effective action when it is needed, without creating cognitive overload. This fits the idea that transparency should help people understand what a system is doing and why, rather than show them more data (Chen et al. 2014). The same applies to how a system is presented: “A clear control architecture and predictable behavior. AI magic is the fastest way to get rejected.”

Regarding interface design, respondents also noted a need for a clear distinction between user types. From their perspective, operators need clear status information and straightforward recovery controls. A maintenance technician may need detailed diagnostics, additional data, and access to system history.

“There are usually two interfaces: operator interface and maintenance/engineering interface. If you merge them, it gets messy.”

Other requirements were similarly concrete. Safety-critical controls should remain physical: “They would be wearing gloves, and we are using physical buttons. The emergency stop has to be physical.” Status should have its own place.

Respondents were also generally positive about using automation to address labor shortages and remove cold, repetitive, or physically undesirable work. “I don’t think anybody wants to work the whole day in an ice-cold factory, so automation will be great.” Our respondents’ concern was more about automation whose failures are opaque, whose status is hard to interpret, or whose operation cannot be recovered quickly. Nor did they expect people to disappear from the line: “Even if we automate everything, someone has to control the systems.” Someone also has to be responsible for decisions being made. Another respondent noted that automation “should not replace decision making,” because “there’s always someone who has to take responsibility.”

Design for the people and the task

The conversations at IPPE did not reveal that technical capability is irrelevant. They revealed that industrial stakeholders define capability more broadly.

A viable system must perform its intended task, but it must also survive the plant, fit into existing operations, remain supportable, reveal what it is doing, and allow people to recover when normal operation breaks down.

Trust in industrial robotics is not only confidence that the robot will work. It is also confidence that, when it does not, the people around it can understand what happened and remain in control of what happens next.

The analysis draws on conversations and open-ended responses collected at IPPE 2026 in Atlanta. Quotations have been lightly edited for readability.