critique

critique skill の概要

critique skill でできること

critique skill は、ページ・機能・コンポーネントを単なる見た目のモックとしてではなく、実際のユーザー体験として評価するための、構造化された UX / プロダクトデザインレビューのワークフローです。critique skill は、視覚的ヒエラルキー、情報アーキテクチャ、感情的トーン、認知負荷、ユーザビリティヒューリスティクス、ペルソナごとのつまずきポイントまで確認し、それを実行可能なフィードバックへ落とし込むようモデルを導きます。

critique skill を導入すべき人

この critique skill は、すでに画面・プロトタイプ・リリース済み UI があり、「この UI にフィードバックをください」のような汎用プロンプトより一段深いレビューを求めるプロダクトデザイナー、フロントエンドエンジニア、創業者、AI ビルダーに特に向いています。とくに、UX Audit 用の critique、リリース前のデザイン QA、あるいは「この UI はありきたりに見えるか」「わかりにくいか」「重たく感じるか」を見極めたいときに有用です。

実際に解決したい仕事

多くのユーザーが欲しいのは、単なる感想ではありません。知りたいのは次のようなことです。

• 体験を最初に損ねている要因は何か
• UI が既視感のあるもの、あるいは「AI-generated」っぽく見えていないか
• 問題が見た目だけのものか、コンバージョンを阻害するものか
• 専任のデザインチームがなくても、どの順で直すべきか

この skill は、そうした実務上の判断を支えるために設計されています。critique をスタイル批評ではなく、意思決定のためのツールとして扱う構成になっています。

この critique が他と違う点

最大の差別化ポイントは、文脈を重視することと、「AI slop detection」の工程が入っていることです。表面的なコメントにすぐ飛びつかず、まずデザインの文脈を前提にし、そのうえで 2024〜2025 年によく見られる AI プロダクト特有のパターン――汎用的なカードグリッド、光彩を多用したダークテーマ、弱いヒエラルキー、テンプレート然とした構成――が出ていないかを明示的に確認します。

さらに、単一のレビュアー視点にとどまらず、以下を組み合わせる点も特徴です。

• design-director 風の critique
• cognitive load analysis
• heuristic scoring
• persona-based testing

導入前に知っておきたい注意点

critique は完全に単独では使えません。リポジトリでは、原則や文脈収集のために frontend-design を必須依存としており、デザインコンテキストがまだない場合は先に teach-impeccable を実行するよう案内されています。セットアップなしですぐ使える critique を期待しているなら、この依存チェーンが導入前にもっとも重要な確認ポイントです。

critique skill の使い方

critique に頼る前に前提コンテキストを入れる

このリポジトリでは critique は .claude/skills/critique 配下に置かれており、skill 本文でも /frontend-design への依存が明記されています。実運用では、このフォルダだけを単独のプロンプトファイルとして扱うより、impeccable 一式を入れた状態で使うほうが critique は機能しやすいです。

利用中の skill runner が GitHub からの skill インストールに対応しているなら、リポジトリごと導入したうえで、critique、frontend-design、teach-impeccable の 3 つが使える状態か確認してください。

最初に読むべきファイル

導入判断を手早くしたいなら、まず以下を確認してください。

• SKILL.md
• reference/cognitive-load.md
• reference/heuristics-scoring.md
• reference/personas.md

この順で見れば、前提条件、レビュー手順、スコアリングモデル、ユーザーテストの視点まで、重要な点をほぼ把握できます。

critique skill が必要とする入力

critique skill は、次の情報を渡すと精度が大きく上がります。

• 対象となる UI アーティファクト: スクリーンショット、モック、URL、またはコンポーネント説明
• レビュー対象の範囲: page、flow、modal、dashboard、onboarding、settings など
• ユーザーの主要ゴール
• プロダクトの文脈と想定ユーザー
• 制約条件: mobile/desktop、B2B/B2C、accessibility、conversion、技術的制約

こうした前提がない場合でも、レイアウトや見た目についてのコメントはできますが、その UI がタスクに対して適切かどうかまでは判断しづらくなります。

あいまいな依頼を強い critique プロンプトに変える

弱いプロンプト:

• “Critique this UI.”

より良い critique の使い方:

• “Use the critique skill on this onboarding flow. The product helps finance teams close books faster. Primary goal: get a first report generated in under 5 minutes. Audience: mid-market accounting teams. Constraint: desktop web app, dense data is acceptable but first-time clarity matters. Please evaluate AI-slop signals, hierarchy, cognitive load, heuristic score, and test it as a first-timer and power user.”

後者のほうがうまく機能するのは、単に反応する対象を渡しているのではなく、何を最適化すべきかを skill に与えているからです。

リポジトリが求める事前準備に従う

この skill では、先に /frontend-design を実行し、そのコンテキスト収集プロトコルに従うことが明記されています。デザインコンテキストがまだなければ、critique の前に /teach-impeccable を走らせる前提です。つまり、想定ワークフローは次の通りです。

1. デザインコンテキストを集める
2. その UI が何を達成しようとしているかを理解する
3. その目標に照らして critique を実行する
4. 優先順位付きのフィードバックを返す

特に 2 を省くと、モデルが「意図された情報密度」と「単に設計が悪い状態」を見分けられず、出力が汎用的になりがちです。

UX Audit 用の critique として使う

UX Audit 用の critique で使うなら、単に「フィードバックください」で済ませないほうがいいです。以下を求めてください。

• 深刻度順の主要課題
• heuristic scoring summary
• 離脱が起きそうなポイント
• ペルソナ別の失敗パターン
• 具体的な再設計の提案

これにより、ただのコメントから、ステークホルダーがそのまま動ける監査レベルのアウトプットに変わります。

このワークフローが実際に見ていること

リポジトリを見る限り、critique skill が特に強いのは、次の観点の点検です。

• AI-generated design にありがちな没個性
• 視覚的ヒエラルキーの問題
• 認知的な過負荷
• 弱い情報アーキテクチャ
• 不明瞭なインタラクションパターン
• usability heuristic の抜け漏れ
• 画面のトーンとユーザーニーズの不一致

そのため、新規コンセプトの発散よりも、すでに存在する、あるいは実物に近い UI の評価に向いています。

おすすめの critique 活用フロー

実務で使いやすい流れは次の通りです。

1. 画面と目標を集める
2. ユーザータイプと成功条件を明示する
3. プロダクト全体ではなく、特定の領域に対して critique をかける
4. まず重大度の高い上位 3 件を確認する
5. 制約を明確にしたうえで、修正版の提案を求める
6. 次の flow に移る

critique skill は、ページ単位・フロー単位で回したほうが、プロダクト全体を一度に見せるよりもシグナルが濃くなりやすいです。

依頼範囲をうまく切る方法

良いスコープ:

• signup flow
• pricing page
• analytics dashboard
• settings panel
• empty state
• mobile checkout

悪いスコープ:

• “the whole app”
• “our design system”
• “everything on the website”

この skill はかなり細かく見に行くため、対象範囲が広すぎると出力が浅くなります。レビュー範囲を絞るほど、指摘の具体性と優先順位付けは改善します。

出力品質を上げる実践的なコツ

より良い critique を得るには、少なくとも次を入れるのがおすすめです。

• ビジネス目標を 1 文で
• ユーザーの切迫度を 1 文で
• 成功状態を 1 文で
• モデルに勝手に「解決」してほしくない既知の制約

例:

• “This page exists to get a team admin to invite coworkers immediately after signup. Speed matters more than education. We cannot remove required compliance messaging.”

こうした入力があると、skill は本当の欠陥と、必要な複雑さを切り分けやすくなります。

critique skill の FAQ

critique は普通の UX プロンプトより優れている？

たいていは Yes です。特に、再現性のあるレビュー手法が欲しいなら有利です。critique skill の価値は、魔法のようなデザインセンスではなく、組み込み済みの構造にあります。つまり、前提コンテキスト、アンチパターン検出、heuristic scoring、cognitive load の枠組み、persona testing が最初から入っている点です。通常のプロンプトでもそれなりの意見は得られますが、一貫性に欠けやすく、無難な称賛へ流れやすい傾向があります。

critique は初心者向き？

基本的には Yes ですが、ひとつ注意があります。frontend-design と、場合によっては teach-impeccable に依存している点です。初心者でも使えますが、準備なしで単発プロンプトを投げるというより、意図されたワークフローを数分かけて把握する前提で考えたほうがいいです。

critique が向かないケースは？

次の条件なら、この critique skill は見送ったほうがいいです。

• デザインレビューよりコード生成が必要
• まだ UI ではなく曖昧なプロダクトアイデアしかない
• まず brand strategy や copywriting を詰めたい
• ユーザーやプロダクトの文脈をまったく出せない

見た目だけにコメントすることは可能ですが、そこはこの skill のいちばんの強みではありません。

critique は完成度の高い UI にしか使えない？

