University of Leeds - UI & UX Guidelines

Primary, Secondary & Tertiary Actions

Why we use this pattern

A typical form usually enables several “final” actions.
Actions like “Submit”, “Save”, or “Continue” are intended to enable form completion – the primary goal.
These are referred to as primary actions.

Secondary or tertiary actions tend to be less utilized and often allow people to retract the data they’ve entered, or go back.
Options like “Cancel”, “Reset”, or “Go Back” represent secondary actions that are counter to most people’s primary goal of completing the form they started.

Because secondary actions can have negative consequences, especially when used unintentionally, secondary and tiertary actions should be used with caution.
Imagine filling in a long form online only to hit the “Reset” button and have all your data erased.

There are some situations where secondary actions make sense (“Save for later”, “Export”, etc.).
In these conditions, visually distinguish primary and secondary actions so that users have an clear path illuminating their primary goal: completing a form.

Reducing the visual prominence of secondary actions minimizes the risk for potential errors and further directs people toward a successful outcome.

Right-aligned Primary Actions

Why we use this pattern

Gutenberg Diagram: Terminal Area:
Putting your call to action in the terminal area makes it quick and easy for users to click your button because it’s in the area where their viewing pattern ends.

A button in the terminal area is a compelling call to action because it’s placed at the end of the user’s viewing pattern. When it’s at the end of their viewing pattern, users don’t have to look around to find the call to action button.

Gutenberg Diagram: Terminal Area

High-level Form UX principles

• Reduce number of fields
• Reduce number of words
• Define naming conventions
• Cut out the noise
• Break big tasks into smaller steps
• Inline validation
• Reduce the number of taps
• Use proper input types

Reduce number of fields

Always (always!) look to combine or reduce the amount of fields to the absolute minimum required for task completion.
This greatly reduces the mental and physical effort required by the user.
It also manages the expectations of the user - nobody likes being faced with a vast number of fields to tackle;
Expectations impact conversion.

Reduce number of words

Always be as concise as possible. Question whether every single word absolutely needs to be included or not.
Every word used increases cognitive load on the user.
Remember, less is more.

Define naming conventions

Consistency of language is crucial in reducing the cognitive (mental) burden on the user.
Ideally, a globally agreed document which defines naming conventions should be discussed and agreed prior to any code build.

Cut out the noise

It’s important to create an interface that helps users focus on the task at hand. For key tasks, it’s often a good idea to remove superfluous elements that can distract users.
Including a simplified header and footer (a la Amazon’s checkout) and removing sidebars and other auxiliary content will help users accomplish the task faster.

Break big tasks into smaller steps

Another way to cut out the noise and help users focus is to break the form into smaller chunks.
This reduces the cognitive load on the user, and also presents a much less intimidating form than exposing all fields at once.
Again, Remember that expectations impact conversion:

Inline Validation

There’s nothing worse than submitting a massive form only to be scolded to go fishing to find your erroneous fields. Inline validation can help users fix their problems while they’re still focused on the general area.

Reduce the number of taps

An important overall goal of a form is to reduce as much as humanly possible. The less work the user has to do the more likely they are to complete the form. Simple things like combining fields like “First Name” and “Last Name” into a field simply called “Full Name” reduces the amount of taps the user has to endure.
It can always get even simpler.

User proper input types

Using the proper HTML5 input types and pattern attributes pulls up the appropriate virtual keyboard on mobile devices, saving users from having to manually switch over to enter a number.

Specific Form UX Guidelines

Required and optional fields

When to use this pattern

For required fields, use the following text positioned below the form heading and above the form fields; Grey text with red asterisk:
"Please answer all questions marked * "
The red asterisk is then included after every required field label, separated from the label by one blank space. See example above.

Label capitalisation

When to use this pattern

Labels should follow the 'sentence case' format. Sentence case text (where only the first word on the label is capitalised) is more eligible due to familiarity.

ISO-9241 part 17 states:
"Initial upper-case (capital) letter for field labels: To facilitate readability, the text field labels begin with an upper-case letter. The rest of the label should contain lower case (small) letters except for cases where the label is a logo, an acronym or language convention that requires each word in the label to begin with a capital letter."

Label font and weight

Label font

• Pick a standard font, eg Arial, Helvetica.
• Ensure good contrast with background (eg black on white).
• Make sure that the users can increase the size if they want to.

Label weight

Labels should not be bold, their CSS font-weight should be 'normal'.

Bold labels have been shown to cause around a 60% increase in saccade (eye movement) time to move from the label to the input field — from 50ms without bold labels to 80ms with bold labels — with no apparent advantage from the more prominent labeling.

Bold labels are more difficult for users to read and perceive—probably because there is more visual confusion between bold text and the adjacent borders of input fields.

'Hint' text

Hint text guides users through answering certain questions, allowing them to complete the form more quickly and avoid potential validation errors.
Hint text clarifies information which is crucial for task success to the customers it applies to, and so, unlike the help icons' alt text, should be visible at all times when required.

When to use it

Hint text should be used to provide info crucial to task success, for example the constraints and formats of required data input.

How not to use it

Hint text should not be placed within the field. This is an increasing common practice, partly due to mobile screen size constraints.
Hint text within a form field makes it difficult for people to remember what information belongs in a field, and to check for and fix errors. It also poses additional burdens for users with visual and cognitive impairments.

User testing continually shows that placeholders in form fields often hurt usability more than help it. See Norman Nielsen study here.

Hint text should not be placed within the label.

Recommendations

Help hints are increasingly underneath vertically aligned fields, again due to mobile screen size constraints.

The design of help hints should differ from the design of form labels to differentiate their purpose.
It is usually shown in smaller, greyed text:

• Font size should be 2 pixels smaller than field labels.
• Text style should be italic to denote task-critical status.
• Text colour should be grey.