※ 本ノートは社内向けに作成したドキュメントをベースにしております。文中には指示語や断定的な表現が多く含まれますが、その点ご理解とご了承ください。以下のレビューの方法が少しでも皆様のお役に立てれば光栄です。

はじめに

ここでのデザインレビューとは、デザイナーが作成したデザインカンプを、上司やチームに確認してもらう機会のことを指します。
この時点では仕様書、設計書などはFIXして進めている事が前提となり、デザインレビュー段階での仕様などの指摘、変更は奨励しません。（※）
また、仮にデザインレビューの段階で仕様書、設計書に不備が発生した場合は、レビューを一旦止め、そこの見直しをした後、再び正しい仕様書に基づいたデザインカンプを基にデザインレビューを再開します。

※仕様書、設計書はデザインカンプ作成の前段階、ワイヤーフレーム（UIの設計）の段階でしっかり潰しておきましょう。

レビューの仕方

・何から話し始めたらいいのか分からない場合。

まずは、作成したデザインカンプが仕様書、設計書に基づき構成されたUIであることの説明をします。

ここで、仕様書、設計書に不備がある場合は、一旦レビューを止め、そこの見直しをした後、再び正しい仕様書に基づいたデザインカンプを基にデザインレビューを再開します。
また、この際に作成したカンプの説明ができない場合は、デザイナー側のスキル不足、準備不足になります。
このまま進めてもデザインレビューの効果が最大化されないので、潔く出直しましょう。

・「仕様書に基づいたUIの説明」が具体的にどのようなものか分からない場合。

デザイナーは仕様書や設計書を基にワイヤーフレームに落とし込み、そこからデザインを作成するかと思います。レビュー時は、その作成したUI・デザインが仕様書通りのプライオリティで構成されたものであることを説明します。

例えば「この部分は仕様書に基づき、このような配置でレイアウトしました。」「この部分は仕様書に基づき、こちらの要素より強調したカラーで配色しました」など、ひとつひとつの構成要素の説明を丁寧にしていきます。

・レビュー時の仕様書にない提案をする場合。

「この要素はこちらの要素よりユーザーニーズが高いので、プライオリティを上げてみましたが、どうでしょうか。」など、ここで仕様書通りでない提案をする場合、なぜ仕様書と違うアウトプットをしたのか理由を添えて提案しましょう。それがレビュー時に提案として通ればそのままUIに落とし込み、通らなかったら仕様書の通りに作り直しましょう。ただし、基本は「仕様書の見直し」はワイヤーフレーム時に潰しておくべき事なので、概ね仕様書通り作る事が求められます。
また、やむを得ずこのタイミングで仕様書にない提案をする場合は「予め仕様書通り設計したもの」もきちんと準備しておきましょう。

・レビューのフローと時間構成

チームやプロジェクトの規模やプロダクトのボリュームによっても変わりますが、基本的には以下の順序がよろしいかと思います。

1. デザインカンプの解説（要素単位かページ単位かはレビュー前のアジェンダに盛り込んでおきましょう）：10分程度
2. デザイナー側からの提案（ある場合）：5分程度
3. 質疑応答（上記内容までの不明点がある場合の質疑応答）：5分程度
4. フィードバック（デザインカンプのフィードバック）（※）：10分程度
5. （修正点があった場合）修正個所のプライオリティ付け：5分程度
6. デザインレビューのまとめ：5分程度

※フィードバックに関して。
レビュー時にフィードバックをするのか、持ち帰ってフィードバックをリストアップしてもらうのか、レビューに対するフィードバックの仕方や期間は予め必ず明示しましょう。

レビュー時やってはいけない事。

・理由が不明確な表現は避けましょう。

「なんとなく綺麗に見えるのでこうしました。」、「一般的には～なので」など。理由が不明確な曖昧な表現を使い説明するのは避けましょう。
なぜ綺麗に見えるのか、なぜ一般的なのかをきちんと説明しましょう。

・感覚で話すのは避けましょう。

「カッコいいのでこうしました。」、「こっちの方が可愛くないですか？」など。個人の感性や主観に依存するような感覚的表現を使い説明するのは避けましょう。
もし、そういう表現を使う場合は、「どうしてカッコよく見えるのか」の理由を説明しましょう。
万人が共感できるようなものであれば、ちゃんとしたロジカルな理由が存在するはずです。レビュー前に落とし込みましょう。

・説明を省略するのは避けましょう。

「前にも言ったと思いますが、」など前置き以外の表現で説明を省略するのは避けましょう。
口頭の説明であれば以前言った事を再認識させるのは時間はかからないはずです。

フィードバックのヒアリングの仕方

・提案ではなく「理由」をヒアリングしましょう。

「ここの文字を大きくして欲しい」といった具体的な「提案」ではなく、どうしてそうしたいのか「理由」をヒアリングしましょう。
理由に則した上でデザインに合った改善案を「提案」するのはデザイナーや、ディレクターなど、「デザイン概論を理解している人」が担当する事を奨励します。
この時、受けた提案がそのままデザイン概論に則った最適な提案である場合は、その旨を「提案者」に伝えたうえで改善案を受け入れましょう。

