I got a little challenge the other day from one of our PMs, Sarin:
Distinguish between Required vs. Optional fields on mobile forms without overcrowding the form
Problem Statement
Consider a mobile form where most fields are mandatory with a ‘Submit’ button. This button is in disabled state until user enters valid data in all fields. These days, many mobile apps follow this practice. However, users might be in grief, not knowing what they have to do for the button to get to enabled state. I have drawn inspiration from Luke Wroblewski’s great body of work on forms and Erin Walsh to outline few approaches I think are useful to solve above problem:
1. Colored Borders
Few mobile forms follow an approach wherein all required fields are highlighted with a colored border by default, when the user lands on the screen. The colored border goes away once user enters valid data in corresponding fields. In some cases, colored borders can blink or glow to garner attention.
Cons
- Mobile forms appear overcrowded due to colored borders, if most fields on the form are required, hence creating visual noise
- User might be shocked to see so many errors, as soon as he lands on the screen, even though he has not started to do anything on the form, yet
2. Secret Asterisks
Asterisks have existed in web development world for decades to indicate required fields. A general rule of thumb is to put an asterisk symbol next to a required field label with a tiny note in the header/footer saying, ‘* symbol indicates this field is required’ message.
Cons- Users hardly pay attention to asterisks on mobile forms.
- Non-tech savvy users might wonder what the asterisk symbol means, especially if they don’t notice the ‘* symbol indicates this field is required’ message or if this message is absent.
3. Using Auxiliary Labels
Another approach to highlight required fields is to add auxiliary text ‘(optional)’ or ‘(required)’ at the end of label to indicate whether this field is required or optional.
Cons- Too much of content for labels has issues if forms need to be localized in multiple languages
- This approach has content overload issue if forms have too many fields. Imagine a form with 15 labels where 12 are optional and 3 are required. The form gets heavily overcrowded due to auxiliary text. Vice versa, imagine a form with 10 required and 5 optional fields. Same problem pursues.
Auxiliary approach appears reasonable in few ways, provided following improvements are considered.
- Use ‘(optional)’ or ‘(required)’ based on which of these field types are fewer in number. For e.g. if most fields are required and very few are optional, indicate ‘(optional)’ for optional fields only as they are fewer in number. Vice versa, use ‘(required)’ for required fields if required fields are fewer in number
- Another rule of thumb is to eliminate optional fields on mobile forms, if that is a feasible option
4. Information Messages
An information message is placed in the header and/or footer that reads, ‘Please enter data in required fields to proceed’ or a similar one.
Cons
- There is a risk that users do not notice this message due to placement, font style, size and color.
5. Animation
If mobile form has too many fields, having visual cues like asterisks, auxiliary labels or colored borders may not really help. This is usually the case where forms are lengthy and user is either at the top of bottom of the form. In such instances, it might be good to do the following:
Introduce an animation where text field moves left to right for a few interactions. This can be combined with mobile device vibration feature for better effect. Booking.com mobile app uses this approach on login form below:
Another way might be to time the behavior. If user hasn’t entered any information on the form for let’s say, 5 seconds, user focus can be taken to the required field where animation effect is displayed.
Cons
- Animating all required fields might lead to chaos; they may have to be defined in a methodical way
- Timing animations may or may not work depending on user behavior and demography
What is a suitable approach?
After analyzing above 5 approaches, I was still with the same problem in hand statement and no solution yet. When I proposed these approaches to few developers, they shared their views on pros and cons of each approach. At this point, it dawned on me to use a combination of multiple approaches to solve the problem I set out to solve rather than hanging onto one approach.
- A message, ‘Please enter data in required fields to proceed’ is displayed at the footer near the disabled action button
- Fields are indicated as optional or mandatory fields [Use ‘(optional)’ or ‘(required)’ based on which of these field types are fewer in number. For e.g. if most fields are required and very few are optional, indicate ‘(optional)’ for optional fields only as they are fewer in number. Vice versa, use ‘(required)’ for required fields if required fields are fewer in number].
- If user is on the form for 3-5 seconds and :
a. User does nothing because ‘Continue’ button is disabled
b. User taps on ‘Continue’ even knowing that it is disabled
In (a) and (b) above, required fields glow with a sky blue colored border to indicate that these fields are required for user to enter. If user is at the bottom of the screen, focus is drawn to the first required field on the screen. Blink is better than glow effect, but from accessibility point, blinking is bad for photosensitive users.
As you notice, we have used Information Messages, Auxiliary Labels and some Motion Design to accomplish desired effect. Several times, we may have multiple approaches or techniques to solve a problem. The challenge is to pick the right approach and validate if selected approach solves the problem in its entirety. Customizing a suitable approach by collaborating with different stakeholders helps in coming up with a good solution that is good enough, if not great. An iterative development process helps refine the identified solution over a period of time.
Have you faced a similar problem before?
