Design Systems 101: Deciding When and How to Start

Design systems are key in digital design for consistency and efficiency. This article covers their creation, challenges, and best practices for successful, scalable systems.

Design Systems 101: Deciding When and How to Start

Imagine you're a designer assigned to a brand-new project, or you've just found a new client, or you've recently started working in this area. Suddenly, you learn that you need a Design System, but you're scratching your head, wondering, "What on earth is that?". Don't sweat it! I've been there, and I'm here to give you the lowdown. Consider this your quick-start guide to Design Systems, shared by me and my experience and how I usually approach things. I won't be detailing everything though—think of this as a lightweight and fun introduction to Design Systems and how you can start to think about and implement a system in your projects.

Identifying the need for a design system in a project

It's your first day on this project, and you're about to have a kick-off meeting with your client. They will explain what they want, outline the project, and mention their desire for a Design System. Now, when they're done, I usually pop the question, "Why?" Or I might get curious and say, "So, why do you reckon a Design System's the ticket for you?" or even playfully groan, "Really, a Design System? 😩" But that's just me!

(Remember when I told you in a previous article that I was going to share some things but not tell you how you should do those things? Here's a great example of that!)

The reason we should start with "Why?" is that there is still a misconception about what a Design System is, in my opinion and experience. Many people are asking for a Design System because it is somewhat of a trend right now, but they have no idea what it means, what to expect, and how it is going to work, as well as the impact it has on projects.

GIF of a person singing "Tell me why", a song by Backstreet Boys

After this question, the answers you receive will define your path. You will either:

  • A) spend the next months (or years) working on components, documenting everything from elements to components and flows, defining how things should be used, determining where component A should or should not be used, writing guidelines and behaviours for a button, or...
  • B) realize that there is no need for that and the project could fare quite well with a simple UI Kit, with a collection of components that you use as you see fit.

There is a significant difference between these two options. That's why it's important to understand this before even starting the project!

If you received an answer that points toward A, go ahead and keep reading! If, on the other hand, you received an answer that points toward B, feel free to skip to the end of this article—unless you want to experience the pain your colleague is going to endure! In that case, you may proceed.

Steps in creating a design system from scratch

So, you got answer A)... Welcome to the super cool universe of Design Systems!

Let me break down how I kick things off with a Design System, step by step, in a nutshell.

Even before opening any sort of graphical software (such as Sketch or Figma), I start by asking the client for any existing Brand Guidelines. These are crucial and lay the groundwork for the Design System. Meanwhile, before I receive any response, I set up a project folder on my computer or in the cloud, with the name of the project, and I start adding subfolders inside. I always stick to a familiar layout and use the same structure and naming convention to make it easier to find stuff later on. (If you want to know more about this, let me know in the comments!)

Once I get my hands on the brand stuff, it's library-making time!

From the Brand Guidelines, we can usually extract the brand colours, typefaces, logos, and maybe some icons and illustrations. These elements are all added to a file and made accessible by publishing this file as a library—this file can be called "Foundations."

Next up, I create another file for "Components". This is where I'll build all the small bits and pieces that compose the components I'll use in my design, and yes, it's also a library—after all we need to use them when we're building everything! These components also pull from the Foundations library, getting their styles and tokens from there.

Basically, imagine two files: one is like the invisible magic behind the scenes, and the other is where that magic becomes real, like turning invisible ideas into something you can see and touch (sort of).

In my files, I usually like to keep things tidy by sorting everything onto separate pages. This way, we can clearly see what's what, and there's a handy guide on when and how to use each item—after all, we're building a Design System, so we need to document these things. If we lumped it all together on one page, it'd be a jumbled mess of components, notes, and random experiments. Plus, I always make a special 'Playground' page where I tinker with new stuff before giving them a proper home on their own proper page.

Challenges faced and how they were overcome

Jumping into making a Design System is fun but comes with its own set of hurdles. First up, we've got to get and maintain stakeholder support. Stakeholders might not immediately see the value of investing time and resources into a Design System. We've got to show them the long-term benefits, how a Design System is a game-changer for working smarter, improved consistency, and the potential for scaling design efforts as the company grows.

Next, we need to win over the designers and coders. People usually don't like new stuff thrown at them, so we've got to bring them in early, train them up, and show them how the Design System simplifies their work and enhances collaboration.

Maintaining the Design System is another significant adventure. As our projects change, the system has to keep up without getting too bloated or outdated. We need a plan with everyone knowing who does what to keep it clear and working. Regular check-ups and feedback will keep the system relevant and useful.

Then there's the puzzle of integrating the Design System into existing workflows. We've got to figure out how everything works now and slip in the Design System without causing a fuss. We'll help everyone get the hang of it and tweak things as we go to make sure it fits just right.

Wrapping it up, sure, there are some tricky bits to making a Design System work, but with some good chats, getting everyone involved from the start, setting up rules, and being cool with change, we'll end up with something that makes us all work really well. The payoff is huge: we'll be more together, work faster, and be ready to grow.

One final note: this article is part of a new collection on Design Systems. Stay tuned for more insights and tips in upcoming articles!


That’s all folks!

Thank you for sticking till the end. Your insights and discussions make this journey worthwhile. Drop a comment, spark a conversation, and let's keep this adventure alive!

You can also find me on dribbble, behance and Instagram.

Subscribe to Mistaek

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe