Back to selected work
5Case Study · Saas

UX Audit ScannerIterating the audit user flows.

The brief

How a single, brittle “paste-and-wait” scan became a multi-track, role-aware system that converges on one trustworthy results experience.

Year2026
IndustrySaas
ClientUX Audit Scanner
Project DurationOngoing
01Context

A scanner is only as good as the flow around it.

UX Audit Scanner runs accessibility, IA, content, and interaction audits on real websites and SaaS apps. The hard problem isn’t the scan engine, it’s the human flow wrapped around a slow, expensive, asynchronous process whose output looks intimidating by default.

Users are a mix: in-house UX leads triaging a release, accessibility owners working to a compliance deadline, agencies pitching a redesign, and public-sector teams under ADA Title II. Each one needs a different framing, but only one results experience is sustainable to build.

The Starting Flow (v0)

One path, one audience, one outcome - abandonment.

The earliest product was a single linear path: paste a URL, watch a spinner for a minute or two, then receive a long, undifferentiated wall of findings. It technically worked. It didn’t convert.

Fig. 01 · v0 flow
Diagram — v0 flow with the three places it leaked users.
02Research signals

What the data and the inbox were telling me.

  • Mid-scan drop-off. Session replays showed a cluster of users closing the tab between 25 and 90 seconds in, the “is it still running?”window.
  • Repeat scans of the same URL. Users would re-paste the same site, suggesting they didn’t trust that the first run had finished or had captured everything.
  • Wrong framing for SaaS apps. Findings that scored well on a marketing page told an authenticated dashboard nothing useful. Users asked, in plain English, “but did you actually log in?”
  • Public-sector requests. ADA Title II teams wanted deadline framing and EN 301 549 / Québec parity coverage out of the box, not as configuration.
  • Support inbox patterns. The most common ticket wasn’t a bug — it was “what am I supposed to do with this?”

These weren’t five different problems. They were one problem: the flow assumed a single archetype of user with infinite patience and full context. Real users had none of that.

03Iteration 1

Launcher split & progressive disclosure.

The first move was to split intent up front. One launcher became three deliberate tracks, public, authenticated (Atrium), and interaction-heavy (Kinesis), each with its own pre-flight, but every track converging on the same results shell so users only had to learn one mental model.

At the same time I shipped a unified progress system: queue position, current step, and an honest ETA replaced the spinner. The wait didn’t get shorter; it stopped feeling broken.

Fig. 02 · Intent picker → orchestrator → results shell
Diagram — intent picker fans out, orchestrator funnels back, everyone lands in one results shell.
04Iteration 2

Jurisdiction & role context, up front.

Splitting the launcher exposed a deeper assumption: the v0 flow treated every site as if it lived in one legal and product context. It didn’t.

  • Jurisdiction at launch. Users pick US (ADA / WCAG 2.1), EU (EN 301 549), Québec (French parity), or UK (PSBAR) before the scan starts, so the rule pack, severity promotion, and Title II framing are correct from second one.
  • Saved Atrium credentials. Re-entering login was the single most painful re-step. One-shot encrypted credentials let users re-run an authenticated audit in two clicks.
  • Sitemap import. Users no longer had to manually queue every URL on a SaaS app, a single sitemap paste seeds the run.
  • Smart defaults for first-timers. For brand-new users, the picker collapses behind a sensible default with a one-line “why this jurisdiction” explainer, so the form doesn’t intimidate.

Net effect: by the time the scan starts, the system already knows enough to give results that read as for you, not as a generic dump.

05Iteration 3

Results flow from dump to decision.

The wall of findings was the next bottleneck. I rebuilt the results surface around a strict, four-tab architecture and a single card pattern that scales from skim to deep-dive without changing skin.

  • Summary first. One health score, three to five opportunities, and an AI-written “success vision”that frames what changes if the top items ship.
  • Clarity Card pattern. Every finding has a collapsed triage view and an expanded evidence view, same card, two states.
  • Hide, don’t destroy. Dismissals are reversible, and AI-generated context is preserved, so pruning never costs credits.
  • Action Plan as the bridge. Findings re-rank by ROI (impact × reach ÷ effort) so users always know what to fight for first.
06Iteration 4

Closing the loop with Atelier.

A report is a one-shot artefact. A loop is a product. Atelier turned each finding into a closeable item: ask for a fix, verify it on the live page, re-score the audit, all without consuming user credits on the automated re-run.

Fig. 04 · Atelier loop
Sequence — per-finding solutions, cluster-mode policies for systemic issues, and an optional Playwright verification that feeds straight back into the audit.

The behavioural change was real: people stopped treating the audit as a deliverable they exported and forgot, and started treating it as a backlog they worked through.

07System view

Four entry points. One shell. Many destinations.

Zooming out, the user-flow story is the shape of the system itself: four ways in, one orchestrator that handles jurisdiction, queue, and progress, one results shell, and several downstream actions, export, AI solutions, monitoring for regressions, and a Title II workspace for public-sector teams.

Fig. 05 · System map
System map — the surface a user navigates is small; the work behind it isn’t.
08What I’d cut

The iterations I’m least proud of, kept on the record.

  • Kinesis as a separate launcher. It made sense engineering-wise, Playwright is a different beast, but users didn’t want a third front door. I folded it back into the main flow as an opt-in checkbox; the standalone route now redirects.
  • A jurisdiction picker that was too prominent. First-time users read it as a quiz they could fail. I changed it to a smart-defaulted disclosure that’s honest about what it does, without blocking the path.
  • A synthetic element preview. The Issues tab once tried to re-render captured HTML with a hand-rolled parser. For icon-only or fragment markup it produced empty pills, worse than no preview at all. I replaced it with a sandboxed iframe of the real captured markup plus a screenshot crop of the live element. The principle: visual evidence must be 1:1 with the claim, or it shouldn’t exist.

Honesty about what I’d cut is part of the same design rule that runs through every other iteration: the product’s job is to deserve the user’s trust, not to demand it.

09Outcomes

Where the numbers moved.

Ranges below are illustrative — directional estimates derived from session replays, support-ticket review, and pre/post comparisons on the same accounts. They are not controlled measurements.

Mid-flow abandonment− ~30–45%Driven by intent split + honest progress.
Time to first actionable finding− ~40%Summary tab + ROI re-ranking.
Repeat scans per audit− ~25%Saved creds, sitemap import, no-cost re-runs.
Free → authenticated conversion× ~2Atrium track made the value visible.
“What do I do with this?” tickets− ~50%Action Plan + Atelier closed the loop.

Behind the numbers, the bigger shift was qualitative: users started using the product as a workspace, not as a one-off scanner.

10Principles I keep

Five rules that survived every iteration.

01

Trust > completeness.

A smaller, defensible finding beats a longer, speculative one. If we can’t ground it in structural or visual evidence, we don’t ship it.

02

Honest empty states.

If the system has nothing to show, it says so. A fake render is worse than none.

03

Progressive disclosure beats hiding.

Two-state cards, collapsed-by-default sections, and a single canonical detail surface mean the UI is never both shallow and overwhelming.

04

Every flow converges on one results surface.

Four entry points, one shell. Learn it once, use it everywhere.

05

Visual evidence is 1:1 with the claim.

If a card says “low contrast in the hero,” the screenshot must show the hero and the contrast, not a generic page thumbnail.

Thanks for reading

Patrick Cayer

Founder & Designer · UX Audit Scanner

Stack: React, Tailwind, Supabase, Playwright, AI Gateway (Gemini / GPT-5).

Patrick Cayer

Senior Product Designer

Hand-built with care. Thoughtfulness in every touch point.

Right now

Raleigh · --:--

© 2026 Patrick Cayer
Private · Under NDA

This case study is gated.

Enter the password shared with you to view the full work. If you don't have one, reach out and I'll send it.

Your unlock is remembered on this device.

Request access →