Study // Knowledge card 3.2
Fix disasters before you chase desire
How to use Alan Dix's disaster and desire on NN/g's impact–effort matrix to pick which problems to fix, so scarce time goes furthest.
- Date
- Aim
- Which usability problems do I fix first when time runs out?
- Topic
- Strategy & Metricsframework · core
- Built with
- Claude + NotebookLMUpdated · 6 min read
Notes
3.2aTwo scores, four cornerssrc 02
Finding usability problems is cheap; choosing which to fix is the work, because time is a design constraint too.
Sarah Gibbons's impact–effort matrix · ma trận tác động – công sức sorts the list on two questions, effort across and impact up the side. I score them like this:
- Impact: how bad, for whom? Minor is a few people, rarely, with an easy workaround. Major is serious trouble for someone.
- Effort: what does the fix take? Easy is a setting or a label. Hard is back to the drawing board.
Gibbons names the corners. Quick wins, high impact for low effort, are worth pursuing. Big bets matter more and cost more, so they get planned and prototyped. Money pits cost a lot for little impact. Fill-ins are cheap and small, yet Surprising: I expected small fixes to be harmless filler between real work. They stack up into whole sprints, so I time-box them..
In my words
The matrix splits one gut feeling into two scores, so a fix stops looking urgent just because it is cheap.
Link
Spend an expert's hour before a user's — a severity rating scores the harm alone; the matrix adds what the fix costs.
3.2bInside the hard corner: disaster, then desiresrc 01
Alan Dix's essay draws no matrix; I hang his two touchstones on the big-bets corner. A disaster · thảm họa ends the relationship; desire · khao khát is what makes someone want the product.
- Disaster comes from function. People live with a lot of interface pain while they get things done, Dix argues; total disaster usually comes from failures of functionality.
- Desire is the other extreme. He credits Apple's success to desire, ahead of good usability or engineering.
- Ordinary fixes pay in proportion. Most usability testing buys gains in step with effort. The large returns sit at Confused: How would I spot a turning point before the fix ships, instead of in hindsight?, where a small change rescues a product or makes it wanted.
A new product, for Dix, spends its effort and creativity at those two extremes; an established one can afford the little things. I read the order as disaster first, because desire cannot reach someone who already left.
In my words
I read Kano's 1984 model the same way: must-be quality acts like disaster, attractive quality like desire, one-dimensional quality like the list between, so two fields agree on the order.
3.2cFour moves for a triage sessionsrc 02
- Screen for disasters. Ask of each issue: if this happened once, would they leave? Those go to the top before scoring, so no average can bury them.
- Score impact and effort apart. Research scores impact from what people hit; engineering scores the fix.
- Place, and write down why. One line per card. Actionable: Next backlog grooming: add an impact column and an effort column to the sheet, filled by different people.
- Hunt for desire, and protect it. Ask which item would make someone want one, and keep it on the plan, because a tight sprint cuts what nobody complained about.
Why
Why two scorers? Because in my experience whoever must build the fix shrinks the problem to match the cost.
3.2dAt work: three situations
- "Can we squeeze these twenty polish tickets into the release?" Twenty fill-ins can eat a sprint. I keep the ones a user would notice, give them a fixed slot, and spend the rest on quick wins.
- A crash during save shows up in three support reports. Few people, rare: the impact score reads minor. Connection: Same test as 3.2b: one occurrence, and they leave. I move it to the top.
- An engineer calls an issue minor because the fix is a rewrite. That is an effort score speaking as impact. Actionable: In the next triage meeting, read the impact column aloud before anyone says how long a fix takes.
Critique
Goal: catch disasters. Element: the question "would one occurrence make them leave?" Works? Only with evidence, because designers guess at it. Pair it with support tickets and notes from people who left.
Examples
One case of the same shape, kept for reference.
3.2eSonos app, 2024src 04
Sonos shipped a rebuilt app in May 2024 that launched without features the old one had, among them queue editing and local media access. Sonos put the cleanup at $20 million to $30 million, and in January 2025 its CEO, Patrick Spence, stepped down.
Link
3.2b — a failure of function, met once by people who had relied on it.
Meaning
Sketch (from my case study · Dash Cam LINK)
Easy
Hard
Major
Minor
Ranked on impact · effort never scored apart
On Dash Cam LINK, people rely on the app in critical moments, after an accident or an unexpected incident, which is why I place a failed connection or a lost video in the disaster corner. The cause lived in a fragmented technical foundation, which I read as hard as well as major. I split the work with a Painkiller (core value) vs Vitamin (supporting value) lens: fast, stable connection and reliable retrieval first; a modern interface and visual clarity second, with changes such as dark→light mode deliberately deprioritized. The case ranks on impact alone, though: nothing records effort scored as its own axis, or any work aimed at desire.
Paraphrase (my own words)
- The hard part of usability work is picking fixes, since time ends first.
- Score harm and cost separately, and every issue lands in one of four corners.
- Do cheap, serious fixes now; plan and prototype the costly serious ones.
- In the costly serious corner, stop what drives people off, then build what pulls them in.
Critique (disagree, edge cases, trade-offs)
- Ranking a list with gaps. The matrix orders only what someone already found, so an unreported disaster never reaches the board. Pair it with support logs and a usability test.
- A stale corner. A placement is a snapshot: platforms change what a fix costs, and growth changes who a problem hits. Tell-tale sign: a money pit nobody has looked at in a year. Re-score that corner every quarter.
Remember
The note in a few cards: the idea, the words, the steps.
Concept
Choosing is the job
Any review finds more problems than a team can fix, so the skill is deciding which ones get the time.
Concept
Disasters before desire
In the major-and-hard corner, stop what drives people away first, because desire never reaches someone who left.
Term
Impact–effort matrix · ma trận tác động – công sức
A two-by-two of harm against cost of the fix — quick wins, big bets, fill-ins, money pits.
Term
Disaster · thảm họa
A failure that, met once, makes someone stop using the product; usually broken or missing function.
Not An interface annoyance people work around.
Term
Desire · khao khát
The pull that makes someone want the product, often from something nothing else does.
Workflow
Run a triage session
- Screen for disasters
- Score impact and effort
- Place and note why
- Protect the desire
Retrieval
Cover the notes. Answer each question from memory, then turn the card to check.
Q1
Why can one rare failure outrank an annoyance that hits far more people?
Tap to answer
Q1Answer
Why can one rare failure outrank an annoyance that hits far more people?
People tolerate friction while they still finish the job. A failure of function breaks that once, and whoever left never sees the polish you add later.
Tap to turn back
Q2
Name the four corners of the impact–effort matrix and what each one gets.
Tap to answer
Q2Answer
Name the four corners of the impact–effort matrix and what each one gets.
Quick wins go first. Big bets get a plan and a prototype. Fill-ins get a time box. Money pits wait, and are re-scored later.
Tap to turn back
Q3
Your team's triage sheet has a single priority number per ticket, and the cheap tickets keep winning. How do you fix it, and why does the fix work?
Tap to answer
Q3Answer
Your team's triage sheet has a single priority number per ticket, and the cheap tickets keep winning. How do you fix it, and why does the fix work?
Split it into impact and effort, scored by different people. Cost then stops hiding inside the harm score, and serious, costly items show up as big bets.
Tap to turn back
Q4
A designer asks for time to build something users will love while two disaster-class bugs are open. What do you settle before saying yes?
Tap to answer
Q4Answer
A designer asks for time to build something users will love while two disaster-class bugs are open. What do you settle before saying yes?
Whether the two bugs are scheduled first. Desire comes after the disasters in the same corner, so the delight work waits for them, then gets protected.
Tap to turn back
Q5
When do the little things deserve the time before disaster and desire?
Tap to answer
Q5Answer
When do the little things deserve the time before disaster and desire?
Once a product is established and its big failures are handled. On a new product, Dix would spend that time at the two extremes instead.
Tap to turn back
Q1 / 5
Open question
The disaster test assumes a person can leave, but a companion app tied to its hardware has no rival to switch to. When people cannot leave, what does a disaster look like?
Sources
- 01Desire and Disaster (opens in a new tab) — Alan Dix — Interfaces 91, BCS Interaction Group (first appeared June 2011), 2012
- 025 Prioritization Methods in UX Roadmapping (opens in a new tab) — Sarah Gibbons, Nielsen Norman Group, 2021
- 03Attractive Quality and Must-Be Quality (opens in a new tab) — Noriaki Kano, Nobuhiko Seraku, Fumio Takahashi, Shin-ichi Tsuji — Journal of the Japanese Society for Quality Control 14(2), 1984
- 04Sonos CEO is out following disastrous app revamp that enraged customers (opens in a new tab) — PCWorld, 2025
- 05Sonos CEO out as company cleans up botched app release (opens in a new tab) — Kristen Doerer, Customer Experience Dive, 2025
Related
Next note