SaaSオンボーディングのデザイン思考——Aha momentを設計する実務

SaaSプロダクトのオンボーディング改善プロジェクトに呼ばれたとき、最初に見せてもらうのは大抵「ドロップオフ率のグラフ」です。サインアップから7日後の継続率が20%を切っている。30日後にはさらに半減している。この数値を改善したい——という依頼です。

ここで多くのチームが陥るのが、データと睨み合って「ステップ3で離脱が多いからボタンの色を変えよう」という表層的な施策に飛びつくことです。ドロップオフ率はどこで問題が起きているかを教えてくれますが、なぜそこで離脱するかは教えてくれません。

デザイン思考が威力を発揮するのはここです。オンボーディング設計の問題を「UXの最適化」ではなく「共感とプロトタイピングの課題」として捉え直すと、施策の方向が根本から変わります。

Aha moment の共感マップ

ワークショップで「あなたのプロダクトのAha momentはいつですか」と聞くと、多くのPMが「○○機能を使ったとき」と機能の名前を答えます。これはAha momentを「機能の到達点」として定義しているPM側の視点であり、ユーザーの体験視点ではありません。

実際にやってみると分かるのですが、Aha momentはユーザーの「感情」であり「文脈」です。共感マップを使ってAha momentを定義し直す作業では、4象限のなかに「価値を実感した瞬間の体験」を配置します。「考えていること」の象限に入るのは「これ、いまの自分のチームでも使えるかも」という接続の瞬間であり、「感じていること」の象限に入るのは「あ、これがやりたかったことだ」という発見の感情です。

Figma の場合、「デザインを作れた瞬間」より「チームと共有してフィードバックを受けた瞬間」の方が価値の実感に近い。Figma がオンボーディングでコラボレーション機能の早期体験を促す設計をとっているのは、この洞察を裏付けています。

Time to Value という共感軸の定量化

SaaSオンボーディングの文脈では「Time to Value（TtV）」が共感軸を定量化する有力な指標です。TtVは「サインアップからAha momentに到達するまでの時間」として定義されます。

注意が必要なのは、TtVを計算するには「Aha momentをどのイベントで定義するか」が先に決まっていなければならないことです。行動ログで計測できるイベントをAha momentのプロキシとして使うことが多いですが、それが本当に「価値の実感」に対応しているかは共感調査で検証する必要があります。

実際にやってみると、インタビューで「どの瞬間に『使い続けよう』と思いましたか」と聞くと、行動ログのどのイベントにも対応しない「隙間の体験」が出てきます。「同僚に見せたら反応が良かったとき」「既存ツールからデータを移せたとき」など、計測されていない文脈の中にAha momentが隠れている。TtVの設計はこの共感調査と組み合わせて初めて意味を持ちます。

Activation funnel の failure points を掘る

ワークショップで使うフレームは「failure points インタビュー」です。直近でオンボーディングを体験したユーザー（継続者・離脱者の両方）に対して、各ステップの体験を時系列で再構築するインタビューを行います。聞き方は「そのとき、頭の中で何を考えていましたか」という認知的な問いです。

参加者からの声として多いのは、「何をするかは分かった。でも、なぜこれをするかが分からなかった」というものです。Activation funnelの各ステップには「技術的な操作のハードル」と「文脈理解のハードル」の2種類があります。後者は画面設計だけでは解けません。

Notion のオンボーディングが「テンプレートギャラリーから始める」設計をとっているのは、文脈理解のハードルを下げる戦略です。一方 Linear はツールの説明に時間をかけず、すぐに「最初のIssueを作る」ところに誘導します。操作を通じて体験させることで「やっていることの意味」を後から理解させる設計です。「先に文脈を与える（Notion型）」か「先に体験を与える（Linear型）」かは、プロダクトの複雑性とターゲットユーザーのリテラシーによって変わります。

プロトタイピング：3層の検証アプローチ

SaaSオンボーディングのプロトタイプは3つの層で検証します。

第1層：テンプレート選択フロー。サインアップ直後の分岐設計は、低忠実度のペーパープロトタイプから始められます。印刷した画面フローを前にユーザーを座らせ、「今どこにいるか分かりますか」「次に何をするか想像できますか」を口頭で確認します。

第2層：ツールチップの文言と配置。ツールチップは「説明」ではなく「行動促進」でなければなりません。「このボタンを押すと○○できます」より「まず○○してみましょう」という行動指示型の文言の方が次のアクション率を高めます。FigmaやMarvelのインタラクティブモックアップで思考発話法を使って検証します。

第3層：インタラクティブツアーの長さ。Slack がオンボーディングツアーをほぼ廃止して「使い始めれば分かる」設計に移行したのは、コア体験（メッセージを送る）が直感的に理解できるためです。複雑な設定が必要なプロダクトでは、ツアーよりチェックリスト型の「達成感設計」の方が機能することがあります。

Appcues、Pendo、WalkMeといったツールを使ってA/Bテストを設計するとき、テスト設計の前に「何を検証したいか」の仮説を共感調査から立てることが重要です。ユーザーの認知的なハードルを解消するための実験として設計する。この順序が守られないと、表面的な数値改善が積み重なるだけで根本的な離脱原因は解決されません。

やってみよう：オンボーディング共感調査の設計

最初のステップは「サインアップ後7日以内に離脱したユーザー3〜5名へのインタビュー」です。インタビューの核心の問いは「サインアップしてから、プロダクトを使うのをやめた日まで、何をしていたかを教えてください」です。時系列の再構築を依頼し、各ステップで「そのとき何を考えていたか」「何が期待通りでなかったか」を掘ります。

この調査で最も重要なのは、「何を改善すれば良いか」をユーザーに聞かないことです。彼らが持っているのは「体験の記憶」と「そのときの感情」です。その記憶を引き出すことがデザイン思考の共感フェーズであり、「Activation funnelのどこにどんな認知的ハードルがあるか」を分析するのが定義フェーズの仕事です。

数値が教えてくれるのは「どこで」です。ユーザーが教えてくれるのは「なぜ」です。この両方がそろって初めて、オンボーディング設計のプロトタイピングが意味を持ちます。

---

参考文献

• Lincoln Murphy, Customer Success: How Innovative Companies Are Reducing Churn and Growing Recurring Revenue, Wiley, 2016
• Tim Brown, Change by Design, HarperBusiness, 2009
• Slack, “The Story Behind Slack’s Rebranding”, slack.com/blog（公開情報）
• Figma, “How Figma’s collaborative design changed the industry”, figma.com（公開情報）
• Notion, “Our Template Gallery”, notion.so/templates（公開情報）
• Appcues, “User Onboarding Academy”, appcues.com（公開情報）