Components are the main building blocks for user interfaces. Building a reusable component library enhances your product development workflow by reducing design and tech debt and speeding up the process. Core components can’t be broken down into granular pieces without losing their meaning.

Always provide a description for screen readers describing what’s displayed on the avatar image instead of just naming its role.

Accessibility

When used with icons or text, there has to be a background colour from the design system colour tokens applied to the avatar shape. Make sure that icons and text have enough contrast ratio with the background according to the WCAG AA standard.

Background colours

Avatars can be used with an icon instead of an image to emphasize areas that don’t necessarily have (or need) an image associated with it.

Icon

Avatars should mask an image into their shape and work with any image size since they may get this image from unknown data sources.

Image

There should be fallbacks when there’s no image available. This can be done with placeholder images or initials.

Image fallback

There are many contexts to use avatars and they all require different sizes for the component. For average projects use at least 2-3 different sizes and make sure there’s at least a small size available.

Sizes

Avatars are used to show a thumbnail of a user photo or a visual representation of any other type of content.

Avatar

Badges may play various roles in your product and having a predefined colour for each role should help users understand their meaning. When changing colours, make sure the text has enough contrast ratio with the background according to the WCAG AA standard.

Appearance

Badges can be used as a dynamic way to display selected values and there should be a way to dismiss them.

Dismissible action

Badges are elements that represent the status of an object or user input value.

Badge

If a banner dynamically appears on the page, it should be announced to the user by their assistive technology.

Actions in banners should relate to its text and provide a way to react to the message sent to the user.

Actions

Banners are used to display different types of messages and it’s important to differentiate their visual appearance based on the role they’re playing. If you’re using background colours for role differentiation, make sure there’s enough contrast ratio with the content according to the WCAG AA standard.

Don’t overwhelm the user with banners on the page and include a dismissable action. That may be either a separate close button or one of the actions provided.

Banners can supplement their message using a supporting icon or image. They shouldn’t be used instead of text content.

Area for icons or images

Banners should adapt to the viewport size. This usually means that they become full-width for mobile to save some space.

Responsiveness

Banners display an actionable message used as a prominent way of communicating with your users.

Banner

Used when a button gets pressed. The same state can be used to represent the button responsible for toggling another element on the page while that element is visibly opened.

Active state

Visually shows that a button is not interactive and restricts it from being pressed.

Disabled

Used when a button gets selected through keyboard navigation.

Focused state

By default buttons take the width of their content, but they should also come with a full width variant that works well in mobile devices.

Full-width

Clearly show that the button is interactive when it gets hovered with a mouse cursor.

Hover state

Icons easily communicate the purpose of the button when used next to its label or can be used without text when there’s not enough space. Make sure that the accessibility label is provided when used with an icon only.

Icon support

Used when users have to wait for the result of their action after they press a button. If a spinner is used to display this state make sure that it’s not changing the original button width or height.

Loading

Buttons can be used in different areas of the website and may have multiple predefined sizes. On mobile, tappable areas have to be a minimum of 48px to be accessible according to iOS and Android accessibility guidelines.

When using multiple buttons, there should be a way to differentiate between primary and secondary actions. Buttons may play different roles for the user or be used on different types of surfaces and they have to change the way they look.

Variants

Buttons are interactive elements used for single-step actions.

Button

Cards can be used with actions usually placed at the bottom of the card, or the card itself can be tappable and represent an action.

Supplementary actions

Cards are one of the most used components in the product, so they have to be flexible enough to support any other components placed in them.

Supports any type of content

One of the most popular scenarios for using cards is mixing them with media content. The most popular options are having a full-width area on top of the content or full-height area at one of the card’s sides.

Supports media sections

On mobile viewports cards are usually full-width in order to save space for the content.

No matter how flexible cards are, it’s important for cards to have a specific structure for its elements for product consistency.

Information structure

Cards are used to group information about subjects and their related actions.

Card

Used when the checkbox is selected and will use its value for the form submission.

Checked state

Prevents checkbox interactions and removes its value from the form submission.

Disabled state

The error state is used for form validation errors when the error is related to the checkbox field only. Always use a text error along with changing the colour of the field.

Error state

Checkboxes can be grouped to work with multiple values at the same time.

Checkbox group

