この記事の要点（UIXHERO視点） UIXHEROでは、フィードバックを「操作後に結果を伝える」、フィードフォワードを「操作前に結果を予告する」と定義し区別する。 フィードバックは「何が起きたか」を伝え、フィードフォワードは「何が起きるか」を伝える。両方を組み合わせることで、ユーザーは安心して操作できる。

導入：「押してみないとわからない」問題

「このボタン押したら何が起きるんだろう…」 「送信したけど、ちゃんと送れたのかな…」

UIを使っていて、こんな不安を感じたことはないでしょうか。

前者は フィードフォワードの不足 ** 、後者は ** フィードバックの不足 が原因です。

• フィードフォワード : 操作前に「何が起きるか」を伝える
• フィードバック : 操作後に「何が起きたか」を伝える

ユーザーは「事前」と「事後」の両方で、システムの状態を知りたい。

この記事の本質は「どちらが大事か」ではなく、「両方あって初めて安心して操作できる」という補完関係です。

---

フィードバックとフィードフォワードの違い（定義）

フィードバックは「事後」、フィードフォワードは「事前」の情報提供である。

項目	フィードバック	フィードフォワード
定義	操作の結果をユーザーに伝えること	操作の結果を事前に予告すること
タイミング	操作後	操作前
目的	「何が起きたか」を確認させる	「何が起きるか」を予測させる
例	保存完了のトースト通知	ボタンホバー時のプレビュー
対応する不安	「ちゃんとできたか？」	「これ押して大丈夫か？」

語源と背景

フィードバック は、制御工学の概念から派生しました。システムの出力を入力に戻す（feed back）ことで、自己調整を行う仕組みです。UIデザインでは、ドン・ノーマンが「システム状態の可視性」として重要性を強調しました。

フィードフォワード は、フィードバックの対概念として提唱されました。「事前に（forward）情報を提供（feed）」することで、ユーザーの意思決定を支援します。

研究からの引用 : 「フィードバックは行動の結果を知らせるが、フィードフォワードは行動の可能性を知らせる。」（Don Norman『誰のためのデザイン？』）

---

なぜ重要なのか

1. 不安のタイミングが異なる

タイミング	ユーザーの不安	必要な情報
操作前	「これ押して大丈夫？」「何が起きる？」	フィードフォワード
操作中	「ちゃんと処理されてる？」	進捗フィードバック
操作後	「成功した？失敗した？」	結果フィードバック

各タイミングで適切な情報を提供することで、不安を解消できます。

2. エラー防止の方法が異なる

アプローチ	方法
フィードバック	エラー後に「間違いです」と伝え、修正を促す
フィードフォワード	エラー前に「これは危険です」と伝え、防止する

フィードフォワードはエラーの「予防」であり、フィードバックはエラーの「治療」です。予防の方がユーザー体験は良くなります。

📌 補足 : これは代表的な役割分担です。実際にはフィードバックも次回の予防学習に効きますし、フィードフォワードも万能ではありません。両者は連続的に体験を支える関係にあります。

---

具体例・ケース比較

ケース1：ファイル削除

観点	フィードバック	フィードフォワード
タイミング	削除後	削除前
実装例	「ファイルを削除しました」トースト	「このファイルを削除しますか？この操作は取り消せません」ダイアログ
ユーザーへの効果	削除されたことを確認できる	取り消せないことを事前に理解できる

ケース2：フォーム入力

観点	フィードバック	フィードフォワード
タイミング	入力後、送信後	入力前、入力中
実装例	「メールアドレスの形式が正しくありません」エラー	「例: name@example.com」プレースホルダー、リアルタイムバリデーション
ユーザーへの効果	何が間違いかわかる	そもそも間違いを起こしにくい

ケース3：ボタン操作

観点	フィードバック	フィードフォワード
タイミング	クリック後	ホバー時、フォーカス時
実装例	ボタンの色変化、完了メッセージ	ホバー時のツールチップ「設定を保存します」、プレビュー表示
ユーザーへの効果	操作が受け付けられたことがわかる	操作前に結果を予測できる

ケース4：価格計算

