130万人の足を計測したZOZOMAT - ユーザビリティテストを中心とした改善策とその裏側

f:id:ikenyal:20210217110333p:plain

はじめに

こんにちは、計測プラットフォーム部の歌代です。

普段はZOZOSUITやZOZOMATといった計測系プロダクトの「計測」に関わる部分の検証や、新規プロダクトに必要なデータ集め、また精度検証などサービス構築から、UI/UXの分析・評価など幅広く業務を行っています。

2020年2月にリリースした足計測ツール、ZOZOMATでは足のサイズをスマートフォンで測るという新しい体験をサービスとして提供開始しました。新たな体験にも関わらず、事前に工夫をすることで、使い方に関するユーザーからの問い合わせ件数を大きく抑えることに成功しました。

今回はZOZOMATリリースの際に、問い合わせ数削減につなげるために行った工夫や事前調査の内容を紹介します。

ZOZOMATとは

既に他のテックブログの記事でも紹介していますが、ZOZOMATは足のサイズを計測するために開発された足専用の計測マットです。

計測者自身のスマートフォンとZOZOMATを使って計測した情報を元に、靴の推奨サイズを提案するサービスを利用可能です。まだお試しいただけていない方、ご興味のある方は無料で配布中なのでぜひこちらをご確認ください。 zozo.jp

2021年1月末現在、ZOZOMATの計測件数は130万件以上あるのに対し、問い合わせ件数は数十件程度に留まっています。問い合わせ発生率としては極めて少なく、その中でもほとんど開発チームが関わる必要のある問い合わせがありませんでした。

ZOZOMATでは、どのようにして問い合わせ件数を抑え込むことができたのでしょうか。実施した内容は至ってシンプル、そしてやって当然な内容も多々ありますが、「事前にやっておいてよかった」と思うものがいくつもあります。ここではそれらの中からいくつかピックアップしてご紹介します。

ZOZOMAT開発時の工夫点

UI/UX改善を開発初期から行える体制を構築する

元々、私は品質管理部に在籍していました。そこでZOZOSUITの精度検証や端末疎通チェックをしていました。

ZOZOSUITを検証する際、すでに実装まで完了したUI/UXに対し、調査を実施し、その過程で「ここがわかりにくい」「ここが伝わりにくい」という情報を把握していました。社内で最も多くZOZOSUITの計測を経験したのは間違いなく私だと思います。

ZOZOSUITの精度検証の過程で気がついた点を、開発チームやUI/UXを担当するデザイナー、サービスチームにフィードバックしていたところ、現在の上司から「サービスを開発する段階からUI/UXについて意見をもらえないか」と声をかけられ、現在のチームに異動することになりました。

ZOZOSUITの計測を多く経験した人の声を、ZOZOMATのデザインや開発にいち早く反映させるために、チーム構成から変更されました。これにより、より良いUI/UXのためのアプローチをしやすい体制になりました。

ユーザビリティテストで問題点を見つける

ユーザビリティテストは、読者の中にも実施されている方もいらっしゃるでしょう。一言で表すと「サービスやアプリの使い勝手の部分を評価するテスト」です。

「サービスを使って目的を果たせているか?」「チュートリアル動画はわかりやすいか?」「エラーメッセージでユーザーの不安を払拭できるか?」などを、社内スタッフや外部被験者を使って、評価・テストを行います。

ユーザビリティテストは、突き詰めていくとユーザビリティテストを専門に行う会社ができるほど、奥深いものです。しかし、簡易的なものでも十分効果があります。ユーザビリティテストだけではありませんが、テストはやった分だけ何かしらの成果・結果が伴ってきます。その中でも、リリース前のユーザビリティテストはその効果が大きいテストです。

ユーザビリティテストの目的は「使い勝手に影響を与える大きな問題(大勢の人間がよく間違う箇所)」を見つけることです。例えば10人テストして、10人がそれぞれ違うミスをしていた場合、それは被験者個別の問題であって、サービス・アプリの問題ではない可能性が高いです。しかし、逆に10人テストして、8人が同じ場所で同じミスをしていた場合、それはサービス・アプリのその該当箇所に問題があると言えます。

