デザインクリティークのフレームワーク:本当に作品を良くするレビューの進め方
現場のデザイナーが書く、デザインクリティークの進め方と受け方のガイド。レビューを自己防衛の場から本物のフィードバックの場に変える、フレームワーク、ルール、構造を解説します。

ほとんどのデザインレビューは茶番だ。シニアデザイナーがボタンの色について20分しゃべり、ジュニアデザイナーはうなずき、作品は何も変わらないまま、あるいは悪化してリリースされる。誰も何も学ばず、作品は良くならず、チームを鋭くするはずだった会議が憂うつの種になる。
このペーパーは実践版だ。クリティークを道具に変えるフレームワーク、エゴを部屋に持ち込ませないルール、そして画面に作品が映っている本人にとって本当に役立つフィードバックの構造をまとめた。「デザインカルチャー」的な美辞麗句も、マニフェストもない。あるのは、レビューがうまいからこそ良い作品を出せているチームの運用手順だけだ。
デザインクリティークとは何か
デザインクリティークとは、制作途中の作品に対する構造化されたピアレビューである。 目的は、デザイナーが自分のドラフトの内側からは見えない問題を洗い出し、リリース前にユーザー、ブリーフ、システムに照らして作品を検証することだ。クリティークは承認ではなく、支持表明でもなく、投票でもない。
クリティークはプレゼンでもない。デザイナーは作品を擁護するためにそこにいるのではない。レビュアーは作品を賞賛するためにそこにいるのでもない。双方が、現在の作品より次のイテレーションを良くするためにそこにいる。
デザインポートフォリオガイドでは、個々の作品が外部からどう評価されるかを扱っている。このペーパーは社内チームのレビューを深掘りする。目的もルールもまったく違うからだ。
なぜほとんどのクリティークは失敗するのか
クリティークに苦労しているチームのほぼすべてで、同じ5つの失敗が起きている。会議が消耗するだけで作品が良くならないなら、まずここを見てほしい。
デザイナーが質問せず、プレゼンしている。 作品が最初から最後まで説明され、レビュアーは礼儀正しく待ち、具体的なフィードバックは求められない。範囲が決まっていないので、レビュアーは抽象的な感想に逃げる。
レビュアー同士が競っている。 全員が最も賢い指摘を最初に見つけようとする。議論は一番シニアっぽく聞こえる人の方向へ流れる。デザイナーは矛盾する12個の意見を抱え、進むべき道が見えないまま帰ることになる。
個人の好みが原則の顔をしている。 レビュアーが書体を気に入らないだけなのに、階層の問題として語る。別のレイアウトパターンが好きなだけなのに、アクセシビリティの問題として語る。フレームワークがなければ、好みが勝つ。
誰も書き留めない。 会話は行われ、会議は終わり、デザイナーが覚えているのはせいぜい3割。次のクリティークでは同じ話をなぞることになる。
クリティークが遅すぎる。 作品はすでに9割完成している。大きな構造変更のフィードバックは、時間がないので無視される。クリティークは仕上げの磨きに格下げされる。
どれも直せる。その直し方が、このペーパーの残りだ。
3層フィードバックモデル
有用なデザインフィードバックは、必ず3つの層のどれかに収まる。自分がどの層の話をしているか言えるレビュアーは、焦点がぶれない。言えないレビュアーは、好みの話に流れていく。
第1層:観察
観察とは、レビュアーが画面上で文字通り目にしているものだ。解釈も判断も入れない。
「1440幅のビューポートでは、CTAがフォールドの下にある」。これは観察だ。「ボタンが小さい」。これも観察だ。「このページには3種類の異なるサンセリフ(セリフなし書体)が見えている」。これも観察だ。
観察は議論の余地がない。デザイナーはその場で画面上で確認できる。どちらの側からも反論できないので、最も安全な層だ。
第2層:解釈
解釈とは、その観察がユーザー、ブランド、システムにとって何を意味しうるか、ということだ。
「CTAがフォールドの下にあるということは、モバイルユーザーはページが何を求めているのかに気づく前に、おそらくそれを通り過ぎてスクロールしてしまう」。これは解釈だ。「3種類のサンセリフは一貫性がないように見え、ユーザーにブランドボイスが不明確だという信号を送る」。これも解釈だ。
解釈は議論に開かれている。同じ観察でも、二人が別々に解釈することがある。そこがクリティークの生産的な部分だ。解釈の層で、チームの集合的な経験が、デザイナー個人のドラフトに価値を加える。
第3層:提案
提案とは、その解釈を受けてレビュアーが検討しそうな対処のことだ。
「CTAをフォールドの上に移すか、スクロール時にスティッキーCTAを出すのを試してみてもいい」。これは提案だ。「本文用と見出し用でサンセリフを1つずつに絞り、簡単なスクイントテストで階層を確認してみてもいい」。これも提案だ。
提案を採用するかどうかはデザイナーの自由だ。作品の持ち主はデザイナーである。レビュアーが差し出すのは選択肢であって、命令ではない。提案が強制になるクリティークはクリティークではなく、指揮命令系統だ。

