#527
インタラクション・アニメーション
#527らっかんてきゆーあい
楽観的UI
別名・表記:Optimistic UIオプティミスティックUI楽観的更新Optimistic Update
UIXHERO Definition
UIXHEROでは、楽観的UIを「サーバーの応答を待たず、成功を前提に画面を先に更新し、失敗した場合に取り消す実装方針」と定義する。
概要
通信を伴う操作には、通常「操作 → 待機表示 → 結果反映」という3段階がある。楽観的UIはこの待機表示を省き、「操作 → 結果反映（仮） →（失敗時のみ）巻き戻し」に置き換える。
応答時間の研究では、およそ0.1秒以内であれば直接操作している感覚が保たれ、1秒を超えると思考が途切れ始めるとされる。楽観的UIは、通信時間をこの0.1秒の枠内に見せかける手段だと言える。
UXでの活用
- 軽い操作の連打対応: リスト内で複数項目を素早く操作する場面では、1件ごとに待たされると作業が成立しない。
- モバイル回線への耐性: 通信が不安定な環境で、操作感を維持できる。
- 状態表現の工夫: 送信中を薄い色や小さなインジケータで示すと、楽観的更新と確定状態を区別できる。
誤用・混乱
- 失敗時の扱いが本体: 楽観的UIの設計コストの大半はロールバックにある。静かに元に戻すだけでは、ユーザーは自分の操作が消えた理由を理解できない。
- 適用範囲を広げすぎない: 決済、予約、投稿の公開など、二重実行や取り消し困難な操作では、確定を待つほうが安全である。
- 速くなったわけではない: 実際の処理時間は変わらない。体感の改善であって、サーバー性能の問題を隠すために使うと、失敗率の上昇に気づきにくくなる。
💡 使いどころ
成功率が非常に高く、失敗しても取り返しがつく操作（いいね、フォロー、チェック、並べ替え）で、待ち時間を体感させたくない時。
⚠️ 注意点・誤用
失敗時のロールバックが必ず必要になる。取り消しの表現が弱いと、ユーザーは成功したと誤認したまま次の行動に進む。決済、送信、削除など、失敗時の影響が大きい操作には使わない。
具体例
- いいねボタンを押した瞬間に色が変わり、通信は裏で行われる
- チェックリストの完了チェックが即座に反映される
- 送信メッセージがグレー表示で先に並び、確定後に通常表示になる
出典・参考文献:
- Response Times に関する Nielsen Norman Group の解説記事（0.1秒 / 1秒 / 10秒の目安）
- Designing Interfaces (Jenifer Tidwell)
関連する解説記事
心理学・認知バイアス
ドハティの閾値 (Doherty Threshold)
UIXHERO POINT
- •UIXHEROでは、ドハティの閾値を「システムとユーザーが会話するように対話できる応答速度の限界点（0.4秒）」と定義する。
- •本記事では、物理的な速度の向上だけでなく、楽観的UIやスケルトン表示によって「待たされている」と感じさせない体感速度の向上策を整理する。
UI設計パターン
レスポンスと待ち時間設計 (Response Latency)
「遅い」より「わからない」がユーザーを壊す。待ち時間を正直に伝え、体感速度を設計する原則。スケルトン・プログレスバー・楽観的UIの使い分けと実装チェックリスト。