ユーザーフィードバックを変更リストに変える
不満の山から、直すべきことと直さなくてよいことを見極める
以下はユーザーフィードバックの原文です：[フィードバックを貼付]。デザイン変更リストに変換してください：1）まず 6 カテゴリ以内の問題に統合し、各カテゴリの出現回数を記す；2）ユーザーが言ったことと実際に遭遇したことを分け、表現の問題かフローの問題かを示す；3）各項目に変更アクションを 1 つ、UI・フロー・コピーのどれを変えるか明記；4）「影響人数 × 修正コスト」で並べる；5）従うべきでない提案を挙げ、理由を述べる。フィードバックをそのまま要件にせず、声が大きいという理由で上位に置かないこと。
使い方
フィードバックが 20 件未満だと結論は不安定。数を貯めてからこのステップを行う。
向いている場面
- フィードバックが溜まった（グループチャット、チケット、ストアレビュー）。今回どれを直すか決めたい——まずカテゴリに統合し、影響人数×修正コストで並べる。
- 会議で「声が大きい人を先に」を止めたいとき——従うべきでない項目とその理由を明記したリストが必要。
向いていない場面
- フィードバックが 20 件未満——サンプルが小さく、分類も順位も安定しない。数を貯めるか、ユーザーインタビューに切り替える。
- ヘビーユーザー 1 人からの意見だけ——全体を代表しない。まずユーザー層で分けて見る。でないと製品が 1 人の道具になる。
例
入力
20 件のフィードバック：7 件が「書き出しが遅い」、5 件が「書き出しボタンが見つからない」、3 件が一括削除の要望、2 件が表の文字が小さい、残りは散発的
得られるもの
4 カテゴリに統合：書き出し性能 7、書き出し導線の発見性 5、一括操作 3、可読性 2。言っていることと実際の遭遇を分離：「遅い」7 件のうち 3 件は待っても反応がなく固まったと誤認したもので、ローディング状態の問題だと指摘。各項目にアクションと変更種別（UI・フロー・コピー）を付け、発見性を先頭に置く（コスト最小で 5 人に効くため）。最後に従うべきでない項目として、一括削除は低頻度なので観察とする。
よくある誤用
- フィードバック原文をそのまま要件としてスケジュールする——ユーザーが言うのは症状で解決策ではない。字面通りに直すと往々にして見当違いを直すことになる。
- 出現回数だけで並べ、修正コストと影響範囲を見ない——最も声の大きい項目が、最も直しにくく最も影響の小さいものだったりする。
こう変えると効く
- 「各カテゴリが UI・フロー・コピー・性能のどれかを明記する」を足す——すべての問題を UI の問題として直す事故を防げる。
- 「影響×コストで並べる」を「今週やる／次の版でやる／やらないの 3 段に分ける」に変える——そのまま日程に対応し、議論が収束する。