Goodpatch Advent Calendar 2017 14日目は、アプリの初回起動時の体験設計を考えてみます。

アプリの初回起動時のユーザー体験はとても重要です。

そこは、ユーザーとアプリ（≒サービス）の出会い場であり、ユーザーがコンテンツに触れるための入り口でもあります。この画面をオンボーディングとも言います。オンボーディングの体験をどうするべきかという話は調べるといろいろ出てくるかと思いますが、今回は私自身の考えを言語化してみたいと思います。

オンボーディングとは

アプリの初回起動時にはたいてい3〜4ページくらいの横スクロール画面を用意して、それぞれぺライチでアプリの概要を説明したり、必要なら初期設定もあわせて行なったりすることがあります。そのほか、初回起動時に限らずとも何かしらの機能に初めてアクセスした際のチュートリアルなどもオンボーディングの一種かと思います。

Appleのアプリのオンボーディング例。基本的にはペライチで、複数ページにまたがることなくシンプルに機能説明を行う例が多いようです。詳細説明は別のページに飛ばすようにし、ユーザーがすぐにアプリや機能を使い始められるためのCTAボタンを設置しています。

ラジコとUber Eatsのオンボーディング例。ラジコのような複数ページのオンボーディングを入れているアプリはよく見かけますね。Uber Eatsではビジュアルを前面に出して食欲を刺激するオンボーディングとしてデザインされています。一方で、日本人的にはキャッチコピーの改行位置がおかしなことになっていて、この先日本語サポートが適切に行われるかどうかなど初回起動の時点でもわずかな不信感を抱いてしまうかもしれません。

初回起動時の機能説明はなるべく最小化すべき

アプリ起動時の唐突なオンボーディングは、おそらくはほとんどの場合において、ユーザーにとっては寝耳に水のようなものです。

十分にコンテクストを共有できていない状態から長々と機能説明をされたところでユーザーは思考停止してしまうでしょう。一方的に多くの情報を提示されてもユーザーはそれらを理解する意欲がまだあまりなく、自身の作業を邪魔されているようにしか感じないでしょう。いきなりよくわからない設定を求められても、一体これが何のためのものなのか、前提が何もわからないのに位置情報を取られるといったことに納得できません。そういった小さな苛立ちをもう初回起動時から募らせてしまうことになるのです。早すぎます。
これは、街中でいきなり声をかけられた相手から結婚を前提に交際しよう、家はどこにしようなどと詰めかけられるようなものです。

せっかくユーザーが自発的にアプリストアにアクセスして、面倒なパスワードを入力して、回線速度や通信許容量を気にしながらダウンロードして、終わるまで時間待機して、やっとのことであなたのアプリを起動してくれたのです。ここまでの面倒な作業をわざわざやってくれたにもかかわらず、ここからさらに「何だかよくわからない情報」を一方的に提示して、さらには納得感のない形でいきなりユーザー登録やプッシュ通知の許可さえ求めます。
これではアプリを使ってみようとする意欲が低下してしまうというものです。

高機能化の代償

アプリ以外の事例を一つ挙げてみましょう。

昔のテレビゲームは、カセットやディスクを挿入して電源を入れればすぐにゲームの世界に飛び込むことができました。
初めてスターフォックス64を買ってきた時には、ワクワクしながらコントローラーを握っていたことを今でも良く覚えています。64初の振動パック対応タイトルでもあったので、どんなものなのか今すぐにでも体験したかったのです。

あの頃の比較的単純なテレビゲームと比べると、最近のテレビゲームは何だか高機能になりすぎて肝心のゲームを体験するまでにたくさんの設定をこなさなければならない印象があります。最新のゲーム機を買ってきて電源を入れたらまずはWi-Fiの設定からです。入力しづらい。そうしたら今度はアップデートをしろだのうるさいのです。それもシステムアップデートとゲームソフトのアップデートで個別にあり、場合によっては数十GBのダウンロードを待っていたら日が暮れていたなんてことも普通にあります。

