TL;DR

Usability is how easily and reliably people can accomplish what they came to do. It is a measurable property — can users complete the task, how long does it take, how many errors do they make — which distinguishes it from user experience, a broader idea that includes how the whole encounter felt.

Key Takeaways

  • Usability asks whether people can complete their task; user experience asks how the whole encounter felt.
  • Because it is measurable, usability can be tested and improved rather than argued about.
  • Task completion, time taken and error rate are the practical measures.
  • Testing with real users reveals problems that no amount of internal review will find.
  • Heuristic evaluation offers a faster, cheaper first pass: reviewing an interface against 10 established usability principles.
  • Small friction points compound — each one is minor on its own, and together they are why people leave.

What Is Usability? Definition, Measurement and the 10 Heuristics

Usability is a measure of how easily and reliably people can accomplish what they cameto do. It is not a synonym for good looks, and it is not a matter of taste. It asks threeanswerable questions: can the user complete the task, how long does it take, and how manymistakes do they make along the way.

That answerability is what makes usability useful. Where design debates stall onopinion, usability can be tested and the argument settled with evidence.

The five components of usability

Nielsen Norman Group defines usability through five components, and this model is theworking industry standard:1

  • Learnability — how easily can a first-time user complete basic tasks?
  • Efficiency — once learned, how quickly can tasks be completed?
  • Memorability — after time away, how easily does competence return?
  • Errors — how many mistakes do users make, how severe are they, andhow easily can users recover?
  • Satisfaction — how pleasant is the design to use?

The international standard defines usability in compatible terms: the extent to which asystem can be used by specified users to achieve specified goals with effectiveness,efficiency and satisfaction in a specified context of use.4 Note how much work"specified" is doing in that sentence — usability is never absolute. A tool that is highlyusable for a trained operator can be unusable for a first-time visitor.

Usability and user experience are not the same thing

Usability is one part of user experience, and the most testable part. User experiencecovers everything about how it felt to encounter the product — including whether it solveda real problem, how the brand behaved, and what happened after the interaction ended.

The practical distinction: usability asks how — how do I complete this task?User experience asks what, why and how together. A checkout can be perfectlyusable and still be part of a poor experience, if the product was wrong, the deliverypromise was misleading or the returns process was hostile.

Why usability is an economic question

Treating usability as polish, to be applied if there is time left over, gets thecausality backwards.

  • Revenue. A checkout that is hard to complete produces abandonedcarts. This is the most direct link between usability and money, and it is whyconversion rate optimisation is largely ausability discipline in practice.
  • Retention. People do not return to products that made them feelincompetent. Friction is remembered even when its cause is not.
  • Cost of change. Fixing a problem in a design file is cheap. Fixingthe same problem after it is built is more expensive, and fixing it after release is moreexpensive again — because the cost now includes the users it already affected.
  • Credibility. A product that is easy to use reads as competent andtrustworthy. One that is not raises doubt about everything behind it.

How to run a usability test

Usability is measured with people, not with opinions in a meeting. A workable testtakes five steps:

  1. Set the objective. Name the task you are testing, precisely. "Testingwhether a new user can book an appointment in the mobile app" is testable; "testing theapp" is not.
  2. Recruit five to seven participants who resemble your users. JakobNielsen's finding is that a first study with five participants surfaces roughly 85% of aninterface's usability problems.2 The implication is not "test less" — it is thatseveral small studies beat one large one, because you can fix problems between rounds.
  3. Write scenarios, not instructions. Do not say "book an appointment".Say: "Imagine you need a dentist appointment for next Tuesday. Please try to arrangethat." An instruction tests obedience; a scenario tests whether the interface isfindable.
  4. Observe, and stay quiet. Do not help. Ask participants to thinkaloud so you hear what they expected, not just what they clicked.
  5. Prioritise by severity. A problem that stops task completion outranksone that merely irritates. Send findings to the team ranked, not as an undifferentiatedlist.

Heuristic evaluation: the 10 principles

Before testing with users, an expert review against established principles catches alarge share of problems quickly and cheaply. Nielsen's 10 usability heuristics are thestandard checklist:3

  1. Visibility of system status. Keep users informed about what ishappening. An order that moves visibly through "received → prepared → shipped" removes theneed to ask.
  2. Match between the system and the real world. Speak the user'slanguage rather than internal jargon. Banking apps that label a transfer the way customersdescribe it, not the way the ledger does, are applying this.
  3. User control and freedom. Give people an exit from a state theyentered by accident — the "Undo" that appears after deleting an email is the canonicalexample.
  4. Consistency and standards. The same action should look and behave thesame everywhere. A save button that is green on one screen and blue in a differentposition on the next forces relearning.
  5. Error prevention. Better than a good error message is a design thatmakes the error impossible. Showing password rules while the field is being typed preventsthe failure instead of reporting it.
  6. Recognition rather than recall. Do not make users rememberinformation across screens. Showing recent orders on the home screen turns a memory taskinto a recognition task.
  7. Flexibility and efficiency of use. Serve both the novice and theexpert. Keyboard shortcuts are invisible to a beginner and indispensable to a daily user.
  8. Aesthetic and minimalist design. Every extra element competes forattention with the ones that matter.
  9. Help users recognise, diagnose and recover from errors. "Error code5002-B" tells the user nothing. "The card number you entered is not valid — please checkand try again" tells them what happened and what to do.
  10. Help and documentation. Ideally unnecessary, but when needed it mustbe findable and task-focused.

Heuristic evaluation does not replace testing with real users. It removes the obviousproblems so that testing time is spent on the ones no expert would have predicted.

Frequently asked questions

How is usability different from accessibility?

Accessibility asks whether people with disabilities can use the product at all;usability asks how well anyone can use it. They overlap heavily — most accessibilityimprovements raise usability for everyone — but a product can be technically accessibleand still be difficult to use.

Is five users really enough?

Five is enough to find most problems in one round, not to prove a statistic.2 Ifyou need quantitative confidence — a completion rate you can report as a number — you needa larger sample. For finding and fixing problems, small and repeated beats large andone-off.

Can you test usability without a finished product?

Yes, and it is cheaper to. Paper sketches and clickable prototypes reveal navigationand labelling problems long before anything is built, which is exactly when those problemsare least expensive to fix.

What should we measure?

Start with task completion rate, time on task and error rate. These three map directlyonto the components above and are readable by people outside the design team, whichmatters when you need the fix prioritised.

Who should run the test?

Someone who did not design the thing being tested. Designers unconsciously guideparticipants past the exact friction the test exists to find. If that is unavoidable, atminimum write the scenarios in advance and read them verbatim.