Trust is shaped by decisions users never see.

It started with a contradiction.

This project started with a 1,5 month research phase. During my research on trust in human-machine interaction, I kept running into the same paradox. Every product team agreed that trust matters. During 6 interviews with experienced UX designers, yet almost nobody could explain how their day-to-day design decisions actually shape it.

Trust wasn't ignored. It was simply too abstract to influence everyday product decisions. Furthermore, close deadlines, unrealistic goals, and competing priorities often pushed trust considerations to the background.

Additionally, the fact that trust is a very abstract concept - and is perceived differently by each stakeholder - doesn’t make things any easier. For example, a developer might be satisfied as long as the product works, but a designer might feel that the emotional connection needed for customer loyalty is missing, and a project manager might consider time too precious to go through another iteration.

Topics I started to explore:

Trust had to become tangible.

The deeper I explored the problem, the more I realized that trust isn't something teams can simply discuss into existence. Frameworks, guidelines and principles create awareness but they rarely change the way decisions are made.

Trust is built through experience. Not through presentations. Not through checklists. But through moments that make invisible consequences visible. That realization became the turning point of the project. Instead of creating another framework, I began designing an experience.

Creating a shared experience

With this realization, trust doesn't emerge from interacting with a product once. It develops through interpretation, discussion and shared understanding.

I therefore designed an interactive workshop where product teams could experience the impact of design decisions before reflecting on them together. Rather than teaching principles of trustworthy design, the workshop encourages participants to observe behaviour, challenge assumptions and develop a shared language for discussing trust.

Designing behaviour instead of interfaces.

Designing the robot wasn't about creating personality. It was about translating abstract design principles into observable behaviour. Every movement, pause and reaction was intentionally designed to communicate a different quality of trust. During my research, I identified the following characteristics that are necessary for trust. Some are more pronounced, while others are less so.

Rather than asking participants what trustworthy design means, the workshop allows them to experience it first and reflect on it afterwards. The robot becomes a conversation starter, a shared point of reference and a physical reminder that every digital interaction communicates something, even when the interface seems invisible.

Behind the experience

Creating the experience required much more than designing a workshop. It meant translating an abstract research topic into something people could see, feel and remember. Every design decision from the workshop structure to the robot's behaviour served the same purpose: making trust tangible.

Furthermore, this experience should not only be present during the workshop but should also continue to resonate afterward. For this reason, the various phases of the workshop were developed, which are described in more detail below.

Understanding trust

The project began with an extensive research phase exploring how trust is formed in interactions between people and digital systems. Through literature review and expert interviews, I identified three core dimensions that shape trust: Competence, Benevolence and Integrity. While these concepts are well established in theory, I discovered that they rarely become part of everyday product decisions.

This insight became the foundation of the entire project.

Defining the scope

Rather than trying to solve every aspect of the problem, I focused on validating the core hypothesis behind the project: If trust is experienced rather than explained, can physical interaction help product teams make better design decisions?

The outcome is not a finished product, but a proof of concept that demonstrates the potential of experiential learning in strategic product development.

Designing the experience

The challenge wasn't to explain trust. It was to make people experience it. I designed a workshop that gradually moves participants from individual observations to shared decision-making. Each activity builds on the previous one, allowing teams to first experience behaviour, then reflect on it and finally translate those insights into concrete design principles for their own products.

Instead of searching for the "right" answers, the workshop creates space for discussion, negotiation and collective reflection.

Designing behaviour

The robot wasn't designed as a product. It was designed as a behavioural system. Every movement, pause and reaction was intentionally crafted to communicate different qualities of trust.

Instead of relying on facial expressions or speech, the prototype explores how behaviour alone can influence the perception of competence, benevolence and integrity. Designing these interactions became an exercise in behavioural UX rather than interface design.

Attributes: K=Competence, W=Benevolence, I=Integrity.
Intensity: 1=low 2=normal 3=high

To change Klausi’s behavior, participants need a smartphone. They use it to scan one of the QR codes displayed on Klausi’s iPad. Each QR code can only be scanned once per round. The three QR codes represent Competence, Benevolence, and Integrity, respectively. Participants then set the intensity for each of the three values and send it to Klausi. Once Klausi has received all three values, he waters the plant according to the values sent, as shown in the table above. The iPad also displays his thoughts and what the participants need to do next.

Building the prototype

To bring the concept to life, I stepped beyond traditional UX design. I designed the robot's enclosure in CAD, researched and selected the hardware components, built the electronics, developed a browser-based control interface and programmed the behavioural logic using Arduino with AI-assisted implementation.

Working across industrial design, physical computing and interaction design allowed me to prototype the complete experience rather than only illustrating it. The result isn't a polished product. It's a proof of concept demonstrating how physical interaction can support strategic design conversations.

Designing within constraints

This project was developed independently within a three-month timeframe. The original concept envisioned 27 behavioural expressions. For the prototype, I implemented three fully functional behavioural states that were sufficient to validate the interaction concept.

Unlike in the workshop’s vision, the three preset behavior patterns could be selected directly on the iPad in the prototype. It would therefore still need to be tested how it feels when the values can be adjusted individually using a cell phone, and whether users recognize that these adjustments then contribute to changes in Klausi’s behavior.

Several technical decisions were deliberately pragmatic. Looking back, I would choose a different hardware architecture to enable true parallel processing and richer behavioural interactions. These constraints became an important reminder that prototyping isn't about building everything. It’s about building enough to answer the right questions.

Looking back

This project changed once again how I think about design. Building every part of the experience myself from research to hardware gave me a deep understanding of how different disciplines contribute to a single user experience.

At the same time, it highlighted the value of collaboration. Many aspects of the robot's behaviour were based on informed design decisions, but they remain hypotheses that deserve further validation with users and experts from fields such as behavioural science and physical computing.

If I continued this project today, I wouldn't start by adding new features. I'd start by building the right interdisciplinary team.

What this project ultimately proposes.

Rather than offering a framework to follow, Embodied:Intent proposes a different way of approaching trust in product design - by transforming abstract concepts into shared experiences that inspire reflection, dialogue and more intentional design decisions.

My 3 key takeaways from this project are: