UX の重要性が叫ばれる昨今、正常系のフローにおける UX は入念に考慮されていると思います。その一方で、エラーが起こったときの UX についてはどうでしょう？
限られた工数の中でエラーなどの異常系をケアする事について、サーバサイドエンジニア、特に API を提供する立場から考えてみました。
エラーメッセージとは
エラーメッセージとは、予期せぬ状態が発生したときに表示されるメッセージのことです。このようなダイアログに見覚えがある人は多いと思います。
Windows のエラーダイアログの例
Mac のエラーダイアログの例
エラーの種類によっては、メッセージをダイアログではなく UI に統合して表示するほうが適切な場合もあります。
UI に統合されているエラーメッセージの例
誰のためのエラーメッセージなのか意識する
私はサーバサイドエンジニアとして API を提供する立場なので、サーバ起因のエラーが起きたときに適切な情報を伝えるために何ができるかを考えてみます。
サーバサイドの視点では、クライアント（顧客）は２者存在すると考えることができます。
ひとつは、もちろんアプリケーションを実際に利用するエンドユーザ。
もうひとつは、サーバサイドが提供する API を利用するクライアントサイドエンジニア。
同じ事象でも対象によって伝えるべきエラーメッセージは変わってきます。
たとえば、エンドユーザにデータベースのエラーコードをそのまま伝えても不親切です。逆にクライアントサイドエンジニアに「不正なリクエストです」としか伝えなかった場合、何がどう不正なのか分からず、原因を切り分けるためにより詳しい情報を知りたいと思うでしょう。
つまり、それぞれの立場にたって「何の情報を伝えるのが親切なのか？」と再考することが大事になってきます。
エンドユーザに対するメッセージ
マテリアルデザインのエラーパターンや、iOS ヒューマンインタフェースガイドラインでは、一般的なエラーの表示方法には２種類あると書かれています。
- アラートダイアログを用いて表示する方法
- UI の一部として表示する方法
アラートダイアログとスナックバーでのエラー表示 出典：マテリアルデザインガイドライン
アラートダイアログが表示されているときは、他のコンポーネントが操作不能になるため、致命的なエラーを通知するときに使用するのがベターとされています。
また、アラートダイアログに表示すべき文言のガイドラインも存在します。以下は、iOS ヒューマンインタフェースガイドラインからの部分抜粋です。
状況を簡潔に記述し、その状況でユーザが実行できることを説明する。理想的には、用意したテキストは、アラートが表示された理由を理解し、どのボタンをタップするべきか決定するために必要十分なコンテキストをユーザに与えます。
一般に、2つのボタンのアラートを設定する。ユーザは2つの選択肢から選ぶのがもっとも簡単であるため、多くの場合、2つのボタンのアラートがもっとも有用です。1つのボタンのアラートは、ほとんどの場合役に立ちません。その状況に対処するための手段を与えるものではないからです。3つ以上のボタンを含むアラートは2つのボタンのアラートよりかなり複雑なので、できるだけ避けるべきでしょう。ボタンが多すぎるとスクロールが必要になり、使い勝手が悪くなってしまいます。
もしサーバサイドで定義したエラーメッセージをエンドユーザにそのまま表示する場合は、こういったことを意識するとともに、アプリケーション全体のトーン＆マナーを揃えることも大事です。
アプリケーション全体の体験を統一するには、エラーメッセージのリソースファイルをデザイナーが編集できると良いと思います。
クライアントサイドエンジニアに対するメッセージ
アプリの開発中に複数のリクエストパラメータが存在するような API をコールしたら下記のようなレスポンスが返ってきたとします。
あなたならどう思いますか？
|
1 2 3 4 |
{ "error_code":1, "error_message":"不正なリクエストです" } |
リクエストパラメータがひとつだけだった場合ならまだしも、これだけでは対処方法が不明瞭で、どのリクエストがどのように不正なのかが分かりません。
また、細かいエラーハンドリングをクライアントサイドで行う場合もあるので、エラーコードはある程度細かい粒度で定義するほうが良いでしょう。
理想的なエラーメッセージとは
では、どのようなエラーメッセージなら良いのでしょうか？
一例として、メールアドレスとパスワードのリクエストパラメータが空のままリクエストされたときのユーザ登録 API のレスポンス（JSON形式）を挙げてみます。
message には主に開発者向けのメッセージを、 user_friendly オブジェクトはエンドユーザ向けの情報を返すようにしています。 errorsオブジェクトは、どの項目がどのようなバリデーションに引っかかったのかをそれぞれ返します。
このような形式であれば、開発者とエンドユーザーの両者にとって有益な情報となるのではないでしょうか。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
{ "result": "error", "code": 1001, "message": "バリデーションエラーが発生しました。", "user_friendly": { "title": "入力した形式に間違いがあります。", "message": "お手数ですがもう一度入力してください。" }, "errors": { "email": [ "メールアドレスは必須です。" ], "password": [ "8文字以上のパスワードを入力してください。", "パスワードに使用できない文字が含まれています。" ] } } |
サーバサイドエンジニアの責務の範囲を少し超えて、アプリケーションの UI まで考慮した API 設計までたどり着けるかどうかが、クライアントサイドエンジニアにとっての開発 UX 向上にも繋がります。
まとめ
正常系でない部分の実装は、どうしても優先度も低くなり後回しにしがちです。
しかし、異常な事が起こったときに親切なメッセージを出してあげられるかどうかは、ユーザのストレスをいかに軽減するかという部分に直結し、サポート対応のコストにも大きく響く部分です。
誰にとっても分かりやすいエラーメッセージを心がけたいですね。
