Guideline for primary Primary buttonsGuideline for secondary
Guideline for tertiary Tertiary buttonsGuideline for destructive buttons
Buttons are used to help the users carry out important actions. There are four types of buttons: primary, secondary, tertiary and destructive. It’s important to remember that a button represents an action, whereas links navigate the user somewhere. Use of buttons, labels and their types should be consistent throughout the entire application. It’s important to note that buttons are not the same as links. For more information on button labels, see the section on buttons in Guidelines for content the article on Content writing.
Types
Primary
Primary buttons are the main call-to-action (CTA) on a page. They are strategically positioned and visually distinct to help guide users toward the important action or way forward on a page. Because of this, there should only ever be one primary button per page.
For a detailed explanation of how to use primary buttons, please see the Guidelines for primary Primary buttonsarticle.
Secondary
Secondary buttons are used for alternative, less important actions such as "previous/next" buttons in a form or the “cancel” button in a modal. They may be used more then once per page and are often paired with primary buttons.
For a detailed explanation of how to use secondary buttons, please see the Guidelines for secondary Secondary buttons article.
Tertiary
Tertiary buttons are used for reduced-importance actions that are not essential to the main task, such as "Edit", “Favorite” and "Delete". Tertiary buttons may be used more than once per button group and more than one tertiary button can be used on a single page.
For a detailed explanation of how to use secondary buttons, please see the Guidelines for tertiary Tertiary buttonsarticle.
Destructive
Destructive buttons should be used sparingly to warn users of irreversible actions such as deleting data or canceling a request. Their use is meant to help further communicate to the user the importance of considering whether to proceed with the action they represent.
For a detailed explanation of how to use destructive buttons, please see the Guidelines for destructive Destructive buttons article.
Icons
Icons can enhance the usability of buttons, making it easier to scan a page. They should only be used for common actions like save, print, or delete. It's important to choose globally recognized icons to ensure clarity. Research has shown the solid or filled icons are easier for users to recognize.
Icons should always be placed on the left of button text. Maintain a consistent button size of around 24px by 24px, with 12px padding. A great resource for free icons is the FontAwesome icon library. Another popular icon family is from Google’s Material Design. You can use other icon font families as long as the symbol clearly indicates the action. If in doubt, test with users or ask the design community.
Common Icons
Action | Icon | Example |
|---|---|---|
Save | Floppy disk |  |
Delete | Trash can |  |
Printer |  | |
Download | IT appliance with down arrow |  |
Upload | IT appliance with up arrow |  |
Sort in ascending/descending order (this icon should only be used directly beside a column header so users know what they are sorting e.g. Date) | Up/down arrows together |  |
Edit | Pencil and card |  |
Filter | Funnel/ filter |  |
Home | House |  |
Settings | Cog/ gear |  |
Profile | Silhouette of a person |  |
Comment | Speech bubble |  |
Menu | Set of 3 horizontal lines |  |
Responsive design
In order to be inclusive to all users, we need to consider how our applications behave on smaller viewports. (For more information on viewports, see The viewport is the window to your site – Digital.gov.) While designing and building using responsive design principles will allow you to create an optimized layout for users accessing your application on smaller viewports, this is not the only benefit. This will also ensure you are supporting users with low vision who need to enlarge text by using the browser’s zoom function.
To help ensure the responsiveness of your applications, consider the following points when designing buttons:
Preservation of content - Content shouldn’t be removed or changed to view an application on a smaller screen size. Don’t change or remove the icons and/or text of a button when changing the size of the viewport.
Reflow strategy - Determine the breakpoints at which buttons will reflow and a strategy to maintain consistent placement across the application. For example, a button grouping with a primary and secondary button should reflow from being side-by-side on larger viewports to being stacked on smaller viewports. When side-by-side, the secondary button should be to the left of the primary. When stacked, the primary should be on top of the secondary.
Size - Buttons must maintain a minimum width of 160 px regardless of screen size. Increasing the width of buttons may make them easier to interact with on smaller viewports. To prevent text wrapping and ensure buttons don’t exceed the screen width, keep button text short and to the point. 25 characters or less is recommended.
Padding - Buttons must maintain sufficient padding. When positioned side-by-side on a large viewport, a minimum of 32 px of padding should be used. When stacked on a smaller viewport, a minimum of 24 px of padding should be used.
Once your design has been implemented, it’s important to test the functionality in various different viewports.
Technical specifications
Width of the button (minimum 160px) should be the size of the text label with additional padding:
Use 32px of horizontal spacing (white space) between buttons for desktop
Use 24px of vertical spacing (white space) between block-level buttons for mobile
All button text should be written in sentence case
Use a max of 25 characters with spaces
| Info |
|---|
It is important to consider the French translation when designing and placing buttons on an interface since French uses approximately 2.2x more characters than English. |