デザインレビューのチェックリスト｜コーディング前に確認する項目

この8つは、デザインの良し悪しを評価するものではありません。「コーディングする人が、デザイナーに質問しなくても作れるか」という視点で見ていくものです。デザイナー本人は意図を分かっているため、描いていないことに気付きにくいものです。レビューは、別の人の目で行うと効果が上がります。

数値の規則が揃っているかを確認します。規則がバラバラだと、実装時に「どれが正しいか」を判断できません。

• 基準の画面幅（例：1440px）とコンテンツ幅が決まっている
• 余白が決まった刻み（例：8の倍数）で統一されている
• 見出し・本文・注釈など、文字サイズの種類が整理されている
• 行間・文字間の指定がある
• Webフォントを使うか、使う場合の書体と太さ
• 長い文字列（会社名・URL・英単語）が入ったときの折り返し

レビューで見つかった点は、デザインデータを直すか、文書に残すかのどちらかで解決します。文書に残す場合は、次のような書き方にすると、コーディングする側がそのまま使えます。

■ 基準幅：1440px（コンテンツ幅1120px、それより広い画面では中央寄せ）
■ 余白：8の倍数。セクション間はPC 120px／スマホ 64px
■ 文字：見出し1・見出し2・見出し3・本文・注釈の5種類（サイズと行間は別表）
■ 色：メイン・アクセント・本文・背景・罫線の5色（カラーコードは別表）
■ 長い文字列：URLや英単語は折り返しを許可、見出しは2行まで想定

上の数値は書き方の例です。案件ごとの実際の値に置き換えてお使いください。文字や色の種類が多すぎる場合は、レビューの段階で整理を提案するのも有効です。似た大きさの文字や、わずかに違う色が混ざっていると、実装時にどれに揃えるべきか判断できず、ページごとに見た目がばらつく原因になります。

デザインで最も描き漏れが多いのが、「状態」です。静止画のデザインでは、操作したときの見た目が分かりません。

次の状態が描かれているか確認します。

• ボタン・リンクのホバー時、押した時
• キーボード操作時のフォーカスの見え方
• フォームの入力中・エラー・送信完了
• お知らせが0件のとき、1件だけのとき
• 画像が設定されていないときの代わりの表示
• メニューを開いた状態（スマホ）

フォームの状態はお問い合わせフォームの要件チェックリストもあわせて確認してください。

すべての状態を1つずつ描く必要はありません。たとえば「ボタンのホバーは全て背景色を少し暗くする」「エラーは入力欄の下に赤い文字で表示する」といったルールを1か所に書いておけば十分です。大切なのは、コーディングする側が想像で補わなくて済むことです。共通パーツをまとめたページを1枚用意し、そこに状態の見本も並べておくと、レビューも実装も効率よく進みます。

すべてのページでスマホデザインを用意できれば確実ですが、難しい場合はトップページと代表的な下層ページ1〜2枚のスマホデザインに、崩し方のルールを添える方法が現実的です。

崩し方のルールを決めるときは、「何を優先して見せるか」を基準にすると判断がぶれません。スマホの画面は狭いため、PCで横に並んでいた情報をすべて同じ重みで並べると、大事な情報が下のほうに埋もれてしまいます。お問い合わせボタンや電話番号など、スマホで特に使われる要素の位置は、デザインの段階で決めておくのがおすすめです。

デザインとしては魅力的でも、実装や更新の段階で無理が出る表現があります。レビューの段階で気付いておくと、代わりの案を早めに検討できます。無理がある表現を見つけたときは、「できない」と伝えるのではなく、「この表現を活かすなら、更新の範囲をこう絞る」「表示速度を考えて、動画の代わりに静止画とアニメーションで表現する」のように、代わりの案とセットで相談すると話が前に進みます。

注意したい表現の例です。

• 文字数が決まっている前提のレイアウト（更新で崩れる）
• 画像の上に重ねた文字（画像差し替えで読めなくなる）
• 要素ごとに角度や形が違う装飾
• 更新担当者が入力する箇所の複雑なレイアウト
• 表示速度に影響する大きな動画・大量のアニメーション

更新を前提としたWordPress化の範囲はWordPressサイト制作を外注するで解説しています。

当社がおすすめしている進め方です。

1. トップページと代表的な下層ページだけを先にレビューする
2. このチェックリストで「描かれていないこと」を洗い出す
3. デザイナーが追記するか、ルールとして文書に残すかを決める
4. 共通パーツをまとめた一覧（スタイルガイド）を作る
5. 残りのページをデザインし、同じ観点で最終レビューする
6. デザインデータを整えてコーディングに渡す

データの整え方はデザインデータの渡し方、コーディングへの指示はコーディング指示書・仕様書の作り方をご覧ください。

当社（RunLand）は制作会社様の下請けを専門にしており、デザインをお預かりしてコーディングする機会が多く、受け取った段階で「状態」「スマホ」「長い文字列」の扱いを質問することがほとんどです。

レビューでこれらが整理されていると、質問の往復が減り、そのぶん実装と確認に時間を使えます。結果として、公開までの期間も短くなります。

逆に、レビューをせずにコーディングに入ると、実装が終わってから「ここはこう動くと思っていた」という食い違いが見つかります。デザインの段階なら直すのはデータだけですが、実装後はコードの修正と再確認が必要になり、手間が何倍にもなります。デザインの確認は、手戻りのコストが一番小さいうちに行うのが合理的です。

アクセシビリティの観点（コントラスト・色だけに頼らない表現・フォーカスの見え方）も、デザインの段階で確認しておくと後から直す手間が省けます。詳しくはWebアクセシビリティ対応を外注するをご覧ください。

Q. スタイルガイドは必ず必要ですか？

A. 必須ではありませんが、ページ数が多い場合や公開後に更新が続く場合は、共通パーツの一覧があると品質を保ちやすくなります。

Q. デザインツールのデータのまま渡してもよいですか？

A. はい。ただし、非表示のレイヤーや使っていないパーツは整理し、どれが最終版か分かるようにしてから渡してください。

Q. レビューにはどのくらい時間をかければよいですか？

A. ページ数や複雑さによって変わります。最初にトップページと代表ページを丁寧に確認し、残りのページは同じルールに沿っているかを中心に見ると、全体の時間を抑えられます。

Q. レビューはデザイナーとコーダーのどちらが行うべきですか？

A. 両方の視点があると理想的です。コーダー側から事前に質問を受ける場を設けるだけでも、手戻りは減らせます。