心を込めたエラーメッセージでユーザに価値を届ける

¡Hola!プロダクトマネージャーをしているマイコです。

現職にはマーケティング職として入社し、マーケティング業務の傍らエラー調査と処理を行なっていました。ある日、社長にデータとともにプロダクトのエラーについて熱く語ったところ、そのままプロダクトマネージャーとして問題解決することになりました。
（それまでプロダクトマネージャー不在だったので誰かを押し退けたわけではないです、念の為）

急なポジションチェンジに戸惑いつつも、問題解決好きとしてまずは手持ちの情報の整理から始めました。

ツリー図で現状整理

手始めに行ったのが、全体を俯瞰できるエラーのパターンのツリー図作成です。
エラーには大きく分けて①ユーザが想定外の動作をするなどユーザに起因するもの、②設計不良や不備などシステムに起因するもの、③ネットワークやサーバ障害など外部要因があります。

このツリー図作成過程を通じて、全体像の可視化だけでなく、取り組むべき問題の共通理解を醸成することができました。

解決すべき問題を特定する

次に、ツリー図にある各エラーについて、現在の対応状況を記入しました。
その際に用いたのが次の3段階評価です（「エラーが発生しない」のが最高ですが、今回は難しいのでスコープ外とします）。

1. エラー原因であることを特定できる

2. エラー発生時に検出できる

3. エラー発生時に適切なエラーメッセージが表示される

エラーのツリー図と評価の結果イメージ

「0」は1にも達していないものです。

「3」は対応が完了しているため、新たなアクションは不要です（改良の余地はあるかもしれません）。
「2」については、ユーザ自身に解決を促さず自社で解決する場合は現状維持でOK。
「0」と「1」は漏れなく対応を検討する必要があります。

ここまでくれば、解くべき問題も、解決策も自ずと決まります。

アインシュタインも
「地球を救うために1時間の時間を与えられたとしたら、59 分を問題の定義に使い、1分を解決策の策定に使うだろう」
と言ったとか言わなかったとか。

解決する

いよいよ解決フェーズです。

特に注力したのが、ユーザが自己解決できるようなエラーメッセージを表示することでした。

エラーパターンごとに分岐させそれぞれ適切なエラーメッセージ表示させるようにしました。

エラーメッセージの文言も、
結果的にはシンプルでありきたりな文言に落ち着いたのですが、その1行にユーザ体験を良くしたいというみんなの想いを詰め込みました。

効果測定する

社長に直訴してまで押し進めた今回のエラー対応再設計。有効であると信じていましたが、1、2ヶ月後には想像以上効果が表れ、ユーザからのお問い合わせがほぼ皆無になりました。

このプロジェクトからの学び

プロダクトマネージャーとして初めて担当した今回のプロジェクト。
ここから得られた学びは二つあります。

一つ目は、新しくてカッコいい機能を作るだけがプロダクト開発じゃない、当たり前のことを丁寧にやることだって立派な価値創出だということ。そしてもう一つは、問題発見・解決の「考え方」は普遍的であるということ。

これからも問題解決して、ユーザに良い体験を提供できるプロダクト開発をしていきます！