・理由を否定するのは避けましょう。

提案ではなく理由がある場合の意見についてそれを無闇に「否定」するのは避けましょう。
理由がその場で納得できないものであれば、チームおよびプロジェクトの上長にその内容を説明し、判断を仰ぎましょう。

※ただし、最適な改善案ではない提案については改善理由を基に正しい改善策を明示するようにしましょう。
お互いハラオチするためにデザイン概論が存在します。

レビューを受けての改善の仕方

・レビューでの提案や改善案を鵜呑みにしない

レビューにおいてデザイン経験を積んでいない人がフィードバックをする場合はその改善案を鵜呑みにするのは危険です。
例えば、「文字が見えないから文字を大きくしてほしい」というフィードバックがあった時に、そのレビュアーの中には「見えないから大きくする」という改善案しか持っていない可能性があります。
もし、そのフィードバックをそのままデザインに反映すると、デザインによっては返って見づらくなったり他の要素を阻害する可能性も出てきます。
文字が見えにくいときの改善案には「フォントカラーを変更してコントラストを高くする」「背景に色を入れて強調する」「ボールドにして文字の色面積を増やす」「イタリック調やフォントの種類を変更する（シェイプを変える）」などたくさんデザイン手法があるので、そのデザインに「合った」変更をおこないましょう。

ただし、レビュアーがデザイン経験を積んだ人の場合は、さまざまなデザイン手法の中からそのデザインに合った解決案を「考えたうえで」提案する事がありますので、その場合は傾聴して対応しましょう。

決して「考える事を放棄したり」、「言われた通り直すだけ」のオペレーターにならないように、デザイナーの介在ポイントを抑えた対応を心がけていきましょう。

提案者の意見がよく変わる問題

・その都度、本質的なフィードバックをしてくれている場合

レビュアーも人間です。レビューをしている最中でもレビュアーの方のインプット量が増えれば自然とフィードバックの精度も上がっていきます。また、その時その時のトレンドの移り変わりは非常に速いので、状況次第ではリアルタイムで最適なフィードバックに至らない可能性もあります。
その際に前回と違った「意見」になる事は理解しましょう。むしろ、デザイナーが気づかなくてはいけない箇所を、先に気付いてフィードバックをしてくださった事に感謝をしましょう。
デザイナーは「誰が言ってるか」ではなく、「何を言ってるか」の本質をとらえましょう。
意見が変わる＝悪い事と決めつけないようにしましょう。

・信念のないフィードバックをしている場合

上記のような例とは異なり、レビュアーの方に信念がない場合も同様の「前と意見が変わる」という事態は発生します。
その場合は、「前回の意見となぜ違った意見になったのか」の「本質」をきちんとヒアリングしましょう。
「前回と言ってる事が違いますよね。」という指摘は意味がありません。
レビュアーをする方というのは大抵は時間に追われている方が多いものです。そうなると、以前の流れを覚えていない場合は多々あります。（※）
なので、「前回はこのようなご意見を頂戴したので、このように変更しました。」などレビュー前に思い出してもらいながら確認をすると良いでしょう。

※ デザインタスクのみに従事しているデザイナーと、他にも複数の業務を遂行している方（特に重たい決断をたくさん行っている方）ではレビューに対する意識や記憶内容に差が生じることがあります。本来はその差を埋めるためにディレクターが介在したりもするのですが、さまざまな事情によりディレクターの編成がないチームもあるかと思いますので、そういったチームのデザイナーは意思決定者のタイムラインと自分のタイムラインが違うことは理解しておくと自身のストレスマネジメント（≒ストレスコーピング）に繋がります。

・意見を言いたいだけの人の場合

中には、とにかく自分の意見が反映されていない事に不満を感じるレビュアーの方がいらっしゃいます。
その場合はそのレビュアーの方の意見を反映する事が全社貢献になるかどうか、視座を変えてジャッジをしましょう。
全社貢献とは大抵は「売上」に直結する事です。そのレビューを受け入れたことによりプロダクトやサービスの「価値」が上がるのであればコンサルタントと同じです。素直に聞き入れましょう。
そうでない場合は、レビュアーの方のキャスティング変更を提案しましょう。

以上になります。

このレビュー方法は私が様々な環境でレビューに携わっている中で特に心掛けてきたことや、チームを更に活性化できたと感じたやり方だったりするので、使えそうな箇所は参考にしていただければと思います。もちろんチームの規模やプロダクトやサービスのフェーズによっては全く異なったレビュー方法も存在するかと思います。これがすべてというわけではありません。
ただ、デザインレビューはプロダクトやサービスだけではなく、チームやデザイナーを成長させられる大切な工程なので、もっと浸透していくといいなと思います。

※ デザイン経験のない方がデザインレビューする際のドキュメントもまとめさせていただいております。
https://note.mu/may_nishimori/n/n6397c93b995c