How to prepare for a UX audit

Write a short problem brief

You don’t need a long document. Half a page is plenty. Cover the product, who uses it and the task you want to improve. Then explain what prompted the review: recurring support questions, an upcoming release, conflicting feedback, or a workflow that’s become painful to maintain.

Keep it specific enough to guide the work without prescribing the answer. “Operations managers review and approve requests, but ownership gets lost when a request is sent back for changes” is a great brief. “Modernise the approval dashboard” isn’t. The first describes a task and a problem. The second jumps straight to a visual solution.

Gather the evidence you already have

Pull together relevant research notes, support themes, product feedback and analytics. For each, add the date, who it’s about and the context. A study of new customers might not explain how experienced users behave. A report on an old version might describe a problem that’s already been fixed.

Please don’t spend days building a presentation for the reviewer. A folder with a short index is enough. Strip out personal or confidential information you don’t need to share, and agree how materials will be shared, used and deleted afterwards. Don’t send real customer records just because they’re handy examples.

Give the reviewer a realistic way in

Arrange access to the agreed screens and states. A test environment with realistic but made-up data beats a folder of screenshots almost every time. Let the reviewer know where it differs from the live product. If you can only share a prototype, say which parts are simulated.

Prepare at least one realistic task scenario: what the user knows before starting and what they’re trying to achieve. Don’t write step-by-step instructions telling the reviewer where to click, because that hides the very discoverability problems you want found. Keep the business rules in a separate document so they can be checked when needed.

Line up the people and the constraints

The reviewer needs someone who understands the workflow and someone who decides what happens after the findings. Often they’re different people. Agree how questions will be answered and which review points need product, design or engineering in the room.

Write down the constraints that could shape recommendations: release dates, accessibility requirements, integrations, permissions, contractual limits. Then separate the real constraints from the assumptions. “We’ve always done it this way” isn’t a technical restriction, and it’s worth saying so out loud.

Confirm the boundaries before you start

A final check before day one:

• One agreed workflow, role and device.
• A clear start point and finish point.
• Access to the included screens and the states that matter.
• Existing evidence, labelled by source and date.
• Known constraints and open questions.
• A decision owner and a date for the walkthrough.
• Agreement on deliverables and how follow-up questions work.

Our UX Audit takes two weeks: scoping on day 1, the review on days 2–8 and a walkthrough on day 10, followed by one round of follow-up questions. User research, detailed redesign and implementation are separate unless we agree otherwise. Getting those boundaries clear early makes the whole thing easier to run and the output easier to use.

Not sure which workflow to pick? Send us a few lines about the product and the task. That’s a better starting point than trying to write the perfect brief.