A UX audit template is one table with nine columns: screen or flow, finding, heuristic broken, severity, evidence, fix, effort, owner, and status. You fill in one row per problem, found while testing a product against a fixed set of usability checks.
Below is that table, header row included, with two rows already filled in so you can see exactly what belongs in each cell. Copy it straight into Google Sheets or Notion right now. No email form, no account, no second app to open first.
| Screen or flow | Finding | Heuristic broken | Severity | Evidence | Fix | Effort | Owner | Status | |---|---|---|---|---|---|---|---|---| | Signup, step 1 | Email field is labeled "Business" with no explanation, so personal addresses get rejected with no visible reason | Visibility of system status | High | Screenshot: signup-step1-error.png | Replace the label with "Business email" and show the rejection reason inline, not just a red border | S | One named engineer | Open | | Checkout, payment step | The submit button stays enabled while a required field is still empty, so the form can be submitted incomplete | Error prevention | Critical | Screen recording: checkout-empty-submit.mp4 | Disable submit until all required fields validate | M | One named engineer | Open |
That is the whole template. It is one artifact inside a bigger process, and the guide to running a UX audit end to end covers where it fits. What follows is what belongs in each column, how to score severity without the scale collapsing into mush, and how to actually fill the rows in.
What goes in each column, and how people get it wrong
| Column | What goes in it | The mistake to avoid | |---|---|---| | Screen or flow | The exact screen, step, or flow where you found the problem | Being vague ("the app") instead of specific ("checkout, step 2") | | Finding | One sentence describing the problem you observed | Writing a fix in disguise instead of the actual problem | | Heuristic broken | The usability principle the finding violates, from your checklist | Skipping this, so the audit reads like opinions | | Severity | Critical, High, Medium, or Low | A 1 to 5 scale, where everything lands on 3 | | Evidence | A screenshot, screen recording, or a link to the exact spot | A finding with no proof attached | | Fix | A specific, buildable change | Something like "improve clarity", which nobody can build | | Effort | A rough size: S, M, or L | Skipping it, so nothing gets prioritized | | Owner | One named person | A team name, which means no one | | Status | Open, in progress, fixed, or will not fix | Never touching it again after the review meeting |
Finding is the problem, not the fix. "Add a tooltip" is a fix. "Users cannot tell why the field rejected their input" is a finding. Keep the two in separate columns, or you will skip past what actually broke.
Evidence is not optional. A finding with no screenshot or recording next to it is an opinion, and opinions get challenged in the review meeting and cut. Grab the proof while you are looking at the screen, not after.
Owner has to be one name. "The frontend team" is not an owner, it is a place a task goes to disappear. Put a real person in that cell, even if you have to guess and correct it later.
Fix follows the same rule as Owner: specific, or it does not count. "Replace the label with 'Business email' and show the rejection reason inline" is buildable. "Improve clarity" is not, and it will sit in the backlog forever.
Four severity levels, not five
A severity scale needs exactly four levels.
- Critical: blocks the task, or loses the user's data.
- High: the task completes, but users drop off or misread something important.
- Medium: friction, but no drop off.
- Low: polish, nothing more.
A 1 to 5 scale looks more precise, but it is not. Give people a middle number and they will use it for everything they are unsure about. A 3 becomes a place to park findings without deciding, and half the audit ends up there.
Four named levels force an actual decision. Does this stop someone, or does it just annoy them? There is no comfortable middle to hide in.
How to fill the rows in without guessing
Work one flow at a time. Pick signup, or checkout, or the dashboard, not the whole product at once.
Run that flow against a fixed list of checks, so you catch the same things every time instead of whatever you happen to notice that day. That fixed list is what the UX audit checklist is for. It is the input. This template is where the output lands.
Capture every state as you go: empty, error, loading, and the state right after a form submits. Most usability problems live there, not in the default screen everyone screenshots.
Write one row per finding, not one row per screen. A screen with three problems gets three rows.
Score severity before you write the fix. Write the fix first and you will rate the finding by how easy it is to build, not by how bad the problem actually is.
What a filled in version actually looks like
The two rows above are illustrative. A real audit runs to 20 or 40 rows across a product, sorted by severity so the worst problems sit at the top.
If you want to see one worked all the way through, from raw findings to a scored, prioritized backlog, read the complete UX audit example. Same template. Just full.
Sheets, Notion, or Figma: pick by what happens after
The tool matters less than what your team does with the output. Pick by that, not by preference.
- If engineers work out of Jira or Linear, a table that exports to CSV wins. Sheets and Notion both do this cleanly.
- If the team reviews findings next to the actual screens, Figma annotations win, because the finding sits right where it happened.
- A beautiful Figma file nobody on the engineering side ever opens is documentation, not a fix.
In practice I keep the master table in Sheets, because it filters and sorts by severity in two clicks, and I drop evidence into a linked folder instead of pasting images into cells. Notion works the same way if that is where your team already lives. Neither needs Figma to be useful.
The template was never the hard part
Copying a table takes a minute. Filling it in with findings that are true, scored honestly, and specific enough to build takes longer, and no template does that part for you.
That is the actual work of a UX audit: looking at real screens, in real states, and writing down exactly what is broken instead of what feels off.
If you would rather have someone else run the audit and hand you a filled version like this one, on your own product, that is what the UX audit service is for.