「ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―」を読んで学んだこと

こんにちは、ミッキーです。

MMMでは毎週、「読書会」を開催しています。全メンバーが同じ本を読んで、感想を言いあったり、議論したりすることで、様々な分野の学習や研鑽をする時間です。

今秋、読書会で読んだ書籍は、「ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―」です。

もともとメンバー内に、UXやユーザビリティに関わる本を読んでみたいという声がありました。そこで、ユーザビリティ分野の定番的な入門書として取り上げられることが多く、私自身も以前読んでとても役に立ったことから、本書を推薦しました。

   

学んだこと

週に1回、皆で理解を確かめ合いながら本書を読み進めることで、UCDの意義やプロセスを、深く理解できたように思います。

「ユーザー調査」→「調査結果の分析」→「プロトタイプの設計」→「プロトタイプの評価」→「改善プロセスをまわす」というUCDの全体像。ユーザーをよく理解し、誰に、どんな文脈で、どんな価値を提供したいのかを明らかにする。それができて始めてモノづくりをスタートできるということを、改めて学びました。

「ペルソナ」や「シナリオ」、「ユーザーテスト」について、今までも意識してきたものの、重要性を認識し直しました。「The Elements of UX」のフレームワークやKJ法、ユーザビリティ評価の手法の使い分けなど、様々なメソッドについて触れたことも大きな収穫でした。

限られた時間の中での読書でしたが、実務に即して丁寧に解説している本なので、学ぶことがたくさんありました。

   

メンバーの声

続いて、メンバーの本書を読んだ感想の一部をご紹介します。

・UCD全体について

受託形式でのプロジェクトだと、プロジェクトの発注主側の発言力が大きく「提示された仕様通りに作る」ケースがあるけど、その場合でもユーザビリティに関しては我々も真剣に考えて、主体的に取り組むことがすごく重要だと感じた。

受託でも、早めの段階からエンドユーザーにクローズドベータみたいな形で使ってもらってフィードバックをもらう、といった取り組みができるといいと思った。「その機能ほんとに必要?」って思うような機能もあったりする。

「誰が何をしたいか」を明らかにしないうちに、言われるままに作ってしまうと、「これはやっぱり必要なかった」「あれが必要だった」となってしまう。漠然とした要望に対して、こちらから本当に重要な要点を引き出す努力を、欠いてはいけないと感じた。

・ペルソナについて

機能を追加することは簡単。無数のユーザーを思い浮かべると、いろんな機能を付けたくなってくる。でも、そうすることで使いものにならないソフトウェアや製品になっているものが世の中にたくさんある。昔、開発していたソフトウェアも、要求や不満に対応するというアプローチを取り入れたところ、どんどんカオスになっていったことがある。

ペルソナを明確にしないまま改善を繰り返していくと、本来の目的からどんどんズレて、迷走することがあった。改善を繰り返すにしても、まずはブレないような目的を決めておくことはやっておいたほうがいいと感じた。

複数のペルソナを作って、優先順位をつけて、重み付け機能一覧を作るのは良さそう。ある機能が必要かどうかなどの議論は、プロジェクトメンバーそれぞれ主観が入ってしまい混乱する場合があったりするので、ペルソナベースで議論するようにしたいと思った。

・プロトタイプについて

ユーザーニーズに対する深い理解、論理性、既成概念にとらわれない発想力がプロトタイプ制作で重要だと感じた。そのため、MMMが主体的に取り組むのはもちろん、クライアント側の担当者も、レビューだけじゃなく制作に巻き込んでいくような進め方のほうが、より価値のあるプロトタイプが制作できるかもしれない。

・ユーザービリティ評価について

パフォーマンス測定よりも、思考発話法などの少人数テスト(わずか5人で大規模な テストの85%の成果が得られる)のほうが、ほとんどのプロジェクトで役に立ちそうだと感じた。

(本書の「作り手と評価者の間に十分な信頼関係を構築すべき」という箇所について)顧客やベンダーや、社内のチームメンバーとの間でも同じことが言える。十分な信頼関係があって初めて、良いものが作れると思う。

普段、開発に専念しているメンバーが多いので、頭の中をユーザー視点に切り替えるのは良いリフレッシュになったかもしれません。

   

今後に生かす

MMMは、システムインテグレーターとして、価値を生み出す、品質の高いシステムを作り上げることがミッションです。今回の読書会は様々な学びがありましたが、特に、MMMの業務にダイレクトに生かせそうだと感じたのが、ユーザービリティ評価です。

ユーザビリティ評価のメソッドを、システム開発の様々なフェーズやシチュエーションの中で適切に取り入れれば、プロトタイプの検証や、本番システムの継続的な改善に役立ちそうです。

まずは第一歩として行いたいのは、メンバー同士でのユーザーテストです。MMMが今まで作ったもの、もしくはこれから作るものに関して、プロジェクトに直接関わっていない社内メンバーに、簡易的なユーザーテストをしてもらうところから始めたいと考えています。

経験がないメンバーもあまり難しく考えずに、シンプルにクイックに、まずは負担無くできることから始めて、少しずつ経験を積んで習熟していけたらと思っています。

このエントリーをはてなブックマークに追加