UX Research
Replace guesswork with observed behaviour, scoped to the decision.
Interviews, stakeholder alignment, user sessions and journey mapping, synthesised into findings a product team can use. Not a default three-month study on every brief.
Evidence, sized to the question
Research is a tool for an expensive decision, not a ritual.
We talk to stakeholders and to the people who actually use the product, then map journeys and synthesise findings the team can act on. The scope matches the decision. A landing-page argument and a multi-role SaaS workflow do not deserve the same research programme, and we will say when an audit or a prototype test is the cheaper way to learn.
Typical constraints
The team is designing from opinions that have not been checked.
- Roadmap arguments keep returning to the loudest stakeholder.
- Personas exist as slides and nobody can point to a conversation behind them.
- Support tickets hint at a problem and nobody has watched a user attempt the task.
- A redesign is about to start on an untested story of 'what users want'.
- Sales, product and success describe three different customers.
- Previous research produced a deck that never changed a screen.
How research is scoped
Frame the decision. Then pick the smallest useful method.
We will not sell months of fieldwork because it sounds thorough. Method follows the cost of being wrong.
01
Frame the decision to be made
If the team cannot name the decision, we do not start recruiting.
02
Choose the smallest useful method
Interviews, observed tasks, stakeholder alignment or a map of existing evidence.
03
Speak with stakeholders and users
Internal stories are collected first so we know what to test, then we talk to the people who do the job.
04
Map journeys from evidence
Steps, tools and failure points drawn from what was said and shown, not from a template.
05
Synthesise findings the team can use
Patterns, exceptions and design implications in a form product can brief from.
06
Recommend what to design or skip
Including the honest option that more research would be waste.
What you receive
Findings that can change a design decision.
The output is a synthesis the team can use next week. We do not deliver a research archive that only the researcher understands.
01
Decision and question frame
What the team must decide, and which questions research is allowed to answer.
02
Stakeholder interviews
The internal story of the customer, the offer and the constraints, written down and challenged.
03
User conversations or sessions
Interviews or observed tasks with the people who actually do the work.
04
Journey maps from evidence
Paths, emotions and failure points attached to quotes and observations, not to invention.
05
Synthesised findings
Patterns, tensions and opportunities the design or product team can brief from.
06
Recommended next design move
What to prototype, what to skip, and what still does not need more research.
Useful when
This is the brief when being wrong would be expensive.
- A SaaS team is about to rebuild onboarding on an untested theory of activation.
- Two customer types are being treated as one, and the product is losing both.
- A new market or role is being added and the current journeys may not travel.
- An audit found friction and could not explain the motivation behind it.
- Leadership wants evidence before funding a large design or build programme.
- In-house teams have data and still cannot agree what the next screen should do.
What we judge
Research should change what gets designed next.
A decision the team can defend
The next design move is attached to evidence, not to the last workshop.
Journeys everyone can point to
Sales, product and design are arguing about the same path.
A smaller, clearer backlog
Work that does not serve the real job is easier to cut.
A stop rule
You know when you have learned enough to design, and when you have not.
Related work
Selected research programmes will appear here when they can be shared.
User research is rarely public. We will not invent quotes or personas for this page. Approved work lives on the Work index.
Published case studies will appear here when they are cleared.
Related services
Work that usually sits beside this.
Questions
Buying questions, answered directly.
No. If the constraint is already visible in the live product, an audit or a prototype test may be enough. Research is for decisions that are expensive to reverse or arguments that cannot be settled with current evidence.
Next move
If the team is guessing, gather evidence first.
Name the decision you need to make and the people you can reach. We will say whether interviews, an audit or a prototype test is the smallest useful next step.