Product Experience Coverage Audit

Audit the product represented by the current workspace for materially useful improvements to its user experience, interaction design, information architecture, visual hierarchy, responsive behavior, accessibility, content design, feature completeness, and design-system organization.

The audit must be useful to a cross-functional audience of product owners, product experts, designers, and engineers. Explain accepted findings in terms of:

the user or business outcome;
the product or design decision required;
the smallest credible implementation scope;
the evidence needed to validate the result.

You are the audit coordinator. Continue until the complete user-facing product has been reviewed and the final audit has been independently validated.

Project-agnostic scope guard

Audit only the product represented by the current workspace.

Do not assume its industry, audience, business model, terminology, feature set, technical architecture, design maturity, or competitive category from:

the workspace or directory name;
prior conversations or previously audited projects;
conventions from superficially similar products;
generic examples in this prompt.

Establish the product’s identity, users, goals, constraints, and intended behavior from evidence in the current workspace and running product.

Treat the screen, workflow, component, and state categories in this prompt as inspection prompts, not requirements. Do not criticize the product for lacking a category or feature irrelevant to its purpose.

Use project-native terminology in the audit. Do not import terminology, findings, screenshots, credentials, or assumptions from another project.

For competitor research, first establish the product’s actual category and user goals. If no sufficiently comparable product or workflow exists, skip the comparison rather than forcing one.

Operating constraints

This is an audit-only exercise.

Do not:

modify application or configuration files;
implement recommendations;
update screenshots, snapshots, or visual baselines;
install or upgrade dependencies;
run migrations;
run broad test suites;
modify fixtures or seed data;
commit, push, or create a pull request.

Read-only repository inspection commands are allowed.

Runtime inspection is encouraged when safely available. You may:

launch the application locally;
navigate through the product;
resize or emulate supported devices;
inspect interactive and asynchronous states;
use non-destructive representative data;
run non-mutating browser or accessibility diagnostics;
capture screenshots;
inspect existing tests, stories, fixtures, and visual baselines without updating them.

Use the running product and its implementation together. Do not infer the complete experience from screenshots alone, and do not infer actual behavior from code alone.

If a surface cannot be run or reached, inspect its implementation and mark runtime behavior as unverified. Never invent unseen screens, states, interactions, users, or requirements.

The repository must remain unchanged.

If audit artifacts such as screenshots and annotations are necessary, store them only in an explicitly designated audit-output directory outside the repository. If no external output directory is available, include evidence directly in the final response.

1.1 Authentication and credentials

You may use credentials or authenticated sessions previously saved and authorized for the current workspace through workspace memory, the existing browser session, environment, or an approved credential store.

Handle credentials securely:

never print, quote, expose, summarize, or return credential values;
never include credentials in source files, reports, screenshots, commands, shell history, or logs;
do not search unrelated files or directories for additional credentials;
use credentials only to access the product being audited;
do not reset passwords, change MFA, change security settings, accept invitations, or alter account ownership;
do not attempt account recovery when credentials are unavailable or invalid;
mark inaccessible authenticated surfaces as blocked.

If multiple authorized roles are available, inspect each role only when it exposes a materially different experience.

Do not perform irreversible actions, modify production data, make purchases, send real messages, publish content, or create external side effects.

For destructive or externally visible workflows, inspect the experience only up to the final safe step.

1.2 Assumptions and clarification

Prefer making reasonable, evidence-based assumptions and recording them over blocking the audit.

Ask for clarification only when:

different answers would materially change the audit scope;
the ambiguity could cause unsafe or externally visible actions;
a required environment or role cannot be identified;
product intent cannot be distinguished from an apparent defect.

Establish the product model

Before evaluating individual screens, determine:

the product’s apparent purpose and value proposition;
its primary user types;
the principal jobs or goals of each user type;
the product’s most important workflows;
business-critical, trust-critical, or data-critical actions;
the expected level of user expertise;
supported browsers, devices, and input methods;
relevant product, brand, accessibility, and technical constraints;
the apparent maturity and intended scope of the product.

Inspect available:

product documentation;
route definitions and navigation;
layouts and UI components;
design tokens and assets;
tests, stories, fixtures, and visual baselines;
analytics instrumentation;
feature flags;
issue descriptions and internal notes;
authenticated runtime behavior.

Distinguish among:

documented product intent;
intent inferred from implementation;
observed runtime behavior;
auditor assumptions;
behavior that remains unverified.

Establish the coverage contract

Inventory every identifiable user-facing experience surface, including where relevant:

public and authenticated routes;
onboarding and first-use experiences;
primary workflows and recurring tasks;
global and local navigation;
search, filtering, sorting, and discovery;
forms, editors, selectors, dialogs, drawers, and menus;
dashboards, details, lists, tables, maps, calendars, and visualizations;
settings, accounts, permissions, billing, and administration;
loading, empty, partial, success, validation-error, server-error, timeout, and permission-denied states;
destructive actions and recovery paths;
compact and tablet-specific layouts;
keyboard, pointer, touch, zoom, reduced-motion, and assistive-technology behavior;
notifications, confirmations, asynchronous feedback, and saved-state indicators;
shared layouts, components, patterns, terminology, and design tokens;
embedded surfaces, platform bridges, legacy screens, experiments, and feature-flagged experiences.

Give each experience surface:

a stable ID and descriptive name;
its intended user and user goal;
its exact ownership boundary;
entry points, exit points, and routes;
key implementation files;
shared components, layouts, and design-system dependencies;
related upstream and downstream workflows;
relevant tests, stories, fixtures, and specifications;
required states and variants;
applicable viewport, theme, role, and input method;
a status: queued, in review, recommend, skip, blocked, or runtime unverified.

Create a separate inventory of important end-to-end user journeys.

Reviewing individual screens does not prove that the complete workflow is coherent.

For each journey, record:

the user and their goal;
its starting condition;
the expected happy path;
important choices and decision points;
errors and recovery paths;
completion criteria;
the surfaces crossed;
required data, account state, role, or permissions.

Create one canonical scratchpad or report containing:

the product model;
the surface inventory;
the journey inventory;
the screenshot and runtime-evidence index;
confirmed recommendations;
evidence-backed feature gaps;
accessibility findings;
explicit skip, blocked, and unverified decisions;
cross-cutting design-system patterns;
duplicates and superseded findings;
final priorities and dependencies;
assumptions and limitations;
an audit log.

Treat these inventories as the coverage contract.

Broad rows such as “dashboard,” “responsive design,” “forms,” or “accessibility” do not prove coverage unless their exact screens, workflows, states, and boundaries are enumerated.

Build the desktop and tablet baseline

The supported device scope is desktop and tablet web.

Mobile-phone optimization is out of scope unless mobile behavior directly exposes a defect in the supported tablet experience or in shared responsive code.

Prefer the project’s declared breakpoints. If none are declared, inspect at least:

wide desktop: approximately 1440×900;
compact desktop: approximately 1280×800;
tablet landscape: approximately 1024×768;
tablet portrait: approximately 768×1024.

Test relevant input modes:

pointer and keyboard on desktop;
touch on tablet;
external keyboard on tablet where materially relevant.

Where supported, inspect:

light and dark themes;
browser zoom and larger text;
reduced motion;
first-use and returning-user conditions;
sparse and heavily populated data;
short, long, missing, and overflowing content;
loading, empty, partial, success, validation-error, server-error, timeout, and permission states;
hover, focus, active, selected, disabled, and destructive-action states;
slow or interrupted asynchronous behavior when it can be simulated safely.

Use WCAG 2.2 AA as the default accessibility target unless the workspace declares a different requirement.

4.1 Screenshot evidence

Capture screenshots when they materially improve the evidence. Do not produce large galleries of nearly identical screens.

Each screenshot must record:

related surface or journey ID;
route or product location;
viewport dimensions and theme;
role, data, and application state;
what the screenshot demonstrates;
related finding IDs.

Use annotated screenshots for problems involving:

hierarchy;
spatial relationships;
density;
overflow;
responsive layout;
discoverability;
touch targets;
focus or interaction state.

Preserve the unannotated original alongside an annotated version.

Use deterministic filenames containing the surface ID, state, viewport, and reviewer ID. Prevent parallel reviewers from overwriting one another’s artifacts.

Do not silently treat missing states as acceptable. Mark each required state as:

observed;
implementation-only;
unavailable;
apparently missing;
not applicable.

Coordinate parallel reviews efficiently

The coordinator owns:

the canonical inventory and report;
work assignment and boundary definitions;
deduplication and cross-cutting ownership;
final verification;
prioritization;
the completion decision.

Sub-agents return structured findings to the coordinator. They must not independently edit the canonical report or application files.

5.1 Build review units

Divide the inventory into bounded review units.

A unit may contain one substantial surface or a small group of tightly related surfaces.

Do not create one agent per minor component, modal, or state. Bundle adjacent surfaces when they share:

the same user goal;
a route family;
an implementation owner;
a runtime setup;
a common role or data requirement.

Every review unit must specify:

stable surface and journey IDs;
exact included routes, files, and states;
explicit exclusions;
relevant user roles;
required desktop and tablet viewports;
whether runtime, code, or both must be inspected;
dependencies on other review units;
completion criteria;
the required output schema.

Review-unit boundaries must not overlap.

Agents may report cross-cutting concerns, but must nominate one likely authoritative owner rather than expanding their assignment.

5.2 Use phased parallelism

Run the audit in these phases.

Phase A — Coordinator discovery

establish the preliminary product model;
identify roles and safe runtime access;
create the initial surface and journey inventories;
identify shared shells, layouts, and design-system ownership;
create non-overlapping review units.

Do not dispatch broad “review the whole application” assignments.

Phase B — Parallel surface reviews

Dispatch independent review units concurrently where their routes, implementation ownership, and runtime state do not conflict.

Reserve at least one execution lane for coordination and synthesis. Do not occupy every available lane with workers.

Prefer giving one agent a coherent bundle over repeatedly creating agents for tiny surfaces.

Phase C — Journey reviews

After the relevant surfaces are understood, review end-to-end journeys in parallel where they do not share mutable runtime state.

Journey reviewers concentrate on transitions, continuity, recovery, and completion. They must not repeat the full surface audits.

Phase D — Targeted horizontal validation

Run specialized passes for:

accessibility and keyboard behavior;
desktop/tablet responsiveness and touch behavior;
design-system and content consistency;
coverage, duplication, and materiality;
implementation feasibility and priority;
constrained competitor research.

These are validation passes over the inventory and candidate findings, not unrestricted second audits of the entire product.

Only research competitors for already-identified, credible feature-gap candidates. Do not run competitor research for every surface.

Phase E — Coordinator verification

The coordinator independently verifies the evidence for every accepted finding without repeating the entire original review.

Verification must be proportional to risk:

reproduce every critical or high-impact runtime issue;
inspect every cited implementation location;
verify accessibility claims against the relevant requirement;
verify competitor references and contextual fit;
spot-check lower-impact runtime evidence where reproduction is straightforward;
reject findings whose evidence cannot be confirmed.

5.3 Manage browser and session contention

Parallelize repository inspection where ownership boundaries do not overlap.

Runtime inspection may run concurrently only when agents have isolated browser contexts, accounts, and application state.

If reviewers share a browser, authenticated session, test account, or mutable dataset:

use a single runtime-inspection lane;
serialize navigation and screenshot capture;
parallelize code inspection separately;
do not allow agents to change shared filters, records, permissions, fixtures, or account state concurrently.

Agents must reference authorized credentials by workspace context. Never include credential values in an assignment or result.

5.4 Give each worker a complete context packet

Every worker receives:

the established product model and known assumptions;
its exact ownership boundary;
relevant routes, files, roles, and states;
required viewports and input methods;
explicit exclusions;
the materiality threshold;
the standard finding schema;
known findings that must not be duplicated;
artifact naming and storage rules.

Do not ask workers to rediscover global context unless discovery is part of their assignment.

Each worker returns:

coverage completed;
evidence inspected;
at most two materially useful findings per review unit;
explicit skips;
blocked or unverified behavior;
possible cross-cutting concerns;
an overflow signal if additional material findings may exist.

A critical accessibility, data-loss, security, or trust issue must not be omitted because the normal finding limit has been reached. Return it as an exception and explain why.

5.5 Control coordination overhead

Use one consolidated wait mechanism where available. Harvest completed results in batches rather than repeatedly polling individual workers.

Do not interrupt productive workers merely because they are slower than others.

Do not dispatch another agent when:

the remaining check is small enough for the coordinator;
an active review already covers the boundary;
runtime access would conflict with an active session;
the result would merely restate an accepted finding;
the work depends on an unresolved prerequisite.

Reuse an agent for a closely adjacent follow-up when continuity is valuable.

Use a fresh agent when independence is important, especially for:

coverage validation;
materiality review;
accessibility validation;
final priority review.

Only the coordinator may:

accept or reject findings;
change inventory ownership;
merge duplicates;
rank recommendations;
declare the audit complete.

Worker review brief

Each surface reviewer receives this brief:

Review the assigned experience for at most two materially useful design or UX improvements.

Inspect the running experience where available, its implementation, shared components, surrounding workflow, important states, desktop and tablet behavior, touch and keyboard behavior, content, and existing tests or stories.

Stay within the assigned boundary. You may identify cross-surface concerns, but do not expand the scope to redesign the entire product.

Evaluate the experience from the perspective of its intended user and their goal.

Look for:

unclear information hierarchy or weak prioritization of the primary task;
confusing navigation, grouping, labeling, terminology, or wayfinding;
unnecessary steps, repeated decisions, dead ends, or context switching;
actions whose result, scope, status, or reversibility is unclear;
missing feedback during loading, saving, processing, success, or failure;
incomplete empty, error, timeout, permission, or recovery states;
forms that permit preventable errors, validate too late, or discard user work;
destructive actions without sufficient warning, confirmation, undo, or recovery;
desktop or tablet layouts that overflow, become cramped, or hide important actions;
interactions that work with a pointer but fail or become ambiguous with touch;
keyboard traps, illogical focus order, invisible focus, or unreachable controls;
accessibility barriers involving semantics, names, instructions, contrast, motion, or status announcements;
vague, inconsistent, overly technical, misleading, or poorly timed content;
inconsistent components or interaction patterns that increase learning cost;
one-off decisions that should use an existing component, token, or pattern;
recurring defects caused by unclear component or design-system ownership;
excessive density, decorative noise, or weak scannability;
missing progressive disclosure where complexity obscures the primary task;
onboarding gaps that prevent users from reaching initial value;
perceived-performance problems, layout shifts, stale state, or ambiguous saved state;
missing capabilities that prevent a clearly supported user goal from being completed.

Do not force a redesign.

Preserve coherent and familiar behavior when the current experience is already understandable and effective.

Prefer a focused local correction unless evidence shows that a shared pattern is failing across multiple surfaces.

Do not recommend changes solely because:

another visual style is personally preferable;
a layout could be more fashionable;
absolute consistency is theoretically possible;
a hypothetical future user might need it;
a component could be made more generic;
more animation, illustration, onboarding, or configuration could be added;
a competitor has a feature without evidence that it fits this product.

Return at most two opportunities per review unit. If nothing clearly meets the threshold, return skip.

If the finding limit might conceal additional material problems, return an overflow signal so the coordinator can narrow the boundary or schedule another pass.

Finding schema

For every recommendation, provide:

Finding ID and concise title.
Verdict: recommend or skip.
Category:
- usability;
- interaction;
- navigation;
- content;
- visual hierarchy;
- responsive;
- accessibility;
- trust and safety;
- design system;
- perceived performance;
- feature gap.
Affected user, goal, surface, and journey.
Runtime evidence:
- route or location;
- role, viewport, and application state;
- reproduction steps;
- screenshot reference where useful.
Implementation evidence with exact file and line references.
Current user problem and likely consequence.
Proposed experience, including interaction, state, and content behavior.
Why the proposal is materially better and not merely different.
Smallest credible implementation scope, including affected files, components, states, and interfaces.
Acceptance criteria covering desktop, tablet, touch, keyboard, and relevant states.
Accessibility implications. Cite a specific accessibility requirement only when confident it applies.
Risks, tradeoffs, and migration concerns.
Existing and additional validation required.
Impact: critical, high, medium, or low.
Confidence: high, medium, or low.
Estimated effort: small, medium, or large.
Blast radius: contained, moderate, or broad.
Dependencies and prerequisites.
Product, design, or engineering decisions still required.

For a skip, record:

surfaces, states, and evidence inspected;
any runtime limitations;
why no material recommendation met the threshold.

Review complete user journeys

After surface reviews, inspect each important journey from entry to completion.

Determine whether:

users can recognize where and how to begin;
prerequisites are explained before they become blockers;
terminology and object names remain stable;
navigation preserves orientation and context;
state persists when users go backward, cancel, refresh, or recover;
system feedback matches what actually happened;
users can recognize successful completion;
appropriate next steps are evident;
errors are prevented where possible and recoverable otherwise;
desktop, tablet, touch, and keyboard users can complete the same essential goal;
unexpected account, permission, upgrade, or data requirements interrupt completion;
a missing capability forces abandonment or an unreasonable workaround.

Assign each journey finding to one authoritative owning surface. Do not duplicate the same problem under every affected screen.

Evaluate design-system and UX ownership

Review how recurring design and interaction decisions are organized and owned.

Inspect:

design tokens and theme variables;
typography, color, spacing, elevation, and layout primitives;
shared interactive components;
component variants and states;
desktop and tablet responsive conventions;
touch-target and input conventions;
form and validation patterns;
navigation conventions;
dialogs, notifications, and status feedback;
icons, illustrations, and imagery;
content terminology and message patterns;
accessibility utilities and testing;
documentation, stories, visual tests, and ownership boundaries.

Recommend design-system work only when it resolves demonstrated inconsistency, accessibility risk, duplicated UX behavior, or maintenance problems across multiple real surfaces.

Distinguish among:

a local implementation defect;
misuse of an adequate shared component;
a missing shared pattern;
unclear ownership or documentation;
a genuinely inadequate component API.

Do not turn every visual difference into a token or component.

Run a constrained competitor-reference pass

Competitor research is allowed when it helps validate a small, concrete, and straightforward improvement.

Use competitor references only when:

the product has an identifiable user-goal gap or usability problem;
the referenced pattern addresses substantially the same problem;
the improvement fits the product’s apparent scope and interaction model;
the change appears small or moderately scoped with a contained blast radius;
the reference provides evidence for a pattern rather than only visual inspiration.

Do not recommend:

wholesale competitive parity;
major new product areas;
speculative roadmap expansion;
copying another product’s interface without adapting it to the current context.

Use current, publicly accessible sources. Record:

competitor or reference product;
exact page, workflow, documentation, or screenshot;
source link and access date;
the relevant pattern;
how the context matches or differs;
which aspects are applicable;
which aspects should not be copied;
the smallest appropriate adaptation.

Prefer two or more examples when claiming that something is a common convention. One competitor proves only that one product chose that approach.

Do not create accounts, start trials, make purchases, or bypass access controls for research. Use authenticated competitor access only if it is already authorized for the current task.

A competitor pattern is supporting evidence, not sufficient justification. The recommendation must still connect to this product’s users, goals, constraints, and observed behavior.

Classify feature gaps as:

confirmed completion gap: an intended workflow is visibly incomplete;
small competitive gap: a contained capability would remove a demonstrated disadvantage or workaround;
research candidate: potentially valuable but requires product discovery;
rejected comparison: does not fit the product or would introduce disproportionate scope.

Only confirmed completion gaps and well-supported small competitive gaps belong in the prioritized implementation roadmap.

Validate and synthesize

The coordinator must independently verify every accepted finding.

Reject, narrow, or demote findings that:

lack a concrete user or business consequence;
rely only on aesthetic preference;
rely on a screenshot without interaction context;
misunderstand an intentional product constraint;
duplicate another finding;
propose a large redesign for a local problem;
relocate inconsistency behind a new abstraction without improving the experience;
cite accessibility requirements inaccurately;
claim a feature gap without evidence of a blocked goal or meaningful disadvantage;
use a competitor reference whose context does not match;
cannot define credible acceptance criteria.

Record skips, blocked surfaces, and runtime-unverified surfaces as completed coverage with their limitations.

Deduplicate overlapping findings and assign each accepted recommendation to one authoritative surface or cross-cutting owner.

Continue bounded review batches until every row in the coverage contract is complete.

Audit the audit

Before finishing, run fresh independent passes for:

missing screens, routes, workflows, states, roles, and variants;
missing end-to-end journeys;
cross-screen continuity and friction;
screenshot and runtime-evidence completeness;
desktop and tablet responsive behavior;
portrait/landscape transitions, overflow, zoom, touch, and keyboard behavior;
focus, semantics, contrast, motion, and assistive-technology risks;
design-system consistency and ownership overlap;
content clarity and terminology consistency;
materiality, subjectivity, and redesign overreach;
unsupported or speculative feature gaps;
inappropriate competitor comparisons;
duplicate findings and contradictory proposals;
implementation feasibility;
dependency-aware priority ranking.

These passes should inspect the coverage contract, evidence, and candidate findings first. Reopen implementation or runtime behavior only where necessary to verify a suspected omission or error.

If a coverage pass finds a real omission, add an explicit surface or journey row and audit it. Do not hide the omission by broadening a completed boundary.

Prioritize recommendations

Rank accepted recommendations using:

effect on important user goals;
business or product impact;
frequency and reach;
severity of failure or exclusion;
accessibility impact;
trust, data-loss, or error-prevention implications;
strength of runtime and implementation evidence;
confidence;
implementation effort;
blast radius and regression risk;
prerequisites and sequencing;
whether the change unlocks later improvements.

Separate the roadmap into:

immediate usability and accessibility corrections;
focused workflow improvements;
foundational design-system work;
small evidence-backed feature or competitive gaps;
items requiring product discovery or user research.

Identify the best first implementation slices.

Each slice must:

be independently implementable;
be independently verifiable;
have a clear owner or ownership boundary;
include observable acceptance criteria;
cover relevant desktop, tablet, touch, keyboard, and state behavior;
state its dependencies and risks.

Do not use a generic impact-versus-effort score to conceal uncertainty. Explain the decisive reason for the ordering.

Required final report

Produce the final audit in this order:

Executive summary for product, design, and engineering.
Product model, intended users, and major assumptions.
Surface coverage table.
End-to-end journey coverage table.
Screenshot and runtime-evidence index.
Prioritized recommendations.
Accessibility findings.
Desktop and tablet findings.
Design-system and UX-ownership findings.
Confirmed completion gaps.
Small competitor-supported gaps.
Research candidates and rejected comparisons.
Recommended first implementation slices.
Explicit skips, blocked areas, and runtime-unverified behavior.
Duplicates, rejected ideas, and reasons for rejection.
Validation strategy for each accepted recommendation.
Audit log.
Credential-safety and repository-change confirmation.

For each high-priority implementation slice, include a compact cross-functional handoff:

Product

expected user and business outcome;
intended scope;
unresolved product decisions.

Design

intended behavior;
relevant states;
content requirements;
visual and interaction direction;
accessibility considerations.

Engineering

affected implementation boundaries;
likely components and interfaces;
dependencies;
major regression risks.

Validation

acceptance criteria;
roles and data states;
desktop and tablet viewports;
pointer, keyboard, and touch coverage;
evidence required to consider the change successful.

Completion contract

The audit is complete only when:

every identifiable user-facing surface has been reviewed;
every important end-to-end journey has been reviewed;
every surface and journey has a recommendation, explicit skip, blocked status, or runtime-unverified status;
desktop and tablet portrait and landscape behavior have been considered;
pointer, keyboard, and relevant touch interactions have been considered;
critical loading, empty, error, success, permission, and recovery states have been inspected or explicitly marked unavailable;
screenshots exist wherever visual evidence materially improves understanding;
every accepted finding has runtime or implementation evidence, user impact, scope, risk, acceptance criteria, and validation requirements;
competitor references support only contained, product-appropriate improvements;
feature gaps are separated from defects and speculative research ideas;
weak, subjective, duplicative, and over-scoped recommendations have been removed;
priorities and dependencies are internally consistent;
credentials have not been exposed;
audit artifacts exist only in the designated external output location;
the repository remains unchanged.

tommymarshall/product-experience-cover-audit.md

Select an option

No results found

Select an option

No results found