Usability heuristics

In one line: usability heuristics are a small set of interface common-sense rules — does the screen show its status, let you back out, stay consistent, and help you recover — that you can hold up against any design and spot what's broken in minutes.

What it is

A heuristic is a rule of thumb: not a law, but a question worth asking every time. Usability heuristics are a compact list of those questions, distilled from decades of watching people stumble through interfaces. They cover the recurring ways screens fail — hiding what's happening, trapping you in a flow, surprising you with inconsistency, scolding you with errors you can't act on.

Running a screen against the list is called a heuristic evaluation. You walk the interface as a user would, and at each step you ask: can I see the system's status here? Can I undo or back out? Does this match how the rest of the app behaves? When something is off, you name the heuristic it breaks. That name turns a vague "this feels clunky" into a specific, fixable defect.

Why it matters

Most usability problems are not exotic — they're the same handful of mistakes, made again and again. A checklist catches them cheaply, before you spend money watching real users hit the same wall. One or two evaluators with a good list will surface a large share of the issues in an afternoon, no lab required.

The value is shared language. "The Continue button is confusing" invites an argument about taste. "There's no visible system status on the payment step, and no way back except the browser button" points at two named heuristics, and the fixes write themselves. Heuristics turn opinion into a punch list — which is also their limit: they tell you a rule is broken, not whether real people actually trip on it. They're where evaluation starts, not where it ends.

See it

How it works

The demo shows one checkout step twice. Toggle Respect the heuristics and watch the same screen go from quietly broken to quietly correct. Four rules do most of the work:

1. Visibility of status. The broken version never tells you where you are or what you'll pay — the total is "shown on the final step." The fixed version adds a step indicator (this is step 3 of 4) and a running total. The principle: keep people informed about what the system is doing, in reasonable time, so nothing is a surprise.
2. User control and freedom. The broken version offers no in-page Back; your only escape is the browser button, which may abandon the whole order. The fixed version adds a real Back control. People choose wrong functions by mistake — give them a clearly marked, low-cost way out.
3. Error recovery. The broken field says only "Invalid input." The fixed field says exactly what's wrong, in plain language, tied to the field: the number is short, a Visa card has 16 digits, you entered 6. Good error messages name the problem and suggest the fix.
4. Match to the real world. Phrasing like "a Visa card has 16 digits" speaks the user's language instead of system jargon. Words and concepts should be the ones people already carry in their heads.

The annotation pills under the screen name each heuristic so the mapping from fix to rule stays explicit — that naming is the whole skill.

Build it

The single most common heuristic failure is a vague, disconnected error. Here's the opposite: a specific inline error, programmatically tied to its field so a screen reader announces it when focus lands. The same markup carries a step indicator with aria-current for visibility of status.

<!-- aria-current marks the active step for assistive tech (Visibility of status). -->
<nav aria-label="Checkout progress" class="steps">
  <ol>
    <li>Cart</li>
    <li>Address</li>
    <li aria-current="step"><strong>Payment</strong></li>
    <li>Review</li>
  </ol>
</nav>
 
<div class="field">
  <label for="card">Card number</label>
  <!--
    aria-invalid flags the error state; aria-describedby ties the message to the
    field so it's announced on focus (Error recovery). The message is specific.
  -->
  <input
    id="card"
    type="text"
    inputmode="numeric"
    value="4001 22"
    aria-invalid="true"
    aria-describedby="card-error"
  />
  <p id="card-error" role="alert" class="field__error">
    <span aria-hidden="true">⚠</span>
    Card number looks short — a Visa card has 16 digits. You've entered 6.
  </p>
</div>

.steps ol {
  display: flex;
  gap: 0.75rem;
  list-style: none;
  padding: 0;
  margin: 0 0 1rem;
  font-size: 0.85rem;
  color: #5b606b;
}
.steps [aria-current="step"] {
  color: #1b1d22; /* meaning is in the text weight + aria-current, not colour alone */
}
 
.field {
  display: grid;
  gap: 0.4rem;
  max-width: 22rem;
}
.field label {
  font-weight: 600;
}
.field input {
  padding: 0.55rem 0.7rem;
  border: 1px solid #c9ccd4;
  border-radius: 0.5rem;
  font: inherit;
}
.field input:focus-visible {
  outline: 2px solid #5b6cff;
  outline-offset: 2px;
}
/* Invalid state reads through the border AND the message text, never colour only. */
.field input[aria-invalid="true"] {
  border-color: #b4540a;
}
.field__error {
  display: flex;
  gap: 0.4rem;
  margin: 0;
  font-size: 0.85rem;
  color: #b4540a;
  /* a gentle nudge to draw the eye when the error appears */
  animation: error-in 160ms ease-out;
}
@keyframes error-in {
  from { opacity: 0; transform: translateY(-2px); }
  to   { opacity: 1; transform: none; }
}
/* Status must not depend on motion: drop the animation, keep the message. */
@media (prefers-reduced-motion: reduce) {
  .field__error { animation: none; }
}

Make it yours

Reproduce it with an LLM

Pitfalls & accessibility

Related

Further reading

• A canonical set of usability heuristics for interface design, in your own words — keep your team's copy phrased the way you actually talk.
• A short guide to writing error messages that name the problem and the fix, rather than just flagging that something went wrong.