ユーザに愛されるかが決まる初回起動後のUXデザイン:「ファーストラン」のつくり方

編集:三橋ゆか里

プロダクトを箱から取り出して使えるようになるまでの体験を指す「Out of box experience」という表現があります。ユーザにワクワク感と信頼感を感じてもらうと同時に、クレームや返品対応のコストを削減する、という明確なビジネス目的があります1

主にICT機器の領域で使われるフレーズですが、ウェブサービスやアプリのUXデザインにおいても、ユーザが初めてプロダクトに接した時の体験を上手く設計することは必要不可欠です。一回試しただけで放置しているアプリや、アカウント作成以降触っていないサービスの数を思い浮かべてください。たくさんの機会損失が見えてきます。

AQでは、この体験を「ファーストラン」と呼び、そのUXデザインは主要機能のものと同じくらい重要なステップだと捉えています2

ファーストランで達成したいこと

プロダクトが今後使われるかを大きく左右する大事な時間であるファーストランにおいて、サービス提供者が達成したいことはたくさんあります。気まぐれなユーザにプロダクトのコンセプトや世界観を理解してもらい、利用するメリットや使い方のイメージを抱いてもらうためにどうすればいいのでしょうか?ユーザに取ってほしいアクションはプロダクトによって異なりますが、個々のユーザが将来的にもたらす価値(利益)を高めることは、共通したゴールとなります。

ファーストランは、マーケティングとプロダクトを繋げる大事な営業ツールです。

4つのファーストラン設計へのアプローチ

画像をクリックすると、4つのアプローチがポスター形式で表示されます

ファーストランの設計には、大きく分けて4種類のアプローチがあると考えます。もちろん、これらを組み合わせることも可能です。プロダクトのKPIを用いてファーストランのKPIを導きだすところからはじめると、最適な方法が見えてきます。

1. チュートリアル型

プロダクトを通じていくつかの大きなコンセプト(機能)があり、一回触っただけでは全貌がつかめない時に適したアプローチです。まず説明から入るというアプローチは、特にスマートフォンアプリに多く見受けられます。

PLUS: チュートリアルの制作がプロダクト本体の開発に依存しないため、開発に負荷をかけずにリリースしやすい
MINUS: 読み飛ばされることが多い。その上、きちんと理解したことを前提にアプリが設計されているため思い違いが発生するリスクがある。また、チュートリアルの効果は計測しにくく、ユーザの習熟度や考えについて何も学ぶことができないというデメリットがある
TIP: 閲覧を強制しないこと

PCサイトでは、ファーストランの起点がホームページ又は(友だちがシェアした)個別ページであることが多い。サービス概要や利用メリットの説明を「チュートリアル」と捉えると、メルマガ配信サービスMailchimpの例が参考になる。アカウント登録を検討しているユーザに向けたコンテンツは、「説得しようか?」というリンクから飛ぶ所謂Aboutページに集約されている。Mailchimpのことを知っている人は読む必要がないので、ホームページでの閲覧を強制しない設計を取っている

応用編:初回のみに表示される吹き出しヒント

Facebookの吹き出しヒントの例

Flipboard iPhoneアプリの吹き出しヒントは、青い丸が何回か脈を打ってから消える

FacebookのPCサイトにて、新規機能が搭載された際の吹き出しが一番良い例かもしれません。Wordpressをアップデートした後の管理画面に出るヒントも、良く出来ていると思います。サービスが進化していることを印象付けるので、新しい機能を紹介したい時に特に適したアプローチです。

PLUS: 表示するタイミングをコントロールできるので、より多くのコンテキストと共に提供することができる。また、説明ページやコンテンツブロックを追加しなくてもメッセージを伝えられる柔軟性がある
MINUS: 吹き出しヒントの表示・管理を行う機能開発の初期投資が必要となる

[jwplayer config=”Custom Player” mediaid=”1341”]

2. 補助線型

例えば、格闘ゲームの基本動作を習得してもらうために、右フックを一回すればクリアできる「レベル1」を仕込む、というようなゲームデザインを連想させるアプローチです。ユーザのプレイしたい気持ちを邪魔しないように、誰もがすぐにクリアできるレベルとしてゲーム内に含まれています。時系列で起きるアクションをサポートしたい時に適しています。

