Intersection（機能の交差点）を棚卸ししてみる
新しい機能をリリースしたけど、思ったより使われない。
こういうときにまず考えるのが、
「そもそも新機能があることを知らないのでは？」
ということだと思います。
じゃあガイド(案内)を出してみよう。
それでも使われない。
じゃあもう一回出してみよう。ダメ押しでもう一回！
気づいたらログインするたびに何かしらガイドが出てきて、ユーザーからすると、
「最近このアプリ、なんかうるさいな」みたいな状態になります。
これ、みなさんが通るあるある話だと思います。
Pendoにはガイドを使ってアプリ内でユーザーに直接メッセージを出せる機能があります。便利なんですが、当然ながら出せば出すほど良いわけではありません。
むしろガイドを増やす前に、
「その新機能に自然にたどり着ける導線って、そもそもあるんだっけ？」
を考えたほうがいいんじゃないか、というのが今回の話です。
なぜガイドを増やしても機能利用率が伸びないのか
よくあるパターンを考えると、だいたい3つあります。
全員に出している
その機能を必要としていない人にも同じガイドを出してしまうケースです。
当然ですが、その人にとってはどれだけ素晴らしい新機能でもただの邪魔です。
ログイン直後に出している
これもよくあります。アプリを開いた瞬間に、
「新機能が登場しました！」と言われても、ユーザーは今から自分の作業をしようとしているわけで、
まだ何もしていないので、その新機能が自分に必要なのか判断する材料もモチベもありません。
反応がないからもう一回出す
そして使われないので、また出す→さらに出す
これを繰り返すと、いわゆるガイド疲れが起きます。
面白いことにPendoでも、こういう状態をover-guidance（過剰ガイド）として扱っています。
レイジクリックなどと同じように、ユーザーのフラストレーションを見るための指標のひとつです。
つまりガイドはユーザー体験を改善するための機能なんですが、使いすぎるとガイドそのものがユーザー体験を悪くするわけです。
そこで少し考え方を変えてみます。
「新機能をどうやって知らせるか？」
ではなく、「ユーザーが今やっている作業のどこに、この新機能を入れられるか？」を考えてみます。
特に、完全に新しい体験を作る機能ではなく、既存の作業を便利にするタイプの機能ではこの考え方がかなり重要です。
ユーザーがすでに通っている導線の途中に新機能を置ければ、そもそも大々的に告知する必要がなくなるからです。
Intersectionという考え方
Pendo社内にはIntersectionsというカタログがあります。
Intersectionは日本語にすると「交差点」です。機能Aを使っている途中で、機能Bにつながる場所。
これをIntersectionと呼んでいます。
たとえば、Pendoでは、以下の導線があります：
-
ファネルレポートを見ていて離脱している場所を見つける
-
そこから離脱したユーザーのセッションリプレイを開く
-
実際にユーザーが何をしていたのか確認する
ファネルとSession Replayという別々の機能がありますが、この2つがつながっている。
これがIntersectionです。
1つのIntersectionについて、
-
名前
-
何ができるか
-
画面の画像やGIF
-
ユーザーにとって何が嬉しいか
-
担当PM
-
いつ追加されたか
くらいをまとめています。
ポイントは、機能単体ではなく「機能と機能のつながり」を管理していることです。
普通プロダクトの機能一覧を作ると、
-
ダッシュボード
-
ファネル
-
セッションリプレイ
-
ガイド
-
NPS
みたいになります。
でも実際にユーザーが作業をするときは、ひとつの機能だけを使って終わるとは限りません。
ファネルで問題を見つけて、リプレイを見て、セグメントを作って、そのユーザーにガイドを出す。
ユーザーからすると全部ひとつの流れです。
なので、機能一覧だけを見るのではなく、
「この機能から次にどこへ行けるんだっけ？」
も見たほうが良いという考え方です。
Intersectionにはいくつか種類がある
整理してみると、大きく3つに分けられると思います。
1. 埋め込み型
埋め込み型は、別の機能に移動しなくても、今いる画面の中で必要な情報まで見られるようにするパターンです。
たとえばファネルレポートを見ているときに、
このステップで離脱したユーザーの一覧
がその画面の中に表示されていたら、わざわざ別の機能を開く必要がありません。
ファネルを見ながら、そのまま「誰が離脱したのか」まで確認できます。
つまり埋め込み型は、本来は別の機能に見に行く情報を、今いる画面に持ってくる考え方です。
2. 遷移型
次は、
今やっている作業の文脈を持ったまま別の機能へ遷移するタイプです。
先ほどの、ファネル → Session Replayはこれに該当します。
ここで重要なのが「コンテキストを持ったまま」というところです。
たとえばファネルで特定のステップから離脱している人を見つけてSession Replayに飛んだのに、遷移先でまた検索条件を全部入れ直さないといけない。
これだとあまり意味がありません。
ユーザーが設定した条件を引き継いだまま次の機能へ移動できることが重要です。
3. 推奨・自動型
ユーザーに探してもらうのではなく、
「次これ見たほうがいいですよ」とプロダクト側から案内を出すタイプです。
たとえば、
- 見るべきSession Replayを自動で出す
- よく使う分析をテンプレートに最初から入れる
- ファネルで離脱が多い場所を見つけたら、次に見るべきSession Replayをおすすめする
といったものです。
ユーザーは機能を探していません。
むしろ、存在を知らなくても使えます。
新機能の利用促進を考えると、
推奨・自動 → 埋め込み → 遷移
の順で、ユーザー側の負担が少なくなります。
逆に一番ユーザーに頑張ってもらわないといけないのが、
「新機能があります！クリックしてください！」という単発ガイドです。
じゃあガイドはいらないの？
もちろんそんなことはありません。
むしろここでガイドの使い方が変わってきます。
自分はガイドを、導線そのものではなく、導線の上に置く案内板と考えると分かりやすいと思っています。
まずプロダクトとして、
-
埋め込みできないか
-
自然に遷移できないか
-
推奨できないか
を考えます。
でも当然、全部プロダクト改修できるわけではありません。
開発には時間もかかります。そこでPendoガイドを使って、疑似的にIntersectionを作ることができます。
たとえば本当は画面上に新しいボタンを追加したい。
でも開発には3か月かかる。
だったら一度Pendo ガイドでボタンを置いてみて、本当にユーザーが押すのか試してみる。
使われるのであればプロダクト側に実装する。
使われないのであれば、そもそも作らなくていいかもしれません。
これ、ガイドの結構面白い使い方だと思います。
単なる告知ツールではなく、**「プロダクト改修前に導線を試すツール」**として使えます。
実際にどうやって考えるか
5ステップくらいに分解して考えてましょう。
Step 1. まず新機能を誰に使ってほしいのか決める
最初に、誰に使ってほしいのかを決めます。
これを決めないと、最終的に「全ユーザーにガイドを出そう」になりがちです。
さらに、何をしたら利用したことになるのかも決めます。
ここはできればイベント1個くらいまで具体的にします。
たとえば、「新機能の画面を開いた」ではなく、
「新機能を使って処理を完了した」です。これはファネルで測ることができます。
画面を開いただけでは、価値を得たか分かりません。
もうひとつ重要なのが分母です。たとえば1000人いるサービスで、新機能を使う可能性がある人が100人しかいないとします。
この機能を20人が使った場合、全ユーザーを分母にすると利用率2%。
でも対象ユーザーを分母にすると20%。全然違いますね。
なので「新機能の利用率」を見るときは、その機能を使う理由がある人を分母にするのが大事だと思います。
Step 2. ユーザーが今どこを通っているか見る
次に既存のユーザーフローを見ます。
ここは想像ではなく、せっかくなのでPendoのデータを使います。
パスレポートを見て、この画面に来る前って何してるんだろう？を見てみる。
ファネルレポートを見て、どこで諦めているんだろう？を見てみる。
機能利用率を見て、普段どの画面をよく触っているんだろう？を見る。
ざっくり言うと探したいのは2つです。
よく通る道 & 詰まっている場所です。
よく通る道には、新機能を埋め込めるかもしれません。
詰まっている場所には、新機能を「これ使ったら楽になりますよ」と出せるかもしれません。
Step 3. 新機能と既存機能を掛け合わせてみる
ここでIntersectionを考えます。
新機能を縦に並べて、既存の機能や画面を横に並べます。
そして、
この2つってつながらないかな？を考えてみます。
全部埋める必要はありません。むしろ全部埋まったら怪しさMAXです。
交差するところだけで大丈夫です。
候補が出てきたら、
-
埋め込み型
-
遷移型
-
推奨型
のどれなのか考えます。
さらに、
-
プロダクト側で実装する
-
Pendo ガイドで一旦試す
-
両方
も考えます。
そして一番重要なのが、
「その瞬間、ユーザーは本当にこの機能を欲しいのか？」 です。
たとえば、新機能として「レポートの自動配信」を追加したとします。
既存の画面と掛け合わせてみると、こんな感じにまとめられると思います。
| 既存の機能 / 画面 | ここで何ができそうか | 文脈適合度 |
|---|---|---|
| レポート作成画面 | 同じレポートを何度も作っている人に「これ、自動配信できます」と出す | 高 |
| レポート保存完了画面 | 保存後に「毎週このレポートを送る」を出す | 高 |
| ダッシュボード | レポートの横に「自動配信を設定」を常設する | 中 |
| CSVエクスポート完了画面 | 繰り返しエクスポートしている人に自動化を案内する | 高 |
| 設定画面 | 自動配信の設定メニューを追加する | 低 |
| ログイン直後 | 新機能として一律告知する | 低 |
こうやって並べてみると、同じ新機能でも出す場所によってかなり意味が変わることが分かります。
特に、「毎週CSVを出している人」 に 「それ、自動化できますよ」
と出すのと、
ログインした全員に 「自動レポート配信が追加されました！」 と出すのでは、同じ機能の告知でも文脈が全然違います。
Step 3で見つけたいのは、こういう交差点です。
Step 4. どこで何を言うか決める
交差点が見つかったら、誰に、いつ、何を見せるかを決めます。
ここでガイドの内容を考えてみます。
だいたい5パターンくらい？あるかなと思っています。
ガイドのメッセージは5パターンくらいで考える
A. 「それ、自動化できます」
ユーザーが何か面倒な作業を終えた直後に、今やった作業、自動化できますよと教えます。
たとえば毎週同じレポートを作っているユーザーに、このレポート、毎週自動で送れます
と出す。これは刺さりやすそうです。
なぜならユーザーがたった今その面倒くささを体験しているからです。
新機能の説明を長々とする必要もありません。
B. 「あなたの場合こうなっています」
これは、ユーザー自身の利用状況をもとに新機能を案内するパターンです。
たとえば、毎週同じ条件でレポートを作っているユーザーに、先月このレポートを何回も作成しています。自動配信にすると毎回作り直す必要がありません。と出してみます。
単に、自動レポート配信という新機能が追加されました
と伝えるのではなく、
「あなた、実際にこの作業を何度もやっていますよね」という事実とセットで見せてみるのです。
これならユーザーにとって、新機能が自分に関係あるものだとすぐ分かります。
ガイドというより、利用状況をもとにしたおすすめに近いですね。
C. 「ついでにこれもできます」
作業が終わったタイミングで次の行動を出します。
たとえばレポートを保存したあとに、このレポートをダッシュボードに追加と出す。
ここで大事なのは、作業中に邪魔しないことです。
ユーザーは今やっている仕事を終わらせたいので、途中で別の機能に誘導するとただの邪魔になります。
終わってから出す。
D. 「最初から案内の中に入れておく」
これは、新機能だけをあとから単発で告知するのではなく、既存のオンボーディングやチェックリストの中に最初から含めておくパターンです。
たとえば新しいユーザー向けに、
-
最初のレポートを作る
-
レポートを保存する
-
自動配信を設定する
というチェックリストを出しておきます。
こうしておけば、あとから
新機能「自動レポート配信」が追加されました！というガイドを別で出す必要がなくなります。
ユーザーからすると、自動配信は「あとから追加された知らない機能」ではなく、レポートを使い始めるときに覚える一連の操作のひとつになります。
特に新規ユーザーにはかなり使いやすい方法です。
既存ユーザーに対しては同じチェックリストを出すのではなく、レポートはもう使っていますね。次は自動配信も設定できます。Cの施策を打つことができます。
E. 「必要な場所に小さく置いておく」
これは、画面を大きく覆うガイドを出すのではなく、ユーザーが必要になったときに気づける小さな案内を置いておくパターンです。
たとえばレポート一覧の「自動配信」ボタンの横に、毎週同じレポートを作っている場合は、自動配信にできますという小さな案内(バッジやツールチップ)を置いておきます。
あるいは、自動配信がまだ1件も設定されていない画面で、まだ自動配信はありません。よく使うレポートを毎週自動で送ることができます。と表示して、設定画面へ案内します。
これの良いところは、ユーザーの作業を途中で止めないことです。
必要な人は気づける。必要のない人には、ほとんど邪魔にならない。
Step 4. 打つ前に計測方法を決める
ガイドを出したあとで、ところでこれ成功したんだっけ？
となることが結構あります。
なので先に決めておくとよいですね。
-
導線まで来た
-
反応した
-
初めて使った
-
もう一回使った
-
その後も使い続けている
くらいでいいと思います。
「ガイドをクリックした」だけで成功にしないことが大事です。
クリックしたけど使わなかったかもしれません。
逆にクリック率が低くても、クリックした人がその後ずっと使っているなら意味のある施策だった可能性があります。
Pendoレポートを活用するなら：
| ステージ | 見たいこと | 例 |
|---|---|---|
| 露出 | Intersection入り口まで来たか | ページ / ガイド閲覧 |
| 反応 | 興味を持ったか | ガイド CTA押下率 |
| 初回利用 | 初めて価値を得たか | ガイドゴール/First time to use |
| 再利用 | もう一度使ったか | ファネル / 利用定着度 |
| 定着 | 継続しているか | (機能)リテンション |
| 副作用 | 邪魔してないか | 離脱、Rage Click、Over-guidance |
ガイドを出しすぎないためのルール
ここまで色々書きましたが、これが一番重要です。
ガイドは簡単に作れるので、ルールがないと増えます。本当に増えます。
＊（ひと昔前の弊社のサブスクではガイドが無限に増えていました。。。ガイド増えすぎ問題をどうやって解決したか社内ガバナンスの観点でご興味ある方はこちらの記事もぜひご一読ください！
閑話休題：
なので最初にルールを決めてしまいます。
1画面にひとつまで
同じ画面でキャンペーンが3個走っていて
バナーが出て、
Tooltipが出て、
さらに「新機能があります！」
みたいになると私だったら邪魔に感じます。
優先順位を決めて、ひとつだけ出します。
一度見た人には何度も出さない
特に使った人にはもう出さなくていいです。
「この便利な機能使ってみませんか？」
と言われて、昨日使ったよとなった思われた瞬間、プロダクトが急に頭悪く見えます。
ガイドの閲覧有無や新機能利用済みを条件にして除外します。
ログイン時に全員へ出すのをなるべくやめる
もちろん大規模障害や重要なお知らせなど、全員に出すべきものもあります。
でも新機能の利用促進で、全ユーザー × ログイン直後ではなく、基本的には何かしら行動条件をつけたほうがいいと思います。
同時に走らせすぎない
自分なら3つくらいまでにします。
施策が多いとユーザーがうるさいだけではなく、どの施策が効いたのかも分からなくなります。
成功指標だけじゃなく副作用も見る
新機能利用率が10%上がった。いいね！
でも同じ画面の離脱率が20%上がっていたら、それはちょっと考えなおさないといけません。
施策のKPIとフラストレーション指標を同じ定点観測事項と置くのがおすすめです。
「使わなかった人」を見る
使った人だけではなく、使わなかった人を見ることです。
たとえば新機能へのGuideを表示した。
でもクリックしなかった。
その人に1問だけ聞いてみます。
なぜ使いませんでしたか？
-
必要ない
-
今やる時間がない
-
何ができるか分からない
-
今のやり方で困っていない
これだけでも次の打ち手がかなり変わります。
認知の問題なのか。
価値の問題なのか。
タイミングの問題なのか。
同じ「使われていない」でも、理由によって打ち手は全然変わります。
定量データだけを見ていると全部同じに見えてしまうので、Pendoの分析だけではなく、アンケートを使って定性データも一緒に見てみます。
ただ、当然アンケートに答えてくれない人もいます。
それでも分からなければ、Session Replayなどで実際の行動を見る。
それでもわからなければそんなときは、直接にユーザーにインタビューしてみる。
まずは機能の交差点を洗い出してみる
ここまで色々書きましたが、最初からプロダクト全体のIntersectionを全部整理する必要はありません。
まずは、今まさに利用を増やしたい新機能を1つだけ選んで試してみるくらいでいいと思います。
その新機能について、
-
誰に使ってほしいのか
-
何をしたら「使った」とするのか
-
その人たちは普段どの画面を通っているのか
-
どのタイミングなら新機能が役に立ちそうか
を見ていきます。
そこからIntersectionの候補をいくつか出して、
- この作業の直後なら便利そう
- この画面なら自然に案内できそう
という場所を探します。
全部やる必要はありません。まずは一番文脈が合っていそうなものを1つか2つ試して、実際に利用率が変わるか見ます。
そして、
-
使われた
-
使われなかった
-
逆に邪魔になった
を確認して、次のIntersectionを考えてみる。
この繰り返しで十分だと思います。
大事なのは、ガイドを何本作ったかではなく、どのタイミングならユーザーが自然に次の機能へ進めるのかを少しずつ見つけていくことです。
そうやって整理していくと、結果的に自分たちのプロダクトの「機能と機能がどうつながっているか」という地図もできてきます。
まとめ
新機能が使われないと、
認知されてない → ガイドを出そう
と考えがちです。
でも実際には、そもそもその機能へ自然にたどり着く道がないだけかもしれません。
なのでガイドを増やす前に、
-
ユーザーが普段どこを通っているか見る
-
新機能とのIntersectionを探す
-
埋め込み・遷移・推奨で解決できないか考える
-
すぐプロダクト改修できなければPendo Guideで試す
-
効果だけではなく副作用も見る
という順番で考えてみると良いと思います。
Pendoのガイドは「新機能のお知らせを出す機能」として使うこともできます。
でも個人的には、プロダクトを改修する前に、新しい導線を実験するための道具として使うほうがずっと面白いと思っています。
ガイドをたくさん作ることが目的ではありません。
最終的には、ガイドがなくてもユーザーが自然に次の機能へ進める状態を作れたほうがいいです。
ガイドは、その状態を作るまでの案内板だったり、導線を試すための実験だったりします。
なので、新機能が使われないときに最初に考えるのは、
「どんなガイドを出そう？」ではなく、
「ユーザーが今やっていることと、この機能はどこで交わるんだろう？」なのかもしれません。
「良いガイドを作るより、ガイドがいらなくなる導線を作る。」