What human robot interaction research teaches us about expectations, trust and today’s humanoids
How does a pile of motors, sensors and plastic become something people want to interact with and continue using after the novelty wears off?
That question sits at the heart of robot design. It is also the subject of Chapter 4 of Human-Robot Interaction: An Introduction by Christoph Bartneck and colleagues, which I have been reading as I begin my PhD in the RAP Lab at McMaster University.
The chapter changed how I think about our robots. A robot’s design includes its body, but also its voice, movements, introduction, tasks and responses when something goes wrong. Together, these features tell people what kind of machine they are dealing with and what they can reasonably expect from it.
This article brings the chapter’s main ideas together with current examples, including Figure and 1X, and newer tools for robot development. The industry examples extend the chapter; they are not examples taken from the book.
My central takeaway is this: good robot design helps people understand what a robot can do, interact with it comfortably and rely on it appropriately. Making a robot impressive is only part of that challenge.
Start with people and a purpose
The chapter contrasts two approaches to robot design.
Inside-out design begins with available technology. Engineers assemble motors, sensors, cameras and computing hardware, then work out how people might use the result. Appearance and social behaviour may come later. The book describes an extreme version as the “Frankenstein approach.”
Outside-in design begins with people, activities and settings. Who will encounter the robot? What do they need? What interaction would help them? Those answers guide the robot’s form, behaviour and technical requirements.
The chapter’s examples make this concrete. ASIMO’s relatively small stature was intended to reduce intimidation. Pepper’s hinged waist supports bowing. Paro’s seal-like appearance encourages pet-like interaction without inviting exactly the same expectations people bring to familiar cats and dogs.
Outside-in design does not mean ignoring engineering constraints. It means allowing human needs to shape engineering decisions early enough to matter.
There is also a useful qualification: developing a technical platform is not inherently bad design. A research robot may exist precisely so that others can explore applications that have not yet been defined. The problem arises when technological capability is treated as sufficient evidence that the robot will be useful or welcome.
For me, the first outside-in question is therefore: does this situation need a robot at all?
A screen, a simpler machine or a change in workflow might solve the problem more effectively. Choosing a humanoid should be a design decision that can be explained.
What a robot’s body promises
The chapter describes several broad forms:
- Humanoids have recognisably human body structures; androids attempt a closer resemblance to human appearance.
- Zoomorphic robots resemble animals.
- Minimal robots, such as Keepon, use a small number of expressive features.
- “Robjects” give everyday objects interactive behaviour.
These categories matter because appearance creates expectations.
Eyes can suggest vision. Arms can suggest grasping. A face can suggest emotional understanding. Fluent speech can suggest a much wider conversational ability than the system actually possesses.
The chapter explains these expectations through affordances. In Gibson’s ecological account, an affordance is a possibility for action that exists in the relationship between an organism and its environment. Norman’s design work draws attention to what people perceive they can do and the cues that help them understand it.
That distinction matters. A hand-shaped attachment may signal that a handshake is possible even when it cannot grasp anything. The visible invitation and the actual capability can diverge.
This is especially relevant to robots connected to language models. A robot might produce a convincing explanation of a task while lacking the perception, physical control or permissions needed to carry it out.
My design implication is simple: the robot’s appearance, language and demonstrated abilities should tell a consistent story.
That does not require announcing every limitation at every moment. It requires making the relevant limitation clear before someone relies on a capability the robot does not have.
Are today’s humanoids designed outside in or inside out?
The distinction becomes more complicated when applied to commercial humanoids.
A soft exterior does not prove that users shaped development. Powerful actuators do not prove that users were ignored. Product pages reveal design priorities, but usually provide limited evidence about interviews, participatory workshops or the sequence of internal decisions.
The comparison below is therefore my interpretation of public evidence, not a definitive classification of each company’s process. It is a selected snapshot of the commercial and development landscape as of October 2026, rather than an exhaustive buying guide.
| Robot | What the public evidence shows | My interpretation |
|---|---|---|
| 1X NEO | Its home-focused design emphasises cushioning, covered mechanisms, quiet operation and washable clothing. The ordering page also describes Expert Mode for unfamiliar tasks. | Outside-in leaning: domestic interaction visibly shapes the product requirements. This does not establish how much prospective users participated in development. |
| Figure 03 | Figure explicitly describes a robot designed around three priorities: its Helix AI, household use and manufacturing at scale. Changes include redesigned sensing and hands, soft coverings and easier charging. | Hybrid: AI requirements drive hardware, while household needs shape physical and interaction design. Calling it purely inside out would overlook the latter. |
| Apptronik Apollo 2 | The platform offers wheeled and bipedal configurations, status displays and communication cues. Apptronik also identifies Apollo 2 as a data-collection and training platform operating at partner and customer sites. | Hybrid, with clear outside-in elements: task requirements influence configuration and interfaces, alongside substantial investment in hardware and AI development. |
| Agility Robotics Digit | Its commercial deployment at GXO centres on a defined logistics workflow, supported by a multi-year agreement. | Outside-in leaning at the application level: a concrete operational need provides the design target. Deployment alone does not establish participatory design with workers. |
| Boston Dynamics Atlas | Boston Dynamics describes a progression from research robotics towards an industrial product, informed by manufacturing applications and customer experience. | Hybrid: advanced technical capability is being shaped into a system for specific industrial work. Its research origins do not fully describe its current design direction. |
| Unitree G1 and R1 | These commercially listed platforms foreground hardware capability, configurations and development options. Their eventual applications depend partly on what developers build around them. | Platform-first, tentatively inside-out leaning: useful as a description of their public positioning, but insufficient evidence to conclude that their internal design process ignored users. |
| UBTECH Walker S2 | Its industrial positioning includes autonomous battery swapping and power management linked to task priorities. | Hybrid, with outside-in operational features: the design responds to continuity-of-work requirements, although that is not the same as evidence of worker participation. |
| Fourier GR-3 | Fourier describes companionship as a central purpose, with soft coverings and coordinated hearing, vision and touch interfaces. | Outside-in leaning in its stated intent: social interaction shapes the product concept. Claims about emotional understanding still need independent evaluation. |
The comparison also exposes an important ambiguity in the phrase “available on the market.” Retail listings, deposits, demonstrations, training fleets and contracted deployments represent different stages of maturity.
For example, Figure’s June 2026 report describes Figure 03 demonstrating a logistics workflow at BMW. Apptronik describes Apollo 2 collecting training data through both teleoperation and autonomous execution. Neither description should automatically be read as evidence of unrestricted, general-purpose autonomy.
The more useful question is: which human or operational requirement shaped this feature, and what evidence shows that it works in practice?
Design the interaction, including the awkward parts
The chapter introduces design patterns through the work of Peter Kahn and colleagues. A pattern describes a recurring interaction problem and a reusable approach to addressing it.
Examples include introducing a robot and moving together with it. Patterns can combine: a robot guide needs to introduce itself, explain something, move with visitors and manage interruptions.
This shifts attention from isolated features to the relationship unfolding over time.
A greeting is not complete because the robot can say “Hello.” The designer also needs to consider what happens if the person does not respond, speaks over it, approaches with someone else or wants to leave.
The chapter offers four principles that help organise these decisions:
- Match form and function. Give the robot features that fit its role and capabilities.
- Underpromise and overdeliver. Avoid creating expectations that routine use will disappoint.
- Let interaction expand function. Leave room for people to find meaningful ways of engaging with the robot.
- Keep the metaphor coherent. Appearance, behaviour and role should make sense together.
I would interpret the fourth principle as a question to investigate, rather than a ban on creative combinations. An animal-shaped tutor might work well for a particular audience. What matters is whether people understand and accept the combination.
Extending these principles to contemporary robots, I would also design explicitly for failure and recovery.
What should the robot do when it mishears, cannot reach something or encounters an unfamiliar task? Can the user interrupt it? Does it explain what failed? Can it request help without repeatedly burdening the same person?
Consider two possible responses:
“Something went wrong.”
“I could not grip the cup securely. I have stopped moving. Please move it closer or choose another task.”
The second response gives the person information they can act on. Its usefulness would still need testing, but it illustrates the kind of interaction that belongs in the design from the beginning.
Humanlike behaviour can help and create obligations
Anthropomorphism means attributing human characteristics, intentions or mental states to something nonhuman.
The chapter makes an important distinction between a robot’s humanlike features and the psychological qualities people attribute to it. A machine can have a human-shaped body without seeming thoughtful, while a simple moving object can appear purposeful.
Appearance, timing, movement and context all contribute. A glance that responds appropriately to someone’s arrival may communicate more than an elaborate but unresponsive face.
Animation offers useful techniques here. Anticipation can make an upcoming movement easier to read. Changes in posture can communicate attention. Carefully timed motion can help people follow what a robot is doing.
But more social behaviour does not automatically produce better outcomes.
In Kennedy, Baxter and Belpaeme’s robot-tutoring study, the more socially expressive condition did not produce the expected learning advantage; children learned more in the less social condition. This is a finding from a particular task and experimental design, not a general argument for unfriendly robots. It shows why engagement and task success must be evaluated separately.
For me, anthropomorphism is therefore a design choice with consequences. If a robot appears attentive, empathetic or authoritative, people may expect the corresponding abilities. The designer needs to ask whether the system can support those expectations.
The goal should be appropriate reliance. Research on trust in automation emphasises the importance of matching reliance to a system’s actual capabilities. Too little reliance can prevent useful assistance; too much can encourage people to accept poor advice or stop monitoring performance.
A robot that clearly communicates uncertainty may sometimes inspire less confidence in the moment. That can still be the better interaction.
Use the uncanny valley as a question
Masahiro Mori’s uncanny valley proposal suggests that increasing human resemblance can eventually produce an uncomfortable response when a robot becomes almost, but not convincingly, human.
The chapter is right to question casual uses of the idea. Human resemblance has multiple dimensions, and familiarity, affinity and eeriness are not interchangeable measurements.
However, saying that Mori did not test his original proposal should not imply that nobody has investigated it since. Later research has examined several possible mechanisms. A review by Kätsyri and colleagues found inconsistent support for a simple universal curve, while identifying perceptual mismatch as one supported route to eeriness.
For a designer, “people found it uncanny” should start an investigation.
Was the movement unpredictable? Did the voice clash with the face? Was the gaze poorly timed? Did the robot look competent and then fail at a simple task?
Those explanations lead to different changes. A broad label cannot tell us which change to make.
Bring users into decisions early
The chapter discusses engineering design, user-centred design and participatory design.
Engineering design helps establish what is technically feasible. User-centred design investigates people’s needs and evaluates designs with them. Participatory design gives users and other stakeholders a more active role in shaping the problem and solution.
These approaches can work together. User participation does not eliminate technical constraints, and technical feasibility does not establish social usefulness.
Participatory design’s history in workplace computing and information systems is particularly relevant to my PhD. Workers have knowledge about routines, exceptions and informal coordination that developers may never see.
In a hospital, the relevant participants extend beyond the person operating a delivery robot. They include patients, cleaners, nurses sharing corridors, maintenance staff and people whose responsibilities change because the robot is introduced.
A concrete framework is the Social Robot Co-Design Canvases, developed by Minja Axelsson, Raquel Oliveira, Mattia Racca and Ville Kyrki. It structures collaborative work around three phases:
- Problem space: identify needs, stakeholders and ethical concerns.
- Design guidelines: translate those findings into requirements.
- Solution space: explore the robot’s environment, form, interaction and behaviour.
The canvases can support creating a new robot, selecting one or adapting an existing platform. That makes them relevant to labs like ours.
Value-sensitive design adds a complementary perspective. It combines conceptual investigation of values and stakeholders, empirical investigation of people’s experiences, and technical investigation of how a system supports or undermines those values.
My practical interpretation is to turn broad commitments into decisions that can be inspected. “Respect privacy” should affect recording, storage, access and deletion. “Support autonomy” should affect whether someone can refuse, pause or challenge the robot.
Modern tools expand what we can prototype
The chapter describes hardware kits, Arduino, Raspberry Pi, smartphones and 3D printing. Their central contribution is reducing the cost of trying an idea.
That principle remains useful. A cardboard model or a simple scripted interaction can answer an early design question before anyone needs a walking humanoid.
Modern software adds several complementary capabilities:
| Tool or framework | What it contributes |
|---|---|
| ROS 2 | Libraries and tools for building robot applications and connecting their software components. |
| Gazebo | Simulated robots and environments for testing robot behaviour and control. |
| NVIDIA Isaac Sim | Detailed physics and sensor simulation, synthetic data generation and robot testing. |
| NVIDIA Isaac Lab | Robot-learning workflows, including reinforcement learning and imitation learning. |
| MuJoCo Playground | Environments and training tools for robot learning, including movement, manipulation and transfer from simulation to physical robots. |
| Hugging Face LeRobot | Datasets, models and workflows for learning robot behaviour from demonstrations. |
| MoveIt 2 | Motion planning and manipulation capabilities within the ROS 2 ecosystem. |
These are software frameworks and platforms. The co-design canvases and value-sensitive design guide a different part of the work: deciding what should be built and whose needs it should address.
The distinction matters because a technically successful simulation cannot establish that people will understand, welcome or appropriately trust the resulting robot.
For an HRI study, the best prototype is the one that can answer the current question. If I want to study how an introduction changes perceived authority, I may need carefully controlled dialogue more than advanced locomotion.
Evaluate usefulness after the demonstration
A compelling demonstration shows that an interaction can happen under particular conditions. A useful evaluation asks how reliably it happens, for whom, with what effort and with what consequences.
Building on the chapter’s emphasis on iteration, I would assess a robot across five dimensions:
| Dimension | Questions to investigate |
|---|---|
| Task performance | Does it complete the intended task? How often does it need help? |
| Understanding | Can people identify its capabilities, current state and next action? |
| Reliance | Do people accept correct assistance and question incorrect assistance? |
| Recovery | Can people recognise a failure, stop the robot and resume the task? |
| Experience over time | Does it remain useful after the novelty fades? Does it create additional work for others? |
These questions also help separate variables that are easily confused. Liking a robot is different from trusting it. Trusting it is different from following its advice. Following its advice is different from achieving a good outcome.
For research, I would combine people’s reported perceptions with observable behaviour: whether they verify an answer, request human assistance, interrupt a task or correct an error.
Repeated encounters matter too. A first meeting captures initial expectations. Longer use reveals maintenance burdens, recurring misunderstandings and changes in how people incorporate the robot into daily life.
Culture, privacy and power belong in the design
The chapter challenges simple stories about national attitudes towards robots. Its examples do not support a universal division between robot-friendly Eastern societies and robot-sceptical Western societies.
For my work, that means treating culture as something to investigate through language, practices, prior experience and expectations not inferring an individual’s preferences from nationality alone.
Contemporary home robots add another design issue: who is actually participating in the interaction?
For example, 1X describes an Expert Mode in which a human can guide NEO through unfamiliar tasks. This makes the transition between autonomous operation and remote assistance part of the user experience.
My implication is that a user should be able to understand when assistance is active, what information is accessible and how to stop it. People nearby also matter, even if they did not purchase or activate the robot.
Workplace robots raise questions about power as well. A robot introduced as a supervisor may communicate organisational authority. A worker may experience its request differently from the same request made by a machine presented as an assistant.
An outside-in process should therefore investigate whose interests the robot serves, who bears the consequences of failure and who can challenge its decisions.
Those questions make the connection between HRI and information systems especially strong. Robots enter existing organisations, relationships and routines. Their effects depend on that setting.
The robot worth returning to
Chapter 4 leaves me with a more demanding definition of good robot design.
A robot should have a clear purpose. Its form and behaviour should make that purpose understandable. The people affected by it should help shape the design. Its capabilities and limitations should be communicated in ways people can use.
New humanoids and development tools expand what is technically possible. They also make the chapter’s questions more urgent: what does the robot promise, what can it deliver, and what happens when those two diverge?
The robot I would want to design is one people can understand well enough to use confidently, question when necessary and return to because it continues to help.
Selected references and resources
- Bartneck, C., Belpaeme, T., Eyssel, F., Kanda, T., Keijsers, M., & Šabanović, S. (2024). Human-Robot Interaction: An Introduction (2nd ed.), Chapter 4, “Design.” Cambridge University Press. Book website.
- Axelsson, M., Oliveira, R., Racca, M., & Kyrki, V. (2021, online publication). Social robot co-design canvases: A participatory design framework. ACM Transactions on Human-Robot Interaction, 11(1). DOI.
- Kahn, P. H., et al. (2008). Design patterns for sociality in human-robot interaction. Proceedings of HRI 2008, 97–104. DOI.
- Kennedy, J., Baxter, P., & Belpaeme, T. (2015). The robot who tried too hard: Social behaviour of a robot tutor can negatively affect child learning. Proceedings of HRI 2015. Research paper.
- Kätsyri, J., Förger, K., Mäkäräinen, M., & Takala, T. (2015). A review of empirical evidence on different uncanny valley hypotheses: Support for perceptual mismatch as one road to the valley of eeriness. Frontiers in Psychology, 6, 390. DOI.
- Lee, J. D., & See, K. A. (2004). Trust in automation: Designing for appropriate reliance. Human Factors, 46(1), 50–80. DOI.
- Norman, D. (2013). The Design of Everyday Things (revised and expanded ed.). Basic Books.
- Value Sensitive Design Lab. Methods and background.
Product descriptions and software capabilities are linked where discussed. Manufacturer materials establish stated features and intended uses; they do not independently establish effectiveness, safety or user acceptance.