Design System: My Create-As-You-Go Method for Small Teams
how I learned to keep my designs consistent without killing creativity
One of the first painful lessons I learned as a designer was the importance of a design system. Not from reading an article or watching a talk — but from suffering without one.
In those early years, I kept running into the same two problems. They didn’t hit immediately. They waited quietly in the shadows until I was several screens deep, fully invested, and then they struck.
Where the trouble began
There’s nothing as humbling as needing to change a small detail — maybe the font weight, a border radius, or a subtle color tweak — and suddenly realizing you had copied your elements across dozens (sometimes hundreds) of screens. No components. No variants. Just vibes.
If your prototype is linked, it gets even messier. Replacing an element often unlinks your flows. Editing in place feels like walking through a minefield. And if you miss one button somewhere on Screen 64… well, enjoy the scavenger hunt.
Then there’s the moment you return to a project after working on something else. You’re refreshed, maybe inspired by a different style, a new icon pack, or a cleaner radio button. So you apply it. It looks great — at least on the new screen. You scroll up… and your project looks like a design salad. A mix of styles from different eras of your career. Neoclassical meets Brutalist meets 2021 Minimalism.
Now imagine a second designer joining the project. Two people, copying things freely, each with slightly different instincts. That’s how you become co-authors of an accidental Frankenstein UI.
These experiences formed the foundation of my understanding of design systems — not the glamorous kind you see in presentations, but the practical necessity that keeps your work sane and consistent.
Why design systems exist (a brief reminder)
My assumption is that if you made it this far, you already know the theory, so I won’t belabor this point.
Design systems help products stay consistent, help designers and developers speak the same language, and make scaling a product a lot less chaotic. When they’re done well, they save you time in the long run and reduce the “Who designed this?” moments in a team. See NN/G for more.
But the way many small teams approach design systems is where things start to get complicated.
My attempts at building design systems
Approach 1 – Build everything upfront
Early on, my instinct was to create the entire system before any actual design work. I would set colors, spacing rules, typography scales, button styles, input fields, radio buttons — a whole masterpiece.
The problem? It often became a project of its own, and I’d spend so much time building the system that I hadn’t even started the product itself. And when I finally did start designing, I realized some components never got used, while others needed to be redesigned.
Approach 2 – Start with an existing design system and adjust it
After enough exhaustion from Approach 1, I moved to the opposite extreme: forking pre-built design systems. Material, Carbon, or any well-structured kit I could adapt. This was faster. Cleaner. More efficient.
But over time, something felt off. My projects started looking… similar. Not bad — just not mine. Using someone else’s system meant inheriting their design language. And even when I changed colors or rounded corners, the essence remained.
Both approaches were helpful, but neither quite solved the full problem.
My issue with traditional design systems
In theory, design systems are meant to be “living” — adaptable frameworks that grow and evolve as the product takes shape. But in practice, especially within small teams or freelance environments, they rarely behave this way. The upfront effort required to build a complete system is often too heavy for teams that need to move quickly, and many of the components created early never actually get used. Over time, the system itself becomes difficult to maintain. Updates fall behind, different versions begin to float around, and the promise of a unified structure slowly dissolves.
What stood out the most for me, though, was how easily these systems can begin to limit creativity. When you commit to a full design system before the product has revealed its real needs, you end up designing inside decisions made too early — long before you’ve encountered the actual problems. Fresh ideas feel constrained by outdated rules, and the system that was meant to guide you becomes something you must work around.
This is what led me to rethink my approach entirely.
Approach 3 – The Create-As-You-Go (CAYG) Method
After trying both extremes — building everything upfront and borrowing an entire design system — I landed on an approach that felt more natural for small teams and for my own workflow. The Create-As-You-Go method emerged gradually, shaped by project after project teaching me that the best systems grow out of actual design needs, not predictions.
The idea is simple but surprisingly effective. Instead of building a full design system before starting the real work, you begin with only the essentials: your typography, your color styles, and a few basic foundational rules. Then you dive straight into designing real screens. You explore freely, experiment, and let the early stages of the product shape your direction. When you notice that a particular element is repeating — a button style, an input pattern, a card layout — that becomes the moment you convert it into a component. You lock it down, document it if necessary, and continue designing.
In this way, the design system forms naturally, guided by the evolving needs of the product. It grows at the same rhythm as the project, not ahead of it. There’s no excess, no unused components, and no early constraints boxing you in creatively. The system stays connected to the product because the product is the one bringing it to life.
This approach works especially well for small teams or solo designers who don’t have the time to create or maintain a massive system, and who benefit from staying flexible during the earliest stages of design. It also reduces the risk of mismatched styles creeping into the project because the system is being built in real time, directly around the designs being created.
The only real weakness is that it requires discipline. You need to remember to convert repeating patterns into components so you don’t slip back into old habits of duplication. But once you develop that awareness, CAYG becomes a comfortable and intuitive way to work.
Closing Thoughts
Design systems are powerful tools, but they shouldn’t feel like a burden or a rigid structure you must complete before any meaningful design can happen. For small design teams, or for designers working independently, the Create-As-You-Go method offers a more natural rhythm. It keeps creativity at the forefront while still building the consistency and scalability that design systems promise.
Instead of forcing your ideas into pre-defined boxes, CAYG allows the system to emerge organically from the product itself. It’s practical, flexible, and shaped by real needs rather than assumptions. If you’ve ever felt overwhelmed or constrained by traditional design system approaches, this method might give you the balance you’ve been missing — the freedom to create first, and the structure to support that creativity as the product grows.