WebサービスやiOS/Androidアプリのデザインをするとき、どのようなアカウント概念を採用するか検討したことはあるでしょうか？
ほとんどのアプリは、ユーザーごとにアカウントを作って情報やログを紐づけたり、機密情報を扱う場合は認証機構を設けたりする必要があります。また、どのようなタイミングで、どのような操作でアカウントを作ってもらうかはとても重要で、さまざまな選択肢があります。
一般的なデザイン
アプリをインストールして初めて開いたとき、下図のような画面をよく見るかと思います。
こういったデザインが採用される背景には、理由があります。
- ユーザが慣れているため操作に迷いにくい
- 構造がシンプルなため、仕様ミスが発生しにくい
- 実装ノウハウがシェアされており、コスパが良い
とてもシンプルなデザインなので、コミュニケーション不足なように感じるかもしれません。ですが、事前の口コミやプロモーションによって、アプリのコア体験や機能・使い方等をユーザーが理解しているのなら、これでもサインアップのプロセスに支障はありません。
デメリットはないか考えてみる
当然のことですが、一般的なデザインが自分のサービスにとっても正解である保証はありません。
一般的なデザインを採用することで、知らない間に受け入れてしまっているデメリットがないか考えてみました。
プロダクトのフェーズにもよりますが、インストール時点でプロダクトの価値がユーザーに伝わっていない場合、サインアップのプロセスはとても面倒なものであり、離脱ポイントとなります。
そもそも、20代前後のユーザーはメールアドレスやFacebookアカウント保有率が期待するほど高くない可能性もあります。
また、金融サービスのようにひとりが何個もアカウントを作れると困るという事情がある場合、カジュアルにアカウントを作って捨てられるサービスとは違った配慮が必要になることもあります。
このような状況を考慮したとき、一般的なデザイン以外にどんな選択肢があるかを考えてみます。
アカウント概念の選択肢
アカウント概念の考え方として、以下の４つが考えられます。
- アカウント無し
- ソーシャルログイン
- 匿名認証
- 電話番号 + SMS認証
1. アカウント無し
自分のサービスにそもそもアカウントが必要かをまず検討することが重要です。
たとえば、電卓やシンプルなカジュアルゲームなどはアカウントが不要です。
他にも、ローカルのデータベースやキャッシュを活用することで求めるUXを実現できるというケースもあります。その場合は、わざわざサインアップをさせる必要がありません。
2. ソーシャルログイン
次にご紹介するソーシャルログインはかなり一般的な手法ですが、「メールアドレスとパスワードを使うのではなく、FacebookやGoogleなどの外部サービスのアカウントを利用してサインアップ/サインインを行う」というものです。
メリット
- 操作ステップを大幅に減らせる
- 多くのアプリで採用されているため、ユーザーが慣れている
- ユーザー属性に合うサービスがある場合、ユーザーにとってより使いやすさが増す
- 写真好きなユーザーならInstagram
- エンジニアならGitHub
- AndroidユーザーならGmailなど
また、ソーシャルログインはすべて自前で実装してもいいですが、Firebase Authenticationというサービスを使えば、比較的簡単に組み込めますので、興味がある方は調べてみてください。
デメリット
- プライバシー面で抵抗を感じるユーザーが少なくない
- たくさんのソーシャルアカウントをサポートするとサーバーサイドの管理が大変
- 結局メールアドレス&パスワードによるサインアップもサポートせざるをえないケースも多い
ソーシャルログインは、対象となるアカウントを既に持っているユーザーに対してしか使えません。そのため、より多くのソーシャルサービスに対応したほうが良いように思える一方、あまり増やし過ぎてもユーザーが迷ったり忘れてしまうというジレンマがあります。
3. 匿名認証（Anonymous Authentication）
次にご紹介するのは、「最初はサインアップなしでアプリを使い始めることができて、あとで必要になったときにサインアップを求める」というやり方です。ECやフリマアプリと相性が良く、広く採用されています。
なぜ「匿名（Anonymous）」と言われるかというと、アプリを初回起動したときにユーザー情報が空っぽの匿名アカウントを作成し、idを割り当てるからです。そうすることで、サインアップ前のユーザーでも情報やログを紐づけてカスタマイズや分析を行うことができ、サインアップ後も情報を引き継がせて一貫性のあるUXを実現することができます。
メリット
- インストール直後に離脱する確率が大幅に下がる
- とりあえずサービスを使ってみてもらうことができる
- サインアップでの離脱率を下げるための施策を打ちやすい
インストール後、サインアップせずに無言で離脱していたユーザーも、匿名認証を使えば、どのような行動をしたうえでサインアップに至らなかったのかを分析することができます。また、インストールから初コンバージョンまでに提供するコンテンツやサインアップを迫るタイミングなど、体験設計の自由度も魅力的です。
ちなみに、先ほどご紹介したFirebase Authenticationはこの機能もサポートされています。
デメリット
- ユーザーの種類やステータスが増えて仕様が複雑化しやすい
- ユーザーサイドとビジネスサイドで視線がズレがち
- サインアップなしでできることを増やしてあげたい
- できるだけ早くコンバージョンにつなげるために、サインアップなしで提供する機能は制限したい
「サインアップなしで、どこまで機能を提供するか」という議論が一番難しく泥沼化しやすいポイントです。ある程度の機能を提供してサービスの価値を体験してもらわないとサインアップ意欲を引き起こせない一方で、満足度をあげすぎてしまうとサインアップする理由がなくなってしまうので、注意が必要です。
4. 電話番号 + SMS認証
最後にご紹介するのは、「電話番号をキーにしてアカウントを作成し、SMSメッセージによって確認コードを送ることで認証を行う」という方法です。
SMSを送信することができるサービスを利用して自社でシステムを構築する方法もありますが、Facebookが提供しているAccount Kitを活用することで比較的簡単に実装できるので、興味がある方は調べてみてください。
メリット
- 入力項目が少ない
- 大抵のユーザーは電話番号を持っているため、適用範囲が広い
- メールアドレスに比べて複数所有による迷いが生じにくい
やはりインパクトが大きいのは入力が楽になるという点です。また、電話番号をとりあえず入力してもらうことでサインアップ済みか否かをチェックして、次に進むべきフローをシステム側が判別してあげるといった工夫も可能です。
デメリット
- 電話番号を入力することに抵抗があるユーザーもいる
- 電話番号を変更したユーザーの対応フローを考える必要がある
- 電話番号が他人のものになるケースへのケアを考える必要がある
電話番号の問題点は、解約された番号が一定の休眠期間を経て、リサイクルされてしまうという点です。赤の他人が正当所有者になってしまう可能性があり、対策が必要なので十分注意してください。
ユーザーとの関わり方をデザインする
どのようなアカウント概念を採用するかによって、初めて接触してからヘビーユーザーになってもらうまでの過程が大きく変化します。
近年はさまざまな技術が生まれており、ユーザーがアプリに初めて接触する際の体験が多様化してきています。
例：
- Web広告上でアプリのお試しプレイができる
- LINE, Facebook Messenger, Slack上でbotとして利用できる
- 音声インターフェースを持ち、公共の場で触れることができる
体験の多様化に合わせてベストなアカウント概念を選択することで、ユーザーとの関わり方をゼロから柔軟にデザインすることができるでしょう。
