Building with a design system in a tailwind application.

Design systems bring uniformity in designs. The organization of the design system on the front end also encourages the adoption of the design system and makes it more receptive to change.

Photo by Balázs Kétyi on Unsplash

What is a design system?

A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.

According to Diana Mounter the design systems manager at GitHub, “Design systems are always evolving, and the way you share and encourage the adoption of new iterations will evolve along the way as well.”

Considering design systems are always evolving, I believe it is only right for them to be implemented in a way that is easily maintainable and easy to change. For example, if there was ever a change of brand colors, then switching to the new colors should be almost seamless and done from the global context as opposed to editing multiple lines of code in the application.

In this blog post, I would go through procedures I take when working with a design system. The styling framework of choice is Tailwind, but these procedures can be taken with any styling framework or even plain CSS/SCSS.

Adding Base Styles

Base styles are the styles at the beginning of a stylesheet that set useful defaults for basic HTML elements. When working with a design system, some tags have a recommended or default style. For example, a design system could signify that all h1 tags by default should have font-weight set as bold and the font-family as nunito-sans. It would be repetitive to add the font-family class to every h1 tag being used. It would also be overkill to create a component for the h1 tags and I feel it should be malpractice. The cleanest solution would be to add base styles for that HTML tag.

/****
tailwind.css || a global css file(if tailwind is not being used).
****/
@tailwind base;
@tailwind components;
@tailwind utilities;
@layer base {
h1 {
@apply font-nunito-sans text-3xl md:text-4xl font-bold
}
h2 {
@apply font-nunito-sans text-2xl md:text-3xl font-bold
}
p {
@apply font-nunito-sans text-xs md:text-xs font-bold
}
}

The code above sets the base style for the h1, h2, and p tags. These HTML tags when used would have the default style set above. But this default style can still be overridden:

<h1 class="text-2xl font-bold text-left text-black font-halant">
Sign In
</h1>

Adding custom colors

Design systems come with custom colors and sometimes, tailwind does not offer all or even most of the colors needed. In this case, it’s best to go, rogue, 😄 and create your own colors by adding a color object to the theme object of the tailwind.config:

// tailwind.config.js
module.exports = {
purge: ["./index.html", "./src/**/*.{vue,js,ts,jsx,tsx}"],
darkMode: false, // or 'media' or 'class'
theme: {
extend: {},
// get colors subsequently.
colors: {
primary: "#06818F",
"primary-a10": "#06818F10",
"primary-a24": "#06818F24",
"primary-a75": "#06818F75",
"primary-a99": "#06818F99",
secondary: "#E1F5F7",
"secondary-a10": "#E1F5F710",
white: "#FFFEFF",
success: "#22BF3E",
"success-a10": "#22BF3E10",
danger: "#FF5F56",
"danger-a10": "#FF5F5610",
warning: "#FEAD54",
"warning-a10": "#FEAD5410",
"warning-a24": "#FEAD5424",
black: "#1E1E24",
"black-a50": "#1E1E2470",
grey: "#C4CECF",
}
},
variants: {
extend: {},
},
plugins: [],
};

This is going to override the default colors that came with tailwind with your new colors.

There are a few rules I follow when naming color variables:

a. Make use of contextual names as opposed to direct color names: Making use of contextual names for colors such as primary, secondary, warning, e.t.c makes it easier to maintain as opposed to names like green, red, white, e.t.c. If green is used in place of primary, if the brand color changes to purple, you would not only need to edit the variable value but also the name which means you would need to go edit the name everywhere it was used which makes it very difficult to change.

b. Using the term alpha for colors with a degree of opacity: When naming colors, I make use of names like primary-a10 which signifies the primary color with 10% opacity. The alpha channel is a color component that represents the degree of transparency (or opacity) of a color.

Creating base components

Base components are components that act like HTML tags or that apply app-specific styling and conventions. Most times, it’s best to build out components of the design system and make use of them around your application as opposed to designing them separately everywhere it is being used. This way, some behaviors could be shared e.g. Adding a loader to a button or adding an error/success state to an input.

Conclusion

These few procedures make it easier for me to work with design systems and easier for me to maintain frontend codebases.