エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン
  • TOP
  • キーパーソン
  • 旬ネタ
  • コラボ
  • ノウハウ
  • 女子部
  • キャリア

システムを一般公開する前に行う「ユーザーテスト」をうまく進める6つのtips【連載:五十嵐悠紀】

タグ : UI, UX, ユーザースタディ, ユーザーテスト, ワークショップ, 開発 公開

 
天才プログラマー・五十嵐 悠紀のほのぼの研究生活
先読み(5)五十嵐さん_100px.jpg

筑波大学  システム情報工学研究科  コンピュータサイエンス専攻  非数値処理アルゴリズム研究室(NPAL)
五十嵐 悠紀

2004年度下期、2005年度下期とIPA未踏ソフトに採択された、『天才プログラマー/スーパークリエータ』。筑波大学 システム情報工学研究科 コンピュータサイエンス専攻 非数値処理アルゴリズム研究室(NPAL)に在籍し、CG/UIの研究・開発に従事する。プライベートでは二児の母でもある

暑い夏がやってくると、毎年コンピュータグラフィックス分野の国際会議『SIGGRAPH』の時期だなぁと感じます。

昨年参加した『SIGGRAPH 2012』のレポはコチラ

siggraph2013

今年7月に行われた『SIGGRAPH 2013』の内容はコチラ

今年は、Studioというデモ展示で、研究者だけでなく、エンジニアやアーティストなどさまざまな人をターゲットにシステムを展示する、という経験をさせていただきました。

研究発表にしてもWebサービスを作るにしても、大勢の人に使ってもらう前にはユーザーテストが欠かせません。Webサービスもシステムも、開発者はその開発をずっとしてきているので、ユーザーテストをするころには開発している自分自身が一番プロフェッショナルになってしまっています。そのため、まだ使ったことのない人の視点で洗い出しをすることが大事です。

そこで今回は、わたしなりのユーザーテストのやり方をお伝えしてみようと思います。

ユーザーテストをする前にもテストが必要

ユーザーテストをする前に必ずやるべきなのが、プレリミナリ・ユーザーテスト(Preliminary User Study)です。簡単に言えば、ユーザーテストのための予備実験です。

これをすっ飛ばしていきなりユーザーテストに入る人も多いのですが、かなりの経験者でない限り、すっ飛ばすことはお勧めしません。というのも、一般に、ユーザーテストをやり直しをすることになってしまうと、人材を集めたり、時間を割いたりとコストがかなり掛かるからです。

実験の仕方や順番を考える上で有用なのが、以下を意識することです。

【1】 どのような層をターゲットユーザーとするか? 年齢、バックグラウンド、経験値(初心者・専門家)etc.
【2】ユーザーテストをすることでどんな知見を得たいか?
【3】そのためにはどんなことをユーザにやってもらえば良いか?

ほかには、AとBというタスクがあった時に、「AをやってからBをやる」というグループと、「BをやってからAをやる」というグループに分けてタスクをやってもらいたい、などと考えることもあります。

プレリミナリ・ユーザーテストを行った知見から、ユーザーテストの設計、そしてユーザーテストでどのような知見が得られそうか、といった予測が立てられます。

ユーザーにやってもらうタスクが既存システムと自分のシステムとを比較するような場合には、「自分のシステムが優位な状況になっていないか」のチェックも必要です。

ユーザーテストをやる時に注意する点

AB-test

サービス発展の命運を握るようなデータを取得するのがユーザーテストだが、やり方によってはうまく機能しない

プレリミナリ・ユーザーテストで、問題点の洗い出しができたら、それを修正して、実際のユーザーテストに入る時には、今一度、ユーザーにやってもらうための課題の見直しをします。

ユーザーテストを行うのが初めての人には、この段階でぜひ経験者に尋ねてみることをお勧めします。その際には、

・プレリミナリ・ユーザーテストの結果
・ これから行う予定のユーザーテストの設計(ターゲットユーザー層、実際に行うタスク、スケジューリング)

などを持っていくと、より具体的なアドバイスをもらいやすいので、ユーザーテストを行いやすくなります。間違ったユーザーテストをしてしまって、時間も人手も無駄! なんてことを避けることもできるでしょう。

特に検定などをして評価を出したい場合、ユーザーテストの設計次第では、評価できないこともあるので、検定に詳しい人に事前に見てもらうことも大事です。

ここで、わたしがユーザーテストをする際に気を付けていることを挙げてみます。

【1】目的を説明する

ユーザーテストの目的を説明する際に、「評価するのは製品/サービスであってユーザではない」、「失敗するのは製品/サービスのせい(ユーザーのせいではない)」というのを伝えます。

14回目の連載でご紹介したように、「ヒトが技術を使う時、システムの操作を誤ってしまったり、使い方が覚えられなかったりすると自分自身を責めてしまいがち。しかし、『悪いのはデザインである』」からです。

嫌だったり、苦痛だと思ったら、「いつでもやめて良い」ということも伝えておきます。

【2】1人1人に対して同じことをする

説明の仕方が違ったり、やってもらう順序が違ったり。意図して異なる順番でやってもらう場合ももちろんありますが、何となくバラバラになってしまうのは避けます。

【3】実験は15分、長くても30分で終わるように設定する

だいたいどのくらいで終わるのかをあらかじめユーザーに伝えます。長時間の実験は、疲れや飽きなどといった別の要因が加わってしまうので、簡潔に、15分から長くても30分程度で終わるように設定しています。

例えば、わたしが開発してきた手芸設計支援システムだと、システムの使い方をレクチャーして10分、自分でいろいろ試行錯誤してもらって5分、最後に自分だけのオリジナルデザインのモノを作ってもらって15分。これだけであっという間に30分の時間を使ってしまうので、実験のタスク設計には十分注意を払っています。

