グラフィックデザイナーのための Webデザイン基本ルール

印刷と異なり、Web は媒介（HTML・CSS・ブラウザ）と読み方（スクロール・入力）が前提になる。次の並びは、その前提から情報の骨格 → ビジュアル基盤 → レイアウト → 素材・操作 → 実務へと読み進められるようにした。

前提と情報の整理

1. スクロール前提の設計（紙との違い）

Web は「連続体」であり、一画面で完結しないことを前提に設計する。

重要な考え方

• 一画面で完結しない
• 下へ読む流れを作る

意識すること

• セクション切り替えに意味を持たせる
• 次を見たくなる余白を作る

デザインの確認

• ページ全体を俯瞰して一度に確認しすぎると、ユーザーが実際に見るスクロールしながらの視線との間に齟齬が出やすい。カンプやブラウザでは上から順に、画面内（ビューポート）に収まる範囲ずつ確かめる

2. 階層構造（見出しと HTML）

• 見出しが分かるようにしておく
• 実装時に h1, h2 の見分けがつかないと、SEO 的に良い HTML を作れない

3. コンポーネントとデザイントークン

再利用可能なパーツを定義する

同じ意味を持つものならば、同じスタイリングを使い回す。

デザイントークン

色、フォント、余白など、サイトの統一感をアップするために使う値を明示化する。

コンポーネントライブラリを参考にする

表現の引き出しを増やすために、既存のライブラリを参考にする。

たとえば次のような UI パターンは、各ライブラリの実装例を見ながら設計するとイメージしやすい。

• ダイアログ：確認・補足情報・フォーム入力をモーダルで扱う
• ドロワー：モバイルでのメニューや補助情報を画面端から展開する
• タブ：同一ページ内で関連情報をカテゴリ切り替えで見せる
• アコーディオン：FAQ など長い情報を折りたたんで整理する

参考サイトの例は次のとおり。

• shadcn/ui
• MUI

ビジュアル基盤

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

レイアウトの種類（用語は文献によってブレるので、ここでは役割で整理）

表示まわりの実務メモ

• セーフエリア（ノッチ・角丸ディスプレイ）付近に重要 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 ── 操作できない状態

ボタンとリンク

アニメーション

• アニメーションは装飾というより、ユーザーの視線誘導の手段
  • ※ FV などのデザインの側面が強いものは除く
• OS の「動きを減らす」設定（prefers-reduced-motion）を有効にするユーザーがいる。装飾アニメはオフまたは短くなる案も設計し、実装と相談する

11. モバイルのタップ領域

ボタンが見えていても押しにくいと UX が落ちる。グラフィック出身の人が抜けやすいスマホ固有の設計ルール。

タップサイズ

• Apple HIG などではおおよそ 44×44pt が目安に挙がることが多い。最低 44×44px 前後を確保するのが無難。Material 系では 48×48dp を推奨とする資料もあるので、プロジェクトのターゲットに合わせて寄せる

要素間距離

• 隣接するタップ可能な要素には誤タップ防止の余白を取る

フォーム・実務

12. フォームの基本

意外と抜けやすいフォーム設計のルール。

必須事項

• 必須／任意を明示する
• エラー表示位置を決めておく
• placeholder に依存しない
• 実装では autocomplete 属性（氏名・メール・電話 など、適切な値の指定）で入力負担を減らすことができる。必要な項目はデザイン・仕様書で伝える

13. 避けるべきパターン（Web 特有）

グラフィックデザインでは問題なくても、Web では避けた方がよい例。

14. 実装コストと開発への引き渡し

デザインの自由 ≠ 実装の自由。曖昧なまま渡すと実装者の判断に委ねられ、手戻りや見え方のブレにつながる。再現コストを抑えつつ、数値と挙動を明示すると信頼につながる。

再現コストを抑える

• 避けたいもの：微妙に違う角丸の大量発生、1px 単位で別パターン乱立、似た UI なのに全部違うスタイル
• 近いものは統一する

仕様として決めておくこと

• hover の変化量（例：opacity 80%）
• transition 時間（例：0.3s）
• breakpoint ごとの差分（何がどう変わるか）