Featured
Design Systems are Materials. Not Ideas.
Knowing when to introduce design systems into design work
Imagine this…
An architect walks into a pre-fab building supply warehouse to inventory what’s available (pre-built trusses, complete door frames, modular sections from pre-fabricated homes), then turns around and starts assembling them into a space. This materials-first architect eventually pieces together a structure and works backward into a blueprint, one shaped entirely by what was on hand, not what was needed.
There are two ways to respond to this. One is to say, “That’s reasonable. You can’t build anything without materials.” And sure, that’s fair. But the more appropriate response might be: “That’s a little absurd, isn’t it?” Architects don’t design by flipping through what’s sitting in the warehouse. They begin by understanding the purpose of the space: who will use it, what they’ll need, how it should feel, and how it should function. Only after defining those goals do they choose the materials to bring that vision to life.
This is the tension many product teams feel. We rush straight to the materials because we need to make our ideas possible, based on what already exists. But that mindset can erode the very purpose behind the solution. We end up designing based on pre-built parts that “can work,” rather than starting with the raw materials that could support what’s actually needed.
And this is the trap: we’re handed a set of functional requirements, we open the design system, flip through the available components, and start stitching screens together. But this approach (driven by what’s in the yard) often misses the mark. It forgets the problem we’re solving or the effortless experience we’re trying to create for the end user. We let the system dictate what kind of building to make.
But a design system doesn’t define the solution. It’s the resources we use to build. Less blueprint, more construction material.
Let’s go deeper on what healthy design systems are really for and why confusing materials with design exploration can quietly erode your product’s value.
Struggling with Design Systems as a Constraint
Many designers have felt the tension: a promising solution is met with, “The system doesn’t support that.” It feels like a dead end. But that tension usually stems from a misunderstanding of what a healthy design system is meant to do.
Design systems are often misunderstood as tools for designing (the exploration and synthesis of successful solutions). But they aren’t where ideas are born. They’re where ideas go when it’s time to be built. Their purpose is to help us construct solutions that are structurally sound and consistent with the rest of the product ecosystem. They don’t decide what kind of structure we need in the first place.
When we confuse a system’s capabilities with a solution path, we risk building products that are consistent, but ironically, less usable and less valuable.
Where Design Happens
In architecture, the design process starts long before materials are selected. Architects begin by engaging with the needs of the people who will use the space. They sketch, explore options, iterate on layouts that respond to specific goals. It’s messy, conceptual, and highly contextual.
Digital product design is no different.
Critically important design work happens before the design system even enters the conversation. We’re exploring problems, mapping user journeys and task flows, and evaluating tradeoffs. We’re making sense of ambiguity and identifying the best structure for the challenge ahead.
The design system isn’t the tool for this phase. And it’s not supposed to be. It’s not meant for invention…it’s the means of translation. Once a good idea is formed, the system helps you make it real.
Design Systems as Material, Not The Solution
A design system is like a well-stocked construction yard. It holds reusable parts, trusted patterns, and standard elements that help you build efficiently and with confidence.
But just like in architecture, having a warehouse full of pre-fabricated house parts doesn’t tell you whether you should build a school, a hospital, or a treehouse. It’s not the source of vision. It’s the material for execution.
Design systems shine when they’re used to scale known solutions. They help teams avoid reengineering and refabricating the wheel. But the decisions that impact user value (the ones about how to serve users, which flow makes sense, what problem needs solving) still come from design exploration and practice.
The Challenge of Letting the System Drive Design
When teams start with the system instead of the vision, things go sideways. They flip through the component library the way a builder might walk the aisles of a supply store, looking for items to cobble together. “We’ve got plenty of card components. Let’s just stack some of those here.”
The result? Something that looks like a product, but may not actually solve the problem. It appears consistent, but it doesn’t practically work. It may not even be usable.
This “compliance-first” mindset leads to predictable outcomes, uninspired products, and sometimes even broken experiences. Patterns get reused not because they’re the best fit, but because they’re easy and cheap to implement. Exploration gets shut down in the name of efficiency. Teams default to what’s available instead of asking what’s necessary.
Design systems aren’t the problem here. Misuse and misalignment are. A system should never decide the purpose of the structure. It should support the construction of the one you’ve already designed.
Optimizing Design System Use
The most effective teams treat the design system as a construction partner, not an architect. It enters the process once the direction has shape and clarity, once the blueprint is in place.
What might this look like in practice? Consider a two-part approach:
- Explore freely. Start with sketches, flow maps, and open conversations. Avoid materials too early. Don’t let available components define your thinking. You’re still discovering what kind of building is needed and how it should function.
- Systemize intentionally. Once the concept is clear, bring in the design system. Use it to construct the idea with speed and reliability. Leverage known patterns where they fit. Extend the system when it benefits the larger product ecosystem. Build one-offs from atomic elements when needed.
This approach doesn’t diminish the system. It places it where it performs best and protects the early stages of design from unnecessary constraint.
Working “Beyond” the System “Limits”
Sometimes, the structure you need to build requires materials that aren’t in the yard. That’s not a failure; it’s an invitation.
Innovative ideas often stretch the boundaries of what a system currently supports. When that happens, the answer isn’t to abandon the system or start from scratch. It’s to evolve it. Extend it with intention and consistency.
I recently finished reading Thinking in Systems by Donella Meadows. One of my takeaways was this:
“You should modify the system and strengthen it so it can self-correct itself.”
That’s the mindset we need in design systems. A solid atomic structure (tokens and core elements) makes it possible to build new additions that remain cohesive. Yes, you’ll need to validate, document, and integrate thoughtfully. But that’s how a system grows: one new beam, one reusable component at a time.
Strong systems aren’t patched with shortcuts. They’re extensible. And it’s the needs of real design work that make them better over time.
A Good System Supports, Not Limits
So back to the core question: is your design system limiting your imagination? Or is it just being used too early, or too often, in the wrong phase of the process?
Design systems exist to bring great ideas to life, not to dictate what gets designed in the first place. They offer structure, consistency, and speed. But not vision. That still has to come from the teams doing the hard work of understanding, exploring, and solving real problems.
The best teams don’t let the materials dictate the building. They invest in discovery before engaging with the system. They balance exploration with execution. They use the design system to deliver well, not to decide what gets built.
Because at the end of the day, a design system is where building begins, not where the idea is born.
The vision and architecture? That still comes from you.
I’d love to know how you leverage your design system throughout design project work? How have you optimized for when you introduce it?
This is my second article on the topic of design systems. You can read my first article on Enablement over Enforcement.