Used when the checkbox has children selectable elements and only some of them are selected.

Indeterminate state

Checkbox selections should be triggered with the Space key. Using native elements for this should provide this kind of interaction out of the box.

Keyboard support

There should be a text label linked with the checkbox field. Clicking the label should also trigger the checkbox selection.

Label

An input checkbox is a form element used for selecting one or multiple options.

Input checkbox

Either some actions inside the dropdown should close it or there should be a separate close button. Also, it’s good practice to close the dropdown when a user clicks outside.

Close action

Dropdowns may be used in a lot of contexts like date pickers, language selection or other product features.

It should be possible to navigate through dropdown children elements with the keyboard and close it with an Esc key.

Keyboard navigation

One of the most used scenarios for dropdowns is providing an action menu for the user, so it’s useful to have this layout defined.

Action menu

Dropdown content should be adapted for mobile viewpoints as it may take a lot of space on desktops.

Dropdown content should be displayed based on the current position of the trigger element on the screen and always visible to the user.

Dynamic positioning

Once the dropdown’s opened, the focus should work only for elements inside the dropdown. When it’s closed, the focus should move to the dropdown trigger.

Focus trapping

Dropdowns are used to display a contextual subview with a list of actions or content related to the area where the dropdown is.

Dropdown

Icons should be using values from the design system colour palette. Using parent element text colour for icon fill colour can make this automatic.

Colours

Icons should have a number of predefined sizes to provide a holistic experience across the product. Typography pairings may be used for these size values to ensure that they are aligned with the text sizes.

The icon component is a way to align the way iconography static assets are displayed in the product.

Sometimes lists are used for grouping tappable components, where the whole area of the list item should be clickable.

Supports actionable content

Lists can be used in any context from page-level layout to managing offsets between granular components. hey should work with any component used inside.

Lists with dividers are the best practice advised by many platform guidelines (especially on mobile).

Divided variant

Lists can be used for inline elements and they have to manage how they’re stacked horizontally, including handling offsets between multiple rows of elements.

Horizontal stacking

Lists define the layout of the page content or groups of elements stacking them vertically or horizontally.

List

The loading indicator should respect its parent element background and provide a variant to be used on darker background colours.

Light variant

The loading indicator should be synced with the system motion settings and reduce its animation speed when reduced motion settings are turned on.

Reduced motion

Depending on the context and the component it’s used for, the loading indicator can be represented either with linear or with a non-linear (e.g. circular) variant.

Linear and non-linear variants

In some cases, the wait time can’t be determined. The loading indicator should be shown until the loading finishes or an error happens. In other cases, it’s better to indicate how much time’s left until the loading is done.

Determinate or indeterminate wait time

The loading indicator shows that an operation’s being performed and how long the process will take.

Loading indicator

Since content in the modal may be actionable, it’s important to have an area for action elements. This area is usually located at the bottom of the modal container.

Modals should provide a clear way to be closed as they’re blocking content when open. This may be either a separate close button or one of the supplementary actions.

It should be possible to close a modal by pressing the Esc key and all the focusable elements inside the modal container should be accessible with keyboard navigation.

Keyboard navigation support

Even though modals can be used as an empty container for the content, they need a defined information structure to provide a holistic experience. It may include defining how titles and subtitles look by default or where an action element’s area is.

Like any other container, modals can be used in different scenarios and you should be able to use it with any other component inside.

Once a modal is opened, the focus should be moved to the first element inside the modal and should be looped within the modal container. Closing the modal should return the focus to the last focused element on the page.

Modals are containers appearing in front of the main content to provide critical information or an actionable piece of content.

Modal

Used when the radio is selected and will use its value for the form submission. A radio input can’t be unselected by pressing it again.

Prevents radio interactions and removes its value from the form submission.

The error state is used for form validation errors when the error is related to the radio field only. Always use a text error along with changing the colour of the field.

Radio inputs should always be used in a group. If  one of them is selected, it can be deselected only by choosing another radio.

Radio group

A radio selection should be triggered when the Space key is pressed. Using native elements for this should provide this kind of interaction out of the box.

There should be a text label linked with the radio field. Clicking the label should also trigger the radio selection.

An input radio is a form element used for selecting one option from a list.

Input radio

