UIって何だろう？⑨ 〜状態とフィードバックで作るデザイン〜
第1回「ポスターとアプリケーションの違い」の記事で、「ポスター（静的デザイン）とアプリ（動的デザイン）は違う」というお話をしました。ポスターは印刷されたら変化しませんが、UIはユーザーが触れることで変化する「動的なもの」です。
しかし、デザインツールで画面を作っていると、どうしても「何もしていない状態（静止画）」ばかりを作り込んでしまいがちです。 「ボタンを押したらどうなる？」「読み込み中は？」「エラーが起きたら？」 こうした「動き」と「反応」まで考えて初めて、使いやすいUIになります。
今回は、UIに命を吹き込む「状態（ステート）」と「フィードバック」について整理します。
1. 「状態（ステート）」をデザインする
UIコンポーネントには、ただ置かれているだけでなく、状況に応じた「状態（State）」が存在します。 第4回の「コンポーネント」の記事でも少し触れましたが、ボタン一つをとっても、ユーザーの操作に合わせて見た目を変える必要があります。
基本的なステート
UIパーツには、ユーザーの操作に応じて以下のような状態があります。GoogleのMaterial Designでは、ボタンなどのインタラクティブな要素に対して、以下の状態を定義しています
Material Designより引用
- Default（通常）: 何もしていない、初期状態
- Hover（ホバー）: マウスカーソルが乗った状態（※主にWeb）
- Press（押下）: 指やマウスで押し込んだ瞬間
- Focused（フォーカス）: キーボード操作などで選択されている状態
- Drag（ドラッグ）: オブジェクトを掴んで動かしている状態
参考：Material Design States（https://m3.material.io/foundations/interaction/states/state-layers）
これらに加えて、多くのUIでは
Disabled（無効）: 条件が揃うまでボタンを押せない
も重要です。
❌ NG
ボタンを押しても何も変化がないため、「押せているのかな？」と不安になり、何度もクリックやタップをしてしまう（多重送信の原因に）。
✅ OK
カーソルを乗せると色が少し明るくなり（Hover）、押すと沈み込む（Press）。ユーザーは自分の操作がシステムに伝わったことを直感的に理解できます。
2. システムからの「フィードバック」を返す
ユーザーが操作をした後、システムがどう処理したかを伝えるのが「フィードバック」です。 フィードバックが不足しているUIはユーザーを不安にさせます。
Nielsen Norman Group が提唱する「10 Usability Heuristics（ユーザビリティの10原則）」の第1原則は、「Visibility of System Status（システム状態の可視性）」です。システムで何が起きているかを、適切なタイミングでユーザーに伝えることが重要だとされています。
出典：https://www.nngroup.com/articles/ten-usability-heuristics/
具体的なフィードバックの例
処理中であることを伝える（Loading）
Material Designより引用
通信中や処理中であることを伝えます。Google の Material Design では、Progress indicators（プログレスインジケーター）として、スピナーやプログレスバーの使用が推奨されています。これがないと、ユーザーは「フリーズした？」と勘違いしてしまいます。
Material Designより引用
結果を伝える（Success / Error）
操作が成功したのか、失敗したのかを明確に伝えます。Material Design では、Snackbarなどの一時的な通知を使って、「保存しました」「エラーが発生しました」といったメッセージを表示します。
特にエラーの場合、Nielsen Norman Group 第9原則では、「エラーコードではなく、平易な言葉で伝える」「何が問題なのかを正確に示す」「解決策を建設的に提案する」ことが推奨されています。
❌ NG
「Error 401: Unauthorized」 → 何をすればいいのか分からない。
✅ OK
「ログインの有効期限が切れました。もう一度ログインしてください。」 → 状況と次のアクションが明確。
3. 「無効（Disabled）」の扱い方
ボタンがグレーアウトしている Disabled 状態は、「今は押せない」ことを伝える状態です。
Nielsen Norman Group の第5原則「Error Prevention（エラーの防止）」では、エラーが起きないよう事前に防ぐ設計が推奨されています。Disabled 状態は、その一つの手段です。
例えば、必須項目が未入力のまま送信ボタンを押せないようにすることで、「送信したのにエラーが返ってくる」という体験を防げます。ただし「なぜ押せないのか」が分からないと、ユーザーは困ってしまいます。
❌ NG
理由が分からない
入力フォームが埋まっていないため送信ボタンがグレーになっているが、どこが未入力なのか一目で分からない。
✅ OK
理由を明示する
未入力の項目に「必須」マークや赤い枠を表示し、ボタンの近くに「すべての必須項目を入力してください」と説明を添える。
なお、あえて Disabled にせず、ボタンを押したときにエラーメッセージで伝える方法もあります（Nielsen Norman Group の第9原則「Error Recovery」）。どちらが親切かは、状況によって変わります。
4. おわりに
デザインツールで作る静止画は、UIデザインの「半分」です。残りの半分は、ユーザーが触れたときの「反応」をどう設計するかです。
- 状態（State）：ボタン一つにも、Hover / Press / Focused などの状態がある
- フィードバック：処理中・成功・失敗を、きちんと伝える
- Disabled の扱い：グレーアウトするなら、理由も一緒に示す
「押したらどうなる？」「読み込み中は？」「エラーが出たら？」このような問いに答えることで、UIは初めて「使えるもの」になります。
第1回で触れた「ポスターとアプリの違い」も合わせて考えると、UIデザインは、静止画ではなく「ユーザーとの対話」といえそうです。
