design-critique について
Design Critiqueは、デザインへのフィードバックやレビューを構成するスキルです。意図の確認、トレードオフや原則の議論、制作面と好みの切り分けを重視します。
主な機能
- 01観察・原則・質問のフィードバック形式
- 02意図の確認から始める批評
- 03トレードオフを軸にした意見
- 04制作面と好みの切り分け
- 05構成化されたレビューの進行案
活用シーン
- 01チームのデザインレビューの進行
- 02具体的で命令形でないフィードバック
- 03原則と好みの区別
- 04批評の受け止めと振り返り
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ dragoon0x/ taste-skills --skill design-critiqueインストール後、Claude Code で/design-critiqueを入力して読み込まれたか確認します。
詳細
デザイン批評
より良い批評の構成。より良いデザインの成果物。
使い方
/design-critiqueこの会話でのフィードバックに、デザイン批評の制約を適用します。
制約
批評の形式
- フィードバックのすべての項目で、必ず「観察 > 原則 > 質問」の形式を使ってください。
- 評価に入る前に、必ず意図を尋ねてください:「何を最適化しようとしていましたか?」
- 欠点ではなくトレードオフを必ず挙げてください:「情報密度を高める選択により、パワーユーザーは素早くアクセスできますが、初めて使う人には圧倒的に感じられます」
- クラフトに関するフィードバック(配置、統一感)と、好みに関するフィードバック(そもそもこれを存在させるべきか)を必ず分けてください。
- フィードバックを指示の形で伝えてはいけません(「ボタンを青くしてください」)。方向性を示してください(「CTAをもっと視覚的に際立たせる必要があります」)。
批評セッションの進め方
- 5分:全員が黙って、具体的な観察を3つ書き出します。曖昧な言葉は使いません。
- 10分:順番に回り、一人ずつ観察を1つ共有します。重複は避けます。
- 10分:意見の相違について話し合います。異なる見方があるところに、学びが生まれます。
- 5分:原則を言語化します。このレビューから得られる教訓を一文にまとめます。
フィードバックを受けるとき
- 反応する前に、まず「なぜ」と尋ねることが望ましいです(防御的にならず、心から尋ねます)。
- 好みに関するフィードバックと、原則に関するフィードバックを必ず区別してください。
- 同意できないフィードバックも書き留めることが望ましいです。1日後に見直してください。
アンチパターン
- 何も学べない曖昧な称賛(「すばらしいですね!」)
- 方向性を示す質問ではなく、指示を出す
- コンセプトへの批評と、実行への批評を同時に混ぜる
- 最も役職の高い人が最初に発言する(場の意見を固定してしまいます)
コメント
Markdown 対応