遅延そのものよりもつらかったのは、その後の体験だった ―
旅行や出張で飛行機を利用していると、天候や機材トラブルなどによる遅延は避けられない。
先日、北海道から東京へ戻るANA国内線を利用した際、出発が2時間30分以上遅延した。結果として空港には5時間以上滞在することになり、東京への到着は深夜2時頃。さらに到着後はタクシー待ちの長蛇の列ができており、200人以上が並んでいる状況だった。
もちろん、安全運航が最優先である以上、遅延そのものについては理解できる。
しかし今回印象に残ったのは、遅延ではなく、その後に待っていた補償申請体験だった。
遅延情報が反映されない案内表示
まず戸惑ったのが空港内の案内表示だった。
実際には遅延しているにもかかわらず、掲示板にはその情報が反映されていない。すでに遅れることが予定されているにも関わらず、客室乗務員の方に確認すると「表示に反映されていないだけです」と説明された。
案内によって遅延していることを知らずにゲートに入ってしまったら外には出られない。顧客にとってはとても重要な情報であるにも関わらずだ。
利用者にとって掲示板は最も信頼する情報源の一つである。そこに新しい情報が表示されていないと、「自分の認識が間違っているのか」「システムの問題なのか」を判断できなくなり不安になる。
補償制度はある。しかし手続きが分断されている
今回のケースでは、
- 一定以上の遅延による2,000円の補償
- 深夜到着に伴う交通費・宿泊費補償（上限15,000円）
が用意されていた。
補償制度そのものは利用者に配慮された内容だと感じる。しかし問題は、その申請が別々のフォームになっていることだった。
利用者から見れば「今回の一連の遅延に対する補償」であるにもかかわらず、システム上は別の手続きとして扱われている。その結果、同じ情報を何度も入力することになった。
なぜ同じ情報を何度も入力するのか
申請フォームでは、専用メールに送られてきたURLからアクセスしているにもかかわらず、メールアドレスの入力と確認入力を再度求められた。
しかも、この作業を補償ごとに繰り返す必要がある。
利用者からすると、メールアドレス登録は
「なぜすでに分かっている情報を再入力しなければならないのか」
という疑問が生まれる。仮に入力されるにしても2度の登録は不要である。
フォーム設計においては、入力項目の数そのものよりも、「意味のない入力」がストレスを生む。
勝手にメールアドレスが大文字に変換される問題
会員登録でもないのに2度のメールアドレスを要求されるもの精神的にストレスになるが、せっかく小文字で入力してもなぜか大文字変換されてしまう。いちいち、選択して小文字変換をしなくてはならない。しかも、コピペができないフォームで、メールアドレスを手で入れて、小文字変換を2度もしなければならない。
エラーの原因が分からない
さらに厄介だったのが入力エラーだった。
国内線は「カタカナでも入力可能」と解釈できる。しかし実際には、予約時にアルファベットで登録している場合、アルファベットで入力しなければエラーになる。
問題は、そのことがエラーメッセージがまとめて表示され、わかりにくいことだった。
利用者は何が間違っているのか理解できず、何度も試行錯誤することになる。
良いエラーメッセージは、エラーを伝えるためではなく、解決方法を伝えるために存在する。
エラー表示をまとめて表示させてしまう
ユーザーのミスでエラーがあった場合には、エラー内容をまとめて出してユーザーに判断させることはせず、適切な位置にで明確にエラー内容を表示させる必要がある。
入力ルールが利用者に委ねられている
航空会社選択でANAを選択した時点で、便名は「NH」で始まる。
よく見ると選択したものに(NH)となっているが、便名の接頭辞になっている認識は少ない。
メールでの情報からもユーザーは、「NH0082」で1つの情報である認識がある。しかしフォーム側が求めていたのは数字部分のみだった。
これは、システムが知っている情報を利用者に判断させている設計の問題である。
入力補助やプレースホルダー、入力例の表示があれば防げると判断したデザインだと思われるが、ユーザーは意外に細かく見ないものである。もっと明示的に「NH」に変化する仕組みにすれば、直感的なデザインの実装が可能になるだろう。
最大の壁は環境依存だった
最終的に最も時間を奪われたのは領収書のアップロードだった。スマートフォンではファイル選択が正常に動作せず、アップロードできない。ここまで入力した行為は無意味になる。
パソコンに切り替えたが、今度はChromeで正常に利用できなかった。
Safariに変更すると別のエラーが発生し、自分のPCではページそのものが表示できなくなった。
ネットワークエラーと表示されるが、他のサイトは問題なく閲覧できる。
結局、別の人のPCを借りてSafariで申請を完了することになった。ここまでで同じ手続きを4回近くやり直している。
遅延による負担を、補償申請がさらに増幅してしまう
今回、空港で待った時間は約5時間半。
帰宅した後も補償申請のために約1時間を費やした。
もし補償申請がスムーズに完了していれば、「大変だったけれど、きちんと対応してもらえた」という印象になっていたかもしれない。
しかし実際には、補償を受けるために追加の負担が発生してしまった。
UXの観点から見えた3つの課題
今回の体験を振り返ると、課題は大きく3つに整理できる。
- 同じ情報を何度も入力させる設計
- エラーの原因と解決方法が分からない設計
- 利用環境によって完了できない設計
遅延は必ずしも防げない。
しかし、遅延後の体験は設計できる。
利用者が最も疲弊しているタイミングだからこそ、補償申請の体験はできる限りシンプルであるべきだ。
サービスの評価は、順調なときではなく、トラブルが発生したときに決まる。今回の経験は、そのことを改めて考えさせられる出来事だった。
メールの案内だけでも今よりかは解決できる
今回補償の案内メールにたくさんの情報が入っていて、また、入力するべき内容が散漫になっているのでユーザーはわかりにくかった。
この方法が最善ではないが、もっとも素早く今より解決出来る方法を記載する。それは、入力しなければならない情報をメールでまとめて表示させることだ。しかも、入力する順番に掲載する。それだけで、ユーザーのストレスはぐっと下がるだろう。
もっと言えば、入力フォームでユーザーに行ってもらいたいことは領収書の提出と実際に乗ったかどうかの確認だけのはず。であれば、すでに必要事項を全部記載したものを提示して、「確認」だけさせるだけで事が足りるはずだ。
事務的な作業をなぜユーザーがしなければならないのか、それをさせることで企業にとってのメリットはあるのか？形式的なステップを踏ませることにフォーカスするのではなく、なぜこのフォームが必要なのかも検討する必要すらあるのかも知れない。
