#think_design ユーザーファーストな勉強会 Think User First – Cookpad × Fablic に参加してきたまとめ！

クックパッドとファブリックのデザイナーが考えるユーザーファーストを共有するThink User First – Cookpad × Fablicに参加してきたのでそのまとめです！

発表やイベントの雰囲気もユーザーファーストに考えられていてとてもいい勉強会でした！

クックパッドデザイナーが実践するユーザーファースト

倉光 美和（くらみつ みわ)様 Cookpad/デザイナー

ユーザーファースト事例紹介

Cooking

• 一度ユーザ視点になって、今ある材料で実際に料理をしてみる
• 開発者もユーザーになって、サービスを利用して、料理を作り、その体験を通してヒントを得る
• 機能ではなくユーザーストーリーで考える
  • 卵でレシピを検索した時のユーザーは「冷蔵庫にある材料で一品作れないか」と考えていたりする

Design Review

• 互いのデザインをレビューしあう文化がある
• デザイナー全員で成果物に責任を持つことで一定水準以上のレベルに持っていく
• githubのissueで行われている
• ユースケースなどを明確にした上でレビューを投げる
  • レビューを受けた上で他社事例の調査をしたり、テキスト表現を変更、タッチポイントを考慮した設計にしたり変えていく

Groupad（クックパッドの社内の情報ポータル的なもの）

• 部署や専門職の垣根を超えて知見を共有することで、開発効率があがり、サービスに磨きが上がる
• 例えば社内のブログで勉強会の内容を書いたらコメントをもらえ、社内のコミュニケーション活性化に役だっている模様

User Interview

• 「誰のどんな課題を解決するのか」を定義するために開発デザイナーも定期的にユーザーと会う
• 3月：1人ぐらしの若者（8人）、4月：SNSで料理写真をシェアしている人（7人) 5月：料理ブログを書いている人（14人)インタビューしたりした
• インタビューするまでにまず、テーマの選定を行った上、ユーザー抽出条件を決めて設問項目を設定する
• 冒頭で質問する内容は最初に、朝起きて、夜寝るまでの代表的な1日の流れをきくことで、その人が何を大事にしているかを探る
• インタビューデータはグラフ化する
• 傾向が近いユーザを集合体として分析する
• cf: クックパッドでのユーザ調査

さいごに

• デザインする時に以下の自問自答をしている
  • そのデザインは、どんなユーザーのどういった課題を解決しようとしているか？
  • 機能主体ではなく、ユーザーストーリーで考えた時、今やっているデザインはユーザーにきちんと価値を届けられているか？

Holiday のデザインと開発 – ユーザーに価値を届けるためのプロトタイピングから実装まで

多田 圭佑（ただ けいすけ）様 Holiday/デザイナー

• Holidayは5人で制作
• ユーザーに価値を届けるプロダクトを作る方法としては、速さと品質をいかに両立するかにかかっている
  • 速さ：価値を発見したり、時代とともに変わるユーザの変化に適応する
  • 品質：価値を発見したら価値を適切な人に正しく届けたりするためにインタラクティブを適応したりして、価値を高める
• どうやって速さと品質を高めるかというと、仮説、検証、実行のサイクルを細かく何回も回す

仮説

• ユーザー、欲求、課題、特徴をうめる価値仮説シートというものを使っている
  • 〜は、〜（し）たいが、〜（ない）ので、〜（こと)に価値がある
  • 例えばHolidayなら、「お出かけが好きでよく出かける人」は、「自分のおすすめプランを人に教え」たいが、「プランを伝えるのに手間がかかる」ので、「簡単に魅力的なプランが作れる」ことに価値がある
• Emotion Oriented Goal Setting Framework
  • 複数の人の欲求を一つのゴールにまとめて作る
• アプリを作る際にはアプリケーション定義ステートメントを使う

実行

• Minimum Viable Product
  • 仮説を検証するために必要最低限のものを備えたプロダクトを作る
  • 紙で書いたり、FlintoやPrott、Keynoteで作ったりする

検証

• 数字をみて仮説が正しいかを指標を計測する
• ユーザビリティテストやヒアリングもかかさない

Holidayを作った時のお話

• Githubのissueでアプリケーション定義ステートメントを作る
  • 48コメントももらえた！
  • コア機能が多すぎと言われたので、少なくシンプルにした
• アプリケーション定義ステートメントを元にペーパープロトタイピング
  • 各スクリーンがどういうシチュエーションにつながるかを作っていく
  • 何パターンか作る
• おでかけプランをこだわりたかったが、イケているかどうか分からなかったので、他の方法を使ってみた
  • 他サービスにコラ画像当て込みでおでかけプランを投稿した雰囲気画像を作った
  • 既存のWebViewでHTML/CSSを少しいじってレイアウト変更
  • 2パターンを使って、観察・意見を聞いた
• Sketchで画面imageを作成し、Flintoでおおまかな遷移を確認できるものを作った
• 実装フェーズ
  • エンジニアは週2日しかこなかったので、UI部分はデザイナーがどんどん実装していった
• ある程度できたら旧testflightで社内の人に日常的に使ってもらった
  • フィードバックをもとに多くのUIを変更していった
  • 実装で手戻りはあまりなかった
• 価値を正しく伝えるためにトランジションやインタラクションを実装していった
  • ひとつのものを拡大しながら遷移したり、パララックスの効果などを実装していった
• 実装後も繰り返し仮説、実行、検証を繰り返していった

FAQ

• 仮説検証を繰り返すとのことだが、社員の人たちにどれくらいの使いにくいという意見が集まったら実行していくか？
  • ケースバイケースだが、データ定量的に仮説をたてて、ユーザーヒアリングをした上で判断する
• 価値シートはどういう時に使うのか？
  • 毎回ではなく、大きい物の初期の価値を建てる時に使われる
  • 細かいところの改善は他の手法を用いている
• 検証のフェーズの分析は誰がやるか？
  • 多くはデザイナーディレクターがやるが、数値分析を行うスタッフも入れている
• ABテストやっているか？
  • 有料会員に対して文言を変えたりなどして訴求方法を変えたりしてやっている

ユーザーファーストな会社の誕生と実践

竹渓 潤（たけたに じゅん）様 Fablic/取締役・デザイナー

• ユーザーファーストはサービスを成功させるためにまずはユーザーを満足させるという考え方

文化の芽生え (Frilリリース前)

• 女性向けサービスだが、創業メンバーが全員男性だったため、ターゲットのことが全然わからなかった。
  • 「間違った判断をしないようにしよう！」ということで100人の女性にインタビューした
• アンケートを記入していくシートをベースに質問をしていった
  • アンケートの内容として平日の過ごし方と休日の過ごし方はcookpadと同じように聞いていた
• 学びとして、買ったけど着ないことが頻繁にあったり、着ない服を捨てたり、ヤフオクで服を売っている人は少ないことがわかった
• 2012/07までフリマアプリが1個もなかったので検証できるものがなかった。そのため一つ一つ検証するために、100人の女性にユーザビリティテストをして作った。
  • 部分的に作って試していったので実際に出来上がったものに対してはこんな人数はいらないと思われる
  • 質問予定項目として、「DLしてください」「新規登録してください」などのアクションをかき、それに対する想定回答を書く。その後、ユーザーから実際に得られた回答とを比較していった
• 学びとして、女子は文字を読まない、女子はボタンを連打する、女子は手が小さいことがわかった
• ユーザービリティテストをすることで、QAでは分からないユーザーが実際に躓くポイントを確認でき、UIの不毛な議論に終止符を打てる
• スマフォで撮影してyoutubeで共有したりすると実際の操作から学べるものもある

文化の定着と実践 (Frilリリース後)

• カスタマーサポートをアプリ内のお知らせでカジュアルにユーザーから採用した
• ユーザーが近いことで、issueごとにユーザーテストしたり、企画ごとにユーザーインタビューしたり、ユーザによるカスタマーサポートをしている
• ユーザーアンケートをアプリ内でよく配信する
  • 一晩で1000~2000件集まったりする
  • よく使うユーザーだけにセグメントを切って配信することも
  • 事実を聞く
  • 意見は取り扱い注意
  • 100〜ある数を集めるとブレない回答になる

現在の課題

• ライトユーザーの声をどう集めるか
  • ユーザーを抽出してメールしたり、アンケートに答えてくれた人に対して紹介してもらったりしているが、なかなかうまくいっていない
• 非ユーザーの声をどう集めるか
  • Survayなどのアンケートサービスを使って集めることもできるが、毎回毎回実施するといったようなことはできない

ユーザーの声とどう向き合うか

• ユーザーの声をどこまで信じていいのか
  • 本当に必要な物が何かはユーザー自身もわからない（医者と患者の関係のようなもの）
  • 例えば、ユーザーが「簡単に再出品できる機能がほしい！」といった場合、実際に実装すると、新着順に商品が閲覧できなくなる副作用があるが、そのユーザーの要望を掘りさげると「時間が経つと商品が埋もれてしまい売れにくくなる」ことに不満を感じていることがわかったので、「検索結果の並べかえ」機能をリリースして改善した
• 声の大きな人に振り回されない
  • 共通した言動・反応はなにか
  • 10人中10人が言うことは信じられる
  • 例えばとある機能を廃止したところ、実際不満を感じたユーザーは一部だけだった
• そもそもどんなサービスにしたいのかをもって作っていくべき
  • ユーザーの言われるがままにやっていくのではなく、ユーザーを仮説の検証のために使っていく
• ユーザーの声を聞くのは簡単。やっちゃダメという思い込みを捨てること

FAQ

• ヘビーユーザーへの配信はどうやっててるのか？
  • DBにユーザーステータスが保存されていてそれを元に配信している
• ユーザビリティテストを社内でやっているとのことだが、アップデートを重ねる時には大体何人くらいの方にテストをしているか
  • 1桁台後半の人数
• frilはios/androidあるが、OSごとのUIでそれぞれテストをしているのか？
  • 別のUIのときは別々にやるが、あまり変わらない時は1回でやったりする
• 女性向けをつくろうと思ったきっかけは？
  • 調査していく中で、市場としてmixiのコミュニティや、若い女性向けサービスのデコログというブログサービスでフリマみたいなことをやっていることがわかったため、コアターゲットを女性にした
  • C2Cは成約率（売りたいという人に対して買いたい人がどれくらい現れるか）を高めるのが肝と思い、同じクラスタでやるのがマッチングしやすいと考えた
• 初期案からどのように変わっていったか
  • 最初は全ユーザー全ジャンルの商品を対象にしていた
  • 位置情報、ソーシャルグラフ、興味関心をマッチングさせる予定だったりした

UXマップを活用したサービス改善

塚由 恵介（つかよし けいすけ)様　Fablic/デザイナー

インタラクションとは

• twitterのインタラクションはタイムラインを見て、ツイートするといった形になっているが、ツイートをいきなり起動画面後に持っていたら使いづらいことになる
• Fabrix流UXマップの作成
  • 理想的な感情の動きをプロットする
    • 実際の声を反映する
  • 現実的UXをプロットする
    • 実際にユーザーに使って書いてもらう
  • 何回か繰り返して制度を上げていく
• UXマップを眺めているとタイムラインで離脱が起こっていた
  • デフォルトでフリル内で人気のブランドをだしていたら好みを制限してしまったので、ブランド好きに並べられる機能をつければ改善すると考えた
• 理想との乖離や、理想でも低いところを見たりと問題点が見えてくる
• UXマップを作ると、コンテキストに沿った適切なUI設計をするための良い材料になり、今のインタラクションがどうなっているのかを可視化できた
• チーム全体の意識がユーザーの体験の改善に向いた

UXマップの実践編

• 身近なところでの実装例
• 普段はデザイナーである皆さんにユーザーを体験してもらうために今回のイベントのUXマップを作ってみた
  • 懇親会で話しかけにくい：話しやすい雰囲気をつくるために風船をおき、ここの付近にいる人は気軽に話しかけていいというアピールゾーンにした
  • 座る場所に困る：アナウンスをしたり、プレゼン資料で誘導
  • 明日も仕事：ソフトドリンクも用意した
  • 円滑に進行するためのパネルディスカッションを置いた

FAQ

• UXマップはどう書いている？毎回書いているのか？
  • UXマップを毎回新規ではなく、同じフォーマットのものをアップデートしていっている（インタラクションの部分）
  • 仮説にインタラクションがついていくとは限らない
• UXマップを作ってもらう対象者（初めての購入者、初めての出品者、既存の購入者、既存の出品者）どうやって決めているか
  • リピートユーザーはどこかで一旦戻るが、初めての人と分けると混乱するので分けている
  • さらにAさんとBさんとで分かれていないと成立しないサービスだったので 購入者と出品者でもわけている

パネルディスカッション

モデレータ：池田 拓司（いけだ たくじ）様 Cookpad/執行役・ユーザーファースト推進室長

デザインの議論が割れた時に最終決定はどういう判断をするか

• 竹渓様: デザインのレビューというのがあり、意見を出しあうが、対立することはまれ。基本的には、ユーザビリティテストで判断していく
• 倉光様: cookpadにもデザインレビューがあり、レビューしあって解決している
  • 決着つかない時は責任者やユーザーをよくみてる人が判断したりしている

新規のユーザと既存のユーザをどちらに大切にしているか

