SaaS UX Audit

# SaaS UX Audit

## Why this skill works the way it does

A UX audit is only useful if it's grounded in who the product is actually for and ends in things a team can act on. Two generic-audit failure modes to avoid: (1) treating every product like it's for the same audience — an issue that's a shrug for a power user can be a blocker for someone who rarely uses software, and the fix is often different too (simplify the interface vs. add a bit of contextual help); (2) producing a report full of "the UI feels dated" observations that nobody can turn into a sprint. This skill is built to avoid both: it starts by establishing who the audience is, works through the entire product surface systematically rather than a few screens someone happened to click, and ends every finding as something assignable — severity, evidence, a concrete recommendation, and (where possible) an actual ticket.

This is framed as a **one-time, comprehensive** audit, not a lightweight periodic check-in. Default to thoroughness over speed. If the product is large, it's fine to sample deeply within a feature category rather than click every single sub-page (say so in the report), but never silently skip a whole category from the checklist in Step 2.

Work through the steps below in order. Don't skip Step 0 — everything downstream (what counts as a problem, how severe it is, what the fix should be) depends on it.

## Step 0: Intake

Before looking at anything, get context. If an interactive question tool is available, use it for the multiple-choice-friendly parts; free-text works fine too. Explain briefly why you're asking — this isn't throat-clearing, it materially changes the audit:

1. **Target audience & digital fluency.** Who uses this product? How comfortable are they with software generally — e.g. "developers", "small business owners who mostly live in email and their phone", "a mix of tech-savvy admins and non-technical end users"? Are there distinct personas or roles (admin vs. member, free vs. paid, new vs. power user) that might experience the product differently? This directly shapes severity ratings later — see Step 3.
2. **What the product does.** A one- or two-sentence description of the core job the user is trying to accomplish, so findings can be judged against real intent rather than assumptions.
3. **What business outcome this audit should serve.** Ask directly: is the priority reducing churn, improving trial-to-paid conversion, cutting support ticket volume, driving expansion/upsell, or something else? A finding is far more persuasive and easier to prioritize when it's tied to "this is likely costing you trial conversions" rather than described in usability terms alone — use this in Step 4/5 to frame recommendations, not just to describe them.
4. **Known pain points** (optional but valuable). Any existing complaints, recurring support themes, or hunches about weak spots.
5. **Available data** (optional but valuable). Analytics/funnel data, support ticket exports, NPS/CES scores, or user interview notes. If provided, use it in Step 3 to weight severity and prioritization — findings that line up with real drop-off points or common tickets are higher-confidence. If nothing is available, proceed on heuristic evaluation + walkthrough alone, and note in the final report that adding this data would sharpen future audits.
6. **Access** — see Step 1.

Don't treat this as a rigid form. If the user has already given some of this in conversation, don't re-ask it — just fill the gaps.

## Step 1: Get access to the product

Try these in order, and tell the user which one you ended up using and why — don't silently downgrade to a weaker option without saying so.

1. **A connected browser-control tool, if available (preferred).** Check whether the user has a browser-automation tool connected (e.g. a "Claude in Chrome"-style connector, or an equivalent browser bridge). If so, ask the user for the login URL and to sign in themselves in that connected browser tab — you never need or want their real credentials — then drive that authenticated tab to browse the live product. This is the best option: real screens, real data, real logged-in states.
2. **Sandboxed browser + test credentials.** If no connected browser tool is available, ask for a URL and test/demo credentials as part of intake — ideally for more than one role (e.g. a fresh trial account and an admin account) so you can see onboarding as well as an established account. Use whatever local browser tooling is available (e.g. Playwright) to navigate and screenshot.
3. **User-provided screenshots or a screen recording.** If live access isn't possible (no test account exists, data is sensitive, etc.), ask the user to walk through the checklist in Step 2 and provide full-page screenshots or a recording — specifically ask for expanded menus and settings pages, not just the default dashboard view, since those are the parts people forget to capture.
4. **Description-only, last resort.** If none of the above work, interview the user flow by flow. Flag clearly in the final report that visual and consistency findings are limited without direct access, since word-of-mouth descriptions miss inconsistencies the person giving them has stopped noticing.

## Step 2: Work through the full surface

Read the attached `audit-checklist.md` for the complete list of areas to cover (registration, login, transactional emails, onboarding, dashboard, navigation, every core feature, empty states, account/billing settings, notification settings, team/permissions, help/support, error and edge states, accessibility, responsive behavior, component and copy consistency). Go through it systematically rather than free-clicking — it's easy to spend an hour on the dashboard and forget the password-reset email exists.

As you go, capture evidence (a screenshot, or a precise description of what you saw) for anything you flag — findings without evidence are much less useful to a team trying to verify and fix them.

## Step 3: Apply the methodology

Combine two lenses across everything you looked at in Step 2:

- **Heuristic evaluation** — evaluate each screen against an established framework rather than personal taste. Read the attached `heuristics-and-severity.md` for Nielsen's 10 heuristics and how to apply them.
- **Cognitive walkthrough** — separately, walk through the 4-6 journeys that matter most as an actual task, start to finish, rather than just admiring screens: sign-up to first value, the core thing this product's users do daily/weekly, upgrading a plan, inviting a teammate (if applicable), and canceling/downgrading. Walkthroughs surface friction that screen-by-screen review misses, because real tasks cross multiple screens.

**Mitigate the evaluator-effect.** Research on heuristic evaluation (Nielsen's own studies among others) consistently finds that a single evaluator doing one pass typically catches only around a third of the usability problems actually present — different evaluators notice different subsets, which is why professional practice aggregates multiple independent passes rather than trusting one. Comprehensive checklist coverage helps but doesn't fully substitute for this. So: if it's possible to run more than one independent evaluation pass through the same product (e.g. one pass reasoning explicitly as the least tech-savvy persona from Step 0, a second pass reasoning as a power user or efficiency-focused persona), do at least two and reconcile the two sets of findings rather than merging them unreflectively (agreement between passes is a strong signal; disagreement is worth a closer look, not an automatic tiebreak). If only a single pass is feasible, say so plainly in the final report and note that supplementing this audit with a small round of real user testing would catch problems a single expert pass structurally can't.

**Consider competitive context where it sharpens severity.** If a flow is markedly more effortful than how category-standard competitors handle the same task (e.g. "competitors let users do this in one click, this product takes five steps across three screens"), note that comparison — it's often the most persuasive argument for prioritizing a fix, and it's a legitimate severity signal, not just an aesthetic preference. Don't force this for every finding; use it where a clear, well-known comparison exists.

Then weight every finding through what you learned in Step 0:

- **Tag each finding with which persona(s) it affects**, and let audience fluency change the severity — something that mildly annoys a power user (e.g. no keyboard shortcuts) can be minor for a rookie-first product, while something a power user would shrug off (unfamiliar iconography, a non-standard interaction pattern) can be a real blocker for a less confident audience, because that group leans much more heavily on recognizing patterns from other apps they already know.
- **Distinguish domain education from interface education.** If users need to learn a concept from their field to use the product (legitimate — recommend contextual help or docs), that's different from users needing to learn how the interface itself works (usually a sign the interface should be simplified, not explained more). Recommend fixing the interface over adding more tooltips when it's the latter.
- **Cross-reference with any data from Step 0.** If a finding lines up with an actual drop-off point in analytics or a recurring support ticket theme, say so explicitly and treat it as higher-confidence — this is what turns "I think this is confusing" into "this is confusing and it's costing you X."

## Step 4: Write up findings

For every finding, capture: screen/flow, issue, frequency (how often users encounter it), impact (how bad it is when they do), severity (Blocker / Major / Minor, derived from frequency × impact — see the attached `heuristics-and-severity.md`), affected persona(s), evidence, a concrete recommendation (not just "improve this" — say what to change), and a rough effort estimate (S/M/L). Findings without a clear recommendation aren't done yet — push past "this is confusing" to "do X instead, because Y." Where it's a reasonable inference, note which business outcome from Step 0 the finding likely affects (e.g. "likely contributing to trial drop-off" vs. "unlikely to move the needle on churn, but worth fixing for support burden") — this is what makes the prioritized list in Step 5 persuasive rather than just a severity sort.

## Step 5: Deliverables

Produce two things:

**1. A narrative report** (Markdown, or a Word doc if the user wants something more formal/shareable). Structure: executive summary (a few sentences on overall state and the 3-5 things that matter most), methodology and scope (what was covered, what access method was used, any areas sampled rather than exhaustively covered, and whether one or multiple evaluation passes were done — include the single-evaluator caveat from Step 3 if only one pass was feasible), then full findings grouped by the areas in the checklist, each with frequency/impact/severity/persona/evidence/recommendation/effort and, where relevant, which business outcome it likely affects. Close with a prioritized top-N action list ordered by severity, effort, and business outcome together — not severity alone — a Blocker that takes five minutes to fix belongs above a Major that takes three weeks, and a Major tied directly to the business outcome named in Step 0 belongs above a Blocker that's real but low-stakes for that goal.

**2. Tickets in the user's project-management tool.** Check what's available for a PM connector (Nifty, Asana, Jira, Linear, etc). If exactly one is connected, confirm with the user which project/board the tickets should land in before creating anything. If more than one is connected, ask which to use. If none is connected, say so plainly in the report and offer to export the findings as a CSV the user could import instead, rather than silently skipping this half of the deliverable. When creating tickets: one ticket per Blocker or Major finding at minimum, each carrying the severity, evidence, and recommendation from Step 4 (use labels/tags for severity and area if the tool supports them); batch Minor findings into a single "polish" ticket per area unless the user says they want them split out individually.

Before creating a batch of tickets, show the user a short summary of what you're about to create (count, and a few examples) and get a go-ahead — this avoids flooding their board with dozens of tickets they didn't expect.