User Pain Criteria
The criteria we use to define user pain are divided into three factors:
- Type
- Likelihood
- Priority
Factors
Type
What type of bug is this? For example is it a crashing issue, a problem with localization or a matter of visual polish?
| Nr. | Description |
|---|---|
| 1. | Documentation: research ticket |
| 2. | Localization: Wrong translations, new feature |
| 3. | It is not broken but it looks broken, styling and visual. Unprofessional look and feel. |
| 4. | Balancing: use workaround because the process works but is inconvenient. E.g. call lists for sales in excel |
| 5. | Minor usability; standard process works - but with nasty workarounds like user cant activate so the agents will do it for the user |
| 6. | Major usability; effects process - no bidding, no registrations |
| 7. | Crash, data loss. Shit is broken. Site down, server down, call-center down. |
Likelihood
How likely are users to experience the bug? For example, does everyone run into the issue or do only a few users run into it?
| Nr. | Description |
|---|---|
| 1. | Almost no users |
| 2. | Few users |
| 3. | Average number of users |
| 4. | Most users |
| 5. | All Users |
Priority
Of the people who experience the bug, how badly does it affect their experience with the product?
| Nr. | Description |
|---|---|
| 1. | Small irritations, Extremely unlikely to affect process. |
| 2. | Person will notice and get a bad feeling but it does not cancel the process. Its just not cool. |
| 3. | Issue that will show up in a bad review. |
| 4. | Consumer bounces, dealer bounces and agents will try to find workaround, fuck you I will go to another site, consumer cancels the sale or registration. |
| 5. | Blocks development / shit breaks / live is broken |
The online version of this document is accompanied by a tool to make it easier to calculate the number for developer pain.