新しいユーザーが使い始められないのはなぜ？
目次
新しいユーザーは登録しているのに、最初の作業を終える前に利用が止まってしまう。説明を増やす前に、登録した人が何をしに来て、どの段階まで進めたかを確かめます。
初めて使う人にとって、アカウント作成は途中の手続きです。この記事では、登録から最初の目的を達成するまでを一つの流れとして見直し、説明不足、準備不足、権限待ちなどのつまずきを分ける方法を紹介します。
- 登録完了の先にある、最初に達成したい目的を決める
- 画面の操作だけでなく、データ準備や権限待ちもたどる
- 止まった段階と理由を分け、必要な支援を一つ選ぶ
最初の目的を、利用者の言葉で書く
「初期設定を完了する」「チュートリアルを見る」は、サービス側が用意した手順です。その先で、利用者が何をできれば使い始められたと言えるかを決めます。
たとえば予約を管理するサービスなら、「翌日の予約を確認できる」、チームの作業を扱うサービスなら、「担当者に最初の依頼を届けられる」といった状態です。画面を一度開いただけでは、目的を達成したか分かりません。
最初から製品全体の価値を一つにまとめる必要はありません。今回調べる利用者と目的を絞ります。自分で登録した管理者と、招待された担当者では、最初にやることも、できる操作も違います。
英国政府のサービス設計基準は、利用者が問題を解決するまでの一連の流れを考えることを求めています。登録画面だけが使いやすくても、その先で必要な仕事に進めなければ、使い始めるための支援が残ります。
登録から目的達成まで、実際の順番を並べる
対象を決めたら、利用者が通る段階を一行ずつ書きます。画面一覧をそのまま使うのではなく、メールを開く、データを用意する、同僚に依頼するなど、サービスの外で行う作業も含めます。
以下は、架空のチーム向け作業管理サービスの例です。手順、発言、改善案は説明用で、アーコレ！の機能や調査結果ではありません。
- 登録する：メールアドレスを登録し、確認メールを開く。
- 作業場所を用意する：チームの作業を置く場所を作る。
- 最初の依頼を書く：依頼内容と期限を入力する。
- 担当者を選ぶ：相手を招待し、割り当てられる状態にする。
- 依頼を届ける：担当者が依頼を確認できる状態にする。
この例では、最初の目的を「同僚に最初の依頼を届ける」とします。依頼を保存しても、担当者が見られなければまだ途中です。どこまでを今回の目的とするかは、チーム内で定義を合わせてください。
各段階には、「次に進むために必要なもの」と「誰が用意するか」を添えます。担当者の参加が必要なら、登録した本人だけでは完了できません。画面の説明を増やす前に、こうした待ち時間を見えるようにします。
どこで止まったかと、なぜ止まったかを分ける
利用履歴があれば、段階ごとの到達を調べます。ただし、「依頼の作成画面で止まった」という記録だけで、「書き方が分からなかった」とは言えません。入力する内容を考えていた、別の作業に戻った、必要な情報を持っていなかった可能性もあります。
英国政府の完了率の計測ガイドは、開始と完了を定義し、保存後に戻って完了するケースも考慮する方法を説明しています。初回利用を見る場合も、途中で離れた人が後日戻る流れを、同じ利用者としてたどれるか確認します。
比較するときは、登録した時期と観察できる期間をそろえます。今日登録した人と、先月登録した人を同じ条件で比べると、まだ作業する機会がなかった人まで途中離脱として扱うおそれがあります。
ログがない場合は、最近使い始めた人への確認や、サポートの記録から始められます。「ここで止まる人が何％いる」とは言えなくても、実際に起きたつまずきを一つずつ確認できます。分かった事実と、全体への推測は分けて残してください。
つまずきに合う支援を選ぶ
初回の困りごとをすべて「操作が難しい」でまとめると、案内を追加するだけになりがちです。以下のように、次に進めない理由を分けて考えます。
次に何をすればよいか分からない
登録直後の画面が空で、どこから始めるか分からない場合です。最初の目的につながる操作を示し、その操作で何ができるかを説明する案が考えられます。
架空例なら、「作業場所を作成」というサービス側の言葉だけでなく、何を入れる場所なのかを伝える必要があるかもしれません。ただし、全機能の案内を最初に並べる必要はありません。今回の目的に関係するものから検討します。
必要な情報やデータが手元にない
初期設定で組織情報や過去のデータを求められ、準備のために離れる場合です。最初の目的に本当に必要な情報か、後から設定できる項目かを確認します。
説明用データを試せるようにする案もありますが、本番のデータと混ざらない表示や、試したあとに実際の仕事へ移る手順まで考えます。サンプルを触り終えたことと、本人の目的を達成したことは区別してください。
権限や他の人の対応を待っている
管理者の承認、同僚の参加、社内での利用許可などが必要な場合です。本人の操作を短くしても、その待ち時間はなくなりません。
架空例では、招待された同僚がまだ参加しておらず、担当者を選べないケースが考えられます。この場合は、今の状態、誰の対応を待っているか、本人が先にできることを伝える案を検討します。許可や確認が必要な手続きを省いて早く見せることは避けます。
進めると何が起きるか不安がある
入力内容がすぐ公開されるのか、相手に通知されるのか分からず、最後の操作をためらう場合です。機能の使い方ではなく、操作の結果や影響が不明なことが支障になっています。
実際の仕様に合わせ、保存と送信の違い、見える相手、変更できる範囲を明示する案が考えられます。「安心して使えます」と抽象的に書くより、利用者が判断するための具体的な情報をそろえます。
直す場所を一つ決め、最初の目的まで見直す
複数の支障が見つかったら、今回の対象者が目的に到達するうえで、何が実際に妨げになっているかを確認します。案内を増やす、設定を後回しにする、待っている状態を知らせるなど、原因に合う改善を一つ選びます。
改善前に、次の確認メモを残すと比較しやすくなります。
- 対象者と目的：初めて登録した管理者が、同僚に最初の依頼を届ける。
- 確認した支障：担当者を選べない理由が表示されず、登録者が作業を止めた。
- 検討する変更：招待中の状態と、参加後にできる操作を案内する。
- 確かめること：状態を理解できるか、その後に依頼を届けられるか。
上記は架空例です。実際には、元の記録と未確認の点を添えます。説明を読んだ人数や案内を閉じた人数だけで、使い始められたと判断しないでください。
観察の準備や進行方法はユーザーテストの進め方、改善後の確認は機能改善の効果を確かめる方法で詳しく扱っています。
よくある質問
最初に全機能の使い方を説明したほうがよいですか？
まず、対象者が最初の目的を達成するために必要な情報を選びます。関係のない設定や機能説明が多いと、何から始めるかを判断しにくくなる場合があります。後から必要になる情報へ戻れる入口も用意します。
初日に使わなければ、使い始めに失敗したと考えてよいですか？
目的や利用機会によります。同僚の参加を待つ場合や、月末の仕事に備えて登録する場合もあります。対象者が使う予定だった時期と、必要な準備を確認してから判断します。
まとめ
使い始めの改善を今後の計画へつなげるときは、プロダクトロードマップの作り方も参考になります。
新しいユーザーの使い始めを見直すときは、登録から最初の目的達成までをたどります。画面の操作に加え、データ準備や他の人の対応も含めて、止まった場所と理由を確かめてください。
数人の確認なら一枚のメモで始められます。問い合わせや自由記述の声が増えると、どの段階の困りごとかを整理する作業が重くなります。アーコレ！では、集めた要望を整理する仕組みを紹介しています。利用履歴の計測とは分けて、使い始めの声をまとめておきたい方は、サービス紹介をご覧ください。
