ユーザーフィードバックを次のプロンプトに変える: 人々がよく間違える3つの方法

何かをリリースし、人々が使い始めると、1週間以内にメッセージが届き始めます。「分かりにくい」という星1レビュー。「これもXできる？」というDM。見つからなかったボタンについて実は愚痴を言っているだけのサポートチケット。これは良い問題です。何かがおかしいと伝えるだけ、人々が気にかけてくれているということだからです。しかし、これはまた、ほとんどのビルダーが静かに事態を悪化させ始める瞬間でもあります。フィードバックをプロンプトに変えるのは簡単なはずだと感じますが、実際にはほとんどそうではありません。

私はこれまで、リリース後に良くなるどころか悪くなっていくビルドをたくさん見てきましたが、それはフィードバック自体が悪かったからではありません。メッセージを読んでから次のプロンプトを打つまでの間に起きたことが原因であることがほとんどです。3つのパターンが繰り返し現れます。

間違い1：入力された言葉をそのまま実装する

あるユーザーが「ヘッダーにダークモードのトグルがあればいいのに」と言ったとします。そこであなたはビルドチャットを開いて「ヘッダーにダークモードトグルを追加して」と入力します。ビルダーはそれを実行します。チケットは解決、そうでしょうか？

実はそのユーザーが本当に望んでいたのはヘッダーのトグルではなく、夜に目が疲れなくなることでした。システム設定に自動的に追従して、二度と考えなくて済むようにしたかったのかもしれません。あるいは本当の問題は、背景がきつい白色で、トグルはほかに何を頼めばいいか分からず考え出した回避策だったのかもしれません。ユーザーは症状を説明するのは得意ですが、修正法を処方するのは苦手です。何が実装しやすく、何が難しいかを知らず、トグル一つのためにアプリ内の他の十数か所で整合性を保つ必要があることも考えていないからです。

ここでの弊害は積み重なっていきます。1週間で5件の機能要望が来て、その5件をすべて文字通り実装すると、ダークモードトグル、「コンパクト表示」トグル、「サイドバー非表示」トグル、他の3つと半分矛盾する「シンプルモード」チェックボックスが並んだ設定パネルができあがります。誰も設定パネルを頼んではいません。それでも一つひとつの文字通りの要望に応えるうちに作ってしまい、今では新機能を追加するたびに、誰も覚えていない組み合わせ爆発的なトグル状態に対してテストしなければならなくなります。

要望はデータであり、仕様ではありません。その間の翻訳作業があなたの仕事であり、それを省略することが、フィードバックが肥大化に変わる最も一般的な原因です。

間違い2：黙り続けて、あとで一気に投げ込む

逆の失敗は、外から見ると規律正しく見えます。届くメッセージ一つひとつに反応せず、それはおおむね良い判断です。しかし、2週間分のチケットをスプレッドシートに溜め込み、ある土曜日に座って一つの長大なプロンプトを書きます。「決済のバグを直して、エクスポート機能を追加して、オンボーディングフローを作り直して、モバイルナビを直して、料金ページのコピーを更新して」

ビルダーは全力で対応しようとしますが、あなたは無関係な5つの変更を1回のパスで、しかもおそらく重なり合うファイルに触れるコードベースの中で、一度に投入することになります。何かが壊れたとき、これだけの規模の変更なら大抵何かが壊れますが、5つの要望のうちどれが原因かを見分けられません。バージョン履歴には、5つのレビュー可能な差分ではなく、1つの巨大な差分だけが残ります。決済の修正が回帰を引き起こしたためにロールバックが必要になっても、うまく動いていたオンボーディングの作り直しまで一緒に巻き戻すことになります。その実行の検証記録は、あなた自身を含め誰も1行ずつ読むことのない変更の壁になります。

バッチ処理は効率的に感じられます。しかし、バッチの中で何かがうまくいかなくなった瞬間、実際には正反対の非効率になります。デバッグが1本の糸を追うのではなく、5本の糸をほどく作業になってしまうからです。

間違い3：最も声の大きいメッセージにロードマップを決めさせる

これは、やっている最中には最も気づきにくいものです。あるユーザーが、望む機能について怒りのこもった詳細で説得力のあるメールを送ってきます。文章は上手く、具体的で、明らかに10分かけて書かれたものです。誰かが実際に10分かけて注いだ注意は、あなたも10分かける価値があるように感じられます。そこであなたは今やっていたことを止めて、それを作り始めます。

一方で、もっと静かな40人のユーザーは毎週同じ分かりにくいサインアップステップにつまずき、そのまま離脱していきます。誰もそれについて長文を書きません。何も送らず、ただ戻ってこないだけです。その沈黙は、返信を求めてあなたの受信箱に現れることは決してありません。メッセージの新しさや文字数の多さは重要性と同じではありませんが、そう感じてしまいます。特に夜11時、目の前に一件のメッセージがあり、まだ開いてもいない分析ダッシュボードの中に40件の未コンバージョンが眠っているときには。

本当に正しいプロンプトとはどんなものか

対処法はプロセス図ではなく、習慣です。メッセージを読んだら、ビルドチャットに触れる前に、その裏に何があるのかを考える。ダークモードを求めるユーザーが現れたとき、その根底にあるニーズはたいてい「夜間の目の疲れを減らしたい」であり、より安く、より良い答えはしばしば「OSレベルのカラースキーム設定を尊重する」こと――新しいUIも、維持すべきトグルも不要な一行で済みます。1週間に5件のチケットが届いたら、何かを書く前にパターンを探してください。もし3件が実は同じ混乱を3通りの言い方で表現しているだけなら、それは3つのプロンプトではなく1つのプロンプトです。

急いで進めたい気持ちがあっても、変更は単一目的に保ちましょう。「更新時にゲストユーザーのカートが消えるチェックアウトエラーを修正する」というプロンプトなら、一度で検証でき、間違っていればきれいにロールバックできます。それはまた、6週間後にも意味を持つバージョンカードを残すことにもなります。「各種修正」としか書かれていない変更履歴ではなく。

そしてフィードバックは、感情の量ではなくパターンで重み付けしましょう。他の3人のユーザーも直面した簡潔な一言の不満は、誰も使っていないワークフローについて説明する巧みな要望よりも、次のプロンプトに値します。ここで実際の利用状況――どこで人が離脱するか、離脱前に何をクリックしているか――を見ることが価値を発揮します。それは、声の大きい少数派がメールを送っている間、声なき多数派が実際に何をしているかを教えてくれるからです。

これは、わざわざ連絡してくれたユーザーを無視しろという意味ではありません。「最近、最も説得力を持って書いてきた人」が次に作るものを決めるアルゴリズムになってはいけない、という意味です。メッセージは会話の始まりであり、チケットではありません。誰かが言ったことを、実際にビルダーに依頼する内容へと翻訳する作業は、依然としてあなた自身が、毎回行うべきものです。