A UX Audit Checklist a Startup Can Run in One Afternoon

A UX audit does not need a research lab. For an early-stage product, a focused review by two or three people in four hours will find most of the problems that are costing you sign-ups and support tickets. This post gives you the exact passes to run, a rule for ranking what you find, and a table to record it in.

The audit below is an expert review, not user research. It finds obvious breakage and friction. It cannot tell you what users want. Treat it as the cheap first step before you spend money on interviews.

Before you start: set the frame (20 minutes)

Most audits go wrong because they wander. Fix three things first.

1. Pick one core job. Not "the whole app". Choose the single task your product exists for: book a slot, send an invoice, upload a file and share it. Audit that path from first visit to done.
2. Pick one user. Write one sentence: "A freelance designer on a laptop, signing up for the first time, who has never seen our product." Every judgment you make is from that person's seat.
3. Pick the people. Two or three is enough: someone who designs, someone who builds, and ideally someone who does not work on the product at all. The outsider will find things the rest of you can no longer see.

Open a shared spreadsheet or a Figma file. Everything you find goes in one place, with a screenshot.

Pass 1: Clarity of purpose (30 minutes)

Open your landing page and your signed-in home screen cold, as if you had never seen them.

• Can someone say what the product does within five seconds of looking at the first screen? Ask your outsider to look, look away, and describe it.
• Is the primary action obvious, and is there only one primary action per screen?
• Does the page name the user's problem, or only list your features?
• Does the sign-up button say what happens next ("Start free trial" beats "Submit")?

A common mistake here: three equally loud buttons on the hero. The fix is to demote two of them to text links.

Pass 2: The core flow, step by step (60 minutes)

Walk the single core job from start to finish and count things.

• Steps: how many screens or clicks from intent to done? Write the number down. Then ask which steps exist for your convenience rather than the user's.
• Fields: for every form field, ask "do we use this in the first week?" If not, cut it or move it after the first success.
• Dead ends: is there any screen with no forward action and no way back?
• Account wall: are you asking for sign-up before the user has seen any value? Sometimes necessary, but decide on purpose.
• Progress: in a multi-step flow, does the user know where they are and how much is left?

Record the path as a simple list: "1. Landing, 2. Sign up, 3. Verify email, 4. Empty dashboard, 5. Create first item." Seeing five or six steps written down often makes the unnecessary ones obvious.

Pass 3: States and errors (45 minutes)

Most products are designed for the happy path with perfect data. Real use is messier. For each key screen, trigger or inspect these states:

• Empty: a new user with no data. Does the screen explain what to do, or show a blank table?
• Loading: does something show while data arrives, or does the page freeze?
• Error: submit a form with bad input. Does the message say what is wrong and how to fix it, next to the field? "Something went wrong" is a failure.
• Partial or long data: a name with 60 characters, a list with 500 rows, an image that fails to load.
• Offline or slow: throttle the connection in browser dev tools and repeat the core flow.

This pass tends to produce the longest list of findings, and many are cheap to fix.

Pass 4: Readability and accessibility basics (45 minutes)

You are not doing a full accessibility audit here. You are catching the failures that exclude people and that automated tools can flag quickly.

• Run a free contrast checker on body text, buttons and placeholder text. WCAG 2.1 asks for a contrast ratio of at least 4.5:1 for normal text; check your own colours against that.
• Tab through the core flow with the keyboard only. Can you reach every control? Can you see where focus is?
• Zoom the browser to 200 percent. Does anything overlap or disappear?
• Are tap targets on mobile large enough to hit with a thumb? Apple and Google both publish minimum target size guidance (44 points and 48 dp respectively); check against it.
• Do images that carry meaning have text alternatives, and do form fields have visible labels, not just placeholders?

Pass 5: Consistency and trust (30 minutes)

Open five screens side by side.

• Do buttons, spacing, headings and icons look like they belong to one product?
• Is the same action called the same thing everywhere? (Not "Remove" on one screen and "Delete" on the next.)
• Are destructive actions confirmed or undoable?
• Is pricing, data use and cancellation easy to find? Users who cannot find the exit stop trusting the entrance.

Score what you found: a severity rule

Without a rule, every finding feels urgent. Use this four-level scale and apply it to each row.

Level	Meaning	Action
3	Blocks the core job or loses user data	Fix this sprint
2	Slows the user or causes frequent errors	Fix within a month
1	Annoying, but the user recovers	Batch with other work
0	Preference or polish	Park it

Add one more column: effort (small, medium, large). A level 2 with small effort should usually be done before a level 3 that needs a rebuild and a plan.

The findings table

Use these columns and nothing more: #, Screen, What we saw, Why it matters, Severity, Effort, Proposed fix.

Write "what we saw" as an observation, not an opinion. "The error appears at the top of the page, 600px from the field that caused it" is useful. "The error handling is bad" is not.

Close the afternoon: pick five

At the end, sort by severity, then effort. Pick the top five and assign an owner and a date to each. Resist the urge to hand the team a list of 60 items; a list that long gets filed and forgotten.

Common mistakes

• Auditing your own work alone. You know too much. Bring an outsider.
• Skipping the user sentence. Without a defined user, findings become taste arguments.
• Fixing symptoms. If three screens have bad error messages, the fix is an error message pattern, not three rewrites.

FAQ

How often should a startup run a UX audit?

Run a small one before any major release, and again after you change the core flow. A quarterly rhythm works for most teams, since the cost is one afternoon.

What is the difference between a UX audit and usability testing?

An audit is experts reviewing the product against known principles. Usability testing watches real users attempt tasks. The audit is faster and cheaper; testing finds what the audit cannot.

Talk to us

If you want a second pair of eyes on your product, or help turning an audit into a prioritized fix list, the Rising Station team can help. Email hello@risingstation.com or visit risingstation.com/contact-us.