As years go by, web applications become larger and people went from designing pages to designing systems. Web Design and Development roles also became more specialized, and somehow created a drift between developers and designers, UI designers and UX designers, UX designers and Interaction designers, and the list goes on. Getting everybody on the same page could be a challenge especially if code and design doesn't have consistency and order. Design Systems is the best way to get everybody on board with your project.

What is a Design System?

A design system is every component in your product, from navbars, buttons, typography, icons, and just about everything. It documents everything together and allows you and your team to learn and expand your product without having to worry about duplication or finding where's what.

Style guide for Doctrailapp

"You mean another Bootstrap?"

It's basically like creating your own UI library like Bootstrap, but tailored especially for your product. Why? Because your product has it's specific UI needs and you can't rely everything on frameworks.

Front-end frameworks have become really popular now and it helps speeding up development, but settling for frameworks and using the same buttons, navbars, dropdowns, tables, and panels results to interface and experiences that feels the same for every website in this age. I've observed from depending too much on frameworks is that some designers tend to only do designs that is within the capabilities of the framework.

from Every Fucking Bootstrap Website Ever

Although we can override the styles of these frameworks, this will often result to bugs in functionalities for the framework. Most of the times, some of the frameworks' components aren't used, adding up to the project's file size and slows it down.

A Living Style guide: From Brand Guidelines to UI Libraries

Documenting everything for your product saves you from the hassle of encountering something like this:

The cornerstones of good design systems are style guides, which document and organize design materials while providing guidelines, usage, and guardrails.

Brad Frost

You can document everything from Brand guidelines, grid system, voice and tone, and code styleguides. But the idea to to make a living style guide.

Brand Guidelines for Twitter
Mailchimp Content Style guides

Before I had the practice of maintaining a living style guide (and being a designer who didn't code years ago), I just documented everything in an image, compiled them and sent them to the developers. I wrote everything from hex codes, fonts used, font weight, forms in idle, active, and error state. Everything. It was a pain to maintain all this and update stuff over at Photoshop. It wastes so much time and effort compared to just digging in the code and that automatically updates your style guides.

Style guides for Champions' Fund.

Component-based Design

A Design System may appear big, but all you need is to think that this system is just a collection of bits of components that makes up an entire layout of your product. It's best to think that each component of your product is a lego block, developing your product will be a plug-and-play experience for both designers and developers.

Consider pieces of your UI as an individual component.

Writing Stylesheets

For our projects at Proudcloud, we follow the RSCSS for writing CSS along with styledown-rails for generating our style guides. You can learn more about integrating styledown for Rails projects in my other blog post.

RSCSS follows a component-based approach on writing CSS. Every component is one stylesheet file named after the component's class name.

In your artwork-card.scss

/**
* Artwork Card:
* `.artwork-card` - thumbnail for an artwork.
*
*     @example
*     div.artwork-card
*       img
*       .settings
*       .details
*         .avatar
*         .name
*         .timestamp
*/

.artwork-card {
  & {
    ...
  }

  > .img { ... }
  > .settings { ... }
  > .details { ... }
}

This approach makes it easier to find what you need in a sea of CSS in your project. The comment above is for styledown-rails to parse and generate a style guide. You can learn more about this approach in RSCSS.

The benefits of having a Design System

Easier iteration

Knowing where and what stylesheet to find and iterate is easy with design systems. It's a pain having to deal with overrides that you don't know where it comes from.

An investment for your team

In a project, you have a lot of engineers, designers, and other people getting their hands on your code. Creating design systems needs an open-source mentality: You're not the only one who will use it. It should have one "language" which everyone can understand. This also makes it easy for new people getting on board in the product because of less time having to understand and searching what they need in your codebase. It also enforces code standards for your project and the team.

Avoids duplication of components

Writing stylesheets for apps can be a pain. Sometimes we forget that we already wrote something for a component months ago, so other will have a tendency to write new code of what's already there causing bloat throughout your project. Through component-based CSS enforced by your design system, incidents like this can be prevented. Always remember that performance is a feature.

References and Further Reading