Skip to main content
Our component sizing policy gives designers the flexibility and ownership to make strategic decisions based on UX reasoning. This ensures that every choice solves a specific user need while upholding consistency.

How We Approach Sizing

To balance flexibility with consistency, we recommend the following approach to component sizing:
  • Default Sizing: Always use the default size for a component unless there’s a strong UX reason to change it.
  • Diverging from Default: It’s crucial to diverge from a default size only when there is a clear UX benefit, not just for visual preference. This ensures we maintain consistency where it’s most needed while providing the flexibility for unique edge cases.

Why Use Defaults?

While we provide options to diverge from our defaults, using the default most of the time is a strategic choice that benefits both the user and the team.
  • Consistency: The default provides a predictable baseline that ensures a unified look and feel across the entire platform. When users see a standard-sized component, they intuitively understand its purpose.
  • Clarity: Using defaults simplifies the design process and reduces the need for custom styling, making it easier for design and development teams to align.
  • Hierarchy: By using the default size for most components, you give more visual impact to the few exceptions that have a clear UX justification for being a different size. This helps to guide the user’s eye to the most important elements on the page.
  • Efficiency: It allows designers to focus on core user experience problems, such as content and flow, instead of debating minor visual preferences.

When to Diverge from Default

Diverging from the default size is a strategic choice with a clear UX benefit. Here are a few key use cases that justify a change in size:
  • For Dense Information Displays: Diverge to small for interfaces like data tables or dashboards. A small component size allows more information to fit on the screen at once, improving scannability without sacrificing readability.
  • For Primary Calls-to-Action: Diverge to large for crucial buttons on a page. A large size gives a button more visual weight, clearly guiding the user to the most important action, such as “Submit” or “Create New.”

What a “Strong UX reason” Means

A strong UX reason ensures a design choice is strategic, not subjective. This can be accomplished through various research methods:
  • User Testing: Observing users as they complete tasks can provide direct evidence that a change in component size improves task completion rates, reduces errors, or increases efficiency.
  • Existing Data: Reviewing product analytics, user feedback logs, and support tickets can help you identify existing pain points where a change in component size could be a potential solution.
  • Competitive Analysis: Reviewing how industry-leading applications handle similar use cases can reveal a validated best practice. This helps you determine if a particular sizing choice is a standard that users already expect.

Accessible Target Area

If a component’s size violates WCAG guidelines, its target area must be increased to ensure accessibility. This is done by adding sufficient margin around the component to meet the required minimum size for safe interaction. For more information, please refer to the official WCAG guidance on safe target areas: Understanding Success Criterion 2.5.8: Target Size (Minimum).

Feedback

Your feedback is crucial for the success of this policy. If you find a default size is inconsistent with other components or if you encounter difficulties using only the defaults, please reach out. You can find us in #ask-designsystem on Slack or schedule an office hour with us.
Last modified on January 23, 2026