Creating a Design System for Everybody

Or: a Series of False Starts

I am a UI/UXer working with a small team of devs who are embedded within an architecture, planning, and landscape architecture firm called Sasaki. Our little tech team makes a *lot* of different kinds of things — data visualizations, websites, data dashboards, software plugins, sensors, mobile apps — to support the design work of Sasaki.

When you make a lot of different kinds of things, you realize at some point that… well geez, they all look different. If our tech innovation is a selling point of the firm, maybe our interfaces should all exhibit the same level of polish. Maybe it would even be nice if they were branded the same way, to coordinate with the firm’s branding. And I bet such a system would even save us time, because then we could reuse code and styles.

Enter the design system.

Design systems, so hot right now

Our primary goal in developing this system is to establish one source of truth to guide decision-making about the interfaces and experiences we create. However, because there are multiple user groups for this design system, we have found that it’s been difficult to find a format that works for everyone.

A design system for you, and for you, and for you — I just want to channel Oprah in this effort.

The process so far can best be described as… a series of false starts. Learn from our trial-and-errors; read on.

First Attempt: Code-Driven

My first thought was that this design system is for our devs, to make their lives easier by streamlining their process a bit. If I could just give them a pre-baked stylesheet, with iconsets and fonts and colors and libraries all loaded in and attached, they could go off and focus on making shit functional / amazing, and not have to get fussy with styling. I also have a background in html / CSS, so I started by simply writing a flat html documentation site with a corresponding structured stylesheet. When I shared an initial draft with our devs, there was much excitement!

Flat HTML + SCSS
Takeaway: A design system doesn’t work unless it is easy for devs to pick up and run with.

This went fine — until I realized that as a design system, obviously it all needs to hang together as a cohesive kit of parts with a holistic identity. That kind of big-picture, sketchy-level of designing is hard to do directly in the code. I wanted to just sit down with pen and paper, or a UI design program like Sketch, to hash out a lot of these minute design decisions before I coded them in. I wanted to see all the components in one view, develop a mood board, that kind of thing. So that led me to…

Second Attempt: Design-Driven

I took all the pieces I had coded so far and translated them into a UI design platform (in my case, Figma. See earlier post about being a UX/UI designer in a Windows-only environment…) I mocked up everything and looked at the system holistically, and pulled together an inspirational mood board (using Niice) to serve as a grounding reference. (Admittedly, I should have started here first!) I made a few changes to the components that helped them fit together in a way that I couldn’t have seen just by working through the code.

Room to sketch and be moody
Takeaway: A design system needs to hang together as one cohesive set — and that requires a bit of breathing room to figure out in a sketchy open workspace.

This was all great, too — except it was a bit tedious, to mock up all those components so that they exactly mirrored the specified style in the code. I definitely didn’t want to have to do it all over again the next time I created a mockup for a new interface. Wow, wouldn’t it be great if this design system for our team wasn’t just for devs, but included resources for UX/UI designers too, to make our design process more streamlined?

Third Attempt: Library-Driven

Well hello, component libraries. Ding ding ding, lightbulb. Duh, of course, if the design system is going to be the one source of truth for our team’s interface identity, then it needs to not only live in the code but live in a design / interface program too. There are plenty of programs that include library features these days, specifically for this reason. I don’t want to recreate that rectangular button with the same hover effects every single time, and neither does any other designer. At this point, I moved from Figma to UXPin for their expanded design library features, and mocked up all my components again, adding them to a library.

Such usefulness, so streamlined!
Takeaway: In the same way that a stylesheet can save devs time and improve consistency, a design library can save designers time and improve consistency.

To Recap

So a few lessons learned here, to meet the needs of all the user groups interacting with this system. The design system needs to…

  • Include dev tools (a stylesheet, JS libraries, etc.)
  • Feel cohesive and polished as one system (#protip: start here first)
  • Provide designer tools too (a component library)

This is all great to know. So it was a series of false starts, that’s ok. I can now sketch out a cohesive system (the open, mood-board-y approach) in an interface design program, add those components into a library in that program, and then write the corresponding code for devs to use that library in their work, right? Simple.

The Reckoning

Except: what happens when something changes? And, maybe more importantly: what happened to that concept of “one source of truth”? We now have a couple sources of truth serving different user groups on our team: the design library in a UI program (for designers) and the CSS / code / stylesheets (for devs) — and arguably that sketchy mood-board thing is still hanging out there waiting to confuse people too. What happens if we decide our button corner radius needs to change from 3 to 10?

As I mentioned, UI design programs (mostly) have figured out the relationship between the mood-board-y sketching and the design library — you sketch out the corner radius, update the component style, and the change carries through. But what about the devs?

And I think this is where the disconnect often happens with design systems. Designers create this fab thing, but then either a) don’t equip devs with the tools that work for them to begin with (i.e., don’t write a stylesheet at all); or b) those dev resources inevitably get out-of-sync with the component library in the designer’s UI program and it all falls apart.

???

Sorry, no solution offered here — maybe I’m asking for ideas. The best I’ve come up with is to just make sure changes get updated in both places…? In the design library and the code — but that hardly seems sustainable, and geez what a pain to maintain.

I want — I’ll go ahead and be demanding here — I want a design library that generates code and a stylesheet, that I can then tweak and update to our team’s specifications, that then updates smartly whenever something changes in the library, that devs can import into their code directly. Anyone found that yet? How do *you* do it?

Stay gold out there, UXers. I’ll be over here on attempt #4.


Gretchen is UX Lead (full-stack designer?) for Sasaki Strategies, a team of devs and data nerds nested within the design firm Sasaki. She wears many hats, all the hats, the best hats — and believes in the value of systems thinking, using the right tool for the job, and accomplishing more with less.