Usability Is a Promise

Usability is usually discussed as a property of a design: how clean it looks, how intuitive the layout feels, how consistent the components are. That conversation is worth having, but it misses the more useful definition. A site is usable when it keeps the promises it makes.

The three promises

Every single visit carries three implicit promises, made by the site without ever stating them:

I will understand what this is. Within a few seconds, a visitor should be able to say what the organisation does and who it is for.
I will find what I came for. The page or answer they needed should be reachable without knowing how the site is organised internally.
I will know what to do next. At the end of the page, the next step should be obvious and matched to why they arrived.

Break any one of them and the rest of the experience stops mattering. A beautiful site that fails the first promise reads as expensive but irrelevant. A clear site that fails the second feels like a dead end. A site that fails the third collects contact details nobody wanted to give.

How to test them

The stranger test

Give someone who has never seen the site a task, such as finding your pricing or booking a consultation, and watch without helping. Do not explain the navigation. Where they hesitate, you have found a broken promise: either the vocabulary does not match what a visitor would use, or the structure requires knowledge the visitor does not have.

The five-second test

Show the first screen for five seconds, then cover it and ask what the site does. If the answer is vague, the headline and the first paragraph are doing too much work at once. The best first screen states what this is, who it is for, and what to do, in that order.

The next-step test

For every important page, ask what a visitor would do next, and check that the page offers it. A pricing page with no prices, a services page with no contact route, an article with no related reading: each one ends a visit that was otherwise going well.

What breaks them quietly

A few patterns cause most of the trouble I find:

Navigation that describes the organisation. Menus built from internal team names and reporting lines. Visitors do not know your departments; they know their own problem.
Asking before giving. A form that asks for six fields before explaining anything is a request for effort without evidence. Explain the value first, ask for less, and let them supply details later.
Hiding the important part. The cost, the lead time, the eligibility, or the actual answer, all buried in a paragraph or a linked PDF. If it is the reason someone is reading, it belongs in the open.
Designing the empty and error states last. They are the states people actually see most often, and the ones most often left unconsidered.
Making people wait. A slow first page is a broken promise in its simplest form. The visitor came for an answer, and the site is making them stand around for it.
Writing for colleagues, not visitors. Jargon that is accurate internally and opaque outside it. If a term matters, define it the first time it appears.

A short checklist

Before calling a page done, it should be possible to answer yes to all of these:

Can a stranger say what this is and who it is for, after five seconds?
Is there one clear action, and does it match the visitor’s intent?
Do the words use the visitor’s language rather than the organisation’s?
Are the facts people came for visible without clicking anything?
Do the empty, loading, and error states look designed?
Does it work with a keyboard, on a phone, and on a slow connection?
Is there a next page worth going to, and does the page say so?

Usability is not a coat of paint applied at the end. It is the sum of those promises being kept, page by page, which is why it is cheaper to design for from the start than to retrofit afterwards.