Buttons
Buttons are triggers that provide users with a call to action. Typically allowing users to execute, choose, submit and confirm actions.
FT Buttons
FT buttons are those that are designed for FT’s digital products, with FT branding.
- Icon (optional): Most buttons don’t need an icon. Use an icon to add additional affordance where the icon has a clear and well-established meaning.
- Label: Text that explains the result of selecting the button. Use action verbs or phrases to tell the user what will happen next.
- Container: has minimum width of 80px for standard buttons and 64px for small buttons.
Usage Guidelines
Keep button labels short
Keep labels short and free of punctuation. They should confirm the action a user is taking. Drop unnecessary articles, such as ‘a’ or ‘the’, for a more concise label.
Use sentence case for button labels
Only capitalize the first letter of the button and any proper nouns. Not title case or Upper case.
Don’t use more than one primary button
Each page or product area (a form, modal, within an article) should not have more than 1 primary button to help guide the user to the primary action. Any remaining CTA’s should be displayed as secondary or ghost buttons.
Avoid disabled buttons without user research
Avoid disabled buttons unless user research shows they improve your interface. Disabled buttons have poor contrast which makes them difficult to read. They also do not give feedback to a user why they are disabled. This has caused issues for FT readers in the past, and has been flagged in previous accessibility audits.
Hampus Sethfors explains the issues with disabled buttons in more detail in an axesslab.com article. In the article Hampus suggests alternative design approaches for common uses of disabled buttons.
Don’t use full width buttons in wide containers
Instead use fluid buttons, which are full-width for small devices or containers up to around 400px width. Otherwise, button width should default to its content length.
Width
A button’s width is dependant on the length of its content by default. Alternatively buttons may be “fluid”, and stretch to fill the full width of their container.
We recommend buttons are fluid until around 400px, after which the button should be determined by the length of its content.
(Resize your browser to preview the fluid button’s responsive width)
Icons
Buttons may be used with icons, without icons, or only icons.
Without icon
With icon
When icons are used, these are always left aligned.
Only icon
Sizes
The button comes in two sizes: standard and small.
Standard
Small
Types
There are three types of buttons to support different contexts.
Primary
The primary button is used for the most important calls to action on a page. Primary buttons should only appear once per product area (not including the application header, modal dialogue, on-site messaging, or side panel).
Secondary
For secondary actions on each page or used in conjunction with a primary button. As part of a pair, the secondary button’s function is to perform the negative action of the set, such as “Cancel” or “Back”.
Ghost
For the least pronounced actions; often used in conjunction with a primary button. In a situation such as a progress flow, a ghost button may be paired with a primary and secondary button set, where the primary button is for ‘Save and continue’ the ghost button would be ‘Skip’.
Themes
Each button type supports the following themes.
Standard
Inverse
An alternative theme for use on dark backgrounds.
Mono
Mono can be helpful where the standard theme distracts from other colour used, for example when placed near data visualisations.
FT Button Groups
Buttons may be grouped to combine related buttons together which present users with a set of related, frequently used actions or options in a compact and organized manner.
In terms of user experience, button groups provide a straightforward way for users to perform actions within a single context, emphasizing action over navigation.
<ButtonGroup> <Button label="Hello" type="secondary" attributes={{ "aria-selected": true }} /> <Button label="World" type="secondary" /></ButtonGroup>;<div class="o3-button-group"> <button class="o3-button o3-button--secondary" aria-selected="true"> Hello </button> <button class="o3-button o3-button--secondary">World</button></div>Usage Guidelines
Use grouped buttons for related actions
Group related actions or options closely together to improve usability and decision-making efficiency. For example, use for switching views or modes within the same context, such as changing calendar views from day, week, to month
Don't use grouped buttons for navigation
Use tabs instead to imply navigation between different content areas or contexts within the same workspace.
Limit the number of buttons in a group
Never use groups of more than six buttons, as too many calls to action can cause users to be unsure of what to do next. Also be thoughtful about how multiple buttons will look and work on small screens, this may vary according the the length of the button’s label.
Single Sign On
Single Sign On (SSO) buttons allow users to sign in or sign up using 3rd party platforms. We provide the visual style of these and leave platform integration to the developer.
Usage Guidelines
Sign up vs Sign in
Ensure consistent wording for different user flows. This may be changed if needed, but refer to Apple and Google guidelines below on appropriate wording. We recommend:
- “Sign in with [Provider]” for login
- “Sign up with [Provider]” for registration
Responsiveness
The SSO button spans the full-width of its container to increase tap area on mobile, up to a maximum width of 4 grid columns on tablet and desktop. When used with form fields, always align SSO button width to ensure consistency.