Think User First#3 サービスデザイン手法のワークショップに行ってきた

 

なにこの記事

CookpadとFablic共催のThink User Firstというイベントに行ってきたので、久しぶりのアウトプットがてら内容の要約と感想をメモする。

 

ワークショップということもあって、最初30分だけクックパッドのサービス開発で行っている手法の紹介があって、その後は実際にその手法に則ってどんなにショボくてもいいからアウトプットしてみましょう。という会だった。

 

発表された資料を何枚か撮ってきたが、斜めからの写真で見づらいのと、あとあと資料も公開される(と思う)ので講義中にとったメモだけ残しておく。

 

紹介があった手法は以下の4つ

・価値仮説

・EOGS

ユースケース

・プロトタイピング

 

(プロトタイピングについてはなんかあんまりメモが残っていないので、上3つについてだけ)

 

 

価値仮説

 ・LeanStartupで紹介されているシンプルなフレームワーク

 ・【ユーザー】は【欲求】(し)たいが、【課題】(ない)ので、【製品の特徴】に価値がある という文章に当てはまるように【】の中身を埋めていくことで、プロダクトの価値を明文化する手法

 

 探したらクックパッドの人が作った別資料があった。

speakerdeck.com

 

 

EOGS

・キャスト(ステークホルダーみたいなもの)ごとの

・疑いようのない欲求を立てて

・それらを満たす解を導くフレームワーク

・クックパッド謹製のフレームワークで一番歴史があるらしい

・価値仮説とは異なり、目的や利害が異なる複数の登場人物・組織が存在するときに各登場人物がWinWinになるようにサービスを設計するために使う

・コツは、書いてる本人がワクワクするような登場人物全員がハッピーな「背伸び」をした目標を描くこと(ただしKPIは別にきちんと設定する必要がある)

 

これも探したら資料が出てきた。

ブログ中段の図がEOGS 

techlife.cookpad.com

 

 

ユースケース

・別名ユーザーシナリオとかストーリー

・ユーザーの行動フローを書き出す

 

これはググってもいい実例がなかったので、資料で紹介されたユースケースを転載する

 1)セールで、狙っていた服を買い逃してしまった

 2)諦めきれず、フリマで売りに出ているものを探す

 3)運良く服をみつけ、状態も新品であることを確認

 4)が、販売価格が高いのでひとまず保留にしておく

 5)一週間後、さらに値下げされたことを知る

 6)他の人に狙われないうちに、急いで購入の手続きをした

 

上記の例でポイントになるのは、

・開発者目線で書かないこと。例えば、「さらに値下げされたことを知る」を「値下げされたことをプッシュ通知で送信する」と書いてはならない。さらに値下げされたことを知るという欲求を満たすための方法は1つではないしその場面で何を提供できるといいのか選択肢も含めて考えられるようにするため。機能名を書くと選択肢について思考停止してしまう。

 

・本当にユーザー目線で書けている(=開発者目線の書き方ではない)と別にアプリを使うという文脈でなくても成立するストーリーになっている(上記ユースケースは5あたりを除けば一般的なフリーマーケットでも成立する)

・ユーザー視点で記述することでそのサービスに既存の代替手段との優位性があるかがわかる

・あえて画面外の行動も書く

・これがしっかり書けるようになると開発者目線とユーザー目線の思考が切り離せるようになる

 

実際のワークショップ

 限られた時間ということもあって、ワークショップでは与えられたペルソナを元に生活に関する新規事業の企画のためにアイデアの有用性について議論できるレベルのスマホアプリのプロトタイプを製作する。というお題が与えられた。

 

最初は6チームに分かれてアイデア出ししたり価値仮説やEOGS、ユースケースを作成した。決まったテーマをざっくり説明すると「余った食事を近所でシェアするCtoCサービス」。わりと他のチームとは毛色の違うアイデアだったので、チーム内では密かに自画自賛していたw

作った価値仮説とユースケースはこれ。

 

 

この時言われたポイントとしては、

・あやふやな定義の言葉はその言葉を構成する要素を分解して本質的なターゲット像や課題、サービスの価値を突き詰めたほうがいい。最初自分のチームのターゲット像は「非リア充」というふわっとしていて特定の世代しかわからないような言葉だったが、突き詰めて自分たちが考えたアイデアが刺さりそうなターゲットは「食生活を改善したいめんどくさがり屋」というところまで具体化した。

ユースケースを作る時はまず1つ使用開始から使用終了までの流れを1本作った後に、その一部分を変えてみたりして複数作ってみるといい(って言っていた気がする)

・手詰まりになったり、前に作った価値仮説やEOGSと矛盾が発生するようなら、前に作った資料を修正してもいい。

 

プロトタイプ作り

・ここから個人作業だったが、自分が作ったものはひどい出来栄えだった。

・最初は簡単なプロトタイプだし、Cookpad本体から画像とかUIとかパクればいいやん!とか思っていたが、甘かった。「これクックパッドと変わらなくね?」と当たり前のツッコミをくらい。ほぼ全ボツとなった。

・ペルソナはとんでもないめんどくさがり屋ということに再度焦点を絞り、「ワンコインで購入できる」「帰り道で受け取ることができる」といった導線を作成し、アプリ起動から3タップで購入できるような設計をしたら、これは以外と好評だった(未完だったけど)。

・既存のUIを最初からパクっても、ユーザーの課題解決にはつながらないといういい教訓になった。

・チーム内で1人代表を出して発表してもらったのだが、うちのチームの代表者が作ったモックはSketchやらで書いたカッコイイモックではなく、手書きのポンチ絵であった。それでもサービスの価値は十分伝えられており、短時間でサービスの価値を伝える上ではモックのかっこよさはあまり重要でないことを学んだ。

 

その他なるほど、と思ったポイント

・調査や手法はすべてユーザーの課題解決のための手段なので、手段を開発組織に取り入れることそのものを目的にsないこと。組織にフィットした形で取り入れること。

・1〜2人とかの少人数で開発している場合は価値仮説やEOGS、ユースケースを書く必要はない。これらはあくまで複数名で開発しているときにサービスの目標や価値を共有したりメンバー間で考えがぶれたときの立ち返り先として使うものであって、チーム内で完璧にユーザー像や課題を共有できている場合は不要

・正しいやり方で正しいものを作ってもヒットするかは時の運だから多くのトライを打つことが合理的