UIデザイン原則

UIデザインの基本原則をカテゴリー別に整理。

→ デザイン原則インタラクティブページ - Good/Bad例を比較できるインタラクティブ版

実装カテゴリー（実装しやすさ順）

Good/Bad例を作成する際の実装難易度でグルーピング。同じコンポーネントパターンで複数の原則を実装できる。

A. テキスト変更のみ（最も簡単）

UIコンポーネントは同じ、テキストの書き方だけでGood/Badを示せる。

No	原則	実装パターン	完了
11	ユーザーの言葉を使う	ラベル比較	✅
33	ナビゲーション項目は名詞にする	ナビ項目比較	✅
44	選択肢の文言は肯定文にする	チェックボックスラベル	✅
47	デフォルトボタンには具体的な動詞を用いる	ボタンラベル比較	✅
55	エラー表示は建設的にする	エラーメッセージ比較	✅

B. 単一コンポーネント（ボタン/コントロール）

1つのコンポーネントでGood/Badを示せる。

No	原則	実装パターン	完了
4	シグニファイア	ボタンの見た目（押せそう/押せなさそう）	✅
48	ラジオボタンは単数選択、チェックボックスはオンオフ	選択UI比較	✅
49	フリップフロップ問題を避ける	トグルボタン比較	✅
72	肯定／否定ボタンの順序	ボタン配置比較	✅
74	ハイライト表現は構成要素をひとつだけ変化させる	ハイライト比較	✅
78	タッチ操作する要素の大きさは7mm以上	ボタンサイズ比較	✅
93	ホットスポットを広げる	クリック領域比較	✅

C. フォーム系（入力UI）

フォームコンポーネントでGood/Badを示せる。

No	原則	実装パターン	完了
42	よいデフォルト	デフォルト値あり/なし	✅
43	制限コントロールを活用する	テキスト入力 vs ドロップダウン	✅
45	値を入力させるのではなく結果を選ばせる	スライダー vs プリセット	✅
46	入力欄を構造化する	電話番号入力など	✅
50	ユーザーに厳密さを求めない	バリデーション比較	✅
51	入力サジェスチョンを提示する	オートコンプリート	✅
39	整合性を損なう操作を求めない	重複入力の例	✅

D. レイアウト/配置系

要素の配置やグルーピングでGood/Badを示せる。

No	原則	実装パターン	完了
10	視覚ゲシュタルト	グルーピング比較	✅
30	ペンは紙の近くに置く	ツール配置比較	✅
40	入力フォームにはストーリー性を持たせる	フォーム順序比較	✅
41	操作の流れを作る	視線誘導比較	✅
66	操作の近くでフィードバックする	フィードバック位置比較	✅
84	色やフォントを使いすぎない	スタイル過多 vs シンプル	✅
85	整然とレイアウトする	整列あり/なし	✅

E. ナビゲーション系

ナビやメニューUIでGood/Badを示せる。

No	原則	実装パターン	完了
59	ウェイファインディング	パンくず/現在地表示	✅
60	エスケープハッチ	ホームリンクあり/なし	✅
73	メニュー項目の位置を変化させない	固定 vs 動的メニュー	✅
80	ドリルダウンは上→下、左→右	階層UI方向	✅
81	左が戻るで右が進む	戻る/進むボタン配置	✅
82	モバイルでは包括的より階層的に	情報密度比較	✅

F. インタラクション/アニメーション系

動きやタイミングでGood/Badを示す（デモが必要）。

No	原則	実装パターン
8	直接操作	ドラッグ操作デモ
63	画面の変化をアニメーションで表す	トランジションあり/なし
64	トランジションは両方向につける	双方向アニメーション
65	ユーザーの操作に対して0.1秒以内に反応	遅延比較デモ
79	ジェスチャはコマンド式ではなく直接操作式	スワイプ操作デモ
90	UIをロックしない	ローディング中の操作可否

G. モーダル/確認系

ダイアログやモーダルでGood/Badを示せる。

No	原則	実装パターン
32	前提条件は先に提示する	条件提示タイミング
54	フールプルーフよりフェールセーフ	Undo vs 確認ダイアログ
57	黙って実行する	過剰確認 vs 即実行
62	回答の先送り	初期設定の強制 vs スキップ可能
67	プログレッシブ・ディスクロージャ	全表示 vs 段階的表示

H. 情報表示系

データや状態の表示方法でGood/Badを示せる。

