SHIFT EVOLVE Presents Events Vol.14 エンジニアのためのUXデザイン講座「ストーリーボードで学ぶUXデザイン」

Transcript

1. SHIFT_EVOLVE エンジニアのための UXデザイン講座 「ストーリーボードで学ぶUXデザイン」 1
2. ▪アジェンダ ・自己紹介 ・前回までの復習 ・ストーリーボードでUXをデザインする 2
3. ▪自己紹介 ・前職は損害保険会社のシステム子会社 ・エンジニアリング（メインフレーム開発、WebUI設計） ・品質管理（開発プロセス、UXプロセスの構築・整備、組織展開） ・インフラ（性能チューニング、セキュリティ対策） →いわゆる「便利屋」 ・現在、株式会社SHIFTのDAAE開発グループでUXディレクターを担当 ・日本科学技術連盟（品質管理系研究会）のソフトウェア品質管理研究会 でUX演習コースのサブリーダーを担当 3
4. 前回までの復習 ストーリーボードに入る前に 4
5. UXデザインにおける「戦略」 ・ユーザーの需要 ★「ペルソナ」と 「カスタマージャーニーマップ」を 使って把握する UXデザインの5段階モデル 今日のテーマであるストーリーボードに入る前に、前回講義の内容を簡単に 復習します。 前回、UXデザインで重要なのはユーザーの需要を把握することで、そのため にペルソナとカスタマージャーニーマップを使うという話をしました。 5
6. ・年齢、性別、リテラシー（≒知識、経験）、 サービス利用頻度etcで分類して作成する 仮想の「具体的な」ユーザー ・インタビュー、アンケート等の調査を通じて 作り上げる（「なんちゃってペルソナ」） →ペルソナを作ると、「誰のためのサービスか」 について関係者の目線が揃う ◆ペルソナ ペルソナは年齢や性別、リテラシー、サービス利用頻度などでユーザーを分 類して作る具体的なユーザーです。 分類する際にインタビューやアンケート等の調査を通じて情報を集めて作り 上げますが、コスト、スケジュールの面で難しい場合は「なんちゃってペル ソナ」を作ることもあります。 ただ、「なんちゃってペルソナ」を作る場合、好き勝手に作っていいわけで はなく、関係者間で「こういうユーザーいるよね」の合意が取れるくらい、 具体的かつ実在する可能性が高いペルソナにする必要があります。 ペルソナを作ると、関係者間で「誰のためのサービスなのか」についての目 線が揃います。 6
7. ・サービスを通して、ユーザー（＝ペルソナ）の 行動、感情、思考を時系列（シーン別）に並べる ①まずAsIsを記載 → 「問題」を特定する ②次にToBeを記載 → 「解決策」の仮説を立てる ◆カスタマージャーニーマップ カスタマージャーニーマップはサービスを通して、ユーザーの行動、感情、 思考を時系列に並べます。 まず、現状、AsIsを記載して、問題を特定します。このペルソナが感じてい る問題がユーザーの需要ということになります。 7
8. 事例：Starbucks Experience Map https://theoperationsblog.com/wp-content/uploads/2011/09/experiencemap1.pdf セミナーのみ資料 前回はこのカスタマージャーニーマップの事例としてStarbucks Experience Mapを紹介しました。 10年以上前のものですが、今見ても参考になると思います。 また、Starbucks Experience Mapで検索すると様々な考察を見ることができ るので、そちらも併せてみてみることをお勧めします。 8
9. ストーリーボードで UXをデザインする 今日の本題のストーリーボードを使ったUXデザインの説明に入ります。 9
10. ・機能仕様 ・コンテンツ要件 ★ユーザーが体験する 「ストーリー」から導く ストーリーボードでUXをデザインする（要件） UXデザインの5段階モデル システム開発における機能要件やコンテンツ要件は、何もないところから急 に出てくるのではなく、ユーザーが体験する「ストーリー」から導く、と考 えるのがUXです。 10
11. ・サービスを通して、ユーザー（＝ペルソナ）の 行動、感情、思考を時系列（シーン別）に並べる ①まずAsIsを記載 → 「問題」を特定する ②次にToBeを記載 → 「解決策」の仮説を立てる この仮説の検証に使うのが「ストーリーボード」 ◆カスタマージャーニーマップ 先ほど、ユーザーの需要を把握するためにカスタマージャーニーマップを使 うと説明しました。 その際、まずはペルソナが「問題」と感じることを特定し、それから解決策 の仮説を考えると話しました。 実は問題の解決策は一つだけというケースは少なく、いくつも解決策のアイ デアが出てくることが大半です。 ただ、沢山の解決策のアイデアが出てきたとしても、全てのアイデアが有効 とは限りません（一般的には有効だが、ペルソナが直面しているシーンでは 有効ではないetc）。 そこで解決策が有効かどうかを検証する際に「ストーリーボード」を作成し ます。 11
12. A.「作る前に試す」が重要 Q.なぜこのタイミングで「検証」？ 「まだ要件を考える段階で『検証』？」と疑問に思う方もいらっしゃると思 います。 しかし、要件がユーザーの需要を満たせるかどうかわからないまま、開発を 進めていき、リリースしても結果、ユーザーの需要を満たせないがゆえに使 われないというケースは避ける必要があります。 そのためには要件を考える段階から、つまり「システムを作る前に試す」こ とが重要です。 12
13. ・ユーザーの体験をイラストで表現して、ユーザー の問題を解決できるかを評価する →ストーリーボード＝「絵コンテ」 漫画や映像作品で使用される手法 ◆ストーリーボード ストーリーボードは、ユーザーの体験をイラストで表現知って、ユーザーの 問題を解決できるかを評価するため実施します。 ストーリーボードというと耳慣れないかもしれませんが、絵コンテというと 聞いたことがある方も多いと思います。 漫画や映画、MVなどの映像作品で使用される手法です。 13
14. イメージを具現化する「体験の設計図」 ↓ UXをデザインする スライドにあるように、ストーリーボードは登場人物の体験をイラストで表 現して、イメージを具現化する「体験の設計図」、つまりストーリーボード でUXをデザインするということになります。 14
15. ・ユーザーの体験をイラストで表現して、ユーザー の問題を解決できるかを評価する →ストーリーボード＝「絵コンテ」 漫画や映像作品で使用される手法 ・プロジェクト関係者間で、共有、評価することで 「解決策」が適切かわかる ◆ストーリーボード ストーリーボードを作って、プロジェクトの関係者で共有、議論、評価して いくことで、沢山の解決策のアイデアから、本当にユーザー需要を満たせる （＆プロジェクトとして許容できるコスト、スケジュール）解決策を見つけ ることができます。 15
16. ・カスタマージャーニーのシーンごとに、数コマの 絵コンテを作成して、仮説（解決策）を検証する。 ・ストーリーボードには以下を記載する ①登場人物（≒ペルソナ） ②タスクと実施する方法（≒解決策） ③動機（目的） ④満足度 →ざっくり言うと、「5W1H」＋「感情」 ◆ストーリーボードのつくり方 ストーリーボードは、前述したようにカスタマージャーニーマップのシーン を数コマの絵コンテの形で仮説を描き、検証します。 ストーリーボードには以下4点を記載します。 ①登場人物（≒ペルソナ） ②タスクと実施する方法（≒解決策） ③動機（目的） ④満足度 ざっくり言うと、「5W1H」＋「感情」 です。 これを絵コンテの形で記載します。 16
17. ★ポイント いわゆる「UI」はあえてぼかすほうが良い ・UIを出すには早い ・UIを見ると、UIに目が行ってしまう →ここで考えるべきは「UI」ではなく、「体験」 ×「UI」のための「体験」 ◎「体験」のための「UI」 ※ただし、既にUIが存在するケースは例外あり（事例で後述） ここでポイントになるのが、「UIはあえてぼかす」ということです。 要件の洗い出しというタイミング的にUIを作るのが早いという点と、UIを見 てしまうとUIそのものに目が行ってしまい、本来考えるべき「体験」ではな く、「UI」を考え始めてしまいます。 それも、「ボタンの角を丸くしたい」とか、「この情報は上下を入れ替えた い」、「説明文がわかりづらい」といった、かなり細かなUIが気になってし まうケースが多いです。 このタイミングで細かなUIにフォーカスしてしまうと、後になって必要な要 件が抜けてしまっていたり、実現したかった体験が作れなかったりします。 ただ、例外があって、既にUIが存在するケース（稼働中システム等）はUIを 出すこともあります。この場合も、UIそのものに目がいかないように注意す る必要があります。 17
18. Q.なぜ「文章」ではなく、「絵」なのか A.ストーリーは文章“だけ”で表現すると、受け手に よってイメージが異なる →「百聞は一見にしかず」 逆に、「絵」だけである必要はないので、補足 説明や、セリフは適宜追加OK ストーリーボードを説明すると、「なぜ『文章』ではなく、『絵』にする必 要があるのか？」という質問が出ます。 文章だけでもストーリーを伝えることができますが、受け手にとってイメー ジが異なる可能性が高いです。 百聞は一見にしかずという言葉の通り、絵で見せると多くを説明せずにイ メージを統一することができます。 逆に、絵だけで説明する必要はないので、状況説明やセリフ等の文章は適宜 追加してもOKです。 18
19. ◆サンプル ストーリーボードのサンプルです。これと一緒にテキストの説明がつくイ メージです。 このレベルのリアルなストーリーボードを作るケースはあまりなく、もう少 し簡素なものが多いですが、最初にしっかり作られているものをサンプルと してお見せしたほうが良いと思い選びました。 19
20. 事例 PC向け業務システムのタブレット化 ◆対応内容 ・既存のワークフローシステムのタブレット対応 プロジェクト ・タブレット向けの機能設計をするのではなく、 PC機能をそのまま移植する想定のコスト・工数 ・ボトムアップではなく、トップダウン ・類似の業務システムの中で初のタブレット対応 ストーリーボードを使った事例です。 過去にPC向け業務システムのタブレット化というプロジェクトがありました。 ワークフローのシステムだったんですが、外回りをしていてもオフィスにい るのと同じように申請、承認ができるようにするというプロジェクトで、PC 向けの機能をそのままタブレットに移植するというプロジェクトでした。 このプロジェクトは、社員がより積極的に外回りをするようにしたいという、 トップの意向からスタートしており、ボトムアップではなく、トップダウン の案件でした。 また、タイミング的に今のようにタブレット端末が普及する前で、安易に 「ノートパソコンの代用として使える」と思われている状況でした。 20
21. ◆ストーリーボードの作成 ①登場人物（≒ペルソナ） →営業担当（申請者）とその上司（承認者） ②タスクと実施する方法（≒解決策） →稟議の申請と承認をタブレットを使って ＆PC向けの画面・機能のままで ③動機（目的） →出先でも申請＆承認したい ④満足度 →満足できる？？ このプロジェクトで実際に開発を始める前に、2人のペルソナを作ってストー リーボードを作成しました。 一人はワークフローの申請者である、営業担当者、もう一人は承認を行う上 司を設定しました。 タスクと動機に関しては、トップが狙っている、「外出先でもオフィスと同 じことができる」ということで、タブレットを使った申請＆承認をPCと同様 にできる このストーリーで、ペルソナが満足できるかという点について議論しました。 21
22. ★ポイント１ ・既に稼働中のシステム、かつ PC画面・機能を 移植するというプロジェクトだったため、 「PC画面のスクショ ＋ スクリーンキーボード」 を提示 ★ポイント２ ・Web画面の移植のため、技術的なハードルは なかった ポイント１として、この時のストーリーボードはUIを見せました。というの も、稼働中のシステムだったことと、PC画面のまま移植するというプロジェ クトだったからです。 ポイント２は移植自体には大きなハードルはなく、開発するにあたっての課 題はありませんでした。 22
23. ストーリーボードを使って、 タブレット使って、出先で申請・承認するって こういうことですよ？ を共有 つまり、ストーリーボードを使って、「タブレットを使って、出先で申請・ 承認する」ってこういうことですよ」を説明、共有したことになります。 23
24. ◆内部で「満足度」を議論した結果・・・ ・営業担当（申請者）：満足度は低い PC画面のタブレット対応 →「②タスクと実施する方法」が厳しい ・その上司（承認者）：満足度は同じ or 低い そもそも外出が少ない →「 ③動機（目的） 」がない →プロジェクト実施の再考を依頼 内部で満足度がどうなるか議論したところ、やはり満足度は高くならないど ころか、低いのではないかという予測に至りました。 というのも、営業担当ペルソナの目線からすると、単純にPC向けの画面をタ ブレット用に置き換えただけでは難しく、タブレット特有のスクリーンキー ボードで1から入力することは非現実的。かろうじて、あらかじめPCで入力 しておいたものを出先で修正して申請するといった補助的な使用であれば使 えるといったものでした。 また、承認者である上司ペルソナの場合、そもそも外出頻度が少なく、タブ レットを使う必要性がないというものでした。 このように、どちらのペルソナも満足度が低い可能性が高いため、プロジェ クト実施について再考してもらうように関係者に依頼しました。 24
25. ◆その後 ・「オトナの事情」で開発続行、リリース ・リリース後に利用状況調査を実施した結果、 全通信量のうち、0.1％程度の利用 →ある特定の役職者（上司）がヘビーユーザー しかし、結果的にはオトナの事情でプロジェクトにはGoサインが出され、リ リースにこぎつけました。 リリース後、数日にわたって利用状況を調査したところ、ストーリーボード で想定していたように利用率が低く、このプロジェクト単体で見た場合には 投資対効果に見合わないものでした。 （もともとトップの「営業担当がオフィスに縛られないように、出先でもオ フィスにいるのと同様の仕事ができるようにしたい」という意向からスター トしたプロジェクトだったため、他システムと足並みをそろえてタブレット 対応をする必要があった） 25
26. ◆教訓 ・「使える」≠「使う」の再認識 →タブレット向け機能設計から実施すべきだった ・結果的に開発はしたものの、ストーリーボードに よって、システムを作らなくてもUXをある程度、 予測できる このプロジェクトは本来ならPC向けの機能をそのまま移植するのではなく、 タブレット向けの機能設計をすべきで、単に「使える」というだけではユー ザーは使わないということを再認識しました。 また、結果的に開発、リリースはしたものの、ストーリーボードの作成を通 じて関係者の目線をそろえることができ、他のプロジェクトで自ずとユー ザーの具体的な利用シーンを想定するようになりました。 事例の紹介は以上となります。 26
27. Q.絵心がありません。 A.絵心は不要。大事なのは「ストーリー」で、 「絵のうまさ」ではありません。 ◆ストーリーボードを作成するというと・・・・ ストーリーボードの説明をすると、必ず「絵がうまくかけない、絵心がない 場合はどうしたらよいか」という質問が出ます。 しかし、ストーリーボードで求められるのは「きれいな絵」ではなく、あく までストーリーです。 絵をきれいに書くよりも、「ユーザーが満足できるストーリーはどういうも のか」を考え、検証することが重要なので、絵に拘る必要はありません。 27
28. Q.とはいえ、やっぱりハードルが高いです・・・ A0.棒人間でもOK A1.「5W1H」縛り A2. StarPeople＆エモグラフィ A3. 写真コラージュ A4. Webサービス（StoryBoardThat、コミPo!） とはいえ、1枚目の絵から「どう描いたらよいかわからない」というケースも あると思います。 ここでは、その壁を超えるための方法を紹介します。 一つ目は棒人間です。これに関してはほとんど説明不要だと思いますが、ほ ぼ記号であり、描くハードルも低いと思います。 28
29. A1. 「5W1H」縛り シチュエーションを固定し、ユーザーの思考、感情にフォーカスする →ストーリーボードとは別に「シチュエーション」の共有が必要 次に、「5W1H」のうちのいくつかを決めてしまう（縛る）という方法です。 5W1H（シチュエーション）を固定して「この状況でユーザーは何を考え、感 じるのか」にフォーカスするやり方です。 サンプルイメージは、ユーザーがデスクトップPCを使って作業をするという 状況に焦点を当てたストーリーボードとなります（実際にはこのシートの吹 き出しを埋めて、検討、議論します）。 29
30. A2. StarPeople＆エモグラフィ ＋ ＝ 「StarPeople」・・・記号で人を表現 次に、StarPeopleとエモグラフィーの組み合わせです。 StarPeopleというのは、記号の◦と、★印を組み合わせることで、人型を作 るというものです。 棒人間に似ていますが、こちらのほうが若干、人の書き分けがしやすいと思 います（色を変える等）。 30
31. 出典：Star People: How to Storyboard Quickly and Effectively https://medium.com/designer-recipes/star-people-how-to-storyboard-quick-and-effective-5ea812ab153d これはStarPeopleの発案者のイラストです。手に動きがあることがわかると 思います。 31
32. 「エモグラフィ」・・・ 目、眉、口の組み合わせで100の表情を表現する 出典：絵心がないと悩む人でも一瞬で100の表情が描けるようになるラクガキテクニックとちょっとしたコツ【emography(エモグラフィ)】 http://tamkaism.com/2015/03/rakugaki100faces/ A2. StarPeople＆エモグラフィ StarPeopleの顔部分に表情を入れるとよりイメージしやすくなります。 表情については、グラレコの第1人者のタムラカイ氏が考案した、「目、眉、 口の組み合わせ」で表情を作る手法を紹介します。 口の5種類、目の5種類、眉の4種類を組み合わせることで、100通りの表情が 作れます。 また、応用もしやすいので、おススメです。 32
33. A3.写真コラージュ ＋ ＝ →数枚の写真でもストーリーの共有は可能 →→「紙芝居」 次に写真を使うコーラジュです。これはイラストを超えて、無料や有料の写 真素材を組み合わせてシチュエーションを説明するものです。 この手法ののメリットは、スマホを使って、自分であったり、友人、家族に 任意のポーズや表情を撮影することで自由にストーリーを作れることです。 実際の写真を使うことで、よりイメージが具体的にできる手法です。 33
34. A4. Webサービス（StoryBoardThat、コミPo!） 出典：会社設立マンガ もし女子高生が会社を設立したら https://ameblo.jp/zeirisitokyo/image-10772088747-10990535162.html ▪コミPo! https://www.comipo.com/ ▪Storyboard That https://www.storyboardthat.com/ 4つ目はストーリーボードが作成できるWebサービスを使うことです。ここで は2つのサービスを紹介します。 Storyboard Thatというサイトでは、ドラッグ＆ドロップでストーリーをボー ドを作成することができます。 人物やモノ、背景等も豊富なうえ、操作も簡単なのでおススメです。 もう一つはコミPo!といサービスです。こちらもイラストを使ったものですが、 Storyboard Thatよりもちょっと漫画っぽい感じです。 こちらも使いやすいと思いますし、サイトには利用事例もあるので、参考に できると思います。 34
35. ・UXはストーリーボードを作ることで 実現精度をあげることができる まとめ ・大事なのは「ストーリー」 最後に、まとめです。 UXはストーリーボードを作ることで、関係者がユーザーの目線を持つことが でき、結果的に狙ったUXの実現精度を上げることができます。 またストーリーボードでは、絵よりも「ストーリー」を意識することが重要 になります。 35
36. 質疑応答 36
37. 「 Microsoft: Productivity Future Vision」https://www.youtube.com/watch?v=w-tFdreZB94 追加資料：Microsoft Future Vision 補足で、Microsoft Future Visionを紹介します。 37
38. 「 Microsoft: Productivity Future Vision」https://www.youtube.com/watch?v=w-tFdreZB94 「近未来におけるテクノロジーと生活」を 描いたムービー。 →「ストーリーボード」の発展形 →→「今は存在しないもの」の見せ方 追加資料：Microsoft Future Vision Microsoft Future VisionはMicrosoft Office Labsが作成した、近未来のテク ノロジーを描いたショートムービーです。 ムービーですが、「今は存在しないが、こういうデバイスや機能があるとこ ういう生活になる」というストーリーを描いているので、ストーリーボード の延⾧線上にあると言えます。 38
39. おススメの見方 1回目：利用者の視点で見る →「生活がどう変わるか」 2回目：開発者の視点で見る →「どうやったらアレを開発できるか」 追加資料：Microsoft Future Vision Microsoftは継続的にこのようなムービーを作成、公開してきましたが、視聴 の際は「出てくるデバイス、機能のユーザー」という視点に加え、「出てく るデバイス、機能を作るエンジニア」という目線で見ると面白いと思います。 39