Usability

Noticing that a product wasn't being used was never the hard part. Naming why was. What came out in meetings was some version of "the screen is awkward" or "it's hard to use," and neither sentence tells anyone what to change. Whether the feature was missing, present but unfindable, or found and then abandoned after two wrong clicks all collapsed into the same phrase.

So the argument usually ended at the intuition of whoever built the thing. "It works fine for me" carried the room, and that statement is generally true. The person who built the screen already knows which menu holds what, so there is nothing left for them to get lost in. Only new people get lost, and new people aren't in the meeting. That's how a support queue fills with requests for a feature that already shipped while engineering keeps confirming that it is right there. Neither side is saying anything false. They are describing two different screens: the one the builder navigates from memory, and the one a stranger reads for the first time with no idea what lives behind each label.

Those tickets rarely changed a screen. The usual response was one more help article, because changing a screen requires naming what's wrong with it and nobody had the words, while nobody ever objects to writing documentation. The articles pile up unread, and the fact that they're unread takes months to surface. By then the help center has three pages describing a screen that could have been fixed once.

Usability is the name for pulling this judgment away from intuition. Instead of asking for opinions, you hand people a real task and count three things: how many reached the end, how many seconds it took, and how many wrong turns happened along the way. If you ask five people to share a document and three of them sit frozen for more than twenty seconds, that isn't taste, it's a record. User experience splits the whole experience into five axes, and this one sits second. First you ask whether the product does something people need; then you ask how many times they get blocked on the way to it.

The terms under usability fall into two groups. Four sub-attributes break the axis down further and decide what gets measured. One evaluation method lets a team sweep all four before bringing any users in. The four are the thing being measured; the method is the filter you run first.

The four sub-attributes differ in when the user meets the product. The same screen scores differently depending on which moment you look at.

1. Learnability — how quickly a first-time user picks it up. Only the first half hour after signup counts, since after that the person has learned the product and can no longer tell you whether it was learnable. Hand five new people a task with no guidance — make a document and share it with a coworker — and count how many finish unassisted. A product that loses points here signs plenty of people up and loses half of them on day one. The fix is usually narrowing the first screen to a single job rather than removing features, because someone who sees twelve options spends all their time deciding which one to press first.
2. Efficiency — how fast an experienced user gets through the work. The reference person does the same thing ten times a day, so the unit of measurement drops to seconds and clicks. Duplicating a document and renaming it at six clicks is sixty clicks a day for that person. This axis fights with the one above it. A wizard that walks a beginner through each step becomes twelve unskippable clicks for someone who has done it a hundred times. Most products settle this by deciding which side wins and then opening a separate lane — keyboard shortcuts, bulk actions — that only experienced users find. The lane works because it stays out of the way: a beginner who never discovers it loses nothing, while the person doing the task sixty times a day saves most of those clicks.
3. Memorability — how much someone has to relearn after being away. Daily screens never expose this. Monthly ones do: billing reconciliation, quarterly reporting, anything opened once every few weeks. If a user can't recall where they clicked last time, they are functionally a first-time user again. Traces left on the screen — recently used items, last settings retained — hold this axis up, because they let a returning user recognize the path instead of recalling it, and recognition survives a month away where recall does not. Naming screens with internal team vocabulary collapses it fastest, because someone who heard that word once a month ago won't recognize it now.
4. Error prevention — designing so the mistake is hard to make in the first place. That ranks above explaining the mistake well after it happens. Buttons stay disabled when their conditions aren't met, delete lives at the bottom of the menu, and confirmation is reserved for things that can't be undone. Attach a confirmation dialog everywhere and people learn to click through without reading, so the one that actually matters gets dismissed too. Prevention and recovery substitute for each other, so wherever undo genuinely works, dropping the confirmation is the better trade.

The evaluation group is what you use before recruiting anyone. Nielsen's heuristics are ten principles for reviewing a screen — does the interface say what is currently happening, is it written in the user's words, is there a visible way out. Three or four reviewers walk the screens separately, write down violations, and merge their lists. It needs no participants, finishes in a day, and costs almost nothing. Reviewers work separately on purpose, since any one person catches only a fraction of the violations and the overlap between three lists is small. What it can't show you is what real users actually do, so it runs as a filter ahead of testing rather than instead of it. Running it afterward wastes the session, since participants spend their time tripping over problems a reviewer would have caught for free.

The two groups interlock. The four axes decide what to measure, and the ten principles clear the obvious violations before anyone spends a day recruiting. What remains is choosing which axis this product favors, because no team maximizes all four at once. Something opened once a day leans on the first two; a tool that stays open all day leans toward efficiency; anything handling money or irreversible actions puts error prevention ahead of both, accepting that every such flow will feel slower than it could be. Teams that chose and teams that drifted end up with visibly different screens a few months later — the drifting ones stack beginner guidance and expert shortcuts in the same space, so new users can't tell where the guidance ends and daily users dismiss a panel every single time.

"This reads like a usefulness problem, not a usability one. Nobody asked for this feature."

Fixing the screen won't help, so decide whether to build it at all.

"Three of five couldn't find the share button and stalled for over twenty seconds."

That's a count from watching people attempt a task, not an opinion.

"If we add undo here we can drop the confirmation dialog."

Swap the safeguard from checking beforehand to recovering afterward.

At Pagedeck the phrase came up most around document sharing. Sofia brought in a summary of support tickets and the same question kept repeating: how do I show a document to someone outside the company? That feature had shipped at launch. Theo checked the logs and found that a large share of people who reached the sharing screen closed it without selecting anything.

Noa ran five people through the same task — send this document to someone outside the company, read-only. Three stopped at the permission list. Read, comment and edit sat side by side, and the gap between "sending this outside the company" and "picking one of these three" never closed in their heads. One person chose edit, cancelled, and opened the dialog again. All five understood what the three words meant. Where they stalled was deciding which of the three their own task was, a question the screen had quietly handed to them without any of the context needed to answer it.

Noa removed nothing. She changed the order and the wording: ask who the document is going to first, and when the answer is someone outside the company, default the permission to read-only. Mia wrote down the part worth keeping, which was that none of those tickets came from a missing feature. The repeat question dropped sharply the next month, and so did the share of people who opened the sharing screen and left empty-handed. The permission options were identical before and after; what changed was the order in which the screen asked its questions.

The most common error is assuming better usability makes a product succeed. Screen fixes produce visible before-and-after numbers and give a team something concrete to start on. But this axis sits second of five, and the first slot belongs to usefulness. Make an unwanted feature easier and you have removed one reason not to use it. Teams that invert the order redraw screens every quarter and keep asking why the numbers won't move, and the answer is usually outside the screen. Checking first whether anyone actually asked for the feature costs an afternoon and saves the quarter. Separating the two is straightforward: look at whether the people who did finish the task came back the following week. Finished and gone means they didn't want it; only the stuck ones disappearing means they couldn't find the way, and that difference decides whether the next sprint touches the screen or the roadmap.

The other one is treating it as something users grow out of. Long-time users genuinely stop complaining, which makes the claim look right. But the people not complaining are the ones who adapted, and the ones who couldn't already left and have no way to say so. New users arrive every day, so this problem isn't solved, it repeats at the same rate indefinitely. Left alone, churn concentrates on day one and no amount of ad spend raises the number of people who stay. The quickest way to end the argument inside a team isn't a chart — it's showing five people who signed up this week stalling at the same screen.