UX Audit Checklist Builder

Why UX Audits Need to Be Project-Specific

A UX audit is only as useful as its checklist. Generic audits tend to reflect the reviewer's current expertise – strong on visual design, weak on performance, silent on microcopy – rather than the actual surface area of the product. A structured, project-type-specific checklist ensures you review the full system, not just the parts you find interesting. It also makes the audit repeatable: two reviewers working from the same checklist will catch the same categories of issues, even if their individual findings differ.

Different product types have fundamentally different failure modes. An e-commerce checkout that requires account creation loses 30–40% of potential conversions – that's a navigation and forms problem, not a visual design problem. A SaaS app where empty states say nothing loses users in the first session – that's a content and onboarding problem. A landing page with three competing CTAs converts at a fraction of the rate of one with a single clear action. Project-type specificity means the checklist surfaces the issues that actually cost you users, not just the issues that are easiest to see.

Use this tool as a structured starting point, not a complete standard. The priority labels (Critical / Important / Nice to have) are calibrated to typical project contexts – but your judgment still matters. A broken checkout flow is more critical than a missing breadcrumb, even if both appear in the same category. The goal is a prioritized list: Critical issues to fix before launch, Important items for the next sprint, and Nice-to-have improvements for the backlog. The audit structures your thinking; you decide what ships first.