いいえ。wireframe、粗いモック、初期段階のコンポーネントにも有効で、とくに hierarchy や cognitive load の確認に向いています。ただし、persona testing や heuristic scoring は、インタラクションモデルがある程度見える状態のほうが信頼しやすくなります。

単一コンポーネントにも critique は使える？

使えます。重要なのは、そのコンポーネントが文脈の中で実際の役割を持っていることです。filter panel、modal、table、form などは、いずれも critique の対象になります。どこに出るのか、誰が使うのか、何を完了しようとしているのかを添えてください。

どんな出力を期待すべき？

良い critique の出力には、次の内容が含まれているはずです。

• 主な UX リスク
• 深刻度または優先順位
• その問題が重要な理由
• 何を変えるべきかの具体例
• 表面的な磨き込みと、構造的な UX 問題の明確な切り分け

結果が形容詞ばかりなら、たいていはプロンプト側の文脈不足です。

critique skill を改善するには

画面だけでなく成功指標を渡す

critique の出力を最短で改善する方法は、意図するユーザー成果を明示することです。“Review this dashboard” よりも、“Review this dashboard for whether a new manager can spot blockers in under 30 seconds.” のほうが強いです。成功指標があると、その後のあらゆる判断が鋭くなります。

想定ユーザーとプロダクト成熟度を伝える

同じ UI でも、次のどれに当てはまるかで評価は変わります。

• 密度の高い B2B ツールを使いこなす expert operators には適切
• 初回利用の consumer には不適切
• internal tooling なら許容範囲
• premium な customer-facing product としては弱い

想定ユーザーと成熟度を示せば、critique skill は一般論の UX アドバイスに流れず、トレードオフ込みで判断しやすくなります。

ペルソナ選定を明示的に依頼する

リポジトリには複数の persona が含まれていますが、毎回すべてが有効とは限りません。UX Audit 用の critique を改善したいなら、どのユーザータイプを重視すべきかを明示してください。たとえば次のような指定です。

• first-timer
• power user
• cautious admin

これにより、関係の薄い失敗パターンに出力が散るのを防げます。

初回レビュー後に優先順位付けを強制する

よくある失敗は、観察結果の長い羅列で終わり、意思決定に使えないことです。最初の critique のあとに、次のように聞いてください。

• “Which 3 issues most threaten task completion?”
• “Which issue is most likely to reduce trust?”
• “What should be fixed before launch versus later?”

こうすることで、分析をそのままアクションプランへ変えやすくなります。

モデルが守るべき制約を渡す

UI に次の条件を維持する必要があるなら、

• data-dense
• enterprise-looking
• compliant
• on-brand
• mobile-first
• low-engineering-effort

といった点をはっきり伝えてください。そうしないと、critique は見た目はきれいでも現実的ではない再設計案を出しがちです。

汎用的な “AI slop” への過剰反応に注意する

この critique skill の長所のひとつは、AI っぽい量産型パターンを検出できることです。ただし、だからといって「今っぽい定番」をすべて排除して独自性だけを追うのは逆効果になりえます。大事なのは、単に違うことではなく、そのデザインが適切で見分けがつくことです。このセクションは雑な類似性を見つけるために使い、修正案は必ず usability の観点でも検証してください。

Before / After の反復で入力を改善する

ベストプラクティスは次の流れです。

1. 現在のデザインに対して critique を実行する
2. 大きな変更を 2〜3 件反映する、または試作する
3. 修正版に対してもう一度 critique を実行する
4. 主要なリスクが実際に下がったか比較する

critique は、一度きりの判定として使うより、反復的なデザインループの中で使うほうが価値が高くなります。

critique の出力が弱く感じるよくある理由

たいていは次のどれかが不足しています。

• ユーザーゴールがない
• プロダクト文脈がない
• スコープが広すぎる
• 制約がない
• 点検できるだけの品質の artifact がない
• “thoughts” のような曖昧な依頼で、レビュー構造が定義されていない

これらを補うと、critique ガイドの実用性は大きく上がります。

より良い critique 用の強いプロンプトテンプレート

次のようなプロンプトを使ってください。

• “Use the critique skill on [area].
• Product: [what the product does]
• Audience: [who this is for]
• Primary task: [what the user needs to do]
• Success metric: [what success looks like]
• Constraints: [platform, compliance, technical, brand]
• Review for: AI-slop signals, hierarchy, cognitive load, heuristics, and 2 relevant personas.
• Output: top issues, severity, why they matter, and concrete fixes.”

このテンプレートは、リポジトリが想定している critique の動かし方にかなり沿っており、自由入力の依頼よりも高いシグナルを得やすいです。