グラフィックデザイナーのための Webデザイン基本ルール
印刷と異なり、Web は媒介（HTML・CSS・ブラウザ）と読み方（スクロール・入力）が前提になる。次の並びは、その前提から情報の骨格 → ビジュアル基盤 → レイアウト → 素材・操作 → 実務へと読み進められるようにした。
前提と情報の整理
1. スクロール前提の設計（紙との違い）
Web は「連続体」であり、一画面で完結しないことを前提に設計する。
重要な考え方
意識すること
- セクション切り替えに意味を持たせる
- 次を見たくなる余白を作る
デザインの確認
- ページ全体を俯瞰して一度に確認しすぎると、ユーザーが実際に見るスクロールしながらの視線との間に齟齬が出やすい。カンプやブラウザでは上から順に、画面内（ビューポート）に収まる範囲ずつ確かめる
2. 階層構造（見出しと HTML）
- 見出しが分かるようにしておく
- 実装時に h1, h2 の見分けがつかないと、SEO 的に良い HTML を作れない
3. コンポーネントとデザイントークン
再利用可能なパーツを定義する
同じ意味を持つものならば、同じスタイリングを使い回す。
例：本文テキスト ── 下記の値をすべて統一する
- font-family / font-size / line-height / font-weight / letter-spacing / color
例：カード ── 下記の値をすべて統一する
- padding / margin / border / background-color
デザイントークン
色、フォント、余白など、サイトの統一感をアップするために使う値を明示化する。
コンポーネントライブラリを参考にする
表現の引き出しを増やすために、既存のライブラリを参考にする。
たとえば次のような UI パターンは、各ライブラリの実装例を見ながら設計するとイメージしやすい。
- ダイアログ：確認・補足情報・フォーム入力をモーダルで扱う
- ドロワー：モバイルでのメニューや補助情報を画面端から展開する
- タブ：同一ページ内で関連情報をカテゴリ切り替えで見せる
- アコーディオン：FAQ など長い情報を折りたたんで整理する
参考サイトの例は次のとおり。
ビジュアル基盤
4. タイポグラフィと可読性
グラフィック出身の人が一番抜けやすいポイント。印刷は自由なレイアウトが可能だが、Web はスクロールして読むため疲れやすい。フォント指定とセットで、読みやすさを設計する。
Webフォントの選定
- 案件により異なるが、無料で配布・セルフホストしやすい Google Fonts などが選ばれやすい。Adobe Fonts も Web 用ライセンスと埋め込み手順が整えば利用可能。利用条件・読み込み方法・表示速度は実装側と事前にすり合わせる
- 使えるフォントかどうか、事前に確認しておく
- 読み込みが遅くなるので、使用する font-family の数と font-weight の数を多くしない
- 用件に応じて WOFF2 の利用や、必要な文字だけに絞った subset などの読み込み戦略も検討する（実装と相談）
- フォールバックフォント を指定しておく
デザインカンプとブラウザのズレ
- Illustrator や XD とブラウザでは、フォントの計測・行ボックスの扱いが異なり、行の上下の見え方がズレることがある
- CSS では
line-height やメトリクスまわりの指定で寄せる。新しい仕様の leading-trim / text-box-trim などは対応ブラウザが限定的なので、実装時に実機・主要ブラウザで必ず検証する
- JS だけで無理にトリミングすると、文字が見切れるリスクがある
letter-spacing は一定にする- font-weight は数値で指定する
- 単位は pt ではなく px で指定する
行長（1行の文字数）
- 欧文の本文：おおよそ 40〜60 文字（約 45〜75 文字相当の文献も多い）が目安
- 日本語（全角）の本文：フォントサイズにもよるが、おおよそ 25〜40 字前後を一つの目安にすることが多い
- 長すぎると視線移動が大きくなり読みにくい
- 短すぎると改行が多くなりリズムが崩れる
行間・段落
- 本文の行間は 1.5〜2.0 程度が目安。見出しは詰めることもある
- 改行だけでなく、段落ごとの差を明確にする
フォントサイズの目安（最小値と推奨値）
- 本文の最小サイズは 16px を基本にする（特にスマホ）
- 本文の推奨サイズは 16〜18px。文字量が多いページは 17〜18px も検討する
- 注釈・補足などの小さな文字でも、最小 14px を目安にする
- 12〜13px は短いラベル用途に限定し、長文には使わない
5. 色と意味づけ（アクセシビリティ）
- 背景色とのコントラスト比（WCAG 2 系・レベル AA の目安）：通常の本文テキストは背景に対して 4.5 : 1 以上。大きなテキスト（サイズ・太さの条件あり）は 3 : 1 で足りる場合がある。詳細は 達成基準 1.4.3 コントラスト (最低限) を参照
- レベル AAA を狙う場合はより高い比（例：7 : 1）が求められることもある
- 色だけに意味を持たせない。情報や状態は、色に加えて形状・文言・位置などでも伝える。
- 例 ── リンクできるものを青色だけで表現するのではなく、アイコンもつける
- 例 ── テキスト入力のエラーを赤枠だけでなく、エラーメッセージもつける
6. 余白
使用する余白を統一することで、サイト全体の統一感がアップする。もちろん例外パターンもデザインによっては発生する。
余白設定の例
| 用途 | 値 |
|---|
| テキスト間のミクロな調整 | 4px |
| アイコンとラベルの間 | 8px |
| カード内パディング | 16px |
| セクション内の要素間 | 24px |
| セクション間 | 32px |
| 大きなセクション区切り | 48px |
| ページセクション間 | 64px |
レイアウトと環境
7. レイアウト・ブレークポイント・表示環境
基本方針
- 横幅いっぱいになったときの挙動を決めておく（例：1600px 以上の場合）
- モバイルファーストか PC ファーストかを選定しておく（案件による）
デザイン時のレイアウト基準（例）
| デバイス | 幅 |
|---|
| SP | 375px |
| PC | 1024px |
| Tablet（必要ならば） | 768px |
レイアウトの種類（用語は文献によってブレるので、ここでは役割で整理）
固定幅レイアウト（いわゆるソリッド／fixed-width）
- カンバス幅を固定し、狭い画面では横スクロールが出やすい（意図しない横スクロールは基本避ける）
- レスポンシブ主流の現場では基本使わない
可変（フルード）レイアウト（fluid）
- パーセントやフレックスなどで、ビューポートに合わせてレイアウトが伸縮する（英語圏では fluid / liquid が同義で使われることも多い）
- 実装は比較的しやすい一方、タイポや画像の扱い次第では極端に小さく／大きく見えることがある
タイポ固定のレスポンシブ
- フォントサイズはおおむね固定し、ブレークポイントごとにレイアウトだけ変える考え方（実装・調整の手間は増えがち）
- 画面幅によってはデザインカンプと余白の印象が変わるため、主要幅で見え方を確認する
- ブログやメディア、ドキュメントなど本文が長く文字量が多いサイトでは、行長や文字サイズを安定させやすく、読みやすさを保ちやすい
表示まわりの実務メモ
- セーフエリア（ノッチ・角丸ディスプレイ）付近に重要 UI を詰め込み過ぎない。必要なら実装とマージン方針を決める
100vh などの「画面いっぱい」指定は、モバイルブラウザの URL バー表示の変化で想定とズレることがある。固定フルスクリーン UI は実装と検証
8. レスポンシブと情報の優先度
「画面サイズ」の設定だけでは足りない。PC を縮小するのではなく、優先順位を変えるという発想が重要。
多言語・文字量のブレ
- 同じ UI でも、言語によってラベル・ボタン文言の長さが大きく変わる。固定幅のボタンに詰め込み過ぎない
- 必要なら主要言語でカンプまたはワイヤー上で文字列を足して検証する
素材・操作
9. 画像とアセット
- 画像はセットのものはグルーピングして書き出しやすくする
- 角丸などは CSS でスタイリングするので、綺麗な状態で素材を書き出せるようにしておく
- 拡大率に応じた書き出し（例：@2x / @3x）や、ロゴ・アイコンはSVG を検討。写真・グラデは WebP / AVIF などでの配信を実装と相談し、不要に巨大な PNG を避ける
- ヒーロー画像などは幅・高さまたはアスペクト比をデザインで指示し、読み込み時のガタつき（CLS）を抑える
- alt テキストの設定ルールを決める
- alt を書く画像：内容に意味がある画像（図解・写真・アイコンなど）
- alt 不要な画像：装飾目的の画像 →
alt=""（空 alt）を明示する
- 空 alt を設定することで、スクリーンリーダーがスキップできる
10. インタラクションと UI
状態
すべてのインタラクティブ要素に以下の状態を設計する：
- default ── 通常の見た目
- hover ── マウスカーソルが重なったとき
- focus / focus-visible ── キーボードなどでフォーカスされたとき。ブラウザ標準のリングを消す場合は、代替の視認できるフォーカス指示をデザインに含める
- active ── クリック・タップ中
- disabled ── 操作できない状態
ボタンとリンク
役割の区別
- ボタン ── 画面をまたがないアクション（フォーム送信、モーダル表示、カートに追加 など）
- リンク ── 別 URL への移動、同一ページ内アンカー、ファイル DL など「ナビゲーション・参照」に寄せる
- 見た目が近い場合でも、ユーザーや支援技術が役割を区別できるようにする
- 例 ── CTA をボタン風のリンクにする場合、右矢印 などで「移動」のニュアンスを足す
- 主要アクションと補助アクションを視覚的に区別できるようにする
- 見た目の例 ── 塗りつぶし（プライマリ）と枠線のみ（セカンダリ）、など
- 場面の例 ── カート・決済で「注文を確定する」などが主要で、「買い物を続ける」「戻る」が補助
- 場面の例 ── 問い合わせ・会員登録フォームで「送信」が主要で、「キャンセル」や入力のやり直しが補助
- 場面の例 ── 設定やプロフィール編集で「保存」が主要で、「変更を破棄」「デフォルトに戻す」が補助
アニメーション
- アニメーションは装飾というより、ユーザーの視線誘導の手段
- OS の「動きを減らす」設定（
prefers-reduced-motion）を有効にするユーザーがいる。装飾アニメはオフまたは短くなる案も設計し、実装と相談する
11. モバイルのタップ領域
ボタンが見えていても押しにくいと UX が落ちる。グラフィック出身の人が抜けやすいスマホ固有の設計ルール。
タップサイズ
- Apple HIG などではおおよそ 44×44pt が目安に挙がることが多い。最低 44×44px 前後を確保するのが無難。Material 系では 48×48dp を推奨とする資料もあるので、プロジェクトのターゲットに合わせて寄せる
要素間距離
- 隣接するタップ可能な要素には誤タップ防止の余白を取る
フォーム・実務
12. フォームの基本
意外と抜けやすいフォーム設計のルール。
必須事項
- 必須／任意を明示する
- エラー表示位置を決めておく
- placeholder に依存しない
- 実装では autocomplete 属性（氏名・メール・電話 など、適切な値の指定）で入力負担を減らすことができる。必要な項目はデザイン・仕様書で伝える
NG：placeholder だけで項目説明をする
- 入力後に説明テキストが消えるため、ユーザーが内容を確認できなくなる
- label を別途設けること
13. 避けるべきパターン（Web 特有）
グラフィックデザインでは問題なくても、Web では避けた方がよい例。
全文中央揃えの乱用
- 長文を中央揃えにすると視線の起点がブレ、読みにくくなる
- 見出しや短いキャッチコピーに留める
文字の画像依存
- SEO に弱い（クローラーが読めない）
- 可変性がなく、多言語対応も困難
- テキストは極力 HTML テキストで実装する
余白だけで意味を持たせ過ぎる
- レスポンシブ時に余白が変わり、意図した区切りが崩れやすい
- セクション区切りには border や背景色など視覚的な要素も併用する
14. 実装コストと開発への引き渡し
デザインの自由 ≠ 実装の自由。曖昧なまま渡すと実装者の判断に委ねられ、手戻りや見え方のブレにつながる。再現コストを抑えつつ、数値と挙動を明示すると信頼につながる。
再現コストを抑える
- 避けたいもの：微妙に違う角丸の大量発生、1px 単位で別パターン乱立、似た UI なのに全部違うスタイル
- 近いものは統一する
仕様として決めておくこと
- hover の変化量（例：opacity 80%）
- transition 時間（例：0.3s）
- breakpoint ごとの差分（何がどう変わるか）
例：値の明示
- hover →
opacity: 0.8
- transition →
0.3s ease