# Prioritize bugs by user impact

- **Canonical URL:** https://playbook.affpartners.io/en/practices/quality-bugs/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/quality-bugs/index.md
- **Module:** Product quality
- **Time:** 60 minutes for the first analysis

You do not need to be a technical expert to bring order to a bug backlog. For each bug, answer four questions: what is broken, who is affected, how often it happens, and whether a safe workaround exists.

## Outcome

A table of the five highest-impact bugs with evidence, a workaround, an owner, and a review date.

## Priority is harm to the user, not how loud the discussion is

A striking visual defect may get a lot of attention, but a broken transaction status, data loss, or a login failure usually matters more. Protect security, money, data, and the key journey first; convenience and appearance come after.

## What you will need

- **Access:** Crashlytics, AppMetrica, or another error report, plus the current task list in Jira, Linear, or a spreadsheet.
- **Colleagues:** A QA engineer or developer and a support representative for 20 minutes to confirm the technical trail and complaint frequency.
- **Period:** Errors, support requests, and reviews for the last 14 days; note app versions and platforms separately.

## Terms in plain language

- **Crash-free rate — The share of users without an app crash:** Definition: The closer it is to 100%, the fewer users experienced an app crash during the selected period. Example: 99.5% crash-free users means 0.5% experienced at least one crash.
- **ANR — An Android app freeze:** Definition: Android records an ANR when the interface does not respond to the user for too long. Example: The user taps a button, the screen freezes, and Android offers to close the app.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.
- **Conversion — The share of people moving to the next step:** Definition: Shows how many people who started a step completed it or reached the next one. Example: 80 registrations completed from 100 started: 80 ÷ 100 × 100% = 80% conversion.

## When to use it

The backlog keeps growing, the team argues about urgency, and the latest loud request gets picked up instead of the most dangerous problem.

## Where to look for evidence

One screenshot does not show the scale. Combine the technical signal, a user report, and the impact on a key action.

- **Crash and ANR reports**
  - **Source:** Look at the number of affected users, the app version, device, stack trace, and repeatability.
  - **If access is unavailable:** If there are no reports, ask a developer to reproduce the problem and save the video, logs, and conditions.
- **Support and reviews**
  - **Source:** Group requests by a single cause: login, status, payment, data loss, blank screen, or a confusing message.
  - **If access is unavailable:** If tags are not set up, manually go through the 30 most recent requests and create five simple categories.
- **Key journey**
  - **Source:** Compare the action's success rate before and after the error appeared: login, registration, saving, verification, or a transaction.
  - **If access is unavailable:** Without analytics, run the journey ten times on the affected version and record the failure rate.

## Sort out the bug list in five steps

1. **Collect everything into one table.** Merge duplicates from crash reports, QA, support, and reviews. One user problem should be one row.
   - **Where to do it:** Jira, Linear, or a shared table with links to the original signals.
   - **Example:** Three tickets — “endless status,” “transaction stuck,” and “I can't see the result” — are merged into one problem.
2. **Describe the harm in plain words.** Write down what the user cannot do and what they risk losing. Do not leave only an error code in the title.
   - **Where to do it:** In the “user impact” field of each task.
   - **Example:** Not “API 504,” but “after confirming, the user does not see the final status and repeats the action.”
3. **Confirm the scale.** State the number of people affected, the platform, version, frequency, and period. If there is no number, honestly note your confidence level.
   - **Where to do it:** Next to the technical trail and a link to the support requests.
   - **Example:** 84 users in 7 days; Android 12 only; confirmed by 12 support requests and one error cluster.
4. **Assign a priority and a workaround.** Security, money, data, and a blocked key action come first. While the fix is in progress, support must know how to help the user safely.
   - **Where to do it:** In the P0–P3 columns: owner, deadline, and workaround.
   - **Example:** P0; owner — the backend team; deadline — today 18:00; support checks the status by ID.
5. **Close on data, not on release.** After the fix, repeat the scenario and make sure both the technical signal and the user complaints are gone.
   - **Where to do it:** In the task, 24–72 hours after the fix ships.
   - **Example:** The error cluster is gone, 20 test runs pass, and no new requests on the topic for two days.

## Practical examples

- **P0: transaction status stuck:** The problem hit 84 users in a week: the result is invisible, so people repeat the action. There is a financial and trust risk — an owner and a safe support reply are needed today.
- **P1: empty history on Android 12:** The scale is smaller, but key data is unavailable. The task records the version, a repro video, the temporary restart workaround, and a support-request check 48 hours after the hotfix.

## Finished artifact: A priority table the whole team understands

Five rows are enough for the first decision. Do not hide the impact behind a technical bug name.

| Problem | Impact and scale | Workaround | Decision |
| --- | --- | --- | --- |
| Transaction status stuck | Money/trust · 84 users | Support checks manually | P0 · fix today |
| Login code not delivered | Blocks login · Android 12 | Resend after 60 seconds | P0 · Android developer |
| Empty history | Data not visible · version 4.2 | Restart the app | P1 · urgent fix |
| Push opens the home screen | Extra step · 11% of taps | Open the section manually | P2 · next release |
| Misaligned icon | Appearance only | Not needed | P3 · design debt |

Rule: P0 blocks or corrupts money, data, security, or the main journey. Every P0 has an owner, a deadline, a message for support, and a way to verify the fix.

## Prioritization checklist

A critical task should read the same to product, support, and development.

- [ ] The problem is named through the action and the harm to the user.
- [ ] Platform, version, period, and a confirmed scale (or a confidence level) are present.
- [ ] Errors involving money, data, security, and trust are flagged separately.
- [ ] P0/P1 issues have an owner, a deadline, and a safe workaround.
- [ ] It is written down in advance which data will confirm the fix.

## How to know the fix worked

- **Technical signal:** The specific crash cluster, ANR, or error code disappeared on the affected version.
- **User journey:** The success rate of logins, saves, transactions, or the other broken action recovered.
- **Support and trust:** New requests on the topic stopped, and users who hit the problem received a clear answer.

## Key rule

A bug is closed not when the code ships, but when users complete the journey again and the data confirms it.

---

- [HTML version](https://playbook.affpartners.io/en/practices/quality-bugs/index.html)
- [All practices](https://playbook.affpartners.io/en/)