What Should a Humanoid Robot Look Like When It’s Doing Nothing?
We spend most of our design effort on the robot in motion — walking, grasping, jumping, backflips. But even when a humanoid is switched on, it spends far more time on standby than we think.
Why design the idle state at all? Think of a game character frozen mid-screen: the first thing a player assumes is that it crashed. Same here. Without a designed idle state, how does anyone know the robot isn’t switched off, or broken?
So what should a humanoid look like on standby? Perfectly upright and motionless, with an indicator light on the chest to confirm it’s powered on? Or with its weight shifting slightly, a finger moving now and then, occasionally changing stance — so you can tell at a glance it’s ready to go?
The first reads as a machine, the second as a person.Both are valid.It depends on where it’s standing.
On a factory floor, what the business cares about is utilization — how much of the available time the equipment is actually running. Resting means idle, and idle means money draining away. So the idle state has to answer three things: I’m not broken, why I stopped, and what happens next. The worst thing it can do in that context is look like it’s taking a break.
In a service setting, it’s close to the opposite. People are standing right next to it. What they want is something predictable, quiet, and never startling. Here the robot should look unoccupied — nobody wants to stand beside something that might move at any second. At the same time, it has to stay trustworthy and approachable. Too much stillness turns eerie, like the motionless stare in a horror film, and people start to feel watched and wonder what it records.
One is saying I’m still working. The other is saying I won’t move without warning. Opposite messages, but the same underlying problem: making the next few seconds predictable.
So how does a robot get either message across to the people around it? There are a number of options, each with its own cost.
A light is the cheapest. Technically simple, no impact on motion, and the color can be adjusted. But what it can carry is fairly limited — whatever state maps to whichever color, the user has to learn it first.
Sound travels and doesn’t require line of sight, which makes it good for marking that something just happened. But it’s unforgiving about environment: inaudible in a noisy plant, intrusive in a quiet one, and the right volume for one person is too much for another. And once there are multiple robots and multiple people in the same space, voice starts interfering with itself — who is addressing whom becomes ambiguous, and in the worst case that means the wrong robot acting on the wrong command.
Screens carry a lot of information and can state the next action explicitly. The cost is that someone has to walk over, look at it, read it — and there’s the language barrier on top of that.
Motion and posture are the most expensive — structure, power budget, safety certification. But the learning cost for the user is low, and it can signal intent ahead of the action. Which way the body faces, where the weight sits, whether the arms are tucked or open: we read this kind of body language without being taught.
On using movement to communicate, Apple’s ELEGNT study is worth reading. They built a lamp — no face, no features, nothing but movement — and ran two versions of the same tasks. One simply completed the task. The other turned toward the window before answering a question about the weather. Participants found the second version noticeably more intelligent and were more willing to engage with it. The paper and videos are on Apple’s machine learning research site.
Line these up and a pattern emerges: the cheaper something is to implement, the more the user has to learn. The less learning it requires, the more it costs.
Cost to the productLearning for the user
Which makes it a question of deployment context. In long-running, fixed settings, a certain amount of learning cost is acceptable — operators will pick up the vocabulary. Where most encounters are the first and only one, it doesn’t pay off; people passing through won’t learn, so experience has to come first.
Ultimately, one of the things idle design is really working on is predictability. The factory wants it for scheduling, the service floor wants it so people dare to stand nearby. And the trade-off is a decision about who pays — the product, in engineering cost, or the user, in learning.