Run a competitive UX audit
Audits how competitors handle one key user task, comparing steps, patterns, friction and delighters, and recommends what to adopt or avoid. Use before redesigning a core flow.
Competitive reviews usually turn into screenshot collages or feature checklists, and when produced by a model they often describe competitors' flows from memory, inventing step counts and screens that changed long ago. A useful audit compares the same task, done by the same type of user, from the same starting point, measured the same way, and ends with specific decisions: what to copy because users now expect it, what to avoid, and where there is room to be better.
Audit how these competitors handle this task.
- Scope. Restate the task as a scenario with a clear start point (for example "lands on the homepage, logged out, on mobile") and end point, the user type, and the platform. Use the same definition for every product.
- Check the evidence. For each competitor, note whether the input contains a walkthrough (notes or screenshots for the steps) or only a name. Analyse only what was supplied. For competitors with no walkthrough, do not describe their flow from memory: list them under Gaps with a walkthrough protocol (start state, device, account state, what to capture at each screen, the time limit) so the user can collect it. If no competitor has a walkthrough, produce only the protocol, a blank comparison table and the questions to answer, and stop.
- Comparison. For each product with evidence, record: number of screens and required inputs (fields, choices, taps) from start to end; points where the user must create an account, pay or give permission; information shown before commitment (price, time, availability); error prevention and recovery; and the patterns used at each stage.
- Friction and delighters. Per product, list friction points (unclear labels, forced sign-up, surprise costs, dead ends, extra steps) and delighters (smart defaults, saved state, previews, reassurance) with the step where each occurs. Rate friction severity: blocker, major, minor.
- Patterns. Group what the products do into stages of the task and note which patterns are now conventional (most products share them, so users will expect them) versus distinctive.
- Recommendations. For your product, or for a new design if none was given: adopt (conventions users expect, and strong ideas worth borrowing), avoid (patterns causing friction or dark patterns), and differentiate (gaps no competitor fills). Each with the evidence that supports it and a confidence level. Note that an expert walkthrough is not user evidence, and recommend which items to validate with users.
- Never invent screens, step counts, prices or features. Every observation cites the supplied walkthrough; anything not supplied is a gap.
- Count steps the same way for every product, and state the counting rule.
- Do not recommend copying dark patterns because a competitor uses them: confirmshaming, hidden costs, forced continuity or obstructed cancellation are listed as patterns to avoid.
- Do not copy competitors' copy, imagery or trade dress; borrow patterns, not assets.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Scope
Comparison
| Product | Screens | Required inputs | Account / payment / permission points | Info before commitment | Notable patterns |
Friction and delighters
Per product, a list with step, finding and severity.
Patterns
Recommendations
Three lists: Adopt, Avoid, Differentiate. Each item with evidence and confidence.
Gaps
Missing walkthroughs with the protocol, and what to validate with users.
2 required values still a placeholder; the assistant will ask for them.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Design
- category
- UX research
- level
- Intermediate
- made for
- Product / UX / UI designer, UX researcher, Product manager, Founder / business owner
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install run-competitive-ux-audit --target claude-codenpx skills add hermes-hq/hodios-dist --skill run-competitive-ux-audit -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-design@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of UX researchRun a heuristic evaluation
Evaluates a flow step by step against Nielsen's ten usability heuristics and returns located issues with severity ratings and concrete fixes. Use for a fast expert review before or between user tests.
run-heuristic-evaluationCritique a UI screen
Critiques one interface screen for hierarchy, layout, consistency, clarity and accessibility against its goal, and returns prioritised, concrete fixes. Use when reviewing a mockup or live screen.
critique-ui-screenAnalyse competitors
Builds a competitor comparison of target customer, messaging, pricing, strengths and gaps, and finds openings for differentiation and how to win against each. Use for strategy or battlecards.
analyze-competitorsProduct designer
Product designer who frames the problem before the pixels, explores several options, designs every state and defends decisions with user evidence. Use as a design partner or reviewer.
product-designerUX researcher
UX researcher who matches the method to the question, separates what people did from what it means, and protects participants. Use as a partner for planning, running and synthesising research.
ux-researcherBuild evidence-based user personas
Builds UX personas from research notes, grouping participants by behaviour, with goals, pain points and scenarios traced to evidence and assumptions marked. Use after interviews or field research.
build-user-personas