次のお題はこちらです

WEBデザインとWEBディレクションの話

30分でやる短時間ユーザーテスト

去年くらいからデザイン思考を学びはじめて、(書籍を参考にしながら)部署内で2回ほどスプリントをやった。

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法

SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法

思考の仕方や視点はとても参考になる... が、ちゃんとやろうと思うと丸々1週間予定を空ける必要があるので、他の仕事も抱えている身としては若干重たい。 プロジェクトメンバーも2人(エンジニア1名、デザイナー1名)しかいなかったので、もう少し短時間でできる手法を探してみよう、となった。

RITEメソッドを見つける

書籍やネットを漁ったところ、RITEメソッド (Rapid Iterative Testing and Evaluation: RITE)を応用したユーザーテストを見つけた。

RITEメソッドとは

  • 問題発見の精度よりも問題解決を優先する方法
  • 小さいテストを繰り返し、問題が見つかるたびにそれを修正する
  • 1990年代からある古典的な手法だが、応用を入れながら現在も使われている

方法

  1. 1人に声を掛け、ユーザーテストする
  2. 終わったら結果を整理→UI修正
  3. 次の人に声を掛け、2.の内容でユーザーテストする
  4. 終わったら結果を整理→UI修正

…のように、1人のテストが終わった段階でプロトタイプを修正してしまい、修正したものを使って次の人にユーザーテストする。

メリットとデメリット

メリット

  • 数人分のデータが集まるまで待たなくて良い
  • テストが終了した段階でおおよその問題の発見と解決が完了している

デメリット

  • 1人の行動で判断するので、UIの問題なのかその人固有の問題なのかの判断が難易度高い(設計が右往左往するリスクがある)
  • 修正のスピードが求められるため、「高速」だが「軽量」な訳ではない

RITEメソッドの応用事例

厳密なRITEメソッドは高速だけど軽量ではないため、各々応用して使っているところが多い。 調べた範囲では、下記のような応用例を見つけた。

グリー - 10分ユーザーテスト

  • ひとりあたり10分のユーザーテストを3名行なう(10分×3人=30分)
    • 思考は口に出しながら進めてもらう
    • その時に深堀りの質問もする
  • テストが終わった直後、その場で課題まとめ・改善策共有(できればTODOまで落としこむ)
  • 注意すること
    • 事前に観察者にインプットする(情報共有)
    • 被験者に勝手に話しかけない

GoogleAndroid部門

  • 「5人のテストと5回の修正」を1セット(1日でやる)
  • 「3人のテストと1回の修正」を2セット(2日間に分ける)

のパターンを使い分けてユーザーテストを行っている

コーヒーショップ・テスト

  • コーヒー1杯おごるのを条件にテストに協力してもらう
  • 場所はコーヒーショップ
  • 付箋でつくったペーパープロトタイプを5分前後で試してもらい、1人終わったらその場で修正
  • 15~20人繰り返し、テスト終了時にはUI修正が完了する

yagish風ユーザーテスト

元の手法や応用事例を参考にしながら、先日リリースしたサービスの開発期間で試してみた。

rirekisho.yagish.jp

ちょっとずつ軌道修正して、最終的には下記のフローに落ち着いた。 社内のメンバーに声をかけて、計10人ほど実施。

  1. ひとりあたり30分のユーザーテストを3~5人/日行う(操作15分/質問・感想15分くらいの配分)
  2. その日の分のユーザーテストが終わったらチームで結果を整理
  3. 結果から課題を抽出して修正箇所を決め、次のテスト実施日までに対応する
  4. 数日掛けて実施し、課題として上がったUI修正を完了した状態でFix

メモ:

  • 実施人数は計10名くらい
    • 意見が割れたときの判断材料を増やすために、一日のテスト人数は奇数(3か5)
    • 他の業務の合間を縫うなら3人/日くらいがちょうどよかった
  • 操作中は考えたこと・思ったことを随時口にしてもらうように頼む
    • 原則、こちらからは口出しや誘導をしない
    • 迷っていたり同じ行動を繰り返しているのに黙っている場合は、声を掛けて何をしているか(考えているか)を教えてもらう
  • 記録は簡易に取って、誰でも見返せる場所に置いておく
    • 気になったところ(行動・発言)をメモ
    • アクション別に項目分け(デザインスプリントを参考に。出し方は箇条書き程度で十分)
    • 解決すべき課題と修正内容をチェックリストにして書き出す
  • 操作中の動画を撮っておく
    • チーム内で意見が割れたときの見直し用に、操作中の動画を撮っておく
    • ここで困っていた/いやそんなことはなかった…と議論になったとき、記憶頼りにしないため

実際にやってみての感想とか

例えば、

  • 細かい説明なしで、そのサービスの目的(yagishの場合は履歴書の作成〜出力)を一人で達成できるか
  • 「次にどうしたらいいのか」が分からず、操作に迷っているところはないか
  • サービス内の文章や名称は正しく伝わっているか(そもそも読まれていない、別の解釈をされている可能性も)
  • 複雑すぎたり、期待したものと違う結果が出て困惑している画面遷移や機能はないか

は、比較的誰にでも共通することだし、社内メンバーに試してもらうだけでも一定レベルの問題解決ができる。

どんなに配慮していても、使ってもらったらその意図が伝わらなかった...みたいな現象は少なからずあるので、 30分くらいなら時間も都合してもらいやすいし、まずは周りにいる人に声をかけて試してもらうのは全然あり。

もちろん、ターゲット層にヒアリングやテストをするのは大切で、面倒くさがらずにきちんと機会を設けなければいけない。 でも、ターゲットに近い属性でないと意味がないし...そんなの集めているヒマがないし...と、何もしないよりはずっといい。

デメリットを挙げるとしたら、テストする人のスキルと経験で結果が大きく変わりそうなところ。 課題の抽出や解決法の選択を手早く適切にやらないといけないので、日頃から観察力をつけておきたい。