本当に機能するクリティークのフレームワーク
フレームワークは会議の台本だ。その場でフィードバックの出し方を考える認知負荷を取り除き、レビュアーが作品そのものに集中できるようにする。
フレームワーク1:ゴール、根拠、フィードバック
最も早く導入できるフレームワーク。3ステップで、1作品あたり10分。
ステップ1:デザイナーがゴールを述べる。 「ホームページからワンクリックで有料登録まで、ユーザーを連れていくことを狙っています」。最大2文。
ステップ2:デザイナーが根拠を説明する。 「前回のテストでコンバージョンの60%がフォールドの上で起きていたので、CTAをヒーローに置きました。ブランドがプライマリアクションに使う色なので、緑を選びました」。最大3分。
ステップ3:レビュアーがゴールに照らしてフィードバックする。 すべてのコメントは、述べられたゴールに結びついていなければならない。「CTAはゴールを支えているか?」であって、「CTAはこの緑で正しいか?」ではない。
ゴールに結びつかないフィードバックは、別のリストに退避させて後回しにする。会議の焦点は保たれる。デザイナーは明確な進路を持って帰れる。
フレームワーク2:I Like、I Wish、What If
IDEOから借りてデザインチーム向けに調整したもの。作品が初期段階で探索的なときに役立つ。
I like(良いと思う点): 機能している部分。レビュアーは、作品が残すべきだと思う具体的な要素を挙げる。ほとんどのクリティークが飛ばしてしまう、ポジティブな観察を強制する。
I wish(こうだったらいいのに): レビュアーが変えたい点。命令ではなく願いとして言う。「見出しと本文のコントラストがもっと強ければいいのに」。
What if(もし〜だったら): 推測に基づく代替案。「CTAがインラインではなくスティッキー要素だったらどうだろう?」。デザイナーが考えていなかった方向を開く。
このフレームワークが効くのは、ハードルを下げるからだ。願いや「もしも」は協力的に響く。直接的な批評は、そのつもりがなくても対立的に感じられることが多い。
フレームワーク3:ディシジョンスタック
何をリリースするかをチームが決める、後期段階の作品に最適。
必要な決定: デザイナーは具体的に何の決定を必要としているのか。「セカンダリCTAは残すか、削るか?」であって、「このモックアップを見て」ではない。
テーブルの上の選択肢: デザイナーは何を検討したのか。却下した代替案も見せる。レビュアーは、特定の選択肢がなぜ外されたのかを尋ねられる。
推奨: デザイナーは何を推奨し、それはなぜか。
リスク: その推奨で何がうまくいかない可能性があるか。
レビュアーの仕事は、推奨をリスクに照らして試すことだ。デザイナーはリスクを見落としていないか。リスクの重みづけは正しいか。推奨は、示された選択肢の中で本当に最も強いか。
このフレームワークは、デザイナーに会議の前に仕事を済ませることを強いる。会議は、ゼロから新しい思考を生み出す場ではなく、思考を試す場になる。

部屋を機能させ続けるルール
フレームワークは会議を構造化する。ルールは、その中での振る舞いを律する。ルールがなければ、どんなに優れたフレームワークも、前回うまくいかなかったのと同じゆるい雑談に崩れてしまう。
ルール1:フィードバックの範囲はデザイナーが決める
クリティークを始める前に、デザイナーはどんなフィードバックがほしいかを述べる。「階層とCTAについてフィードバックがほしいです。カラーパレットは確定、コピーも最終です」。これでデザイナーの時間とレビュアーの注意力が守られる。
レビュアーが範囲外のことに触れたければ、会議の後か別のセッションのためにメモしておく。クリティークを脱線させない。
ルール2:一度に一つの会話
横の会話はクリティークを殺す。肝心なのは、一つの作品に全員の注意を集めることだ。レビュアー二人が内輪で議論を始めたら、ファシリテーターが全体に引き戻す。話すべきことが3つあるなら、並行ではなく順番に話す。
ルール3:一般論より具体論
「なんかしっくりこない」はフィードバックではない。「CTAがグラデーション背景に対してコントラストを失っていて、おそらくライトモードでの視認性を損ねている」ならフィードバックだ。一般的な感想しか言えないレビュアーには、具体的に言うか、パスするよう求める。
ルール4:観察なき処方箋は禁止
レビュアーは、変更のきっかけとなった観察を先に述べずに、変更を勧めてはならない。「ボタンを青にして」は、観察のない処方箋だ。「今の赤いボタンはエラー状態に近く見えるので、重要なフローでユーザーを混乱させるかもしれない。青か、別の赤を試してもいい」は、観察、解釈、提案だ。
このルールは、チームが導入できる変更の中で最も強力だ。レビュアーに話す前に考えさせ、デザイナーには要求だけでなく理由を渡せる。
ルール5:すべて記録する
部屋の誰かがメモを取る。観察、解釈、提案、決定、フォローアップ。デザイナー自身は記録係になってはいけない。フィードバックに応答するだけで認知的に手一杯だからだ。
メモは会議の直後にデザイナーへ共有される。デザイナーは各メモを、採用、理由付きで却下、後回しのいずれかにマークする。次のクリティークは、前回から何が変わったかの確認から始まる。
ルール6:時間を区切り、成果を定義する
クリティーク会議には厳格な終了時刻がある。各作品には固定の枠、通常15〜30分が割り当てられる。ファシリテーターがそれを守らせる。長引かせるのは、チームの熱量を失い、人々が会議に作品を持ち寄らなくなる最速の方法だ。
各枠は、明言された成果で終わる。「デザイナーがCTAをフォールドの上に移し、グラデーション背景でのコントラストをテストする。v2は次回のクリティークで共有する」。成果がなければ、その会議は価値を生まなかったということだ。
クリティークはいつ行うべきか
後期のクリティークは、ほぼ間違いなく遅すぎる。クリティークが最も効くのは、方向性の変更がまだ安く済む時点だ。
プロジェクトごとの3つのクリティークポイント
時間とともに改善する出荷された作品を生むための最小スケジュール:
| フェーズ | ゴール | フレームワーク |
|---|---|---|
| 方向性 | 正しい問題を解いているか? | I Like, I Wish, What If |
| ミッドフィデリティ | 構造は正しいか? | Goal, Rationale, Feedback |
| リリース前 | リリースできる状態か? | Decision Stack |
フェーズごとに目的が違い、合うフレームワークも違う。どれかを飛ばすと、予想どおりの失敗パターンが起きる。
方向性のクリティークを飛ばすと、チームは間違った解決策の磨き上げられたモックアップを完成させてしまう。発見が遅れれば、チームが犯しうる最も高くつくミスになる。
ミッドフィデリティのクリティークを飛ばすと、構造上の問題が高い忠実度の段階で見つかり、直すコストは5倍になる。やり直す時間がないので、チームは妥協した作品を出荷することになる。
リリース前のクリティークを飛ばすと、避けられたはずの問題が本番に出る。第二の目なしにシップドキュメントが書かれ、壊れた状態にはユーザーフィードバックで初めて気づく。
AIデザインワークフローの解説では、AIで加速したデザインループにクリティークを組み込む方法を扱っている。生成が速くなるほど、クリティークは重要でなくなるどころか、重要になる。
ファシリテーターの役割
ほとんどのデザインクリティークにはファシリテーターがおらず、だから崩壊する。ファシリテーターは、部屋にいるシニアデザイナーのことではない。会議を機能させ続ける責任を負う人のことだ。
ファシリテーターがやること
ファシリテーターが担うのは3つだ。
- 時間。 各作品は割り当てられた枠を守る。時間切れなら容赦なく打ち切る。後回しの項目はフォローアップリストへ。
- 焦点。 レビュアーが脱線したら引き戻し、フィードバックが曖昧なら確認の質問をし、会話が範囲外に移ったら指摘する。
- 記録。 自分でメモを取るか、誰かが取っていることを確かめる。メモは任意ではなく、会議の成果物だ。
ファシリテーターはクリティークをするためにいるのではない。会議の構造が整ってからなら、クリティークをしてもいい。進行とクリティークを混ぜると注意が分散し、ほぼ確実にどちらも質が落ちる。
役割は持ち回りにする
毎回同じ人が進行すると、その人がボトルネックになる。役割はチーム内で毎週か隔週で回す。ジュニアデザイナーは進行役から多大な恩恵を受ける。作品だけでなく会議そのものを構造的に考えざるを得なくなるからだ。
シニアデザイナーにも恩恵がある。クリティークする代わりに進行すれば、支配する代わりに聞くことを強いられる。多くのシニアデザイナーが過小評価しているスキルだ。
クリティークの受け方
クリティークのもう半分は、椅子に座るデザイナーの側になることだ。ほとんどのデザイン教育はこれを丸ごと飛ばす。その結果、作品をレビューされると防御的になり、自分に一番役立ったはずのフィードバックを退けてしまうデザイナーの世代が生まれた。
デザイナーのための5つのルール
応答する前に最後まで聞く。 選択を擁護するために割り込まない。フィードバックを受け止め、書き留め、それから確認の質問をする。擁護したくなる本能が、会議の価値を殺す。
観察と提案を切り分ける。 レビュアーが納得できない修正案を出しても、根底にある観察は妥当かもしれない。観察は受け取り、提案は置いて、自分なりの解決策を見つける。
「そうか」ではなく「なぜ」を聞く。 「なぜCTAがコントラストを失っていると思いますか?」は有益な続きを生む。「CTAがコントラストを失っていると思いますか?」は、会話を終わらせるイエスかノーを生む。
反応は保留する。 強く刺さるフィードバックは、書き留めて後で返す。その場の防衛は、双方にひどい応答を生む。24時間置けば、ほぼ必ず良い答えが出る。
決定は自分のものにする。 作品の持ち主はデザイナーだ。クリティークの後、何に対応するかを決めるのはデザイナーである。レビュアーは選択肢を出すのであって、命令はしない。デザイナーの仕事は、フィードバックをプロジェクトについて知っている他のすべてと天秤にかけ、決めることだ。

