When I started my design training back in 2001, one of my earliest assignments was to choose a workplace and a user, then go observe. I chose to accompany a teacher at a local primary school. I spend an hour each week watching her do her job, noting which tasks were most time-consuming, which worked, which didn’t, which were frustrating, and which were most rewarding. As an early graduate student, straight out of school, I was learning to step into the shoes of the user and exercise empathy, to try to see things from their point of view. I was essentially doing what we call “Ethnographic research”.
During my research, I wasn’t asking “What do you want?” I was quietly witnessing the reality of their working lives and looking for opportunities where design could make an impact.
At first, this approach felt counterintuitive. Wouldn't it be faster to simply ask teachers what they wanted? As the weeks went by, I began to understand the power of observation over interrogation. When people are asked directly, their answers often stay within what is familiar to them, a pattern influenced by a cognitive bias known as the "known-solution trap." We are naturally inclined to imagine solutions only from our past experience or current environment, while overlooking unknown possibilities. I saw how teachers navigated busy classrooms, juggled resources, and improvised clever solutions to everyday challenges, many of which they accepted as just how things are. By observing rather than asking, I was able to uncover needs and problems that might have been invisible even to the users themselves.
I wasn’t just stepping into the teacher’s shoes. I was also seeing with fresh eyes.
Instead of gathering a list of feature requests and expecting answers from the user, I gathered insights into real pain points and workarounds. My classmate and I then brainstormed ideas, prototyped solutions, and brought them back to the teachers to observe if our designs actually improved their efficiency, effectiveness, or satisfaction. Sometimes our ideas didn’t work. That was okay. We iterated and refined, watching carefully for meaningful impact, not just polite approval.
An introduction to the design thinking process
If you’d like a deeper dive into this approach, you might want to know more about the design thinking process. Here’s a useful introduction.
Why don’t we ask “What do you want?”
This project taught me the foundational principle of user experience (UX) research: we are not order takers. Most users, when asked what they want, will describe a solution based on what they already know or have seen in other similar solutions. People are often unaware of the underlying causes of their frustrations, or they’ve adapted so thoroughly to suboptimal systems that they no longer notice the problems.
As UX practitioners, our job isn’t to act as short-order cooks, serving up whatever is requested. Instead, we:
Observe real behaviours. What do users actually do, not just what they say they do?
Identify needs and opportunities. Where are the pain points, inefficiencies, or sources of delight?
Prototype, test, and iterate. Bring solutions into the real context, watch how they fit, and refine based on evidence, not assumptions.
This observational, iterative approach leads to better, more innovative, and more impactful products. For example, imagine a KPI like time saved per day for a teacher, or a measurable reduction in error rates when recording student progress. Those kinds of metrics make the real-world payoff clear, especially to decision-makers who need to see tangible value. It’s why the best UX work starts not with a list of requests, but with a willingness to watch, listen, and learn. After all, our goal is to create solutions that users truly value, that improve their lives, that transform their experience. Sometimes the solutions are the ones they never imagined were possible.
This is my favourite resource about why we don’t ask users for solutions. An entertaining explanation by Alan Cooper, a pioneer of user-centred design:
