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

design-critique

Critique a design for usability, hierarchy, and accessibility. Use when the user says "critique this design", "review this screen", "what's wrong with this UI", "design feedback", "UX review", "how can I improve this", "review my mockup", "is this good UX", or shares a design and wants structured feedback - even if they don't explicitly say "design critique".

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.7 KB

SKILL.md(原文)

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

Overview

Based on "The Design of Everyday Things" by Don Norman. Norman's framework: good design makes the right action obvious and the wrong action difficult. Bad design forces users to think when they should act. A critique is not about aesthetics - it's about whether the design communicates correctly: what can I do here, how do I do it, and did it work?

Norman's three key concepts:

  • Affordances - what actions does the design suggest are possible?
  • Signifiers - what cues communicate where and how to act?
  • Feedback - does the system communicate the result of every action?

Workflow

Step 1: Define the user goal

Before critiquing, state: what is the user trying to accomplish on this screen? Critiques without a user goal produce aesthetic feedback, not usability feedback.

Step 2: Check affordances and signifiers

Walk through every interactive element:

  • Is it obvious this is clickable/tappable/draggable?
  • Does the visual design suggest the correct interaction?
  • Are buttons distinguishable from static content?
  • Does the hierarchy direct attention to the primary action?

Norman: "If it requires a label, the design has failed."

Step 3: Check feedback

For every action a user can take:

  • Is there immediate visual feedback that the action registered?
  • Are loading states communicated?
  • Are success and error states clearly differentiated?
  • Does error feedback tell the user what to do next, not just what went wrong?

Step 4: Apply Nielsen's 10 Heuristics

Scan the design against each heuristic:

  1. Visibility of system status - does the user always know what's happening?
  2. Match with real world - does language and metaphor match user expectations?
  3. User control and freedom - can users undo, escape, or cancel?
  4. Consistency and standards - does it follow platform conventions?
  5. Error prevention - does the design prevent mistakes before they happen?
  6. Recognition over recall - are options visible, not memorized?
  7. Flexibility and efficiency - does it serve both novice and expert users?
  8. Aesthetic and minimalist design - is every element earning its place?
  9. Help users recognize, diagnose, recover from errors - are errors human-readable?
  10. Help and documentation - is help available when needed?

Step 5: Check accessibility

  • Color contrast ratio >= 4.5:1 for normal text, 3:1 for large text (WCAG AA)
  • Interactive targets >= 44x44px (mobile), >= 24x24px (desktop)
  • No information conveyed by color alone
  • Focus states visible for keyboard navigation

Step 6: Write the critique

Structure as:

  • Works well - what the design gets right (always include this)
  • Critical issues - prevents task completion, must fix
  • Usability issues - adds friction, should fix
  • Polish - optional improvements

For each issue: describe the problem, explain the impact, suggest a solution.

Anti-Patterns

1. Aesthetic critique instead of usability critique Bad: "The blue is too dark. I'd try a lighter shade." Good: "The CTA button doesn't have enough contrast against the background. Users with low vision may not see it as actionable. Test with contrast ratio >= 4.5:1."

2. Critique without knowing the user goal Bad: Generic feedback about layout without understanding what the user is trying to do. Good: "Given that the primary goal is checkout completion, the payment form should be the dominant element. Currently the promotional banner competes with it."

3. No positive feedback Bad: Only problems listed. Good: Name what's working. It tells the designer what to preserve and builds trust in the critique.

4. Solutions without problems Bad: "Make the button bigger." Good: "The CTA is competing with 3 other buttons of equal weight. Users don't know where to look first. Establish a clear visual hierarchy."

Quality Checklist

  • User goal stated before critique begins
  • Affordances and signifiers reviewed for every interactive element
  • Feedback reviewed for every user action
  • Nielsen's 10 heuristics scanned (at least the relevant ones)
  • Accessibility: contrast, touch targets, color-as-information
  • Critique has positive feedback section
  • Issues classified: critical / usability / polish
  • Every issue paired with a suggested direction (not just a problem)

レビュー

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

同じリポジトリのスキル

概要と使いどころ

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 のスキルをすべて見る

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