I'm designing an mobile app. There are 4 input fields that users must fill all to complete the registration. Those are full name, email address, password and username. First, I thought placing all in one screen might give users a simple registration experience, but later it looked scary to see too many fields in one screen. Should I divide all fields to steps provided that each field will be in one screen? Or, there is a common practice for the registration process?
-
Why do you have a separate username & full name?– koosvdkolkMar 19, 2021 at 11:38
-
1Username is unique and mandatory to distinguish user accounts. Full name is just a display name that can be anything. I want to keep full name because there is interaction between users and they need real names to call each other. I think it wouldn't be user-friendly to use only username.– Stewie GriffinMar 19, 2021 at 12:01
-
But can't you use the email address to distinguish user accounts?– koosvdkolkMar 19, 2021 at 12:17
2 Answers
I would make it a 2-step form: first username + password, then full name & e-mail ('To get to know you!').
This resource might also be of help: https://www.nngroup.com/articles/checklist-registration-login/
I would start with a 2-step version and then a/b test different registration flows in the live product.
Hypothesis to start with: By splitting the flow into two steps, with each step having a more specific purpose, the completion rate will be higher.
Step 1: Essentials (email + password)
Step 2: Welcome (enter name + pick username)
Rationale for starting with 2 steps:
- fewer inputs per step allow for more focus
- fewer inputs per step are easier to design in a conversational style
- flexible, e.g., you can do email verification first and after users clicked the link in the verification email, you can direct them to the app, welcome them and ask them to enter their name and pick a username
Once the product is live and has real users, I would use the above as a control version and test against a 1-step flow. I would look for completion rate as main KPI, but also for data quality as a secondary KPI.
Last one: It might be helpful to speak to developers early so that they can plan for a/b testing from the start.