Defeat Decision Paralysis: Building a Killer Design System in Isolation

Rate this content
Bookmark

These days everything has an app or website and users have come to expect perfection out of their UIs. With the bar so high, it can be overwhelming for those of us designing and building those experiences. Before you start building you need to choose fonts, type, spacing, and colours. What’s more, every decision you make seems to lead to even more options.

Shaun will show you how to work through these tough decisions in small isolated steps that will make this massive undertaking feel like a breeze. You’ll learn how to build your colours, typefaces, and spacing into design tokens, build a theme, and develop your components in isolation using tools like Storybook.

12 min
15 Nov, 2023

Video Summary and Transcription

Defeating decision paralysis when building design systems by letting tools make some decisions. Using design tokens to express design decisions as data, including colors and typography. Alias colors to give them more specific names and define typography with a type scale. Use existing spacing scales and build components in isolation to test different states. Start with the basics, use existing tools, and have fun with it.

Available in Español

1. Defeating Decision Paralysis in Design Systems

Short description:

Hey, friends! My name is Sean Evening. I'm here to talk to you today about defeating decision paralysis when building design systems. Stop making so many decisions at the start. Let some tools make some decisions for you. There's no need to reinvent the wheel. We've got Tailwind CSS, Redux UI, and Shadcn to help you get started. So, what are some basics then? We're gonna need a few colors.

Hey, friends! My name is Sean Evening. My pronouns are he, him, and I'm based in Hamilton, Ontario, Canada. I'm here to talk to you today about defeating decision paralysis when building design systems. So, let's dig in.

With all that a design system can be, it's really hard to know where to start. What should my color pallet be? How do I make this work for dark mode? Should I have a high contrast mode? What kind of fonts should I use? How is this going to look on mobile? Are there languages like French and German going to break my layouts? How am I going to test all of this? And pretty soon, if you're anything like me, you are ready to scrap the whole thing and go cry in a corner. But don't worry, I have some tips for you.

First and foremost, stop making so many decisions at the start. Good examples of this would be if you're not going to have async actions, don't define loading, success, or failure states. You wouldn't even need to describe success and error colors that way. If you're not going to use box shadow, don't define an elevation scale. Simply put, if you don't need it, forget about it. You can always come back to it later. And remember, no decision is permanent. Unlike this jQuery hand tattoo. If you aren't satisfied, you can change these things later. Unless it truly matters, don't let a decision or a lack of one be a blocker for you moving forward to the next thing.

My next piece of advice is going to be let some tools make some decisions for you. At least to start. There's no need to reinvent the wheel. There's lots of great tools out there to help you get started. And there are no wrong answers. Which is perhaps part of the problem. We've got Tailwind CSS has great color, font and spacing scales. You could use Redux UI. They have great unstyled accessible components. And Shadcn actually puts those two together to give you some really beautiful styled components to get you started that are very customizable. They pretty much just copy and paste component code into your code base for you. It's really, really cool.

So, what are some basics then? To start off, we're gonna need a few colors.

2. Design Tokens and Color Scales

Short description:

I'm talking gray scale and a primary and secondary. Your typography scale. A spacing scale. And anything else that's critical for your use case. For example, if you're making a weather app, you might need to create a temperature color scale. But if you're not making a temperature app or a weather app, don't worry about anything to do with temperatures. Let's talk about design tokens. Design tokens are a way of expressing design decisions as data. They consist of a name and value pair, with the option to use aliases for different contexts. For colors, we can choose from existing accessible scales like Tailwind and pick a gray scale. We can also select primary and secondary colors. It's important to remember that we don't have to use the entire color scale if it's not necessary.

I'm talking gray scale and a primary and secondary. Your typography scale. A spacing scale. And anything else that's critical for your use case. For example, if you're making a weather app, you might need to create a temperature color scale. But if you're not making a temperature app or a weather app, don't worry about anything to do with temperatures.

