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