Most pre-launch QA covers bugs but not friction. The result is a launch that technically works and quietly underperforms. This checklist focuses on the nine usability issues that most often slip through to production, and how to test each one without recruiting real users. The recurring theme: simulate the journey, not just the unit tests.
1. Does the first-time path make sense without context?
Most teams test their product the way they built it — already knowing where every button goes. First-time users don't. They land on a page with no context and have to decide what to do.
Test the first-time path by having someone who has never seen the product attempt the primary action. Watch where they hesitate. Nielsen Norman Group's research suggests new users decide whether to continue within 10 to 20 seconds of landing — so the first screen has to do more work than any other.
2. Are loading states obvious enough?
Async operations that take more than a second without feedback feel broken. Users assume the click didn't register and try again, which either duplicates the request or breaks the state.
Make sure every button that triggers a network request has a loading state. Skeleton screens or progress indicators are strongly correlated with perceived speed even when the actual speed is unchanged.
3. Do error messages tell the user what to do?
"Something went wrong" is not an error message. It's a shrug. Every error needs to say what failed, why, and what the user should do next.
The cost of a generic error is high — most users don't try again. They assume the product is broken and leave. Spend the time to write specific error messages for the top 10 failure modes per critical flow.
4. Does the form ask for things it doesn't need yet?
Every required field reduces conversion. Most signup, checkout, and onboarding forms include fields that could be collected later, after the user has committed.
Cut anything that isn't strictly needed for the immediate action. One widely cited case lifted conversions by 120 percent by cutting fields from 11 to 4. Defer phone numbers, company names, and optional fields to a later step.
5. Is the primary CTA visible on every screen?
Users often forget what the primary action is. If the CTA isn't visible on the screen they're looking at, they assume it doesn't exist.
Walk through every screen of the critical flow and make sure the primary action is visible without scrolling. Persistent sticky CTAs help on long pages, but only if they don't fight the content.
6. Do error states for required fields fire at the right time?
On-blur validation (firing after the field loses focus) is almost always better than on-submit. Users get feedback while context is fresh, not after they've moved on.
Inline errors should also appear in a consistent place — usually right under the field. The Nielsen Norman Group recommends validating after the user leaves a field and not while they're still typing, which feels nagging.
7. Does the mobile flow actually work, or just look fine?
Most teams test mobile by looking at the responsive view. Real mobile use is one-thumb, small screen, slow network, tiny tap targets.
Tap targets should be at least 44×44 px. Inputs should never trigger zoom (use font-size: 16px minimum). Forms should use the correct keyboard (inputmode="email", type="tel", etc.). Test on a real phone, ideally with throttled network.
8. Is the empty state useful?
Most products ship empty states that say "No data yet" with no path forward. The user has to figure out what to do next on their own, which is exactly when most new users give up.
Empty states should explain what this part of the product is for, why it's empty, and exactly what the user can do next — ideally with a single clear CTA.
9. Does the flow break if a step takes too long?
Real-world sessions get interrupted. Phones lock, tabs get switched, the laptop sleeps. If a user comes back to your flow 10 minutes later, does the state survive?
Sessions, partial form data, and OAuth callbacks should all degrade gracefully. Make sure long-lived flows save state at every step, not just on submit.
How do I run this check without real users?
Going through 9 items by hand is slow and biased — you tend to skip the things you don't expect to break. The fastest way is to simulate the full flow with a stand-in user and watch where they hesitate.
Swarm sends AI personas through your product like real users and surfaces the friction across all of these checks before you ship. It works in the browser, your terminal, or as an MCP server inside Cursor and Claude Code.