Client-Ready UX Teardown for Agencies (Bill It Like a Deliverable)

October 29, 2026

A client-ready UX teardown is a structured report a stakeholder can open without an account: funnel and friction, segment breakdown, key-moment screenshots, and plain-language findings tied to design intent. Boidwatch flies Census-derived personas through the page in real Chromium sessions and composes that report with a public share link. Agencies can run it at kickoff—product positioning on boidwatch.com frames a flock that can land before a kickoff call ends, versus a specialist audit at “four figures / three weeks”—then bill it as a deliverable rather than burying it in hours. Treat it as directional behavioral evidence that complements, not replaces, human research when the engagement requires it.

What “client-ready” actually means

“Client-ready” is not a zip of session recordings. It is an artifact a founder or stakeholder will open and skim without coaching.

That means:

A public link — no client account, no invite, no “log into our tool”
Stakeholder language — ranked findings against design intent, not raw telemetry
Funnel + friction + segments — enough structure that the report can sit in a kickoff deck or SOW appendix
Key-moment screenshots — proof of where archetypes stalled, not a vibe summary of the HTML

Heatmap dumps and LLM page reads fail that bar. A heatmap shows where someone stared; it does not explain whether a Census-weighted stranger could complete the job the page was built for. An LLM summary of the markup guesses how a visit might go. A client-ready teardown has to survive a cold open from someone who did not build the site.

Competitors in the synthetic / AI UX audit space (SyntheticUser Lab, Black Lotus UX, Canary Research, Convy, and similar) already sell client decks. The agency-shaped gap Boidwatch owns is narrower: Census-flock Chromium sessions + a public report link + agent-callable surfaces (web, CLI, API, MCP) you can productize into every engagement—not a generic “AI research platform.”

Anatomy of a teardown worth billing

Map each client-facing promise to one Boidwatch output. If a section cannot earn its place in a PDF or share link, cut it.

| Client-facing section | What it must prove | Boidwatch output |

|---|---|---|

| Design intent | You audited the job, not random clicks | One-line design intent you set on the run |

| Who visited | The flock is demographic, not invented avatars | Census-derived personas (36,000+ profiles; IPF-weighted; 17 navigation archetypes) |

| What they did | Real visits, not a static page read | Real headless Chromium per persona |

| Funnel | Where archetypes completed or dropped | Funnel by archetype |

| Friction | Ranked gaps against intent | Friction + recommendations |

| Segments | Different visitors, different failure modes | Segment breakdown |

| Evidence | Stakeholder can see the stuck moment | Key-moment screenshots |

| Handoff | Client can open it cold | Public share link |

Flow that maps cleanly into a SOW line:

1. Design intent — one sentence: what the page should make a visitor do.

2. Flock — personas drive Chromium against that intent.

3. Funnel / friction / segments — composed into the report body.

4. Strongest findings — ranked, plain language.

5. Recommendations — what to fix before redesign or handoff.

Homepage example-report framing covers a landing-page exploration and a web-app POC—use those as shape references, not as invented outcomes for your client’s URL.

Real profiles and real browsers (why this isn’t a vibe check)

Two ingredients separate a teardown from a vibe check: who visits, and how they visit.

Who. Boidwatch samples from 36,000+ Census-derived demographic profiles with IPF weighting, then navigates via 17 archetypes. Rows in the report map to those archetypes; dashed cells are where an archetype broke off. That is population-shaped sampling, not a handful of founder-imagined personas.

How. Each persona drives a real headless Chromium session—clicks, scrolls, and gets stuck the way a visitor does. Every step writes four behavioral traces:

| Field | Example |

|---|---|

| Intent | “I'm trying to find pricing before I sign up.” |

| Perception | “Top nav has five links. None of them say Pricing.” |

| Affect | confidence 0.4 · frustration 0.7 · trust 0.5 |

| Memory | “The hero mentioned a 30-day trial — try clicking the signup CTA.” |

One run × N personas × every step is the report substrate. That is why the artifact reads like a visit log a stakeholder can argue with—not an LLM essay about the page.

NN/g-style caution still applies: synthetic users are directional. Cite them as behavioral evidence that complements moderated research when the engagement requires statistical or ethnographic depth. Do not claim equivalence to a three-week specialist study.

Where it sits in the engagement timeline

Three natural slots—same artifact, different SOW language:

| Moment | Job | Packet depth |

|---|---|---|

| Kickoff / discovery | Baseline the live (or competitor) URL before redesign scope locks | Full flock → public link in the kickoff deck |

| Pre-redesign | Prove which friction is worth the redesign budget | Full or quick flock; ranked gaps as scope input |

| Pre-handoff | Prove the staging primary journey before the client opens it | Capped peek for strongest blocker, or full flock for the client packet |

How to talk about synthetic evidence with clients (without inventing testimonials):

> This is a Census-weighted persona flock in real browsers against the design intent you approved. It is directional behavioral evidence—fast enough to land before kickoff ends—not a replacement for moderated usability when that is in scope.

Pair with your existing research plan when the contract calls for human sessions. Do not sell the flock as “statistically equivalent to moderated tests.”

Related gates once published: Test the site before client handoff (delivery SOP) and Agent-native shipping proof (capped peek before the client URL goes out).

How to run and share

Authenticate once (BOIDWATCH_API_KEY from API keys settings). New accounts get 30 free credits; 1 credit = 1 persona. No card required for that pool. The 5- and 20-persona counts below and ungated complete reports require wallet top-up / a paid run outside the free cap. Without top-up, ordinary runs remain free-capped at 3 personas with gated results, even with signup credits.

Client packet (default full flock — 20 personas):

curl -fsSL https://boidwatch.com/install.sh | sh
# or: brew install boidwatch/tap/boidwatch

export BOIDWATCH_API_KEY=fg_live_...

boidwatch --json run create \
  --url https://CLIENT-PRIMARY-URL \
  --design-intent "Understand pricing and start a trial" \
  --wait

Faster pass (5 personas) — add --quick when you want ranked gaps without the full packet.

MCP — after CLI ≥ v1.1.0, teams that productize via agents:

claude mcp add boidwatch -- boidwatch mcp

Use boidwatch_teardown for the client packet, or boidwatch_quick_check (resume with boidwatch_get_results—do not call quick_check again for the same run). Wiring detail: MCP site QA for Cursor and Claude Code.

CLI and MCP create ordinary /v1/runs, not peeks.

Adjacent shipping gate — authenticated POST /v1/peek on https://api.boidwatch.com (force-free even on paid accounts: 3 personas, 15 steps, 5-minute hard stop → one strongest finding; full report gated). Prefer documented CLI / MCP for the teardown deliverable; treat peek as the yes/no gate before a client link goes out. Prefer CLI --quick / MCP until peek appears in public llms.txt.

After the run: open the composed report, copy the public share link, drop it into the kickoff deck or discovery appendix. Web app: app.boidwatch.com. Agent docs: llms.txt. Example report shapes: boidwatch.com.

Pricing posture for the agency (no invented rates)

Package the teardown as a line item, not as hours buried under “research.”

Useful framing for the SOW (adapt; do not invent Boidwatch list prices or market rate tables):

Name it — “Kickoff UX teardown (persona flock + shareable report)”
Scope it — one primary URL, one design intent, public report link delivered in the kickoff packet
Separate it — from moderated research, accessibility certification, and visual QA; those stay their own owners
Escalate clearly — peek / quick for gates; full flock with wallet top-up / a paid run outside the free cap when the client packet needs the ungated complete report

Credit math you can state product-truthfully: 1 credit = 1 persona; new accounts get 30 free credits to trial. Do not invent agency ROI, close rates, or “clients love this” quotes. Do not claim “#1 UX audit tool.” The sell is repeatability: same artifact shape on every engagement, agent-callable when you want it in the stack.

FAQ

What should a client-ready UX teardown include?

Design intent, who visited (persona / segment framing), funnel and friction against that intent, segment breakdown, key-moment evidence, plain-language findings and recommendations, and a public link a stakeholder can open without an account.

How can an agency produce a UX audit deliverable without a three-week research project?

Run a Boidwatch persona flock on the client’s primary URL with a one-line design intent; share the public report link. Product positioning contrasts that with a specialist audit framed as four figures / three weeks—use it as positioning, not a market study. Keep moderated research when the engagement still requires it.

What’s the difference between a heatmap dump and a teardown a client will open?

Heatmaps and raw session dumps need an analyst to narrate. A client-ready teardown is already narrated: ranked gaps against design intent, segments, screenshots, and a cold-open public link. Stakeholders skim findings; they do not reverse-engineer telemetry.

Can synthetic Census personas support a kickoff audit responsibly?

Yes—as directional behavioral evidence. Census-weighted personas in real Chromium sessions surface friction fast enough for kickoff. They do not replace moderated usability, accessibility certification, or legal review. Say that out loud in the SOW.

Put the teardown in the next kickoff deck

Pick the client’s primary URL and one-line design intent, run a flock (or peek → full), and send the public report link in the kickoff deck as the teardown artifact.

boidwatch --json run create \
  --url https://CLIENT-PRIMARY-URL \
  --design-intent "YOUR ONE-LINE INTENT" \
  --wait

Product & example reports: boidwatch.com · agent docs: llms.txt · keys: API keys settings.