User Testing

Analytics can show where users go and where they drop out, but they do not always explain what happened.

User testing provides that context.

We give participants realistic tasks and observe how they move through the experience, what they expect to happen and where they hesitate or become confused. The focus is on behaviour rather than asking people whether they like a particular design.

Testing can be used to explore:

• navigation and information architecture
• key website journeys
• forms and application processes
• search and filtering
• product or service selection
• content and terminology
• account and portal experiences
• eCommerce journeys
• prototypes and new features
• mobile experiences

Watching people complete these tasks often exposes issues that are difficult to identify through internal review alone.

A label that appears obvious to the project team may mean something different to a customer. Important information may be technically available but difficult to find. A process may contain a small point of friction that causes people to abandon it altogether.

These details can have a significant effect on whether an experience works as intended.

User testing works best when it is designed around specific questions.

Before each round of testing, we establish what the team needs to learn and which parts of the experience need the most attention. This keeps sessions focused and ensures the findings can be used to make practical decisions.

For an existing website, the priority may be understanding why customers struggle with a particular journey.

During a redesign, testing may focus on proposed navigation, content structure or wireframes before more time is invested in visual design and development.

For an application or portal, the emphasis may be on whether users understand the workflow, can complete key tasks and know what to do next.

Testing can also help resolve internal debate. Where teams have different views about how customers will respond to an experience, putting the work in front of users can provide evidence to guide the decision.

A testing session can generate a large number of observations. Some will be minor, while others point to problems that affect many users or prevent an important task from being completed.

We review the sessions to identify recurring patterns and distinguish isolated comments from issues that warrant action.

Findings may cover:

• navigation problems
• unclear terminology
• content gaps
• confusing interactions
• unexpected user behaviour
• accessibility barriers
• unnecessary steps
• unclear calls to action
• trust concerns
• points of hesitation or abandonment

We then consider the severity of each issue, how frequently it occurred and the effect it has on the user or the organisation.

This helps teams focus on the changes that are likely to make the greatest difference rather than responding equally to every observation.

User testing does not need to wait until a finished product is available.

Testing earlier in the project can make changes easier and less expensive. Information architecture, wireframes and interactive prototypes can all be tested before development begins.

Later rounds can then focus on the working product and more detailed aspects of the experience.

For larger projects, testing at several points can be useful:

• early research to understand existing problems
• testing proposed information architecture or navigation
• validating wireframes or prototypes
• reviewing the developed experience before launch
• testing improvements after launch

The level of testing should reflect the size and risk of the project. A focused round with a small number of participants may be enough to identify major usability issues, while complex platforms or services may require several rounds across different audience groups.

The findings can then feed directly into UX, content, design and development decisions, giving the project team clearer evidence about where changes are needed before the next stage of work.