Form controls are some of the most fundamental elements in our interfaces. They are also represent an interaction where we are asking for something from our users. We are asking them to complete a task or enter important information.
Because of this, its vital that form controls are clear and cohesive across our entire product.
While a form may have only a single field, in many cases in our product, forms are made up of many fields. For these cases we have two basic styles for laying out fields.
The Standard form style is the default style that should be used throughout our interfaces.
It provides a clean, airy layout with enough whitespace between elements to make them easily readable and clickable, and the vertical spacing between fields (1rem/16px) directly matches our base-16 type and layout scale.
In cases where there needs to be more information density in an interface, or when there is simply less space available for laying out a form, the Compact form style is available. In this denser style, the vertical spacing between fields is halved (0.5rem/8px).
You should try to use the Standard style wherever possible, but there are certainly times where Compact is appropriate.
General Style Guidelines
In either style, there are a few general best-practices (you get these for free if you use the Form Components in Uniform UI Components):
- Always put labels above the field.
- Always left-align label text.
- For now, always keep 1 field per row (until we provide additional layout options and components).
- Always create tab ordering on all fields.
- Respect as many ARIA guidelines as possible.
For each of the Form Styles defined above — Standard and Compact — there are also size options for the fields within that style.
Medium is the default size for fields in either style. The text size for Medium is 16px/1rem. For inputs, the height is 40px and the left and right padding is 16px/1rem. This results in a more clear and readable form.
Additionally, when a field and a button are used together inline, the medium field size matches up with the medium button size.
That being said, for buttons that sit on their own row in the form (for example the ‘Submit’ button at the bottom of the form), it is recommended to use a Large-sized, Primary-type Button. This provides a clearer call-to-action.
There is also a Small field size available for use in either style. The text size for Small is 14px/0.875rem. For inputs, the height is 30px and the left and right padding is 8px/0.5rem.
This size is appropriate in denser interfaces where space is a premium, or when 16px/1rem text is too large in the type hierarchy (i.e. filter panels).
When a field and a button are used together inline, the small field size matches up with the small button size.
There is also a Large field size available for use in either style. The text size for Large is 18px/1.125rem. For inputs, the height is 54px and the padding is 16px/1rem.
This size is appropriate in interfaces where there is available space. It gives the fields room which can ease readability and make the form less intimidating.
When a field and a button are used together inline, the large field size matches up with the large button size.
Any of the above form styles will be made up of many different fields. Below are the visual guidelines for the most common base HTML fields.
For detail on on writing for these fields, check out the Microcopy guidelines.
Labels need to be included on all fields. While they can be visually hidden in some instances, the label should still exist for accessibility purposes.
A label should clearly and concisely describe the purpose of the field with no more than a few words in length—use title case.
Text Inputs are used when you’re asking for a single line of text (usually no more than 75 characters).
The Text Input Label should provide enough direction in most cases so that no placeholder copy is needed.
If the text needed has special considerations or formatting, help copy can be provided below the field detailing how the text should be entered.
If you aren’t using the Form Components in Uniform UI Components, make sure to use the proper input type on Text Inputs to support the mobile web (password, tel, number, etc.).
Text Areas are used when you’re asking for a large or unknown amount of text that will span multiple lines.
The Text Area’s Label will determine whether or not placeholder copy is needed. If it is, the placeholder should start with with the word Enter.
Select controls are used when providing the user a large set of options to choose from, with only one choice allowed. The options within a Select control should be logically ordered (alphabetical, grouped, etc.) with separators used as needed.
Additionally, if a Select control has less than 5 options it is recommended to use a Radio control instead (as this is better than obscuring the options behind a click).
At the moment, only the main Select control has a defined style. The dropdown that shows the options on click can have the browser default styling.
Radio inputs are used when providing the user a small set of options to choose from, with only one choice allowed. The inputs should be logically ordered and it’s best to have no more than 5 inputs to choose from. Any more than 5 means a Select control is a better field choice.
Checkbox inputs are used when providing the user a small set of options to choose from, with one or many choices allowed. The inputs should be logically ordered and it’s best to have no more than 5 inputs to choose from.
The options listed below can be used on fields to show additional, helpful information.
With Required Labels
Required labels are important aids to help the user correctly complete a form. They are recommended in complex forms where there are multiple fields, or in any situation where there is a combination of required and optional fields.
Required label sizes correspond to the field size automatically since labels are included on all fields.
A Required label is not necessary in simpler forms with a 3 or fewer fields, when required is implied (for example a Log In form with only Email and Password text input fields).
With Placeholder Text
Placeholder text can be used in text input, text area, and select fields to provide a clear example of the correct type of data expected in the field.
They can also be used as examples of how to format data within a field, for example a phone number or search query.
While suggested, there are times where placeholder text is not appropriate — when it would be redundant to the Label. An example would be in a Log In form where a text input field has the label ‘Email’ and the placeholder text was ‘Email Address’. This would be unnecessary unless the placeholder text had more explanation, like ‘Enter your email address…’, and even that is at your discretion.
With Help Text
Help text can also be used below text input, text area, and select fields. It is used to provide additional information — beyond the label and placeholder text — in situations where the user may need some extra help entering the correct data.
A good example being Sign Up forms with a password field where the password needs to be a certain length or has special character requirements. The goal is to help the user get it right the first time, to avoid an error state.
Placeholder text is 12px/0.75rem, Nonessential Color for all field sizes.
The states listed below are either based on default browser interactions (hover, disabled, etc.), or to reflect things like form submission errors.
Focus states are used to show that a field is active during tab interactions. These are important to help with keyboard navigation of forms.
Disabled states are used to prevent the user from interacting with a field until a certain condition is met. To convey this state, the entire field should be at 20% opacity, and on hover the default cursor should display (instead of a cursor specific to that field like a text input cursor).
They should be used sparingly, but are a good way to prevent error states or incorrect choices in complex forms. A better pattern than disabled states are hiding fields until they become relevant. This reduces cognitive load and creates a clearer path through the form — especially when the fields change based on certain selections above.
One exception to that rule would be with submit buttons in forms. These buttons should never be hidden, but can be disabled (using the button’s disabled state) until the fields are completed as required.
Error states are extremely important in Forms. In the unfortunate circumstance of incorrect form submission, we need to provide very clear and helpful error states so that the user can fix the issue and resubmit successfully.
This is done through color and copy. Both should highlight the field(s) in question, and provide clear instructions on how to fix the error.
In an error after submission, each field in question should get a red color border, and the help copy should be updated with instructions as to why the data in the field was incorrect.
Additionally, if there was any data in other fields that were not related to the error, it should be preserved. Clearing all fields after a submission error should always be avoided. Only the fields that were related to the error should be cleared.
The goal obviously being to prevent errors from happening at all (through good labels, placeholder text, and help copy), but should an error happen on submission, the goal is to help the user fix it on the very next try. Nothing is worse then an endless error cycle.
The following are also important to consider when designing Forms and using the defined fields.
The mobile web is extremely important for Hudl. A majority of our web traffic comes from handheld devices. Because of this it’s important to leverage the field behaviors on mobile browsers — especially when it comes to triggering the proper keyboard for a specific field type.
An example of this is an email field, or a number field. Passing in the correct type to a text input will ensure that the proper keyboard is shown on the device, making input much easier.
A good summary of the available mobile input types can be found here.
As you probably realized, most of the Uniform Design Language definitions (not just with Forms) are specific to the web. We are starting with the web since it has the most technical and design debt within our product, but we also plan on providing guidelines for mobile (iOS and Android) as soon as possible.
In the meantime, it’s best to lean heavily on the guidelines for native controls defined by the specific platform. For iOS that is the HIG, for Android that is [Material] (https://material.google.com/).
Always default to the platform before going custom — especially in lieu of any official Uniform guidelines.
What about more advanced fields?
These Form styles only cover the basics, for now. We focused on defining styles for base HTML form elements, but in a way that will give us a solid foundation to improve on in the future.
More advanced elements will come soon that will build upon these base styles. An example being Advanced Select (with type-ahead, filtering, multi-select), Custom Input fields for things like phone numbers and credit cards, and more.
If you’d like to use these styles in static mockups, there is a Sketch file available.
A Sketch file with with UI elements used to design Hudl interfaces.