フィードバックと通知

前回の続き——「自動で置かれる状態」から「操作への反応」へ

前回のH-07では、ローディング状態・空状態・エラー状態という、画面が自動的に置かれる状況の設計を学びました。今回扱うのは、利用者の操作に対して画面が返す反応です。ボタンを押す、保存する、削除するといった能動的な行為に、システムがどう応答するか。ここを設計しておかないと、利用者は自分の操作が届いたのかどうか分からなくなります。

このスライドのポイント

• H-07: ローディング・空・エラーは、画面が自動的に置かれる状況の設計だった
• 今回: 利用者が能動的に操作したときに画面が返す反応の設計
• 対象は、押す・保存する・削除するといった行為への応答

定義——フィードバックと通知、そして3つの原則

フィードバックとは、操作に対する画面の反応のことです。押せた、保存された、失敗した、という結果を利用者に返す表示すべてを指します。通知とは、その結果を伝えるための具体的な表示で、画面隅に数秒だけ出る一時表示や、実行前に確認を求めるダイアログなどが含まれます。原則は3つです。すべての操作にほぼ即時の反応を返すこと、結果をはっきり示すこと、失敗したときは理由と次の一手を添えることです。そして削除のような破壊的操作、つまりA-09で見た戻せない変更には、事前の確認か取り消し手段のどちらかを必ず付けます。

このスライドのポイント

• フィードバック＝操作に対する画面の反応（押せた・保存された・失敗した）
• 通知＝結果を伝える表示（画面隅の一時表示、確認ダイアログ等）
• 原則3つ: ①ほぼ即時に反応 ②結果を明示 ③失敗時は理由と次の一手
• 破壊的操作（削除等＝A-09の戻せない変更）は、事前確認か取り消し手段のどちらかを必ず付ける

なぜ必要か——無反応は二重処理と不信を生む

この反応を設計しないと、何が起きるでしょうか。押したのに何も起きないように見えると、利用者は届かなかったと思ってもう一度押します。その結果が二重処理です。保存されたかどうか分からなければ、利用者は不安で画面を閉じられません。反応の欠落は、そのまま利用者の信頼の欠落につながります。だからこそ、反応を返すことを後回しの飾りではなく、最初に決める仕様として扱います。

このスライドのポイント

• 押したのに何も起きない（ように見える）→連打→二重処理
• 保存されたか分からない→不安で画面を閉じられない
• 反応の欠落は、そのまま信頼の欠落になる

構造——フィードバックの4象限と破壊的操作の2択

フィードバックは、成功か失敗か、そして即時か処理後か、という2つの軸で4象限に整理できます。押した瞬間の反応と、しばらく待った後の結果、それぞれに成功と失敗の表示を用意します。特に注意すべきが破壊的操作です。削除のように元に戻せない操作には、実行する前に確認するか、実行した後でも取り消せるようにするか、どちらか一方を設計として必ず選びます。両方付けても構いませんが、どちらも無いという選択だけは避けます。

このスライドのポイント

• フィードバックを2軸で整理: 成功／失敗 × 即時／処理後
• 4象限それぞれに、返す表示を用意する
• 破壊的操作は別枠: 事前確認 or 取り消し可能のどちらかを設計で必ず選ぶ

具体例——削除ボタンをどう設計するか

具体例として、削除ボタンを考えます。押した瞬間に確認もなく消えてしまう設計は、A-09で学んだ戻せない変更をそのまま事故にします。防ぐ方法は2つあります。1つは、本当に削除しますかと実行前に確認ダイアログを出すこと。もう1つは、削除した直後に数秒間、取り消しますかという表示を出すことです。どちらを選ぶかは設計で決めますが、どちらも無いという選択だけは避けます。経費申請や日報の削除でも、考え方は同じです。

このスライドのポイント

• 確認なしで即削除＝A-09の戻せない変更を事故にする設計
• 対策A: 実行前に「本当に削除しますか」の確認ダイアログ
• 対策B: 削除直後に数秒間「取り消しますか」の表示
• どちらを選ぶかは設計判断。「どちらも無い」だけは不可

技術サンプル——操作と返すべき反応の対応表

主要な操作と、それぞれに返すべき反応を1つの表にまとめました。保存の成功には完了表示、保存の失敗には理由と再試行の案内、削除には事前確認か取り消し、時間のかかる処理には進行状況の表示、そして入力ミスにはH-05で学んだその場での指摘を返します。この表は、そのままAIへの指示書になります。反応が決まっていない操作が1つでもあれば、それが設計の穴だと考えてください。

このスライドのポイント

• 種別: table
• 目的: 各操作に対して返すべき反応を、抜けなく決める指示書にする
• サンプル本体:

混同しやすい概念——「完了した」と「伝わった」は別

ここで区別したいのは、処理が完了したことと、完了したと利用者に伝わったことの違いです。システムの側で保存が成功していても、画面に何も出なければ、利用者にとっては成功していないのと同じです。システムの事実と、利用者の認識は別のものです。この2つの間にある溝を埋めるのが、フィードバックの役割だと言えます。作り手はつい前者だけを見て「できている」と判断しがちなので、後者まで含めて設計します。

このスライドのポイント

• 処理が完了した（システムの事実）≠ 完了したと利用者に伝わった（利用者の認識）
• 保存が成功しても、画面に何も出なければ利用者には未成功と同じ
• この溝を埋めるのがフィードバックの役割

バイブコーディングでの確認点——無反応の操作を探す

バイブコーディングでAIに画面を作らせたら、反応のない操作を探してください。AIへの質問例は、このアプリの各操作に対するフィードバックを一覧にして、反応が無い操作を指摘してください、というものです。特に削除などの破壊的操作については、事前確認か取り消しのどちらかが付いているかを必ず確認します。AIは指定しなければ、確認なしで即座に実行する画面を作りがちだからです。ここは人間が仕様として先に渡すべき部分です。

このスライドのポイント

• AIが作った画面から「無反応の操作」を探す
• 削除などの破壊的操作に、事前確認か取り消しがあるかを必ず確認
• AIは指定しないと、確認なしで即実行する画面を作りがち

まとめ——操作には必ず反応を

最後に一問一答です。破壊的操作に必ず付けるべき2択とは何でしょうか。少し考えてみてください。答えは、事前の確認か、取り消し手段です。今日の30秒まとめです。すべての操作には反応を返す、これがフィードバックの原則で、システムの事実を利用者の認識に変える仕事でした。次回のH-09では、画面幅への対応、レスポンシブデザインへ進みます。関連資料は、通知・リマインド設計30と、UI改善プロンプト50です。

このスライドのポイント

• 一問一答: 破壊的操作に必ず付けるべき2択は？
• 30秒まとめ: すべての操作に反応を返す。事実を利用者の認識に変えるのがフィードバック
• 次回: H-09 レスポンシブデザイン（画面幅への対応）
• 関連資料: 「通知・リマインド設計30」「UI改善プロンプト50」