No	原則	実装パターン
25	オブジェクトは自身の状態を体現する	状態表示あり/なし
28	データよりも情報を伝える	数値 vs 意味のある表現
31	視覚的に何であるかを示し文字で説明する	アイコン+テキスト
52	スクロール画面では続きがありそうに見せる	切れ目の見せ方
53	プロパティの選択肢でプレビューを見せる	プレビューあり/なし
96	色に依存させない	色のみ vs 色+形

Z. 概念的（UIで直接示しにくい）

設計指針として理解すべきだが、単一UIで示すのが難しいもの。後回しまたはドキュメントで説明。

No	原則	備考
1	シンプルにする	全体設計の話
2	簡単にする	全体設計の話
3	メンタルモデル	概念的
6	一貫性	システム全体の話
7	ユーザーの主導権	概念的
9	モードレス	システム設計の話
17	ヒックの法則	選択肢数の話
18	複雑性保存の法則	概念的
83	単純なものは単純なままに	概念的
87	ユーザーの道具にする	概念的
99	デザインは新しい意味を提案する	哲学
100	人類にポジティブな影響を与える	哲学

デザインカテゴリー（内容別）

基本原則

No	原則	説明
1	シンプルにする	機能や情報を厳選し、できるだけ要素を少なくする。あらゆるデザインジャンルにおける基本原則。
2	簡単にする	利用方法を効率化し、目的達成までの手順と労力をできるだけ減らす。

認知・心理

メンタルモデルと知覚

No	原則	説明
3	メンタルモデル	ユーザーが想像する利用モデルに合った構成と動きにする。学習可能なイディオムによってユーザーに利用モデルを与える。メタファを用いて概念や機能性を伝える。
4	シグニファイア	操作対象となる要素が見えていて、その意味が一目でわかるようにしておく。押せるものは押せそうに、押せないものは押せなさそうに見せる。
5	マッピング	操作する所と結果が反映される所の対応を把握できるようにする。位置関係、形、色、記号などによって手掛かりを与える。
6	一貫性	配色、形状、配置、振る舞いなどに一貫したルールを適用する。同じ性質のものは同じ表現、違う性質のものは違う表現にする。
10	視覚ゲシュタルト	近接、類似、閉鎖といったパターン（プレグナンツの法則）を用いてレイアウトし、要素同士のグループ関係を効果的に示す。
71	直観的より慣用的に	多くの人が言う「直観的」は「慣用的」の意味。人々がすでに知っているイディオムにすることが大事。

認知負荷

No	原則	説明
12	ユーザーの記憶に頼らない	参照すべき情報はそれが必要となるその場で参照できなければいけない。
17	ヒックの法則	選択肢の中からひとつを選ぶ場合、選択肢の数に比例して時間がかかる。
18	複雑性保存の法則	プロセスを単純化しようとしても限界がある。複雑性をできるだけユーザー側からシステム側に移動した設計にする。
19	タスクコヒーレンス	ユーザーが最後に行ったことを覚えているだけでユーザーの行動を正しく予測したのと同じ効果がある。

操作・インタラクション

ユーザー主導

No	原則	説明
7	ユーザーの主導権	システムがユーザーをコントロールするのではなく、ユーザーがシステムをコントロールできるようにする。
8	直接操作	画面上のオブジェクトに直接触れて操作しているような感覚を与える。身体的な動作に追従してリアルタイムに表示を更新する。
9	モードレス	できるだけモードをなくす。UIがモードレスであれば、ユーザーは自由な順序で作業を行うことができる。
11	ユーザーの言葉を使う	インターフェース上で使う文言は、システム内部の技術用語や運営者の業界用語ではなく、ユーザーが普段使っている一般的な表現を用いる。

効率化

No	原則	説明
14	プリコンピュテーション	先人がすでに見つけている最適値をプリセットにしたり、デザインの過程で再利用する。
20	メジャーなタスクに最適化する	80%のユーザーは全機能の20%しか使わない（パレートの法則）。メジャーな要求への対応を優先する。
21	パースエージョン	説得的な仕掛けでユーザーの行動を促す。レコメンデーション、心理的な報酬、他者との比較などによって動機づけする。
22	ショートカットを用意する	経験あるユーザーが頻繁に実行することについて、通常の段階的な操作を短縮してより速く行う方法を提供する。
29	ユーザーがとれる操作がひとつしかないなら自動化する	現在許された入力が1種類だけであればシステムが自動で代行するべき。

タッチ・ポインティング