この格闘ゲームが、前述した1.チュートリアルのアプローチを取っていたとしましょう。一刻も早く悪者を倒したいユーザは説明文を読み飛ばし、右フックを知らない状態で試合に入ってしまうかもしれません。瞬殺されてしまった可哀想なユーザには行き場がありません。確実にステップをこなし、次に進んでいることをユーザに実感してもらうことの価値は侮れないのです。

PLUS:ユーザがXという行為を習得したことが確実に分かるので、その前提でプロダクトを設計できる
MINUS: 頭をひねらないと、プロダクト本体に溶け込んだ上手なデザインは難しい可能性がある

3. ウィザード型

ユーザのデータ入力なしではプロダクトが使えない、もしくはその体験が著しく乏しくなってしまう場合に適したアプローチです。

PLUS: 全ユーザに同じスタートラインに立ってもらうことができる
MINUS:リターンがない状態が続くので、プロダクトの価値が充分に伝わってない場合、途中で離脱するリスクが高い
TIP: ウィザード応対のリターンが明確であり、大きいことが大切

Pathのアカウント作成プロセスは、ファーストラン設計の勉強になるので一回試してみてください。1枚目(左)はチュートリアル、2枚目以降のアカウント作成はウィザード形式で設計されていて、その面倒なステップをこなす間に、Path的なコミュニケーションの感覚を伝えることに成功しています。

4. 何もしない

プロダクトの価値と使い方が共に極めて明確である時に使えるアプローチです。Manga Cameraのように機能が一つであれば、ファーストランとそれ以降の利用を差別化する必要がないかもしれません。何もしないということを決めるのも、UXデザインの立派な判断です。

PLUS: 何もしなくていい!
MINUS: アプリをフル活用してもらえない可能性がある
TIP: 広く認知されているデザインパターンを使うこと

応用編:外部リソース

Twitterで話題になっているニュースや有名アカウントの一覧など、内容が盛りだくさんのTwitterナビサイト

分からなかったらFAQやナビサイトを見てね、という割り切ったアプローチは、一回使っただけでは分からない複雑なプロダクトに適しています。

プロダクト本体の主要ターゲット層とは違うターゲットにアプローチしたい時にも力を発揮します。開発は本国主導で進んでいるが、日本のマーケットではまた違ったコミュニケーションを取りたい、と思った場合を考えてみてください。プロダクトのローカライズだけで対応しきれないのであれば、自由にコンテンツ作成ができる外部リソースでフォローする、というのも一つの手です。

PLUS: プロダクト本体の開発と依存関係がない。いくらでもコンテンツ量を増やすことができる。
MINUS: 使われない可能性がある。プロダクトの新規開発で忙しくなって、更新が疎かになる

プロダクトの進化に伴い、ファーストランは進化していく(べき!)

プロダクト開発に長く関わっていると、慣れてしまってどうしても感覚が麻痺していきます3。プロダクトを触ったことのない人をリクルートするのはちょっと手間ですが、定期的にユーザビリティテストを行うことを推奨します。

同じプロダクトでも、その知名度に応じて、初回アクセス時のユーザが持つ前提知識や期待は大きく異なります。特にソーシャルの要素を持つサービスに関して言えることですが、オーディエンスの変遷に応じて、適度なタイミングでファーストランの設計を見直す必要があります。誰も知らない状態、口コミで広がっている状態、かなり知名度が上がって来た状態・・それぞれのフェーズに最適なファーストランがあるはずです。

最初に述べたように、ファーストランは、マーケティングとプロダクトを繋げる大事な営業ツールです。この切り口で、手に取るプロダクトや自分の関わっているプロダクトを見つめてみてください。

予告:次回は、ウィザード型アプローチを実践するランニングサービス「My ASICS」のファーストラン再設計に関するケーススタディを投稿します!

脚注:

1. 初期設定が難しくて多くの不満が出てしまった電子書籍端末kobo Touchの例を思い返すと、OOBEのクオリティを担保する価値が分かるかと思います。

2.AQでは、気になったアプリのファーストランを分析するFirst Run ImpressionsというTumblrを、たまに更新しています。

3.例えばダッシュボードは、データが存在することを前提にデザインすることが多いので、初回アクセス時の空っぽの状態がいかにネガティブな印象を与えるか、プロダクトチームには分からなくなっていきます。コンテンツの増減に対応する「負荷テスト」を忘れずに。