逆境にあろうとも、より良いエラーメッセージを書くこと
Oct 31, 2022この記事はWix UXのブログ: When life gives you lemons, write better error messagesの翻訳転載です。著作者のジェニファー・ナドラーさんの許可を得て公開しています。
エラーメッセージは、私たちのネット生活の一部となっています。サーバーがダウンしたとき、インターネットに接続できないとき、フォームに情報を入力し忘れたとき、私たちはいつもエラーメッセージを受け取ります。「Something went wrong（何か問題が発生しました）」というのがお決まりの表現です。しかし、何が悪かったのでしょうか？何が起こったのでしょうか？そして何よりも、どうしたら解決できるのでしょうか？
私たちは頻繁にエラーメッセージを目にしていますが、何が問題で、どうすれば解決できるかを理解するのに役立つメッセージは、どれほどあるでしょうか
1年ほど前、Wixでは、これらの問いにあまりにも答えられていないことにふと気づきました。このとき、私たちは個別のエラーメッセージへの対処だけでなく、すぐに行動を起こさねばならない感じました。
これは、たった1ヶ月でWixの何千ものエラーメッセージを変更したときのことです。
この取り組みを達成するために、私たちはまず、何が悪いエラーメッセージで、何が良いエラーメッセージであるかを自分たちで定義する必要がありました。
悪いエラーメッセージの特徴
悪いエラーメッセージの一例。不適切なトーンで、責任転嫁し、専門用語を使い、ありきたりです
（補足：記事原文では「取得」を難解なFetchと表記）
不適切なトーン：医者が手術をしているときに突然 「おっと！何かマズいことが起きたようだ…」と言い出したらどうでしょう。手術であれ、誰かの稼ぎに関することであれ、大きな賭けに出るとき、誰もが一番聞きたくない言葉でしょう。トーンを可愛らしくしたり、ふわふわさせたりしている場合ではないのです。私たちはユーザーに対し、事態の深刻さを認識しており、ことの重大さを理解していますよ、と示したいのです。
技術的な専門用語：ユーザー中心設計を掲げる今日でも、エラーメッセージに専門用語が紛れ込んでいることがあります。私のデータをFetchできませんでしたか？私のCredentialが拒否されましたか？なんですって？ユーザーは、技術的なことなどどうでもよく、何が問題で、どうすれば解決できるかを知りたいだけなのです。
責任転嫁：問題を引き起こした行為ではなく、問題そのものに焦点を当てるようにしましょう。たとえ自分がしたことが原因でそのエラーが表示されたとしても、ユーザーを責めるようなことはしたくありません。
また、Wixの負担が軽減されるとしても、第三者への責任転嫁はプロらしくない印象を与えるので、しないことにしました。ユーザーは、信頼できるプラットフォームとしてWixに来たのであって、他のプラットフォームについて考えたくはないのです。私たちは、「○○への接続に障害が発生しました」というようなことは言えますが、「○○は現在応答していません」のようには言わないでしょう。
やたらにありきたり（汎用的過ぎる）：エラーの原因がわからないこともありますが...時にはわかっていることもあります。原因が分かっているのに伝えないのは、ユーザーに対して大変な迷惑をかけていることになります。
良いエラーメッセージの特徴
良いエラーメッセージの一例。何がなぜ起こったのかを説明し、安心感を与え、共感させ、ユーザーが問題を解決する手助けをし、打開策を与えています
何が起きたのか、なぜ起きたのかを言う：何が起き、何が起きなかったのかを明確にする。これは、ビジュアルとテキストの組み合わせで実現できます。技術的な問題があったとしか説明できない場合でも、なぜこのエラーが発生したのかを説明しましょう。Wixでは、スペースがあれば「こちらの問題で」と言うことにして、ユーザーの責任ではないことを再度強調するようにしています。
安心感を与える：可能な限り、エラーの影響を受けていない部分を伝えます。例えば、メールが送信されていなくても、変更内容は下書きとして保存されていたのか、などです。
共感を持って：過剰な謝罪は避けたいところですが、状況次第では「Please（お願いします）」を使いたいと考えています。たとえば、本当に切迫した状況や、私たちではどうしても解決できないようなことです。そのような場合は、より共感を求めるために「Please」を使うかもしれません。
解決に導く：解決できる可能性がある場合は、どうすればよいかを正確に伝えます。スペースがない場合？ナレッジベースの記事を紹介し、「Learn how to resolve this（解決方法を見る）」や「How do I fix this?（これを解決するには？）」 などの説明的なリンクを貼りましょう。
つねに打開策を与える：問題を解決できない場合、またはその問題が起こり続ける可能性がある場合は、カスタマーケアに連絡する方法を伝えます。
さて、何が良いエラーメッセージか悪いエラーメッセージかを定義したところで、悪いエラーメッセージをなくす作業に取り掛からなければなりません。
悪いエラーメッセージをなくすために、どのように取り組んだか
コンテンツ管理のシステムで調べたところ、文字列または値に「エラー」と含まれるものが7,643個あることがわかりました。これは7,643個のコンテンツを最低限見直す必要があることを意味します。
この作業は途方もないものに思えました。
しかし、私たちはやり遂げたのです。エラーに関連するコンテンツを一つひとつ確認し、この取り組みに関連しているかどうかを判断しました。そして、「ありきたり（汎用的過ぎる）」あるいは「役に立たない」と評価したエラーのリストを作成し、そのすべてを開発者に送りました。
これがMonday.comのボードで、エラーに関連するあらゆるコンテンツを分類するために使用しました。このようなボードは、優先順位や期限を設定し、すべての部門に情報を行き渡らせるのに役に立ちました
開発者はメッセージを一つひとつ確認し、それぞれがコードのどこでトリガーされているかをマッピングしました。何がきっかけでメッセージが表示されるのか、どのくらいの頻度で発生するのか、その問題を解決するにはどうしたらいいのか。
このエラーマップをもとに、プロダクトマネージャー、UXデザイナー、ライターが集まり、解決策を考えました。まず、すべてをスプレッドシートからMonday Boardに移し、進捗状況や必要なことを簡単に把握できるようにしました。時には、簡単なコンテンツの入れ替えで済むこともあります。また、まったく新しいエラーメッセージが必要になることもありました。さらには、その裏で修正すべき追加の開発作業が発生するケースも多々ありました。
そして、どのエラーから手をつけるか、優先順位をつけました。優先順位を決めるにあたっては、エラーの発生頻度と、そのエラーによってユーザーがフローを完了できなくなるかどうかに注目しました。その後、1週間から4週間のマイルストーンを設定し、途中で頓挫しないようにしました。
私たちが学んだこと
ありきたりなメッセージと、不明瞭なメッセージは別物です。確かに「何か問題が発生しました」というありきたりなメッセージはたくさんありましたが、不明瞭なメッセージもたくさんありました。これらもまた悪いエラーメッセージであり、同じように注意を払う必要があります。
ありきたりな（補足：汎用的過ぎる）メッセージと、不明瞭なメッセージの比較例です。ありきたりなメッセージでは、何かがうまくいかなかったということ以外、ユーザーには何も伝えていません。不明瞭なメッセージでは、何が問題だったのかを説明しようとしていますが、分かりにくい表現が使われています
ほとんどの場合、コンテンツの問題ではありません。このプロジェクトが始まったきっかけである当社CEOのアビシャイ・アブラハミは、全社員に宛てたメールの中で、次のように語っています。「ありきたりなエラーは、誤った開発とプロダクトの結果である。...私たちは、全員が一丸となってこの問題に取り組まなければならない」
これらのエラーを修正するために、文字通りWixの全社員がいくつもの分野を横断して協力しなければなりませんでした。開発者は、調査を行い、マップを作成しなければなりませんでした。プロダクトマネージャーは、優先順位をつけ、タスクを作らねばなりませんでした。デザイナーは、新しいフローに新しいデザインを、そして、私たちUXライターは、何千ものエラーメッセージを書き直さなければなりませんでした。
私たちはもっと質問すべきです。以前はよく、開発者が私たちに「ここによくあるエラーメッセージが必要なんだけど、追加してもらえる？」と言われることがありました。私たちは「はい」と答え、それが代替のメッセージや稀にしか表示されないメッセージだと考えていました。そして、「なぜユーザーはこのメッセージを見るのか」「裏で何が起きているのか」といった質問をすることは、あまりありませんでした。
学びの機会を逸してしまっていたのです。残念ながら、私たちは積極的ではなく、消極的でした。もしこの取り組みが戦略的に計画されていれば、若手ライターにとっては特に、素晴らしい学びの機会になったはずです。しかし、私たちは戦略的な思考を持たずに、メッセージを書いたりリライトしたりすることに躍起になっていました。
また、私たちは悪い友人関係に陥っていました。Wixでは、「友人と話すように書こう」というのが信条です。ユーザーに共感し、ユーザーのプロセスを通じて友人として付き合うことを大切に考えています。しかし、私たちはどちらかというと、ゴシップ好きで、生活が大変になると電話をとらない友人のような存在だったのです。
それは、私たちが望む友人像ではありません。私たちはもっと真剣に、自分たちが最善を尽くしていなかったことを、認めねばならなかったのです。
協力し合えば、もっと良いプロダクトを作れる。陳腐な表現ですが、これは真実です。
仕事の工程で変えたこと
エラー処理に特化した部門横断的なチームの設立。このチームは、シニアプロダクトマネージャー、フロントエンドおよびバックエンドの開発者、UXデザイナー、UXライターで構成されています。このチームのゴールは、適切なエラー処理をプロダクトのライフサイクルの一部とすることであり、後回しにすることではありません。
共同責任としてとらえる。全員が、エラーを適切に処理する責任を負っています。プロダクトマネージャーは、楽しいフローだけでなく、エラーやエッジケースに重きを置くことが期待されています。開発者は、プラットフォームに沿ったガイドラインに従ってエラーを調査し、ドキュメント化することが期待されています。データサイエンティストには、エラーに関するより良い分析を行い、イベントを適切に追跡できるようにすることが期待されています。
ローンチから1ヶ月後にエラーを見直す。特に新しいプロダクトの場合、どのようなエラーが発生するかさえもわからないことがあります。そのため、汎用的なエラーでローンチしなければならないこともありますが、現在は、ローンチから1ヵ月後に生じたエラーをレビューする手順を設けています。これにより、何が最も大きなエラーなのかがわかり、そのエラーに特化したコンテンツを書くことができるようになりました。
継続的なレビュープロセス。ライターとして、私たちはあらゆるコンテンツが常に最適化されうることを知っています。つい最近更新したばかりのエラーも含めて、つねに見直しを行っています。
UXライターは、ありきたりなエラーメッセージに立ち向かえるようになりました。万が一、プロダクトマネージャーや開発者が「この汎用的なエラーメッセージをすべての場面で使いましょう」と言ったとしても、私たちには「ノー」と言える力があるのです。CEOが汎用的なエラーは認めないと言っているのだから、問題点をもっと調査し理解しない限り、書くことはありません。その力は、私たちにあるのです。
すべてにおいて私たちは同僚と協力し合い、何千ものエラーメッセージを書き換えました。大変な作業でしたし、最後にはみんなで一杯やりました。しかし、これはユーザーにとって必要不可欠なことであり、ユーザーを第一に考えるという私たちの価値観に沿う唯一の方法だったのです。
編集：Dan Raz
図： Yansou Girard
