Size

Ensure balance and coherence in each context aligned with the hierarchy and information density.

Sizing

Maturity

Beta

FYQ2 target

Beta

Repository

-

Overview

When it comes to establishing a hierarchy, size is critical. More prominent elements naturally draw more attention and are seen as more important. We use predefined size sets to ensure balance and coherence in each context and align with the hierarchy and information density.

Related content


Scale

Our predefined base eight sizing scale helps makers layout elements consistently, allowing flexibility.

When creating any component or designing a screen, make sure you use one of the values below:

Sizing / Size
16px
16px
size.XS
Icons
Code token
size.XS
Token set
Product/App
24px
24px
size.SM
Icons, Figures, Badges
Code token
size.SM
Token set
Product/App
32px
32px
size.MD
Icons, Figures, Dense interactive controls
Code token
size.MD
Token set
Product/App
48px
48px
size.LG
Figures, Loose interactive controls
Code token
size.LG
Token set
Product/App
72px
72px
size.XL
MainNav, TopBar
Code token
size.XL
Token set
Product/App

Usage

Information density and size

High-density components can improve the experience when people are presented with and interact with large amounts of data.

Dense density (default)

Dense sizing - TopBar
Dense sizing - Toolbar
Dense sizing - Menu
Dense sizing - Lists

Increasing the density of lists, tables, or toolbars can make viewing and interacting with screen content easier. For this, we have the Dense density, which uses the size-md size.

32px
32px
size.MD
Icons, Figures, Dense interactive controls
Code token
size.MD
Token set
Product/App

Loose density

Loose sizing - Forms
Loose sizing - ActionBar
Loose sizing - Dialog
Loose sizing - Empty state

However, when a person performs or finishes a specific main task, like filling out a simple form, editing large amounts of data, or confirming an action, we'll use the Loose density, which uses the size-lg size.

48px
48px
size.LG
Figures, Loose interactive controls
Code token
size.LG
Token set
Product/App

Minimum target sizes

Enhancing the clickable area size allows people to complete actions faster and prevents triggering accidental interactions for people with motor disabilities. Our interactive controls follow the WCAG 2.1 success criterion for target sizes, establishing a 48x48px target area for interactive elements, regardless of their contents.

Target areas

But to prevent accidents and be forgiving with people, we must also ensure that our controls are not too close to each other by adequately spacing controls.

Related content

Maximum and minimum sizes

Defining maximum and minimum sizes is an excellent way to create adaptive components that remain understandable and accessible.

Sometimes—as in our Buttons—we might need a component with a minimum width regardless of its content, ensuring the clickable area meets our usability and accessibility requirements.

⛔️ When a minimum width is not defined, buttons with short labels may become too small.

⛔️ When a minimum width is not defined, buttons with short labels may become too small.

✅ By applying a MinWidth to the container, we can maintain a reasonable width for the target area.

✅ By applying a MinWidth to the container, we can maintain a reasonable width for the target area.

And sometimes, we need components to do the opposite: stop growing even if the content is very dense or the viewport/container size increases, as in our Tooltips.

⛔️ Without a max-width, our tooltips would grow horizontally with no limits, making them harder to read and relate to their parent trigger.

⛔️ Without a max-width, our tooltips would grow horizontally with no limits, making them harder to read and relate to their parent trigger.

✅ Applying a max-width to the component, we reduce the area, ease the reading and keep it in context.

✅ Applying a max-width to the component, we reduce the area, ease the reading and keep it in context.

Fixed sizes

Defining fixed sizes for containers can cause issues with overflowing content and a broken/non-accessible user interface, so it's generally not recommended. However, in certain cases, specific element measures may be necessary.

Navigation

Our TopNav and MainNav use fixed height and width to keep the Application Frame consistent throughout the app experience.

⛔️ Allowing content inside a container to grow without a defined size can lead to overlapping important content and a broken user experience.

⛔️ Allowing content inside a container to grow without a defined size can lead to overlapping important content and a broken user experience.

✅ A container with a fixed size can maintain the position of its content.

✅ A container with a fixed size can maintain the position of its content.

Quality checklist

This element passes the following requirements described in our Component lifecycle.

Maturity

Beta

α · Design tokens

It uses Ariane design tokens.

α · Naming agreement

Its name is agreed upon and shared between design and development.

α · Responsive L1

Is responsive to different viewport sizes.

β · Responsive L2

The responsive behavior has been reviewed and validated by the team.

β · Docs L1

It has essential documentation with at least primary usage.

β · Use cases

All the uses are audited and refined.


Acknowledgements

  1. Applying density — Material Design