11/16(土)に開催された仮説検証型UXデザインのワークショップに参加してきました。
産業技術大学院大学の履修証明プログラム
「人間中心デザイン」の講師でもある、ギルドワークス社のちゃちゃきさん(@chachaki)に行っていただいたクローズドイベントでした。
ワークショップを中心に約6時間みっちりUXデザインに触れることができ、学びの多い時間となりました。
当日の参加者によるツイートがtogetterにまとまっているので、併せてこちらもご覧いただければと思います。
ワークショップで利用したフレームワーク
今回のワークショップでは以下のフレームワークを利用し、UXデザインの仮説検証プロセスを体験しました。
- ジャベリンボード
- ストーリーマッピング
ジャベリンボードとは
ジャベリンボードは仮説管理のためのフレームワークです。さまざまな仮説をどのように組み合わせて検証したかを記録するために利用します。
詳細については以下の記事などをご参照いただければと思います。
余談ですが、ジャベリンボードという名前は「Javelin社の考案したExperiment Board」から来ているそうです。
抜けてしまったExperimentは一番重要な単語だったのでは…笑
今回のワークショップでは、既存のジャベリンボードの一番左に「目的・ビジョン」の項目が追加されたものを利用しました。
この項目があることによって、仮説と検証方法がビジョンや目的に沿って考えられているかをすぐに振り返ることができました。
実際にワークを行ってみて
やることとしては、いくつかの仮説を立て、検証する単位でこの表を順に埋めるだけのシンプルなものでしたが、実際にワークを行ってみると以下の3点が特に難しかったです。
- 顧客と課題をごちゃまぜにしてはいけない
- ユーザインタビューで誘導型の質問をしてはいけない
- 次の検証を行うときに2つ以上の項目を変更してはいけない
顧客と課題をごちゃまぜにしてはいけない
私の参加したチームは、「大人の読書」というテーマに対して忙しい社会人、向上心があるなどの顧客を最初に設定したのですが、「忙しい」は顧客の特徴ではなく課題に書くべき内容でした。
この切り分けは本当に言うは易く行うは難しだと感じました。実際の現場でもこのような仮説を立ててしまうことは多いそうです。
このような状態になると、いわゆる「何か言っているようで何も言っていない」状態に陥ってしまうので、「忙しい」という課題の背景を深堀りする必要があると感じました。
ユーザインタビューで誘導型の質問をしてはいけない
仮説を立ててから参加者同士でユーザインタビューによる検証を行ったのですが、検証したい内容に対する答えを得ることを意識しすぎて、クローズド・クエスチョンや仮説が真であることを前提とした質問を数多く作ってしまいました。
ユーザインタビューでは自分たちの知らないニーズを知る機会にもなるので、基本的には抽象度の高いオープン・クエスチョンを心がけることが重要だと感じました。
抽象度が高いというのは「コンテキストが限定されず、インタビュイーがより自由に回答できる」のような意味として書いています。
ユーザインタビューの目的や方法についてはこちらの記事が個人的に分かりやすかったです。
また最近ではユーザインタビューに関する書籍も出ていると教えていただいたので、ちゃんと読みたいと思います(ああ、積読がどんどん増えていく笑)。
次の検証を行うときに2つ以上の項目を変更してはいけない
1つの仮説検証が終わって次に進むときに、1つの項目だけを変更して次の仮説を立てることが難しかったです。
1つの項目だけ変更すると仮説が立てられなくなる場合は、各項目の切り分けが十分にできていない状態の可能性が高いとのことでした。これは先ほどの「顧客と課題をごちゃまぜにしてはいけない」とも関連しており、要素を分解することの難しさを痛感しました。
ストーリーマッピングとは
ストーリーマッピングは仮説を物語形式に整理することによってサービスの利用体験の整合性を検証するためのフレームワークです。
詳細については以下の記事などをご参照いただければと思います。
サービスの利用体験が検証対象のように書きましたが、それ以外にも利用できる場面は多く、例えば、新海誠監督は『君の名は。』の脚本を執筆するときに実際にストーリーマッピングを利用していました。
『君の名は。』脚本執筆時の資料が出てきました（ややネタバレ注意、本編最終とも異なります）。時間軸の中での観客の感情・テンションの変化をなんとか捉えられないかと考えていました。懐かしいなあ。 pic.twitter.com/Mi5RkAJQEJ
— 新海誠 (@shinkaimakoto) April 24, 2017
実際にワークを行ってみて
今回のワークショップでは、先ほどのジャベリンボードを利用して作成したサービス(仮説)に対してストーリーマッピングを行いました。
物語形式に整理したときに違和感があれば、ユーザがサービスと出会う前からサービスを利用した後までの一連の流れがきちんと設計できていないことになります。
仮説を立てるだけでは点と点がほとんどつながっていない
実際にマッピングしてみると、そもそものストーリー展開が強引な箇所を数多く発見できました。
これを検証するためのフレームワークなので当たり前と言えば当たり前なのですが、仮説を立てているときは「いい感じじゃん、いけるいける」みたいな雰囲気になっていたにもかかわらず、実際は特に「ユーザがサービスを利用する動機」の設計は全くと言っていいほどできていなかったことに自分でも驚きでした。
既存サービスの新機能追加の検証にも活用できそう
今回のワークでは新規サービスが題材でしたが、既存サービスに新機能を追加する場面でもストーリーマッピングは活用できそうだと感じました。
新機能の追加は元々あるストーリーをリライトするような行為だと思うので、個人的には新機能の検証からライトに利用して慣れていきたいです。
所感
『UXデザインの教科書』を読んだり(全部は読み終わっていませんが…)、UXデザイン系のイベントに何度か参加したりして、UXデザインで具体的にどのようなことをやるかは何となく理解したつもりでいましたが、「知っている」と「できる」の間には大きな隔たりがあることを改めて実感しました。
エンジニアという立場で業務内でUXデザインにガッツリ携わる機会はなかなか作りにくいというのが正直なところですが、例えどれだけ知識を持っていても実践しない限り身に付かないことを今回のワークショップを通じて痛感したので、小さなことから少しずつ業務の中で取り入れていきたいと思います。
