2010年度、第２期修了生の渡辺洋人です。
「産技大人間中心デザインOB/OG Advent Calendar 2018」に向けてユーザーテストについての自分なりの考えを書いてみました。

●演習直後の率直な感想

先日、講師の古田さん会ったときに「渡辺さん、準備何割、実査何割って言ってましたっけ？」と聞かれました。

2010年度のユーザビリティ評価方法論の演習で自分たちで計画から実査、報告まで終わったときの率直な感想はユーザビリティ評価の力のかけ具合は「段取り８割、本番２割」でした。
一緒にやったメンバーに久しぶりに会ったときにも「段取り８割って言葉は今でも印象に残っているんですよね」といわれたこともあり、なぜか覚えられているようです。

演習の前にもユーザビリティ評価は会社の専門家にお願いしてときどき実施し、見学したりレポートを受けていたいたので流れは知っていました。いざ産技大の演習で自分たちでやってみると、

* なにを評価するの？
* 評価の目的は？
* タスクはどう書いたらうまくいくんだろう？
* どんなデータを記録で残そう？
* 進行スクリプトは？、観察シートは？
* 当日の進行と役割分担は？
* 評価する機器の使い方を覚えておかなきゃ
* 機材の準備は万全？
* トラブルがあったときはどうする？

など、考えること、準備することがいっぱいで、チームメンバーとのやり取りもかなり多くて実査当日まで精一杯。

なんとか実査は無事終わったものの報告用のレポートがまた大変。事前に準備していないと対応できないこと、取れないデータ、被験者に聞き忘れたことがあり、「ユーザビリティ評価は段取り、準備の段階でほぼ決まってしまうな」という率直な感想がこの言葉になりました。

そのときのレポートを見返したら、ちゃんと書いてありました。

●ユーザビリティ評価→ユーザーテスト

ちょっとここで言葉について補足です。厳密には「ユーザビリティ評価」というのが正しいと思うのですが、関係者には覚えてもらいづらく、間違えているときに言い直すとめんどくさがられます。コンテンツの印象評価だったり、ユーザーの価値観を理解するための インタビューを加えたり、ユーザビリティだけでもないことが多いのです。そこで開発者以外の誰かに体験して試してもらって結果を得る評価の場合はざっくりと「ユーザーテスト」ということにしていて、この文章では「ユーザーテスト」として話します。

説明しづらい、長いのに省略できない、つづりが覚えづらい、ユーザービリティという単語のユーザビリティの悪さをなんとかしてほしいときがありませんか？

●「人間中心デザイン」との出会い

そもそも自分が産業技術大学院大学の「人間中心デザイン」のコースと出会ったのは2009年の夏、りんかい線の大井町駅に置いてあったオレンジ色のパンフレットを見つけて「これだ！」と思いました。
iPhoneが出てきてUXという言葉を目にすることが増え、それまで経験則でUI設計をしていたので、系統的に学んで説明能力を身に着けたいけれど、今ほど参考書もなく、もやもやしていたころでした。

安藤さんに直接内容を聞きに行ったり、上司に説明したりしたものの、仕事の状況で第１期は受講を断念。受講生が４人と聞いて次回はあるのだろうかと不安だったところ、次の年も無事開講され受講することができました。そしてこの領域にずぶずぶとはまっていくことに…

ちなみこれが貴重な第１期のパンフレットの表紙です。

●まずはいろいろアプローチ

「人間中心デザイン」を受講するのとたまたま同じタイミングで、業務がカーナビのUI設計から、UIアーキテクトに任命されたのは今思えば幸運でした。タブレットという商品の中に入るたくさんのアプリのUIがばらばらになって使い勝手が悪くならないようにという、ソフトウェアのシステムアーキテクトと対になる役割。

前例がない役割を自分以外のUIアーキテクトで試行錯誤しながら、UIガイドラインをまとめてみたり、エキスパートレビューをしてみたり、チャンスがあれば開発中のアプリをプロトタイプとして扱いゲリラ的にユーザーテストしたり、これらを開発プロセスに定期的に入れ込もうとしたり、いろいろチャレンジして少しづつ実践経験を積むことができました。でも、そのころはプロジェクトに貢献できていたのか、正直実感がなかったのです。

●とにかく回数を重ねる

その後、ニュースアプリの開発チームに専属のUXアーキテクトとして加わりました。３週間ごとのリリースの頻度の中で、UXに影響を及ぼすユーザビリティ品質を担保することも役割の１つでした。
毎回ユーザーテストができるわけ期間はないので、エキスパートレビューは必ず実施しつつ、案件を先読みして数回に１回はユーザーテストを計画に入れて実施し、気がつけば約３年で合計98回のユーザーテストやエキスパートレビューを実施しレポートしていました。
ユーザーテストは途中から優秀なユーザビリティ専門家と一緒に組ませてもらえたので、自分でモデレータをやらなくなったのは物足りなかったですが、短期間で計画から準備、実査までする力はついた気がします。
それでも、分析はやってみないとわからない発見も多いので毎回頭を悩ましていました。

●ユーザーテストも１つのサービス

これだけたくさんの評価をやっていく上で気がついたのはユーザーテストも１つのサービスと捉えられる、ということでした。

* 評価で得られたデータ、見つかった課題のリスト、分析結果をまとめたレポートなど、得られた成果物を利用する人がいる
* 開発者がテストを見学してもらうことは、ユーザーを知る機会を提供している
* 評価結果が信頼できるよう、被験者ができるだけ本来に近い行動をとってもらえるように実査を進める

など。特にレポートを求めているのは誰なのか、それを使ってなにかを判断して次のアクションにつなげてもらうのかを意識して、計画の説明から分析結果の報告まで開発メンバーに納得感を得られるように工夫をするようになりました。

それを続けていくと、開発メンバーにも信頼されるようになってきて早めに相談を受けることで、結果として大きなユーザビリティの課題は評価する前、リリースする前に改善できるようになりました。その分、どんな体験を提供すればよいか、その体験がビジネスに貢献できるようにする仕組みはどうすればよいか、考える時間を作れるようになっていきました。

●現時点での割合は？

そんなわけで今は、ユーザーテストを実施するときの力のかけ具合は「段取り５割、本番２割、伝達３割」のくらいの割合な気がしています。

このリリースのリズムでユーザーテストをやろうとすると、準備に十分な時間をかけられることはほとんどないこと、開発チーム内にメンバーとして加わることで普段は評価対象と背景を理解する時間を意識しなくなったことで、段取りの割合は減りました。
一方で計画を説明して納得してもらったり、実査の結果を効果的に報告したり、関係者にユーザーを理解してもらい、結果を活かしてもらえるか、ということにそれなりのエネルギーと時間を費やすため、本番より伝達に時間を費やすことになりました。

この割合はこの先また変わるかもしれません。この割合が人によって違っていてもいいと思います。それを自分で考え、説明できることが大事だと思います。この感覚を持つことで工数の見積もりもある程度できるようになってきます。

●数字の力

統計的な根拠はないとしても、嘘をつかない程度で数字にして伝えることで、人は興味を持ってくれたり、意外と記憶に残っていたりするので、数字をきっかけとして使って伝えるのはレポートを書くときの工夫の１つです。一方で力がある分、副作用には要注意です。

ということで、ユーザーテストをしても結果が活かされないと悩んでいる方の参考になれば幸いです。