ユーザーのシナリオの完成形ってどう決める？ 知見聞いてみ隊vol.3
こんにちは、コンセントのUX/UIデザイナー荻原です。
「勉強会や本で知識を得たつもりでも、いざ実践してみると『え、これってどうやるの…？』と手が止まってしまう…」
いざ実践した時にぶち当たる壁。本には書いてないし調べても出てこない正解のない問いや疑問。
この記事は、そんなお悩みにスポットを当てた社内の取り組みである「知見聞いてみ隊」のレポートです。
今回のテーマは「シナリオの完成形ってどう決める?」。アクティビティシナリオの作成を起点に、プロジェクトメンバー間での合意形成の方法が主題になりました。
「知見聞いてみ隊」とは？：
UX/UI初学者（以下、質問者さん）から実践して感じた「正解のない問いや疑問＝お悩み」を収集。質問者さんと共に経験値のある人（以下、経験者さん）へお話を聞きに行く。お悩みに対して、経験者さんなりのやり方や対処法を聞いてみるのが目的です。
取り組みの性質上、記事の内容が必ず正解ではないこと・初歩的な学びも含んでいることを念頭に読んでいただけると幸いです。
登場人物
シナリオの完成形ってどう決める?
質問者さんから経験者さんへ共有したお悩みは以下です。
🐭質問者さんのお話
業務システムをつくるプロジェクトの中で、現行業務をリサーチした上で、理想の業務フローがどのようになるか整理するためにアクティビティシナリオを作成しました。その際に疑問に思ったことを聞いてみたいです。
理想の業務フローを描く上で機能を追加していったものの、最終的には実現が難しい／今回の実現には負担が大きいなどの理由でスコープ外とすることがありました。
アクティビティシナリオを考える段階で、
■どこまで詳細に記載するべきか
■実現可否をどこまで考慮するべきか
が気になっています。
また、シナリオをプロジェクトメンバーに共有した時、反応が薄く理解してもらえているか不安に思う場面がありました。
■理解してもらえるシナリオのつくり方
についても、これってどうしたらいいんだろう…と悩んでいます。
どこまで詳細に記載するべきか
粒度はシナリオの用途に応じて変わるので、枠組みにとらわれなくてよい
まず1つ目のお悩み「どこまで詳細に記載するべきか」、記載する粒度について経験者のお2人に聞いてみました。
今回のお悩み元のシナリオは構造化シナリオ法に基づいて作成されています。構造化シナリオ法のシナリオには大きく分けて「バリューシナリオ」「アクティビティシナリオ」「インタラクションシナリオ」の3つがあり、上から下へ徐々に具体化されていく内容になっています。
バリューシナリオ
ユーザーにとっての価値を可視化するアクティビティシナリオ
ユーザーがそのサービスや製品を使うことによって体験するうれしさや、今回実現したい体験仮説を可視化するインタラクションシナリオ
体験仮説の中のさらにインタラクションレベルで実現したいことを可視化する。例えば、画面の操作の体験など
構造化シナリオ法について、詳しくは以下書籍等を参照ください。
例えばアクティビティシナリオを書く際に「インタラクションレベルにまで踏み込みすぎることを心配する」といったことは気にしなくてよいとのことでした。
🐯経験者さん1のお話
体験のうれしさを伝えるためにインタラクションにも少し踏み込む必要があると感じるなら、書いていいんじゃないかなと思います。私は個人的に細かめにシナリオを書くことが多いですが、それは一度書いてみないと自分がその体験を具体的にイメージできないからだったり…。
結局最後にたどり着きたいのは、プロジェクトメンバー全員が理解できるか／共通イメージをもてるかといったところ。そのゴールを達成していれば、粒度はあんまり気にしなくていいのかなという気がします。
アクティビティシナリオ自体はひとつのフレームワークでしかなく、どのように用いてプロジェクトメンバーとコミュニケーションしたいか、どういった用途で使うか次第で粒度も変わってくるということですね。
また、インタラクションまで踏み込んだアクティビティシナリオを作成した際の注意点もあわせて聞くことができました。アクティビティシナリオをつくるメリットは具体的な機能やUIに落とし込む前に体験レベルで認識を揃えたり、理想を定義できる点にあります。しかしアクティビティシナリオの段階で機能の話も一緒にしてしまうと、議論が機能ベースになってしまうことも。そういった際は、「今は行動のみに絞った話をしましょう」というファシリテーションが必要とのことでした。
とりあえず手を動かした先の、気づきが重要
枠に囚われる必要はない…とはいうものの、無駄に時間をかけてしまっていないか？書き過ぎてしまっていないか？と不安に思ってしまうもの。この辺りをどのようにコントロールしているのかについても聞いてみました。
🐯経験者さん1のお話
これは私の性格上かもしれませんが、「無駄かもしれないけど、やってみないと無駄かどうかがわからない」から、やる前から無駄を考えてもあまり意味がないなと思って。
よくやっていたのは、自分の頭の中の解像度上げるために 1 回粒度を気にせず書くこと。その後に情報の取捨選択をしていく。これをやることによって足りない情報が見えてきて次のアクションを起こせる。
つくりきることをゴールにしていなかったというか。シナリオって仮説を具体化して、それをバウンダリーオブジェクト（※）として次につなげるための中間成果物でしかないので、そんなに重くとらえずに「とりあえずやる！」という感じでやっていました。
あくまで中間成果物かつプロトタイピングツールであり、内容そのものというよりも具体化したことで見えたこと、それらをどう議論していくかが大事ということですね。そのためにも精度や粒度は気にせず一度出力してみる、という行為を早くおこなうべきということなのだと思います。
※バウンダリーオブジェクトとは、「境界をつなぐためのもの」という意味をもつ概念。異なった背景や立場の人たちをつなぎ、共通の目的に向けた議論を通じて、相互理解を促すためのものを指す言葉。
実現可否をどこまで考慮するべきか
理想の時間軸と期待値を明確にすることで判断ができる
2つ目のお悩み「実現可否をどこまで考慮するべきか」ついても聞いてみました。
🐯経験者さん1のお話
まず最初に「実現したい理想が、いつの時点での理想像なのか」という目線合わせがあるといいんじゃないかなと。
例えば、今から開発して1年後とかにリリースされるものって、今ある技術でしか実現できないじゃないですか。1年後にリリースしている＝1年後までには何か実現しなきゃいけないし、理想を実現にする方法を決めなきゃいけない。
なので、ここをすり合わせておくと発散のしすぎをある程度抑えられるんじゃないかな。進行していく中で、都度会話を重ねていかなくちゃいけない部分ではあるけれどね。
🦊経験者さん2のお話
（経験者さん1のお話に加えて）期待値はすり合わせた方がいいかなと思います。
例えば「新規画面だけ改修したいです」という話がきた時に「オンボーディング体験全体を改善した方がいいです」という提案をした場合、仮にそれが正しかったとしても「いやそこまで求めてないんだけれど…」となってしまうので。
提案をするのであれば、そもそも期待値がずれていることを認識した上で、どのようにプロジェクトメンバーと話を進めるか考えていけるとよいと思います。
まとめると理想としては以下のような流れでシナリオを作成し、最終的にどのような形でサービスやプロダクト等に落とし込んでいくのかを議論できるとよいのだろうと思います。
理解してもらえるシナリオのつくり方
見る人のリテラシーに合わせたシナリオづくりをする
前段でシナリオを使うことで、プロジェクトメンバーと認識合わせしたり、議論が盛り上がったり、何か方向性が見えることこそが大事ということがわかってきました。その上で3つ目のお悩み「理解してもらえるシナリオのつくり方とは」について、「理解できる粒度はプロジェクトメンバーのリテラシーや考え方に依存する」というお話をもらいました。
シナリオのつくり方の例を挙げます。
Aさんの場合
【リテラシー】プロダクト開発に関わったことがない
【考え方】シナリオをしっかり理解したいと思っている
→いきなり体験を考えるのはハードルが高いので、イメージがしやすいように画面のラフも作成してシナリオに添えて話す
Bさんの場合
【リテラシー】プロダクト開発の経験が豊富
【考え方】メンバー間で議論して一緒にシナリオを仕上げていきたいと思っている
→あえてテキストのみ／内容も抽象度を高くし、それを持って具体的に議論していく
上記に挙げたような人や、UXに興味はあるが詳しくはない人もいる。また志向として、議論が好きな人もいれば、ドキュメント化を大事にする人もいる。プロジェクトメンバーの理解度や志向、目的に応じてつくり込みの調整が必要というお話でした。
その上で、プロジェクトメンバーのリテラシーや理解度を測るコツも聞いてみました。
🐯経験者さん1のお話
改めて言語化すると多分いろんな観点出せるので悩ましいですが、経験値は大きいと思っていて。それこそ 1 回でも開発に関わったことがある人と、一度も開発に関わったことがない人だと解像度が全然違いますし、過去に何かものをつくった経験があるかとか、デザイン会社と仕事した経験があるかによっても全然違いますね。
なので、ものづくりの経験がどの程度あるのかが、まず1個の指標なのかなと思います。
よいシナリオをつくるには
ビジネスゴールを意識できている＋ユーザー中心になっていること
ここまでお話ししてもらって改めて、「よいシナリオとはどんなものなのか？」という疑問が浮かんできます。
シナリオを作成した目的が達成ができている。つまりシナリオが完成した時に「プロジェクトメンバーの満足度が高い」だったり「きちんと共通認識が取れている」ということは大前提にありつつ、もう少し具体的に分解すると下記の2つがあるのではというお話がありました。
■1つ目：クライアントのビジネスゴールを意識できていること
■2つ目：ユーザー中心なものになっていること
UX/UIデザイナーが伴走する意味として、1つ目と2つ目どちらか片軸だけの視点ではなく、両軸で提供できることが大事であるとのことでした。
「ユーザー中心に考える必要性を共有する」ことも大切なこと
その上で、「ユーザーを中心に考えることが、そこまで求められていないというケースもあるよね」という話に。経験者2さんの「プロセスとアウトカムを実感しないと、なかなか理解や腹落ちはしづらい」という経験則から、そんな時私たちはどうしたらよいのだろうという点についても最後にお話を聞いてみました。
🐯経験者さん1のお話
ユーザー中心なサービスをつくることへの期待値がそこまでなかったとしても、私たちはデザインのプロとしてユーザー中心に考えることの大切さをお話ししていくべきだと思います。なのでユーザーが中心ってどういうことなのか、どんなメリットがあるのか。情報を共有してお互いに目線を合わせていくことが大事なのかなと。
プロジェクトメンバー全員が同じ土俵に立って、本当に必要か一緒に議論して決めていく。この形が全てうまくいくわけではないけれど、そんな形で議論が進むと理想的だなと。
🦊経験者さん2のお話
伝え方の話ですが、私の場合はユーザー中心の視点が足りていない観点を論点として出して、その中のデメリットを伝えることが多いです。もしくは、なぜユーザーを中心に考えないといけないのか共有した上で「なので今の方向性は私はおすすめしません」と明確に言い切ることもあります。最終的な意思決定は相手がする場合でも、自分の観点を伝えることは大事にしていますね。
相手も良くないと思っている可能性は十二分にあるので、言い方のバランスは探り探りです。
求められている／いないという話ではなく、プロとして「やるべきこと」であり、それこそがUX/UIデザイナーがプロジェクトに入っている意義。逆にユーザーを中心に考えられていないことに気がついた時に「言わない」という選択肢はなく、一緒に伴走していくために共有しなくてはいけないことであるという言葉ももらいました。
まとめ
シナリオ自体の捉え方の話から、最終的にUX/UIデザイナーのあるべき姿にまでお話が広がった回になりました。
シナリオはあくまでも中間成果物であり、これを通じてどのようにコミュニケーションを取りたいかによって、粒度や内容を調整すればよく。逆にあまりにも粒度に悩んでしまう時は、時間軸や検証したいことが曖昧な時なのかもしれないと思いました。立ち返って、そこからプロジェクトメンバーと認識を合わせなきゃと気付けたらそれはそれで成果なのである、ということもまた今回お話を聞いて感じたことでした。自分で作成する際は、ある意味肩の荷を下ろして取り組むことができそうな気がします。
また、最後のプロとしてのありかたについて「伝えるべきことはきちんと伝える」という点は、胸に刻みたいです。
いかがだったでしょうか？
この記事を読んで、自分もここ悩みがち…、自分はこうしているなぁ…など少しでも共感したり、思ったことがあればぜひコメントに書き込んでいただけたら嬉しいです。
コンセントではデザイン分野が多岐にわたることもあり、キャリアを形成する上で新しい分野に挑戦する人が少なくありません。そして、その中には「最近UX/UIについて学び始めた」という人もいます。そんなUX/UI初学者に対して知見をひらいていこう！という取り組みが「知見聞いてみ隊」です。
引き続き「UX/UIデザイン」にまつわるテーマで第4回も開催・記事化する予定ですので、お楽しみに！
▼▼▼「ペルソナ」について話した第1回はこちらから▼▼▼
▼▼▼「価値探索」について話した第2回はこちらから▼▼▼
🙋 一緒に働く仲間を募集しています
コンセントでは、対象とするデザイン領域の広さから多くの職種があり、一緒に働く仲間を募集しています。
📮 お仕事のご相談お待ちしています
事業開発やコーポレートコミュニケーション支援、クリエイティブ開発を、戦略から実行までお手伝いします。
お仕事のご相談やお見積もり、ご不明な点など、お気軽にお問い合わせください！