また、自分では5分くらいで終わるな、と簡単に思っていたことも、実際に説明をして理解してもらって、やってもらう、となると15分くらい掛かったということもよくあります。

時間配分はプレリミナリ・ユーザーテストの時の結果から余裕を持って設定するようにしています。

【4】質問がないか聞いてから始める

研究室内部などでユーザーテストを行うケースではない限り、「ユーザーテストなんて初めて」という人がユーザーになることがほとんどです。ありがちなのは、「分からないことがあっても聞いてはダメ」と思い込んでいる人が多いのです。

内容を説明をした後、実際にユーザーテストを始める前に、質問がないか聞いてから始めると防げるでしょう。基本的には「事前の質問は受け付ける」が、実験中に「操作を助けることはしない」というのが多いです。

【5】ログをとる

ユーザーテストをしている状況を客観的に振り返ることが必要になることも多いため、ログをとっています。具体的には、「録音機で言葉のやり取りを録音させてもらう」、「ビデオ撮影をさせてもらう」、「マウス操作やクリックしたボタンをカウントしてログファイルとして保存しておく」などをしておきます。

これらはユーザーテストの結果をもとに、システムやサービスを修正するときにも役立ちますし、論文やドキュメントなどにまとめる際にも使えます。また、ユーザーテストの結果を専門家に見てもらって、批評していただく、なんてことにも使えます。

わたし自身、論文を投稿した際に、自分が思ってもいなかった視点から専門家に指摘され、ユーザーテストの際にマウス操作のログをとっておいたため、そのログを解析して有意義な議論を展開できた(もう一度ユーザーテストを行わずに済んだ)、という経験があります。

このように、さまざまな形のログは有意義な材料になると思います。

そして、「ユーザーテストをするためだけの開発」も、もちろんあります。ユーザーの操作を可視化したり、操作のログをとったり……、といったことをするためには追加でシステム開発が必要になりますが、ここを面倒がらずにやっておくことで、ユーザテストの結果を検証したり、まとめたりする作業が格段に楽になります。

【6】何を知りたかったのか説明する

最後にこの実験で何を知りたかったのか説明をしましょう。そして、相手からも何か質問がないか聞きます。また、アンケートや感想を聞くことも多いです。

ワークショップをテストの場にする、というケースもあり

workshop-image

ユーザーテストと言われるとかしこまってしまうような場合も、ワークショップとしてであれば和らぐ

わたしたちの分野ですと、ワークショップをユーザーテストの代わりにすることもあります。また、ユーザーテストをし終わったものを改良して、ワークショップを行うこともあります。

ユーザーテストとワークショップが異なる点は、ユーザーテストは1人1人をターゲットとすることも多いのですが、ワークショップは1人対多数で行うことが多い点です(もちろん、ユーザーテストでも1対多数のこともあるので、一概には言えませんが)。

例えば、10人が参加するワークショップにおいて、全員の前でレクチャーをするだけでは、1人1人の理解度が異なるため、全員が理解できているかどうかに気を配りながら進めなくてはいけません。

1人1人を観察して得られる知見、というよりは、ワークショップでは全体としての傾向がつかみやすいと言えます。

また、わたしが行ってきた手芸設計支援システムでのワークショップでは、1人1人設計に掛かる時間も異なりますし、実際に手作業でモノを作る時間も異なるため、1番最初に終わった人と最後に終わる人では時間に差がでることが多いです。

このように、みんなで一斉に終わらないと想定できる場合、先に終わった人は帰ってもいいとするのか、それとも先に終わった人はさらなる上級者用にトライできるのか、手芸だったらもう1つ作っても良いのか……。ワークショップ自体がだらだらとしてしまわないための、ワークショップとしての時間設定の工夫も必要になります。

最後には、アンケートを配布して、ワークショップの反省(良かった点、直したほうが良い点)を記入してもらうことで、重要な参考資料になります。

新しいWebサービスを作ろうとしている人、システムを開発している人、自分の趣味でスマートフォンアプリを作って公開している人。さまざまな人の身近にあるユーザーテスト。少しでもご参考になることがあれば幸いです。

>> 五十嵐悠紀さんの連載一覧はコチラ




人気のタグ
業界有名人 スタートアップ 開発 SE 転職 エンジニア プログラマー Web スキルアップ ソーシャル アプリ シリコンバレー キャリア プログラミング Android 起業 えふしん スマートフォン アプリ開発 SIer 技術者 UI btrax Webサービス クラウド Apple スペシャリスト CTO Twitter Brandon K. Hill ギーク 英語 村上福之 Facebook Google デザイン IoT SNS ツイキャス 世良耕太 モイめし IT 30代 採用 赤松洋介 コーディング 20代 UX 勉強会 プロジェクトマネジメント Ruby ITイベント Webエンジニア 中島聡 ビッグデータ 法林浩之 ウエアラブル iOS 五十嵐悠紀 LINE ドワンゴ ひがやすを ロボット 受託開発 モノづくり IT業界 コミュニケーション イノベーション ハードウエア MAKERS tips ゲーム 女性 ソーシャルゲーム Webアプリ SI インフラ iPhone 女性技術者 高須正和 マイクロソフト 研究者 UI/UX トヨタ 自動車 ノウハウ チームラボ 息抜き システム ソニー プラットフォーム Java メイカームーブメント オープンソース 和田卓人 エンジン グローバル 開発者 教育 イベント サイバーエージェント ソフトウェア 女子会 コミュニティ メーカー 家入一真 スーパーギーク 増井雄一郎 GitHub 人工知能 IPA 40代 日産 テスト駆動開発 ソフトウエア 音楽 TDD ニュース モバイル PHP TechLION

タグ一覧を見る