• 多田様: Holidayの場合はまだ支持されているものではないので既存のユーザに向いている
  • ずっと使ってもらえるかに向いている
• 竹渓様: 施策やタイミングなどでケースバイケース。
  • 施策が新規の人をとりたいのか、既存のユーザへの訴求かによる
  • 施策実施前にはっきりさせているが、できていない時もある
• 倉光様: 検索から流入するユーザも多く、新規の人でもわかりやすいUIを提供している
  • プレミアムサービスは既存ユーザを重きにおいている
  • 池田様： 会員を施策する部署、検索を改善する部署、などわかれているがその部署ごとに新規や既存でわかるようにしている

デザイナーやエンジニアはどれくらの数字をみているか

• 竹渓様: デザイナーがディレクターも一貫してできることでいい部分もある。
  • 自分が作った成果の数字は追ってほしいし、やれている部分ではある
  • GAや、自社用の数値管理画面、GoogleBigQueryなどを使って追っていったりしている
  • ユーザーファーストを実践する上で比較的によく見る数字やKPIはあるか？
    • 出品数や成約数はよくみている
• 倉光様: レシピが何品投稿されているか、月間のユーザー数などを見ていたりしている
  • 池田様: cookpadもSQLを叩いたり、自発的に見る意識は高い

デザイナーが増えていく中で経験の浅いデザイナーや新しく入ってくるデザイナーにどうやって文化を伝えているか

• 竹渓様: 少数精鋭で、ユーザーファーストを理解していてレベルの高い人しか採用していないが、新卒やインターンの人たちにはまずは直接UIやサービスの根幹に関わるところを触ってもらってUIをいじってもらう
• 多田様: プロジェクトが違くても意見を言ってくれる人たちが多い環境にある
  • 社内の情報共有ツールを見ると過去の知見があるのでそこを見たりしている
• 倉光様: あまり大きな意識のブレはあまりない
  • エンジニアやデザイナー以外もデザインを理解していて開発もやりやすい
  • 全く違う文化を持ったところにユーザーファーストを持ち込むために悩んでいる
  • 具体的にプロダクトを作る上で意識を共有するのがマインドを伝えやすいところではないか

ユーザーファースト自体KPIと売上がずれることがあると思うが、どうやってバランスをとっているか

• 池田様: ユーザーファーストを実践することは意思決定をすることと思っている
  • 両方同じ方向に向かわせる努力をするのが大事
• 竹渓様: 人々に中毒的なサービスを作るというのが企業理念だが、それがそのままユーザーファーストなのであまりブレない
  • トランザクションごとに課金が発生するので、サービスを充実させていくことでユーザーファーストを追求しやすい環境なのだと思う

デザイナーやエンジニアにとらわれず、ユーザーファーストの点でぶつかった事はあるか？

• 竹渓様: 共通の意識をもててるのでぶつかったりした点はあまりない
  • カスタマーサポートの意見を参考・尊重するようにしており、迷った時はカスタマーサポートやユーザビリティテストで意見を求めるので、解消できていると思われる
• 塚由様: お互い納得行くまで話し合う
  • 企画の始まる前の段階から関係者が集まって一旦意見を集めるという場面を設ける
  • 形になったところでまた意見を集めるようにしている
• 多田様: ユーザーが言われたことなどをよく話し合っている
  • 話し合った上でチームの合意になるまで話し合っている
  • 向いてる方向が同じなので議論すれば同じ方向に向かいやすい
• 倉光様: 目標をもっている部署とやるときはやりたい機能に関して議論になることはある
  • 別の方法を提案したりして議論を重ねている

@mogmetの所感

• LINEとかはテスト用の監視部屋などもあるくらいですし、人気アプリはユーザーテストや仮説検証のプロセスを細かく回してサービス改善していってるのを感じました。弊社はユーザビリティテストなど全然取り入れることができてないので、是非積極的に取り入れたいとは思いましたが、どうやって取り入れるかを最初に考える必要はありそうです。やはりFabric社みたいにテレフォンショッキング形式で最初は100人にインタビューから試してみるとかですかね・・・！
• ツール系アプリは如何に人々の日常にはいりこんで使ってもらうかが鍵なので、日常過ごしている中での問題点を探し出し、その問題点を解決できるように仮説検証を建てていくというのは両社ともやり方は同じなのかと感じました。
• 発表自体もおもしろいものだったのですが、発表者に聞いたら発表自体もユーザビリティテスト（事前に社内で発表練習）していたそうです。発表も事前準備がやはり大事ですね・・・！