No	原則	説明
16	フィッツの法則	近くて大きいものほどポイントしやすく、遠くて小さいものほどポイントしにくい。
78	タッチ操作する要素の大きさは7mm以上にする	ボタンをはじめ各種UIコントロールを、指で十分に押しやすい7〜10mm四方以上の大きさにする。
79	ジェスチャはコマンド式ではなく直接操作式にする	ジェスチャに対する画面の反応は、対象の要素が直接的に追従するような振る舞いにする。
93	ホットスポットを広げる	表示されている矩形よりも広い範囲をタップ／クリック可能にする。

オブジェクト指向UI

オブジェクトの設計

No	原則	説明
23	オブジェクトベースにする	要求からオブジェクトを抽出してUIに反映する。ユーザーがオブジェクトに直接働きかけながら目的を達成できるようにする。
24	ビューはオブジェクトを表象する	インターフェースは、オブジェクトを表象するビューの集まりによって構成される。ひとつのオブジェクトは複数のビューによって異なる表現を持つことができる。
25	オブジェクトは自身の状態を体現する	画面上のすべてのオブジェクトは、自身の状態を視覚的かつリアルタイムに体現し続けなければいけない。
26	名詞→動詞の操作順序	ユーザーがまず対象物（名詞）を選び、それからアクション（動詞）を選ぶようにする。これがGUIの基本的な操作順序。
35	データをバインドする	同じオブジェクトが複数のビューで見えている時、それらの状態を常に同期させる。
36	ゼロ・ワン・インフィニティ	個数に関して恣意的な仕様を作らない。要素の存在可能な個数は基本的に0か1か無限とする。
37	すべての操作可能な要素は意味を持つ	画面上で現在操作可能な要素や選択可能な項目はすべて、ユーザーのタスクにとって何らかの意味を持っている必要がある。

ラベルとアイコン

No	原則	説明
33	ナビゲーション項目は名詞にする	情報の種類ごとに画面を作り、ナビゲーション項目は名詞表現にする。
34	アイコンは名詞または形容詞を表す	アイコンはオブジェクト（名詞）、あるいは結果として得られる状態（形容詞）をモチーフにする。

ツール配置

No	原則	説明
30	ペンは紙の近くに置く	ツール類は処理対象の近くに配置する。その場でモードレスに操作して逐次結果を確認できるようにする。

入力フォーム

データ入力の基本

No	原則	説明
38	ユーザーが入力したものはユーザーのもの	ユーザーが入力した値や設定した内容は基本的にすべて保存されるべき。
39	整合性を損なうような操作をユーザーに求めない	情報の整合性が損なわれる可能性がある操作をユーザーに求めない。生年月日と年齢を両方入力させるようなことはしない。
40	入力フォームにはストーリー性を持たせる	入力項目はユーザーにとって意味のあるグループにまとめる。身近なことや単純なものを先に、複雑なものを後にする。
41	操作の流れを作る	視覚ゲシュタルトを利用したグルーピングやストーリー性のある項目配置によってユーザーの視線と操作を誘導する。

入力支援

No	原則	説明
42	よいデフォルト	選択式の入力欄や設定項目に妥当性の高いデフォルト値を与えることでユーザーの操作を減らせる。
43	制限コントロールを活用する	入力可能な内容に制限がある場合は、ラジオボタン、ドロップダウン、スライダーなどの制限コントロールを用いる。
45	値を入力させるのではなく結果を選ばせる	パラメーターの値を設定させるよりも、得られる結果を示して選ばせる。
46	入力欄を構造化する	入力すべき値の書式に合わせて入力欄を分割または制限コントロール化する。
50	ユーザーに厳密さを求めない	半角と全角、ひらがなとカタカナ、ハイフンの有無など、入力書式の揺れをシステム側で吸収する。
51	入力サジェスチョンを提示する	途中まで入力したところで「入力しようとしていたこと」や「価値のある入力値」を選択肢として提示する。

ボタンと選択肢

No	原則	説明
44	選択肢の文言は肯定文にする	選択肢の文言はできるだけ肯定文にする。ラベルが否定形だと選択行為が「否定を肯定する」という意味になりわかりにくい。
47	デフォルトボタンには具体的な動詞を用いる	「OK」や「はい」ではなく、「保存」や「消去」など、実行されるアクションを表す具体的な動詞を用いる。
48	ラジオボタンは単数選択、チェックボックスはオンオフ	AかBかの場合はラジオボタン、真か偽かの場合はチェックボックス。
49	フリップフロップ問題を避ける	ひとつのボタンでオンとオフを切り替える場合、状態表現とラベルを分離する。
72	肯定／否定ボタンの順序はプラットフォームのルールに従う	明確なルールがない場合は「左が戻るで右が進む」に従って右を肯定ボタンにする。

エラー・制約

エラー回避

