UCD
Government
Healthcare
View more blogs
User-centred design (UCD) often gets taught as a clear, structured process: speak to users, validate decisions, iterate, deliver. In an ideal world, everything flows neatly. But in reality? It rarely works like that.
In this blog, Opencast Senior Interaction Designer James Tabiner shares his perspective on what it means to practise UCD in the real world, especially in environments shaped by constraints like tight budgets, shifting deadlines, limited user access, or small teams. His core message: the real skill isn't just practising UCD when conditions are ideal; it's knowing how to adapt when they aren't.
The gap we all feel
In an ideal world, we all have clear access to users, defined roles across a multidisciplinary team, time for proper iteration and strong governance and validation. However, in reality, I have often found myself in situations where:
I cannot always access users directly
I am the only designer on the team
Timelines are shifting
The project is driven by business requirements and regulatory constraints
That gap between ideal UCD and reality is where discomfort comes in. For me, the uncomfortable feeling usually doesn’t come from the work itself. It comes from not being able to follow the process I have been taught is “correct”.
Why clinging to process can hold us back
When we as designers feel discomfort, our instinct is to cling tightly to process and try to do things the “right” way. But I have learned that this can cause its own problems. I have seen it lead to:
Waiting for perfect research that never comes
Feeling like I can’t move forward without certain inputs
Missing opportunities to shape early decisions
Missing opportunities to influence decisions when design activities are perceived as delaying progress
Putting pressure on myself and questioning whether I am doing things wrong
There are absolutely times when you need to advocate for certain activities to ensure decisions are informed by the right evidence. However, if you cling too tightly to process, you can end up stuck.
Reframing what “good” looks like
What has helped me most is reframing how I think about UCD. I no longer see it as a checklist. I see it as a mindset. If it’s a checklist, you are blocked the moment you can’t complete something. With a mindset, there is always a way to move forward.
For me, good design is not about following UCD perfectly. It's about delivering meaningful outcomes while working within real-world constraints.
Once I started thinking this way, it opened things up. Instead of asking myself if I am doing it correctly, I ask whether I am reducing uncertainty and improving outcomes.
A more flexible way of thinking
Over time, I have started reframing some of the core principles to ensure I can move forward regardless of the situation I’m presented with:
Instead of starting with user research, I always aim to start with the best understanding I can get my hands on and build from there
Instead of testing frequently with users, I focus on finding ways to reduce uncertainty however I can
Instead of validating every decision, I prioritise the riskiest ones
Instead of aiming to follow the process perfectly, I try to do the best possible thing within the constraints I have
I am not abandoning UCD when I do this. I am adapting it.
What I actually do in practice
There are a few things I have leaned on repeatedly when things are not ideal:
Using proxy users
If I cannot speak to real users, I find the closest option I can. That might be support teams, sales teams, analytics data, or even previous research. While it is not a substitute for direct user access, it can provide valuable insight.
For example, on a past project, I couldn’t get access to users at all. So, I worked with their customer support team instead. They were dealing with user problems every day, and that gave me enough initial insight to move in the right direction.
What I always remind myself here is I am not aiming for a perfect understanding. I am aiming for something that is directionally correct.
Mapping assumptions early
When I don’t have certainty, I make sure I am explicit about it. I map out:
What I know
What I am assuming
What the risks are
Having these assumptions clearly documented ensures I can prioritise what needs to be validated first. In some cases, not everything needs validating. I focus on addressing the things that could break the experience first.
Keeping validation lightweight
If we are unable to validate assumptions and design decisions with usability testing, I find smaller ways to get feedback. I’ve grabbed colleagues to run quick tests. I’ve facilitated walkthroughs with internal teams and stakeholders. I’ve shared early drafts with users and asked simple questions to understand what is unclear or what would be expected to happen next.
It’s not perfect, but in some cases, it helps me reduce risk enough to move forward.
Being conscious when working from business requirements
Sometimes business requirements are all I have available initially. In those situations, balancing business goals with user needs becomes more challenging, so I focus on making assumptions explicit and identifying where the greatest risks lie. Rather than pushing back blindly, I reframe requirements as hypotheses, consider their potential impact on users, and look for opportunities to validate them over time. I also make it clear to stakeholders when decisions are being made with limited evidence, helping teams understand the associated risks and make informed choices. I've found that being transparent about uncertainty builds trust and keeps everyone aligned.
Being a team of one
There have been times where I have had to take on multiple roles within a project, which can be stressful. When that happens, I try to:
Focus on what matters most
Prioritise key journeys over everything else, sometimes we can’t account for every scenario
Communicate trade-offs clearly to build trust
Lean on others for support where I can, whether that be speaking to a User Researcher to ensure I’m not asking biased questions or talking to a Business Analyst to understand how they would approach breaking down some high-level requirements.
Most importantly, I remind myself that I am only one person operating under these constraints. Comparing myself to a fully resourced team is not helpful.
Redefining “good enough”
One of the biggest shifts for me has been redefining what “good enough” looks like. I do not need perfect validation. I need enough to move forward with confidence. My job is not to eliminate risk completely. It is to reduce it to a level the team is comfortable with and can make decisions from.
Progress matters more than perfection.
Dealing with the pressure
Most of the pressure I have felt in challenging situations has come from within. I hold myself to a high standard that the environment does not always support. Recognising that gap has helped me approach those situations with more perspective.
I have learned to be comfortable with a degree of uncertainty. Feeling uncomfortable does not mean I am doing something wrong. More often, it means I am navigating real constraints and making the best decisions I can with the information and resources available.
Why this matters
Working this way has made a difference for me. I feel more confident in ambiguous situations. I put less pressure on myself. I feel like I can still influence outcomes, even when conditions are not ideal.
For clients and teams, it means we keep moving. We make progress. We adapt to reality rather than getting stuck waiting for perfect conditions that may never come.
Final thought
I used to think confidence came from following the process perfectly. Now I think confidence comes from making decisions when the process breaks down. The perfect version of UCD is structured and predictable. The real world isn’t. The real skill is knowing what to do in that gap. For me, getting comfortable being uncomfortable is about accepting that gap exists and moving forward anyway.
OpenPerspectives is our platform for Opencast people to share their thoughts and perspectives on modern digital delivery. It offers practical insight into user-centred design, engineering excellence, product leadership, data-driven decision making and building expert capabilities, grounded in real-world experience.
Related Content
View more blogs