Form Field Enhancements
This is a design story I created to articulate solutions and document the design work to be done. It also captured my ideas for handoff to development. One engineer loved the content so much he commented “Best ticket in Jira.”
As a Guest
I want to fill out fields efficiently and without errors in order to save/submit the form.
In a successful design…
Guests can clear text fields.
Guests can identify when input is optional.
Placeholders or field labels always indicate what the corresponding input fields mean to the Guest.
Validation: Guests can understand the result of their input through feedback.
An error message using indicates errors clearly, with steps for resolution if needed.
A success message confirms positive submission when appropriate.
Use Cases
The Guest ...
needs to create an account.
wants to sign in to the app.
adds a new address, under profile, or while checking out.
adds a new payment method, under profile, or while checking out.
fills out profile.
edits a previously saved form.
adds a gift message to an order.
purchases a gift card.
books a class.
Discount input
Guest Scenario Considerations
The new designs should accommodate all current forms. Are the above uses cases all of the forms?
Every effort should be taken to maintain/improve accessibility standards in Guest forms.
Current Pain Points for the Guest
We mark 90% or more of all fields as required, using the placeholder to show “required” instead of helpful text to let the Guest know what type of data to enter.
Guests can lose location in form, with little feedback about which field is active.
Filling the input with “Required” adds noise and makes it unclear what the Guest missed if the form is incomplete until an error appears.
It is not clear which input an error is associated with, leaving the user confused.
Recent one-on-one research indicates that “Name” fields for Address or Credit Card are superfluous to the Guest and detract from the experience of adding a new address or payment.
Lack of smart defaults makes users manually enter data we could import for them without compromising security.
Recommended Solutions
Run a quick UX test on an adapted version of adaptive labels.
The label starts as placeholder text in input e.g. “Password,” with any helper text placed below the field.
Add an active state using color and animation, giving the user more feedback than a blinking cursor.
When active, the adaptive label “floats” up above the input and shrinks to a smaller size, giving context to the user while they type in the field.
When a field is not required, mark it as optional. Do NOT indicate required fields with placeholder text.
Consistently use a prominent input accessory above the keyboard to let the user enter text in all the inputs in order without ever leaving the keyboard or spinner. (See Anthropologie example). We use them sometimes, but not always, and the design is too faint to be noticed.
Update error states and helper text to indicate which field needs action.
Revisit form headers for better information hierarchy.
Remove unnecessary fields, such as “Address Name” or “Card Name.” Every extra field we add to a form affects its conversion rate. Always consider why we are requesting certain information from the Guest and how we use that data.
Not in Scope for this Story
Leverage address Autofill from Contact using CNContactPickerViewController https://developer.apple.com/documentation/contactsui/cncontactpickerviewcontroller
Research
User Research Lo-Fi Prototype: <InVision Link>
Helpful Reading: https://www.nngroup.com/articles/form-design-placeholders/
TLDR;
Disappearing placeholder text strains users’ short-term memory.
Without labels, users cannot check their work before submitting a form.
When error messages occur, people don’t know how to fix the problem.
Placeholder text that disappears when the cursor is placed in a form field is irritating for users
Fields with stuff in them are less noticeable.
Users may mistake a placeholder for data that was automatically filled in.
As a Guest using GuestApp I want to have a clearer and more intuitive form UX throughout the app such that I can quickly and seamlessly provide the information the app needs for me to complete my desired journey
UX Design
<InVision Link>
Acceptance criteria
All forms (and fields) throughout the app will be updated with a new visual and interaction treatment as described below and demonstrated in attached UX design
see list of impacted forms in <Confluence link>
selected field treatment will clearly indicate to guests the appropriate field states
note the updates to field labels, field highlighting, required/optional field indication and field default text
Field level error state treatment will be updated to be clearly associated with the applicable field
Form level error state treatment will be updated
Form Behavior
Text fields use a container to provide an explicit affordance for interaction. The color and thickness can change to indicate when the text field is active or in an error state.
Field States
Passive, active, filled, empty, and error states give the guest feedback for successful form completion.
Passive - Field can be empty or filled. The guest is not interacting with the field, and there are no errors.
Active - The user is interacting with the field. The correct keyboard/picker raises from the bottom of the screen. Field-clearing icons let users clear an entire input field and appear only when any value is present.
Error - Field can be empty or filled. Empty error is applicable for required fields with no value. Validation error reports a problem with the value and gives the guest help text on how to resolve the issue. e.g "Please enter a ten-digit phone number." for an incomplete phone number.
Empty Field Error (Required field)
Container outline changes to Error color at 2 pt width.
The label changes to font BodyErrorMedium.
Error text says `[field name] is required.`
Error icon indicates invalid inputs, making error states clear for colorblind users.
Validation Error
Container outline changes to Error color at 2 pt width.
The label changes to font SmallestErrorMedium left-aligned.
Error text gives useful guidance on how to resolve the error. Help text is hidden.
Error icon indicates invalid inputs, making error states clear for colorblind users.
Empty
The label acts as a placeholder in the middle of the field in font BodySecondaryRegular.
Filled
The label "floats" to the top of the field and shrinks to font SmallestSecondaryRegular. The value appears in the field below the label as font BodyPrimaryRegular.
Field Elements
Corners
The top-most and bottom-most fields of a form have a border-radius of 5 pt on the outside corners. A solo text input has a border-radius on all four corners.
Label
Label text should always be visible, animating from the middle of the text field to the top when the guest adds a value. The label starts as font BodySecondaryRegular and shrinks to font SmallestSecondaryRegular. The label is persistently visible.
Value
The value is text or numbers entered by the guest. The value appears in the field below the label as font BodyPrimaryRegular.
Required vs Optional
Indicate optional fields by displaying the word `optional` in parentheses next to the label text.
Help Text
Help text conveys additional guidance about the input field, such as how we use the value e.g. "In case we need to contact you about an order." on the phone number field. It should only take up a single line and is persistently visible unless there is a validation error, in which case the error is visible and the help text hidden. The help text appears at the bottom of the field in font SmallestSecondaryRegular.