Whether a UX audit or a usability test is the right starting point depends on the question you need to answer. An expert review can provide useful groundwork when your team wants to find and organise potential problems in an existing journey. If you need to understand how customers interpret and complete a choice, you need observations involving suitable participants. That distinction helps establish which investigation is useful before the next design.
You do not have to choose a single method for the whole project. A review often helps focus a later test on the important unresolved questions. This guide explains how to scope both investigations and compare proposals. A backpack size-selection example then shows how a potential issue becomes a finding your team can act on.
What evidence does your next decision need?
A UX audit examines an agreed part of a product against explicit criteria. These may concern understandable feedback, consistent selections or the handling of errors. NN/g describes heuristic evaluation as this type of expert assessment: it identifies potential usability problems and can prepare further investigation.
In a usability test, people from the target audience attempt a realistic task. You observe their journey and can ask about their understanding. NN/g’s introduction explains the roles of the task, participant and facilitator. Your choice of method depends on the kind of evidence currently missing.
| Your unresolved question | A useful starting point | Result you can act on |
|---|---|---|
| Which parts of this mobile purchase journey conflict with the agreed usability criteria? | A focused UX audit | Documented locations with reasons, proposals and open questions |
| Do customers understand which product size suits them? | A usability test involving a selection task | Observed decisions, information used and difficulties understanding it |
| Which work does support currently complete outside the application? | User interviews about actual work | Concrete workflows and requirements to inform a design |
| Which of two changes produces more completed actions under the measured conditions? | An appropriately planned A/B test | A comparison of the agreed measure with its statistical uncertainty |
If the work a product needs to support is still unclear, conversations about the current workflow often help more than testing the existing screen. If the application is already known to display an incorrect confirmation, that contradiction can be investigated directly. This lets you address the question that makes a further decision possible.
Define scope through the user journey
Suppose you run a hiking-equipment shop. A backpack comes in two back lengths, and your team suspects that choosing the right size on a phone is unnecessarily difficult. A brief to “audit the shop” covers far more than that question. A better first scope could run from opening the backpack’s product page through size selection to checking the cart.
That makes the subject of the investigation visible. Which product page is included, what information is needed to choose, and where does the journey end? Device and user group matter too. Someone buying a backpack without advice brings different knowledge from someone reordering a model they already know.
Describe the important states as well. Alongside the initial page, relevant states might include an unavailable size, an incomplete selection and editing a previously chosen variant. These often distinguish a well-presented screen from a dependable journey. Agree which states belong to the work before the review so that “complete” does not mean different things to different people later.
Turn a walkthrough into a traceable UX audit
The reviewer begins by becoming familiar with the agreed journey. The first pass establishes product terminology, available content and system states. Treating every unfamiliar element as a fault immediately risks overlooking a distinction the business actually needs.
The next pass records specific findings. Each refers to the reviewed version, a screen or a reproducible sequence. Its reasoning explains the difficulty expected; a recommendation describes how the design might address it. When an assumption matters to the assessment, it belongs beside the finding so your team can resolve it directly.
Related findings are then brought together and assessed in relation to the task. Five differently worded observations about the same unclear size selection are not automatically five independent problems. A combined finding can instead show that the same missing information affects both the product page and the cart.
Prioritisation benefits from considering task relevance, the expected consequence and the available evidence together. Something that blocks the agreed journey needs different treatment from a stylistic preference. The number of screenshots does not establish how many actual users are affected; that requires relevant usage data or further observation.
A complete finding about size selection
In the assumed backpack shop, the product page offers “S” and “M”. A size table explains the back lengths further down, but nothing at the selection points to it. The cart then displays only the chosen letter. A finding that the team can investigate could look like this:
| Part of the finding | Worked example |
|---|---|
| Location and state | Mobile backpack product page before selection, followed by the cart with size M selected |
| Observation | The size options do not explain back length. The size table appears after several other content sections. |
| Evidence | Screenshots of both states, marking the selection and the table’s location; record the URL, date and reviewed version alongside them. |
| Expected difficulty | Someone unfamiliar with their required back length must find the connection between the letter and the measurement. Checking that choice in the cart is difficult without returning to the product page. |
| Proposed change | Place a short explanation and access to size guidance beside the selection; include the chosen back length in the summary. |
| Open business question | Which measurements apply to this model, and who verifies the relationship between the size label and back length? |
| Question for a test | Can new customers make a reasoned size choice and explain in the cart which version they selected? |
The finding goes beyond “size guidance missing”. It identifies the decision affected and connects a proposal to the required product data. Your team can already establish whether the measurements are correct and how they are maintained. Whether the new explanation actually helps people choose then becomes a suitable test question.
Focus the usability test on what remains unknown
The backpack example needs participants who could realistically face that product choice. People from your own engineering team may already know the sizing logic and therefore have a different starting point. Our participant-recruitment guide helps you describe those requirements.
The task needs a realistic reason and the relevant information without telling someone to use the size guide. A participant could choose a backpack for a multi-day hike using a supplied back measurement. Nobody then has to improvise a body measurement during the session, and the observation stays focused on the information provided. Our usability-task template explains how to prepare such tasks.
In a moderated remote test, the task stays on the intended device: a mobile purchase journey is completed on a smartphone while the facilitator follows the shared view and asks follow-up questions. Before starting, check that selection and feedback are visible. If screen sharing is interrupted, record that technical interruption separately from a usability problem in the product.
During the task, the facilitator records which information the person uses, where they pause and how they explain their decision. If they only progress after a hint about the size guide, that assistance belongs in the observation. Otherwise, the result would later suggest that the journey supported them independently.
The report should therefore keep task, reviewed version and observation connected. “The participant chose M after comparing the back length in the table” differs from “The participant chose M after a hint from the facilitator”. Both can be useful observations, but they do not answer the same question about independent use.
Match tools and participant numbers to the research goal
An automated website check can flag technical issues but does not observe how a person understands size selection. Likewise, a usability audit of an online shop is not automatically a complete accessibility assessment. If accessibility is the research goal, the relevant requirements, devices and evaluation methods must be explicitly defined. The W3C planning guidance places early and repeated evaluation within web work. For your comparison, a tool name or general review badge cannot replace a traceable service description.
Participant numbers also follow the question. A limited qualitative investigation of one audience needs different planning from a statistical comparison of several groups. The NN/g introduction to usability testing distinguishes these goals. One universal number therefore cannot define scope or establish a guaranteed share of all problems found. Instead, clarify the background participants need and the tasks they will actually perform.
Cost planning includes preparation, recruitment and possible incentives alongside moderation and analysis. A low-cost offer without suitable participants may describe a different task from one with separately organised participation. For the usability test linked here, you provide suitable adult participants and appointments; recruitment and participant incentives are outside the package price. The current price and exact scope are shown with the offer, while technical implementation of findings is planned separately.
What to compare when commissioning the work
A quotation is not defined by whether its heading says “UX audit” or “usability testing”. Compare the task being investigated and the result you receive. An audit might specify the devices and states included, the format of findings and the agreed clarification of follow-up questions. Testing also involves suitable participants, preparation, facilitation and analysis; responsibility for recruitment should be explicit.
Agree what happens after the report as well. For the size guide, approved measurements must be available before a designer can develop the explanation and an engineer can implement its mapping in the shop. Naming the owners and this sequence while commissioning the work makes it easier to turn the finding into specific tasks afterwards.
“After the investigation, we want to decide whether the product’s size guidance needs to change” is therefore a useful starting point. It defines the decision without prescribing the solution. You can find the actual scope and current price in our usability-testing offer. If the underlying product question is still unclear, UX decision support provides a suitable starting point.
Connect observations to product decisions
At medienkundig, investigating first use informed a decision beyond a button label: exercises are available before registration, and signing in later enables progress to be saved. The project explains how the journey and its implementation work together.
Bridagency illustrates a planning flow with different entry points and interdependent choices. Projects like these show why investigations need to begin with a particular task. For your own journey, the next step is to describe what people need to achieve and what your team still needs to decide. That gives us a basis for defining the right investigation with our UX agency.
