Severity and priority
🎯You'll be able to
Rate each finding's severity with a shared scale and decide what to fix first, using severity, frequency and effort.
🏠The everyday picture
A hospital's emergency room sees people in order of need, not arrival. A broken arm waits for a heart attack. Findings need the same kind of triage.
📘What it really is
- Severity describes the harm when the problem happens. A simple scale:
- Critical: stops people completing the task, or causes a serious mistake (booking the wrong day, exposing personal data).
- Serious: slows people down, causes errors they can recover from, or makes them lose trust.
-
Minor: annoying, but people carry on easily.
-
Frequency is how many participants met it. A minor problem that everyone met can matter more than a serious one only one person met, but a critical one seen once still needs attention.
-
Effort is how hard the fix is. Teams often fix high-severity, low-effort problems first.
-
Privacy, safety and accessibility problems are rated by their harm even if few people noticed them. P4 noticed the full phone number on the confirmation page; the others may simply not have thought about who was looking at their screen.
-
Agree the scale before rating so that two people rate the same problem the same way.
📝A worked example
Input: the eight tags from Lesson 1.
| Tag | Seen by | Harm | Severity |
|---|---|---|---|
| slot-picker | 4 of 5 | People can't tell what they chose; keyboard users can't choose | Critical |
| error-colour | 3 of 5 | P3 gave up on T1; others needed help | Critical |
| no-back | 3 of 5 | Two failed T3; details lost | Serious |
| no-results | 2 of 5 | Both failed T2 | Serious |
| placeholder-label | 2 of 5 | Retyping, mistakes | Serious |
| small-targets | 2 of 5 | Wrong taps | Serious |
| phone-shown | 1 of 5 | Personal data visible to others | Serious |
| jargon | 1 of 5 | Confusion, no failure | Minor |
Expected output: the two critical findings are fixed first; the phone number is quick to fix and protects privacy, so it goes early too.
🌍Where it's used
- Bug trackers use severity fields for design problems as well as code bugs.
- Accessibility reports rate issues by their impact on people with disabilities.
- Release planning: critical findings block a release; minor ones go on a list.
📝Case scenario
A travel site's team argued for weeks about which finding to fix first. They agreed a three-level scale with written examples, re-rated every finding together in an hour, and found that most of the disagreement had been about the words, not the problems.
🖱️Try it
Rate these: (a) a checkout button hidden under the keyboard on small phones, seen by 2 of 6; (b) a typo in the footer, seen by 5 of 6; (c) another customer's address shown on the order page, seen by 1 of 6. Success: (a) and (c) are critical or serious, (b) is minor, and your reasons mention harm.
⚠️Common mistakes
- Severity from frequency alone. Sign: "only one person saw it, so it's minor". Fix: rate harm, then consider frequency.
- Everything is critical. Sign: no minor findings. Fix: use the written definitions.
- No scale agreed. Sign: two reviewers rate the same thing differently. Fix: agree definitions and examples first.
🛠️For your project
Project 1's findings table needs a severity for each finding, using exactly critical, serious or minor, and test 8 checks that every
critical and serious finding has a design change.
✅Quick check
What does a critical finding do?
Show the answer
It stops people completing the task or causes a serious mistake.
Should a privacy problem seen by one person be rated minor?
Show the answer
No: severity is about harm; exposing personal data is serious or worse even if only one person noticed.