But before we go any further, I just want to cover the topic of design tokens. Now, design tokens are a way of expressing design decisions as data. At a bare minimum, a design token is a name and value pair that can express that. So, we've got our name, which is like a global reference to the value. We've got the value itself, the raw value. And you can also have aliases that reference those tokens with a more self-descriptive name for a particular context. And we'll get into that soon.

For example, here are a few examples from Tailwind in Sky Blue color scale. We've got sky 50, which has a value of F0F9FF. But we could alias that as primary accent. And Sky 500 here has a value of 0EA5E9, but we're might want to alias that as primary base. Now, while we're on the topic, let's talk about colors. First and foremost, let's think about what we need. We can use already existing accessible scales, again, like tailwind. We want to pick a gray scale. Now, turns out, there are several different grayscales you could use, with different tints of blue or red or whatnot. Let's use one. And then we're going to pick our primary and secondary color. Here's an example of how I've put this together in Storybook. I'm using three scales from Tailwind. I've got their gray, which is more neutral. I have the pink scale and the sky scale. Now, having 50 to 950 is quite a lot. And you might be thinking, what are we going to do with all these colors? Well, just because we have been given a full scale doesn't mean to say we need to use the whole thing.

3. Alias Colors and Define Typography

Short description:

I'm going to alias some of the colors to give them more specific names, like background, background accent, and foreground for the gray scale. This helps us understand their purpose. Additionally, we have hover, active, primary, secondary, and base colors.

So what I'm going to do is take some of those colors and I'm going to alias them to give us some idea of what they're used for. So you can see for gray scale I have background, which was 50. We're going to have the background accent, which I believe was 200. And foreground, which was 900. So I've shrunk down the colors here and I've given them more specific names. Though hover and active and primary and secondary is probably fairly explanatory, what it's going to be used for. We've also got background background accent and the base color, too.

4. Typography and Spacing Scale

Short description:

So, let's talk a little bit about typography next. Picking your type scale. It's the sizes of your fonts. I always stick to a display heading and subheading. Your header tags are semantic hierarchy for a document. The last thing we're gonna need is to figure out our paragraph style too. So, how do we do this? Here's my example in Storybook. Now, let's talk about the spacing scale. When you're picking a spacing scale, use something existing. Simplify it a little bit.

So, let's talk a little bit about typography next. Picking your type scale. What do we mean when we need a type scale? It's the sizes of your fonts. I always stick to a display heading and subheading. Think of that like a hero. They called it Jumbotron. You want your sizes for your heading levels. One through six.

Now, just because we've got h1 through h6 tags, I would encourage you to keep the two separate. You may want to style them default using this scale. But remember that your header tags are semantic hierarchy for a document. So, don't feel like you need to keep the style tied to the tag itself for design purposes.

And the last thing we're gonna need is to figure out our paragraph style too. So, how do we do this? Again, we can use an existing I am again using the Tailwind font size scale and I'm gonna customize it as I go. I'll talk about that soon. But first and foremost, find your font later. If you're not experienced in picking fonts like me, there are so many to wade through, including some of these horrendous gems on the screen here. So, go ahead and just put that aside for later. That's a whole task in and of itself.

So, having said all of that, here's my example in Storybook. You can see I've got my display heading and subheading and goes all the way down, heading 1 through 6. That's a little cut off there. But now that we have this displayed in Storybook, if I make changes to this scale later, I have one place to see all of it change in one place. Really nice.

So, last up, let's talk about the spacing scale. Now, unfortunately, this gave us a little too hard to stick my face on it. You're going to have to deal with Ron Atkinson. But I digress. When you're picking a spacing scale, again, use something existing. Again, I'm using Tailwind in this example, but simplify it a little bit.

5. Building Components and Wrapping Up

Short description:

Their scale is extensive, but start with a small chunk. Use existing components and style them later. Build in isolation in Storybook to test different states. Made buttons, links, and cards with different tints of pink. Used shadcn to generate code. It's not a full design system yet, but it's all I need for now. Start with the basics, tweak later, use existing tools, and have fun with it.

