Case Study · Product Designer & Builder

Omnis UX Audit Engine — a day-long chore, automated.

I turned a manual, screen-by-screen design review into an engine that logs into any web product, audits every state, and ships developer-ready annotated reports — at ~$0.30 a screen, versus hours of a senior's manual review.

Muzeeb Urrahaman Solo designer + builder Jun – Jul 2026 v5.0

229

Deterministic checks

342

Audit rules

AI skill packs

187

Passing tests

~27k

Lines of TypeScript

90%+

Element-grounded

In one line

Point it at a product URL with credentials, and it logs in, walks every screen, clicks through to every interactive state, and produces a self-contained report — one clean numbered box per problem.

At Omnis AI I was the solo product designer across five legal-tech products, asked to manually audit our live staging apps screen by screen. That's slow, inconsistent, and doesn't scale — so instead of doing it by hand forever, I built the thing that does it for me. The non-negotiable principle that shaped everything: findings must be grounded in the real DOM, not guessed.

The signal, from being the bottleneck myself: auditing those five products by hand, the issues I consistently missed were the hidden states — modals, error and empty screens I simply forgot to open. That finding, not a spec, is why exhaustive state exploration — clicking every control and auditing each resulting state — became the engine's first-class job rather than a nice-to-have.

Problem

Manual audits were slow, inconsistent & didn't scale across 5 products.
Interactive states (modals, errors, empty) quietly got skipped.
Every fix meant redoing the whole review by hand.

Solution

Point it at a URL — it logs in, walks every screen & state.
Applies UX + content lenses, grounded in the real DOM.
Outputs annotated reports — one numbered box per problem.

Results

~$0.30 & ~3 min per screen vs ~$400 & hours.
Every state clicked & captured — provable coverage.
Handoff with exact selector + copy-paste fix.

The workflow

Before → After

How the workday changed.

The whole project is really a story about a broken workflow and the one I replaced it with.

Before · manual — a day+ per product

Open each staging screen, one at a time
Screenshot, paste into Figma, hand-draw boxes + notes
Try to remember modals, dropdowns, error & empty states (usually skipped)
Export images, field "which element?" questions
After every fix → redo the whole pass from scratch

After · the engine — ~3 min per screen

Run one command: audit <url> <credentials>
Logs in → walks every screen + state → analyzes
Grounds each finding on a real element → annotates → builds report
Developer opens a finding → exact selector + copy-paste fix
Re-audit after a fix = one command

Dimension	Before · manual	After · the engine
Time per screen	~2–3 hrs of a senior's day	~3 minutes
Cost per screen	~$400	~$0.30
Interactive states	Usually skipped	Every state captured
Consistency	Varies by reviewer	Identical, rule-based
Coverage record	None	"N elements, 0 skipped"
Dev handoff	Static image + Q&A	Selector + copy-paste fix
Re-audit after a fix	Full manual redo	One command; shows deltas

User flow — the manual audit (top, red) vs the engine (bottom, green). The manual loop redoes the whole pass after every fix; the engine re-audit is a single command.

Before — a real manual annotation, marked up by hand, one note per issue.

After — the same review inside the engine: annotated screenshot + grounded finding cards.

The product

What it does today.

Because it has live access — not just a static screenshot — it:

Logs in automatically (reuse a saved session → scripted login → AI fallback).
Captures each screen as a full-page screenshot + complete DOM inventory, and runs the axe accessibility engine live.
Explores states — clicks every button, dropdown, modal, filter & tab; one dashboard expands into 8+ states.
Analyzes on two tracks: deterministic checks (zero-cost, zero-hallucination) and AI skill packs (the right lenses per page type).
Validates — dedups, grounds every finding on a real element, gates out false positives, routes copy to a Content track.
Resolves — CSS-fixable issues auto-applied with before/after proof; everything else stays a recommendation, never faked as fixed.

State explorer — one screen expands into many; the engine clicks every control and audits each resulting state.

Anatomy

Every issue is one card — and that card is the product.

Each finding carries a severity chip for triage, the category + rule ID so it traces to the exact rule that fired, a plain-English title, a Why → How → Impact reasoning chain that names the exact principle, a copy-paste Fix, a confidence score, and a Copy-as-markdown button. A finding missing any of these is rejected before it reaches the card.

Anatomy of a finding card — a real COPY-007 finding with every field labelled.

The stack

Two codebases.

The engine (ux-audit-mcp) does capture + analysis. The service (ux-audit-service) turns it into a multi-product dashboard with CI.

Layer	Technology
runtime	Node + TypeScript, Model Context Protocol (MCP) SDK
capture	Playwright — login, full-page screenshots, DOM inventory, state exploration
a11y	@axe-core/playwright — the axe engine, live per page
ai-vision	OpenAI-compatible SDK → Gemini Flash / OpenRouter (multi-provider + fallback)
image	Sharp (annotation), tesseract.js (OCR snapping), pixelmatch (diff)
service	Next.js 16, React 19, Tailwind 4 · Prisma 7 + Postgres · BullMQ + Redis · GitHub Actions · Docker

User scenarios

One audit, six people.

A deliberate product decision: the same underlying findings are presented six ways so each role gets exactly what it needs.

Product Designer (me) — a pre-release skim by severity; rejecting a false positive turns it into a permanent rule.
Frontend Developer — opens a blocker and gets the exact selector, offending HTML, and a copy-paste fix with before/after proof.
QA Engineer — the State Explorer catches hidden-state bugs a manual pass over the default screen never sees.
Content writer — a separate Content track: current text in red, a suggested rewrite in green, a Copy button.
Engineering Manager — a fleet dashboard + a CI gate that blocks any PR introducing a new blocker.
Leadership — coverage proof and before/after tracking: evidence products are measurably improving.

The Content track — copy issues audited separately, each rewritten to UX-copy standards.

The product index — every screen in one scorecard with severity, state & element counts.

The fleet dashboard (the Next.js service) — every product's UX health, severity & last run in one view.

The hard parts

Decisions that make it trustworthy.

Anyone can draw a box on a screenshot. The judgment is in making the report trustworthy.

Grounding in the real DOM — an accuracy stack (grid coords, OCR + DOM snapping, crop verification) maps every finding to a real element's bounding box. Ungroundable findings are rejected → 90%+ element-grounded.
Deterministic certainty vs AI opinion — 229 hard-coded checks handle everything objective at zero cost; AI is a second lens only for subjective judgment.
Designing for AI trust — every AI finding names a principle/WCAG criterion, carries a confidence score, grounds to an element, and passes a four-question false-positive gate. Reviewer corrections become permanent rules.
Honest resolution — CSS-fixable issues get before/after proof; everything structural is a "recommendation," never faked as resolved.
Trust over volume — v5.0 consolidated 400+ rules to 342 high-signal ones; no rule ships above a 10% false-positive rate on a real product.

Results

Proven on real products.

CaseNotes (our own staging app): an early 4-screen audit found 89 issues across 22 interactive states in ~11 minutes for ~$1.20 — 35 deterministic, 45 AI, 22 content, across 1,035 elements; 26 auto-fixed; dedup removed 800+ duplicates. AutoDoc: 87 findings (4 blocker, 26 major, 42 minor, 12 nit, 3 praise). Also proven on public logins — GitHub (29) and Vercel (26).

It designs its own edge states, too: a clean "0 issues found" report when a screen passes, and a login-failure path that falls back to a saved session or scripted login instead of erroring out — the same reality-first standard it audits others against.

$0.30

per screen, in ~3 min

Measured API + compute cost. The manual alternative is ~half a senior's day per product — my estimate at contractor rates (~$400), not a billed figure.

100%

state coverage, provable

Every interactive state clicked & captured — "N elements, 0 skipped."

90%+

findings element-grounded

Every box sits on a real DOM element — never floating near it.

Export

A finding is only useful if it can leave the tool.

The engine exports a complete audit as a self-contained HTML file and clean Markdown (paste into a PR or ticket), and rolls every screen into one product dashboard. A verbatim excerpt from the Markdown export:

**1. Low contrast on div "Profile": 1.3:1 (need 4.5:1)**
- Why: Insufficient text contrast makes content hard to read.
- Impact: Users with low vision cannot read this → WCAG non-compliance.
- Fix: Increase contrast to at least 4.5:1.
- rule: DET-CONTRAST-001 · WCAG 1.4.3 (AA) · confidence: 1
- div.sidebar-footer-profile.expanded

The product-audit dashboard — a 6-screen sweep: 209 issues & 16 working-well findings in one health view.

The self-contained HTML export — scorecard, per-screen summary & severity-grouped cards in a single file.

Reflection

Why it matters

Not a "designer who also codes a bit" story.

It closes the design → build loop most designers never close — so I learned the things only visible once it's real: the bottleneck was trust, not coverage; a box one pixel off destroys credibility; "acceptance %" is a vanity metric.

It's evidence of judgment, not pixels — problem-framing, explicit trade-offs, a defined success metric, and the versions I killed. It's systems thinking across states, flows, failure modes and six user roles, with craft in service of trust.

The version I killed: an early build analysed static screenshots only. It confidently flagged elements that weren't really there — so I rebuilt it around live DOM access. Every finding now has to point at a real element or it doesn't ship. That single constraint is why the reports are trustworthy, and it's the whole reason "grounded in the real DOM" became the non-negotiable.

The maturity is in the honesty. I score the engine at ~5.5–6/10 — a strong, genuinely working tool that competes with a manual audit on coverage, but not a validated GA product. Staging went down and I was laid off, so I no longer hold the login needed to finish the live baseline. Everything up to that line — the design, architecture, ~27,000 lines, 187 tests — is done and demonstrable.

What I'd do differently: build the measuring stick first. I spent early weeks adding rules because progress felt fast, then realised the real bottleneck was trust, not coverage. For any AI product, decide how you'll measure "good" before you build it — volume is easy, trust is the hard, valuable part.

Leverage, not just output: the engine became the audit method across all five Omnis products, and one run serves six roles — design, PM, three engineering disciplines and leadership — off a single grounded report. The work compounded past my own hands, which is the point.

Interview brief

Anticipated questions

The things hiring managers probe for.

Are you a designer or a developer?

A product designer first — research, UX, UI, design systems are my core. The building is what makes me unusual: I can take a design decision and ship the working thing myself instead of waiting for a handoff. This tool is the proof.

What was your specific contribution vs. engineers?

There were no other engineers on it — I was solo. I owned the problem framing, the design, the architecture, and every line of the implementation.

How do you stop the AI from hallucinating findings?

The objective stuff never touches AI — 229 deterministic checks handle it. Every AI finding must ground to a real DOM element or it's rejected, must name a specific principle/WCAG criterion, and must pass a four-question false-positive gate. Reviewer rejections become permanent rules.

How is this different from axe-core or Lighthouse?

Those see one static page and cover mostly automated accessibility. This logs in and clicks through the product to audit every interactive state, combines deterministic checks with AI design judgment, grounds every finding on a real element, and outputs annotated screenshots plus copy-paste fixes — not just a score. It uses axe-core inside it as one of many inputs.

How did you measure success?

Absolute human-confirmed useful findings per screen. I deliberately rejected "acceptance %" because you can game it by shrinking the denominator. No rule shipped without a measured false-positive rate on a real product.

Could you take it to production?

Yes — the roadmap is written: a live baseline, multi-product validation, a fix-verification loop, and deploying the dashboard service with inline review and continuous monitoring.