User Experience

For a long time a product got judged on two questions. Does the feature exist, and does the screen look good. One question kept coming back that neither of them could answer: the feature list beats the competition and the screens are fine, so why is nobody using it.

Open the cancellation survey and the reasons are scattered outside the feature list. "I signed up and had no idea what to do next." "My file won't upload and nothing tells me why." "It was slow." "I wrote in and heard back three days later." Four people left, and not one of them left over a missing feature. The first left because the welcome email said nothing useful, the second because the error text was a single line reading something went wrong, the third because the screen took eight seconds to load, the fourth because support was slow.

The trouble was that those four could not be discussed in one meeting. Marketing owned the welcome email, engineering owned the error text, infrastructure owned the speed, support owned the reply. Inside each of those teams nothing was broken. One person's single experience was held as four fragments by four organizations, and there was no name that let anyone put the fragments on one table.

User experience is that name. It bundles every point where a person touches the product, not just what happens inside the screen. The first ad they saw, the email after signup, the empty screen on the third visit, the failed-payment notice, the menu they hunted through to cancel — all of it belongs to the same experience. A team that starts using the term stops asking how this screen looks and starts asking what this person went through to get here.

What changed when the term spread was not the tooling, it was who sat in the room. Fixing a screen used to mean a designer and an engineer. Looking at the whole experience means the person who writes the welcome email and the person who answers tickets are reading the same table. The four teams holding fragments now have a place to follow one person's day and fill in their own column.

That is also why the term sits at the top of the design field. Information architecture, interaction and copy each handle one material of the experience. User experience is the name for what those materials add up to.

"The UX is bad" fixes nothing on its own. Naming what is bad is what assigns an owner and sets an order, and that means breaking the experience into parts. This field has two groups: the five quality attributes that make up an experience, and the framework that keeps a team from skipping any of them.

Each quality attribute holds one axis of measurement. They come in an order, and when an earlier one collapses the later ones stop meaning anything.

1. Usefulness — does the product actually solve a problem someone has. This is the first gate. However easy it is to operate, a feature that does an unneeded job goes unused. Ten font effects nobody asked for in a collaborative document tool fail here. This axis is usually settled before design begins, at the point where someone chose what to build.
2. Usability — can a person reach their goal easily and correctly. The question is not whether the feature exists but how many times they stall on the way to it. Spending twenty seconds on a sharing dialog deciding between view, comment and edit loses points on this axis. Twenty seconds sounds small, but it's four minutes a day for someone who shares twelve documents, and the worse outcome is the person who deliberates and then picks the wrong one.
3. Findability — can a person locate what they want. It sits next to usability but measures a different moment. Usability starts after the feature has been found; findability is the part before that. A feature buried three menu levels deep is built, and to the user it does not exist. When this axis collapses, support keeps receiving requests to build something the product already has.
4. Credibility — does the product feel safe to rely on. Press save with no indication that anything happened and people reload the page to check. After one experience like that, they start keeping a second copy of anything important somewhere else. When this axis breaks on a payment screen, the exit is immediate. People will tolerate the first three axes being poor and keep using the product; this one takes months to win back.
5. Desirability — does a person want to use it. The first four remove friction; this one makes someone open the product again. It usually explains why one of two products with matching features gets used more. But working on this axis while the other four are broken produces a product that changed only on the surface. Add animation to a product whose saves keep failing and all you have extended is the waiting.

The five axes do not substitute for each other. A high score on one does not cover a low score on another, which is why scores inside a single product diverge sharply by axis. A file storage product that has never lost a save but takes a minute to locate the right file is high on credibility and low on findability. Average the two into "fine" and there is nothing left to fix.

The framework group gathers these attributes into one checklist. The UX honeycomb splits experience quality into seven cells laid out as a honeycomb. It adds two things to the five above: accessibility, which asks whether the product works for someone with a disability or with one hand occupied, and value, which asks whether the experience is worth something to the company as well. The last cell is there because an experience that is good for users and unsustainable for the business does not last.

The use of the frame is that it exposes the cell nobody mentioned. After forty minutes of a meeting spent on screens, laying out the seven cells makes it visible on the spot that accessibility and findability have not come up once this quarter. It is not an instruction to fill all seven. It is an instruction to know which cell is being given up this time.

There are three places the term actually comes up. The first is sorting incoming complaints, where the same complaint gets a different owner and a different fix depending on the axis it lands on. The second is choosing what to build, where the split becomes the basis for comparing one more feature against raising one axis on a feature that already exists. The third is checking afterward, because writing down which axis was supposed to rise also settles what will be used to confirm it.

The two groups interlock like this. The five attributes tell a team what to look at, and the honeycomb keeps them from missing one. Once the problem is split into axes, the next question follows on its own: which axis got worse this time. Being able to answer that is the moment user experience turns from a matter of taste into a piece of work.

"It's not a missing feature, it's a UX problem. It's all there and nobody can find it."

A diagnosis that findability has collapsed, and a proposal to fix structure instead of adding features.

"Let's spend this quarter on user experience instead of new features."

Moving resources from adding things toward raising the quality of what is already built.

"Don't just say the UX is bad. Tell me which axis is the problem."

A lumped-together verdict can't assign an owner or an order, so break it into attributes.

At Pagedeck, when free-to-paid conversion sat flat for two months, Mia's first answer was a new feature. She read it as the missing document-locking feature that a competitor shipped. Noa proposed reading the 180 cancellation responses by axis first, and the result did not match. Eleven responses named a missing feature. Most of the rest had either set a sharing permission wrong and exposed a document externally, or had a colleague unable to open something and lost time resending it.

Splitting the same problem by axis produced three separate jobs. Permission options whose names don't say what they mean went to UX writing. A settings screen buried inside the document menu went to findability. No way to check who can see a document after sharing it went to credibility. Rewriting the copy was the fastest of the three, so it shipped first. View, comment and edit became can only look, can leave comments, can change it directly, with one line under each saying what it does not allow — that was the whole change, and permission tickets fell by more than half within a month. The document-locking feature never got built that year.

What is worth noticing is the order in which the survey was read. Setting the axes first is why the same 180 responses produced a different answer. Read without axes, they would have collapsed into "sharing is awkward," and that conclusion cannot tell anyone what to do first. The same approach came back the next quarter. When Theo brought in a pile of speed complaints, Mia's first question was not how many seconds but which axis the problem sat on. A screen taking eight seconds to load is usability; pressing save with no way to know whether it saved is credibility. Same number of seconds, different owner, different fix.

The most common misreading is that user experience is another name for screen design. The people who say UX are mostly designers and the visible output is a screen, so the assumption is easy. But of the four cancellation reasons above, only one happened on a screen. Response time, the welcome email and the support reply all sit where a designer cannot reach. Left alone, this misreading makes experience work a design-team project, and the other three fragments that actually drove people away go unowned. That is how a team spends six months redoing the interface twice while churn stays where it was.

The other is treating experience as taste, and therefore unmeasurable. A good experience is hard to define in one sentence and people do feel it differently, so it looks that way. Split it into axes, though, and every axis takes a number. The share of people who completed a task, the time it took them, how many attempts it took to find a feature, the share who came back after hitting an error — all of these are countable. The HEART framework organizes items like these into five groups. Without measurement, experience work gets decided by whoever argues hardest, and nobody can tell whether a fix helped. Numbers do not replace the feeling. They do mean that "better than last month" is something people can agree with or dispute.