Their scale is very, very extensive. You really probably don't need the whole thing, so start with a small chunk of it. And here is what that might look like in Storybook. I made a quick component to show what the sizing might look like there.

But now we have our fundamental pieces that we need to start building some components. So what do we do next? Well, first and foremost, only build what you need. Don't be afraid to use existing components and style them to your liking later. And also don't forget, build in isolation in Storybook to test out your different states and variations.

So let's have a quick peek at what I've done here. You can see I've made a button with primary and secondary styles. I've also made one for a link. Also made a card. You can see in this primary card here, you can see that I'm using the different tints of pink that I created in my scale here. We've got the background, we've got the border, we've got the base in here, and we're also using the foreground for some of the text.

And there you have it. I also used shadcn here to be able to generate a lot of this code ahead of time. And then used my design system, my colors, and my spacing, and everything to make it look and feel like a full system here. Well, full in the sense that I've demonstrated. It's definitely not full design system yet. But that's okay. Because this is all I need for now.

So, to wrap things up, start with the bare necessities. You can always tweak things later. Don't forget to use existing tools to avoid starting from scratch. And also, while you're at it, just have fun with it. But that's it for me. Thank you so much. You can find me on these social media platforms here. And if you want to have a look at some of the example code from the storybook that I showed, I have the link at the bottom here for you to check out that repo. Thank you so much. Take care.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue.js London 2023Vue.js London 2023
14 min
Domain Driven Design with Vue Applications
Introduction to Domain Driven Design- What is DDD?- Key principles of DDD- Benefits of using DDD in web application developmentDomain Modeling in Vue 3 Applications- How to design and implement domain models in Vue 3- Strategies for integrating domain logic with Vue's reactive data model and component-based architectureBest Practices for Implementing DDD in Vue 3- Strategies for organizing code in a way that follows DDD principles- Techniques for reducing coupling between domain and application logic- Tips for testing and debugging domain logic in Vue 3 applications
Vue.js London 2023Vue.js London 2023
20 min
Proven Pinia Patterns
With Vue's new-and-improved state management library, Pinia, we gain a much more modular tool. While being more flexible, leaner, and lacking the Mutations of Vuex, Pinia presents us with more opportunities to be creative, for better or worse, with our app architecture and how state management is conducted and organized within it.This talk explores some @posva-approved best practices and architectural design patterns to consider when using Pinia in production.
Vue.js London 2023Vue.js London 2023
18 min
Component Design Patterns
How do you write a good component? In this talk we’ll explore several different patterns for writing better components. We’ll look at techniques for simplifying our components, making them easier to understand, and getting more out of the components we’ve already got.
React Advanced Conference 2022React Advanced Conference 2022
19 min
Building Figma’s Widget Code Generator
Widgets are custom, interactive objects you place in a Figma or Figjam file to extend functionality and make everything a bit more fun. They are written in a declarative style similar to React components, which gets translated to become a node on the canvas. So can you go the other way, from canvas to code? Yes! We’ll discuss how we used the public Figma plugin API to generate widget code from a design file, and make a working widget together using this.
React Summit 2022React Summit 2022
32 min
Design-Driven Full-stack: an End-to-End Dev Workflow that Scales
I’m going to show you something you haven’t seen before — a simple, integrated workflow made possible by React, RedwoodJS, and Storybook. We’ll start from scratch, generate code for components, design and mock state, then finish with a secure API and CRUD UI.
Sounds hard? It was. But not anymore! 🤯
You’ll learn how to bridge existing development gaps between stateful designs, data fetching, and your API using Redwood Cell components — a one-stop-React-shop for fetch, state, mocks, and design. Teams can move faster. Solo devs can iterate more quickly. And there are secondary benefits from documentation to security to accessibility, which add up to improving long-term maintainability at scale.
Get ready to be inspired by what you’ll be able to build!