ユーザに黄金体験していただくために・・・。

　「アジャイル」「ユーザビリティ・テスト」と、ともに知識の乏しいエリアに関する本を読んでみました。

ユーザビリティ・テストがわからない

　テストにおいて、「うーん、仕様に反しているとまではいえないけど、ちょっと・・・」というものの一部は、ユーザビリティに関わるものですよね。メッセージの出し方だったり、操作の動線だったり、何が起こるかよくわからないボタン名だったり。
　たとえばぼくは、googleカレンダーのtodoリストを愛用していますが、『完了したタスクを消去』という機能が何をしてくれるのか、よくわかりませんでした。「完了したタスクを削除する」ものなのか、「完了したタスクを非表示にする」ものなのか・・・。

　ユーザビリティが、ユーザの満足度に重大な影響をもっているとはわかっていても、そのテストは、どうにもつかみどころがない。何をテストをするのか、また何をもってOKとするのか。
　タイミングも重要ですよね。ユーザとイメージをすり合わせるためのプロトタイプを作り込めば作り込むほど、被験者かの指摘は細かく・狭いもの、つまり本質的でないものになってしまうそうです。そもそも、作り込んでからでは、変えられるのはせいぜい画面部品の配置や文言くらい、ってことにもなりかねません。

ユーザビリティ・テストを学ぶ

　樽本徹也さんの『アジャイル・ユーザビリティ』は、ソフトウェアのユーザビリティとは何か、それをどうテストするのかについて説明した本です。 

アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―

 　特に「どうやって」の方に重きをおいており、「あまり金をかけすぎずに、周りから人を集めてユーザビリティのテストをするには」ということを、ものすごく具体的に説明しています。

　紹介されるユーザビリティ・テストは、プロジェクトに閉じて行われるテストとは一線を画したもので、心理学の実験みたいなところがあります。
　開発側の人間がインタビュアーになり、開発チームの外から探してきた被験者に、ソフトウェアで実行してもらうシナリオを説明します。たとえば、通販サイトで服を見て、選んで、注文する。このシナリオを理解してもらった後で、実際にソフトウェアを使ってもらう。
　その過程で現れた、被験者の一挙手一投足を観察（録画！）し、ユーザビリティの問題を探していくという流れになります。

　このテストにおけるノウハウが、大きなものから小さなものまで説明されていて、面白い。

　大きなものとしてはたとえば、

ユーザの声聞くべからず

　これはちょっと意外な感じがしませんか？ユーザ中心デザインの4原則の1つで、どう改善すべきかを被験者に聞くべきではないそうです。
　ユーザの声をV、ユーザの体験をxとすると、V=f(x)であり、注目すべきはVではなく、x。被験者から得られるのは主観的な意見でしかないので、「詰まった」「戸惑った」という現象の方から、開発チームが客観的に改善ポイントを導く必要があるのだと。

　小さなものとしてはたとえば、

ウェブサイトでは未訪問リンクと訪問済みリンクは色が異なるので、ブラウザの履歴をクリアしておかないと、前の被験者の訪問済みリンクをたどっていくだけで、次の被験者はタスクを達成できてしまいます。

　こういった、初めてユーザビリティ・テストに取り組む場合にはなかなか気付けないようなtipsもたくさん書かれています。

　またテストそのものだけでなく、人の集め方から社内政治の問題、果てはテストの撮影機材の安価な調達方法まで、周辺の作業についてもしっかり書かれており、これからユーザビリティ・テストに取り組む人にはとても役に立つ本だと思います。
　またそこまで行かなくても、ユーザビリティを「効果」「効率」「満足度」で分類するといった、ユーザビリティ一般の考え方の基本を知っておくのにもいい本です。

　ただ1点だけ。。。
　タイトルが『アジャイル・ユーザビリティ』とありますが、どちらかといえば副題の「ユーザエクスペリエンスのためのDIYテスティング」の話がメインのようです。
　アジャイル開発とUCD(User Centered Design)の出会い・融合については、最後の第6章で語られています。ちょっとこれは「アジャイル」という言葉でズルしてませんか・・・という気持ちになりました。逆にいうと、全然アジャイルに関わっていない人でも読めます(笑)

補足と蛇足

　ちょうどこの本を読んでいるタイミングで、SQiPの『ソフトウェア品質のホンネ』に、金山豊浩さんの『ユーザエクスペリエンス(UX)の時代に向けて』というコラムが掲載されました。このコラムでも紹介されている「UX白書」やISO 9241-210も、読んでみようと思っています。

　最後に、印象に残った「スカンクワークのすゝめ」という文章を引用。

もしかすると上司に提案するかも知れません。─「今回のプロジェクトでユーザテストをやらせて欲しい！」 　多くの場合、答えは「NO」でしょう。それは上司の”頭が固い”からではありません。上司にはあなたが「今回のプロジェクトで（生まれて初めての）ユーザテストを（自信はないけれど試しに）やらせて欲しい！」と言っているように聞こえるからです。 　まずは「スカンクワーク」から始めましょう。

　・・・これって、テストに限った話じゃないよなあ・・・。自省。