#UIデザイン原則
オンボーディング (Onboarding)
登録直後の離脱を防ぐ。新規ユーザーが「最初の成功体験」に辿り着くまでの道筋を設計し、サービスの価値を体感させるオンボーディング設計の原則。
ピーク/終わりの体験設計 (Peak-End Experience)
ユーザーはサービスの「平均」ではなく「最高潮」と「最後」で全体を評価する。購入完了・タスク達成・解約——感情が動く瞬間を意図的に設計するピーク・エンドの法則の実践原則。
わかる言葉で書く (Plain Language)
専門用語・社内用語・曖昧な表現はユーザーを迷わせる。ユーザーが日常的に使う言葉でUIを書くことで、理解のコストをゼロに近づける設計原則。
主要導線を先に決める (Primary Path)
すべてのボタンが同じ大きさ・同じ色——ユーザーは「次に何をすべきか」がわからない。主要導線（プライマリパス）を先に定義し、UIの視覚的階層でユーザーを迷わず導く設計原則。
達成感・進捗 (Progress & Reward)
「あと少し」が人を動かす。プログレスバー・バッジ・ストリーク——進捗の可視化と達成の報酬設計がユーザーのモチベーションを維持し、継続率を高める設計原則。
近接 (Proximity)
ラベルと入力欄が同じ距離で並んでいると、どれとどれがペアかわからない。線や枠を使わずに「近づける・遠ざける」だけで情報のグループを作る、近接の設計原則。
記憶に頼らせない (Recognition over Recall)
ユーザーに「覚えておくこと」を要求するUIは失敗する。情報を見せて「思い出させる」のではなく、「認識させる」設計でユーザーの記憶負荷をゼロにする原則。
レスポンスと待ち時間設計 (Response Latency)
「遅い」より「わからない」がユーザーを壊す。待ち時間を正直に伝え、体感速度を設計する原則。スケルトン・プログレスバー・楽観的UIの使い分けと実装チェックリスト。
検索とフィルタ (Search & Filter)
検索は「知っている人」のための機能、フィルタは「探している人」のための機能。この違いを理解し、ユーザーが大量の情報から目的のものを素早く見つけられる設計原則。
単純化 (Simplicity)
機能を増やすことは簡単だが、削ることは難しい。UIの単純化とは「何を見せないか」を決める設計判断であり、ユーザーの認知負荷を下げ、目的達成を加速させる原則。
状態と例外を先に設計する (States & Edge Cases)
デザインは「うまくいったとき」だけ描かれている——ローディング中・エラー時・空状態・長すぎるテキスト。これらを後回しにすると、実装後に必ず壊れる。状態と例外を先に設計する原則。
トーン&ボイス (Tone & Voice)
同じ「エラーが発生しました」でも、ブランドによって言葉は変わる。UIのすべてのテキストに一貫した「人格」を持たせ、ユーザーとの信頼関係を言葉で設計する原則。