2026年の条件でのクリティーク
デザインクリティークの働き方を変えた3つの変化がある。仕組みはその3つすべてに適応しなければならない。
リモートと非同期のクリティークがデフォルトだ。 全員が一つの部屋に集まる会議はまれになった。クリティークは今、Figmaのコメント、Loomの録画、共有ドキュメントの中で行われる。フレームワークは今も機能し、ファシリテーションも重要だが、タイミングが変わる。非同期のクリティークには、明確な依頼、明確な締め切り、明確な決定ポイントが必要だ。それがなければ、コメントの墓場になる。
AI生成の作品こそ、より多くのクリティークが必要だ。 数秒で選択肢を生成するツールは、作品が「ただのAI出力」だからとクリティークを省きたくさせる。まさにそのときこそクリティークが最も重要なときだ。AI生成の作品は、デフォルトでは誰も責任を負わない。人間によるクリティークが、それに責任を持たせる。
職種横断のクリティークがいまや標準だ。 エンジニア、PM、コンテンツデザイナーが、ビジュアルデザイナーと同じクリティークに座る。フレームワークは全員に通用する。語彙は平らにする必要がある。「アフォーダンス」や「フォールドの上」は構わないが、会議全体がデザイナーの専門用語だらけだと、非デザイナーは離脱する。
デザインハンドオフの用語集では、クリティークがより広いハンドオフの規律とどう結びつくかを扱っている。共有できる成果物を生まないクリティークは、ハンドオフを生き延びられないクリティークだ。
FAQ
デザインクリティークのフレームワークとは?
フレームワークとは、デザインレビュー会議を進めるための構造化された台本だ。誰がいつ話すか、どんなフィードバックを求めるか、会議をどう終えるかを定める。最も一般的なのは、Goal-Rationale-Feedback、I Like-I Wish-What If、Decision Stackの3つ。それぞれ作品の異なる段階に合う。
良いデザインフィードバックはどうすれば出せる?
3層モデルを使う。まず観察(見えているもの)、次に解釈(それが意味しうること)、最後に提案(検討しそうな対処)。どの層を飛ばしてもフィードバックは弱くなる。観察を丸ごと飛ばせば、フィードバックは処方箋になり、デザイナーに退けられてしまう。
デザインクリティーク会議はどれくらいの長さがいい?
1作品あたり15〜30分で、厳格に時間を区切る。1作品に60分かけるクリティークは、ほぼ確実に範囲が広すぎるか、フレームワークが不適切だ。各枠に上限を設け、成果を記録して次へ進む。ほとんどのチームは、1回のセッションで2〜4作品をクリティークしている。
デザインチームはどれくらいの頻度でクリティークを行うべき?
定期的にリリースする小さなチームなら、週1回が基本線。プロジェクトサイクルが長いチームなら隔週でも機能する。スケジュールそのものより、継続性のほうが重要だ。1年間毎週クリティークを続けるチームは、誰かが頼んだときだけ場当たり的にやるチームより速く成長する。
クリティークが個人攻撃にならないようにするには?
フレームワークを入れ、ルールを入れ、ファシリテーターを持ち回りにする。フレームワークは観察と処方箋を切り分けるが、個人的に感じられるクリティークの多くはそこから始まる。ファシリテーターが、ついやってしまう失言を拾う。時間が経つにつれ、チームは構造を内面化し、個人的に感じられるクリティークは、そうした言葉がもう成り立たなくなるので起きなくなる。
シニアデザイナーにクリティークするには?
他の誰にするのとも同じやり方で。3層モデルを使い、フィードバックを述べられたゴールに結びつけ、決定はシニアデザイナーに委ねる。クリティークを受け入れられないシニアデザイナーは、クリティークそのものより大きな問題だ。シニアの作品のレビューを黙って避けるチームは、妥協したシニアの作品を出荷するチームである。
クリティークは会議ではなく、規律だ
クリティークをうまく運用するチームは、問題を早く見つけ、各決定により多くの視点を得て、デザイン品質についての共通語彙を育てるので、より良い作品を出荷する。下手に運用するチームは、ムラのある作品か、磨かれているが的外れな作品を出荷し、毎週開いている会議がなぜ役に立たないのかと首をひねる。
解決策は構造にある。フレームワークを選ぶ。ルールを入れる。クリティークは最後ではなく、プロジェクトごとに3つのポイントで設定する。成果を記録する。ファシリテーターを持ち回りにする。防御せずにクリティークを受ける。処方せずにクリティークを出す。
この規律を導入するコストは、チームが慣れるまでの2、3回の会議の軽い居心地の悪さだ。見返りは、プロジェクトごとに鋭くなるチームと、一番声の大きい人の意見に向かって後退するのではなく、時間とともに良くなっていく作品群である。
すべてのプロジェクトでこの規律を実践するチームがほしいなら、Brainyに依頼してほしい。私たちは社内デザインチームに入り込み、ブランドやプロダクトの仕事と並行して、クリティークの仕組みを導入する。
関連記事
Want a design team that critiques without the drama and ships better work because of it? Brainy embeds with internal teams to install critique systems and ship product with the rigor baked in.
Get Started




