# Product Design Audit

> Use when auditing a real product across multiple surfaces such as marketing web, SaaS, iOS, Android, or desktop and producing scored, prioritised, skill-routed findings. Use design-audit for one artefact and design-qa-and-pre-launch-review for a release gate.

- Skill: `peterbamuhigire/product-design-audit` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add peterbamuhigire/product-design-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/peterbamuhigire/product-design-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: peterbamuhigire (https://skillmd.com/u/peterbamuhigire)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/peterbamuhigire/product-design-audit

---


# Product Design Audit
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

<!-- dual-compat-start -->
## Use When

- You have a **real, existing product** (live or staging) and want a single, scored
  design audit of the **whole thing**, not one screen — covering every surface it ships
  on and ending in a prioritized, skill-routed fix list.
- The product spans **multiple platforms** — e.g. a marketing **website** + a **SaaS web
  app** + an **iOS app** (iPhone/iPad/Mac) + an **Android app** + a **desktop app** — and
  you need each platform judged on its own idioms *and* the experience judged for
  cross-platform parity.
- You want findings that **route to the engine skill that remediates them** (e.g. low
  contrast → `accessible-color-and-contrast`, Inter in use → `font-selection-and-pairing`,
  no empty states → `empty-error-and-loading-states`, non-idiomatic iOS →
  `ios-ui-ux-design`) so the audit becomes an executable work plan, not just a critique.
- You need a **defensible number** (0–100, with the hard gates that can cap it) per surface
  and an overall product verdict for a stakeholder, investor, or roadmap conversation.
- You are doing **due diligence** on a product (yours or one you are acquiring/consulting on)
  and need the design-quality picture across all its clients.

## Do Not Use When

- You only need to critique **one screen or one artifact** (a landing page, a single
  dashboard, one PDF) — use `design-audit`. This skill *invokes* it per surface; do not
  duplicate it for a single-artifact job.
- You need a **pass/fail go/no-go ship gate** for a build that is about to launch — use
  `design-qa-and-pre-launch-review`. This skill is an exploratory, scored, product-wide
  diagnostic, not a launch sign-off (though its findings can feed one).
- You only need **one cross-cutting dimension**: slop → `visual-product-slop-audit`; WCAG
  → `accessibility-wcag-2-2-compliance`; CWV/budgets →
  `performance-as-ux-and-core-web-vitals`; type slop → `ai-slop-typography-audit`.
- There is **no built product yet** (early design only) — there is nothing to audit. Use the
  design/research skills to *create* first; return when there is something running.
- The deliverable is a **document** (DOCX/PDF/PPTX) rather than a product — use the group-13
  document skills; CWV / platform idioms do not apply.

## Inputs

| Artefact or context | Source | Required? | Why |
|---|---|---|---|
| Product and complete platform set | Product owner | yes | Prevents silent scope loss |
| Inspectable key flows and states per surface | Builds or evidence pack | yes | Grounds per-surface scores |
| Users, jobs, brand, system, analytics, and field data | Product evidence | conditional | Supports impact and confidence judgments |

- **The product and its platform set.** Name the product and confirm *which* surfaces are in
  scope: website, SaaS web app, iOS (iPhone/iPad/Mac), Android, desktop (native vs Electron).
  The audit runs only the platform lenses that apply — but it must run **all** that do.
- **Access to each surface in scope** — a live URL / staging build / TestFlight / APK /
  desktop binary, OR a representative set of **screenshots per key flow per breakpoint/device**.
  Refuse to score a surface from a single hero screenshot; ask for the core flows.
- **Product context** — who the users are, the primary jobs-to-be-done, the brand
  personality, and any design system / tokens already in place. This sets the bar the audit
  scores against (`design-audit` §Step 1).
- **The stated type/colour choice** (per the Mission) if one exists — or note its absence as
  the first slop finding.
- **Field performance data** (CrUX / RUM p75) for the web surfaces where available; lab
  (Lighthouse) is a labelled proxy only.
- The **page/app archetype** per web surface (marketing, web-app shell, document) — selects
  the budget row in `web-performance-budgets-2026.md`.

## Workflow

1. **Intake the product and lock the platform matrix.** Record the product, its users/JTBD,
   brand, and the exact surfaces in scope. Build a matrix: rows = surfaces (Website / SaaS
   web app / iOS / Android / Desktop), columns = the cross-platform dimensions
   (`references/audit-dimensions.md`). Every in-scope surface gets a row; every applicable
   dimension gets scored. See `references/audit-dimensions.md`.
2. **Run the doctrine / anti-slop gate over the whole product first.** Before any nicety,
   delegate to `visual-product-slop-audit` (visual + product tells) and
   `ai-slop-typography-audit` (banned fonts, pairing) across the surfaces. Confirm the
   type/colour/layout choice was **stated** (Mission), no banned default font
   (`doctrine/references/ai-slop-banned-fonts.md` — Inter, Geist, Roboto, Space Grotesk…),
   and no convergent visual tell survived. **This gate is binary and product-wide:** any FAIL
   caps the affected surface's score (`references/recommendation-format.md` §gates) and is the
   first routed finding (→ `font-selection-and-pairing` / `distinctive-by-design`).
3. **Score every surface on the cross-platform dimensions.** For each in-scope surface, run
   the 11 dimensions in `references/audit-dimensions.md` (the `design-audit` 10 + IA/Navigation
   + Trust), scoring each 0–4 against the extended rubric. Reuse `design-audit`'s
   `references/audit-rubric.md` for the gate logic and 0–100 math; this skill adds the
   per-surface application and the two extra dimensions.
4. **Apply each platform lens.** For every surface, run its specific lens from
   `references/platform-lenses.md`: **Website** (Core Web Vitals, responsive/container
   queries, SEO-visual); **SaaS web app** (app shell, data density, tables, states,
   onboarding); **iOS** (HIG + Liquid Glass, SF Symbols, Dynamic Type, haptics; Mac
   Catalyst/menus/windows, iPad multitasking/pointer, iPhone safe areas/Dynamic Island);
   **Android** (Material 3 Expressive, dynamic colour, predictive back, foldables,
   edge-to-edge); **Desktop** (native vs Electron, window chrome, density, keyboard/shortcuts,
   menus). Non-idiomatic findings route to the platform's owning skill (`ios-ui-ux-design`,
   `android-ui-ux-design`, `webapp-gui-design`).
5. **Run the cross-cutting gates per surface.** Accessibility against
   `doctrine/references/wcag-2.2-criteria.md` via `accessibility-wcag-2-2-compliance` (the AA
   floor **plus** the nine 2.2 deltas; automated **plus** keyboard **plus** screen-reader —
   automation alone catches ~30–40%); performance against
   `doctrine/references/web-performance-budgets-2026.md` via
   `performance-as-ux-and-core-web-vitals` (web surfaces); content/UX-writing against
   `ux-writing-and-microcopy` / `error-empty-and-system-messaging`. Each gate can cap the
   surface score (`references/recommendation-format.md`).
6. **Check cross-platform parity.** Where the same product spans surfaces, run the parity lens
   (`cross-platform-design-parity`): consistent IA, terminology, brand, and state model
   without forcing one platform's idioms onto another (an iOS tab bar ported verbatim to
   Android is a finding, not parity). Record parity gaps as their own findings routed to
   `cross-platform-design-parity`.
7. **Score and band each surface, then the product.** Produce a 0–100 per surface (gates
   applied) using the rubric, then an **overall product verdict** = the gate-respecting roll-up
   across surfaces (the product is only as shippable as its weakest blocking gate). Band per
   `references/recommendation-format.md`.
8. **Build the prioritized, skill-routed recommendation table.** This is the payload. Every
   finding gets: surface, dimension, severity, evidence, **P0/P1/P2 priority** (user-impact ×
   effort, per `references/recommendation-format.md`), the standard it violates, and the **exact
   engine skill that remediates it**. Group by priority so the team can execute top-down. Never
   leave a finding un-routed — if no skill fits, say so and name the doctrine reference instead.
9. **Write the verdict.** Lead with the product verdict and the single highest-leverage fix,
   then the per-surface scores, then the routed table. Make assumptions, evidence gaps, and any
   surface you could not fully access explicit.

## Decision Rules

| Condition | Action | Wrong-choice failure |
|---|---|---|
| One isolated artefact or flow | Route to `design-audit` | Product-wide machinery adds noise without comparative value |
| Two or more live product surfaces | Audit each surface, then reconcile shared-system and parity findings | Separate reports hide systemic design drift |
| A surface cannot be inspected | Keep it in the coverage map as an evidence gap | Missing platforms silently inflate the product score |
| A release verdict is requested | Hand the relevant build to `design-qa-and-pre-launch-review` | A strategic audit is misrepresented as release certification |

## Capability Contract

Read and visual inspection are required across every in-scope surface. Browser, device, repository,
analytics, and research access are conditional on the evidence available. This audit is read-only;
implementation belongs to `ux-remediation-and-redesign` after findings are accepted.

## Degraded Mode

Audit accessible surfaces, publish a coverage matrix, and lower confidence for missing platforms,
states, analytics, or user evidence. Do not calculate a whole-product score that implies complete
coverage when a material surface is absent.

## Quality Standards

- **Product-level, not artifact-level.** Score whole surfaces and their flows, not one hero
  screen. A surface scored from a single screenshot is flagged as low-confidence.
- **Every applicable platform is actually audited** on its own idioms — an iOS app is judged
  against HIG/Liquid Glass, an Android app against Material 3 Expressive, never one rubric
  flattened across both.
- **Every finding is routed** to a real, existing engine skill (glob-verified name) — the audit
  is an executable work plan. Un-routable findings name the doctrine reference instead.
- The three hard gates (slop, WCAG-2.2-AA, CWV) are **run, not assumed**, and they **cap** the
  score per `references/recommendation-format.md`. Never report ≥ 60 for a surface while slop or
  a11y is failing.
- Accessibility uses automation **plus** manual keyboard **plus** screen-reader. A green
  Lighthouse number is not an a11y pass.
- Scores trace to `design-audit`'s `references/audit-rubric.md`; thresholds trace to the
  canonical `wcag-2.2-criteria.md` and `web-performance-budgets-2026.md` — never re-invented.

## Anti-Patterns

- **Auditing one screen and calling it the product.** The whole point is breadth across
  surfaces and flows; a single-artifact critique is `design-audit`'s job.
- **One rubric flattened across platforms.** Scoring an iOS app with web heuristics (or vice
  versa) and missing the platform idioms — that is what `platform-lenses.md` exists to prevent.
- **Findings with no skill route.** A critique that says "fix contrast" without pointing at
  `accessible-color-and-contrast` is not actionable; route every finding.
- **Letting a weighted total hide a failing gate.** A surface with a slop or AA failure cannot
  score ≥ 60 no matter how pretty — apply the caps.
- **Forcing cross-platform sameness.** Calling a faithful Material 3 app "inconsistent" because
  it does not look like the iOS app — parity is shared IA/brand/terminology, not pixel-identical
  chrome.
- **Re-deriving thresholds or duplicating the audits.** Inventing contrast/CWV numbers, or
  re-writing the slop/a11y/perf logic here instead of invoking the owning skills — this skill
  *composes* them across the product, it does not fork them.
- **Treating Lighthouse green as the whole a11y or perf story.** Field p75 and manual passes
  are required.

## Outputs

| Artefact | Consumer | Evidence and acceptance condition |
|---|---|---|
| Multi-surface scorecard and finding register | Product and design leaders | Scores reconcile per-surface evidence and hard-gate caps |
| Skill-routed remediation portfolio | Remediation owner | Every recommendation names priority, surface, evidence, owner skill, and confidence |

- A **product design audit report** (`examples/product-audit-worked.md` shape): header (product,
  platforms, context), the product-wide anti-slop verdict, a **per-surface scorecard** (0–100
  with gates and band each), and the **overall product verdict**.
- A **prioritized, skill-routed recommendation table**: every finding with surface, dimension,
  severity, P0/P1/P2, evidence, violated standard, and the **engine skill that fixes it**.
- A **per-surface dimension worksheet** (the rubric's 0–4 grid, extended with IA/Nav + Trust).
- A **cross-platform parity note** listing parity gaps routed to `cross-platform-design-parity`.
- An **evidence-gap list** — surfaces/flows not fully accessible, marked low-confidence.

## Examples

- `examples/product-audit-worked.md` — a fully worked product audit of a real-ish SaaS product
  (a small-business invoicing tool, "Tenda Books") that ships a marketing website, a SaaS web
  app, and an iOS app. Real findings with evidence, per-surface 0–4 dimension worksheets, the
  three gates applied (with a contrast + a banned-font failure capping two surfaces), the
  prioritized P0/P1/P2 **skill-routed** recommendation table, and an overall product verdict.
  Not lorem — concrete thresholds, real skill names, no banned fonts.

## References

- `references/audit-dimensions.md` — the 11 cross-platform dimensions this audit scores (the
  `design-audit` 10 + IA/Navigation + Trust), each with what it checks and the skill it routes to.
- `references/platform-lenses.md` — the per-platform check lists (Website, SaaS web app, iOS
  [iPhone/iPad/Mac], Android, Desktop) and which skill remediates each platform finding.
- `references/recommendation-format.md` — how to score (severity), apply the hard-gate caps,
  prioritize (P0/P1/P2 = user-impact × effort), and route each finding to the exact engine skill.
- `design-audit` → `references/audit-rubric.md` — the 0–100 rubric and three-gate cap logic this
  skill reuses per surface (do not duplicate; compose).
- `doctrine/design-doctrine.md` — the Mission and Anti-Slop Charter; the rule that a slop / a11y
  / perf blocker caps a surface and that convenience never overrides.
- `doctrine/references/wcag-2.2-criteria.md` and `doctrine/references/web-performance-budgets-2026.md`
  — the canonical accessibility floor (AA + nine 2.2 deltas) and performance floor (CWV "good").
- `doctrine/references/ai-slop-taxonomy.md`, `doctrine/references/ai-slop-banned-fonts.md`,
  `doctrine/references/font-groups-and-usage.md` — the slop tells, the banned faces, and the
  8 intent-based font categories the typography findings route against.
<!-- dual-compat-end -->
## Plugins (Load Alongside)

| Companion Skill | When to Load |
|---|---|
| `design-audit` | Per-surface scored 0–100 diagnostic — this skill runs it per surface and aggregates |
| `design-qa-and-pre-launch-review` | When a surface is about to ship and needs the pass/fail gate, not a diagnostic |
| `visual-product-slop-audit` | The product-wide visual + product slop gate — blocking |
| `ai-slop-typography-audit` | The banned-font / pairing half of the slop gate — blocking |
| `accessibility-wcag-2-2-compliance` | The per-surface WCAG 2.2 AA gate — blocking |
| `performance-as-ux-and-core-web-vitals` | The per-web-surface Core Web Vitals / budget gate — blocking |
| `cross-platform-design-parity` | The parity lens across surfaces of one product |
| `ios-ui-ux-design` / `android-ui-ux-design` / `webapp-gui-design` | The platform lenses' remediation owners |
| `ux-remediation-and-redesign` | **Downstream of this audit** — takes the prioritized, skill-routed findings and runs the fix lifecycle (triage → redesign → re-validate → measure) per flow |

---

*Sources: composes `design-audit`, `design-qa-and-pre-launch-review`, `visual-product-slop-audit`,
`ai-slop-typography-audit`, `accessibility-wcag-2-2-compliance`,
`performance-as-ux-and-core-web-vitals`, and `cross-platform-design-parity`. Standards: WCAG 2.2
AA (`doctrine/references/wcag-2.2-criteria.md`); web.dev Core Web Vitals
(`doctrine/references/web-performance-budgets-2026.md`); Apple HIG; Material 3 Expressive; the
Chwezi Anti-Slop Charter (`doctrine/design-doctrine.md`). NNG heuristic evaluation for structure.*