User Research Isn't a Luxury. It's How You Get the Results You Need.

Everyone talks about wanting to be user-centred but do they walk the talk?

We hear it often that all organisations have the desire to be seen as user-centred. UCD (user-centered design) is the  second biggest buzz phrase after AI - of course. Is that because it signals digital maturity, innovation, and a commitment to delivering better user experiences or is it just a box ticking exercise?.

I myself can often be found waxing lyrical about our UCD practice at Zoocha, whether in pitches or with new and existing clients. We have a robust and scalable Discovery framework - the Zoochange Toolkit - based on Design Thinking and User-Centred Design methodologies.

A core principle of our approach is that user insight should never be treated as an optional extra reserved for large budgets. The scale and methods of research may vary depending on time, budget and complexity, but there is always an opportunity to learn from users. Some user research is better than none, and there are often faster, leaner and more cost-effective ways to gather meaningful evidence than stakeholders initially realise.

By right-sizing our research activities, from stakeholder interviews and usability testing to surveys, analytics reviews and rapid discovery workshops, we help clients reduce risk, challenge assumptions and make more informed decisions. 

The result is a stronger foundation for product strategy, service design and delivery, regardless of project size.

Ultimately, UCD is not about doing more research; it's about doing enough research to build confidence that we're solving the right problems for the right people.

But in reality when considering user research the response can sometimes become ‘Can we just use best practice?’  We understand as budgets tighten, deadlines shrink, or stakeholders want a quick solution, user research is often the first thing to be removed from the plan.

Why "Best Practice" isn't always best for your users

The challenge is that best practice is usually based on general patterns and averages. Your users, business goals, and context may be very different. While these approaches can feel faster, they rarely answer the most important question: What do your users actually need?

A solution that works brilliantly for one organisation can fail completely for another.

Research helps uncover:

• What motivates your users
• The barriers preventing them from completing tasks
• The language they use
• The journeys they actually take

These insights create solutions that are tailored to both user needs and business objectives.

The real cost of skipping research

Research is often viewed as an additional cost, but in reality, it's a form of risk reduction. By investing in understanding user needs, behaviours and pain points early, organisations can avoid costly mistakes, reduce rework and make more informed decisions. The cost of research is often far lower than the cost of building the wrong thing, solving the wrong problem or launching an experience that fails to meet user expectations.

Without understanding user needs, organisations can end up:

Building features nobody uses

It’s a common scenario: the CEO, Marketing Director or CTO has a great idea for a new feature and is convinced it belongs on the website. The challenge is determining whether it genuinely delivers value to users, supports business objectives and generates a return on investment. Don't let decisions be driven solely by the HiPPO—the Highest Paid Person's Opinion.

Mitigation: Before committing valuable budget and development time, test the idea with users. A lightweight prototype can provide invaluable insight into whether the feature solves a real user need, how people expect it to work, and whether it is likely to drive the desired outcomes.
These prototypes don't need to be fully functional or pixel-perfect. Low-fidelity wireframes, clickable mock-ups or even simple concept sketches can be enough to validate assumptions and gather meaningful feedback. Investing a small amount of effort upfront can prevent significant expenditure on features that users neither need nor want, while helping identify opportunities that genuinely deserve future investment.The goal isn't to prove an idea right or wrong—it's to ensure investment decisions are guided by evidence rather than opinion.

Solving the wrong problem

Organisations often jump straight to solutions when something isn't performing as expected. If users are struggling with a service, abandoning a journey or failing to complete a task, it's tempting to redesign the interface, add new functionality or rebuild the experience. But simply knowing that "it doesn't work" rarely provides enough insight to identify the right fix.

Mitigation:Take the time to understand why the problem exists before deciding how to solve it. User interviews, usability testing, journey mapping, analytics reviews and stakeholder workshops can all help uncover the real barriers users are experiencing.

Sometimes the issue is a design flaw, but often it's something much simpler: unclear content, poor information architecture, confusing terminology, missing expectations or an internal process that creates friction. By identifying the root cause, organisations can focus investment where it will have the greatest impact, avoiding costly redesigns and ensuring that solutions address genuine user needs.

Asking "Why?" a few more times at the start of a project can often save significant time, money and effort later. The goal isn't just to fix what's visible—it's to understand what's causing the problem in the first place.
 

Designing around organisational assumptions

One of the most common pitfalls in digital projects is designing services around an organisation's internal structure, terminology and assumptions rather than around how users actually think and behave.

Departments, business units and reporting lines may make perfect sense internally, but users rarely understand—or care about—an organisation's operating model. When websites and services are organised according to internal structures, users can struggle to find information, complete tasks and understand where they need to go next.

Mitigation: Validate assumptions early and often with users. Research activities such as interviews, surveys, card sorting, tree testing and usability testing can reveal how users naturally categorise information, the language they use and the journeys they expect to follow.

Rather than asking users to learn your organisation's structure, design experiences that align with their mental models and goals. This may mean challenging internal conventions, simplifying terminology or restructuring navigation around user needs rather than organisational ownership.

The most effective digital services are organised around what users are trying to achieve, not around how the organisation happens to be structured behind the scenes. User-centred research provides the evidence needed to make that shift with confidence.

Conclusion

User-centred design isn't just about fixing problems; it's about creating experiences that help people achieve their goals more effectively while delivering measurable value for the organisation. When we take the time to understand users, we often uncover opportunities to improve conversion, increase engagement, reduce support costs and maximise the return on digital investment.

The impact extends far beyond the user experience itself. Every failed journey, unanswered question or confusing process can result in increased contact centre volumes, more support tickets and greater pressure on internal teams. What may appear to be a saving during discovery or design can quickly re-emerge as an operational cost once the product or service is live.

Research is often viewed as an additional expense, but in reality it is a mechanism for reducing risk and uncertainty. The cost of correcting a wrong decision late in a project is almost always significantly higher than the cost of validating assumptions early.

One of the most common responses we hear is, "We already know it doesn't work." And that's valuable. But knowing that something isn't working is only the starting point. The real value comes from understanding why it isn't working. Without that insight, teams risk treating symptoms rather than addressing root causes, leading to costly redesigns, unnecessary features and missed opportunities.