Usability Risk

Concept

The risk that people want what you built but can't work out how to use it, so the feature goes unused.

Why it exists

Teams used to treat "nobody uses it" as a single condition. Four different causes hid inside that one report, and with no words to separate them, meetings split at the same point every time.

A permission-settings feature that took three months to build and came back with 3 percent usage is the classic case. One side argued the feature was never needed. The other argued it was needed and simply couldn't be found. The two diagnoses call for opposite treatments: the first means deleting the feature, the second means fixing the screen. Pick the wrong one without evidence and another three months go the same way. So the causes were split into four named branches, and the second of them is usability risk.

How it works

You can't find this risk by asking. You find it by handing someone the task. Three steps.

  1. Give the task as one sentence. Say "open just this one document to an outside contractor" and then say nothing else. Add a single hint about where to click and the measurement is over.
  2. Watch and time it. Handing someone a real task and watching where they stall is a usability test. If three out of five can't finish inside three minutes, treat the risk as present.
  3. Write down where they stopped. Failing to find the menu and finding it but backing out because the label made no sense point to different fixes.

Value risk asks a different question. When people say yes to needing it and still can't do it, that's usability risk; when they say they don't need it, the problem sits on the value side. Incoming support messages split the same way. "Where is this?" is usability. "Why isn't this here?" is value.

The time to check is before building, not after. The same task can be run against a prototype that is only drawn screens, and with no code behind it a fix takes an afternoon.

How it sounds at work

"Usage is 3 percent. First we have to decide whether this is a value problem or a usability problem."

Deleting and fixing are different decisions, so isolate the cause first.

"Three of five couldn't find it inside three minutes. Let's redraw before we build."

The measurement crossed the threshold, so the screen goes back to the drawing stage.

"Every ticket asks where it is. The feature exists and nobody can find it."

Classifying the cause as usability from the shape of the support messages.

Before Pagedeck built its permission settings, Noa drew the screens and gave five people the same task. Three went past three minutes, and all three stopped in the same place: the item they expected inside the document menu was over in account settings. Mia decided to move it, and Theo started work only after the structure changed.

Where to go next

  • Four big risks

    see all four branches side by side and this one's place becomes clear

  • Value risk

    the neighbor this one gets confused with most often

Last updated 2026-09-16