ユーザビリティテストをやることになった経緯
以前、お客様の新規サービスWebアプリ作成に携わる機会がありました。開発の前に少しでも使いやすいアプリにしたいとのことで、開発着手前にユーザビリティテストを行いました。
ユーザビリティテストのやり方
役割分担
今回2名でユーザビリティテストを行いました。一人はテスト担当、一人は改善担当（私）です。
テスト担当はテストスケジュール管理やリクルーティング、シナリオ作成をメインに担当し、改善担当はテスト用プロトタイプ準備、改善修正をメインに担当しました。テストはテスト担当がメインで遂行し、スケジュールが合えば私も同席しました。そして分析は２人で進めておりました。
スケジューリング
今回はリクルーティングでうまく人を集められたこともあり、2度テストをすることができました。期間は４週間ほどかかりました。テスト・分析の週と改善の週を分けていたため、困ることが少なかったです。
1週目：テスト・分析（テスト人数5人）
2週目：改善
3週目：テスト・分析（テスト人数6人）
4週目：改善
用意したプロトタイプ
Figmaで画面を作成し、プロトタイプを準備しました。（下に掲載しました）
この画面では、カレーのトッピングを選択して注文する流れと、注文を変更する操作ができます。（あくまで仮画面なので選んだトッピングが追加後の画面に反映されているわけではないです）
どんな改善ができたか
実際の改善点を具体的に載せることはできないので、このような改善ができました、というわかりやすい一例をご紹介します。
元のボタンはシャドウをつけて前に出ている押せそうなボタンを置いていましたが、押せるボタンだと思わなかったという意見がありました。そこでチェックボックスを追加して、押すボタンとしての存在感を出しました。
Figmaのプロトタイプを掲載します。左サイドメニューのテスト1が改善前のプロトタイプ（1回目のユーザーテストで使用）テスト2が改善後のプロトタイプ（2回目のユーザテストで使用）です。
Figmaでユーザビリティテストを行うメリット
素早い改善
テストと改善までを2週間で1サイクルとして回しておりました。改善はデザインとプロトタイプの修正のみなので、今回は1週間で終わらせることが可能でした。
実装での手戻りを減らせる
Figmaで画面やプロトタイプを修正するよりも、実装を修正する方がはるかに手間と時間がかかります。「気になるポイントをユーザーに触ってもらい反応を見たいけど、実装を頼むのは申し訳ない」場合に有効です。
Figmaでユーザビリティテストを行うデメリット
プロトタイプの準備が大変
とにかく準備が大変です。想定される操作に合わせてUIパーツの状態変化を準備しなくてはいけないです。微細なUIが変更でもその次のテストに向けて複数パターンを準備する必要がありました。
実装通りのことが全てできるわけではない
機能によっては実装しないと本当の機能の動きを再現できないので、あくまで擬似体験として捉えながら操作性の良し悪しを見たかったのですが、ユーザーに伝わっていない場面が多々ありました。画面の完成度が上がるにつれて、より本物っぽい画面なのに操作できないという点がユーザーに混乱を生じさせてしまいました。
実際にやってみて
私もここまで短期間で改善サイクルを回せたことがなかったので、やればできるのだなと驚きました。制作側が「このぐらい分かるだろう」と思っていることを、ユーザーさんは案外気づかない物なのだなと思いました。
今回は検証範囲がかなり広くその分のプロトタイプを準備したので、少し荒い画面でテストに臨む、もしくは確認したい箇所を絞ってプロトタイプの精度を上げても良かったかもと思いました。
今回の経験はとても良かったので、今後の案件でも積極的に提案していきたいです。
私が登壇予定の勉強会です！今回の案件の話をします。
【1/25（木）大阪】クラスメソッドのデザイン・体験づくり事情大公開スペシャル
41
