チュートリアルだけでは終わらない、7つのアプリオンボーディング施策
これまでアプリのデザインを行っていく中で様々なアプリオンボーディング施策を検討してきました。今回は、それらのオンボーディング施策を7種類に分類して紹介します。また、ユーザーの学習を支援するという意味合いではメタファーを利用したりすることも効果的ではありますが、今回はより具体的なサポートの手段について紹介します。より抽象的な考え方の部分は「使いやすい」を作るための4つのアプローチの記事の中で紹介しているので、ぜひ合わせて読んでいただけると嬉しいです。
また、このオンボーディング施策を考える際に以下の記事を参考にさせていただきました。
目次
オンボーディングとはアプリ起動時のチュートリアルだけではない
一般的に、アプリサービスにおける”オンボーディング”とは、アプリ起動時のウォークスルーやチュートリアルを指すことが多いと思います。しかしそれだけで本当にユーザーはサービスにオンボーディングされるのでしょうか？
『「使いやすい」を作るための4つのアプローチ』でも紹介していますが、サービスを利用するユーザーの中に”サービス初心者”のままでいたい人はほぼ存在せず、基本的には「もっと上手に道具を使い倒したい」という欲求を全てのユーザーが持っています。その観点でいえば、アプリ起動時に一連の流れを説明するだけではなく、さらに多くの場面で、初心者脱却を目指すユーザーをサポート・育成するようなスタンスを持つ必要があると考えています。この考え方を意識するために、この記事の中ではあえて“中長期オンボーディング”と呼びたいと思います。
中長期オンボーディングというと新しい概念のように思えますが、実際はこれまでもアプリ上で表現されてきた要素を学習という概念で再解釈してる部分が多いです。例えば後述するエンプティやレコメンドも要素としては全く新しくはありません。しかし、エンプティであればあくまでUIの状態の1つという文脈で利用されることが多いですし、レコメンドはサービス側の押し付けのような形で表現されることが多いのが現状であり、ユーザーの育成という観点で構成されているものは世の中には少ないと思っています。そのため、今回はこれまでも一般的だった要素を「ユーザーの中長期的学習を支援する」という概念の上で再解釈した上で整理してみました。
中長期オンボーディングに存在する、3カテゴリ・7パターンの施策
中長期オンボーディングは「サポートする役割」という観点と、「サポート対象のユースケースが必須か任意か」という観点によって分類され、合計で3つのカテゴリと7つのパターンが存在すると考えています。
「サポートする役割」とは、オンボーディング施策を実施することでユーザーのどんな行動をサポートするのかという観点です。大きく3つに分けることができ、サービスの流れの理解をサポートする「ユーザーフローの理解」と、次に行う行動をサポートする「ネクストアクションの理解」と、現状のステータスの理解をサポートする「現状の理解」の3つのカテゴリに分かれます。この3つのカテゴリと、「サポート対象のユースケースが必須か任意か」の組み合わせによって中長期オンボーディング施策を7パターンに分けて考えることができます。ちなみに、「ユーザーの行動が(ほぼ)必須」と記載しているのは、”ユーザーの行動は基本的に任意という大前提ではあるがそのサービスを利用するとしたら大体直面するユースケース”のような意味を含んでいます。
それでは実際にユーザーの中長期的学習を支援するパターンを1つずつ解説していきます。
カテゴリ1：ユーザーフローの理解
パターン1. ユーザーフローの提示
サービスの使い始めやユーザーフローが大きく分岐するようなタイミングで、ユーザーが「このアプリでできること」や「このモードで行えること」など、アプリ利用の流れがある程度わかるようにサポートするパターンです。
このパターンは主にアプリ起動時のウォーウスルーやチュートリアルなどが挙げられますが、他にも様々なシーンで活用できると思っています。例えば予約系のサービスであれば、何かの予約を行ったあとに実際にその体験を受けるまでの流れを提示する必要があるかもしれません。他にもゲームを始める前に簡単モードと激ムズモードが用意されているなら（そしてその選択が不可逆であるなら）、ある程度まとまった情報量で簡単モードと激ムズモードを説明する必要がありそうです。
UIの形式としては、ある程度まとまったユーザーフローの流れを説明することがある関係上、スライドのような形式が世の中的には多く見られます。そのような形式でも良いと思いますが、ユーザーの選択が可逆的であったり説明が少量で終わるのであれば、よりユーザーの行動を制限しない形でサポートするのが良いでしょう。
また、アプリ起動時のウォークスルーに限っては、基本的にはなるべく最小化すべきだと考えています。ユーザーは大抵の場合はどこかでアプリの情報を得て、ストアでアプリをダウンロードしたうえでアプリを起動しています。そういった工程をわざわざ辿ってアプリをダウンロードしてくれているので、このアプリで何ができるかは重々理解しているはず。なので、あらためてアプリ説明を行う必要は実はあまり無いと考えています。
ただし、一度アプリをダウンロードしたがしばらく開かなかったようなユーザーに対してはある程度効果的だとは考えています。そのユーザーをフォローしたい場合は、ウォークスルーの導線だけ用意しておいて、ほとんどのユーザーは見なくて良いような設計にしておくと良いでしょう。
カテゴリ2：ネクストアクションの理解
ユーザーが次に行う行動をサポートするようなもので、4つのパターンが存在している。
パターン2.許諾説明
このパターンは、アプリ上で利用したい通知権限や位置情報権限などを提示するときに、「何の権限を求めているのか」と「その権限を許可すると、どんな良いことがあるのか」を説明してユーザーの「判断」というネクストアクションをサポートするパターンです。
基本的に、なにかしらの権限をユーザーに求めるときに何の説明もないままいきなりダイアログを示すのは悪手です。例えば位置情報の必要性がわからないままいきなり位置情報の許諾を求めるダイアログが出てきたらかなり怖い気持ちになるのではないでしょうか。それらを避けるために、「何の権限を求めているのか」「その権限を許可すると、どんな良いことがあるのか」を説明し、ユーザーのネクストアクションをサポートした方が良いでしょう。具体的には、例えば位置情報の権限を求める場合はいきなりダイアログを出すのではなく、「位置情報の権限を許可することで現在地周辺の施設が検索できるようになります」というような説明を1ステップ挟むことが良いと思われます。
また、権限を拒否した場合のサポートも忘れずに実施したい。権限を拒否した場合に何の説明もなく「この機能は使えません」というような形ではなく、「この機能を利用するには位置情報の権限を許可してください」というような説明が入ると、ユーザーがその機能をまた使いたくなったときのアクションをサポートすることができます。UIの形式としては、許諾が必要な画面でエンプティと似た形式で表示するなどがユーザーの行動を制限せずに目的達成できると思われます。
パターン3.エンプティ誘導
このパターンは、コンテンツがエンプティのときに「コンテンツがエンプティであること」と「エンプティを解消するためのアクション」を示し、ネクストアクションをサポートするパターンです。例えばSNSの場合、誰もフォローをしていなかった場合はタイムラインに何もコンテンツが流れませんが、「コンテンツはありません」とだけ表示されていてもユーザーはどうすればコンテンツが見れるのかわからずに困ってしまいます。そのような事態を避けるために、「コンテンツはまだありません。他のユーザーをフォローしてみましょう！」などといった説明と導線を含めると、ユーザーがネクストアクションに迷わず行動できるようになると思います。わざわざそのコンテンツに来訪してくれたユーザーのために、ネクストアクションまでしっかりサポートしましょう。
UIの形式としては、エンプティの画面で説明文と導線があるような形式が多くなっています。
パターン4.レコメンド
このパターンは、ユーザーが今体験しているユースケース上で、追加で実施した方がユーザーメリットが高まるようなケースをサポートするパターンです。例えば、飲食店を予約したときにそのお店をお気に入りに登録しておくと次回以降の予約がスムーズになるようなケースがあると思います。このような場合にお気に入り登録をおすすめするようなパターンになります。
レコメンドはアクションは多くのサービスに見受けられるが、ほとんど場合はポップアップのようなユーザーの行動を制限する形で示しているケースが多いです。しかし多くの場合、ユーザーのコンテキストに直接関係のない情報が一方的に表示されていることが多く、多くのユーザーは自分の行動を制限されてまでほしい情報ではない可能性が高いです。
ユーザーは「初心者に留まりたいと思っていない」という考え方にのっとり、あくまでユーザーのコンテキストに合わせた形でサポートに徹するのが良いでしょう。具体的には、こちらの記事で紹介されているようなモジュール型の形式などでユーザーの行動にそっと添えるような形が良いと思います。「レコメンドは添えるだけ」を合言葉にしましょう。
画像出典： https://note.com/fmkpro1984/n/nbfcf7c63ba93#sy70C
パターン5.機能説明
ユーザーが今体験しているユースケースから他のユースケースに接続することも可能なときに、その選択肢を紹介するようなパターンです。「パターン4.レコメンド」に似ていますが、レコメンドとは異なって他の機能などへ接続するとより良いことがある場合に、ユーザーにその機能の存在自体をお知らせするようなパターンです。
例えば、2つ目のアカウントを持てるような機能があるが発生頻度は低く、設定の階層の奥深くにあるとします。そのようなときに、ユーザーが何回目かのタイミングで設定の階層に訪れたときに2つ目のアカウントを持てる機能があることを教えてあげる、というようなサポートを行うことが当てはまります。
機能説明の場合はレコメンドとは異なりコンテキストが限りなく薄いため、ユーザー側にそのような行動をしたいニーズがあるかは定かではありません。なるべくユーザーの行動を制限しない形を目指しましょう。
カテゴリ3：現状の理解
ユーザーに現状のステータスを説明したり、疑問を解消するようなサポートをするもので、2つのパターンが存在している。
パターン6.エンプティ非誘導
このパターンは、コンテンツがエンプティであり、かつエンプティがユーザー以外の行動によって解消されるような場合にユーザーを支援するパターンです。
「パターン3.エンプティ誘導」に似ていますが、エンプティを解消するアクションがユーザー側にはないときがこのパターンに当てはまります。例えば、ライブ配信アプリなどで、特定の時間にならないとコンテンツが表示されないようなサービスが当てはまるのではないでしょうか。そのような状況でユーザーをサポートするためには「コンテンツがエンプティであること」と「コンテンツが何で埋まるのか」を示す必要があります。この場合ユーザー側にネクストアクションは存在しないため、エンプティであることを示しながらも導線は置かないことが多いです。
パターン7.補足説明・ヘルプ誘導
このパターンは、初見だと分かりづらいようなときに補足的な情報を示したり、ユーザーから問い合わせがきそうなケースでヘルプ導線を出したりするようなパターンです。わざわざ説明するほどでもないかもしれませんが、これも中長期オンボーディングの一種だと考えています。
ただし、ヘルプや捕捉説明は使いすぎると画面が文字だらけになってしまうため、使い所は注意が必要です。使い方によってはユーザーの迷いを減らすことができたり、問い合わせを減らせたりなど効果的ではあるため、用法用量に気をつけて使っていきましょう。
オンボーディング施策を入れる場所の考え方
ここまで中長期オンボーディング施策を紹介してきましたが、全てを取り入れると要素が多すぎると思う人もいるのではないでしょうか。冒頭でも紹介した通り、基本的には”普通を目指す”という考え方を前提としていますが、入れどころを間違えるとかなり説明的なサービスになってしまうため、どこに入れるのが効果的か触れて終わりたいと思います。
ユーザーから問い合わせが多い部分
ユーザーからの問い合わせは中長期オンボーディング施策を検討する良い参考材料になります。問い合わせ内容を利用してヘルプページを作ることも有効ではありますが、ユーザーがヘルプページを訪れるとそれだけでサービスの体験が一時中断してしまうため、今回紹介したオンボーディング施策などを利用してできるだけユーザー行動を阻害しないような形での解決を目指せると良いでしょう。
特殊なフローを通るユーザーがいる部分
サービスの規模が大きくなってくると、サービス全体では少数派だけど決して見逃せないユーザーというユーザーも一定数存在すると思います。そういった場合はサービスを扱うユースケースそのものが異なる場合も多いですし、ユーザーボリュームを考えてもそのユーザーにフォーカスした設計に出来ない場合も多くあります。そのような場合に、導線や画面の出しわけなども含めた形でオンボーディングサポートを試みると効果的だと思われます。
概念的に新しい部分や、使い方的に新しい部分
「使いやすい」を作るための4つのアプローチの記事の中でも紹介していますが、ユーザーが普段馴染みのないモノを初めて扱うような場合や、馴染みあるモノではあるが使い方が特殊な場合はある程度サポートが必要です。その場合のサポートとして、抽象的にはメタファーや仕組みで解決できる部分も勿論ありますが、より細かくユーザーをサポートする手段として取り入れると効果的だと思われます。
終わりに
今回はユーザーの学習を中長期的にサポートする7つのオンボーディングパターンを紹介しました。ユーザーの初回体験だけではなく、さらに多くの場面で、初心者脱却を目指すユーザーをサポート・育成するよう心がけていくことが、長い目で見た時のユーザー体験の向上につながると思っています。具体的な施策としても新しい要素は決して多くはなく、1つ1つ丁寧に積み上げていくことが大切なため、ぜひ実践してみてください。