本文へ移動
cccskills
無料GitHub で公開

ux-audit

Audit a user flow for friction and drop-off points. Use when the user says "UX audit", "audit this flow", "where are users dropping off", "why isn't this converting", "review the onboarding", "usability audit", "what's causing friction", "user journey review", or wants to identify why users struggle with a flow - even if they don't explicitly say "UX audit".

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Overview

Based on "Don't Make Me Think" by Steve Krug. Krug's core principle: every question a user has to ask themselves is a source of friction. Good UX eliminates questions. Users don't read - they scan. They don't make optimal choices - they satisfice (pick the first option that seems good enough). Design for scanning, not reading. Design for satisficing, not deliberation.

Krug's usability testing insight: you don't need 20 users. 5 users reveal ~85% of usability problems (Nielsen's law). The fastest audit tool is watching one real user try to use the product.

Workflow

Step 1: Define the flow and success criteria

State the flow you're auditing and what success looks like:

  • Flow: [start state] to [end state] (e.g., landing page to first value moment)
  • Success: [specific action that means the user succeeded]
  • Current conversion/completion rate: [if known]

Step 2: Map every step in the flow

List every screen and decision point a user encounters. Include:

  • What the user sees
  • What the user must do (read, decide, input, wait)
  • What the user must remember from a previous step

Steps requiring memory or prior knowledge are friction points.

Step 3: Apply Krug's "trunk test"

For each screen: can a user who arrives with no context answer these questions in 5 seconds?

  • What site/product is this?
  • What page am I on?
  • What are the main sections?
  • What can I do here?
  • Where am I in the flow?
  • How do I get started?

If any answer requires more than a quick scan, there's a clarity problem.

Step 4: Identify cognitive load hotspots

Flag every step where the user must:

  • Read more than 50 words to proceed
  • Make a decision between more than 3 options
  • Remember something from a previous step
  • Understand jargon or insider terminology
  • Enter data that could be pre-filled or inferred

Step 5: Check for happy path bias

Most flows are designed for the happy path. Audit the non-happy paths:

  • What happens on validation error?
  • What happens if the user stops and returns later?
  • What happens if the user goes backward?
  • What happens on network failure?

Step 6: Prioritize findings

PriorityCriteria
P1Blocks completion of the flow for significant user segments
P2Adds significant friction but users can complete with effort
P3Minor confusion, edge cases, polish

Step 7: Write the audit report

UX Audit: [flow name]
Date: [date]
Flow: [start] to [end]
Current completion rate: [x]% (if known)

P1 Issues:
  [screen/step]: [problem] -> [impact] -> [recommended fix]

P2 Issues:
  [screen/step]: [problem] -> [impact] -> [recommended fix]

P3 Issues:
  [screen/step]: [problem] -> [recommended fix]

Quick wins (high impact, low effort):
  [list]

Anti-Patterns

1. Auditing without watching real users Bad: Designer audits their own flow based on their own understanding. Good: Watch 3-5 real users attempt the flow. Say nothing. Note where they hesitate, misclick, or ask questions.

2. Auditing only the happy path Bad: Audit covers only the ideal case (valid inputs, no errors, no confusion). Good: Explicitly test error states, re-entry, and edge cases.

3. P1 everything Bad: Every finding marked critical. Good: Prioritize ruthlessly. One genuine P1 is worth more than 10 vague concerns.

4. Audit without a benchmark Bad: Findings with no baseline. Good: Know the current completion rate before the audit. After fixes, measure again.

Quality Checklist

  • Flow and success criteria defined before audit begins
  • Every step in the flow mapped including decision points
  • Trunk test applied to each screen
  • Cognitive load hotspots flagged (reading, deciding, remembering)
  • Non-happy paths audited (errors, re-entry, back navigation)
  • Findings prioritized P1/P2/P3
  • Each finding has a recommended fix direction
  • Quick wins (high impact, low effort) identified separately

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Generate A/B copy variants grounded in Eugene Schwartz's awareness and market-sophistication stages and John Caples' tested-headline discipline. Every variant declares its angle, the awareness stage it targets, and a falsifiable hypothesis, and the skill recommends which pair to test first and what delta counts as signal. Use when the user says "A/B test this", "write variants", "give me options", "test different angles", "copy variants", "ab copy", "test this headline", "multiple versions", "which version is better", or wants to test copy before publishing. For reviewing copy that already exists, see copy-review. For sample size and stopping rules, see growth-experiment. For diagnosing a page rather than its words, see page-cro. For full paid ad sets by platform, see ad-campaign-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write measurable acceptance criteria for requirements or user stories. Use when the user says "write acceptance criteria", "definition of done", "how do we test this", "fit criteria", "given when then", "Gherkin scenarios", "what does done look like", "testable conditions", "how will we know this works" - even if they don't explicitly say "acceptance criteria".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Build a strategic account plan for winning, retaining, or expanding a named account. Use when the user says "build an account plan", "strategic account planning", "how do I grow this account", "account expansion strategy", "whitespace analysis", "QBR prep", "key account review", "map the stakeholders in this account", "land and expand plan", "how do I break into [company]", or wants a structured strategy for a specific account.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write paid ad copy for LinkedIn, Google, Meta, and YouTube. Produces multiple variants per platform, each targeting a different Eugene Schwartz awareness level and Cialdini persuasion principle. Use when the user asks for ad copy, ad variants, "write LinkedIn ads", Google ads, Meta ads, paid social copy, ad headlines, or wants creative for a paid campaign. Reads brand voice, ICP, and positioning from knowledge/. For organic social posts, see linkedin-post or social-calendar. For the landing page the ad points at, see landing-page-writer. For testing variants, see ab-copy-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Design clean and consistent APIs. Use when the user says "design an API", "API design review", "design these endpoints", "REST API for X", "GraphQL schema", "API contract", "how should this endpoint work", "review my API design", or wants to create or improve an API interface - even if they don't explicitly say "API design".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

qa-aman のスキルをすべて見る

このスキルの問題を報告する