クレーム 1 件を変更 1 件に
言われたところではなく、実際に起きたところを直す
ユーザーの言葉そのままです：［クレームを貼り付け］。言われたとおりに実装しないでください。次のように分解します：1）「言ったこと / 実際にしたこと / 実際に起きたこと」の 3 列で書く；2）考えられる画面側の原因を 3 つ、可能性の高い順に根拠つきで挙げる；3）最も可能性の高いものに最小の変更を提案し、文言・部品・導線のどれを変えるか明記する；4）文字どおりに直すとどんな新しい問題が起きるか指摘する；5）検証方法を示す（どの指標を、どれくらい見れば直ったと言えるか）；6）ユーザーへの返信を一文で書く。できない約束はしないでください。
使い方
原因を推定する前に再現してください。操作の録画があれば、誰かの伝聞より確実です。
向いている場面
- サポートから「このボタンを押しても反応しない」と転送されてきます。ボタンの反応をそのまま直しに行くと、見当違いの場所を直すことになります。
- アプリストアの星 1 のレビューが感情的な言葉で書かれています。その中には具体的な画面の判断が 1 つ隠れていることが多く、分解しないと使えません。
向いていない場面
- クレームに再現手順とエラーコードがすでに書かれている場合です。それはバグの流れなので、原因を推定するより再現する方が速いです。
- 同じ内容の声が 20 人から届いている場合です。まず分類して件数を数えます。1 件を深掘りすると共通の原因を取り逃がします。
例
入力
「住所を変えるたびに配送時間を選び直すのが本当に面倒」——3 人のユーザーから、いずれも決済ページで
得られるもの
3 列に分けると、言ったことは「時間を選び直す」、実際にしたことは「住所を変えた後にもう一度時間選択を開く」、実際に起きたことは「住所変更で選択済みの時間帯が消える」でした。最も可能性が高い原因は、住所フォームの送信が配送モジュール全体の状態をリセットしていることで、最小の変更は住所関連の項目だけをリセットし、配送時間帯は保持することです。文字どおり「前回の選択を覚える」を足すと、本当の問題である状態リセットが隠れます。検証は決済ページの離脱率と時間帯の再クリック率を 2 週間見ます。
よくある誤用
- クレームをそのまま要件として工程に載せる場合です。ユーザーが語るのは症状で、原因ではありません。言われたとおりに直しても、言い方だけが消えることが多いです。
- 「ユーザーが使い方を分かっていない」で結論を出す場合です。その結論は検証できず、画面の変更も 1 つも生みません。
こう変えると効く
- 「クレームを言った本人に再現してもらう」に変えます。短いスクリプトを書いて操作の流れを語ってもらう方が、誰かの伝聞より現実に近くなります。
- 「このクレームを直さない理由を探す」を足します。製品の戦略を指している苦情もあり、それに合わせると別の利用者を傷つけます。