【勉強会】達人たちから学ぶ。グロースハックとUI/UX
グロースハック。難しげだけど大事…と思って聞きに行ってみました。というわけで本日の勉強会メモです。
概要
- 達人たちから学ぶ。グロースハックとUI/UX
- 「どのようにサービスの成果を上げていくか、また自社のサービスにグロースハックの手法をどのように取り入れていけばいいのか、といった辺りを中心に、今回もグロースハックの達人たちをお招きし、明日からすぐに使える実践的な内容をお届けします。」
- 日時:2015年6月24日 19:30〜
- 場所:DeNA さくらCAFE
VASILY 梶谷健人さん
- 梶谷健人氏(株式会社VASILY グロースハッカー)
- あなたがグロースハックで抱えている問題は?
- よくある答え
- マクロ:フェーズ・順番(どういうステップでやっていけばいいか)
- ミクロ:実務プロセス(具体的になにをすればいいか)
- それぞれについて詳しく答えていきます↓
マクロ:グロースハックのロードマップについて
- グロースハックとは
- 数値やユーザーの声を分析し、ユーザーの数や質をグロースさせる
- 有名なグロースのモデル:AARRRモデル
- Acquisition, Activation, Retention, Referral, Revenue
- これでグロースしようとすると、ほぼ失敗する
- 失敗する理由:着手すべき順番になっていないから
- この順番はあくまで、顧客視点での順番である
- この順番でやってしまうと、ニーズ検証や体験の最大化よりも、細かい最適化のほうに目がいってしまう
- いまVASILYで採用しているモデル:ARRRAモデル
- Activation:そもそも製品の価値は顧客が求めるもの?
- Retention:使い続けてくれるくらい製品の価値に満足してる?
- Referral:友人に伝えたくなるほど製品の価値に満足してる?
- Retention:お金を払ってくれるほど満足してる?
- Acquisition:製品の価値を広めるために、正しいチャネル・訴求軸を選べてる?
- ARRRAは種々のスタートアップの概念と対応している!
- Lean Analytics
- Growth Pyramid
- Customer Development
- ActivationとRetentionがイケてれば、以降はあまり難しく無いと思っている
ミクロ:具体的な実務プロセスについて
Activationについて
- Activationとは:ユーザーにサービスの価値を感じてもらうこと
- 具体的には、以下の二点
- そもそもサービスに価値があるか:Problem Solution fit
- その価値が初回体験時に伝わるか:User Ongboarding
- ほとんどのサービスは「顧客、課題、解決法」という構造を持っている
- Problem Solution Fit:アイデアの前提となるユーザーの課題が本当に存在するか、アプローチが間違った前提に立脚していないかを確認する
- スタートアップが死ぬ理由
- 存在していない課題にアプローチしている、顧客から求められていないものをつくっている
- 失敗した例:Snapchatのカスタマーサービス
- 死なないためにはどうすればいいか
- きちんと課題が存在している、顧客が存在していることを確認
- うまくグロースした例:Zappos
- 静的な表側(HTML)だけのサイトだけで裏側のシステムはほぼつくらずに、ECサイトをローンチした
- 注文が来たら、一つ一つの商品を起業家自らが発送・梱包した
- 次第にたくさんの注文がくるようになって、価値が検証できた
- 「スタートアップのアイデアの99%は間違っている」
- Javelin Boardというフレームワークでアイデアを検証する
- 間違いに早く気づいて修正するためのツール
- Javelin Boardの具体的な流れ
- サービスについて次のことを考えてみる:顧客、課題、解決策、もっともリスクの高い想定、検証方法と達成基準
- 事前に建物の外へ出てインタビューする:結果と判断、検証方法と達成時基準
- 結果をうけて、顧客や課題などを変更していく
- これを繰り返し、もう変更がない(=サービスアイデアが妥当であると判断できる)というところまで持っていく
User Onboardingについて
- User Onboardingとは:初回のプロダクト体験で「このサービスめっちゃいい!」と思わせること
- 具体的には以下の三点
- Value Proposition:プロダクトがどのような価値を提供するのか、代替品が存在する中でなぜこのプロダクトを使うべきなのか、というのを示す
- 利用方法の理解:どんなにいいと思ったサービスでも、利用方法がわからなければ二度と使ってもらえない!
- AHAモーメント:このサービスを良いと思ってもらえる体験を早い段階でしてもらう
- 悪い例:登録した後に誰もフォローしていないので何もコンテンツが流れてこない
- 良い例:Twitterでは、はじめに必ず5人以上フォローする強制している
- それぞれについて、「何を」「いつ」「どうやって」ユーザーに伝えるかを考えていく
- 具体的なプロセス
- 今いるフェーズでKPIを定める:Onboardingであれば翌日再訪率
- ファネルに明らかなすぼみがないか探る
- 定性/定量調査でパターンを探す:翌日に再訪したユーザーとしていないユーザーにインタビューする、再訪している人/していない人についてLocalyticsで定量調査
- 改善か所を特定
- 改善箇所のファネルに明らかなすぼみがないかを探す
- パターンを増加させる施策を打つ
- パターンが増加したかを検証する(Noなら6に戻る)
- パターン増加が①のKPIに寄与しているかをチェック(Noなら6or3にもどる)
- VASILYではオリジナルのシートを作成して、上記のプロセスを回している
まとめ
- グロースハックでやるべきこと:ニーズ検証や体験の最大化 > 細かい最適化
- 実現方法:ARRRAモデル
- 各フェーズの進め方:フェーズの理解→プロセスマップ&フレームワーク
- より詳細な情報は、10月出版予定の書籍にて!
シロク 石山貴広さん:実践的なUXデザインとグロースハック
- 石山貴広氏(株式会社シロク 取締役/CCO)
- Design Lightning Talksという勉強会を不定期開催中!
- 今回のゴール
- グロースハックの意義を感じる
- サービスにハマる仕組みを作る方法を知る
グロースハックの意義
- サービス事業者あるある
- ①重要なのはユーザー獲得まで、という認識
- ②機能MECE:使ってくれない理由を理由に機能追加してしまう死のサイクル
- 改めて、ユーザーの継続性に着目しよう
- 時代の主導権はとっくに顧客に移っている
- 顧客中心時代の到来:ユーザーが自分に合わせたものを手に入れやすい時代である
- ユーザー獲得後の活性化・継続性に力を入れる必要がある
- サービスの利用価値を定めて、機能MECEから脱却する
- 時代の主導権はとっくに顧客に移っている
- 一方、UXに必要な要件は、顧客の的確なニーズを満たすことと楽しさを生み出すことの二点である(by D.A.ノーマン)
- サービスにハマり続けるしかけをつくろう!
ユーザーアクションサイクルの設計
- ユーザーが、サービスに戻ってくる理由を設計できていますか?
- UXの策定プロセス
- 顧客の問題を知る
- 問題→解決の手法を構築
- 妥当性を検証する
- 整理する
- ユーザーアクションサイクルとは?
- ユーザーが何の行動を経て価値を感じ、能動的に帰ってくるかを表した行動フロー図
- ユーザーアクションサイクルの特徴
- サービスの核が明確になるため共通認識を得られる
- MVP的な話
- ユーザーのサービス内で取る行動をプロットする≒UIFlows
- 継続率向上のためのKPIが理解しやすい
- 長期的な利用価値(能動的に変える理由)と短期的な利用価値(使う楽しさ)を設計する
- 定量的な指標(KPI)に転換して、成果検証しやすい
- どんな行動をするユーザーが継続しているか定量的にはかる
- サービスの核が明確になるため共通認識を得られる
- 重要なこと
My365で実際に取り組んでいた施策
- やったこと
- 多変量DLボタン
- 初投稿
- 過去写真の選択
- Androidファーストでテストを実施
- Androidだと審査期間がないので開発サイクルを早くできる
- 「継続」を軸にKPIを追って改善していった
- 大事なのは打席に立つ数であり、三振を恐れないマインド
- 施策は数を打つ!
まとめ
- ユーザーがサービスに価値を感じ続ける仕組みが大事
- UACやHookedを活用してサービスの継続理由を設計
- 打席に立つ数が大事
DeNA 真崎達也さん:サービスを成長させるための開発について
- 真崎達也氏(株式会社ディー・エヌ・エー デザイン戦略室UXデザイングループ デザイナー)
- 今回は、エブリスタ(小説投稿プラットフォーム)の事例を元に詳しく見ていきます
サービスの成長に必要なもの
- 高いエクスペリエンスの設計
- 徹底した定性・定量データ分析
- 高速のPDCAの実現
- → まとめると、ユーザーの感情を動かすものをつくること
- ユーザー感情主導開発:ユーザー感情とデータ分析を行い、ユーザーにとっての価値&体験の最大化
ペルソナの作成
- エブリスタではふたつのペルソナを設定している
- データ&調査ベースのペルソナ
- プラグマティックペルソナ(チーム認識用)
- ペルソナ作成時の大切なポイント
- どのような判断をする人なのか可視化する
- 利用のゴールは何であるのかを明確にする
- ユーザー行動の軸(チームの共通認識)をつくる
ジャーニーマップの作成
- 作成プロセス
- フェーズを分ける
- 行動を出し、グルーピングする
- ユーザーの思考(thinking)
- ユーザーの感情(feeling)
- positiveもnegativeも出し尽くす!
- positiveをいかに高めるか/negativeをいかに抑えるかを考え、ユーザーのエンゲージメントを高めるため
- 課題や重要ポイントをまとめる
- 作成時の注意点
- ペルソナの視点で書き出す
- 願望や個人の意見で書かない
- 行動に対するハードルの高低を意識する
- 施策の重要度/優先度を見分けるため
ユーザーシナリオの作成
- ジャーニーマップの時系列順にシナリオ化
- 「○○として▼▼したい(できる)。なぜなら□□だからだ。」
- ユーザーとしてFacebook認証したい。なぜなら登録がカンタンだからだ、とかとか
- 「○○として▼▼したい(できる)。なぜなら□□だからだ。」
- シナリオの効果を見積もる
- 定性&定量データや主要KPIから判断
- 優先順位を決定する
- 提供機能を決定する
- シナリオのゴールを明確にする
- 実施可否判断
仮説の設定とUI/UX
- 例:投稿機能改修の設計方法
- 課題
- ex.「ユーザーとしてカンタンに投稿したい。なぜなら入力が難しいと挫折するから」
- 課題から仮説の設計
- 何が難しいと感じるのか?
- ex.「入力項目が投稿後にどこに表示されるかわからない」
- ユーザーにとってカンタンとはなにか?
- ex.「見たことのあるUIに近いほうが直感的である」
- エラーはあるか
- ex.「下書き保存したいのに入力中はキーボードがじゃまでできない」
- 何が難しいと感じるのか?
- ペルソナやジャーニーマップを用いて仮説を作り上げる
- ex. 仮説:「読書画面に近いUIを採用してみる」
- テスト/現状分析を行う
リリース&分析
- ユーザー認識をブラッシュアップする
- 継続的に定性&定量分析を行う
- → ユーザーを可視化するための仮説を検証し、ペルソナ&ジャーニーマップを修正する
- アダプティブなPDCAを行う
- 変化を常に受け入れる
- ユーザーシナリオを常に見直す
- テストまでの一連の流れを高速化する:チームの共通認識をつくっていくことで、無駄をなくす
まとめ
- ユーザー感情の最大化からものを考える
- ユーザーを理解するための仮説&検証を行う
- ユーザーにとっての高い価値発見に注力する
- 変化に素早く対応する
パネルディスカッション
- (会場質問)グロースハックがなかなかうまくいかず、答えが見つからない時にはどうしたら良いでしょうか
- (梶谷)二点あると思っていて、ひとつは、そもそもいまいるフェーズが正しいかを疑って、上流に遡るべきかを検証すること。もうひとつは、とにかくユーザーと話すこと。数字が伸びない時に社内で話しても突破口はなかなか見つからないので、ユーザーと話すことが大切
- (会場質問)ニーズの検証について、具体的な方法はどういうものがあるのか
- (梶谷)今回話したJavelin Boardはまさにそれかなと思う。ここで「だれが」「なにを」「どうやって」のいずれもがズレていないことが、ニーズがあるということだと思います
- (会場質問)今回、それぞれがそれぞれの話を聞いて、どう思ったか(うちとは違うなとか)を伺いたいです
- (石山)DeNA真崎さんの話を聞いていて、組織的な体力があるんだなあと感じました。プロセスがしっかりしている印象
- (梶谷)うちはスタートアップなので石山さんの話はわりと近いなあと思いましたが、逆に真崎さんとは結構異なっているなと感じました。真崎さんの丁寧なUX設計プロセスの話を聞いて、今回その重要性に気付かされたので、実際にやってみたいと思いました
- (真崎)DeNAのプロセスは小難しくいろいろやっているように見えたかもしれませんが、私としてはVASILYさんとシロクさんお話のほうが、ロジカルなところや進捗が分かりやすいところをしっかりやっているという印象を受けました。「それって需要がないんじゃない?」というような根本的な課題が少なそうというか。そこがうらやましいなと思いました。ちなみにうちは、会社全体としては体力はあると思うが、実際のチームの規模感としてはそんなに違いはないのかなと思います
(会場質問)定性調査のためにユーザーを集めてくるにあたって、どんな観点でユーザーを集めてくるのか、また、ユーザーインタビューの時に気をつけていることはなにかをお聞きしたいです
(石山)My365の開発時は、Prottみたいなモックアップツールはないような時だったので、実際のプロダクトを渡してテストをするというスタイルでした。テスターを集めるときにはローンチコミュニティをつくったりして、そこに50名ほどが集まったのでそこへアプローチするかたちになりました。インタビューの時に気をつけていた点は、「未来形で質問しないこと」。仮定の話はしないで、今手にしているプロダクトについて実際に使うかどうかを判断してもらう、ということが大事だと思っています
- (梶谷)選定のところでいうと、二つのフェーズがあると思います。ひとつめは、まだプロダクトがない時。この時はざっくりとした区切りで(それこそ○○な大学生とかのざっくりした属性で切り出したりして)いいので聞いちゃう。ふたつめはプロダクトがあって、ユーザーがいる状態。この場合たとえばVASILYでは、「iQonがもし百人の村だったら」という仮定でベン図を作ってみて、どんなタイプのユーザーが多いかをというのを可視化してたりしている。そしてそのなかのマジョリティからユーザーをピックアップするようにしています。実際のインタビューの場面で気をつけていることとしては、ちゃんと台本をつくるということと、リハーサルをきちんとするということ。そうしないと、その時々の聞き方によって答えが変わってしまって、後からまとめられなくなってしまうので。あとは、未来のことをちゃんと聞くこと。過去にどういうことで困ったのか、どうやって解決しようとしたのか、を聞いています(ちなみにそこで解決しようとしていなければほんとは困っていないと言えます)。インタビュー手法に関してはこの他にもいろんなポイントがあるので、勉強していいなと思ったものをかたっぱしから試したりしています。
- (真崎)チラシルのときは、2週間のアルバイトで主婦を雇う、みたいなことをやっていたりしましたね。インタビューの場で気をつけていることとしては、「事実を聞く」ようにするということです。表面的なところではなく、その深層の意図(精神的なところとか)を聞くようにしています
- (会場質問)メディア系やコミュニティ系のアプリだと継続的に使うものになるので指標を追いやすいのかなと思うのですが、toB系のツールのようなユーザーが毎日使わないようなアプリではどうしたらいいと考えますか
- (石山)うちのスタンスとしては、継続性がないものはあまり追わなくていいんじゃないかというのもありますが……。一度しか来ていないという人に対しても、しばらく立ってもう一度DMをだすとか、そういった施策は打てるかなと思う。やりようはいろいろあると思うので、後ほどお話できればと…
- (会場質問)会社のビジョンとサービスのコンセプトがずれたりした場合は、どう修正していけばいいのでしょうか
- (梶谷)おそらくサービスのコンセプトやニーズをピボットをしても、ビジョンレベルでズレることはそうないかなと思うのですが、そこからズレるとしたら、対応は二つ考えられると思います。ひとつは、ビジョンが狭すぎるということなのでビジョンを拡張する。あるいは、ビジョンそのものをピボットする。大体は前者でなんとかなると思いますが…
- (会場質問)ビジョンを一番優先するということ?
- (梶谷)というより、一番優先すべきはサービスがユーザーに求められるものなのかどうかであると思います