画面設計・実装のときに確認するためのガイドです。原則、レイアウト、タイポグラフィ、色、操作、フォーム、フィードバック、アクセシビリティ、レスポンシブ、パフォーマンスの順に、チェックできる形でまとめています。
目次
- 基本原則
- 視覚的階層とレイアウト
- タイポグラフィ
- 色とコントラスト
- ボタンとインタラクション
- ナビゲーション
- フォーム設計
- フィードバックと状態表示
- アクセシビリティ
- レスポンシブ・モバイル対応
- パフォーマンスと体感速度
- マイクロコピー（UIの文言）
- デザインシステム
- よくあるアンチパターン
- リリース前チェックリスト
1. 基本原則
ニールセンのユーザビリティ10原則（要約）
| # | 原則 | 具体例 |
|---|---|---|
| 1 | システム状態の可視化 | 保存中のスピナー、アップロードの進捗バー |
| 2 | 現実世界との一致 | 専門用語ではなくユーザーの言葉を使う |
| 3 | ユーザーの主導権と自由 | 「元に戻す」「キャンセル」を常に用意する |
| 4 | 一貫性と標準 | 同じ操作は同じ見た目・同じ位置に |
| 5 | エラーの予防 | 破壊的操作の前に確認、入力時のバリデーション |
| 6 | 記憶より認識 | 選択肢を見せる、最近使った項目を表示する |
| 7 | 柔軟性と効率 | 上級者向けのショートカットキー |
| 8 | 美的で最小限のデザイン | 不要な情報を削り、主要な情報を際立たせる |
| 9 | エラーの認識・診断・回復 | 何が起きて、どう直せばよいかを平易に伝える |
| 10 | ヘルプとドキュメント | 文脈に応じたヘルプ、ツールチップ |
押さえておきたい法則
- ヒックの法則：選択肢が増えるほど決定に時間がかかる → 選択肢を絞る、段階的に見せる
- フィッツの法則：ターゲットが大きく近いほど押しやすい → 主要ボタンは大きく、よく使う場所の近くに
- ミラーの法則：一度に扱える情報は限られる → 情報をグループ化（チャンク化）する
- ヤコブの法則：ユーザーは他のサイトで慣れた操作を期待する → 独自性より慣習を優先
- 美的ユーザビリティ効果：見た目が整っていると使いやすく感じられる（ただし使いにくさは隠せない）
2. 視覚的階層とレイアウト
視覚的階層
- 1画面に主役は1つ。最も重要な情報・操作を、サイズ・太さ・色・位置で際立たせる
- 重要度は サイズ → 太さ → 色 → 位置 の順で調整すると破綻しにくい
- 視線の流れを意識する：テキスト中心なら F型、ビジュアル中心なら Z型
余白（ホワイトスペース）
- 余白は「空き」ではなく グループ化の道具（近接の原則）
- 関連する要素は近く、無関係な要素は離す：内側の余白 < 外側の余白
- 詰め込むより、余白を増やして情報を減らす方が伝わる
スペーシングシステム
- 4px または 8px のグリッド を基準に、余白・サイズを統一する
- 例：
4, 8, 12, 16, 24, 32, 48, 64
- 例：
- 場当たり的な値（13px、27pxなど）を使わない
グリッドとアライメント
- 12カラムグリッドなどを使い、要素の端を揃える
- テキストは原則 左揃え（中央揃えは短い見出し・CTA程度に）
- 揃っていない要素は「意図的」でない限りノイズになる
ゲシュタルトの原則
- 近接：近いものはグループに見える
- 類同：似た見た目のものは同じ機能に見える
- 閉合・連続：カードや区切り線で領域を示す
- 共通領域：背景色や枠で囲むとグループになる
3. タイポグラフィ
基本設定
| 項目 | 推奨値 |
|---|---|
| 本文サイズ | 16px以上（モバイルでも最低16px。iOSでは16px未満の入力欄でズームが発生） |
| 行間（line-height） | 本文 1.5〜1.8（日本語は1.7前後が読みやすい）、見出し 1.2〜1.4 |
| 1行の長さ | 英語 45〜75文字、日本語 25〜40文字程度 |
| 書体の数 | 原則1〜2種類まで |
| ウェイト | Regular / Bold など2〜3種類に絞る |
タイプスケール
- 一定の比率（1.2、1.25、1.333など）でサイズを決める
- 例（1.25倍）：
12 / 14 / 16 / 20 / 25 / 31 / 39px
- 例（1.25倍）：
- 見出しレベル（h1〜h6）の見た目と意味を対応させる
日本語特有の注意
- 和文フォントは欧文より大きく見えにくいため、サイズ・行間はやや大きめに
font-feature-settings: "palt"で詰めるのは見出し向き（本文は読みにくくなりがち）- 全角/半角の混在ルール（英数字は半角など）を統一する
- 禁則処理・改行位置に配慮する（
word-break: auto-phrase等の活用も検討）
可読性
- 全部大文字・全部太字・長い斜体は読みにくい
- 本文の文字色は純黒（#000）より、少し柔らかい濃いグレー（例：#1a1a1a〜#333）が目に優しい（コントラスト比は確保する）
4. 色とコントラスト
カラーパレットの構成
- ブランド色（Primary）：主要アクション、リンクなど限定的に使う
- ニュートラル（グレー系）：テキスト、背景、境界線。UIの大部分を担う
- セマンティックカラー：成功（緑）、警告（黄/橙）、エラー（赤）、情報（青）
- 60-30-10ルール：ベース60%、サブ30%、アクセント10%が目安
コントラスト（WCAG 2.2）
| 対象 | AA基準 | AAA基準 |
|---|---|---|
| 通常テキスト | 4.5:1以上 | 7:1以上 |
| 大きいテキスト（18pt以上 / 太字14pt以上） | 3:1以上 | 4.5:1以上 |
| UI部品・アイコン・フォーカス表示 | 3:1以上 | — |
色の使い方の注意
- 色だけで情報を伝えない（色覚多様性への配慮）
- ❌ 赤い枠だけでエラーを示す
- ✅ 赤い枠 ＋ エラーアイコン ＋ エラーメッセージ
- プレースホルダーや無効状態の薄いグレーもコントラストに注意
- 色の意味を統一する（赤＝危険/エラー、を他の用途に使わない）
ダークモード
- 単純な色反転ではなく、専用パレットを設計する
- 背景は純黒より濃いグレー（例：#121212）が見やすく、影の代わりに明度差で階層を表す
- 彩度の高い色はダーク背景で目に刺さるため、彩度を少し下げる
- ユーザーのOS設定（
prefers-color-scheme）を尊重する
5. ボタンとインタラクション
ボタンの階層
| 種類 | 用途 | 見た目 |
|---|---|---|
| Primary | 画面の主要アクション（1画面に原則1つ） | 塗りつぶし・ブランド色 |
| Secondary | 補助的なアクション | 枠線のみ / 薄い塗り |
| Tertiary | 重要度の低いアクション | テキストのみ |
| Destructive | 削除など破壊的なアクション | 赤系（確認とセットで） |
ボタンのラベル
- 動詞で具体的に：「OK」より「保存する」「メールを送信」
- ダイアログでは「はい/いいえ」を避け、「削除する/キャンセル」のように結果が分かる言葉にする
インタラクティブ要素の状態
すべての操作可能な要素に、以下の状態を設計する：
- Default（通常）
- Hover（マウスオーバー）※タッチ端末では発生しない前提で設計
- Focus（キーボードフォーカス）※絶対に消さない
- Active / Pressed（押下中）
- Disabled（無効）※なぜ無効なのかが分かるように
- Loading（処理中）※二重送信を防ぐ
タッチターゲット
- 最小サイズ：44×44pt（Apple）/ 48×48dp（Material）
- WCAG 2.2 の最低基準は 24×24 CSS px（AA）
- 隣接するターゲットの間隔は 8px 以上を確保
アフォーダンス
- クリックできるものは「クリックできそう」に見せる（リンクは下線や色、ボタンは形）
- クリックできないものをボタンやリンクのように見せない
6. ナビゲーション
- 現在地を常に示す：アクティブなメニューの強調、パンくずリスト、ページタイトル
- グローバルナビの項目は 5〜7個程度 に抑える
- ラベルは短く、ユーザーが探す言葉で（社内用語を使わない）
- モバイルでは主要機能を ボトムナビ（3〜5項目） に置くと親指で届きやすい
- ハンバーガーメニューは発見されにくいため、主要機能を隠しすぎない
- ロゴクリックでトップへ戻れるようにする
- 検索は目立つ位置に（コンテンツが多いサイトほど重要）
- ブラウザの「戻る」ボタンを壊さない（SPAでも履歴を正しく管理する）
7. フォーム設計
構造
- 入力項目は最小限に。本当に必要か、後で聞けないかを検討する
- 1カラムレイアウト が基本（視線の移動が少なく、完了率が高い）
- 関連項目をグループ化し、見出しを付ける
- 長いフォームはステップに分割し、進捗を表示する
ラベル
- ラベルは入力欄の 上に配置 する（スキャンしやすく、モバイルでも崩れない）
- プレースホルダーをラベル代わりにしない（入力すると消えて何の項目か分からなくなる）
- 必須/任意を明示する（任意項目が少なければ「任意」を表示する方が分かりやすい）
入力支援
- 適切な
type/inputmode/autocomplete属性を指定するtype="email"、type="tel"、inputmode="numeric"、autocomplete="postal-code"など
- 郵便番号から住所を自動入力する
- 入力形式は柔軟に受け付ける（全角/半角、ハイフン有無などをシステム側で吸収）
- 入力欄の幅を、期待される入力の長さに合わせる（郵便番号欄は短く）
バリデーション
- 入力完了時（blur）に検証 し、入力中に早すぎるエラーを出さない
- エラーは 該当フィールドのすぐ近く に表示する
- エラー文は「何が問題で、どう直せばよいか」を書く
- ❌「入力値が不正です」
- ✅「電話番号は数字10〜11桁で入力してください」
- 送信時にエラーがあれば、最初のエラー箇所へフォーカスを移動する
- エラーが起きても 入力済みの内容を消さない
8. フィードバックと状態表示
応答時間の目安
| 時間 | ユーザーの感覚 | 対応 |
|---|---|---|
| 〜0.1秒 | 即時 | 特別な表示は不要 |
| 〜1秒 | 思考が途切れない | 軽いインジケーター（必要に応じて） |
| 〜10秒 | 注意が保てる限界 | スピナー、スケルトン表示 |
| 10秒〜 | 他のことをし始める | 進捗バー、残り時間、完了通知 |
必ず設計すべき画面状態
- 理想状態（データがある通常状態）
- 空状態（Empty State）：何もない理由と、次に何をすべきかを示す
- ローディング状態：スケルトンスクリーンが体感速度を上げる
- エラー状態：原因と回復方法を示す
- 部分的な状態：データが1件だけ、極端に長いテキスト、など
通知の使い分け
| 種類 | 用途 |
|---|---|
| インライン | フォームのエラーなど、特定の場所に関する情報 |
| トースト / スナックバー | 一時的な完了通知（「保存しました」＋「元に戻す」） |
| バナー | ページ全体に関わる持続的な情報 |
| モーダル | 判断が必要な重要事項のみ（多用しない） |
破壊的操作
- 可能なら 確認ダイアログより「元に戻す」 を優先する（操作の流れを止めない）
- 取り消せない操作は、何が失われるかを明示して確認する
- 特に重大な操作は、対象名の入力などで誤操作を防ぐ
9. アクセシビリティ
アクセシビリティは一部の人のためではなく、すべての人の使いやすさにつながる。目標は WCAG 2.2 レベルAA 準拠。
POUR原則
- Perceivable（知覚可能）：代替テキスト、字幕、十分なコントラスト
- Operable（操作可能）：キーボード操作、十分な時間、発作を誘発しない
- Understandable（理解可能）：読みやすい、予測可能、入力支援
- Robust（堅牢）：支援技術と互換性がある
実装チェック
- セマンティックHTMLを使う：
<button>、<nav>、<main>、<h1>〜<h6>など。<div onclick>を避ける - すべての操作をキーボードで行えるようにする（Tab、Enter、Space、Esc、矢印キー）
- フォーカスを見えるようにする：
outline: noneで消さない。:focus-visibleを活用 - フォーカス順序を論理的にする（視覚的な順序と一致させる）
- モーダルではフォーカスを閉じ込め、閉じたら元の位置に戻す
- 画像には適切な
altを付ける（装飾画像はalt=""） - アイコンだけのボタンには
aria-labelを付ける - フォーム入力欄と
<label>を関連付ける - 動的な更新（エラー、通知）は
aria-liveでスクリーンリーダーに伝える - ARIAは最終手段：ネイティブ要素で実現できるならそちらを使う
- ページの言語を指定する（
<html lang="ja">） prefers-reduced-motionを尊重し、アニメーションを抑制できるようにする- 文字サイズを200%に拡大しても破綻しないようにする
テスト方法
- キーボードだけで全操作を試す
- スクリーンリーダー（VoiceOver、NVDA）で読み上げを確認する
- 自動チェックツール（axe、Lighthouse）を使う（ただし自動検出できるのは一部の問題のみ）
10. レスポンシブ・モバイル対応
- モバイルファースト で設計し、画面が広くなるにつれて情報を足す
- ブレークポイントはデバイスではなく コンテンツが崩れる地点 で決める
- 親指が届く範囲（画面下部）に主要操作を配置する
- ホバーに依存した操作を作らない（タッチ端末にはホバーがない）
- 横スクロールを発生させない（意図したカルーセルなどを除く）
- ノッチやホームインジケーターに配慮する（
env(safe-area-inset-*)） - 画像は
srcset/sizesで端末に適したサイズを配信する - 縦向き・横向きの両方で確認する
- ピンチズームを無効にしない（
user-scalable=noを使わない）
11. パフォーマンスと体感速度
Core Web Vitals（目標値）
| 指標 | 意味 | 良好 |
|---|---|---|
| LCP | 最大コンテンツの表示時間 | 2.5秒以内 |
| INP | 操作への応答性 | 200ミリ秒以内 |
| CLS | レイアウトのずれ | 0.1以下 |
体感速度を上げる工夫
- スケルトンスクリーン でレイアウトを先に見せる
- 楽観的UI（Optimistic UI）：サーバー応答を待たずに結果を先に反映する（いいねボタンなど）
- 画像・広告の領域を事前に確保し、レイアウトのずれを防ぐ
- 画像の遅延読み込み（
loading="lazy"）、次世代フォーマット（WebP/AVIF） - 重い処理はバックグラウンドで行い、UIをブロックしない
アニメーション
- 目的のあるアニメーションだけを使う（状態変化の理解を助ける、注意を引く）
- 時間の目安：マイクロインタラクション 100〜200ms、画面遷移 200〜400ms
transformとopacityを使うと滑らかに動く- イージングは
ease-out（入場）、ease-in（退場）を基本に
12. マイクロコピー（UIの文言）
- 短く、具体的に、ユーザー視点で
- 専門用語・社内用語・エラーコードをそのまま出さない
- 能動態で、何をすればよいかを伝える
- トーンを統一する（です・ます調、敬語のレベル）
- ユーザーを責めない：「入力が間違っています」→「〇〇の形式で入力してください」
- ボタン・リンクのラベルだけで行き先や結果が分かるようにする（「こちら」「詳しくはこちら」を避ける）
- 空状態・エラー画面こそ丁寧に言葉を選ぶ
| ❌ 避けたい例 | ✅ 改善例 |
|---|---|
| エラーが発生しました（E-1024） | 通信が切れました。接続を確認して、もう一度お試しください |
| データがありません | まだプロジェクトがありません。「新規作成」から始めましょう |
| 送信 | 申し込みを確定する |
| こちらをクリック | 料金プランを見る |
13. デザインシステム
- デザイントークン で色・余白・タイポグラフィ・角丸・影などを定義し、デザインと実装で共有する
- 再利用可能なコンポーネントを作り、各コンポーネントの状態・バリエーション・使い方を文書化する
- 「いつ使うか」「いつ使わないか」をセットで記載する
- 例外を作るときは、システム側を更新するかどうかを判断する（場当たり的な例外を増やさない）
- 参考になる公開デザインシステム：
- Material Design（Google）
- Human Interface Guidelines（Apple）
- Fluent（Microsoft）
- Carbon（IBM）
- デジタル庁デザインシステム（日本の行政向け。日本語UIの参考になる）
14. よくあるアンチパターン
| アンチパターン | 問題点 |
|---|---|
| プレースホルダーをラベル代わりにする | 入力後に何の項目か分からなくなる |
| フォーカスリングを消す | キーボード利用者が現在地を見失う |
| 色だけで状態を伝える | 色覚多様性のあるユーザーに伝わらない |
| 「OK / キャンセル」だけのダイアログ | 何が起きるか分からない |
| 主要ボタンが複数ある | どれを押せばよいか迷う |
| 無限スクロールでフッターに辿り着けない | 会社情報・問い合わせにアクセスできない |
| 意味のないアニメーション・自動再生 | 注意を奪う、酔いを誘発する |
| ダークパターン（解約導線を隠す、既定でオプトイン等） | 信頼を損なう。法規制の対象になる場合もある |
| エラー時に入力内容を消す | ユーザーの労力を無駄にする |
| 小さすぎるタップ領域 | 誤タップが増える |
| 理由の分からない無効ボタン | 何をすれば押せるのか分からない |
| ページを開いた瞬間のモーダル・ポップアップ | 目的の行動を妨げる |
15. リリース前チェックリスト
見た目・レイアウト
- 1画面の主要アクションは1つに絞られているか
- 余白・サイズはスペーシングシステムに沿っているか
- 要素の端は揃っているか
- 長いテキスト・多言語・極端なデータ量でも崩れないか
状態
- 空状態・ローディング・エラー状態が設計されているか
- すべての操作要素に hover / focus / active / disabled 状態があるか
- 処理中の二重送信を防いでいるか
アクセシビリティ
- テキストのコントラスト比は 4.5:1 以上か
- キーボードだけで全操作できるか
- フォーカスが見えるか
- 画像に適切な代替テキストがあるか
- 色以外の手段でも情報が伝わるか
- フォームのラベルと入力欄が関連付いているか
モバイル
- タップ領域は 44×44pt 以上か
- 本文は 16px 以上か
- 横スクロールが発生していないか
- ホバーに依存した操作がないか
文言
- ボタンのラベルは具体的な動詞か
- エラーメッセージは回復方法を示しているか
- 用語・トーンは統一されているか
パフォーマンス
- LCP 2.5秒以内、INP 200ms以内、CLS 0.1以下か
- 画像サイズは最適化されているか
参考資料
- Nielsen Norman Group — 10 Usability Heuristics for User Interface Design
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2
- Google — Material Design 3
- Apple — Human Interface Guidelines
- web.dev — Core Web Vitals
- Laws of UX（lawsofux.com）
- デジタル庁 — デジタル庁デザインシステム