デザインレビューの観点チェックリスト——目的・導線・一貫性・実装可能性

結論から書くと、デザインレビューは観点の順番を決めておくだけで、かなり静かになります。私は「目的 → 導線 → 一貫性 → 実装可能性」の順で見ています。上の観点で問題が見つかったら、下の観点の指摘は後回しにします。目的がずれているカンプの余白を直しても、あとで全部作り直しになるからです。

ディレクター、デザイナー、エンジニアを一人で往復していると、レビューする側とされる側の両方を経験します。される側として一番つらかったのは、色の好みとボタンの位置と全体の方向性が、同じ温度で一度に返ってくることでした。どれから直せばいいのか分からないのです。

観点1：目的——このページは何をしてもらうためのものか

最初に確認するのは、カンプが要件定義の目的に沿っているかどうかです。見た目の評価はまだしません。

• このページで、ユーザーに取ってほしい行動は1つに絞れているか
• その行動は、ファーストビューか、最初のスクロールで分かるか
• 想定している読み手（ペルソナ）が、最初に知りたいことが上にあるか
• 要件定義の「やらないこと」に入れた要素が、紛れ込んでいないか

この段階の指摘は、デザイナーではなく、要件を決めた側（多くはディレクターやクライアント）が持ち帰ることもあります。目的のずれはデザインの腕ではなく、伝え方の問題であることが多いからです。

観点2：導線——迷わず次に進めるか

目的が合っていたら、次は導線です。ページを上から順に、ユーザーになったつもりで読みます。

• 主要なボタンが、ほかの要素より目立っているか（目立つものが2つ以上ないか）
• リンクとただの装飾が、見た目で区別できるか
• フォームの入力項目は、本当に必要なものだけか
• エラーや完了の状態がカンプに描かれているか

最後の項目は抜けやすいです。正常系の画面だけでレビューを終えると、エラー文言や空の状態は実装のときにエンジニアが考えることになります。私はレビューの時点で「この画面の、何もない状態はどうなりますか」と聞くようにしています。

観点3：一貫性——同じものは同じに見えるか

3つめで、ようやく見た目の細部に入ります。ここで見るのは「きれいかどうか」ではなく、「同じ意味のものが同じ見た目になっているか」です。

確認すること	よくあるずれ
文字サイズの段数	見出しが5段、6段と増えている
余白の単位	8pxの倍数とそうでない値が混在
ボタンの種類	同じ役割なのに角丸や色が違う
文言	「お問い合わせ」と「問い合わせる」が混在

アクセシビリティもここで見ます。W3CのWCAG 2.2では、達成基準1.4.3として、通常のテキストに4.5:1以上、大きなテキストに3:1以上のコントラスト比が求められています（レベルAA）。また達成基準2.5.8では、クリックやタップの対象を原則として24×24 CSSピクセル以上にすることが求められています（間隔などによる例外あり）。数値で確認できる項目は、好みの話にならないので、レビューで扱いやすいです。

観点4：実装可能性——作れるか、運用できるか

最後に、エンジニアの目で見ます。ここを最後にしているのは、上の3つが決まる前に実装の都合を出すと、デザインが縮こまってしまうからです。

• 画面幅が変わったとき（スマホ・タブレット）の配置が描かれているか
• テキストが想定より長くなったとき、レイアウトが崩れないか
• 画像や動画は、誰が用意し、更新するのか
• CMSで更新する部分と、固定の部分が分かれているか

特に「テキストが長くなったとき」は、カンプでは短い仮の文章が入っていることが多く、公開後に崩れやすい箇所です。私はレビュー中に、見出しを2倍の長さにして見てもらうことがあります。

指摘の書き方もそろえる

観点をそろえても、指摘の書き方がばらばらだと伝わりません。私は指摘を1件ずつ、次の3つで書くようにしています。

1. どの観点か（目的・導線・一貫性・実装可能性）
2. 何が起きているか（事実）
3. なぜ問題か（目的や基準との関係）

「このボタン、ちょっと弱い気がします」ではなく、「導線：申し込みボタンが、上のバナーより目立たない。このページの目的は申し込みなので、ボタンを優先したい」と書く。修正案は、デザイナーに任せることが多いです。

明日から試せる一手

次のデザインレビューの冒頭で、「今日は目的と導線だけ見ます」と宣言してみてください。一貫性と実装可能性は、目的と導線が固まった次の回に回します。

1回のレビューで扱う観点を2つに絞るだけで、指摘の数は減り、ひとつひとつの指摘が直しやすくなるはずです。観点ごとの確認項目は、この記事の箇条書きをそのままチェックリストとして使ってかまいません。