❱ Design Sprintとは
Google Venturesが提唱したIDEOのMethodsなどを参考にしてつくられた、新規プロダクトや新機能などを解決するため短期間に行うアイデアソン的なブレインストーミングを言います。
動画: Google I/O 2014 - The design sprint: from Google Ventures to Google
❱ Design Sprintの体験
2014年11月の終わりにGoogle 東京オフィスにてワークショップが開催され、自分も参加してきました。
Design Sprintのテーマとして、Android Wearのアプリケーションということで、用意されたペルソナのユーザーニーズを読み解き、そこからアプリケーションのペーパーワイヤーまでを作成しました。
実際はこの工程を繰り返しながら、プロトタイプを使いユーザーの反応・行動を観察・分析し、プロダクトへフィードバックしていくところまで行うようですが、1日でしかも4時間程度のワークショップなのでその辺りはご愛嬌。
➡ Google Japan Developer Relations Blog - Design Sprint for Android Wear を開催します
というか、まぁフローに忠実すぎて目的を見失うようでは意味がないので、何をやって何を分析しどうプロダクトへ反映させるかはケースバイケースかなと思います。
❱ 主な環境・注意点・フローについては以下の通りです。
環境と道具
- 1チームは5〜6人程度、人選はデザイナーとエンジニアがミックスされる形
- 時間はトータルで3時間弱(実際は数日に分けて行う)
- 使用した道具
- ホワイトボードもしくは付箋を貼るグラフボードが記載でき、チームでディスカッションできるくらいの何か。今回はホワイトボードの数が足りなかったので、壁に大判の紙を貼ったり、窓にグラフ用の軸をテープではったり。
- 正方形の付箋
- ペン(ポールペンやシャープペンシルでは見えにくいので太く見やすい字がかけるもの・色は特にこだわりなし)
- 時間が計れるタイマー的ななにか
- A4紙(20枚程度用意しておく)
- プロジェクター
- ファシリテーターを置く
注意点
- ペーパープロトタイプの作成はこの段階では実装可能かどうかより、サービスとしてニーズに対応できるかどうかを優先として考える
- それぞれの工程は10分程度で、時間は厳守!
- 今回はStartUp規模のプロダクトを想定
フロー
1. チーム分け
- チームメンバーの自己紹介(何をしているか、どこに所属しているか軽く)
2. プロトペルソナの選択
- ファシリテーターの方から配られたのは5名くらいの様々な国の男女
- 自分たちのチームでは、その中から以下の条件の女性を選択
- フランス人
- 20代半ば
- TwitterやInstgramのフォロワー数がかなりの数いる
- ちょっとした有名ブロガー
- 写真家
- 日本好きで、過去に来日している
- 列車での旅が好き
3. プロトペルソナのサブストーリーを仮定
- チームメンバーそれぞれが仮定する
- その後にチーム内で軽くプレゼンをし、最も適しているものを選択するか、各員のサブストーリーをミックスする
- 自分たちのチームでは、以下のサブストーリーを仮定してみた。
- フランスで出版した旅の写真集が好評で2冊目の出版予定がある
- 次作のテーマは日本の旅・ことば
- 出版までスケジュールは少ない
- 日本では大都市ではなく、地方、とくに列車を使って移動を考えている
- 滞在先で現地の人びととコミュニケーションもはかっていきたいと思っている
- TwitterやInstagram、ブログで旅先や活動・写真を公開するつもり
4. ユーザーのWant/Need/Becauseを考える
-
Want(欲しいもの・したい事)
- 今回の場合は以下の点をWantにしました
- 日本を旅しながら写真を撮りたい
- 日本人(特に地方の)とコミュニケーションをとりたい
- 日本の様子を自国に紹介したい
- etc
-
Need(必要なもの・しなければならない事)
- 今回の場合は以下の点をNeedにしました
- 日本の語学・文化について理解する必要がある
- 日本の交通について知っておく必要がある
- etc
- 今回の場合は以下の点をNeedにしました
-
Because(Want/Needの理由)
- 今回の場合は以下の点をBecauseにしました
- 日本の旅をテーマにした写真集を出版するので
- 出版スケジュールを加味するとゆっくりもできないので
- 過去に来日しているが、それほど多くの回数来日していないので
- etc
- 今回の場合は以下の点をBecauseにしました
- 今回の場合は以下の点をWantにしました
- こちらも4の工程と同様に、チームメンバーそれぞれが仮説を立て、後にプレゼン→ミックス or 選択する
5. どのような機能やコンテンツがあればいいか付箋に書き出す
- 今回の付箋の内容は多かったので一部覚えているものだけ紹介します。
- 翻訳(とくに方言)
- 時刻表(電車以外にもバスなども含む)
- 写真をシェアする
- ホテル・宿検索
- 行き先をレコメンドしてくれる機能
- etc
6. 縦軸[User Value: ユーザーの価値]と横軸[Technical Complexity: 実装の複雑さ]のグラフに付箋を貼る
- 付箋の内容は軽くプレゼンしながら貼ること
7. メインになる機能をいくつか選ぶ、もしくはミックスする
- 既存サービス充実をはかる場合はUser Valueに寄ったものを、新規サービスなどはTechnical Complexityに寄った機能を選ぶ
- 今回は新規サービスを想定しているのでTechnical Complexityに寄った機能を選ぶ
8. 選んだ機能を使っているユーザーストーリーをイラストで描く
- チームメンバーそれぞれが描く
- A4紙を8つ折りにし、8つのコマそれぞれにイラストを描く
- イラストの上手い下手にこだわらず、チームメンバーに伝わるように描く
- 書き終わったら各員プレゼンテーションを行う
- 最も今回の内容に適していると思われるものを選ぶ・ミックスする
9. ペーパープロトタイプを描く
- チームメンバーそれぞれが描く
- A4紙に8つのコマそれぞれに画面を描いていく
- 今回はAndroid Wearなのでそれを踏まえた画面構成・導線までを描く
- どこをタップしたらどの画面へ遷移するか→などで導線を示す
- 書き終わったら各員プレゼンテーションを行う
- 最も今回の内容に適していると思われるものを選ぶ・ミックスする
10. 各チームプレゼンテーションを行う
- プロジェクターにペーパープロトタイプとプロトペルソナを映しながら代表者が行う。
- 今回の場合は、方言をAndroid Wearで録音し読み取り、英語などに翻訳、また音声も含めてシェアできるアプリケーション・サービスを考えました。
11. 終了
❱ 所感
上の経験を踏まえて、2014-12-13にQiita Api Hackathonに参加しました。Golangも書けるAndroid EngineerとJavascriptも書くUI Designerの自分とで。
上のAndroid Wearのアプリケーションは仮想のものなのでワークショップ向けという印象で終わりましたが、持ち帰ってQiita Api Hackathon向けにAndroid Engneerに教えながら実践したところ、かなりスムーズに意識の共有・課題の集約・ユーザー心理の分析ができたと感じました。
サービスデザインを行う上で重要なのは部署の垣根を取払い、サービスについて意識と情報の共有を行うことだと思います(至極当然のことですが)。そのための一つのツールとしてDesign Sprintを採用するのはアリなのではと思いました。