Here comes the tension: design system vs. guideline — similar, but not the same thing

Here I am again, ready to poke at concepts I keep seeing thrown around everywhere.

Design System. Every good designer has been chasing this concept to stay current, right? That's probably what made you open this article. But I'm not here to hand you a magic formula or anything like that. I want to dig into something simple: do designers build guidelines or design systems?

First, a quick trip through the history of the design process. Documentation has always existed under two names we know well: the brand book and the brand manual. The world moved on, one thing led to another, and digital design showed up.

More time passed. Technology got more robust, and new needs for documentation and organization methods appeared. A few methodologies emerged to address those pain points, and one in particular caught on: Atomic Design, created by Brad Frost. That's when we started talking about design systems.

All of this happened around 2012/2013. That's right — almost 10 years ago! At the time, Frost had built this style of documentation to make design deliverables easier and keep the whole system consistent. In other words, a design system, exactly as he proposes and names it in his book.

The years went by, the need for standardization grew, and it spilled into other areas. Libraries, patterns, and new organization systems appeared, like Bootstrap. And we designers started working more and more closely with developers.

At some point, two companies announced something new (but not really) to the design and development community: from now on, designers, we'll call our pattern documentation "Guidelines" — a language guide, if you like. Follow the structure they laid out to design screens with outstanding usability. And off we went, studying, absorbing, and memorizing Google's Material Design and Apple's Human Interface Guidelines.

Back to the present. Who here hasn't heard a hundred things about design systems? So I started to get that itch and stopped to ask myself: is everything I keep seeing labeled a Design System actually mislabeled? To me, most of it looks more like design-language documentation — limited to designers and focused on the visual (layout) side of apps and websites.

On the other hand, I saw companies with robust design system material approaching it in a much broader way. Wait — wouldn't front-end developers be part of it too? Exactly. The concept of a design system shifted again, partly because design ideas themselves became popular and evolved — and that makes complete sense to me.

The systems we build today are far more complex as a whole, so it's essential to have more complete documentation that brings together code, best practices, visual components, and their behaviors. That is what a Design System actually is. One example I love is IBM's material, the Carbon Design System. Take a look — it's worth it!

Conclusion:

Building a Design System is no longer the interface designer's job alone. It's become shared work with the dev team. So be careful when you say: the day I built a Design System.

Visual Guidelines, on the other hand, are a fundamental UI deliverable — they make screen design fluid, consistent, and fast, the same way graphic design leans on the Brand Manual.

And here's a bonus tip I keep coming back to in my own projects: both the Design System and the Guidelines are living documents that evolve over time. Don't try to build everything at once, right from the start. You'll pile up a mountain of work and, trust me, a mountain of rework too.

Start with a lean style guide that holds the components you need to build the app's 5 main screens. Usually that means colors, typography, forms, and buttons. Validate the language. Grow into spacing and margins, and build a solid structure for your project. After that, it's just a matter of evolving and playing with Lego.

A kiss, and until next time!