「もう少し良くして」をタスクに
曖昧なフィードバックを検証可能な作業に
以下の曖昧なフィードバックを、実行できる作業に翻訳してください。まず、それが指しうる具体的な問題を3つ挙げ、それぞれに観測できるシグナルを添えます。次に、私が答えるべき3つの質問（目標、現状、合格基準）を投げかけてください。そのうえで既定案として、変えるもの・変えないもの・検証方法・作業量の目安を示します。すぐに作り直さず、「最適化」を「作り直し」と解釈しないこと。 [曖昧なフィードバック] [現在の版／データ]
使い方
先に「どこまで行けば良いと言えるか」を聞き、その後に「今どこが悪いか」を聞きます。どちらも答えられないなら、それは感情であって要件ではありません。
向いている場面
- レビューで上司が「このページをもう少し良くして」と言うが、どこが悪いかは言わない。デザイナーはすでに3回目の修正をしている。
- 顧客から「レポートをもう少し使いやすく」と言われるが、速度なのか、集計定義なのか、操作手順なのか分からない。
向いていない場面
- すでに性能問題だと分かり、監視データもある場合。ボトルネックを直接特定すればよく、要件のすり合わせは不要です。
- 相手が役員で、方向性を一文だけ示した場合。質問を10個投げるより、低コストの具体案を一つ持って行ってすり合わせるほうが有効です。
例
入力
上司（グループチャット）：このキャンペーンページ、もう少し良くして。転換が低い気がする。現在の転換率は2.1%、業界平均は3%前後。ページは上からバナー、規約、商品一覧、申込ボタン。
得られるもの
まず可能性を三つ挙げます：訴求が不明瞭（シグナル：ファーストビューの滞在が3秒未満）、規約が長い（シグナル：商品一覧までスクロールする人が少ない）、ボタンが下すぎる（シグナル：申込クリックがページ下部に集中）です。目標の転換率、変更可能な範囲、公開時期を確認します。既定案はファーストビューの訴求とボタン位置を直し、規約は折りたたみ、商品一覧は変えず、A/B を1週間回してサンプルが十分になってから判断し、作業量はデザイン1日＋開発2日程度です。
よくある誤用
- 「はい、もう少し良くします」とだけ返す。相手は理解したと思い、直してもまた「なんか違う」となり、1往復を無駄にします。
- 「最適化」を「全部作り直す」と解釈する。問題を特定せず構造をひっくり返すので、比較データも取れず、効いていた部分も捨ててしまいます。
こう変えると効く
- 「三つの方向の改案を、それぞれ期待効果一行付きで出す」と足す。言葉にできないが良し悪しは分かる相手に向きます。
- 「一箇所だけ変える最小実験から始める」と足す。転換率の議論をデータで決着させたい場合に有効です。