今日の問い
処理が終わらないとき、利用者は待つべきか直すべきか分かりますか。
30秒でつかむ
画面は、データがそろった通常状態より、途中の状態で迷いが生まれます。主要フローの各場面にLoading、Empty、Error、Partial、Undoを当て、必要な案内と操作を決めます。
五つすべてを毎画面に作るのではありません。起こり得る状態だけを選び、利用者が次にできることを示します。
30秒図解 · LESSON 17
分岐図
正常以外の状態が体験を決める
待機、空、失敗、部分成功、取消を最初から構造に含めます。
操作の結果
- Loading
- Empty
- Error
- Partial
- Undo
CLUE · 見抜く手掛かり
次に取れる行動が各状態にあるか
TRAP · ありがちな罠
エラーを赤文字だけで終える
原則
Loadingは処理中です。何を待っているかを伝え、時間が読める処理なら進み具合も示します。同じ操作を重ねて送らないよう、実行中の扱いも決めます。
Emptyは表示する対象がない状態です。初回利用、検索結果なし、権限不足では理由と次の行動が違います。「データがありません」だけで一括りにしません。
Errorは処理が完了できない状態です。何が起きたか、利用者が直せるか、再試行して安全かを伝えます。入力値を消すと、修正の負担が増えます。
Partialは一部だけ成功した状態です。たとえば予約日時は変わったが、通知メールだけ送れない場合です。成功と失敗を分けて示さないと、利用者は変更操作そのものを繰り返すかもしれません。
Undoは完了した操作を一定の条件で戻す手段です。破壊的な操作を確認画面だけで守るより、取り消せる設計が合う場面があります。ただし決済や外部連携など、本当に戻せる範囲を明記します。
この五状態はAMPLで実装漏れを減らすための確認枠です。根にある原則は、現在の状態と次に取れる行動を適切な速さで伝えることです。
システムの現在状態と操作結果を適切なフィードバックで知らせ、利用者が次の行動を判断できるようにする原則を支える。
良い例と惜しい例
部分成功の伝え方
状態を切り替え、表示すべき事実と次の行動の違いを確認してください。
Loading
変更処理中と伝え、重複送信を防ぎます。
Empty
変更できる予約がない理由と戻り先を示します。
Error
失敗した処理と安全な再試行方法を示します。
Partial
予約変更の成功と通知送信の失敗を分けて示します。
Undo
取り消せる期限と影響を示します。
AIへの指示例
目的: 予約変更フローの各画面について、通常時以外の状態と回復操作を設計する
制約: 五状態を機械的に全画面へ追加しない。成功済み処理を再実行させない。取り消せない処理をUndo可能と書かない
参照: primary-flow.md、各APIの成功条件と失敗条件、再試行の安全性
受入条件: ui-states.mdに画面id、状態名、発生条件、表示する事実、可能な操作、戻り先を記し、主要フローの全画面を一度確認する
確認問題
セルフチェック
1. 予約変更は成功し、確認メールだけ失敗しました。最も安全な表示はどれですか。
最終制作へ反映する
主要フローの画面状態表
primary-flow.mdの各画面に起こり得る状態を選び、発生条件、表示内容、可能な操作、戻り先をui-states.mdへ記す。
Acceptance criteria
- 主要フローの全画面について通常時以外の状態を検討した記録がある
- 各状態から利用者が取れる操作と、処理を再実行してよい条件が分かる
今日のまとめ
- 途中状態では、現在の事実と次にできる操作を伝える
- 部分成功は成功と失敗を分け、成功済み処理の重複を防ぐ
- 次は、主要フローと状態を低忠実度の画面へ移す