There are two ways to build a website. You can design every page as a unique composition... or you can design a system of components and compose pages from them. The first approach is how most teams start. The second is how every team that ships consistently ends up.
Component-based design is not a framework choice. It is a mindset shift. Instead of asking "what does this page look like," you ask "what reusable pieces does this page need?" That question changes everything about how you design, build, and maintain interfaces.
Why Pages Are the Wrong Unit
When you design page by page, you get page-by-page inconsistency. The button on the homepage is 44px tall. The button on the pricing page is 40px. The contact form uses 16px input text. The signup form uses 14px. Nobody intended the inconsistency... it just accumulated.
The Atomic Design methodology that Brad Frost introduced reframes the problem. Instead of designing pages, you design at five levels: atoms (buttons, inputs, labels), molecules (search bars, form fields), organisms (navigation bars, hero sections), templates (page layouts), and pages (specific instances).
The insight is that pages are assembled from smaller pieces, and those pieces should be designed once and reused everywhere. A button is a button regardless of which page it appears on. If it looks different on different pages, something is broken.
This is not just a design philosophy... it has direct engineering consequences. When components are the building blocks, adding a new page means assembling existing pieces, not building from scratch.
Designing Components, Not Screens
The shift from screen-based to component-based design requires different deliverables from your design team. Instead of a Figma file with 20 page mockups, you need a component inventory with detailed specifications for each piece.
Start With an Inventory
Before designing anything new, audit what exists. Screenshot every unique UI pattern across your current site or application. You will find redundancy you did not know about. Most sites have 5-10 variations of things that should be 1-2 components.
Group similar patterns together. Those groups become your components. A card is a card whether it shows a blog post, a product, or a team member. The content changes; the structural pattern stays the same.
Define the Variants
Every component needs a clear set of variants. Not infinite flexibility... constrained options that cover real use cases.
A button component might have:
- Sizes: small, medium, large
- Variants: primary, secondary, ghost, destructive
- States: default, hover, active, focus, disabled, loading
That is a finite set of combinations. A developer can implement all of them. A designer can document all of them. And when someone needs a button, they pick from the menu instead of designing a new one.
The key is resisting the urge to add variants for every edge case. Every variant is maintenance burden. If a variant is only used on one page, it probably should not be in the component library.
Design With Real Content
Components designed with "Lorem ipsum" break the moment they encounter real content. A card that looks great with a 50-character title falls apart with a 120-character title. A navigation bar that works with 5 items is unusable with 12.
Design with the longest, shortest, and ugliest content your component will encounter. This is where Storybook becomes invaluable... you can test every content variation in isolation before it appears on a real page.
The Design-to-Code Translation
The biggest pain point in component-based design is the handoff between design and engineering. A component in Figma and the same component in React can drift apart fast if there is no shared language.
Design tokens bridge this gap. When both Figma and code reference the same token values for colors, spacing, typography, and elevation, the translation is mechanical rather than interpretive.
| Design Token | Figma Value | CSS Variable |
|---|---|---|
| color-primary | #0F172A | --color-primary: #0F172A |
| space-4 | 16px | --space-4: 1rem |
| font-heading | Inter Bold 24px | --font-heading: 700 1.5rem Inter |
| radius-md | 8px | --radius-md: 0.5rem |
When a designer changes the primary color in the token system, the code updates automatically. No more "the design uses #0F172A but the code has #1A202C." The token is the source of truth.
Component APIs: The Contract Between Design and Code
Every component has an API... the props it accepts, the content it renders, and the behavior it supports. Designing this API is as important as designing the visual appearance.
Good component APIs follow the React principle of thinking in components:
- Single responsibility. A component does one thing well. A Card displays content in a card layout. It does not also handle navigation, data fetching, or form submission.
- Composition over configuration. Instead of a Card component with 15 props, build CardHeader, CardBody, and CardFooter components that compose into any card layout.
- Sensible defaults. The most common use case should require the fewest props. A Button with no variant prop should render as the primary variant because that is what people use 80% of the time.
- Accessibility built in. ARIA attributes, keyboard navigation, focus management, and color contrast should not be optional. They should be part of the base component.
Accessibility Is Not Optional
Component-based design gives you a unique opportunity with accessibility. Build accessibility into the component once, and every instance across your entire site inherits it. Skip it, and every instance is broken.
The WCAG guidelines are the standard. At a component level, that means:
- Every interactive element is keyboard-accessible
- Color contrast meets AA standards at minimum (4.5:1 for normal text, 3:1 for large text)
- Focus states are visible and logical
- Form inputs have associated labels
- Dynamic content updates are announced to screen readers
- Touch targets are at least 44x44 pixels
When these rules are enforced at the component level, accessibility becomes a system property rather than a per-page checklist. That is the power of component-based design... get it right once, and it propagates everywhere.
How We Approach Component-Based Design at Last Rev
At Last Rev, component-based design is not a phase of the project... it is the foundation. We start every engagement by defining the component library before designing any pages. The components are designed in Figma, built in code, documented in Storybook, and mapped to CMS content types.
The result is a design system that designers, developers, and content editors all work from. New pages get assembled in hours instead of days. Brand consistency is enforced by the system, not by review processes. And the codebase stays clean because every UI pattern is defined once and used everywhere.
Want to build a component system that scales with your team? Let's design it together.