Not all components are equal.
Ooowee, aren’t we tired of hearin' the word component. It is used a lot these days. Might as well clarify some things.
When designers use it to refer to UI elements, those elements exist at varying levels of the system. Understanding this hierarchy makes it easier to anticipate how components will inherit traits, be governed, and are meant to be reused.
Some components are foundational and support nearly everything in the product. Others capture repeated product decisions. Others exist only to solve a local problem on a single screen.
Using the same word for all of them is confusing. It makes decisions and expectations feel murky, complicates reuse, and makes it harder to imagine how the design system will evolve naturally, and intentionally.
This post introduces a simple mental model designers use: component tiers.
The goal is not to add process. The goal is to give us a shared language so conversations about components become clearer and faster.
The Core Idea
Not all components are equal.
Components live at different levels of abstraction. They have different lifespans, different expectations for stability, and different levels of governance.
Treating them the same leads to predictable problems. Foundational pieces become overloaded. One-off solutions get over-formalized. Teams hesitate because they are unsure what “counts” as system work.
Thinking in tiers helps us avoid those traps.
Tier 1: Foundational Components
The bedrock
Tier 1 components form the structural and visual foundation of the product.
Examples include:
color, spacing, and typography tokens
base primitives such as buttons, inputs, icons, and surfaces
These components are used everywhere. Changes ripple broadly and are costly to reverse.
Because of that, Tier 1 components move slowly. They are intentionally minimal, carefully governed, and resistant to feature-specific customization.
They are less about expression and more about reliability. In practice, they behave more like infrastructure than interface.
Tier 2: Composed and Opinionated Components
Where product decisions live
Tier 2 components combine foundational pieces into recognizable, repeatable patterns.
Examples include:
tables and grids
forms
modals
common workflows
These components encode product and UX decisions that we want teams to repeat consistently. They are designed for reuse, but have intentional limits in place when it comes to flexibility.
Tier 2 components evolve over time. They do change, but with intention and coordination. Governance here exists to preserve clarity, not to slow teams down.
This is where the design system provides the most leverage.
Tier 3: Contextual Components
Feature and screen specific
Tier 3 components exist to solve a local problem in a specific context.
Examples include:
custom assemblies
screen-specific layouts
feature-level UI groupings
These components are allowed to move quickly. They often have limited reuse and may never belong in the shared system.
That is not a failure. It is a sign of a healthy system that can support experimentation without forcing everything into a permanent structure.
Tier 3 gives teams freedom while protecting the integrity of the foundation.
Why This Distinction Matters
When someone asks, “Should this be a component?” the real question is usually about tier.
Understanding tiers helps us:
avoid turning one-off solutions into permanent system commitments
protect foundational components from feature creep
set clearer expectations about stability and ownership
make faster, more confident decisions
Most importantly, it creates a shared vocabulary across design, engineering, and product.
A Simple Rule of Thumb
When deciding where something belongs, ask:
Does this need to be used nearly everywhere? If yes, think Tier 1.
Does this capture a repeatable product or UX decision? If yes, think Tier 2.
Is this solving a local problem right now? If yes, think Tier 3.
None of these tiers are better than the others. They exist to serve different purposes at different moments in the product’s life.