1.カセットを挿す、2.起動する、3.遊ぶ

この3ステップを犠牲にしてまで、高機能・高画質が体験として優れているのか、私には少々疑問が残ります。

納得感のあるオンボーディングとは

アプリの話に戻しましょう。

オンボーディングでは、このアプリは何のための道具なのか、何が得られる機能なのか、なぜこの設定が必要なのか。そのことをユーザーに理解してもらうことが大切です。アプリが複雑であればあるほど、それを文章で伝えるのは難しくなります。いくら丁寧に書いたところで、読みたくないものは読まれません。
百聞は一見に如かず、一番良いのは、そのアプリの「それっぽい画面」をまず見せて、実際に体験させてから、ユーザーがアプリの使い方を触りながら想像し学ぶことができる形にすることです。初回起動時のつまらないオンボーディング画面なんてすっ飛ばしてしまい、いきなりホーム画面に放り込んでしまいましょう。ユーザーはもうすでに「アプリストアの概要を読んで、アプリをダウンロードして起動する」というオンボーディングを経験済みであるため、これ以上の険しい登山を期待していません。頂上で快適に過ごしたいのです。だからこそ、アプリは起動したらすぐに使えなければなりません。

まず使わせて、ユーザーがアプリの世界に浸って意識が能動的になったところで初めてそれ以上の情報を提供してあげる形にしましょう。

オンボーディングを提示する適切な時期の検討

そのアプリにとってプッシュ通知が必須機能だとします。
しかし、ユーザーにとってプッシュ通知の必要性が理解できないままそれを問答無用で「許可」しようとはまず思いません。いきなりあのアラートが現れたら怪しんで「許可しない」を選ぶのは当然の心理ではないかと思います。

これではアプリにとってはよろしくない状況です。こうならないようにするためにもまずはユーザーにプッシュ通知を納得していただかなければなりません。そのためにも、いきなり許可を求めるのではなく、納得感のある適切な時期を設計する必要があります。

例えば次のような時にプッシュ通知の許可アラートを出すことを検討できます：

• プッシュ通知が必要な機能にユーザーが初めてアクセスしたとき
• 何回めかのアプリ起動直後（ユーザーがアプリの概要を理解し、継続利用し始めたと思われる時期）

SNSアプリであれば、ユーザーが初めて誰かに返信を送った際に、「プッシュ通知の許可をすることで、相手からの返信を通知で受け取ることができます。」と言った説明とともに許可を求めるアラートを出してあげると、納得感を得られやすいのかなと思います。

ナビゲーション系アプリであれば、ユーザーがマップ画面を初めて開いた際、あるいは許可されていない状況でマップ画面を開いた際に、「マップを利用するには位置情報を許可してください。」と促すことができるでしょう。

事例：「さんちの手帖」iOSアプリ

私がグッドパッチでアプリケーションデザインから開発まで携わった「さんちの手帖」というアプリでは、初回起動時のオンボーディングを一切表示せず、ユーザーがタブに初めてアクセスした際にそこで必要な情報や設定を促すモードレスなオンボーディングを設計しました。

例えば旅印帖（たびいんちょう＝電子スタンプによるチェックイン機能）のタブでは、旅印獲得に必須の機能である「位置情報サービス」「ローカル通知」の許可を求める必要があったので、ここではタブ内にウィザード形式で旅印の概要から仕組みをざっくりと説明してから、それぞれの機能を許可してもらうという流れを設計しました。写真を見て分かるとおり、タブバーは表示されたままなのでユーザーはいつでもこの画面から抜けることができますから、オンボーディングを抜けるのを強制されることはありません。

1. 概念の説明

まずは旅印という新しい概念を説明しています。
ユーザーは他の画面ですでにさんちのコンテンツに触れているので、その前提知識や積み重ねてきた細かい体験が経験としてありますから、人によっては旅印に興味を持ってもらえるかもしれません。

