こんにちは、UXリサーチャーの吉永です。
メディアドゥにてUXリサーチをプロジェクトを横断して行なっています。
みなさんの会社では、ユーザビリティテストの際、どのようにしてテスターのリクルーティングを行っていますか？
弊社では、外のユーザーに触ってもらう前に、社内にいるユーザー候補の方に協力してもらっています。
今回は、社内で行ったプロトタイピング〜ユーザビリティテストの一連の流れをご紹介します。
- [1日目]チーム全員で作ったペーパープロトタイプ からいいとこ取り
- [1週目]プロトタイピングとテスト設計。検証するUIパターンを整理
- [2週目前半]パイロットテスト
- [2週目後半〜3週目]社内ユーザビリティテスト
- 回帰インタビューと振り返り
- まとめ
[1日目]チーム全員で作ったペーパープロトタイプ からいいとこ取り
まずは、前回の記事で紹介したペーパープロトタイピング会のアウトプットをすべて見返し、いいとこ取りをすることに。
画面数にして20近い数のペーパープロトタイプがあったため、純粋に抜き出していくと「いいとこ」の数は約50個にものぼりました。
次に、その50個の中から本当に使えそうなものを選び、相性が良いと思われる要素同士をグルーピングしていきます。
この工程を3回ほど繰り返して、3つのパターンが作られました。（残念ながら画面は見せることが出来ません💦💦）
良質なアイデア創出にはイテレーティブであることに加えて、発散するフェーズが必要不可欠です。今回も、発散と収束を工程に加えることで、デザインの洗練を狙っています。
[1週目]プロトタイピングとテスト設計。検証するUIパターンを整理
UIパターンを作り終えたら、それぞれのパターンについてCVポイントを明確化し、そこに至るためにユーザーにとってほしいアクションを一覧化します。
その後洗い出したアクションでCVポイントに至れるよう遷移をつなげ、操作出来るプロトタイプにします。今回はFigmaを使いました。
また、今回のテストでは、CVポイントとなるボタンをタップしたら終了とし、それ以外に細かく採点するテスト設計は排除しました。
このようなゆるい設計でテストに臨んだのは、細かい項目を用意することで起こる次のようなデメリットを回避できることが理由です。
- 用意した検証項目以外の発見を見落としがちになる
- 検証項目を管理するシート作り・入力といった雑務の時間でディスカッションが遅れる
- 振り返りのディスカッションが検証項目とその周囲以外に及ばなくなる
- 用意した項目と結果を照らし合わせた後(つまり数日後)にやっと詳細のディスカッションやプロトタイプの改修に入ることになりがち
個人的には、細かく設計するユーザビリティテストは上記のような理由で短期的な生産性が低くなりがちだと考えています。
ちなみに細かい設計とはこの記事にあるシートようなイメージです。
【テンプレート】ユーザビリティテスト - デザラボ - Medium
正しく管理することで生まれる検証シートやジャーニーマップといった中間生成物によって出来るようになるのは、その場にいないメンバーへの効率的な結果の伝達です。これは中期的なメリットとなります。
しかし、1〜5人の小チームであったり意思決定者がその場にいるというシーンならば、事後の伝達よりも素早い実施と意思決定を優先すべきでしょう。
また、正しい伝達にこだわる必要もありません。課題感を共有するといった意味では、例えば撮影したテストの動画の観賞会を開く方が、中間生成物を見せるよりも効果的です。
何故なら、ほとんどのチームで中間生成物は参照されません。1、2回眺められればよい方です。
全ての中間生成物が無ければ意思決定されない職場でない限り、見られない前提のアプローチをとる方が生産的でしょう。
[2週目前半]パイロットテスト
出来上がったプロトタイプは、この時点ではまだ未完成です。
用意した端末で問題無く操作を完遂できることが確認できていませんし、単純にデザイナーが遷移の設定を間違っている可能性もあります。必要な画面をうっかり入れ忘れていることもあるでしょう。
これらを総称して可用性と呼ぶことにします。
もし、可用性が分かっていない状態でユーザビリティテストを始めるとどうなるでしょうか。個人的な経験則からすると、ほとんど100%に近い確率で、最初のテストは使い物にならないような失敗回になります。
これを防ぐのがパイロットテストです。 内容としては、メンバー同士でユーザビリティテストのロールプレイをやります。
弊社では、デザイナーとリサーチャーでインタビュアー役とテスター役を交換して1回ずつこれを実施。
いくつかの遷移のミスとバグの発見と、3つのパターンの内1つをこの時点で却下するという結果を得ることができました。
[2週目後半〜3週目]社内ユーザビリティテスト
今回は、ユーザビリティテストを社内のメンバーにテスターとして協力してもらいました。選んだのは、偏りが無いよう、庶務・別プロジェクトのデザイナー・エンジニア から1名ずつ。
社内のメンバーをテスターに選ぶことには賛否両論あるかもしれませんが、テスターを素早くアサインできるよい手段だと考えています。
弊社の事業ドメインは、マンガというtoCの比較的一般にユーザーが広がっている事業領域です。そのデザインチームの強みを活かさない手はありません。協力者を探すのに困らない程度の社員数がいることも幸いしています。
回帰インタビューと振り返り
実は今回の設計では、テスターの操作自体は10〜15分程度で終わるものでした。テストの時間は1時間としていたため、残りが40分ほどあります。
もちろん、40分ムダに過ごすわけではありません。
この40分の用途は、撮影した動画をテスターと一緒に振り返る時間。いわゆる回帰インタビューです。
この時間で、発話が上手でないテスターが操作中に考えていたことや、操作中の発話から読み取れなかったことを拾い上げていきます。
さて実は、テスト自体は1時間の設計にも関わらず、担当デザイナーとの間では1回のテストの全景は3時間としていました。
何故かというと、テストの後の2時間は、各回が終わった後に振り返りを行うからです。
振り返りで行う内容は、次の3点の洗い出しです。
- Problem - 行動から読み取れる課題点
- Value - 課題点を解消できる価値
- Solution - 価値を実装するための改修案
ただし、3の改修案は全てが採用される前提ではありません。
こうして出来た最終バージョンのデザインをもとに、現在サービスのリニューアルが進行しています。
まとめ
最後になりましたが、社内でユーザビリティテストを行う際のオススメ6工程を以下にまとめます。
- ペーパープロトからいいとこ取りしてプロトタイプ案を3つ作成
- CVポイントを明確化してプロトタイピング
- ゆるいテスト設計
- パイロットテストで遷移ミス等を事前に潰しておく
- 社内でユーザビリティテストを実施
- テスト結果を、Problem・Value・Solutionの3つの角度から振り返る
*1:UX DAYS TOKYOの記事：https://uxdaystokyo.com/articles/glossary/doublediamond/
