ユーザーテストに行ってきました。
はずかしながら、僕自身はちゃんとしたユーザーテスト、ユーザビリティテストに参加したことがなく、前日まで「モックアップを触りながら皆でディスカッションしたりするのかな?」とか想像してたのですが、全然そんなものではなくて、もっとちゃんとしていて、面白いものでした。
いつやるか ユーザーテストの頻度
こちらの会社ではアジャイル型開発(のひとつの、スクラムという方式)が採られているので、プロジェクトは「スプリント」と呼ばれる2週間くらいのスケジュール単位の連続で進んで行きます。ひとつのスプリントに1〜2回以上はユーザーテストをしていて、結構まめに実施されている印象です。
それぞれのイシューについて、解決案ができたらすぐプロトタイプにしてテスト、という流れで進んでいます。
今回は、僕が設計した部分のテストだったので、ユーザーテストの現場にも参加してきたという次第です。
誰がやるか 参加者
- 被験者:ユーザーとしてウェブサイトを触る人。実際のユーザー像に近い人から老若男女を散らして選定してる模様。
- 試験官:被験者に説明をしたりする人
- オブザーバー:プロジェクト参加者(クライアント担当者と制作サイドの両方)
どこでやるか 場所・環境
今回のテストは、プロジェクトに参加しているUX、ユーザビリティ専門の会社で実施されました。被験者と試験官がいる部屋(実験室)と別の部屋で、オブザーバーがモニタリングします。
ユーザーテストの流れ
テストしたいシナリオ部分のプロトタイプ(モックアップHTML)を用意して、それを被験者に使ってもらい、その様子からわかることを観察する、というのが大きな流れです。
被験者と試験官が試験室にいて、その様子を別室から観察します。
別室(僕らがいるほう)には、被験者が見ているプロトタイプ画面と同じものが映されます。マウスの動きやクリック、それと被験者の視線の動きも赤い点で表示されています。右下に小さく被験者の表情や様子が映され、スピーカーからは被験者(と試験官)の声が聞こえるようになっています。
被験者が「うーん、なになに?」などと操作しながら言う言葉と、マウスや視線の動きから、どこが分かりにくいか、設計意図どおりの行動をしてくれるか、などを観察するわけです。
今回の場合は、被験者は自然にオランダ語で話すわけなので、僕は言葉がわからないのが残念でしたが、なんとなくの口調のニュアンスとマウスの動き、視線の動きから、だいたいのことは分かります。「あー、そっち行っちゃうのかー」とか、「へー、なるほど!」の連続でした。
テスト中もどんどん作る
面白かったのは、その場でプロトタイプを直しながらテストをしていくということ。この日は4セッション(被験者4名)の試験をしたのですが、1つが終わるたびに、そのセッションから分かった「明らかに直したほうがいいところ」「ちょっと変えて試してみたいところ」は、すぐプロトタイプをいじって、次のセッションまでに作り替えてしまうのです。
僕もその場でデザインをわーっと修正して、コードを書く人に渡して・・・と、なんだかスポーツの試合をしているみたいでした。F1レースのピットの人みたいな感じ。面白かったけど、そういうのは久しぶりだったので、疲れた。
細かくは、試験を開催した会社からすぐにレポートが上がってくるので、来週はそれを読んで、改善策を考える。ということになります。
テスト結果で印象に残ったこと
- コピーワークが結構大事。
今回は、文章より図やグラフによる把握を重視したUIにしましたが、それだからこそ、少量でフォローするテキストは一瞥しても混同しない言い回しや単語選定に気を配らないといけない。 - 画面の動きは文脈、流れをつくる
図とあわせて、画面の展開(閉じるとか開くとかの動き)で次にすべき行動を示唆しようとしました。「動き」は年配の方だと混乱させるかも?という不安もあったけど、正しく使えば静的なレイアウトよりもユーザーを誘導しやすい。
などなど。いろいろ勉強になりました。
(いまやっているデザインには、 僕が外国人で言葉に弱いというのが反映されていたんだと、これを書いていて気づいた。)
ユーザーテストの意義
現地でへーへー思ったあとに、家に帰ってから改めて思ったのは、
テストで引っ掛かりのあった箇所の半分くらいはうっすら懸念のあった所だということ。「ここちょっとイマイチかもだけど、ひとまず」とそのままにしていた部分とか。プロトを作るのにも時間が限られているので、全部は完璧にできません。じっくりと時間をかけて考え抜けば、おそらくテストの前に解決できていた部分も多いともいえます。
でも、もしかしたらそれこそが「ユーザーテスト」や「アジャイル型開発」のひとつのポイント、長所というか狙いなのかもしれない、と思いました。
つまり、
- じっくり時間をかけすぎないで、さっさと実験する。時間を区切る。
- 懸念箇所もテストで被験者が指摘してくれれば、話しが早い。
- クライアントも参加する場で、明快な事実として共有できる。
「ちゃんと全部考え抜いて、こういうデザインになってるんですよー」とクライアントに説明しても、あまり納得感が得られないこともあると思います。また、設計者も専門家であるとはいえ、すべて正解を出しているとも限らないし、やはり時間もかかる。
それを実験で一緒に見てしまえば、ひとつの事実として明確な結果が得られるので、良い部分も悪い部分も決断をしやすい。
そういう意味で、ユーザーテストは、スピードをあげて開発を進めるひとつの有効なステップであると思いました。プロトタイプをどんどんつくるのは、多少大変だけど、それ以上の効果はあるのではないかと思います。