2. 設定が必要である旨の説明

次に、旅印に必要な二つの設定を行います。
位置情報と通知の設定はあくまで 任意 であり、利用したくなければユーザーはいつでもこの画面を去ることができます。HIGでも通知を強制するようなことをは避けるべしと指南されています。オプトアウトの権限は常にユーザー側にあるということです。
ユーザーが再び旅印に意欲を持ったら、いつでもこの設定画面に戻ってくることができます。

3. 設定の実施

ユーザーがいずれかの「許可する」ボタンを押すと、ここでOS標準の仕組みに従って機能の利用許可を求めるアラートを表示します。
これらの設定を満たせなければ旅印帖画面には進めないため、旅印帖や旅印獲得に関する機能は利用できないままではあるのですが、さんちの手帖アプリの機能が全て利用できなくなるわけではないので、これは大きな問題はありません。

4. 機能の開放

設定が完了してオンボーディングを抜けると、ユーザーは旅印帖のブランクな画面に辿り着くことができます。ここからはユーザー次第で、日本全国のさまざまな工芸産地の見どころを訪れてもらい、その場所に設置された旅印を自由に集められるようになります。上の写真は獲得した旅印が表示されている画面の様子です。

ブランクを効果的に活用する

UIスタックモデルによると、UIには5つの状態があるとされています。すなわち、空状態 (Empty)、ロード中 (Loading)、部分的状態 (Partial)、エラー (Error)、理想形 (Ideal) です。UIデザインではこれら5つの状態を常に意識し、その時になったらどのように振る舞うのかをきちんと定義しなければなりません。

How to fix a bad user interface

これらのうち、空状態（ブランク）をオンボーディング代わりに活用するといったことも考えられます。「さんちの手帖」アプリでは、次の画像のようにデータが存在しない場合にはその画面で何が行われるのかということの簡易的な説明文を挿入しました。

このアプリでは、ユーザーが好きな読み物や産地ページに対して栞（ブックマーク）を挟むとこの画面で一覧することができます。

まとめ：アプリの初回起動時の体験をデザインする上で工夫すること

初回起動時の体験は重要

アプリの初回起動時の体験はとても重要です。そこは、ユーザーとアプリ（≒サービス）との初めての出会いの場であり、ユーザーがコンテンツに触れるための入り口でもあります。ユーザーにとって、「アプリを使うこと」よりも「コンテンツに触れること」の方が重要であるため、アプリを無理やり使わせている感を出さないように工夫しなければなりません。

初回起動時のオンボーディングに必然性がないのであれば、まずアプリを使わせてあげることを検討する

特に必要がなければ、初回起動時の3〜4ページに及ぶオンボーディングは省いてしまった方が良いでしょう。ユーザーはアプリストアからアプリを起動するまでにすでに険しい道のりを歩んできているため、これ以上の作業を求めていません。ユーザーをいきなりアプリの世界に放り込んでしまい、その世界を体験してもらうようにしましょう。

プッシュ通知などの設定はその時がきてから

プッシュ通知や位置情報サービスの許可が必要であるならば、それをアプリの初回起動時に求めても納得感がありません。いきなりあのアラートを出したところでどうせ拒否されてしまいますから、そうではなく、ユーザーが能動的に関連する機能に触れた際に説明とともに許可を求めるなど、納得感のある時期というのをよく考えて設計することが重要です。

アプリ開発者は、プッシュ通知や位置情報サービスは常にユーザーによってオプトアウトされ得るものだという認識を持ち、仮に特定の仕組みが機能しないとしてもアプリが成り立つように設計しましょう。

UIスタックを効果的に活用する

UIスタックをうまく活用して、オンボーディングに違和感がないようにデザインしましょう。ユーザーがデータを満たしてゆくような機能であれば、初めのうちは空状態（ブランク）であるはずです。この時にオンボーディングを提供してあげることで違和感のない形にすることができます。