成長し続けるサービスのユーザーオンボーディングを学ぼう

サービス・デジタルプロダクトに関わるプロダクトオーナーやUI/UXデザイナーの方は、ユーザーにとって使いやすいサービスにし、ユーザーが離脱しないように日々努力しています。使いやすいサービスにするためにユーザビリティを高めるのはもちろんですが、誰でも機能を初めて見たときに完璧に使いこなせるわけではありません。そこで必要になるのがオンボーディングの改善です。

スライド式でアプリを紹介するウォークスルーや新機能を指し示すコーチマークなどといったUIを用いて、ユーザーがサービス利用に慣れるまで導くプロセスのことをオンボーディングと呼びます。

オンボーディングは、新人研修という英語に由来し、人材育成用語としての意味もあります。オンボーディングを日本語でGoogle検索すると、人材育成の最初の段階として使われるものとして紹介されているものが多く見られます。

サービスデザイン・UX設計でのオンボーディングは、ユーザーオンボーディングとも呼ばれ「サービスやアプリの初回ユーザーが1回で離脱しないように利用設計するためのもの」と解説している記事が多く見られます。日本語の文章として間違ってはいないのですが、初回という認識を強く持ちすぎてしまう傾向があるようです。

最初のユーザー体験だけがオンボーディングではない

初回のユーザー体験の設計は「First Time User Experience ( FTUE )」と呼ばれ別用語として明確に扱われています。ユーザーオンボーディングがユーザーの初回の体験でないことの裏付けになります。定義をしっかり理解することがユーザーオンボーディングの本質の理解の第一歩です。

Googleでは、初回のみならず全体験においてオンボーディングを設計する必要があると言います。

長期的なユーザー教育プロセス＝ユーザーオンボーディング

ユーザーオンボーディングは、ユーザーにサービスを理解してもらう「ユーザー教育」のプロセスと切って離せない関係で、「初回のユーザーに限らず、すでにサービスに定着しているユーザーに対しても長期的に繰り返し行う」という考え方です。

ユーザーオンボーディングとユーザー教育は繰り返される図
引用元: Building onboarding for long-term guidance

オンボーディングの専門家であるGoogleのシニアUXデザイナー、クリスタル・ヒギンズのブログでは、継続して行うオンボーディングをマラソンに例えて、以下のように設計の心構えを紹介しています。

オンボーディングは、短距離走ではなくマラソン

多くのチームは、チュートリアルや入門用のスライドショーだけをオンボーディングのデザインとしてしまいます。
初回のチュートリアルだけをオンボーディングとしてしまうと、ユーザーが途中で迷い、ガイダンスが必要な時の設計を見落としてしまう可能性があります。

そのため、オンボーディング設計は、カスタマージャーニーの中の他の瞬間（継続的な新機能追加、大幅なリニューアル、離脱からの復帰など）に対しても適応する必要があります。

クリスタル・ヒギンズ

Marathon, not a sprint

Many teams call onboarding complete once you’ve designed a tutorial or introductory slideshow. But when you limit onboarding to first run, you shortchange users that could benefit from similar guidance at other times in their experience. Instead, extend your initial onboarding philosophy and techniques to other moments in the customer journey like continued discovery, major redesigns, and returning from a lapse.

翻訳・引用: From first run to the long run | Kristal Higgins

表面だけを真似ても間違ってしまう

ユーザーオンボーディングの定義を勉強・理解して実践している人はまだまだ少ない状況です。そんな状態で、他社製品のオンボーディングの表面だけ真似て作ってもオンボーディングの効果は発揮しません。つまり、意味がありません。

例えば、以下の様なスライド形式の説明表示を見かけますが、不適切な部分があります。

（参照元：First time user experiences in mobile apps）

このアプリは日本でも話題になったClearというTodoアプリです。最初にアプリを起動すると、ウォークスルーで操作説明が7画面もでてきます。その7画面のうち、2つは特に説明をしていない画面で省いても問題がありません。スライドでの操作説明も冗長であるにも関わらず、スキップする方法がありません。

オンボーディング設計の基本原則には、「簡潔に伝える」「ユーザーの自分のペースで学習できること」などがあり、沿っていないことが理解できます。このように、基本の原則を知ることでオンボーディングの改善点を見分けることができるようになります。

オンボーディングの不適切な点

触って試せるサンプルリストで学習させる

Clearアプリのオンボーディングは、悪いところばかりではありません。ウォークスルーの後に良い初回ユーザー体験(FTUE)の「サンプルTodoリスト」が実装されています。

サンプルのTodoリストに、どの操作ができるかが書いてあるので、どんな操作ができるか、その操作で何が起きるかを、ユーザーは自分のペースで操作をして体験して理解することができます。

画期的な操作性や気持ち良いインタラクションは、説明されるよりも実際に触ってみるほうが直感的に良さが理解できます。実際のUIを操作し、操作に対するフィードバックを体験して理解できる点が、マニュアル説明のようだったウォークスルーの説明より優れています。

「この機能をユーザーに伝えるにはどんな方法が最適か？」という視点で捉えられるようになると、説明コンテンツを見てもらう方法にとらわれず、視野を広げてユーザーを教育する方法を考えることができるようになります。

ライブラリに頼った実装だけではダメ

日本でも、チュートリアル・ツールチップやオーバーレイを簡単に実装できるオンボーディングに特化しているライブラリやツールが人気です。

オンボーディングライブラリの例
引用: AlertOnboarding

しかし、ライブラリやツールを導入しているから大丈夫、ということもありません。
ライブラリは見栄えが良いオンボーディングがすぐに実装できる利点がありますが、自分たちでオンボーディング設計の考えを持たずに頼ってしまうのは危険です。ライブラリありきの設計や改善に視野が狭まり、適切なオンボーディングは設計できません。

ウザくないオンボーディングにするには？

オンボーディングで「何を、どんなタイミングで、どうやってユーザーに伝えるか？」は、多くの人が設計で悩むポイントです。

サービスの提供企業としては、サービスを理解してもらいたいので、たくさん説明したくなってしまいますが、ユーザーの気持ちを考えない過剰なオンボーディングは「ウザい」と思われ離脱に繋がってしまいます。

そこで、オンボーディング対象の見極めと優先順位づけをする必要があります。
サービス利用体験の中でも継続ユーザーと離脱ユーザーを分ける重要な行動を「キーアクション(Key Action)」と言います。
キーアクションがどこにあるかを、ユーザー体験の中で特定し、マッピングをすることで迷ったユーザーにそっと手を差し伸べて導く、気が利いたオンボーディングの計画が立てられるようになります。