この記事は リクルート  プロダクトデザイン室  アドベントカレンダー 2022年 19日目です。

みなさん、こんにちは！

リクルート 新卒4年目でプロダクトマネージャーをしている牛島菜々です。
まず自己紹介ですが、入社前にアルバイトとしてUXリサーチサポート業務を担当した後、入社。丸2年ほど中古車探しのサービス『カーセンサー』にてグロースエンハンスを担当していました。
現在は『ゼクシィ』などの結婚領域の新規事業立ち上げを担当しています。その新規事業では、少し前にβ版プロダクトをリリースしました🎉

そのβ版プロダクトは既存の『ゼクシィ』『ゼクシィ 縁結び』などとは完全に別物として作った新しいサービスだったので、世に出す前に品質が問題ないかを確認する必要がありました。

そのためにユーザビリティテストを実施したのですが、そのテストがうまく機能し、現在公開したβ版プロダクトに対して初期ユーザーから良い反応をいただいている状況です。
そこで、今回Tipsになりそうな部分を紹介しようと思います。

公開前にユーザビリティテストは必要か？

そもそもサービス公開前にユーザビリティテストを実施する必要があるのか、という点ですがプロダクト公開後の検証の品質を上げるために公開前に検知できる課題は検知した方が良いと思っています。

例えば、ユーザビリティ課題の残ったプロダクトを公開してしまった場合にはそのサービスが使われない理由が「提供価値が合ってないから」「ユーザビリティ課題で躓いて使いこなせないから」のどちらなのかが分からなくなりますし、おそらく課題特定にも少し時間がかかります。

しかし、公開前にユーザビリティ課題の検証が終わっていれば、自ずと課題は絞られるので、その分課題仮説が生まれるスコープも絞られプロダクト改善のスピードが早くなります。

もちろん、公開してから爆速で課題を把握しにいく、ということをするのであれば特に公開前にこだわる必要性はないと思うのですが、プロダクト公開後初手のユーザーからの反応はチーム士気に大きく影響すると思うのでその辺りも考慮して世に出す前に一度ユーザーにあてておくのがやはり良いのかなと個人的に思っています。

ユーザビリティテスト設計のポイント

今回のユーザビリティテスト実施目的は、プロダクトをターゲット層が問題なく利用できる品質にすることでした。
それを実現するために気をつけたことは、下記2つです。

• 網羅的に課題を発見できるよう設計すること

• 課題が存在した場合には打ち手の確認まですること

まず前者「網羅的に課題を発見できるよう設計すること」を実現するためにした工夫は、被験者選定と検証ポイントの整理です。

初期利用層と一致したITリテラシーの被験者を呼集する

BtoCの新規事業サービスだと、利用初期層としてどんなサービスでも割とすぐに使いこなせるような人が多く流入してくるので、そのような人たちが問題なく使えれば良いと思います。

しかし、BtoBサービスや利用シーンが限定的なサービスの利用初期層は必ずしもそういった人という訳ではありません。

担当しているサービスはまさに初期から様々な人に利用される可能性が高かったため、Webサービス・アプリを使いこなすことを得意と感じている人から苦手と感じている人までバランスよく呼集できるようにしました。

実際、得意だと感じている人たちが全く躓かなかった箇所でも苦手だと感じている人たちに触ってもらうと手が止まりそこから進めない、ということがあったので重要です。

検証ポイントを細かく洗い出し、優先度を付けておく

ユーザーが操作できなくなるレベルで致命的なユーザビリティ課題はどのようにテストを実施しても分かりやすく発露するので良いのですが、設計側の意図通りに正しく理解しているか・その利用体験を実は不満に思っているかどうかは見えづらいです。
行動を解釈したり、詳しくヒアリングすることであぶり出す必要があります。

しかし、事前に検証ポイントを整理できていないと、つい「ふむふむ...ちゃんとタスクを進められているな」と被験者に与えたタスクを実行できたことに満足し、課題を見逃してしまう可能性が高いです。

