ref: 0d01089078825854271524b11bcd6a39250f0068 wuz.sh/writing/design_systems_101.md -rw-r--r-- 5.9 KiB
0d010890 — Conlin Durbin Add black lives colors changes 1 year, 2 months ago

#title: "Design Systems 101" date: 2020-04-01T14:12:55.044Z cover_image: https://imgur.com/mkcG5lz.png

#Benefits of a design system:

  • Design systems bring order to chaos. Everyone is kept on the same page, so the entire product remains consistent and polished throughout.
  • Design systems improve the user experience through the repeated use of familiar and proven patterns. Designing anything from scratch leaves room for error, so try to use what already works.
  • Design systems improve workflow efficiency. Product teams know exactly how components of new features should look and how to implement them.

#Building a design system

a visual representation of a design SYSTEM

#Questions to ask

  • How does the system work today and in the future?
  • What is our vision?
  • What problems are we trying to solve?
  • Who does this problem most impact?
  • What impact do we want a design system to have on how we work?

#Building on a smaller team

#1. Don't start from scratch

"Steal like an artist", where you can. There are lots of open design systems out there that we can borrow from. Additionally, there are lots of good tools that we can use.

Even things like Bootstrap can be useful to steal from - we can find common patterns that many web-apps use and build reusable components to build them out for our companies.

#2. UX/UI Audit

We can't know where we are going until we know where we are and where we have been. Before starting, get an idea of where you are, what pages you have, what components they use, and what makes sense to abstract into a design system.

#3. Build a living document

A design system is a living breathing collaboration between designers and developers. As such, it can and should grow and evolve - which means getting started and letting it change/evolve.

Some ideas of sections:

  1. Colors
  2. Typography
  3. Sizing/Spacing
  4. Imagery

#4. Build a component library and document it

Once the audit is done, begin to build out a component library. For each component, include documentation and standards. Remember that when not to use a component is just as important as when you should use it.

#Quick Activity for getting started

Our design system offers [kit scope] released as __[kit outputs] and documented at [kit doc site] produced by [people] in order to serve [products] products and experiences.

#To infinity and beyond

As the design system grows and evolves it enables us to work in interesting and new ways.

#Giving Back

One great thing about a design system is that it can live out in the open. It's a great way to represent your Product/Engineering brand and give back to the community.


DesignOps (also called div-ops!), much like DevOps, is a fast-growing field. A design system is the first step in implementing a DesignOps team.


#Full Stack Design systems

When you’re creating a bespoke Design System for a specific product, you have the opportunity to not just group common UI elements together, but to actually represent your core product concepts at many levels. I call this a Full Stack Design System. [Link]


#Any design system is better than no design system at all.

Get something built sooner, rather than later.

GitHub’s design system, Primer, was being revamped internally and privately. Doing so, Diana said, was in part because her team faced Imposter Syndrome comparing Primer to the systems of matured and larger organizations like AirBnb’s DLS, Shopify’s Polaris, and the US Web Design System. Primer felt unpolished in comparison. Many components were deprecated. [Link]

#Build systems, not pages

The web is massive and diverse - it is no longer enough to build webpages. Instead, we need to think about responsive and adaptive design made up of components.


#Pay attention to the team's limits

We can't build a design system in a day, a sprint, or a quarter. Even starting with just a sketch file that makes the creation of new features and pages consistent is a good base.

#Organization is key

Avoid "quick and dirty", you'll only bite yourself later. Make sure people know what is happening and get input from everyone that might touch the system. The worst possible timeline is some people using the design system and others not using it.

#Have a single source of truth

Have a sharable Sketch library and component library that everyone uses while working on the design system.