Website usability: find friction in the paths visitors use

Website usability describes how well a particular visitor can find the information they need, understand it, and complete a task on your site. Your page may look polished, but that doesn’t help someone who can’t work out where to go next. To review usability, follow the task far enough to see what gets in their way.

Start where the visitor arrives and keep going until the task is complete. When you find an obstacle, note it, choose a fix, and try the task again to see whether the change helped.

What website usability means

Your returning customers bring knowledge that a new visitor doesn’t have. A page might make perfect sense to someone who already uses the product, while a prospective buyer is still trying to work out whether it does what they need.

Nielsen Norman Group defines usability through qualities including learnability, efficiency, memorability, errors, and satisfaction. These qualities give you a way to approach the review once you’ve described the visitor and what they need to do. Their device and familiarity with the product may affect what you observe. The qualities themselves don’t add up to a website score.

Usability and utility answer different questions. Utility asks whether your site provides what the visitor needs; usability asks whether they can work with it. If a pricing page leaves out important conditions, clearer buttons won’t fill in the gaps. And if the information is there but difficult to find or use, you still have a problem to work through.

Keep the visitor’s goal in mind before you start simplifying. A shorter page may leave out the detail a buyer needs to choose a plan. A longer form may be perfectly reasonable if each field has a clear purpose and people can recover from errors. Fewer elements aren’t automatically the answer.

Start with the task your site must support

What does someone need to find before they can take the next step? Start there. It gives you something more specific to investigate than “Is our website easy to use?”

Define the task before reviewing the interface:

1. Audience: Who is attempting it? Use a realistic group, not “all users.”
2. Goal: What are they trying to understand, decide, find, or submit?
3. Starting point: Are they arriving from search, a campaign, a shared link, the homepage, or another page?
4. Completion: What observable state shows that the task is complete?
5. Context: Which device, viewport, input method, or prior knowledge matters?

Take a fictional B2B example: your visitor needs to confirm an accounting integration, find the relevant security information, and reach the contact option. Now you have a route to follow and a clear place to stop.

Choose another task if your audience needs something different, such as comparing plans. Review each path separately.

Where website usability friction appears

Once you’ve chosen the task, follow the links and try the actions they lead to. This is where you start finding the awkward parts of the route.

Findability, navigation, and current location

Your navigation needs to make sense from wherever someone arrives. A visitor coming from search may never have seen the context on your homepage. Check whether the labels and links on their entry page give them enough to continue.

Trace the route from the actual starting point and inspect:

• whether the expected destination is exposed at the right moment;
• whether link and menu labels match the language used in the page heading and content;
• whether the destination confirms that the visitor reached the right place;
• whether the next step is distinct from adjacent actions;
• whether returning to an earlier decision point preserves context.

Work out the problem before picking a component to fix it. A breadcrumb may clarify one structure and add noise to another. And a clearer label can only do so much if the destination still combines unrelated jobs.

Readability and content clarity

Finding the page is only part of the task. Its content needs to answer the question that brought someone there. Read it with that question in mind, in the order a visitor encounters it:

• Does the heading describe the subject of the page rather than a slogan?
• Do section headings help someone locate a specific answer?
• Are product, navigation, and form terms consistent?
• Is required evidence attached to the claim it supports?
• Are material limits visible before the visitor commits to the next step?
• Do links describe their destination?

Give readers enough context to decide whether a link is worth following. “Learn more” is a bit unhelpful when they can’t tell what they’ll learn or where they’ll end up.

Forms and high-friction actions

If the next step is a form, go all the way through to submission. Then try making an error and recovering from it. The successful path is only part of what you need to check.

W3C WAI’s form-label guidance says controls need identifying labels and explains label-and-control association. It also notes that appropriate HTML input types can support mobile entry. Use the guidance to check each field; it gives no universal number of fields for a form.

For each field, check:

• whether the label remains available while someone enters or reviews a value;
• whether required formats or conditions are stated before submission;
• whether the input type suits the expected data and device;
• whether keyboard and touch interaction work for the task;
• whether an error preserves valid information already entered;
• whether the success state explains what happened and what comes next.

When an input error is detected, W3C’s explanation of Error Identification says the affected item should be identified and the error described in text. Color or an icon may supplement that description; it should not be the only signal. Checking this requirement covers only part of an accessibility review.

Mobile and responsive task paths

Now try the same task on a phone. An overlay or the on-screen keyboard may get in the way of an action that was straightforward on your laptop.

Repeat the same task in a relevant narrow viewport. Do not run a separate “mobile check” with a different goal. Inspect:

• content and action order;
• navigation disclosure and current-location cues;
• tap targets and controls near viewport edges;
• overlays, sticky elements, and on-screen keyboards;
• form input, validation, and recovery;
• whether the visitor can move between related pages without losing the thread.

Don’t stop at checking how the layout looks. Open the menus, enter form data, and try recovering from an error.

Where accessibility and usability meet

Some conditions create both usability friction and accessibility barriers. Examples include an unlabeled control, missing keyboard focus, a color-only error signal, or an overlay that blocks the next action.

Record these barriers when you find them. A usability review does not establish accessibility conformance or legal compliance; those need a separate assessment, including specialist evaluation with assistive technologies.

Run a useful website-usability review

Choose your evidence according to what you need to learn. Your team can walk through a route to spot possible problems, and an expert can use a heuristic review to assess the interface against usability principles. Neither tells you how an actual participant will behave. Analytics can show where people leave, giving you somewhere to investigate; search and support data can suggest questions worth testing. Session recordings give you another source of observations to examine. A usability test involves observing realistic participants as they attempt a defined task.

Use that distinction when planning the review below.

1. Define the review question

Write one sentence that names the audience, task, starting point, and completion state. Keep the scope small enough that the team can trace the full path.

Weak: “Find usability issues on the website.”

Specific example: “Can a first-time visitor find the requirements for this product and reach the contact form?”

2. Choose evidence that fits the question

Keep the source of each finding in your notes. A stakeholder may be convinced that a link will confuse people; for now, that’s an assumption you can investigate. If analytics shows exits, find out what visitors were trying to do before deciding why they left. One observed problem can still deserve attention. It just doesn’t tell you how many people encounter it.

If the question needs a usability test, use realistic participants and tasks. NN/g’s usability-testing overview describes a facilitator asking a participant to perform tasks while observing behavior and listening for feedback. Choose the number and design of sessions for the question you are investigating.

3. Start where the visitor starts

Open the search result, campaign page, shared URL, or product page that represents the real entry. Record backtracking, repeated clicks, abandoned fields, and terminology changes.

4. Observe without revealing the route

Give participants a goal they can attempt without telling them which control to use. “Find the status of your request” lets you see how they find their way. “Click Account in the header and open Requests” does the navigating for them.

Digital.gov’s usability-test model uses goal-aligned scenarios, think-aloud prompts, and non-leading questions. Adapt the prompts to your own question, and let the participant attempt the task before explaining the interface.

5. Record the obstacle, not a verdict

Fictional examples of observation notes:

• “The participant opened Pricing, returned to Product, then asked where plan limits were listed.”
• “The error summary said the form was incomplete but did not identify the affected field.”
• “On a narrow viewport, the next action was covered by the open chat panel.”

Avoid labels such as “confusing,” “bad UX,” or “not intuitive” unless the note also records the behavior or condition behind them.

6. Change the path and check it again

Tie each change to an obstacle, then repeat the task from the same context. Start the retest at the original entry point so you can see whether the visitor can now finish.

Website-usability task-path worksheet

The worksheet brings the fictional integration example together. Replace it with your own observations when you run a review.

Keep the worksheet somewhere you can return to after making changes. You want to see the evidence behind each decision and what still needs checking. There’s no need to turn it into a pass/fail score for the whole site.

Decide what to fix first

Once you have a few findings, you’ll need to decide which one gets attention first. Look at how each obstacle affects the task and how much evidence you have for it:

1. Does it block the task? Give attention to conditions that prevent completion, cause data loss, hide required information, or leave the visitor without a viable next step.
2. How important is the task? A local inconvenience on a rarely used path may matter less than a smaller obstacle in a core decision or submission path.
3. How strong is the evidence? Separate a team assumption, one observation, a repeated pattern, and a measured behavior. Do not make them sound equivalent.
4. What does the change depend on? The owner may be content, information architecture, design, a component, CMS behavior, analytics, development, or accessibility review.
5. What will be checked next? Define the smallest repeatable task that can show whether the path changed as intended.

Teams can use blocker, high friction, and local friction as shorthand if the evidence and task impact remain visible. These are not industry-standard grades.

Changing a button’s color won’t explain why the form needs certain information. Before making a fix, check that it addresses the obstacle you actually found.

When a design review needs broader support

Sometimes a clearer label is enough. If the route breaks across several pages or on different devices, you’ll need to look at those parts together. Our Website Design services cover broader website work, with the scope agreed around what needs attention.