ユーザー体験(UX)を設計・改善するときに押さえておきたい原則と実践ポイントをまとめたガイドです。


目次

  1. 基本原則
  2. ユーザーリサーチ
  3. 情報設計(IA)とナビゲーション
  4. ビジュアルデザインとレイアウト
  5. インタラクションとフィードバック
  6. フォーム設計
  7. UXライティング(マイクロコピー)
  8. エラー処理
  9. アクセシビリティ
  10. パフォーマンス
  11. モバイル・レスポンシブ
  12. オンボーディング
  13. 倫理的なデザイン
  14. 検証と改善
  15. チェックリスト

1. 基本原則

ニールセンの10ユーザビリティヒューリスティクス

#原則要点
1システム状態の可視化今何が起きているかを常にユーザーに伝える
2現実世界との一致ユーザーが慣れた言葉・概念・順序を使う
3ユーザーの主導権と自由「元に戻す」「キャンセル」を用意する
4一貫性と標準同じものは同じ見た目・同じ挙動にする
5エラーの防止エラーを出すより、起きない設計を優先する
6記憶より認識覚えさせず、見ればわかるようにする
7柔軟性と効率性初心者にも熟練者にも使える(ショートカット等)
8美的で最小限のデザイン不要な情報で重要な情報を埋もれさせない
9エラーの認識・診断・回復の支援平易な言葉で原因と解決策を示す
10ヘルプとドキュメント必要なときにすぐ見つかるヘルプを用意する

覚えておきたい法則

  • ヒックの法則:選択肢が増えるほど意思決定に時間がかかる → 選択肢は絞る・段階的に見せる
  • フィッツの法則:ターゲットは大きく近いほど操作しやすい → 主要ボタンは大きく、押しやすい位置に
  • ミラーの法則:人が短期記憶で扱える量には限りがある → 情報はチャンク(まとまり)に分ける
  • ヤコブの法則:ユーザーは他のサイトで多くの時間を過ごしている → 一般的なパターンに従う
  • 美的ユーザビリティ効果:見た目が良いものは使いやすいと感じられやすい
  • ピーク・エンドの法則:体験は「最も印象的な瞬間」と「終わり方」で評価されやすい

2. ユーザーリサーチ

  • 推測ではなく観察する:「ユーザーはこう思うはず」を検証可能な仮説として扱う
  • 定性と定量を組み合わせる
    • 定性:インタビュー、ユーザビリティテスト、行動観察 → 「なぜ」がわかる
    • 定量:アクセス解析、アンケート、A/Bテスト → 「どれくらい」がわかる
  • ユーザビリティテストは少人数でも効果的:5人程度で主要な問題の多くが見つかると言われる。小さく繰り返すほうが有効
  • ペルソナ・カスタマージャーニーマップで、チーム内のユーザー像を揃える
  • 「言うこと」と「やること」は違う:意見よりも実際の行動を重視する
  • 誘導的な質問を避ける:「この機能は便利ですよね?」ではなく「普段どうやって○○していますか?」

3. 情報設計(IA)とナビゲーション

  • ユーザーのメンタルモデルに合わせて構造化する(社内の組織図に合わせない)
  • カードソーティングでユーザーが自然に感じる分類を調べる
  • ツリーテストで目的の情報にたどり着けるか検証する
  • ナビゲーションのポイント
    • 現在地を明示する(ハイライト、パンくずリスト)
    • 主要メニュー項目は5〜7個程度に抑える
    • ラベルは具体的に(「サービス」「ソリューション」のような曖昧な語を避ける)
    • 検索機能を用意し、サイズの大きいサイトでは特に重視する
  • 3クリックルールより「迷わないこと」:クリック数よりも各ステップで次が明確かどうかが重要

4. ビジュアルデザインとレイアウト

  • 視覚的階層をつくる:サイズ・太さ・色・余白で重要度を表現する
  • 1画面1目的:主要なアクション(Primary CTA)は1つに絞る
  • 余白を恐れない:余白は情報のグルーピングと可読性を高める
  • ゲシュタルトの法則を活用:近いもの・似たものは同じグループと認識される
  • F型・Z型の視線パターンを意識して重要情報を配置する
  • タイポグラフィ
    • 本文は十分なサイズ(Webで16px前後以上)
    • 行間は1.5〜1.8程度(日本語はやや広めが読みやすい)
    • 1行の文字数は日本語で35〜45文字程度が目安
  • 色
    • 色だけで情報を伝えない(アイコンやテキストを併用)
    • 意味のある色(赤=危険/エラー、緑=成功)を一貫して使う
  • デザインシステムを整備し、コンポーネントとトークンで一貫性を担保する

