The 4 Pillars That Support a Scalable Design System
Every building needs a solid foundation, four walls, and a roof. Without these elements, it's not a building — it's a pile of materials waiting to collapse.
Thiago Saraiva
The 4 Pillars That Support a Scalable Design System
Every building needs a solid foundation, four walls, and a roof. Without these elements, it's not a building — it's a pile of materials waiting to collapse.
Design Systems work the same way. There are non-negotiable elements that must be present for the system to work, scale, and survive over time.
These elements are the 4 Pillars of Frontend Architecture.
Pillar Overview
| Pillar | Focus | Question It Answers |
|---|---|---|
| Code | HTML, CSS, JavaScript | "How do we write code?" |
| Process | Workflow and tools | "How do we work?" |
| Testing | Quality and confidence | "How do we know it works?" |
| Documentation | Knowledge and continuity | "How do we preserve knowledge?" |
Let's explore each one.
1. The Code Pillar
At the end of the day, every website is a bunch of text files and media assets. When we look at the amount of code produced in a web project, it becomes clear that we need to set expectations for the code we write.
What this pillar covers:
- HTML — How do we structure our markup? Do we use components? Templates?
- CSS — Which methodology? BEM? CSS Modules? Tailwind? CSS-in-JS?
- JavaScript — Which framework (if any)? How do we organize logic?
Questions to answer:
- What's the acceptable level of CSS nesting?
- How do we name classes and components?
- Where does business logic vs. presentation logic live?
- How do we ensure visual consistency?
2. The Process Pillar
We're far from the "connect via FTP, edit the file, save" workflow. Today, our process involves version control, bundlers, preprocessors, documentation tools, test suites, and server automation.
What this pillar covers:
- Development environment — How does a new dev start working?
- Build process — How does source code become production code?
- Deploy — How does code get to production?
- Collaboration — How does the team work together?
Modern tools in this pillar:
| Category | Tools |
|---|---|
| Bundlers | Vite, esbuild, Turbopack |
| Version control | Git, GitHub/GitLab |
| CI/CD | GitHub Actions, GitLab CI |
| Package managers | npm, pnpm, yarn |
The paradigm shift
The workflow has also evolved in terms of when frontend enters the project:
Before:
Design → Backend → "Make the HTML look like the PSD"
Now:
Requirements → Browser prototyping → Components → Integration
This inversion means we often write all HTML and CSS before the feature is implemented on the backend.
3. The Testing Pillar
To create a scalable and sustainable design system, we need to ensure that yesterday's code isn't devalued by today's code. Code doesn't exist in a vacuum — it's part of a larger system.
Types of tests in this pillar:
| Type | What it tests | Modern tools |
|---|---|---|
| Unit Tests | Isolated functions | Jest, Vitest |
| Integration Tests | Components together | Testing Library |
| E2E Tests | Complete flows | Playwright, Cypress |
| Visual Regression | Visual changes | Chromatic, Percy |
| Performance | Speed and weight | Lighthouse, WebPageTest |
Why tests matter in Design Systems:
Imagine you style a button. Weeks later, someone changes a CSS variable "by accident" and your button breaks in 47 different places. Without tests, you only find out when the client complains.
With tests, you find out before the merge.
4. The Documentation Pillar
"It seems that nobody sees value in documentation until a key team member is about to leave — then it's 'stop everything and document everything'."
Documentation isn't something you do at the end. It's something you do alongside development.
Types of documentation:
- Style Guide — Colors, typography, spacing
- Component Library — Components and their variations
- Pattern Library — UI patterns and when to use each
- Onboarding Docs — How new devs get started
- Decision Records — Why decisions were made
Modern tools:
- Storybook — Interactive component documentation
- MDX — Markdown with JSX for rich docs
- Notion/Confluence — Process documentation
How the Pillars Connect
The pillars don't exist in isolation. They reinforce each other:
- Process defines how Code is written
- Testing validates that Code works
- Documentation preserves Code and Process decisions
- Testing is executed through Process
Important: It's Not a Recipe
These pillars don't prescribe the only way to do something, or even the best way. Every decision needs to be made in the context of your project.
A small, temporary project might not need the same level of foundation as a corporate portal that will last years.
Sometimes the right decision is to do nothing. That's architecture too.
How to Start
If you're starting a new project or wanting to improve an existing one:
- Evaluate each pillar — Where are you strong? Where are you weak?
- Prioritize — Don't try to fix everything at once
- Document decisions — Even the small ones
- Iterate — No architecture is born perfect
And remember: being a Frontend Architect means constantly learning. Our "a little bit of everything" understanding is what allows us to evaluate new technologies and methodologies quickly.