No	原則	説明
13	コンストレイント	ユーザーの行動を意図的に制限することにより、誤操作を減らしたり有効な使い方を促したりする。
15	エラーを回避する	操作ミスを起こしにくくする。エラーメッセージをわかりやすく示すことも大事だが、それ以前にエラーが起きないように工夫することが重要。
32	前提条件は先に提示する	事前に満たしておくべき前提条件を長い手続きの途中や最後になってから求めない。
56	可能性と確率を区別する	滅多にない事を考慮しすぎて通常の利用を面倒にしてはいけない。メインケースを重視すべき。

エラー対応

No	原則	説明
54	フールプルーフよりフェールセーフ	間違ったとしても大丈夫なようにする方が重要。全ての操作が取り消し可能であれば、実質的に誤操作は存在しなくなる。
55	エラー表示は建設的にする	何が起きたのか的確に知らせ、そこからどうすればよいのかを示す。
57	黙って実行する	ユーザーがやろうとしたことにいちいち確認をとったり、正常完了を報告したりしない。不可逆的かつデータ消失の恐れがある場合にのみ実行前の意思確認をする。

ビジュアルデザイン

レイアウト

No	原則	説明
27	グラフィックのトーン＆マナーを揃える	色調・彩度・明度、グラデーション、ボーダー、影、角の取り方などの度合いを揃える。
84	色やフォントを使いすぎない	種類を増やしすぎると画面が乱雑になる。
85	整然とレイアウトする	グリッドに沿って整然と配置する。余白や揃えに反復性と一貫性を持たせる。

情報表示

No	原則	説明
28	データよりも情報を伝える	ユーザーは数値よりもその意味を知りたい。例えば何バイト使っているかより何割残っているかを示す。
31	視覚的に何であるかを示し文字で説明する	オブジェクトの存在や状態を視覚的に把握できるようにし、文字情報でそれを補足する。
52	スクロール画面では続きがありそうに見せる	スクリーンの下端にちょうどコンテンツの切れ目があるとスクロールできるように見えない。
53	プロパティの選択肢でプレビューを見せる	スタイル変更やツール選択時に、結果として得られる状態のプレビューを選択肢として提示する。

視覚効果

No	原則	説明
74	ハイライト表現は構成要素をひとつだけ変化させる	変化が大きすぎるとハイライトではなく別な種類の要素に見えてしまう。
75	錯視を考慮する	目の錯覚が生じて意図しない見え方になることがある。必要に応じて目視ベースで調整する。

フィードバック

アニメーション

No	原則	説明
63	画面の変化をアニメーションで表す	広い範囲を変化させる際には、0.1〜0.5秒程度のトランジションアニメーションをつける。
64	トランジションは両方向につける	状態Aから状態Bへの変化にトランジションをつける際は、逆方向の動きも状態Bから状態Aに戻る変化につける。

応答性

No	原則	説明
65	ユーザーの操作に対して0.1秒以内に反応を返す	反応が瞬時に行われていると感じる限界は0.1秒。10秒以上かかる処理には進捗率や残り時間の表示が必要。
66	操作の近くでフィードバックする	システムの状態変化を示す時には、ユーザーが注目している場所の近くでフィードバックする。
90	UIをロックしない	数秒以上UIがロックされているとユーザーはアプリケーションを自由にコントロールしている感覚を失う。

No	原則	説明
59	ウェイファインディング	情報空間の中でユーザーが迷子にならないように道しるべを与える。今どこにいるのか、どこへ行けるのかなど。
60	エスケープハッチ	いつでもすぐに最初の場所に戻れるよう避難口を用意する。
73	メニュー項目の位置を変化させない	ユーザーはメニューの中で目当ての項目を空間的に記憶するので、位置関係が変わると学習できない。

画面遷移

No	原則	説明
80	ドリルダウンは上→下、左→右	上で選択した項目の内容が下に、左で選択した項目の内容が右に表示されるようにする。
81	左が戻るで右が進む	画面遷移の方向性を水平軸で示す場合、左を戻る（過去）に、右を進む（未来）に対応させる。
82	モバイルでは包括的より階層的に	モバイルでは一度に見せる情報を限定して階層的に見せるのが良い。

オンボーディング

No	原則	説明
61	即座の喜びを与える	ユーザーが製品を使い始めて数秒以内に成功体験を得られるようにする。
62	回答の先送り	はじめからユーザーにすべての意思決定を求めず、必要最小限のもの以外は回答を先送りできるようにする。
67	プログレッシブ・ディスクロージャ	初級者が簡単に使い始められるように最初は高度な機能を隠しておき、必要になった時にUIを追加表示する。
89	ユーザーを教育するのではなくユーザーが学習できるようにする	インターフェースに操作説明を書くのではなく、インターフェースを自己説明的にする。

