UX Honeycomb

"The UX is bad" fixes nothing on its own. Naming what specifically is bad is what assigns an owner and sets an order for the work, and that sentence supplies neither of those things.

Pagedeck's quarterly review worked that way for a long time. The subject was user experience — everything a person goes through while using the product — and for forty minutes the only topics were button placement, color and spacing. Nobody in the room could say which subjects hadn't come up, because what you fail to look at doesn't appear in the meeting notes either.

The honeycomb exists to make the missing cell visible. Seven cells get drawn as joined hexagons and the conversation happens on top of them. The shape earns its place: write the same seven items as a numbered list and the first one reads as the most important, while the drawing says instead that no cell ranks above another. A high score in one cell does not make up for a low score in a different one.

The exercise takes thirty minutes to an hour, in five steps.

1. Narrow the subject to one thing. Run it against the whole product and every cell has too much to say for anything to be concluded. Pick a single flow instead, something as narrow as sharing one document with one colleague.
2. Write the question into each of the seven cells. Usefulness asks whether the flow solves something anybody actually needs. Usability asks whether the person can finish that thing easily and correctly. Findability asks whether they can locate the feature at all. Credibility asks whether the product feels safe to rely on. Desirability asks whether anyone wants to come back. Two more cells join those five: accessibility, which asks whether the flow works for someone who can't see the screen clearly or can't use a mouse, and value, which asks whether the experience is worth something to the company as well. That last cell is there because an experience that's good only for users and impossible for the company to sustain doesn't last.
3. Attach evidence to each cell. It has to be a record rather than an impression — forty support messages this month, the spot where three of five people stalled in a usability test, the drop-off rate midway through the flow. Impressions are what the forty-minute meeting was already made of. Split the sharing flow up that way and twelve of the twenty complaints turn out to say the same thing, that nobody could find where permissions are changed, which puts them in the findability cell.
4. Mark the empty cells. A cell you couldn't attach a single line of evidence to is what this tool actually produces. In Pagedeck's first pass, accessibility and value were both blank, which meant neither had been mentioned once that quarter.
5. Decide what to give up. Filling all seven isn't the goal. Writing down that desirability won't be touched this quarter makes it a decision; leaving it unwritten makes it an oversight. Last quarter's sheet is where you find out which of the two it was.

The boundary that causes the most trouble runs between usability and findability. Usability is the story after somebody found the feature and findability is the story before. A feature buried three menu levels down loses points in the findability cell no matter how well it was built. It exists in the code and not in the product.

Three places fit. Sorting incoming complaints, choosing what to build next, and deciding what will count as proof after a fix. The same complaint changes hands depending on which cell it lands in: "sharing is awkward" filed under usability becomes a screen to redraw, and filed under findability becomes a menu structure to rework.

The limits are just as clear.

1. It produces no score. There's no scale that says how many points a cell is worth, so comparing against last quarter means choosing a separate metric for each cell first. Nothing in the framework tells you what those metrics should be.
2. The cells don't divide cleanly. A failed save belongs to credibility and to usability at once. In practice you file it in one cell and leave a note in the other.
3. The value cell doesn't come out of user research. It gets filled only when somebody who knows the revenue and the costs joins the session.
4. It's the wrong instrument for taking one screen apart item by item. For that, a denser checklist like Nielsen's heuristics does the job.

"This complaint is findability, not usability. The feature exists, they just can't locate it."

Correcting which cell a complaint belongs in, because the cell decides who picks it up.

"Lay out the honeycomb and you can see accessibility never came up once this quarter."

Using the framework for the purpose it was built for: surfacing the cell nobody looked at.

"Don't average the seven cells and write down 'fine.' That erases everything worth fixing."

Pointing out that combining the cells destroys the information in them.

At Pagedeck, Noa draws this table once a quarter. Mia looks at the blank cells first, Sofia attaches sentences customers actually said, and Grace fills in the value cell. Three people read different cells off a single sheet, and that division of attention is what changed the meeting where forty minutes used to go to button placement.

The most common reading is that filling all seven cells is the target. The word checklist carries the suggestion that every line has to pass before you're finished. But no team raises seven cells in one quarter, and aiming for it means touching each one slightly and moving none of them. The framework is useful because it makes you give a cell up knowingly. Something left out by accident and something postponed on purpose look completely different by the following quarter.

The other frequent mistake is treating it as a scoring instrument. With seven cells it's tempting to rate each out of five and total them up. But the cells are measured in different units and can't be added. A product that has never once failed to save while taking a full minute to locate a file has high credibility and low findability, and averaging those into "fine" deletes the thing worth fixing. Instead of a total, leave one line per cell and then pick one of those lines; the line you pick is what becomes next quarter's work.