着信認証のUIデザインから考える、モーダルウィンドウの使い所とアンチパターン

こんにちは。デザイナーの田村です。

最近「ジョブ理論」という本を読み終えたのですが、お堅いビジネス書かと思っていたら、あまりにもUXデザインや人間中心設計に通ずるものを感じて驚きました。*1

とても面白かったので、興味のある方はぜひ読んでみてください。

さて今回は、クラウドワークスの一部の機能で、「着信認証」を導入したときのことを書きたいと思います。

「着信認証」のUIデザインというと、なかなか特殊なケースかと思いますので、今後同じ状況に遭遇したデザイナーにとって少しでも参考になれば幸いです。

着信認証とは？

着信認証は、Webサービス上で指定された電話番号にかけることで、本人確認を行い「なりすまし」等の不正利用を防ぐための機能です。

主に金融関係のWebサービスなど、セキュリティが重要視される場面では、よく利用されているようです。

クラウドワークスでも、違反案件対策のため、昨年から一部の機能で着信認証が導入され始めました。

着信認証のUIデザイン

UIデザインについて、まずは着信認証のAPIの仕様を把握されているエンジニアから草案をいただき、その案を起点に議論を進めていきました。

草案

最初にいただいた草案では、以下のようになっていました。

右側にある「この人に仕事の相談をする」ボタンをクリックすると、着信認証用のページに遷移し、そこで認証用の電話番号を表示するというものです。

この案でも仕様上は成り立ちそうですが、もう少し分かりやすくできるかもしれません。

改定案

そこで、以下のようなUIに変更しました。

ボタンをクリックすると、そのページ内でモーダルウィンドウが表示され、その中で着信認証のタスクが完了するようになっています。

また文言についても、社内唯一のコピーライターでもあるマネージャーにレビューを依頼し、議論しながらブラッシュアップを行いました。

効果（KPIへの影響）

着信認証を導入する際、「この人に仕事の相談をする」ボタンを経由した仕事の依頼数が極端に低下してしまうのではないか、との懸念もありました。

しかし、実際にはネガティブな影響は見られず、違反案件の閲覧数だけを減らすことができました。

下記のグラフは、運営によって違反認定され、停止されたクラウドワーカーへの相談数を表しています。

詳細な数値は掲載できませんが、比率を見ても一定の効果が確認できると思います。

モーダルウィンドウの使い所

今回、着信認証のUIデザインにモーダルウィンドウを用いましたが、その理由や注意点についてもここで触れておきたいと思います。

モーダルウィンドウとは？

モーダルウィンドウは、現在表示されている親ウィンドウに対して子ウィンドウを生成し、特定の操作を完了させるまで親ウィンドウの操作を制限するというものです。

モーダル（modal）とは、「モードを持っている」ということを意味しています。

なぜモーダルウィンドウを選んだか

モーダルウィンドウを選んだのは、着信認証が、その先の機能を利用するために、必ず必要な操作になることが理由でした。

通常、モーダルウィンドウは操作のコンテキストを遮断するものとして、慎重に扱うべきとされるコンポーネントです。

しかし、今回のように「その操作が必要であり、なおかつ完了しなければ先に進めない」という場合には、ユーザーの注意を引いて、その必要性や操作方法を伝えるために適切と考えました。

アンチパターンに注意する

一方で、先にも述べたように、モーダルウィンドウの使用には注意が必要です。

モーダルウィンドウは、開発者の観点から見れば既存の画面スペースの制約を受けない分、利便性を感じることがあるかもしれません。

そのため、「それ、とりあえずモーダルで出しちゃえばいいじゃん！」と濫用されがちになります。

しかし、コンテキストに沿わない形でモーダルウィンドウを表示することは、ユーザーにとってノイズにしかなりません。

あなたも思い出してみてください。Webサイトを閲覧している途中、関係のない広告が突然モーダルウィンドウで表示されたら、いつもどうしていますか？

ほとんどの場合、条件反射的に閉じているのではないでしょうか。（なぜかサービス運営側に回った途端、その経験を忘れてしまうことが多いようです。）

このように、コンテキストに沿わない形で、過剰にユーザーの行動を妨げるモーダルウィンドウは「Idiot Box（バカげたボックス）」というアンチパターンとして知られています。

デザイニング・ウェブインターフェース ―リッチなウェブアプリケーションを実現する原則とパターン

参考: デザイニング・ウェブインターフェース（読書会でも取り上げた一冊です）

仕様を理解する

着信認証の事例は、UIデザインとしては単純なものですが、実は想定される利用ケースは多岐にわたります。

もし電話番号が発行されてから途中で閉じたら、その電話番号は無効になるのか等、事前に懸念点を潰していかなければなりません。

こうした検証は、エンジニアと密接に連携を行うとともに、デザイナーも仕様についての理解が必要になります。

今回は担当のエンジニアの方にレクチャーしていただきましたが、可能であればデザイナーも、あらかじめAPIの資料などを分かる範囲で読んでおくと良いかもしれません。

おわりに

着信認証のUIデザインに取り組んでみて、「どうして、そのコンポーネントを使うのか？」という事を、しっかり考えて決断しなければならないと再度実感しました。

しかしながら、実はクラウドワークス内にも、間違ったモーダルウィンドウの使い方をしている箇所がいくつか残っているのです。

こうした記事を書いた手前、今後もデザイナーとして引き続き改善活動に勤しみたいと思います。

最後までお読みいただき、ありがとうございました。

*1:著者は「イノベーションのジレンマ」で有名なクレイトン・M・クリステンセン氏です