Remove all non-essential fields.
Reconsider any “optional” field and ask “Is this really necessary?” These are common reasons why “optional” fields are included and what should be done instead:
If it’s only relevant for some users, use conditional logic instead.
Before
Do you need someone to contact you? No
If yes, please provide a contact number:
After
Do you need someone to contact you? No
(Answer is no, so contact number does not appear.)
If it’s redundant or highly related to another question, determine if both are necessary or if one can be derived from the other.
Before
Requested for:
User to apply access changes to:
After
Requested for:
This is the name of the user to apply access changes to.
If it’s highly valuable information but users may not know it at the time of request and/or it’s asked about later in the process, either:
- provide a Don’t Know/Not Sure option, or
- exclude it and just inquire later in the process.
Before
- Students
- Faculty
- Staff
After
- Students
- Faculty
- Staff
- Not Sure
If it’s an “Any additional information” type of question, consider why you need this, how customers use this field, and if your form may be missing something.
Before
Any additional details:
After
Please describe any special requests below.
Clearly indicate what’s required and what's optional.
This will reduce the cognitive effort required by the user. The best way to indicate a required field is by using an asterisk or the word ‘Required.’ Optional fields may be indicated with the word ‘Optional.’
Use inputs that require the least effort.
When multiple field type(s) are appropriate, use the one that requires the least cognitive and physical effort (clicks, scrolling).
Before
Which of the following topics would you like us to cover?
- Yes
- No
- Yes
- No
- Yes
- No
After
- Apples
- Bananas
- Pears
Use conditional logic.
When a set of questions are only relevant for a particular subset of users (e.g., based on their previous response or their role), use conditional logic so that only those users see those questions.
Hide actions when they do not apply.
For example, hide functionality like e-commerce interactions (cart, quantity), attachments, etc. when these actions do not apply.
Before
After
Prevent errors where possible and facilitate error identification and correction.
To prevent possible errors of input format, either:
- format form fields for the user automatically, or
- design form fields to accept multiple formats of an input
If an error occurs:
- Indicate the error clearly to the user. Ideally, this indication would appear “just in time”—at the moment the user commits the mistake—and in close proximity to the field being validated.
- Write error messages in clear, specific, and constructive language. Avoid technical jargon or system language (e.g., error codes).
- Do not use color alone to convey an error.
- Make sure to retain the user’s invalid input in the field so that they can refine their input instead of retyping it.