意思決定をすばやく！スケッチセッションをやってみた
はじめまして
UXデザイナーの中村と申します。担当はぐるなび の検索画面で、以下のような店舗の検索結果一覧におけるユーザー体験の向上をミッションとし、施策の仕様策定やブラッシュアップ、ドキュメント類の作成、ユーザーテストのシナリオ設計、効果計測等々施策の進行管理全般を担っています。
この記事では検索チームで案件立案時に取り組んでいる「スケッチセッション」についてお話します。
スケッチセッションは多様なUI・UXデザインのアイディアをコラボレーションして導き出すための手法の一つで、文字通り図や絵＝スケッチを使います。プロジェクトの様々なフェーズで使える手法ですが、主にはプロジェクトが課題抽出を終えて、ソリューションフェーズに入る際に使用します。
一生懸命ドキュメントを書いても生産性が上がらないと感じている人や、チーム全体で議論する方法を模索している人に読んでいただけたらと思います。
チームの課題＝リードタイムの長さ
検索チームで問題になっていたもの、それが施策のデザイン・仕様が決まるまでの長さです。
取り組む課題は明確で、ソリューションの方針も概ね決まっている。決めるべきはデザインと仕様の詳細のみなのですが、これがなかなか決まらないのです。
決まらない原因は大きく3つありました。
① 単純な考慮漏れ
必要なパターンが網羅できていない、イレギュラーな動作を考慮できていない、前後の動作との整合性が取れていない、他の要素とのデザイン・動作の統一が図れていないなど。
② 技術的視点の不足
UXデザイナーとUIデザイナーで仕様をかためていざエンジニアに展開すると、工数や実現度合い、表示速度への影響等を懸念して差し戻されるケースがありました。
③ テキストベースの共有による認識のずれ
こちらのイメージをきちんと伝えたつもりがメンバーそれぞれの持つイメージが微妙に異なっており、あとになってその認識のずれが露呈するのです。
こうした考慮漏れや差し戻しが多発すると、デザインの修正や見積りのし直しが増えます。伴ってスケジュールが立てづらくなり、チーム全体が身動きの取りづらい状態になってしまいました。
改善のカギは「メンバー全員」で「描く」こと
どうしたら現状を改善できるのか、プロダクトマネージャーと相談した結果「デザインスプリントの考えを取り入れたり、スケッチセッションを使うのはどう？」というアドバイスをもらいました。
要はロールによってフローが分断されていることや誤解の生じやすい文字ベースのコミュニケーション、そしてUXデザイナーひとりで膨大かつ複雑な仕様を網羅しようという考え方が問題の原因なので、プロジェクトに関わるメンバー全員が一堂に会する＆イメージを言葉ではなく図で伝えることで解決するのでは？という提案でした。
スケッチセッション 実践
何はともあれやってみよう、ということで、他社のブログやデザインスプリントの本を読み齧り、私たちのチームでは以下のようなステップでスケッチセッションを行うことにしました。
今回取り組むテーマは「日付指定機能の改修」。当時抱えている課題として日付での絞り込みがしづらい（具体的には今日/明日など予約ニーズの高い日付での絞り込みが不便）というものがあったため、この課題を解決するにはどうしたらいいか？をみんなでスケッチしましょうとなりました。
結論も載せてしまうと、最終的には上記の「実装後」のような形に決まります。これがスケッチでどの様に決まっていったかご紹介していきますね。
スケッチには私たちUXデザイナー、そしてUIデザイナーはもちろん、フロントエンドエンジニア、そして検索チームのリーダーであるプロデューサーにも参加してもらい、計4名で行いました（バックエンドエンジニアは都合がつかず欠席）。
①キックオフ
スケッチセッションに参加するメンバー向けにキックオフを行います。
ここで今回解決したいユーザー課題を共有し、全員の意識統一を図ります。
またこの課題に対して他サイトがどのようなソリューションで対応しているかを調べ、それを発表します。
（同業種はもちろんですが、他業種のサイトもけっこう参考にします）
また、スケッチにあたっての前提や制限事項などもこの時説明します。
アイデアの発散度合いをある程度絞らないと現実的なものにならないからです。
②スケッチ作成
キックオフの内容を元に、各自スケッチを描きます。
私たちのチームではこれは個人作業にしています。本来は全員で顔を合わせて描くのが望ましいようなのですが、そうは言っても時間の確保が難しいので…。
フォーマットは自由で、ガチで手描きの人もいればGoogleスライドを使う人、iPadで描く人もおり様々です。
③チーム内投票
スケッチが描けたら、まずはチーム内でプレゼンと投票を行います。
各自描いてきてもらったスケッチを一つの場所に集約して見比べやすくします。以下が全員のスケッチを壁に張り出した時の様子です。この時はコロナ禍前でしたので対面で行いました。コロナ禍でフルリモートになってからは、Jamboard等のオンライン上のホワイトボードツールを使っています。
各自5分程度で自分のアイディアをプレゼンをしてもらい、質疑応答なども行います。
全員のプレゼンが終わったら、まずいいなと思ったアイディアに対しシールを貼ります（オンラインで行う際はjambord等で付箋を貼っています）。デザインスプリントで「ヒートマップ」と呼ばれている工程です。この時、評価の対象はその人の案全体ではなく、アイディアの一部で構いません。つまり「この人の案のこのアイディアがいいな」という箇所にシールを貼ります。数に制限はありません。
こうすることで、どの案のどのアイディアが好評なのかというのがわかりやすくなり、最終的に誰の案を投票するか考える上で判断材料になるというわけです（私たちのチームの場合、人数が少なすぎてあまりヒートマップらしくなっていないですが…）。
その後はチーム内で投票を行い、推し案を決めておきます。
投票の仕方は何でもいいのですが、対面で行った時は付箋に投票したいアイディアの提案者の名前を書いて、せーので出しました。
リモートになってからはビデオ会議のチャットツールで同様にせーので出し合っています。
この時、ミーティングのホストの方は画面共有を切らないと私みたいに誰に投票するか丸見えみたいなことになるので注意してください。笑
なお、私たちのチームでは自分の案に投票するのを禁止しています。当たり前ですがみんな良いアイディアを出そうと思ってスケッチに臨んでいるわけで、自分の案への投票を可能にするとけっこうな割合で自分の案に投票する人がいます。自分の案に自信があり、忖度がない証拠なのでいいことだなとは思うものの、私たちのような少人数のチームでは票がばらけて投票にならないので禁止にしました。
投票後、スーパー投票までに案のブラッシュアップを行うことも可としています。仲間のアイディアに刺激されたり、質疑応答を受けてもっとわかりやすく修正したいな、となることがあるためです。
④スーパー投票・決定
チーム内でのプレゼン・投票を経て、いよいよ決裁者による投票を行います。
私たちの場合はプロダクトマネージャーが投票権を持ちます。
流れはチーム内投票と同様、プレゼン→質疑→投票です。
この時、判断の参考としてチーム内投票の結果を伝えます。
そして投票で選ばれたアイディアが晴れて採用案となります。
ただし一つの案で解決することはあまりなく、「採用案Aをベースに〇〇の機能はB案、UIはC案を採用」の様に複合したものになる場合は多いです。
なお、チーム内投票で選ばれたものとスーパー投票で選ばれたものが違った場合、有無を言わさずスーパー投票で選ばれた案が採用です。チーム内投票はあくまでスーパー投票の判断材料として行っているので、決済者の決定が絶対です。
やってみた感想
スケッチセッションをやってみた感想ですが、やはり自分では思いつかないアイディアが出て幅が広がることと、短期間で関係者全員の合意形成ができるのが最大のメリットだと思います。
また自分たちでアイディアを出し合うので納得度が上がり、プロダクトに対する主体性や愛着度合いが上がるというのも大きな利点だと感じています。
ただ、もちろんいいことばかりかと言うとそうでもありません。トータルで見れば効率が上がっている実感があるものの、やはり全員のスケジュールを抑える＆個人作業の負担を強いるので、イニシャルコストがそこそこかかる感が否めません。
これについてはデザインをコンポーネント化＆プロトタイピングツールを使ってスケッチ作業をもっと軽くできないかなー、とチームで話し合っている最中です。
今後の取り組み
スケッチセッションを取り入れたのは今年の3月からなのですが、私たちのチームでは既に定着していて、今ではみんなでスケッチやるのが当たり前みたいになっています。現在はほぼフルリモートで業務を進行していますが、ツールを駆使することで問題なくスケッチセッションを継続できています。
今後はこのステップをよりスリム化して行くことと、この手法を他のチームに展開する取り組みを行っていく予定です。
お知らせ
次回は、UIデザイナーが募って作成したぐるなびLINEスタンプの製作プロセスについてお話したいと思います。
更新をお楽しみに！
ぐるなびでは仲間を募集しています
ぐるなびでは一緒に働いていただけるUXデザイナー、UIデザイナーの方を募集しています！
このnoteを見てちょっとでもいいなと思っていただけたら覗いてみてください〜！
参考図書
この記事が気に入ったらサポートをしてみませんか？