なので、事前に可能な限り網羅的に検証ポイントをあげておく必要があると思います。
これはどんな調査をやる時にも意識はしていて、狙った獲物を捕まえるために蜘蛛の巣や漁で網をはるイメージに近いです(独特なイメージですが…笑)

ユーザビリティテストということで、今回はISOのユーザビリティ定義の観点を少し加工し

• 有効性効率性...正しく認知、理解、操作ができたか？

• 利用者の満足度...体験への満足度はどうか?(ストレスに感じてないか）

という2つの側面からプロダクトを眺め検証ポイントを洗い出していきました。

余談ですがこの整理は今更ながら、ヤコブ・ニールセンのユーザビリティ特性から整理してもよかったかな〜とも思ってるので次回機会があればそちらでやってみようと思ってます。

検証ポイントの洗い出しの際には、過去に仕様を詰める際に議論にあがった部分を思い起こしてみたり、ビジネスオーナーやデザイナーにも検証しておきたいと思う箇所についてヒアリングします。

ただ、こうして洗い出すと次に問題になるのは、検証ポイントの量です。

新規プロダクトや大規模な機能の場合だと検証したいことを洗い出していくとすごい量になることが多いと思います。しかし、テスト時間も限られる中で全てを検証しきるのは難しいので、検証ポイントに優先度をつけていきテスト当日は優先度の高い方から解消していくようにします。

検証ポイントの優先度は調査目的に立ち戻って考えると良いと思います。

今回でいうと「プロダクトをターゲット層が問題なく利用できる品質にする」だったので満足度より有効性・効率性の方に重きを置きました。
また、要件定義とデザイン作成が終わっているフェーズでの調査なので、仮説は組み上がっておりそれが問題ないのかを確認したかったので探索的な内容より検証的な内容を優先するという整理にしました。

ただしビジネスオーナー観点で緊急度の高い検証ポイントなどは特例で優先度をあげるなど、その辺りは柔軟に対応していたのであくまでベースの判断基準が調査目的から落とし込まれれば良いと思います。

プロダクトをターゲット層が問題なく利用できる品質にするにあたってもう1つ気をつけたことは「課題が存在した場合には打ち手の確認まですること」です。
具体的にはユーザビリティテスト期間中にプロトタイプを改善し被験者へあてる、を繰り返していました。

ユーザビリティテスト期間中にプロトタイプを改善

課題が見つかったが打ち手の妥当性を確認できていないという状態で持ち帰ると、チームや事業はその打ち手を実装することが良いのか判断がつかず実装する意思決定をするのは難しくなります。
なので、ユーザビリティ課題があった場合には改善案の検証もしておく必要があります。

それを実現するために、シナリオ通りに動くプロトタイプをデザインツール(Figma)で作成し、インタビュー当日は、

• 課題&ソリューションをリアルタイムで議論

• 次のインタビューまでにプロトタイプを修正

• 別被験者のユーザビリティテストで確認

という流れでプロトタイプをひたすら改善していました。

今回、特にこのプロセスで良かったなと思っているのがテスト対象を開発しているプロダクトではなくデザインツールで作成したプロトタイプにした点です。

シナリオどおりに動くプロトタイプを作成するのはデザイン工数を割りと使うので、そのデメリットはありますが修正案を装着できるスピードが爆速(ものによっては5分とか)なので今回のように即時的に改善案を確認したい場合は少し時間をかけてでもデザインツールで作成したプロトタイプを用意することをおすすめします。

最後に

(奇をてらう意味ではない)最高のUXを目指したい！と思い、色んなサービスを見てこうすればきっと使いやすい！などと考えながら要件定義をしていたものの、いざこの調査で蓋を開いてみたら一部のフローで動けなくなる被験者もいて愕然としました...！

すぐチームに持ち帰り起こっていたことを説明すると、基本的にはリリースに向けて極力追加要件を増やしたくないと思っていた開発側や事業側も、改善に前のめりに動いてくれたので、改めてユーザーの声は偉大だなと思った次第です🙏

あと私自身、純粋に届ける先の人に嫌な気持ちになってほしくないという想いもあり今回未然に防げたことは良かったと思ってます。

ではでは、最後まで読んでいただきありがとうございました👋