開発の試作段階のものを評価したい際や事業の方向性に関わる重要な決定する際には、サービスの詳細を知らされていない社内スタッフに依頼、ユーザビリティテストを実施し、スピーディーに問題点を洗い出し、サービスチームや開発、デザイナーにフィードバックします。すべて社内で完結させることにより、早いサイクルで実施できます。

ここでのポイントは、開発が完了したものに対して、ユーザビリティテストを実施するのではなく、開発途中の段階でユーザビリティテストを実施することです。開発終盤での修正は大きな手戻りが発生するため、リソース・時間的に追い込まれ、精神的な負担も大きくなります。その負担が発生しないよう、ZOZOMATプロジェクトでは開発と並行してユーザビリティテストを実施しました。開発やサービスの方向性の変更や決断を容易に行うことができ、サービス品質の向上に大きく寄与しました。

それでは実際にZOZOMATで行ったユーザビリティテストを例に、ポイントを説明します。

ユーザビリティテスト実施時のポイント

UI/UXの工夫

実際にZOZOMATではユーザビリティテストを使った検証をいくつも実施しました。その中でも開発当初には「UI/UX」に関するユーザビリティテストを行いました。

ZOZOMATは開発当初、2種類のUI/UXデザイン案があり、どちらにするべきかサービスチームを中心に議論が行われていました。

開発担当、サービス担当、デザイン担当と議論した結果、2種のデザインはそれぞれに良さがあり、またそれぞれに弱点があるように思えました。

そこで社内と社外の両方から被験者を招き、テストの目的の詳細を説明しないまま、計測成功率を調査しました。

  • A案:6方向から足をスキャンする際、スマホ画面を計測するエリアの色に着色して、計測方向の指示を出すもの
  • B案:スキャンの際、スマートフォンの画面上に、ZOZOMATの緑色の足形を表示させ、実際のZOZOMATの緑色の足形と重ねるもの

被験者は20〜30代、40〜50代、60代以上の3グループで男女5名ずつ、合計30人を集めました。そして、A案→B案の順でテストを実施するAチームと、B案→A案の順でテストを実施するBチームに分け、両方のUI/UXを試してもらい、成功率の比較とどちらがわかりやすかったかのインタビューをしました。

結果として、B案に比べA案の方が成功率が高く、またユーザーインタビューからもA案の方がわかりやすいという意見があり、ZOZOMATはA案のUI/UXを採用することになりました。

A案はあまり難しいことを考えずに、計測する足の周りを6方向からスキャンするという直感的でわかりやすいという特徴がありました。その結果、B案をブラッシュアップしてコストをかけるのではなく、A案にリソースを集中させることができました。開発の早い段階で、より効率の良い選択肢を選べました。その結果、リソースを有効活用してサービスの作り込みをすることにより、問い合わせ発生率を大幅に低く抑えることができました。

ユーザビリティテストは、問題点を見つけるだけでなく、サービスやUI/UXの方針を客観的に評価でき、リリース後のサービスの姿を先に垣間見ることができます。そのため、入念にユーザビリティテストを実施することは、非常に重要だと言えます。

Androidの複数端末疎通チェックによる動作確認

ZOZOTOWNのアプリはiOSとAndroidの両方で提供しています。そして、ZOZOMATはそのアプリ内で利用できます。

開発の流れは、まず初めに端末モデルに機能や仕様に差の少ないiOSのアプリを中心に組み立てられ、その次に同じ仕様をAndroidにコンバートしていきます。

iOSではほとんど端末モデル間に差分がありませんが、Androidは国内外の様々なメーカーで製造されているため、機種によるスペックの違いや設定の違いなどが顕著です。そのため、アプリに対して、どのような影響・違いがあるのかを確認するテストが必要となり、それをAndroid複数端末疎通チェックと呼んで実施しています。

ZOZOTOWNでよく利用されるAndroid端末を社内検証機として一部保有していますが、世の中の全種類を網羅することは現実味がありません。不足する部分は外部の検証機関の協力も得ながら、全アクセスの95〜99%をカバーできるよう、端末検証を実施しています。

ZOZOMATのテストを実施していると、一部の機種でカメラの挙動の影響により開発の仕様とは異なるスキャン結果が返され、うまく計測できないということがリリース前に発覚しました。このテストをリリース前に実施することで、想定通りの動作をしない端末が存在することを把握し、そのようなアプリが対応しきれない機種がある場合はヘルプやお知らせなどでユーザーに周知することができます。改修コスト次第では、テストの結果を受け、リリースまでに原因調査と改修をすることも可能です。

