These UX Patterns and Guidelines provide crucial standards and consistency for prospective students and other users of the SES CRM Portal.
Please use the buttons under each example to view the UX Patterns and Guidelines.
Please direct any feedback to Kath Hallam or Anthony Allen.
Help Help Help Help
Info Info Info Info
Help icons are conventionally used within forms to denote additional information being available on mouseover.
They make efficient use of form real estate and remove visual clutter from too much supplementary text.
Use help icons to facilitate the conversation with our customers, should they require clarification on issues such as our reasons for requiring certain data, eg date of birth.
Help icons should not be used to provide info crucial to task success. Task-critical information should be presented as hint text - see this pattern for more.
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, the best practice I’ve advocated has been to visually distinguish primary and secondary actions so people 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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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."
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 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.
Hint text should be used to provide info crucial to task success, for example the constraints and formats of required data input.
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.
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:
We always approach error messaging like this:
We implement form-level validation messaging when a user has come to the end of a process, or the page has reloaded in a state which requires that the user's attention be drawn to a message.
Anchor the user back at the top of a long form, using these jump tags to address errors (or scrolling down independently to address them).
Submitting and resubmitting forms to check answers can lead to a frustrating and unsuccessful behaviour sometimes called 'pogosticking.'
Pogosticking is common when we ask users to provide an answer they may not be able to guess correctly the first time, and so inline validation should be used for fields which have potentially high error rates.
Selecting a unique username, for example, often involves pogosticking: nobody knows beforehand whether their username is available, so they guess, click “create account,” find out the username they want is taken, guess again, click “create account,” again, and so on.
Inline messaging should always firstly alert the user of the exact problem, and secondly provide a resolution.
Generic messages such as "There is a problem, please re-enter your details." should be avoided where possible.
Refer to the parameters required to complete the task - for example "Sorry, email format should be: email@example.com".
Try to maintain a strong visual relationship between the field and associated error message without encroaching on the field, especially for resposnive and mobile interfaces.
Where alternative answers are offered by the system, ensure that there is a clear visual separation between the explanative text and alternative answers.
The label, text field border, icon area and hint text are in default state:
The label, text field border, icon area and hint text change to error state once the user taps/clicks outside of the field in focus:
Validation now occurs as the user is typing.
The hint text (in red error state) stays in the same position. It is important to maintain visibility of the success parameters.
An additional, context-sensitive, error message can appear below if required - see 3a.
For example, if the user deletes all their text input: 'This field is required'.
Validation still occurs as the user is typing.
Once the user has entered the correct parameters into the field, then the label, text field border, icon area and hint text return to the default state.