Usefulness

"The experience is bad" fixes nothing. Naming what's bad is what assigns an owner and an order, so experience gets broken into separate axes — and one of those axes, if it fails first, makes working on the rest pointless.

One scene shows what that looks like. A new feature ships to usability testing and all five participants finish the task in under 30 seconds. The screen passes. Two months after launch, one percent of users have touched the feature once. The test asked whether people could do it when told to. It never asked whether it was something they wanted to do unprompted. Those are different questions, and only one of them predicts what happens after the researcher leaves the room.

As that pattern repeated, this question moved to the front of the list of axes. Before asking whether something is easy to use, ask whether there's any occasion to use it.

Usefulness isn't settled by how finished a feature is. It's settled by whether the work that feature aims at exists. So checking it means looking at what people do today rather than at a screen. Nothing about the pixels answers this question.

Three things are worth asking.

1. Are they doing this work now? Ask how they currently handle it, and if an answer comes back, the work exists. "I scroll way up in the chat thread looking for the meeting notes" is a real answer. If the response is that they don't do it at all, there's nothing to build for yet.
2. How often does it happen? Daily and once-a-quarter are different situations. A feature needed once a quarter goes unused because when the moment arrives nobody remembers that the feature exists.
3. How bad is the current method? Taking something from five minutes to four is not the same improvement as taking 40 minutes to five. The first one isn't a reason to switch. People tolerate a five-minute annoyance for years, while a 40-minute one is what sends someone looking for a tool.

After building, two numbers matter: the share of people who used it once, and the share of those who came back to it two weeks later. The first number mixes in whether people heard about it, so the second sits closer to this axis. If 100 people tried it and eight came back the next month, the feature missed the work it was aiming at.

Adding ten text-decoration effects nobody requested is the standard example of failing here. It can be built, it looks good, it's easy to use, and nobody was trying to do that.

The score on this axis is largely decided before a screen is drawn, in the stage where what to build gets chosen, which leaves design little room to raise it afterwards. That's why it sits first among the five. Usability, which asks whether the goal can be reached easily and accurately, findability, which asks whether people can locate what they want, credibility, which asks whether the product feels trustworthy, and desirability, which asks whether anyone wants to come back, all stand on the assumption that there's a reason to be here.

There are four places the axis does work.

The first is choosing what to build. Request lists mix "do this work for me" with "make what I already do easier." The first is a question for this axis and the second is a usability question, and separating them changes what kind of work gets scheduled.

The second is retiring a feature. Arguing to delete something used by one percent of people needs a basis, and confirming that almost nobody does the work it aims at is that basis. Without it the conversation stalls on whether the feature might still find its audience, which is an argument nobody can win.

The third is designing a usability test. Before handing someone a task, ask whether they've done that work recently. Give the task to someone who hasn't and you learn only that it's possible, never that it's wanted.

The fourth is talking to users. Don't ask whether they need the feature; ask how they handled that work last week. The first question almost always returns yes. The second returns what they actually did.

"It got easier to use and nobody is using it."

The diagnosis isn't the screen — the work it aimed at wasn't there.

"Don't ask whether they need this. Ask how they did it last week."

Judge from past behavior rather than from stated preference.

"One percent used it, that's usefulness. One percent knows it exists, that's findability."

The same low number, two different places to fix.

At Pagedeck, Mia and Noa held a text-formatting request for two months. Instead they asked ten users how they had found an old set of meeting notes that week, and seven of the ten said they scrolled back through a chat thread or asked a colleague. So what went to the front of the next quarter wasn't formatting effects — it was a screen for finding past documents.

While designing it, Noa checked one more thing. What people remember depends on how old the document is: three days back they remember the title, six months back they only remember who they wrote it with. That split decided which search field came first on the screen.

The most common mistake is treating a feature users said they wanted as useful. It comes straight from the person affected, which sounds like the strongest possible evidence. But asked whether they need something, most people say yes — there's no reason to turn down something that costs nothing to have. Words and behavior diverge here, so the question has to change. Leave the assumption in place and the most-requested features get built first, and it takes two months and a one percent usage rate to learn those requests were opinions. A request count measures how easy something was to say yes to, not how badly it was needed.

The second is deciding usefulness is outside design's reach. What gets built is settled upstream, which makes the claim sound right. But there's one thing design can do: move the verdict earlier. Stitch a few screens together into something clickable and you can find out in two weeks, rather than after six months of building, whether this work exists. Give that up and the verdict on usefulness lands after launch, when reversing it costs six months.