work experience

So, you need a design system.
Here’s what I know.

The idea is not exactly new. It’s a vision shared by many dev teams out there. We want to make our designers more productive and let them focus on the „inspiration“ while we take care of the execution. What we really need is a system that can help us quickly build websites with reusable components  and implement design updates without much hassle. A super fast design to code process. Just like Lego. You’ve got the box, all the pieces, and as long as you snap things together right, it’s gonna look pretty dope.

Yeah! Almost. I appreciate your excitement for building, but to deliver a great result, we have to take the time for planning. You need to consider what platforms you’re going to build for – web page, native app, WPF or QT application (yep, totally valid), smart TV, fridge, car, watch, and so on. And what kind of content you want to display – marketing content, user created content, streaming content, hardware controls maybe? Interactive forms, large data sets, data visualizations. Oof, so many options already.

Now choose what programming languages and frameworks to use, and set up a process to maintain it. A design system grows fast, and the devil will always find you in the details! ( ; ̄︶ ̄) … Oh shut up.

Of course, there is nothing wrong with a team jumping right in, creating and improvising to find unique solutions. I like it that way! But at least come up with a somewhat defined scope before you make that jump.

o               .        ___---___                    .                   
       .              .--\        --.     .     .         .
                    ./.;_.\     __/~ \.     
                   /;  / `-'  __\    . \                            
 .        .       / ,--'     / .   .;   \        |
                 | .|       /       __   |      -O-       .
                |__/    __ |  . ;   \ | . |      |
                |      /  \\_    . ;| \___|    
   .    o       |      \  .~\\___,--'     |           .
                 |     | . ; ~~~~\_    __|
    |             \    \   .  .  ; \  /_/   .
   -O-        .    \   /         . |  ~/                  .
    |    .          ~\ \   .      /  /~          o
  .                   ~--___ ; ___--~       
                 .          ---         .            

Don’t skip the bridge.

When working on design systems, I’m usually some sort of connective tissue between the creative design folks and the techies. It is my job to organize and clean up design elements before developers get their hands on them. However, many teams just skip this step. They either strictly divide teams, and designers hand-off their designs for good. Or they mix it all up, hiring front-end-designer-developers or somebody with *ninja in his or her title. This might be subjective but I believe being the bridge is almost a profession of it’s own. This is true for designers who are willing to understand code as well as for developers who are happy to talk about design.

You know, running in creative design mode is different from strategizing for a system. If designers have to cover it all, they have to flip a switch to move from creation to organization. This can feel like a terrible, overwhelming switch to flip. So they simply don’t do it. The design looks great, the project owners are happy – let’s expect the dev team to implement it perfectly.

Now, when a design wasn’t built with the big picture in mind, developers will find it difficult to translate it’s elements into reusable parts. In this case it’s often easier and much faster to build static pages without setting up a system of half-baked components. With this approach you’ll likely create inconsistencies and the product will become difficult to maintain.

So maybe someone could do the terrible, overwhelming task anyways? – And what task exactly do you mean?

Specifying the parts of a design system. It requires experience and the ability to translate visual into functional elements. The tricky part is getting a really good understanding of the full functional scope of a thing. What does it do and why? Ask that even for a button and you might get tangled up between small, medium and large, primary, secondary and ghost buttons – and what to use which type for. Do we even need these variations? Without such questions, we’ll pile a bunch of snowflakes that will make us cry for a new design system after just a few years. 

Let’s look at something as simple as a color palette. We often start with a nice palette of brand colors. Maybe a range of shades derived from them. Of course we also need some neutrals, that go well together with the brand palette – slightly saturated, cool or warm greys… Ok, how many of them? Maybe 9-ish as Google Material started a trend, naming their color shade palettes $color-100 to $color-900? Well that’s a way to get started as long as you’re ok with never using about 90% of your tokens.

Do we also need pure black and white? What about transparency, do we specify a bunch of transparent tokens or do we want to create a dynamic function for it? And oh hey, what about text colors, how many levels – subtle, normal, strong, how do we even name these varying intensities of text colors? Does text have a defined appearance in light and dark theme? How about placing text on solid colors, oh no, we forgot about accessibility! Did you know that white text on a fresh green button never has enough contrast? But green is our primary brand color, we need green buttons! They are so pretty and engaging!

SOUNDS FUN, RIGHT? That’s just colors. And chaos is already within reach.

What’s so wonderful about design systems is that you cannot follow a set of rules to set them up and waterproof them from the start. It takes time for rules to evolve and a design system’s art is making it flexible. So you can actually go back and change any of its primitives without causing the whole structure to crack and crumble.

And this, my friend, needs a lot of communication. So much talking, back and forth, between PO, PM, UI, UX, ENG and even those sales and marketing people… Nah, well maybe not so much, but in general, we all have to talk to make this work. One thing every designer should understand: a beautiful design system is utterly useless without it’s components mirrored in a well maintained code structure. So get your fingers off those good looking templates at ui8 and start building a set of core components with your engineers. Even if they don’t look pretty from the start, as long as you build a system that you can navigate and improve easily, you’ll have the chance to let it grow into it’s purpose. 

And if you don’t like talking, don’t even try to build a design system. Hire some folks who do, lean back and enjoy the show.

<~( ̄︶ ̄)~>