この原則でできること
- 実装コストを見積もり段階で正確に判断できる
- UIの複雑さが技術的負債に変わるメカニズムを理解できる
- エンジニアとの会話で「これは複雑すぎないか？」と根拠をもって議論できる
例: 「ボタンの状態を5種類作りたい」。デザイナーにとっては5つのバリエーションだが、エンジニアにとっては 5 × 他の状態数 の組み合わせ爆発。KISSを知っていれば「状態は3つに絞れないか？」と提案できる
なぜ難しいか
人は無意識に「念のため」の複雑さを足す。
「あとで困るかも」「この場合はどうする？」と考えるほど機能が増える。デザイナーは「体験を良くしたい」、エンジニアは「エッジケースを潰したい」。両者とも善意で複雑さを増やしてしまう。KISSの本質は「足す」より「削る」判断ができること。
KISS原則とは
一言で言うと
Keep It Simple, Stupid — 「シンプルにしておけ」。問題を解決する最も単純な方法を選べ。
UXとの接点
UIの複雑さは、そのままユーザーの認知負荷になる。そしてコードの複雑さは、バグ・遅延・改修コストとしてユーザーに跳ね返る。シンプルさはUXの基盤。
KISS原則の適用パターン
パターン1: 状態設計をシンプルにする
どんな場面: ボタン、フォーム、カードなど、UIコンポーネントの状態を設計する時
Before（原則なし）:
ボタンの状態:
- default
- hover
- active
- focus
- disabled
- loading
- error
- success
- disabled + loading（組み合わせ）
→ 9状態。組み合わせを含めると実装が爆発する
After（原則適用）:
ボタンの状態:
- default（hover/active/focusはCSSで処理）
- disabled
- loading
→ 3状態。インタラクション状態はCSS疑似クラスに任せる
なぜ改善されるか: 「状態としてデザインファイルに定義するもの」と「CSSが自動で処理するもの」を分ける。デザイナーが明示的に定義すべきなのは振る舞いが変わる状態だけ。
パターン2: ナビゲーション構造をシンプルにする
どんな場面: グローバルナビゲーション、メニュー構造を設計する時
Before（原則なし）:
メガメニュー
├── カテゴリA
│ ├── サブカテゴリA-1
│ │ ├── ページ1
│ │ ├── ページ2
│ │ └── ページ3
│ └── サブカテゴリA-2
├── カテゴリB
│ └── ...
└── 特集ページ（期間限定）
→ 3階層。実装コスト大、モバイルでの表現が困難
After（原則適用）:
ナビゲーション
├── カテゴリA
├── カテゴリB
├── カテゴリC
└── 検索
→ 1階層＋検索。詳細はページ内のフィルターで解決
なぜ改善されるか: 「ナビを複雑にする」のではなく「探す手段を多様化する」。検索とフィルターがあれば、ナビは最小限でいい。
パターン3: エラー処理をシンプルにする
どんな場面: フォームのバリデーション、エラーメッセージの設計
Before（原則なし）:
エラーパターン:
- 未入力
- 文字数超過
- 不正な文字
- 重複
- サーバーエラー
- ネットワークエラー
- タイムアウト
→ 7種類のエラーUIが必要
After（原則適用）:
エラー分類:
- 入力エラー（赤枠＋メッセージ）
- システムエラー（トースト通知）
→ 2パターンのUI。メッセージ内容だけ動的に変える
なぜ改善されるか: エラーの「種類」ではなく「ユーザーが取るべきアクション」で分類する。入力を直すか、リトライするか、の2択にすればUIは2パターンで済む。
デザイナー × エンジニアの衝突パターン
❌ 「全パターンのモックアップがほしい」
デザイナーの視点: 完璧なデザインを届けたい。全ての状態を網羅したい。
エンジニアの視点: 状態の数だけ実装・テスト・保守コストが増える。
なぜ衝突するか（品質の定義差）: デザイナーは「見た目の網羅性」を品質と呼ぶ。エンジニアは「保守性とバグの少なさ」を品質と呼ぶ。同じ「良いプロダクトを作る」という目的でも、指標がズレている。
どう合意するか:
- Must状態 / Nice-to-have状態を一緒に決める
- 「この状態が必要なユーザーは何%か？」で優先度を判断
- 段階リリースで状態を増やす
❌ 「機能を全部初回リリースに入れたい」
デザイナーの視点: 中途半端な体験はユーザーに失礼。完成してから出すべき。
エンジニアの視点: 全部入れるとリリースが遅れ、バグも増える。
なぜ衝突するか（品質の定義差）: デザイナーにとっての品質は「すべての体験が揃っていること」。エンジニアにとっての品質は「安定して素早く動いていること」。スコープに対する認識が衝突する。
どう合意するか:
- MVP（最小限の実行可能製品）の考え方を共有する
- 「この機能なしで、ユーザーは目的を達成できるか？」でMVP境界を引く
- → 詳細はYAGNI原則
実践チェックリスト
最低ライン（Must）
[ ] ページや機能に「状態（ON/OFF, 開閉など）」がいくつあるか数えられている [ ] 「この機能がないと使えない」と言える根拠がある [ ] ナビゲーションが2階層以内に収まっている
理想ライン（Better）
[ ] デザイン段階で「例外処理」や「エラー状態」が増えすぎないようなUIを提案している [ ] エンジニアと「この状態は本当に必要か」を議論した [ ] エッジケースを「対応しない」と明示的に決めた
関連技術
前提となる技術
- エンジニアリング技術概論 — このセクションの全体像
セットで使う技術
次に学ぶ技術
- YAGNI原則 — KISSの次に学ぶべき原則
まとめ
- この原則の本質: 複雑さは意図せず足してしまう。「足す」より「削る」判断ができる技術
- UXへの影響: シンプルなUIは認知負荷を下げ、シンプルなコードはバグを減らして体験を守る
- 実務での判断軸: 「それを足すことで発生する複雑さは、ユーザーへの価値に見合うか？」
- 次に学ぶべき技術: YAGNI原則（今必要ないものを作らない）
目的別のおすすめ:
