ux-audit

• Audit asks: does this match a bar?
• Extract asks: what is the bar?

• Before building a new feature — study how best-in-class apps handle it
• Benchmarking a build — extract the reference, then audit against it
• Onboarding designers or engineers — here's what good looks like, concretely
• Competitor research — document the competitor's UX so you can meaningfully differentiate
• Refreshing an old app — extract patterns from modern equivalents to guide the update

1. Use your own account — don't scrape anything that requires credentials you don't legitimately hold
2. Respect

   robots.txt

   for unauthenticated crawling
3. Rate-limit — act like a human user, not a crawler. Pause between pages.
4. Check ToS — most SaaS Terms of Service permit individual inspection but prohibit automated scraping
5. Don't redistribute screenshots of a live competitor's app publicly — pattern libraries are internal references

• Whole app — traverse everything reachable (can take hours, produces a comprehensive library)
• Feature area — one section ("the settings flow", "the dashboard", "the billing flow")
• Pattern class — just empty states, just error handling, just onboarding

• "Focus on patterns for data-heavy lists" — prioritise table, filter, search, virtualisation screenshots
• "Focus on onboarding and empty states" — prioritise first-run flows and zero-data views
• "Focus on permission boundaries" — log in as multiple roles, document the differences

1. Public sitemap — check

   /sitemap.xml

   ,

   /robots.txt

   for discoverability
2. Nav crawl — click through every section visible in the top nav, sidebar, footer
3. In-app discovery — once inside, note every link that appears (breadcrumbs, tabs, contextual menus)
4. URL inspection — some apps have useful patterns in

   /settings

   ,

   /preferences

   ,

   /admin

   that aren't in the main nav

/settings/billing — subscription plan, payment method, invoice history

• Wayfinding (nav, breadcrumbs, current-location, back)
• Lists & tables (row, hover, action reveal, selection, sort, filter, paginate, empty)
• Forms (label, validation, error, required, inline help)
• Modals & dialogs (trigger, focus, escape, scroll, confirm)
• Feedback (toast, inline, progress, loading, saved)
• Onboarding & empty states (first-run, zero-data CTA, guided tour)
• Permissions & roles (restricted views, denied-access, role indicators)
• Copy & microcopy (buttons, headings, errors, placeholders, tooltips)
• Keyboard (shortcut sheet, focus, tab order, command palette)
• Motion (transition, reveal, loading, gesture)
• Responsive (breakpoints, mobile-specific: bottom sheet, tabs, swipe)

• Button labels:

  "Start chat"

  ,

  "Upgrade plan"

  ,

  "Delete forever"

• Empty states: "No conversations yet. Start one to see it here."
• Error messages: "We couldn't save that change. Try again, or contact support if it keeps happening."
• Confirmation dialogs: "Delete this project? All 14 tasks and 3 members will be removed. This cannot be undone."
• Placeholder text:

  "e.g. smith@company.com"

• Tooltips:

  "Pressing Cmd+K opens this from anywhere"

• Trigger: click / hover / keyboard / long-press / drag
• Target: what it affects (opens modal, filters list, navigates)
• Feedback: immediate visual response? delayed confirmation?
• Reversibility: undoable? destructive?

• Shortcut sheet: is there a

  ?

  or

  Cmd+/

  that reveals the shortcut list? Capture it.
• Command palette:

  Cmd+K

  or similar? Capture the palette open, searching, a result selected, and an action executed.
• Focus indicators: tab through the page, note the ring style, colour, thickness
• Tab order: is it logical? Any unexpected jumps?

• Navigation moves from sidebar to hamburger at [breakpoint]
• Table collapses to stacked cards at [breakpoint]
• Modal becomes full-screen at [breakpoint]
• Multi-column form becomes single-column at [breakpoint]

gif_creator

• Page transitions
• Modal enter/exit
• List item enter/exit
• Loading → loaded
• Success animations (confetti, checkmarks)
• Drag-and-drop feedback

• Same row pattern on 5 list pages → one "list row" entry with a note "used on: /clients, /projects, /invoices, /reports, /team"
• Same empty state layout with different copy → one "empty state" entry with copy variants listed
• Same modal chrome → one "modal" entry; specific modals listed as usages

• Occurrences — how many times this pattern appears
• Variants — meaningful differences (icon vs no icon, small vs large, with CTA vs without)

docs/ux-extracts/<app-name>/

.jez/artifacts/ux-extracts/<app-name>/

docs/ux-extracts/claude-ai/
├── pattern-library.md      ← main document
├── copy-corpus.md          ← optional, raw copy by page (for writers)
└── screenshots/
    ├── 001-home-default.png
    ├── 002-home-hover-cta.png
    ├── 003-new-chat-empty.png
    └── ...

• Navigable — table of contents at the top, jump links to every section
• Cross-referenced — "see also: Modal Chrome"
• Screenshot-dense — every claim backed by a referenced screenshot
• Copy-accurate — verbatim text in code blocks or blockquotes, not paraphrased
• Honest — note what's missing or weak as well as what's good. A reference library isn't gospel.

ux-audit

.jez/artifacts/ux-extracts/<ref>/pattern-library.md

docs/ux-extracts/<ref>/pattern-library.md

"Empty state on /app/clients has no explanatory copy and no CTA. Reference library [claude.ai § Empty States] shows CTA + 2 example prompts in the same position."

• Just do it: Navigate, screenshot, copy text, inject JavaScript to read computed styles, download static assets (logo, icons) for reference
• Ask first: Any login that requires credentials the user hasn't authorised you to use, any scraping of a site where ToS or rate limiting is ambiguous
• Stop and confirm: If the target has a login wall and you don't have clear authorisation, stop and confirm before proceeding

• Screenshots are cheap — capture generously. Easier to drop a screenshot from the library than to rerun the extract to get one.
• Capture copy the moment you see it — don't plan to come back; come back and it'll be behind a different state.
• Note what's absent — if an app has no keyboard shortcut sheet, that's a pattern decision worth documenting too.
• Separate observation from evaluation — extract records what exists, not whether it's good. Opinions belong in an audit, not an extract.
• Extracts decay — apps change. Timestamp the library, link to the date on archive.org if possible, plan to re-extract every 6–12 months for apps you compare against often.
• Build incrementally — open the library file at the start, append as you go. Don't try to structure it all at the end.