状態の可視化 (Visibility of System Status)

ボタンを押した。何も起きない。もう一度押した。まだ何も起きない。フリーズしたのか？処理中なのか？それとも自分の操作が間違っていたのか——ユーザーが「今何が起きているか」を把握できないとき、UIは沈黙という最悪のフィードバックを返しています。

よくある失敗パターンは「送信ボタンを押したのに画面が変わらない」です。処理中のスピナーも、完了メッセージも、エラー表示もない。ユーザーは不安になって連打し、二重送信が発生します。あるいは「読み込み中」とだけ表示されて、あと何秒待てばいいのかわからない。ユーザーは待つことをやめて離脱します。

状態の可視化が崩れたUIは、ユーザーを「操作の結果を知らされない状態」に放置します。それはシステムへの不信感と、操作への恐怖を生みます。

1. 原則の定義

状態の可視化（Visibility of System Status）とは、システムが今どのような状態にあるかを、適切なタイミングと適切な言葉でユーザーに伝え続ける設計原則。

本質は「ユーザーとシステムの対話を成立させること」です。人間同士の会話では、相手の反応がなければ「聞こえていないのか？」と不安になります。UIも同じです。操作に対して何らかの反応を返すことで、ユーザーは「自分の行動が受け付けられた」と確認でき、次の行動に進めます。これはヤコブ・ニールセンの10ヒューリスティクスの第1原則でもあります。

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

特に重要になるケース

• 処理に時間がかかる操作: ファイルアップロード、フォーム送信、検索など、結果が即座に返らない操作では必ずプログレス表示が必要。
• 破壊的・不可逆な操作: 削除、送信、決済など、取り消せない操作の前後では「実行中」「完了」「失敗」の状態を明確に伝える。
• 非同期処理: バックグラウンドで処理が走っている場合（メール送信、データ同期など）、ユーザーが気づかないまま失敗していることを防ぐ。
• 複数ステップのフロー: 登録フロー、購入フロー、設定ウィザードなど、今どのステップにいるかを常に示す。

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

• 通知の過多: すべての状態変化を通知すると、ユーザーは通知疲れを起こし、重要な通知を見逃す。状態表示の優先度付けが必要。
• パフォーマンスとの兼ね合い: リアルタイムの進捗表示はサーバー負荷を増やすことがある。ポーリング頻度とUXのバランスを取る。

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

状態の可視化は「情報を表示する」技術ではなく、「ユーザーの不安を消す」設計である。

設計判断の基準

• 「この操作の結果、ユーザーは0.1秒以内に何かが変わったことを知覚できるか？」→ できなければ即時フィードバックを追加する。
• 「処理中の状態で、ユーザーは他の操作をしてよいか判断できるか？」→ できなければ操作可能範囲を明示する。

優先順位の考え方

• 1. 即時反応（最優先）: 操作を受け付けたことを0.1秒以内に返す（ボタンの色変化・押し込み感など）。
• 2. 進捗の可視化: 1秒以上かかる処理にはスピナー、3秒以上にはプログレスバーと残り時間の目安。
• 3. 完了・失敗の明示: 処理が終わったら「成功」「失敗」を明確に伝え、次のアクションを示す。

例外条件

• 意図的に「処理している感」を演出するため、あえて短い遅延を入れることがある（人工的な待機時間）。即時すぎると「本当に処理されたのか？」と感じるケースへの対処。

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

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

これがないと、ユーザーは操作の結果を確認できません。

操作への即時反応があるか: ボタンクリック・タップ後、0.1秒以内に視覚的な変化（色変化・押し込み・ローディング開始）が起きるか？何も変わらない「無反応」状態になっていないか？
処理中状態が明示されているか: API呼び出しやファイル処理など、完了まで時間がかかる操作では、スピナー・プログレスバー・スケルトンスクリーンなどで「処理中」であることを示しているか？
完了・失敗が明確に伝わるか: 処理が終わった後、成功なのか失敗なのかが一目でわかるか？エラー時は「何が失敗したか」「どうすれば直るか」まで伝えているか？

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

「安心して待てる」「次に何をすべきかわかる」状態です。

残り時間・進捗率を示しているか: プログレスバーに「残り約30秒」「3/5ステップ完了」など、完了までの見通しを示しているか？
操作可能範囲が明示されているか: 処理中に他の操作ができるのか、できないのかが明確か？できない場合はUIをグレーアウトし、できる場合は「バックグラウンドで処理中」と表示しているか？
状態の履歴が確認できるか: 「最終保存：2分前」「最終同期：今」など、過去の状態変化をユーザーが確認できるか？

5. UI例

操作の結果が見えないUIと、状態を丁寧に伝えるUIの違いを比較します。

改善プロセス

1. 操作ごとに状態を洗い出す: 「送信前」「送信中」「成功」「失敗」の4状態を必ず設計する。「送信中」を省略しがちなので注意。
2. 時間軸で考える: 0.1秒・1秒・3秒の閾値を意識し、それぞれの待機時間に適した表示（即時変化・スピナー・プログレスバー）を選ぶ。
3. エラーメッセージを具体化する: 「エラーが発生しました」ではなく「メールアドレスの形式が正しくありません」「通信エラーです。再度お試しください」のように、原因と対処を伝える。

6. 関連リンク

• 関連リファレンス（理論）: フィードバック
• 用語集（定義）: システム状態の可視化, フィードバック
• 関連するUI原則（横）: フィードバック (Feedback), 誤操作を防ぐ (Error Prevention), エラーから回復できる (Error Recovery)
• 関連するUIコンポーネント: Toast（トースト通知）, Alert（アラート）, Notification Center（通知センター）, Status Bar（ステータスバー）, Badge（バッジ）, Loading（ローディング）, Spinner（スピナー）, Progress Bar（プログレスバー）, Empty State（空状態）, AI Chat UI（AIチャットUI）, Editor Patterns（エディターパターン）

7. まとめ

今日から直せる一手 担当しているサービスのフォーム送信ボタンを押してみてください。送信中にボタンの見た目は変わりますか？完了後に明確なメッセージが出ますか？何も変わらないなら、まずボタンに「送信中…」とスピナーを追加するだけで、ユーザーの不安は大きく減ります。

チームに共有するなら一言 「ユーザーが不安になるのは、操作が難しいからではない。今何が起きているかを教えてもらえないからだ。」