2012年年末。「ユーザー中心デザインの導入vs納期 -仁義なき戦い-」という記事をかいた。
タイトル通り、当時はユーザー中心デザインをとりいれたいと思ったら納期との戦いになっておりどうすんべーという状態。そんな折に2005年発行の「ユーザビリティエンジニアリング」初版を読み、現実的な落とし所を探り始めるようになったのだ。
そして2014年2月末。本書の第二版ユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―、が発売されたので、入手してすぐに読み倒した。
今、まさに。ユーザーテストを組織内でひろげていくにあたり、大きな課題を抱えていたので、何かヒントがあればなあと思っていたのだ。
組織内でユーザーテストを広めていくことの課題
チーム内でのユーザーテストの質向上
現在の問題。それはメンバーをまきこんでいったときのユーザーテストの質の向上である。
組織内でユーザー中心デザインを根付かせるべく、自分の案件で簡易的なユーザーテストを繰り返していったところ。プロトタイピングでのテスト、簡易ラボを設営したうえでの思考発話法テスト、アイトラッキング機材を利用した回顧法のテスト等、年々自由にテストをやらせてもらえる環境ができてきた。
嬉しいことに成果もでてきて、よりメンバーの参加を促していく方向になってきたものの。よりユーザーのことを知るためのノウハウを共有していくのが難しいなとも痛感している。
たとえばユーザーテストにおけるインタビュー。
「何を質問したり、何を見ていいのかがわからなくて…」というメンバーの声がちらほらきこえてきた。
ディレクターとしての経験が豊富な人や、ビジネス担当の人がインタビューの現場では質問に窮するのを見て、「あれ、なにかおかしいぞ」と思った。
ユーザーテストの場において、webディレクター(UI UX設計をする人)の仕事は、ユーザーの行動やインタビューから個別のユーザー体験を集め、分析し、ユーザー本人が気づかない暗黙の要求を抽出することだ。しかし、何をみていいか、何を見て質問していいのかわからなければ、個別のユーザー体験を集めることはできない。分析以降は推してしるべし。
ただメンバーが参加するだけでは、この仕事を十分に果たすことができないのではないか。危機感を感じた。
どうすればインタビューにて、よい観察・よい質問を考えられるのか？
私の所属する会社は旅行会社で、web制作会社ではない。デザインに関わる人の総数が決して多くはなく、教育制度も特別なものはない。
私自身、ユーザーテストに関わるきっかけは、ある日突然サービス開発中に「ユーザーテストって必要じゃね、お前やれ！」と上司からいわれたからだ。それからテスト実施の知識を仕入れるために関係する書籍を読んだり、勉強会やワークショップに参加したり。サービス開発案件のたびにテストを実践し、足りないものはまたインプットして、テストをまわしてきた。
私は失敗こそすれど、そういえばあまり質問に窮したこともなかった。
ユーザーテストでの質問に窮さない要因としては、開発するサービスへの仮説があったことにつきる。
- 同じサービス内で販促案件やカスタマーサポート案件のwebディレクターの経験もしていたので、サプライチェーンやカスタマーサポートの担当者とよく話す機会を得ていた。
- 自分がサービス開発のUI設計を担当してきており、過去のUIの設計意図を読み解いたうえで改修していくことが必要だった
- テストを実施するために、仮説をどうもつべきか、どうテストし分析すべきかという本を読みまくっていた
サービス運営の中で、「ここっていけてないなあ」という仮説をもつ頻度が高い仕事をしており、しかも他部署の人からもそうした仮説をきける立場にあったんだと思う。あと、分析は趣味なので、テストについての本を大量に読むのも趣味の一環だった。
つまり、5年程度同じサービスに関わってきたからという超特殊・幸運な状況＋趣味が、私の仮説立ての基礎となっている。成長していく組織の中で、自分と同様の経験を他のメンバーに求めるのは現実的でないと思う。
ユーザーテストについて、ヒントがたくさんの樽本氏の本
しかし、何かを見て感触を得て、質問をどんどん繰り出すメンバーが一人いた。
私より在籍年数が短く販促案件に関わっていないメンバー。ユーザーテストを見る際も仮説をもっており、個別のユーザー体験を抽出しようと的確な質問をしていた。
「あなたはなんで何をみるか想定できてるの？なんで質問できるの？」ときいてみたところ。
「樽本氏の『ユーザビリティエンジニアリング』を読んでいて、何をすべきかわかっていたからというのも一因」という答えがかえってきた。
私も自分で勉強する中で、樽本氏の本は特に影響をうけている。ユーザーテストのたびに困ったことがあれば開き、どうテストに挑めばいいのかの具体的な解や落とし所を得ている。テスト設計に際しては、ユーザビリティエンジニアリングの該当部分をコピーし、テスト設計をする皆に「これ絶対役立つから！！」といって配って回って布教活動に努めていた。
教科書というかもはや聖書。
ユーザビリティエンジニアリング第2版
具体的なテスト実施手法がもりもり
第二版も初版の内容が引き継がれ、さらに具体事例やリーンキャンバスでの発想など、仮説だてに役立つ知識がたくさんのっている。
【インタビューの設計ステップ】
- 聞きたいことを挙げる
- 質問をまとめる
- 聞き方を工夫する
- 順番を工夫する
- インタビューガイドを作る
- そのとおりやらない（会話のきっかけとして用い、あくまで内容や順序を変えながら臨機応変に）
【場所、機材、人員】
ちょっと変わったパターンとして、非常に専門的な内容のインタビューの場合、その分野の専門家を同伴することがあります
そうなのそうなの。旅行のECの場合は比較的「専門的なインタビュー」になりがちだ。
例をあげると。
- 海外航空券の知識（『経由』と『乗継』は何が違うか、オープンジョーとは何か、共同運行便とは何か、直行便や経由便のメリット、フルサービスキャリアとローコストキャリア(LCC)の運賃体系の違い等）
- 各航空会社のフライトの運行状況
- 季節の需要や繁閑によって生じる市場や価格の変動（シーズナリティという）
- 手配旅行契約と募集型企画旅行契約の違い
などなど、知ってないとユーザーと会話にならず、ユーザーインタビューすらできないこともある。
仮にテストへ参加するメンバーが初参加だったり、具体的知識が少ないとわかっているなら。知識がある人を同伴させる等のケアをしする、テストする商品知識のうち重要なものは前もってシェアしておく、観察ポイントを事前にメンバー全員で洗い出して共有しておくなど、体制を考える必要があると思う。
このように、テストを検討する際有用な情報が、本書には随所にある。
私のチームの課題だった、テスト最中の質問の見つけ方についてもコツが記載されている。
・「？」を見逃さない
「あれっ？」「えっ？」「ん？」といった”疑問符”をユーザーが発した瞬間を見逃してはいけません。このタイミングで「どうしました・・・」とやんわり介入すると、ユーザーは「？」について話し始めます。・質問されたら質問する
「これ（ボタン）押せるんですか？」と聞かれれば「どう思います？」と聞き返すのです。・オウム返しする
「字が小さいなー」とユーザーが不満気味に発話すれば、インタビュアーは肯定も否定もせず単に「字が小さいんですね」と軽く応答します。
など。具体的だから、すぐにテストで活かせて素敵。
ユーザーテストについての本質的な理解ができる
また、本書では具体的なアクションのほか、本質的な箇所の解説も繰り返し随所でされている。たとえば「ユーザーの声きくべからず」という言葉。
個別のユーザー体験はまだ分析されてない生のデータなので、それを設計者の手で慎重に分析すれば、ユーザー本人さえ気づいていない”暗黙”の要求まで探索することができます。
これってユーザーテストの真髄だと思う。体験を集めて、分析して、『ユーザー自身が気づいていないような暗黙の要求』（もちろんサービスに関わるメンバーも気づいてない）を見つけ出す。
UIUX改善やサービス開発にあたり、こここそがwebディレクター(UIUX設計者)の腕の見せ所だと思ってる。
ユーザーの声をきいたり、ユーザーの分析をきくのが私たちの仕事ではない。
インタビューが終わってリラックスした時に、ユーザーがぽつりと”本音”を漏らすことがあります。「こんなんで役に立つの？」
（中略）
このユーザーの本音には理由があります。それは今回のインタビューは彼／彼女がこれまでに体験した「アンケートやグルインとは全く異なっていた」ということです。確かに彼／彼女は普段の出来事をダラダラと話しただけで、気のきいたコメントひとつ言っていません。でも、「ダラダラ」とは「断片でなくストーリー」で話したということです。そして「気の利いたコメントをしていない」とは「分析をしていない」ということです。つまり、これは正しく弟子入りできたことを意味しています。
このスタンス、最初はとてもわかりづらいし、はじめてテストに参加する人はどうしたってユーザーの声をきこうとして質問をしてしまう。本書を何回でも読んで頭と体にたたきこんで参加すれば、何をきくべきかという質問の質、ひいてはテストの質はずいぶんあがるんじゃないかと思うのだ。
<!–ここから下は布教活動 –>
ユーザーテストの本質と、実践で使える具体論、ぜーんぶのってお値段なんと2,500円！しかも数時間で読めちゃう読みやすさ！これものすごいです！（ジャパネットたか○風）
冗談はさておき。
お高い専門業者にテストを依頼して毎回ウン十万円かけるのもいいけど、webディレクターが本書を読んで何度も小規模なテストを繰り返していくほうが、事業会社としてはサービスの発展につながると思う。
会社で回し読みしたいなあ。もう一冊買って会社の経費で落として会社に回し読み用に確保しておこうと画策中。
Leave a Reply