Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


This page provides information to help you prepare and perform a UX Walkthrough as described on the UX Walkthrough Protocols and Checklists page.

Choose and Understand your User(s)

To perform a UX Walkthrough effectively, it is best to have a user (or users) of the system in mind along with the real-world tasks they would be performing. Though this is more often part of the cognitive walkthrough approach, we have also found it to be effective when performing a heuristic evaluation. The user may be represented by a persona, or based on a tacit knowledge about a particular user type.

A UX Walkthrough is performed through a step-by-step exploration of a page to see how well a particular type of user will be able to accomplish his or her objectives, while also keeping heuristics in mind.

1. Choose a user:

  • who can help the evaluator keep in mind:
    • the knowledge,
    • the particular needs,
    • the preferences, and
    • the limitations
      ...the user may plausibly be expected to have

You will perform the UX walkthrough from the perspective of this user. If you have created personas for your project, you can select your user or users from this persona set. See Persona Creation for guidance on creating them.

If you have not created personas, but have enough knowledge about users of your system to understand the items above and create tasks for each of them, you can perform the UX walkthrough with these individual user(s) in mind. In this case, it may be helpful to create a provisional persona which captures your knowledge and helps to make the user more 'real,' but is not based on real user research.

Your choice of user(s) should be documented in your evaluation.

2. Specify an explicit user goal

  • A user goal - the specific result desired by the user which motivates the interaction

After you have selected a user, consider what that user will want to accomplish on the system you are evaluating. This goal should be as concrete and explicit as possible, making it easier to evaluate the effectiveness of your system.

Note that separate UX Walkthroughs may be needed for each user since users may attempt to accomplish a goal differently. Some issues will likely show up in more than one walkthrough, which may result in later walkthroughs going more quickly than earlier ones.

User Goal Examples

Here are some examples of specific user goals.

"The user should be able to register for a new account and create new content on the site within 10 minutes."

This first example is a goal that concretely states the success criteria and is focused in scope.

"The user would like to finish editing a document that is work in progress. They should locate their unfinished document, add the missing photos, and announce the availability of the finished document using the website's email system."

This second example is broader and more exploratory, where success can be more difficult to measure. A broad user goal can be useful in identifying areas in which to do further examinations.


1. Preparation

Obtain access to working software or a prototype of the system you intend to inspect.

  • For the cognitive walkthrough portion of the examination, choose one or more representative tasks to inspect related to the chosen user goal.
  • If you are also doing an accessibility inspection, obtain an appropriate tool to use in evaluating the user experience like screen readers, and specialized input or output devices.
    • Example: JAWS is a widely used screen reader - a free time-limited demo is available.
    • Example: Fangs is a Mozilla Firefox extension that displays a text representation of a web page in a manner intended to be similar to how a screen reader would read it.

2. Process

Choose your approach:

Plan to inspect the system from at least four viewpoints, including:

  1. typical users (you may have more than one of these)
  2. screenreader users
  3. keyboard-only users
  4. users who have difficulty processing text (e.g. users with a cognitive disability)

Note that these four viewpoints don't cover all possibilities. For example, you may also want to inspect for low vision users who are not screenreader users or consider other cognitive disabilities not captured by difficulty with text.

You can decide how you want to organize these inspections, for example by doing the entire UX walkthrough for one user type at a time, or by examining a portion of the system from each point of view before moving on to another portion.

Plan both the Heuristic Evaluation and the Cognitive Walkthrough

There are also different ways to organize the heuristic evaluation and cognitive walkthrough aspects of the inspection. The Fluid approach combines some of the preparation for the cognitive walkthrough with part of the heuristic evaluation.

The cognitive walkthrough method requires that the analyst know the right way to perform the task to be tested before doing the walkthrough for that task.

So, as the first part of your inspection, examine the interface with the dual aim of checking the points listed in the Heuristic Evaluation and working out a good approach to your task or tasks. (You can decide whether you want to pick one of your tasks and complete all work on that before beginning another, or do the preparation for all tasks before doing the walkthroughs on them.)

Make notes of any issues you encounter in figuring out how to do the tasks, as well as any other problems you identify in this phase using the heuristics.

Perform the UX Walkthrough

Once you have worked out how to perform one or more tasks for which you will do a UX walkthrough, do the walkthrough. This means working through an appropriate method for the task, step by step, checking the points in the Heuristic Evaluation.

Keep in mind that the walkthrough is not a user test with you as the user. That's why you start the UX walkthrough already knowing a good way to perform the task. At each step, you are checking whether someone else, without benefit of your prior knowledge, will be able to figure out what to do, do it, and respond appropriately to the result of the step.

If inspecting a system for accessibility, you will need to consider the walkthrough points for all of these users. For example, an interface may provide adequate cues for some step for a sighted user, but the cues may simply not be available to screen reader users, or may be hard to interpret and process for users for whom text processing is difficult. Similarly, required actions may be easy for mouse users, but difficult or impossible for people who are using another input method.

Once you have completed all of the walkthroughs you plan to do, keep in mind that the heuristic evaluation portion of the UX walkthrough includes surveying, as well as you can, all aspects of the interface, not just those that figure in particular tasks. Do what you can to explore the interface broadly, recording any issues triggered by the Heuristic Evaluation.

3. Recording Results

While doing a UX Walkthrough, the reviewer should record all the usability/accessibility issues that are uncovered, (e.g. which heuristic checklist items are violated as well as which tasks are problematic in the cognitive walkthrough), and describe where in the system each problem occurs. A common template for recording results has been provided. See the UX Walkthrough Report Template.

titleRelated LinksborderStylesolid