この記事の要点（UIXHERO視点） UIXHEROでは、一貫性を「プロダクト内で揃えること」、標準を「業界やプラットフォームの慣習に従うこと」と定義し区別する。 一貫性は「内部の統一」、標準は「外部との整合」。両方を守ることで、学習コストを最小化できる。
導入：「一貫性を保つ」と「標準に従う」は同じか？
「UIに一貫性がない」 「標準的なUIパターンに従っていない」
このフィードバック、同じ問題を指しているように見えますが、実は別々の問題です。
- 一貫性の問題: 同じアプリ内で、同じ機能が違う見た目・動作をしている
- 標準の問題: 業界の慣習と異なる動作をしている
一貫性は「自分の中で揃える」こと、標準は「世の中に合わせる」こと。
一貫性と標準の違い（定義）
一貫性は「内部統一」であり、標準は「外部整合」である。
| 項目 | 一貫性 (Consistency) | 標準 (Standards) |
|---|---|---|
| 定義 | プロダクト内で同じ要素が同じ動作をすること | 業界・プラットフォームの慣習に従うこと |
| 範囲 | 自プロダクト内 | 業界全体、プラットフォーム |
| 参照先 | 自社デザインシステム、過去の設計 | HIG、Material Design、業界慣習 |
| 問い | 「自分たちの中で揃っているか？」 | 「世の中の期待に沿っているか？」 |
| 例 | ボタンの色が全画面で統一されている | 「×」でモーダルを閉じる |
語源と背景
ニールセンの10ユーザビリティヒューリスティクスの第4項目は「一貫性と標準（Consistency and Standards）」です。これは1つの原則に見えますが、実際には2つの側面を持っています。
一貫性は、同じプロダクト内で「同じものは同じに見え、同じように動く」ことを指します。
標準は、ヤコブの法則（Jakob's Law）にも通じます。「ユーザーは他のサイトで大半の時間を過ごす。だから、あなたのサイトも他のサイトと同じように動くことを期待する。」
研究からの引用: 「ユーザーはあなたのサイトのためだけにメンタルモデルを作らない。他のサイトでの経験をそのまま持ち込む。」（Jakob Nielsen）
なぜ重要なのか
1. 学習コストを下げる
| 問題 | ユーザーの学習コスト |
|---|---|
| 一貫性がない | 「このアプリでは、場所によってルールが違う」→ 都度学習が必要 |
| 標準に従っていない | 「他のアプリと違う動き」→ 既存の知識が使えない |
両方を守ることで、ユーザーは「知っている」知識を活用でき、学習コストが最小化されます。
2. 予測可能性が上がる
一貫性と標準が守られていると、ユーザーは「次に何が起きるか」を予測できます。
- 一貫性: 「ここでも同じボタンを押せば同じことが起きるはず」
- 標準: 「他のアプリと同じ操作で同じことができるはず」
予測可能性は、安心感と効率につながります。
具体例・ケース比較
ケース1：ボタンデザイン
| 観点 | 一貫性 | 標準 |
|---|---|---|
| 問題例 | 画面Aと画面Bでプライマリボタンの色が違う | 「決定」ボタンが左にある（通常は右） |
| ユーザーの混乱 | 「どれがメインの操作かわからない」 | 「キャンセルと間違えて押した」 |
| 解決策 | デザインシステムでボタンを統一 | 業界標準に従い右に配置 |
ケース2：アイコンの意味
| 観点 | 一貫性 | 標準 |
|---|---|---|
| 問題例 | 「ゴミ箱」アイコンが画面によって「削除」「アーカイブ」を意味する | 「ハンバーガーメニュー」がメニュー以外の機能に使われている |
| ユーザーの混乱 | 「押したら何が起きるかわからない」 | 「メニューを探しているのに見つからない」 |
| 解決策 | アイコンの意味をアプリ内で統一 | 業界で確立されたアイコンの意味に従う |
ケース3：ナビゲーション
| 観点 | 一貫性 | 標準 |
|---|---|---|
| 問題例 | あるセクションだけサイドバーがない | iOSアプリで「戻る」が右上にある |
| ユーザーの混乱 | 「なぜここだけ操作が違うのか」 | 「戻り方がわからない」 |
| 解決策 | 全セクションでナビゲーション構造を統一 | プラットフォームガイドライン（HIG）に従う |
実務でなぜ区別すべきか
UIXHEROがこの2つを厳密に区別する理由は3つあります。
1. 解決策が異なる
| 問題 | 解決策 |
|---|---|
| 一貫性がない | デザインシステムの整備、コンポーネント化 |
| 標準に従っていない | 競合調査、プラットフォームガイドラインの確認 |
問題を区別しないと、的外れな対策を打ってしまいます。
2. 優先順位が異なる場合がある
| 状況 | 優先すべきこと |
|---|---|
| プロダクト内で迷う | 一貫性を優先 |
| 初見のユーザーが迷う | 標準を優先 |
| ブランドの独自性を出したい | 一貫性は守りつつ、標準からの逸脱を検討 |
どちらを優先するかは、ユーザー層とプロダクトの性質によります。
3. 「逸脱」の判断基準が変わる
一貫性からの逸脱は、同じプロダクト内で意図的に差をつける場合（例：危険な操作だけ赤いボタン）。これは許容される。
標準からの逸脱は、より慎重な判断が必要。ユーザーが他で学んだ知識が使えなくなるため、明確な理由が必要。
一貫性の4つのレベル
一貫性には複数のレベルがあります：
| レベル | 説明 | 例 |
|---|---|---|
| 視覚的一貫性 | 見た目が統一されている | 同じボタンスタイル、同じ色使い |
| 機能的一貫性 | 同じ要素が同じ動作をする | 「保存」ボタンはどこでも保存する |
| 内部一貫性 | プロダクト内で統一されている | 自社アプリ内での統一 |
| 外部一貫性 | 他のプロダクトと統一されている | 業界標準との整合（≒標準） |
「外部一貫性」は「標準」とほぼ同義であり、両者は地続きの概念です。
よくある質問 (FAQ)
Q1. 標準に従うと、差別化できなくなりませんか？
差別化すべき部分と、標準に従うべき部分を区別しましょう。
| 差別化してよい部分 | 標準に従うべき部分 |
|---|---|
| ビジュアルスタイル、トーン | 基本的な操作パターン |
| 独自機能の表現 | ナビゲーション、フォーム |
| ブランドカラー | エラー表示、確認ダイアログ |
「ユーザーが迷わない部分」で差別化し、「ユーザーが迷う部分」は標準に従うのが原則です。
Q2. 一貫性と標準が矛盾したら？
通常は標準を優先します。
ただし、以下の場合は一貫性を優先することも：
- プロダクトの慣習が強く根付いている（既存ユーザーが多い）
- 標準自体がプラットフォーム間で異なる
矛盾した場合はユーザーテストで検証するのが確実です。
Q3. デザインシステムがあれば一貫性は保てますか？
必要条件ですが、十分条件ではありません。
デザインシステムがあっても：
- 使われていない
- 例外が多すぎる
- 更新されていない
といった状態では、一貫性は保てません。運用と浸透が重要です。
関連リンク
UIXHEROの関連記事
- ヒューリスティクスとガイドラインの違い — 評価原則と実装指針
- ニールセンの10ヒューリスティクス — 全原則の解説
- デザインシステムの作り方 — 一貫性を担保する仕組み
用語集
一貫性は「自分の中で揃える」——プロダクト内の統一。 標準は「世の中に合わせる」——業界慣習との整合。
まとめ
- 一貫性: プロダクト内で同じ要素が同じ動作をすること（内部統一）
- 標準: 業界・プラットフォームの慣習に従うこと（外部整合）
- 使い分け: 一貫性はデザインシステムで担保し、標準はガイドライン・競合調査で確認する。両方を守ることで、ユーザーの学習コストを最小化できる。
「一貫している」だけでは足りない。「世の中の期待に沿っている」ことも必要。両方揃って、ユーザーは「考えずに使える」UIが生まれる。