観点	フィードバック	フィードフォワード
タイミング	購入確定後	購入確定前
実装例	「ご注文ありがとうございます。合計10,000円です」	カートでリアルタイムに合計金額・送料を表示
ユーザーへの効果	支払額を確認できる	購入前に総額を把握できる

---

実務でなぜ区別すべきか

UIXHEROがこの2つを厳密に区別する理由は3つあります。

1. 設計のタイミングが異なる

設計対象	フィードバック	フィードフォワード
ボタン	押した後の状態変化	ラベル、ツールチップ
フォーム	エラーメッセージ	プレースホルダー、入力例
処理	完了通知、結果表示	確認ダイアログ、プレビュー

両方を意識して設計することで、抜け漏れを防げます。

2. ユーザーの認知負荷が変わる

アプローチ	認知負荷
フィードバックだけ	「試してみないとわからない」→ 不安、試行錯誤
フィードフォワードあり	「押す前に結果がわかる」→ 安心、スムーズ

フィードフォワードがあれば、ユーザーは「考えずに操作」できます。

3. エラー体験が変わる

アプローチ	ユーザー体験
フィードバックでエラーを知らせる	「間違えた」→ 自己否定感、フラストレーション
フィードフォワードでエラーを防ぐ	「事前に教えてくれた」→ 安心感、信頼

エラー後の対応より、エラー前の予防の方がUXは良くなります。

---

フィードフォワードの実装パターン

1. ラベルとアイコン

• 明確なボタンラベル : 「送信」ではなく「注文を確定する」
• 意味のあるアイコン : ゴミ箱アイコンで「削除」を示唆

2. ツールチップとホバー効果

• ツールチップ : ホバー時に詳細な説明を表示
• プレビュー : ホバー時に結果のプレビューを表示（例：フィルター適用後の件数）

3. 入力補助

• プレースホルダー : 入力形式の例を表示
• リアルタイムバリデーション : 入力中にOK/NGを表示
• オートコンプリート : 入力候補を表示

4. 確認と警告

• 確認ダイアログ : 破壊的操作前に確認
• 警告表示 : 危険な操作の近くに注意書き

---

よくある質問 (FAQ)

Q1. すべての操作にフィードフォワードが必要ですか？

いいえ。重要度とリスクに応じて 使い分けます。

操作の性質	フィードフォワードの必要性
取り消せない操作（削除など）	必須
重要な操作（購入、送信など）	推奨
軽微な操作（ページ遷移など）	最小限でOK
頻繁な操作（お気に入り追加など）	最小限でOK

フィードフォワードが多すぎると、操作が煩雑になります。

Q2. フィードバックとフィードフォワードを両方入れるべき？

理想的にはYes ですが、優先順位があります。

1. 必須 : 結果のフィードバック（成功/失敗を伝える）
2. 推奨 : 処理中のフィードバック（ローディング表示）
3. 推奨 : 破壊的操作のフィードフォワード（確認ダイアログ）
4. あれば良い : 一般操作のフィードフォワード（ツールチップ）

Q3. フィードフォワードが逆効果になるケースは？

過剰なフィードフォワード は逆効果です。

• 毎回確認ダイアログが出る → 「はいはい」とスキップされる
• ツールチップが多すぎる → 情報過多で読まれない
• 警告が多すぎる → 狼少年効果で無視される

本当に重要な場面に絞ることが大切です。

---

関連リンク

UIXHEROの関連記事

• システム状態の可視性 — フィードバックの原則
• エラー防止 — フィードフォワードの活用
• マイクロインタラクション — フィードバックの実装
• アフォーダンスとシグニファイアの違い — 「何ができるか」の伝え方

用語集

• フィードバック
• フィードフォワード
• システム状態の可視性

---

まとめ

• フィードバック : 操作後に結果を伝えること（事後の情報提供）
• フィードフォワード : 操作前に結果を予告すること（事前の情報提供）
• 使い分け : フィードバックで「何が起きたか」を確認させ、フィードフォワードで「何が起きるか」を予測させる。両方を組み合わせることで、ユーザーは安心して操作できる。

「押してみないとわからない」UIは、ユーザーを不安にさせる。事前に結果を伝え、事後に結果を確認させる。この両方があって、初めて安心して使えるUIになる。