Used when an input switch is turned on. It’s better to provide an additional way to indicate the checked state besides changing its colour when applicable.

Prevents interacting with an input switch.

A switch selection should be triggered when the Space key is pressed.

There should be a text label linked with the switch field. Clicking the label should also trigger the input selection. 

Input switches toggle the state of a single item. Compared to the input checkbox, their changes usually apply without any additional submission.

Input switch

There should be a clear differentiation between selected and unselected tab buttons.

Active button state

Tabs can be used in a relatively small-sized container where you need to switch between a definite number of sections. For such scenarios, it’s better to support a variant where the button’s area is divided equally.

Equally-sized tab buttons

Icons help show the purpose of the tab buttons when used next to its label.

Button icon support

All tab buttons should be focusable and navigation between the tab’s component should be accessible from the keyboard.

If all tabs on mobile don’t fit into the viewport, users should still have access to all tab buttons. Ways to solve this can be making the button area scrollable for mobile or showing a More button containing a dropdown with the rest of the buttons.

Tabs organise navigation between multiple pages or content sections.

Tabs

When applicable, adding support for the HTML autocomplete attribute will allow users to easily enter different data types.

Autocomplete

Prevents input interactions and removes its value from the form submission.

The error state is used for form validation errors when the error is related to the text field only. Always use a text error along with changing the colour of the field.

The focused state should highlight the text field when users start to interact with it. There is always only one focused field in the form.

Icons are used to describe input methods, express a text field state or provide additional functionality.

There should be a text label linked with the text field. Clicking the label should move the focus to the field.

When there’s no value entered, show a placeholder with a potential value example. Don’t use placeholders as labels for the inputs.

Placeholder

Input text lets users enter and edit text.

Input text

Toast messages should be announced by the voice assistive technology and their action should be easily accessible from the keyboard.

Besides displaying the message, toasts may also provide an action related to the message like undoing an action.

Action support

Toast messages shouldn’t interrupt the user flow, block the screen for a long time or require additional action from the user.

Dismissed automatically

Toasts should be aligned with the mobile viewport and their action should be easily reachable for tapping.

Even though it doesn’t happen often, toasts can be called from multiple sources at the same time and all resulting toasts should be queued. It’s good practice not to show all the messages at the same time.

Handles multiple instances

Toasts provide short meaningful feedback messages about the action results.

Toast

If there’s a group of elements using tooltips, hovering over another element while a tooltip’s already active shouldn’t trigger the animation.

Instant transition for element groups

Tooltips should be accessible when an element is focused using the keyboard.

Keyboard hover support

The tooltip should respect its parent element background and provide a variant to be used on darker background colours.

Tooltip content should be displayed based on the current position of the trigger element on the screen and always visible to the user.

Having a small timeout before triggering a tooltip will help to prevent occasionally showing tooltips while users move their mouse cursor.

Hover timeout

Tooltips are desktop-only components that display additional information when hovering over or focusing on an element.

Tooltip

Core components

Like any language, a design language is a methodical way of communicating with your audience through your approach to product design. It’s the cornerstone of consistent customer experiences.

The considerations that guide the basis of your practice. They outline how you approach design from a philosophical perspective and help with everyday decisions.

Design principles

Create the standard terms and phrases that need to be kept the same throughout the user experience, speeding up the design process and unifying your voice.

Terminology

A clear tone of voice defines how you speak to your audience at every moment in their journey, helping them get wherever they want to go.

Tone of voice

Why you exist, what your values are and how they’ll help guide the future of your product.

Vision

Every consistent experience needs watertight writing. Laying down the foundations for your house style early keeps everything in line with consistent grammar, style choices and action-oriented language to help your design.

Writing guidelines

Brand drives every single decision you make when building new products or features. A good brand is much more than a name and a logo. It’s the values that define your unique identity and what makes you stand out from others.

Brand

Guidelines for how you approach accessibility and how you leverage colour, hierarchy and assistive technologies to help your users.

The standard way to write for the components in your design system. These take platform conventions and best practices for writing all into consideration.

Microcopy guidelines

How you onboard your users to your product or a new feature and give them a great experience from the start.

User onboarding

Providing guidance on how to approach common UX patterns will allow your organisation to establish a consistent approach and a consistent user experience on any platform.