Pre-Launch App UX Audit
An exhaustive UX teardown of your app before you launch it.
A prioritised list of UX issues (P0–P3) with severity, owner and concrete fixes.
A UX audit fails when everyone in the room already knows the product — so this council seats the End-User Advocate and the UX Researcher, who read your flows the way a first-time user does, cold. The Onboarding Specialist owns the minutes before the “aha” moment, where most launches quietly die, and the Accessibility Advocate catches the states and users the happy path forgot. The Devil’s Advocate exists to say the uncomfortable thing: that a flow everyone internally loves is confusing.
We are about to launch an app and need a brutal, exhaustive UX audit before it goes live. APP / CONTEXT: [paste your screens, flows, or describe the app — include the primary user and the one job they hire it to do] PLATFORM: [iOS / Android / web / all] TARGET USER: [who they are, their context, their tech comfort] PRIMARY GOAL OF THE APP: [the single most important outcome for the user] Debate the user experience across these dimensions, disagreeing where you genuinely see it differently: 1. First-run & onboarding — time-to-value, signup friction, the "aha" moment, do we explain too much or too little. 2. Core flows — the happy path for the primary job; every place a real user hesitates, gets confused, or has to think. 3. State completeness — loading, empty, error, offline, success, and partial/missing-data states. Flag any screen that goes blank. 4. Friction & dead ends — taps that could be removed, forms that ask too much, moments a user would quit. 5. Retention hooks — what brings them back; is the loop real or wishful. 6. Accessibility — screen-reader support, focus order, contrast, touch-target size, motion, cognitive load. 7. Cross-platform correctness — back navigation, safe areas, keyboard handling, platform conventions. 8. Information architecture — is the navigation obvious; can a new user find the one thing that matters. FINAL SYNTHESIS must deliver: - A single prioritised issue list, each item with: severity (P0 = blocks launch / P1 = fix before launch / P2 = soon / P3 = polish), the affected flow or screen, why it hurts the user, a concrete recommended fix, and a suggested owner (design / eng / product / content). - The 3 things to fix before we are allowed to launch. - Anything that is actually fine and should NOT be touched, so we do not over-engineer.
An illustrative excerpt for a hypothetical brief of this type: A two-person team is a week from launching a habit-tracking app; onboarding has five screens and sign-up comes before the user has logged a single habit. Every real run is generated fresh from your specifics, debated across rounds, and audited before the verdict.
Five onboarding screens before the first habit is logged is four too many. The user came to track a habit — let them do it on screen one and ask for the account after the first win, not before it.
Deferring sign-up sounds clean until you look at what it costs here: streaks are the retention loop, and an anonymous streak that vanishes on reinstall is a support fire waiting to happen. If sign-up moves, streak recovery must ship with it — that is launch scope, not polish.
I walked the flow as written. Nothing tells me why I am granting notification permission on screen two — I have seen no value yet, so I tap “Don’t allow”, and the product’s main re-engagement channel is dead before day one. That prompt has to move to after the first logged habit.
The empty state after onboarding is a blank screen with a plus button. With VoiceOver it reads as “button”. That is two failures in one screen — a sighted new user has no idea what the plus does either. Label it, and give the empty state one line of instruction.
Converging: P0 — move sign-up and the notification prompt behind the first logged habit, and fix the unlabelled empty state. P1 — cut onboarding to two screens. The streak-recovery risk the Devil’s Advocate raised decides whether sign-up deferral ships now or next release.
Prefer drop-and-go? Use the AI UX Audit tool — team pre-seated, included with Plus.
What do I actually paste in — I don’t have a formal spec?
Screens and honesty. Screenshots or a screen recording of the real flows, plus a sentence on who the user is and the one job they hire the app for. The council reads what you give it — the more real the material, the more specific the P0 list. A polished spec is not required; a napkin description of the onboarding is enough to start.
How is this different from just asking one AI to review my app?
One model tends to produce a polite, generic checklist — and it agrees with however you framed the question. Here five personas on different frontier models each read the flows through a different lens, then have to answer each other’s objections by name. The disagreement is what surfaces the non-obvious problems, like a retention loop that breaks when sign-up moves.
We launch in days — is a P0–P3 list going to be actionable that fast?
Yes — every issue in the final synthesis carries a severity, the affected screen, why it hurts the user and a concrete fix — plus the three things to fix before launch and, just as important, a list of what is fine and should not be touched. It is built to be worked through in an afternoon, not admired.