5. インタラクションとフィードバック

  • すべての操作に反応を返す:クリック、送信、読み込みなどに即座の視覚的フィードバックを
  • 応答時間の目安
    • 0.1秒以内:即時と感じる
    • 1秒以内:思考の流れが途切れない
    • 10秒以上:注意が離れる → 進捗表示が必須
  • ローディング表示:スケルトンスクリーンやプログレスバーで待ち時間の体感を短くする
  • アフォーダンス/シグニファイア:押せるものは押せそうに見せる(ボタンらしさ、リンクの下線など)
  • 元に戻す(Undo)を優先:確認ダイアログを乱発するより、取り消せる設計のほうが快適
  • 破壊的な操作は慎重に:削除などは確認か取り消し猶予を設け、ボタン色・配置で区別する
  • アニメーションは目的を持って:状態変化の理解を助けるために使い、短く(200〜300ms程度)。prefers-reduced-motion に配慮する

6. フォーム設計

  • 入力項目は最小限に:本当に必要な項目だけを聞く
  • ラベルは入力欄の上に常時表示:プレースホルダーだけをラベル代わりにしない
  • 1カラムレイアウトが基本(視線移動が少なく完了率が高い)
  • 適切な入力タイプを使う(type="email"、tel、inputmode="numeric"など)でモバイルキーボードを最適化
  • オートコンプリート(autocomplete属性)を正しく設定する
  • インラインバリデーション:入力完了時(フォーカスが外れたとき)に検証し、入力途中で怒らない
  • 必須/任意を明示する
  • 入力形式を柔軟に受け付ける:全角/半角、ハイフンの有無などはシステム側で吸収する
  • 長いフォームはステップ分割し、進捗を表示する
  • 送信ボタンのラベルは具体的に:「送信」より「無料で登録する」「注文を確定する」

7. UXライティング(マイクロコピー)

  • 明確・簡潔・役に立つを優先する
  • ユーザーの言葉を使う:専門用語・社内用語を避ける
  • ボタンは動詞で行動を示す:「OK」より「保存する」「削除する」
  • 前向きでわかりやすい表現:二重否定や曖昧な表現を避ける
  • トーン&ボイスを統一し、スタイルガイドにまとめる
  • 空の状態(Empty State)を活用:「データがありません」ではなく、次にやるべきことを案内する
  • 読まれない前提で書く:重要な情報は冒頭に、見出しと箇条書きで流し読みできるように

8. エラー処理

  • まず防ぐ:入力制約、デフォルト値、確認、無効なボタンの非活性化(ただし理由も示す)
  • 良いエラーメッセージの要素
    1. 何が起きたか
    2. なぜ起きたか(必要な場合)
    3. どうすれば解決できるか
  • ユーザーを責めない:「不正な入力です」→「メールアドレスに「@」が含まれていません」
  • エラーは発生箇所の近くに表示し、色だけでなくアイコンとテキストで示す
  • 入力内容を消さない:エラー時もユーザーの入力は保持する
  • 404ページも導線として設計する(検索、トップへのリンク、人気ページ)

9. アクセシビリティ

WCAG(Web Content Accessibility Guidelines)の4原則 POUR を基準にする。

原則意味例
Perceivable(知覚可能)情報を知覚できる画像の代替テキスト、字幕、十分なコントラスト
Operable(操作可能)操作できるキーボード操作、十分な時間、発作を誘発しない
Understandable(理解可能)理解できる平易な言葉、予測可能な動作、入力支援
Robust(堅牢)多様な環境で動く正しいHTML、支援技術との互換性

実践ポイント

  • コントラスト比:本文は4.5:1以上、大きな文字は3:1以上(WCAG AA)
  • キーボードだけで全操作可能にし、フォーカスリングを消さない
  • セマンティックHTML(button、nav、main、見出しの階層)を正しく使う
  • 画像に適切なalt、装飾画像はalt=""
  • タップ領域は十分な大きさ(44×44pt / 48×48dp程度)
  • ARIAは必要なときだけ:ネイティブ要素で済むならそれを使う
  • スクリーンリーダーで実際に試す(VoiceOver、NVDA、TalkBackなど)
  • アクセシビリティは一部の人のためではなく、すべての人の使いやすさにつながる

