Analysis
User testing · usability testing
Can five test participants use your product? We observe them completing up to three tasks and record where they need help.
UX & research
What happens on the first attempt?
You know every button in your product. A new person does not. We observe how they complete a task or discuss their current workflow. The open product question determines the research you need.
Browse services in the shop View a work sampleWhat decision needs to follow the research?
Whether you want to test a flow, understand needs or compare variants determines the method. A specific decision question defines the audience, tasks and scope. The report connects observations with their meaning for the product and identifies unresolved questions.
Observe a journey
A participant receives a task and attempts it using the existing product or prototype. We observe steps, questions and places where they cannot continue.
Understand the context of use
Interviews can establish how people currently complete a task and which conditions matter. Reported wishes are distinguished from observed behaviour.
Fictional working example
An appointment can be booked. Can it be changed?
A fictional prototype offers simple appointment booking. The team does not yet know whether people can change an existing booking independently.
The change
The test starts with an existing booking and a preferred new time. We observe where the participant looks for the change and whether they understand the final confirmation.
How we check
The findings identify specific locations and feedback. After revision, the same type of task is tested again without explaining the successful route first.
Observe how a task is completed.
Usability testing focuses on what a person does with a specific task. Can they find a suitable variant? Understand the feedback after saving? Continue after an error? These tasks produce different insights from asking whether someone likes an interface. We derive tasks from the decision your team needs to make and choose a suitable version of the product.
A clickable design may be enough to ask whether navigation is understood. Testing reactions to load times or server errors requires those states in an application. The test material must make the question tangible. We separate observation from explanation: a missed button is a finding; its cause still needs interpretation.
User interviews · UX researchSuitable services
All services on this topic Where should you start?
Test a usable product
User testing fits when a flow already exists and you want to observe whether people can complete the intended task.
Research the starting point
User interviews help answer questions about everyday work and current practices. We agree the audience and interview question before conducting them.
Analysis
User interviews · UX research
We speak to five people from an agreed audience about one research question. You receive a thematic analysis of their comments and open questions.
Interviews answer different questions.
An interview helps understand how people work today, the exceptions they encounter and the tools they use. It can reveal the current appointment-planning process, for example. It cannot by itself show whether a new interface is usable. That requires a task using the specific design or product. The method follows the open question.
Participant selection affects which conclusions are useful. Experienced daily users handle a tool differently from first-time users. We agree relevant characteristics and recruitment before research. A few conversations describe observed cases; they are not automatically representative of an entire market.
Read the guideHow we work
Work through a research question.
Define the decision
What would you decide differently after the research? A specific question defines the method, scope and participants required.
Check the material
For a test, the prototype must support the task. For interviews, we gather the situations and existing practices we want to discuss.
Prepare the process
We formulate tasks and interview questions. Participant selection and contact are agreed within the scope.
Record observations
We document where tasks succeed and where difficulties arise. Statements are recorded with their context.
Interpret the findings
Your team sees which changes follow from the observations. Questions the research could not answer remain explicitly open.
A pending decision
Describe what the team might decide differently after the research. Two variants, an unclear flow or a new feature give the work direction. A general satisfaction question is often too broad.
Product and test material
An accessible prototype, existing website or described process helps planning. Identify known gaps so tasks do not accidentally end at a part that has not been designed yet.
Suitable participants
Consider who actually performs the task and whether those people are reachable. Recruitment, participation conditions and recording arrangements are agreed beforehand. Customer names are not needed for the first enquiry.
Do I need a finished product?
A sufficiently usable prototype can be enough for a usability test. Interviews can start earlier. What matters is the question and what the available material allows us to investigate.
Who participates in a test?
Participants must fit the agreed user group and task. Recruitment, numbers, compensation and available contacts are settled within the service scope.
Does a user test prove a higher conversion rate?
It first shows how participants complete tasks and where difficulties occur. Conclusions about order or enquiry rates need suitable quantitative research.
Test a design or first understand everyday work?
If you want to know whether someone can use a design, choose usability testing. If you want to learn how a task is currently completed and which exceptions arise, choose interviews. A finished interface is not required for those.
Research is particularly useful when its answer changes an upcoming decision. If the task is already clear, such as making a truncated error message readable, your team can correct it and check that case directly. Not every change needs a separate study.
Further reading