国際化・アクセシビリティ

多言語対応

No	原則	説明
68	アイコンのモチーフは特定の文化に依存させない	特定の文化圏でのみ使われるサインや言語依存の慣用表現などを元にした記号は国際的なサービスで使わない。
69	多言語化を想定したUIではラベルの長さの違いを考慮する	言語によって単語の平均文字数は異なる。ドイツ語は長く、漢字やハングルは短くなる。
70	◯✕△等の記号を安易に使わない	◯と✕の肯定／否定のニュアンスは文化圏によって異なるので、国際的なインターフェースでは注意が必要。

アクセシビリティ

No	原則	説明
94	音声読み上げに対応する	非テキスト情報には代替テキストをつける。アクセシビリティを高める。
95	文字の拡大に対応する	プラットフォームやブラウザのテキスト拡大機能に対応する。
96	色に依存させない	色がなくても情報が伝わるようにする。グレースケールで表示して確認するとよい。
97	ユーザーが自分のペースで作業できるようにする	操作に時間制限を設けない。タイミングによって操作の有効性を変化させない。

記憶と学習

No	原則	説明
76	空間的に記憶できるようにする	ユーザーが2次元上の任意の場所にオブジェクトを置いて空間的に記憶できるようにする。
77	プロスペクティブメモリー	ユーザーが未来の自分のために手がかりを残せるようにする。ブックマーク、フラグ、付箋、下書き保存など。

設計哲学

ユーザーの道具

No	原則	説明
83	単純なものは単純なままに	シンプルな製品では簡単にできたことが成熟した製品では複雑になってはいけない。
86	カスタマイズ機能に頼らない	カスタマイズ機能に頼ることは、システムをより複雑にしてかえって学習のしやすさや保守性を低下させる。
87	ユーザーの道具にする	システムは提供者の物ではなくユーザーの物として作る。ユーザーが自分の行為を強化するための道具と位置づける。
88	ユーザーが自分なりの方法で作業を遂行できまたそれを改善できるようにする	マニュアルレスよりもモードレスな道具を作る。道具の使い方を工夫することが創造性の源。

インタラクションの品質

No	原則	説明
58	ガッツを見せる	デザインには仕様を割り切るためのガッツが必要。網羅性や論理性や厳密さを優先しすぎると、むしろ基本的なデザイン趣旨がわかりにくくなる。
91	ゲームを持ち込まない	偶然性、意外性、ギャンブル性、難解さなどのゲーム性をインターフェースに含めてはいけない。（ゲームアプリを除く）
92	動かしたままに動くのではなく動かしたいように動く	思いどおりにコントロールできていると感じさせるために、適切な「あそび」や「補正」を含める。
98	ユーザーイリュージョンをもたらす	システムの内部的な仕組みを隠しながら、バーチャルな世界観の中で対象を現し、ユーザーが作業に集中できるようにする。

理念

No	原則	説明
99	デザインは新しい意味を提案する	デザインは問題を解決するだけでなく、物事の新しい捉え方を導く。
100	人類にポジティブな影響を与える	道具のデザインは、人がもつ短所への寛容と長所の増進によって人類に奉仕し、生活を豊かにするためにある。

実装計画：Vueコンポーネント化

目的

UIデザイン原則のGood/Bad例を表示するVueコンポーネントを作成する。

データ構造

interface DesignPrinciple {
  no: number
  name: string
  description: string
  category: string      // 大カテゴリー
  subcategory?: string  // 中カテゴリー
  good?: GoodBadExample
  bad?: GoodBadExample
}

interface GoodBadExample {
  title: string
  description: string
  image?: string  // スクリーンショットやイラスト
  code?: string   // コード例がある場合
}

コンポーネント構成案

components/
  design-principles/
    DesignPrincipleCard.vue      # 単一原則のカード（Good/Bad表示含む）
    DesignPrincipleList.vue      # カテゴリー別リスト
    GoodBadComparison.vue        # Good/Bad比較表示
    CategoryNav.vue              # カテゴリーナビゲーション

実装ステップ

データファイル作成（data/design-principles.ts）
DesignPrincipleCard.vue - 原則カード（タイトル、説明、Good/Bad）
GoodBadComparison.vue - Good/Badの比較UI
DesignPrincipleList.vue - カテゴリー別表示
CategoryNav.vue - カテゴリー切り替え
ページ統合（この記事またはVueページで使用）