見出し画像

全員でイメージを共有する6up Sketches

Classmethod Design Note

Classmethod のデザイナーをしている田中です。
プロダクトを作成する中で以下のデザイン思考のサイクルを行うことがあるかと思います。

  1. 問題の定義

  2. ニーズを把握した上で課題解決の仮説をたてる

  3. 仮説の上でアイディエーションを行う

  4. 試作（プロトタイピング）を作成

  5. テストを行う

  6. フィードバックを元に問題の定義に戻る

ワークショップ形式で上記デザイン思考のサイクルを行うときに、問題の定義やニーズなどの仮説立ては比較的認識しやすいこともあり、その場はスムーズに流れる傾向にあります。

しかしアイディエーションを行おうとすると、アイディアを考える事自体が難しくなってしまったり、ほかの参加者の意見待ちの姿勢になってしまったりして、あまり効果的ではない場面に出会ったことはないでしょうか？

そんなときにいくつかのプロジェクトに導入し効果的に作用した6up Sketches という手法を、ご紹介いたします。


なぜ 6up Sketches を使うのか

デザイン思考やUXといった文脈で語られる手法で、まず「シナリオを作成してください」「As is - To beのカスタマージャーニーマップを作成してください」と言われても、はじめてそれを聞いた担当者さまが「わかりました」と一緒に書くことは難しいです。

また、関係者全員が問題について異なる見解を持っているケースでは、解決策を生み出し議論を手足させることはとても難易度が高いです。

なにより全員の見解をイメージで一致させて、かつ想像力を刺激することができるこの手法が効果的なケースは多いと思います。

6up Sketchesとは

スタンフォード大学が開発したアイディエーションのためのツールで、2014年に発行されたLeanUXで紹介されたアイディエーション手法です。

問題に対して可能な解決策をすばやく探るための手法として知られています。
5〜8人チームに最適で、人数が多い場合はグループを小さなチームに分けて最後に全員でアイデアを比較するのがよいと言われています。

ここでのアイディエーションは、収集した情報を元に問題を設定し、潜在的な仮説、ペルソナなどを決定し、制約のある状態でスタートします。
問題に対する全員の見解を一致させて、想像力を刺激することが目的です。

問題に対して、解決策のアイデアを出すことがゴールですが、答えがあるわけではないことは覚えておく必要があります。理由は、答えはエンドユーザーのみがもっているからです。
そのために、早くプロトタイプをリリースしてテストを行うサイクルを回すという考え方が前提です。

やり方

  1. 問題と前提条件を『全員』で認識・確認する。

  2. チームの仮説を『全員』で認識・確認する。

  3. 用紙を6等分に折る（オンラインの場合、Miroなどつかって6個の枠を作成します）

  4. 5分間、個別に絵を書いてもらう。話して補足することがないように記載してもらう

    1. 問題やペインは文字で書いて、解決策は絵（UIスケッチ、ワークフロー、流れなど）で書き込む。文字だけでは絶対に書かない。

  5. 1人制限時間3分で全員の6up Sketchesを共有する

    1. 誰の、どんな問題を解決・ペインへの対処を明確にする

  6. フィードバックを行う

  7. フィードバックを統合し、2回目の6up Sketchesを5分で作成する。

  8. 再度全員で共有し、良いアイデアに投票するなどして、最も優秀なアイデアをみつける

実際に行うときに発生すること

絵は描けない

「棒人間でもいいし、人の流れを書いてもいいし、ワークフロースケッチでもOK。6つのセルで一つの課題を解決するシーンを描いてもいい」書き方は自由で、絵がうまいかどうかは関係ないことをお伝えする必要があります。どの様に描いても大丈夫ですが、既存のサービスに捉われないアイデアを出すことに挑戦するのが目標です。

また紙に絵で書く理由は、視覚から入る情報で行き詰まっている状態からアイデアを産むのに役立たせるためです。
デザイナーであればワイヤーフレームやデザイン案を出すと新しいアイデアがお客様から湧き上がってくるのを理解できると思います。

デザイナーに任せた

アンチパターンとして、お客様は考えて表現することそのものをデザイナーへ任せっきりにしてしまう場合があります。専門家ですから意見を聞きたい、そちらの意見の方がいいと思いたいとする気持ちはわかりますし、実際にあります。
しかし、そうしてしまうとデザイナーだけのアイデアしか生まれないため別の視点のアイデアが消えてしまいます。全員でアイデアを出すことが目的ですので、お客様にも積極的に参加いただけるよう働きかけをしましょう。

また、アプリの例ですが、慣れているデザイナーが描く場合、UIの画面を書いてしまうと一見整った完成形のように見えてしまい、これでよいと勘違いしてしまう可能性があります。

わたしはそうは思わない

フィードバックで、「私はこう思う」という話をしてしまうと、本質的にはいろいろな人の意見を取り入れたいはずであったのが、その意見はアイデアを出した人物の立場や状態を考慮できていなかったことになってしまったり、発展しなくなるケースがあります。
「なぜそう思ったのでしょうか？」というように意見を述べるのではなく、相手のアイデアが難しい・よいと思えなかったとするなら、質問に切り替えてみることも一つの方法ではないでしょうか？

このアイデアは捨てられるのか

「最も優秀なアイデアをみつける」という作業で、自分が出したアイデアをなかったものにすることに抵抗感がある場合が多いです。

捨てるには惜しいアイデアもありますし、再度メンバーの入れ替えでアイデア出しをするときにすでに検討されていたアイデアかどうかを確認するために、アイデアのストックとして残すことは有効な手段だと思います。

ただし、今回の検証の中に含まれるアイデアは1つまでと線引きを決めた上で、残りのアイデアについての取り扱いは慎重である必要があります。
アイディアの先にシステム開発が控えている場合に、コスト・デリバリーとのバランスを考えたアイディアの採用が求められます。
採用の協議をした上で、採用されたアイディアは必ず１つずつ検証していくことで、施策として効果があったのかを把握しやすくなるでしょう。

うまく作用するのはどんなときか

一番は依頼者であるお客様が協力的であった時です。
そのために、営業やPM、クラスメソッド社内の関係者がそこまで関係を構築するために動いていただいていることもあります。

次に、チームメンバーがお互いの職域をこえて協力できる関係であったときです。

クラスメソッドは受託開発でも依頼者であるお客様とone teamで開発をするという言葉があります。まさしくプロダクトを作成したいお客様とクラスメソッドがいっしょにものをつくるという時が一番うまく作用すると思います。

どのフレームワークでもそうですが、あくまでフレームワークは手段の一つです。

ベストなタイミングで最適なフレームワークが選択できたら素晴らしいと思いますが、重要なのはまず「関係性構築」と「前提の認識をめんどくさがらずに行う」こと、「関係者全員が当事者である意識」、「いっしょにいいものを作成する気持ち」だと思います。

なにか参考になれば幸いです。

参考文献

  • Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES) – 2014/1/22

  • Lean UX 第3版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES) – 2022/8/29: 第3版にも記載はありますが、”6up Sketches”という名前は見当たりませんでした。