既知パターンの活用 (Familiar Patterns / Mental Model)

「左上のロゴをクリックするとトップに戻る」「ハンバーガーアイコンはメニューを開く」「右上のアバターアイコンはアカウント設定」——ユーザーはこれらのパターンを、あなたのサービスで学んだわけではありません。他の何百ものサービスを使う中で学んだのです。

ヤコブの法則（Jakob's Law）が示すように、ユーザーはあなたのサービス以外のサービスで多くの時間を過ごしています。つまり、ユーザーはすでに「UIはこう動くはずだ」というメンタルモデルを持ってあなたのサービスにやってきます。このメンタルモデルを裏切るUIは、ユーザーに「学び直し」を強いることになります。

よくある失敗は「独自性を出そう」という動機で、広く普及したUIパターンを捨てることです。「検索アイコンは虫眼鏡」「削除は赤」「戻るは左矢印」——これらを変えることで得られる独自性より、ユーザーが失う「直感的な操作感」の方がはるかに大きいコストです。

1. 原則の定義

ユーザーが他のサービスで習得した操作パターン・UIの慣習（メンタルモデル）を活用し、学習コストなしに直感的に操作できるUIを設計する原則。

本質は「ユーザーの既存の知識を借りること」です。ユーザーが新しいUIを使う際、ゼロから学習するのではなく、過去の経験から「こう動くはずだ」という予測を立てて操作します。その予測が当たる設計が「直感的」と感じられ、外れる設計が「使いにくい」と感じられます。

2. いつ使うか（適用場面）

特に重要になるケース

• ナビゲーション構造: グローバルナビゲーション・ハンバーガーメニュー・タブバーなど、ユーザーが「ここにあるはず」と期待する場所にナビゲーションを置く。
• アイコンの意味: 虫眼鏡（検索）・ハート（お気に入り）・ゴミ箱（削除）・鉛筆（編集）など、広く普及したアイコンの意味を変えない。
• インタラクションパターン: スワイプで削除・長押しでコンテキストメニュー・ピンチでズームなど、プラットフォームの慣習に従う。
• フォームのUI: 日付ピッカー・ドロップダウン・チェックボックス・ラジオボタンなど、ユーザーが使い慣れたUIコンポーネントを使う。

トレードオフが起きる場面

• 慣習 vs 改善: 既存のパターンが必ずしも最善ではない場合がある（例：フロッピーディスクの保存アイコン）。慣習を変える場合は、段階的な移行と十分な説明が必要。
• プラットフォーム間の差異: iOSとAndroidでは慣習が異なる（例：戻るボタンの位置）。クロスプラットフォームアプリでは、どちらの慣習を優先するかの判断が必要。

3. なぜ重要か（設計判断の核）

既知パターンの活用は「模倣」ではなく、「ユーザーの学習コストをゼロにする」設計である。

設計判断の基準

• 「このUIパターンを変えることで、ユーザーが得るメリットは、学び直しのコストを上回るか？」→ Noなら、既存のパターンを維持する。
• 「このアイコン・インタラクションは、ターゲットユーザーが使い慣れたサービスでも同じ意味で使われているか？」→ Noなら、より普及したパターンに変更する。

優先順位の考え方

• 1. プラットフォームの慣習（最優先）: iOS・Android・Webそれぞれのプラットフォームガイドライン（HIG・Material Design）に従う。
• 2. 業界の慣習: 同じ業界・カテゴリのサービスで広く使われているパターンに従う。
• 3. ブランドの独自性: 慣習を守った上で、色・タイポグラフィ・トーンでブランドを表現する。

例外条件

• 既存のパターンが明らかに問題（アクセシビリティ違反・セキュリティリスクなど）を抱えている場合は、慣習より改善を優先する。
• ゲームなど、独自のインタラクションがコア体験の場合は、学習コストを払う価値がある。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、ユーザーは「このUIは変だ」と感じて離脱します。

主要なアイコンが業界標準の意味を持っているか: 虫眼鏡（検索）・ハンバーガー（メニュー）・ハート（お気に入り）・ゴミ箱（削除）など、広く普及したアイコンの意味が変えられていないか？独自の意味を持たせていないか？
ナビゲーションが期待される場所にあるか: グローバルナビゲーションが画面上部またはサイドバーにあるか？モバイルではタブバーが画面下部にあるか？ユーザーが「ここにあるはず」と期待する場所に配置されているか？
プラットフォームの慣習に従っているか: iOSならHIG、AndroidならMaterial Designの基本的なインタラクションパターン（戻る操作・スワイプ・長押しなど）に従っているか？プラットフォームの慣習を意図なく破っていないか？

理想ライン（Better - できると強い/プロの品質）

「使い方を説明しなくても使える」と感じられる状態です。

競合・類似サービスのパターンを調査しているか: ターゲットユーザーが日常的に使う競合・類似サービスのUIパターンを調査し、ユーザーが「慣れている」パターンを把握しているか？
慣習を変える場合に移行支援があるか: 既存のパターンを変更する場合（例：アイコンの変更・操作方法の変更）、初回利用時のコーチマーク・ツールチップ・チュートリアルで変更を説明しているか？
コンポーネントライブラリの標準コンポーネントを使っているか: 日付ピッカー・モーダル・トースト通知など、プラットフォームまたはデザインシステムの標準コンポーネントを使い、ユーザーが使い慣れた操作感を提供しているか？

5. UI例

同じ機能でも、既知パターンを使うかどうかで「直感的に使えるか」が大きく変わります。

改善プロセス

1. 競合調査: ターゲットユーザーが日常的に使う上位5〜10サービスのUIパターンを調査する。「いいねはどのアイコンか」「メニューはどこにあるか」などを記録する。
2. パターンの一致確認: 自社UIの主要なアイコン・配置・インタラクションが、競合調査で確認したパターンと一致しているかチェックする。
3. ユーザーテスト: 「このボタンを押さずに、何をするボタンだと思うか」を聞く。正答率が80%未満なら、より普及したパターンへの変更を検討する。

6. 関連リンク

• 関連リファレンス（理論）: ヤコブの法則, メンタルモデル
• 用語集（定義）: メンタルモデル
• 関連するUI原則（横）: 記憶に頼らせない (Recognition over Recall), コンポーネントの視覚一貫性 (Component Consistency)

7. まとめ

今日から直せる一手 今担当しているUIの主要なアイコンを5つ書き出してください。それぞれについて「このアイコンは、ターゲットユーザーが使う他のサービスでも同じ意味で使われているか？」を確認しましょう。1つでも「No」があれば、より普及したアイコンへの変更を検討してください。

チームに共有するなら一言 「UIの独自性はブランドで表現する。操作パターンで独自性を出すのは、ユーザーへの学習コストの押しつけだ。」