As autonomy moves from research labs into real-world environments, the role of design is shifting. It's no longer just about usability — it's about trust, safety, and human-machine collaboration.
Designing Trust: Interfaces for Autonomous Machines
Q&A with Vlad Dukhnov, a lead designer at | Hello Robo
We spoke with Vlad Dukhnov, a lead designer at Hello Robo who led interface design for major construction autonomy company, about what it means to design for systems that act on their own.
Designing interfaces for autonomous construction equipment is still largely undefined territory. Where did you begin?
It was very much unknown territory for us as well, so we started with the most fundamental step, talking to the people who would actually be using the system.
We interviewed construction workers, on-site operators, and project managers who had early access to a more technical version of the product. What we quickly realized was that the existing interface had an extremely high learning curve. It was powerful, but it was built with an engineering mindset, which made it inaccessible to most operators.
From there, we expanded our research beyond construction. We looked at adjacent systems: drone controls, remote operation tools, even video games to understand how people interact with complex systems in real time.
At the same time, we worked closely with engineers to understand the machine itself, its states, behaviors, and edge cases.
But the most important insight wasn’t about usability. It was about trust. Operators weren’t just struggling to use the system, they were uncomfortable with it. If they couldn’t predict what the machine would do next, it immediately felt unsafe.
That became the core challenge: How do you make autonomy legible?
That idea of making autonomy “legible” is really compelling. How did that translate into the interface?
We approached it through a series of small but intentional steps, all centered around making the system’s behavior visible.
The first thing we introduced was what we called an Activity log, a live log of what the excavator was doing and why. Instead of hiding system activity, we exposed it. Operators could see real-time states, errors, and actions. Whether the machine was in autonomy, paused, faulted, or waiting for input.
We paired that with a visual layer. A digital twin of the excavator inside the interface. This allowed operators to understand the machine spatially, where it is, how it’s moving, what it’s doing, and how close it is to completing a task.
That combination helped to create predictability. And through the predictability interface started gaining trust from people.
Did this change how you thought about control?
Completely. At first, we thought we were designing a single interface, a web app for operators on-site.
But we realized there were actually two users:
- a supervisor outside the machine
- and a person physically inside the excavator, responsible for safety
That shifted our thinking. We weren’t designing a single interface anymore, we were designing a distributed system of control.
One of the key principles became instant, unquestionable override. We introduced a prominent emergency stop, a digital version of the physical red button operators already trusted. If something feels wrong, the user will click the button and the machine shuts down immediately.
We also explored more conversational interactions.
Operators could ask the system questions — like how much time was left to complete a task and receive answers in a simple, chat-like format. This made the system feel less like a black box, and more like something alive.
For failure scenarios, we designed graduated feedback. Critical issues like detecting a human nearby would immediately stop the machine and trigger a high-priority alert. Less critical conditions were shown as lower-severity signals that users could assess and dismiss. This helped operators focus on what matters, without overwhelming them.
What was the hardest part of work that you did?
Interestingly, it didn’t feel like we were making “hard” decisions in the traditional sense — not because the problem was simple, but because we stayed very close to reality. We spent hours observing operators using the system. In some sessions, we would just watch, ask questions, and see where confusion or hesitation appeared. That proximity made many decisions feel obvious because they were grounded in real behavior.
But the challenge was in the trade-offs:
- How much information do you expose without overwhelming the user?
- How do you simplify without hiding critical context?
- How do you design for non-technical users while supporting a highly complex system?
Those questions were everywhere. What made it work was constant validation with users, engineers, and the team. We weren’t designing in isolation.
What do designers often misunderstand about designing for autonomy?
I think the biggest misconception is that you can rely on intuition the same way you do in traditional product design. In most consumer products, you are the user. You’ve used similar apps before, so you can design from experience. But in robotics, that doesn’t work.
You’re designing for people whose environment, risks, and responsibilities are completely different from your own. You’re not operating heavy machinery. You’re not on a construction site.
"Another thing that doesn’t translate is the idea of a linear process. In robotics, everything is evolving at once. Hardware, autonomy, use cases. So the process becomes fluid. You’re constantly shifting between understanding the system, testing with users, and adapting to constraints. It’s less like following steps and more like navigating a moving system."
As autonomy becomes more embedded in the physical world, the role of design expands beyond pixels and flows.It becomes about making intelligent systems understandable, predictable, and trustworthy. And in that shift, designers are no longer just shaping products. They’re shaping how humans and machines coexist.
The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow
Featured Product
