Building a user-centred mindset across teams
Jump ahead:
- From a design discipline to a team discipline
- User-centred teams have different conversations
- Activities versus behaviours
- Intellectual humility is one of the most important characteristics of UCD
- Building the state of mind
- UCD shouldn't be something you switch on
Ask someone to describe user-centred design (UCD) and they'll probably start by listing activities:
👉 User interviews
👉 Personas
👉 Journey maps
👉 Prototypes
👉 Usability testing
👉 Accessibility reviews
👉 Analytics
All of these can be valuable, but they're tools for practising UCD rather than UCD itself.
A team could do every one of them and still make decisions based on what stakeholders want, or what competitors are doing.
I’ve worked on plenty of smaller, tech-focused, founder-led products where this culture takes hold and the habit needs disrupting. Cultivating a UCD mindset across teams is never easy, but it’s important. Arguably more so now that teams are building with probabilistic AI tools.
At the other extreme, a team might not practise any of the above but is still remarkably user-centred. I’ve seen this in teams where senior members are very close to customer services for example, or where an engineer triages support tickets and feeds the insights back into the team.
The difference is in how the team makes decisions.
At its heart, UCD is the habit of consistently addressing the needs, behaviours, and experiences of users.
It's asking what problem we're trying to solve and who has that problem, questioning how we know the problem exists and what evidence we have, and which parts of our understanding are really just assumptions.
It's considering what a good outcome would look like for the user, and finding the quickest and most appropriate way to learn whether our thinking is right.
These are questions teams should ask across all disciplines.
From a design discipline to a team discipline
One of the problems with user-centred design is right there in the name: design.
It’s easy for teams to subconsciously treat users as the researcher’s and designer's responsibility.
They become the person expected to advocate for users, understand their needs, and challenge the rest of the team when decisions do not serve them.
The problem is that users do not conveniently exist in one part of product development.
A user’s experience can be dramatically affected by technical decisions, commercial decisions, or operational constraints.
If we're serious about building products around people's needs, both decision makers and teams need to understand their users. This is important, because almost every meaningful product decision eventually has consequences for those who use your product.
But that does not mean everyone suddenly becomes a user researcher or product designer.
Planning good research, conducting interviews, designing interactions, and interpreting evidence all require specialist skills. Orientating teams around the user does not require a design qualification.
User-centred thinking needs to become a mindset, shared across all teams.
User-centred teams have different conversations
You can often tell how user-centred a team is simply by listening to how they prioritise and solve problems.
Imagine a stakeholder asks for a new feature:
❌ A team focused primarily on delivery might immediately start discussing how it could work, and how much effort it would take.
✅ A more user-centred team is likely to pause before getting that far. They are more likely to probe the request. They’ll ask what problem the feature is actually intended to solve, who experiences that problem, and ask for evidence.
I’ve noticed that these teams demonstrate an instinct. They do not jump immediately from an idea to a solution. Instead, they stay curious, challenge assumptions, and look for evidence.
Activities versus behaviours
This wider team mindset becomes clearer when we separate the activities teams do from the behaviours those activities are supposed to encourage:
| UCD activity | The behaviour we’re actually trying to create |
|---|---|
| User interviews | Genuine curiosity about people’s needs |
| Personas | Shared understanding and empathy |
| Journey maps | Seeing the wider experience, not just the product |
| Usability testing | Willingness to learn rather than prove we’re right |
| Analytics | Making decisions using evidence |
| Prototypes | Testing ideas before committing to them |
| Discovery | Understanding the problem before jumping to solutions |
The behaviour is the goal.
After 15+ years of working in product teams, I’ve seen how UCD can become dangerously performative.
Artefacts and ceremonies of user-centred design can be performed without necessarily adopting these behaviours. When an important decision needs to be made, evidence can still lose out to assumptions, hierarchy, or whoever can make the most convincing argument.
Intellectual humility is one of the most important characteristics of UCD
Being comfortable with being wrong is a characteristic that separates user-centred teams from those following a process.
That's harder than it sounds. Once people invest time into an idea, they naturally become attached. The further they progress with an idea, the more difficult it becomes to abandon.
This is why intellectual humility is one of the most important characteristics you should look to nurture.
A user-centred team will treat an idea as a hypothesis rather than a conclusion. They might believe a problem exists, that a particular solution will solve it, or that users will understand a particular interaction, but until there's evidence, those things are still assumptions.
This changes their relationship with pursuing research. Research should help the team understand where it might be wrong.
If the goal is learning, contradictory findings help teams course correct.
I’ve fallen into this trap myself. I went into research reasonably convinced of an assumption and had already started thinking about solutions. When I put them in front of users, my biases surfaced and were impossible to ignore.
The uncomfortable but useful conclusion was that we’d listened to our own opinions rather than those of our users. I checked my ego and retested multiple options.
Building the state of mind
If a team is not working like this today, adding more processes is not the answer.
In fact, adding another mandatory research template, framework, or design ceremony can sometimes reinforce the idea that UCD is a box to tick.
A better starting point is to change some of the small, everyday habits that shape how decisions get made.
Bring evidence into everyday conversations.
When discussing an idea, get into the habit of asking what evidence supports it. That does not mean every question requires a six-week research project.
Evidence might come from:
👉 Previous research
👉 Analytics
👉 Customer support conversations
👉 Usability sessions
👉 Behavioural data or something the team learned yesterday.
Teams should begin to expect that decisions connect to reality.
Make assumptions visible.
Every product team operates with assumptions. The dangerous ones are the assumptions nobody realises they are making. Making assumptions explicit helps teams test them, rather than treat them as facts.
Get the whole team closer to users.
Research reports and presentations are useful, but they are no substitute for exposure to real users. This creates shared understanding and reduces the need for the designer or researcher to constantly act as the team's translator for everything users think, feel, and do.
Test things while they're still cheap to change.
The purpose of user-centred design is to learn while you still have options. Learning that you've misunderstood the problem isn't wasted effort; it's information that prevents much greater effort being wasted later.
Testing early also means deciding how to test. In my most recent client engagement, our team needed more structure around how to gather user feedback. We established a lightweight framework to make this decision quickly.
Gold: The work spans several assumptions and feature touchpoints across a wide user journey. It needs at least one moderated user test, and potentially more if we learn and pivot.
Silver: The work covers a narrower feature or a more focused user need. It needs more agile feedback, such as unmoderated testing or a survey.
Bronze: The work is low risk, and we’re confident in our decisions without further insight. We ship the feature and learn from live monitoring.
Rolling out this framework gets the whole team discussing user needs far earlier. It sparks debate about what we know, and what we don’t know.
UCD shouldn't be something you switch on
The takeaway of this article is to create teams that instinctively consider users when making decisions.
Research still matters. Design expertise still matters. Methods, frameworks, and processes still matter too. But they're mechanisms for encouraging something more fundamental:
✅ Curiosity about the people we're designing for.
✅ A preference for evidence over opinion.
✅ A willingness to challenge our own assumptions.
✅ The humility to change direction when we discover we're wrong.
When those behaviours become embedded across a team, designers and researchers remain important specialists, but they no longer carry sole responsibility for keeping the team connected to the people it's designing for.
UCD becomes part of how the team thinks.
