Building With People

In my last semesters at Freie Universität Berlin I took a course on human computer interaction with Prof. Dr. Claudia Müller-Birn. I expected a useful elective. What I got was the course that has shaped my work more than any other, and I want to write down why, because I still think about it most weeks.

Until then, building software had mostly meant this: understand the requirements, design something sensible, build it well, hand it over. It is a reasonable way to work and it produces reasonable software. The course showed me a different order of things, and once I had seen it I could not go back.

What HCI actually is

Human computer interaction sounds like a topic about screens. It is really a topic about people. The field asks how people perceive, decide, remember and act, and what that means for the things we build for them.¹ A button is not a button; it is a promise about what will happen next. A form is a conversation with someone who cannot ask you a question. Every interface is a small theory about the person on the other side, and most of the time that theory is written by someone who has never met them.

A few ideas from the course have stayed with me for good. Affordances: a thing should look like what it does. Feedback: after every action, the system should answer. Mental models: people carry an idea of how something works, and when the software disagrees with that idea, the software loses, whatever the specification says.² And the humbling one: you are not the user. Your familiarity with the thing you built makes you the worst judge of whether it is clear.³

The cycle

Human centred design turns those ideas into a way of working, and this was the part that changed me. It is a loop rather than a line, and it is so central to the field that there is an international standard describing it.⁴ Four activities, repeated: understand the people and the context they work in; write down what they actually need; design something; put it in front of real people and evaluate it. Then round again, with what you learned, until the design fits the people it is for.

1. 01

   Understand the context

   Who the people are, what they are trying to do, and where. Watch, ask, listen.

2. 02

   Write down what they need

   Not the feature list. The real needs, in their words, as personas, scenarios and user stories.

3. 03

   Design something

   Small and rough at first. Sketches, then a prototype you can click through.

4. 04

   Test it with real people

   Give them a task, ask them to think aloud, stay quiet. Learn what they love and what could be more intuitive.

5. ↻

   Round 1 of 3. Each round makes the thing in the middle a little sharper.

Two things about this loop took me a while to appreciate. The first is that it starts before any design exists.⁴ You go and look at how people do the thing today, in their environment, with their workarounds, before you draw a single screen. The second is that the loop does not end where you think. "Done" is not when the feature list is ticked off. Done is when real people can do what they came to do, and the only way to know is to watch them try.

The tools along the way

Each stage has its own craft, and the course gave me a whole kit for it.

Personas turn "the user" into a handful of specific, believable people with names, goals and frustrations, drawn from what you learned in the research rather than invented at a desk.⁵ Once a persona exists, arguments in the team change shape: not "I think" but "would Mara, who does this on her phone between two shifts, understand that?"

Scenarios and user stories describe what those people are trying to achieve, in their own words and without any solution attached.^{6, 7} "As an organiser, I want to see who is on shift tonight, so I can call the one person who has not shown up." The best user stories are small, and the good ones surprise you, because they contain a need nobody wrote in the brief.

Prototypes let you show instead of describe. A paper sketch first, then a clickable mock, then a rough working version.¹ The fidelity grows with your confidence; you spend little on the ideas you are unsure about and more on the ones that have survived a round with people.

And then there is the one I would keep if I could only keep one.

Usability testing, the heart of it

Usability testing is not a survey and not a demo. You give someone a task, ask them to say what they are thinking as they go, and then you stay quiet.⁸ The think-aloud method is almost embarrassingly simple, and it is the most honest instrument I know.⁹ Within minutes you hear the small hesitation before a click, the "wait, what does this mean", the workaround someone invents without noticing. None of that shows up in a meeting. All of it shows up in the first twenty minutes with a real person.

What I love most is that it is not a verdict. It is not about good or bad, pass or fail. You learn what people like and why, which matters just as much as the rest, because that is the part you keep and build on. You learn which moments simply feel obvious to them and which could become a bit more intuitive, and what intuitive would mean for these particular people. After a few sessions there is usually an intersection, a handful of things that felt natural to almost everyone, and that intersection is worth more than any opinion in the room, including mine.

There is a fine line to walk here, and it is my favourite part of the job. Familiarity matters: people arrive with patterns they already know from everything else they use, and it is kind to meet them there.¹⁰ But if you only ever follow what people already know, nothing new gets made. The interesting work is bringing ingenuity into that familiar ground, a new idea where it truly helps, and then testing whether it lands. Sometimes it does not, and you learn. Sometimes it does, and you have just shaped what will feel intuitive to people tomorrow. Iteration is what makes that safe: each round is small enough to be cheap, and five people are usually enough to show you where you stand.¹¹

The magic part

What I did not expect was how much fun it is. Sitting next to someone while they use something you made, with a careful briefing so they know the software is being tested and not them,¹ is one of the most alive moments in this whole profession. People are generous. They tell you things you could never have guessed. They point at the screen and say "I would want this here", and they are right, and you can feel the product get better in real time.

There is a quiet shift that happens when you work this way. The people you build for stop being an abstraction called "the user" and become collaborators. The design stops being yours to defend and becomes something you are making together. That sounds soft, but it is the most practical thing I know: it takes the guessing out. Whole arguments about what people want dissolve because you simply go and find out.

How I work now

Almost everything about how I build today comes from that loop. Within days of starting something, there is a working version you can click through, not a document describing one. It is deliberately small, just enough to do the job. Then it goes in front of the people it is for, and the next version is shaped by what they did with it, what they enjoyed, and what they wished for.

I have watched this work on real products. When we built the ticket shop for Sovereign Tickets, people went through a sandbox that looked exactly like the real shop, thinking aloud from the first click to a paid ticket in their inbox. An hour of that was worth more than any amount of guessing. During my bachelor thesis I sat with two cardiologists and watched them read counterfactual explanations for ECGs; the explanations only became useful once they respected how the doctors actually look at a recording. The same lesson every time.

It also changed what I think good engineering is. The interesting decisions are rarely in a single component. They are in the thousand small choices between a system that works and one a person trusts: what to show, what to leave out, how it behaves when something goes wrong, whether the person in front of it can always tell what happens next. Those are design questions and engineering questions at the same time, which is why I like doing both.

I am grateful for that course, and for a teacher who made a room full of computer science students go and talk to people. Her group at FU Berlin, Human-Centered Computing, still works in exactly that spirit today, on how AI can support the decisions people make and on participatory ways of designing such systems, where the people affected by a technology have a real say in how it is made.^{12, 13, 14} It is the most important thing I learned at university, and I get to use it every single day.

References

1. 1

   Helen Sharp, Jennifer Preece and Yvonne Rogers, Interaction Design: Beyond Human-Computer Interaction, fifth edition. Wiley, 2019. The textbook for the whole field, including prototyping fidelity and how to run a usability session.

2. 2

   Don Norman, The Design of Everyday Things, revised and expanded edition. Basic Books, 2013. Affordances, feedback and mental models, and still the best first book on the subject.

3. 3

   Raluca Budiu, You Are Not the User: The False-Consensus Effect. Nielsen Norman Group, 2017.

4. 4

   International Organization for Standardization, ISO 9241-210:2019, Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems. The standard that describes the cycle: four activities, iterated, starting from an understanding of the context of use.

5. 5

   Alan Cooper, The Inmates Are Running the Asylum. Sams, 1999. Where personas come from.

6. 6

   John M. Carroll, Making Use: Scenario-Based Design of Human-Computer Interactions. MIT Press, 2000.

7. 7

   Mike Cohn, User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.

8. 8

   Jakob Nielsen, Thinking Aloud: The #1 Usability Tool. Nielsen Norman Group, 2012.

9. 9

   K. Anders Ericsson and Herbert A. Simon, Protocol Analysis: Verbal Reports as Data, revised edition. MIT Press, 1993. The roots of the think-aloud method.

10. 10

    Jakob Nielsen, End of Web Design. Nielsen Norman Group, 2000. The origin of what is now called Jakob's law: people spend most of their time on other products, so they expect yours to work like the ones they already know.

11. 11

    Jakob Nielsen, Why You Only Need to Test with 5 Users. Nielsen Norman Group, 2000.

12. 12

    Peter Sörries, David Leimstädtner and Claudia Müller-Birn, Advocating Values through Meaningful Participation: Introducing a Method to Elicit and Analyze Values for Enriching Data Donation Practices in Healthcare. Proceedings of the ACM on Human-Computer Interaction, volume 8, CSCW1, 2024. A method for letting the people affected by a system, here patients, say what matters to them before it is built.

13. 13

    David Leimstädtner, Peter Sörries and Claudia Müller-Birn, Unfolding Values through Systematic Guidance: Conducting a Value-Centered Participatory Workshop for a Patient-Oriented Data Donation. Mensch und Computer, 2022. The workshop format behind it.

14. 14

    Human-Centered Computing, the research group of Claudia Müller-Birn at Freie Universität Berlin.