また、Androidはモデルにより端末のスペック差が大きく、計測はできても、足の計測にかかる計算時に想定以上の時間を要する場合もあります。そのような端末についても事前にテストをして把握しておくことで、ヘルプなどにその旨を記載できるほか、サポートデスクへ事前に情報共有をし、いざ問い合わせがあった場合でも、その情報を元に適切な対処法を案内できます。

このようなテストを時間を確保して実施した結果、リリース前に問題が発生しそうな端末に関する情報を得ることができ、リリース後に大きな混乱や慌ただしい追加調査が必要となることがありませんでした。

エラーメッセージの整理

ZOZOMATの開発時に、UI/UXに次いで議論したテーマが「音声メッセージ」「エラーメッセージ」の伝え方です。

ZOZOMATの計測は、ユーザーがスマートフォンを片手で持った状態で、計測する足の周囲を6箇所、膝の高さから、スマートフォンをやや斜めに向けてスキャンしてもらいます。

上記の説明を読んでもなかなか実際の光景をイメージすることは難しいかと思います。実際の計測時に、この「姿勢とスマートフォンの角度と距離」を正確に伝えることにとても苦戦していました。

ZOZOMATの注文画面に掲載しているイメージ映像や、アプリ起動後のチュートリアル動画で、実際の計測方法を動画で伝えています。

しかし、実際にユーザーが計測する際には以下の2つの想定と異なった計測をしてしまうことが想定されました。

  • スマートフォンを横向きに持ってスキャンしてしまう
  • スマートフォンをマットに対して水平に持ってしまう

ZOZOMATのUI/UXの特徴として、ZOZOSUITの計測時でも利用していた「音声案内による正しい計測姿勢への誘導」があげられます。「スキャン位置が遠すぎる/近すぎる」のようなエラーは検出も容易で、かつ音声メッセージでの修正が可能でした。

しかし、「横持ち」や「水平持ち」はシステムによるエラー検出が難しく、また音声案内で正しい持ち方を案内しても、テストをしてみると「ユーザーは案内されている通りの正しい持ち方をしてるつもりであり、どこが間違えているのかイメージが湧かない」という理由で、音声案内がより混乱を招くという事態に陥っていました。

そこでポップアップによる「正しい計測姿勢の案内」を特定の間違いを連続で検出した際に表示する仕組みを実験してみました。チュートリアル動画で案内した内容をもう一度、ポップアップ画面で案内するという仕様にしましたが、それでも「何が間違っているのかわからない」というテスト結果でした。人間は一度思い込むとなかなかそれを修正することが難しいということを実感させられました。

ポップアップでは、正しい計測姿勢や持ち方を案内した後、最もよく発生する「横持ち」と「水平持ち」ではなく、正しいスマートフォンの持ち方や角度を改めてユーザーに静止画で提示する仕様に切り替えました。これにより、足に対してスマートフォンは「縦向き」「少し斜めにしてスキャンする」ことが、ようやくほぼすべてのユーザーに伝わるようになりました。

エラーメッセージの伝え方はとても難しいものです。すべての発生し得る行動を予測し、丁寧に説明していると、過剰な説明によってユーザーに余計な負担をかける事になります。「アプリとしての機能や使い方を適切に伝えつつも、説明は最低限にとどめておき、直感的でわかりやすいUI/UX」が理想的です。

最後に

本記事で紹介した内容は、特別なスキルや経験を必要とするものではなく、どのサービスでも導入できるものです。もちろんスキルを身につけることによって精度が向上していきますが、第一歩として導入するだけでも効果が得られます。テストは、開発やシステム構築が完成した最後の工程と思われがちですが、開発と並行してテストを実施することで、様々なメリットがあることが今回のZOZOMATでの検証を通して体験できました。

目的とスピード感を持って検証に臨めば、開発やデザインの手戻りといった余計な工数を削減でき、同じ開発期間であってもさらに効率的・効果的にサービスを磨き上げることができます。

皆様も現在開発中の案件があれば、開発と並行したユーザビリティテストを実施してみてはいかがでしょうか。

ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください!

tech.zozo.com

カテゴリー