Life is bitter

日常生活で考えたことやデザイン・写真・インテリアをはじめとした役に立ちそうな知識をまとめて記しています。

エラー設計時に気をつけたい当たり前なポイント

f:id:life-is-bitter:20180820012131j:plain

サービスを作っていて必ずぶち当たるエラー設計。
デザイナーがエラーに関して全て洗い出せてそれぞれに対してUIを作り、エンジニアへばっちり共有できたらいいな〜と思ってエラー設計時に気をつけておきたいポイントをまとめてみました。

が、書き出してみると当たり前なことしかなくて笑ってしまったのですが実際に設計していると抜け漏れてしまうものもあるのでチェックリスト的な用途で見ていただければ。

1. まずどんなエラーが起こりうるか全て洗い出す

  • バリデーションエラー
  • ネットワークエラー
  • タイムアウト
  • 予期せぬ入力値
  • リクエストエラー
  • レスポンスエラー
  • ログインセッション切れ
  • サーバーエラー
  • 404, 403, 500
  • 機能依存のコーナーケース(エッジケース)

機能依存のコーナーケースに起因するエラーを洗い出すのが一般化できないので一番難しく、また数も多いです。
ここだけはエンジニアと一緒に考えるのが良いかと。というかAPIの仕様とかをデザイナーも把握できてるといいよな〜とよく思います。

2. ユーザーが対処可能なエラーには解決策を提示する

エラーがあること自体を示してもその解決策をユーザーに提示しなければ意味がありません。
エラーメッセージ(エリア)内で次に起こせばよいアクションの導線リンクやCTAボタンを置きましょう。
ワンクリック・ワンタップでエラー解決できればかなり良いですが、せめてリンクで遷移したらすぐにエラー解消できる画面まで飛ばしましょう。
ひどいものだと遷移した先でまた遷移させたりモーダルを表示させなければならなかったりするのでそれはやめましょう。

3. ユーザーがわかる言葉を使う

データベースにあるエラーコードをそのまま表示してもユーザーには不親切ですしわかりません。
開発者とユーザー双方にとってわかりやすいユビキタス言語を定めて、それに従ってエラーメッセージを考えましょう。開発者にしかわからない用語を使って設計されているエラーメッセージ割と存在していますよね…。

4. 適切な場所と形式で表示する

プラットフォームにもよりますがエラーメッセージをダイアログなのかインラインなのかUIとして組み込むのか、適切な形式で表示する必要があります。
またトップページに表示するのか階層の深い詳細ページに表示するのか、その機能とエラーの種類を踏まえて適切なページに表示しなければいけません。

最後に

エラー設計で一番難しい部分は機能に依存したコーナーケースに起因するものだなと思っていて、これはもうどんなサービス・機能を作っているかや仕様によるとしか言えないので抜け漏れなく設計するにはどうしたらいいのか…。ぐぬぬ。