UX research observes how real people attempt tasks in a product, identifying where they hesitate, misinterpret or fail. Methods include moderated usability testing, session recordings, journey mapping and interviews. The output is specific, prioritised design problems rather than general opinions.
Five users will humble the team
Watching five people attempt a task on your site is the fastest way to end an internal debate. Problems the team argued about for weeks turn out not to matter; things nobody questioned turn out to stop people entirely.
This is especially true for products serving users unlike the team building them — older users, first-time internet users, people on low-end phones, people who do not read English comfortably. Assumptions fail hardest exactly where the stakes are highest.
Process
How we deliver it
Process flow for User experience
01
Define the tasks
The journeys that matter commercially or civically.
02
Recruit real users
Representative of actual users, not colleagues.
03
Observe
Moderated sessions plus recordings of unmoderated real use.
04
Prioritise findings
By severity and frequency, not by ease of fixing.
05
Redesign and retest
Fix, then verify the fix worked.
Deliverables
What you receive
Usability findings with severity ratings and session clips
Journey map showing friction points and emotional low points
Information architecture recommendations
Accessibility audit against WCAG 2.1 AA
Prioritised design fixes with rationale
Engagement shape
Three to six weeks for a research round. Best repeated at intervals rather than run once before a launch.
Stack decisions follow the problem. This is where we usually start, not a fixed menu.
Frequently asked
Questions we get about this
How many users do we need to test with?
Five per user group finds the large majority of severe usability problems, which surprises people who expect a statistically significant sample. Usability testing is diagnostic rather than statistical — you are finding problems, not measuring their prevalence.
Is accessibility testing part of this?
Yes, and for public-sector work it is mandatory rather than optional. We test with screen readers and keyboard navigation, and audit against WCAG 2.1 AA and GIGW 3.0 where the site serves citizens.
Talk it through before you commit
A discovery call is a working session on your constraint, not a sales pitch.