10. パフォーマンス

  • 速さはUXそのもの:表示速度は離脱率・コンバージョンに直結する
  • Core Web Vitalsを指標にする
    • LCP(最大コンテンツの描画):2.5秒以内
    • INP(次の描画までのインタラクション):200ms以内
    • CLS(レイアウトのずれ):0.1以下
  • 画像の最適化(適切なサイズ、WebP/AVIF、遅延読み込み)
  • レイアウトシフトを防ぐ:画像や広告の領域をあらかじめ確保する
  • 楽観的UI:サーバー応答を待たずに結果を先に反映し、失敗時に戻す
  • 低速回線・低スペック端末でも検証する

11. モバイル・レスポンシブ

  • モバイルファーストで設計し、制約から優先順位を決める
  • 親指の届く範囲に主要な操作を配置する(画面下部が操作しやすい)
  • ホバーに依存しない(タッチ端末にはホバーがない)
  • 入力の負担を減らす:選択式、自動入力、生体認証などを活用
  • 横スクロールを発生させない
  • プラットフォームの慣習に従う(iOSのHuman Interface Guidelines、AndroidのMaterial Design)
  • 実機で確認する(エミュレーターだけに頼らない)

12. オンボーディング

  • 価値を早く体験させる:「Aha!モーメント」までの時間を短くする
  • 登録の前に試せるようにできないか検討する
  • 長いチュートリアルより文脈に応じたヒント:必要な場面で必要な説明を
  • 段階的開示(Progressive Disclosure):最初は基本機能、慣れたら高度な機能
  • スキップ可能にする
  • 空の状態をガイドに:最初の一歩を具体的に示す
  • 権限リクエスト(通知・位置情報など)は必要な理由がわかるタイミングで行う

13. 倫理的なデザイン

ダークパターン(ユーザーを欺いて不利益な行動をさせる設計)は避ける。短期的な数字が伸びても、信頼を失い、法規制のリスクもある。

避けるべき例

  • 解約しにくい設計:登録は簡単なのに解約は複雑(ローチモーテル)
  • 確認シェイミング:「いいえ、お得な情報は要りません」のような罪悪感を与える文言
  • 隠れたコスト:最終画面で突然手数料が追加される
  • 偽の緊急性・希少性:根拠のないカウントダウンや「残りわずか」
  • 事前チェックによる同意の誘導:不要なオプションがデフォルトでオン
  • 紛らわしい選択肢:拒否ボタンを目立たなくする

心がけること

  • プライバシーに配慮し、データ収集は必要最小限に、目的を明示する
  • ユーザーの時間と注意を尊重する
  • 多様なユーザー(年齢、文化、能力、環境)を想定する

14. 検証と改善

  • 早く・小さく・何度もテストする:ワイヤーフレームやプロトタイプの段階から
  • 主要なUX指標
    • タスク完了率、タスク完了時間、エラー率
    • SUS(System Usability Scale)
    • NPS、CSAT、CES(顧客努力指標)
    • 離脱率、コンバージョン率、継続率
  • A/Bテストは明確な仮説と十分なサンプルサイズで行う
  • 定量データで「どこ」、定性調査で「なぜ」 を特定する
  • リリース後も観察を続ける:ヒートマップ、セッション録画(プライバシーに配慮)、問い合わせ内容の分析
  • 改善の優先順位は 影響の大きさ × 頻度 × 実装コスト で判断する

15. チェックリスト

リリース前の簡易確認用。

全般

  • ユーザーの主な目的が、各画面で迷わず達成できるか
  • 主要なCTAは1画面に1つで、明確か
  • 用語・UI・挙動に一貫性があるか
  • 現在地と次の行動がわかるか

フィードバック・エラー

  • すべての操作に即座のフィードバックがあるか
  • 読み込み中の状態が表示されるか
  • エラーメッセージは原因と解決策を示しているか
  • 重要な操作は取り消しまたは確認ができるか

フォーム

  • 入力項目は最小限か
  • ラベルが常に表示されているか
  • エラー時に入力内容が保持されるか

アクセシビリティ

  • コントラスト比が基準を満たしているか
  • キーボードだけで操作できるか
  • 画像に代替テキストがあるか
  • 色だけで情報を伝えていないか

モバイル・パフォーマンス

  • タップ領域は十分な大きさか
  • 実機・低速回線で確認したか
  • Core Web Vitalsの目標値を満たしているか

倫理

  • ダークパターンを使っていないか
  • 解約・退会・設定変更が簡単にできるか

参考リソース

0件のページ