A reflection on what changed in my design process once I understood what a design system actually is

Starting Out Without a Clue

I want to be upfront about something. When I started my first design project, I had no idea what a design system was.

I'd never heard the term seriously discussed. I didn't know what it included, why it mattered, or what kind of impact it had on a product over time. To me, designing meant opening Figma and making screens that looked good. That's it.

So that's exactly what I did. I designed screens. Random ones. Whichever screen the project needed next, I'd jump in and design it. Each screen looked okay in isolation — but I wasn't thinking about how all of them connected to each other.

Looking back now, I can see exactly what was happening. And honestly, it's a little embarrassing.

What "No Design System" Actually Looks Like

Here's what my process looked like back then:

I'd design a button on one screen. Then a few days later, on a different screen, I'd design another button — slightly different padding, slightly different corner radius, sometimes a different shade of the same color. Not because I wanted variation. Just because I forgot what I did last time.

Same thing with spacing. Same thing with typography. Same thing with cards, modals, form fields — every element kept getting reinvented in tiny ways, every single time.

The screens looked fine when you saw them one at a time. But put them side by side and the cracks started showing. The product didn't feel like one product. It felt like five different designers had worked on it, even though it was just me.

The worst part? I didn't even realize this was a problem. I thought I was being thorough. I thought I was "designing for the screen at hand." In reality, I was creating chaos and not seeing it.

The Moment It Clicked

The shift happened when I started noticing how much rework I was doing.

Every new screen took me longer than it should have, because I was making the same decisions over and over again. What color should this button be? What size should this text be? How much padding goes around this card? These should have been answered once and never again. Instead, I was answering them every time.

That's when I started reading about design systems properly. And it hit me — what I'd been missing wasn't a skill. It was an engineering mindset applied to design.

A design system isn't about making things look pretty. It's about creating a foundation that everyone — designers, developers, future team members — can build on without reinventing the wheel.

What a Design System Actually Is (In Plain Terms)

Once I started learning, I realized people use a lot of overlapping terms in this space, and most of them get mixed up. Here's how I now understand the difference:

• Style guide → the rulebook for visuals. Colors, fonts, spacing, brand rules. It tells you what things look like, but it's mostly static.

• UI kit → a set of pre-made design assets, usually in Figma. Helpful for moving faster, but often disconnected from the actual code.

• Component library → reusable UI components that developers can directly implement. This is where design and engineering finally start speaking the same language.

• Design system → all of the above, plus documentation, usage guidelines, governance, and an adoption model. It's a living piece of infrastructure.

Each level builds on the one before it. And here's the thing I wish someone had told me earlier: most small teams don't actually need a full design system on day one. A well-organized component library is often enough. Over-engineering too early is one of the most common mistakes.

But you do need something. You need at least the foundation — even if it's lean.

Why This Stuff Actually Matters (Long-Term)

When I didn't have a design system, here's what was happening to my work without me noticing:

Inconsistency was creeping in everywhere. Same product, different feel on different screens. Users might not articulate why something feels off, but they sense it.

I was spending more time enforcing consistency than designing. Every new screen, I had to manually check what I'd done before. The system should be doing that work — not me.

Handoffs to developers were messy. Without a clear component library, every screen became a new conversation. "Wait, is this the same button as the one on that other page?" Multiply that across hundreds of components and you can see how much time gets wasted.

There was no foundation for anyone else to build on. If another designer joined the project, they'd have to figure out everything from scratch. Same for new developers. Same for me, six months later, when I forgot what decisions I made.

This is what people mean when they say "design debt." It's small at first. Then it compounds. And cleaning it up later is far more painful than building the foundation right the first time.

What I Do Differently Now

After going through this, my approach has completely changed. Now, before I draw a single screen on any new project, I spend time defining the foundation:

1. Set the core tokens first — primary colors, typography scale, spacing system, corner radii. These are decisions you make once, and they apply everywhere.

2. Build base components before screens — buttons, inputs, cards, modals. Get the building blocks right before assembling them.

3. Document the rules as I go — even if it's just simple notes in Figma about when to use what. Future me (and future teammates) will thank present me.

4. Match the system to the project's stage — for an MVP, I keep it lean. A simple component library with light documentation is enough. As the product grows, the system grows with it.

5. Treat the system as living infrastructure — not a one-time deliverable. It needs to evolve as the product evolves.

The biggest mindset shift was realizing this: a design system isn't extra work that slows you down. It's the thing that lets you move faster, especially over time.

What I'd Tell My Past Self

If I could go back and talk to myself at the start of that first project, I'd say one thing:

Stop designing screens. Start designing the foundation that screens come from.

That single shift would have saved me weeks of rework, prevented inconsistencies that were invisible to me but obvious to users, and made every developer handoff ten times smoother.

Today, I see design systems as one of the most important — and most underrated — parts of being a product designer. Founders rarely ask for them upfront. Junior designers rarely think about them. But the projects that have one, even a lean one, age way better than the ones that don't.

Final Thoughts

I'm sharing this because I know there are a lot of designers out there in the same place I was — designing screens without realizing what's missing underneath. If that's you, this isn't a criticism. It's just an invitation to look one layer deeper.

You don't need to build an enterprise-grade design system on your next project. You just need to start thinking systemically. Define your tokens. Build your reusable components. Write down your rules, even if it's a single Figma page.

That's it. That's the difference between a product that scales gracefully and one that turns into a tangled mess by month six.

This is what I do today. And I genuinely wish I'd started doing it from day one.

If you're a founder or designer trying to figure out how much "system" your project actually needs, I'm happy to chat. Sometimes a 30-minute conversation saves months of rework later.