Design Systems and the source of truth

An article, posted 6 months ago filed in atomic design, design, design system, system, css, html, components, @bradfrost, collaboration & work.

Some excerpts I created from the transcript of the Design System Podcast, hosted by Chris Strahl, which in Episode 11 featured Brad Frost and Evan Lovely.

Hand-over of comps

The traditional process starts with the design of comps, comps, non-interactive previews, which are generated by the design team and undergo a rigid design review process up to a design director or VP, and is only then passed on to the developers who need to implement that initially static comp pixel perfect. But Evan Lovely notes that while there is nothing wrong with comps, there is something wrong with mistaking it for the final product. That’s why he likes tools like pattern lab, storybook or knapsack, because they really allow someone to quickly mock up a comp that actually works within the final environment.

To some companies this is a problem; because the formal approval process is important to them (think of regulated industries). Brad Frost notes that his answer to that sentiment was: “‘You do realize that the browser has a print button?’ They’re like… ‘Honestly, that’s what we’re recommending to you.’” The sentiment that Brad Frost shared is that you need to do what you need to do for the stastakeholder approval process and get the buy in from the organisation. Later on, the opportunity might arrise for those processes to change. Let’s not get blinded by the process and stick with old habits forever.

The wall between design and development

Brad Frost: “That wall between design and development has always been really, really big. And again, this design system sits just wonderfully at that wall, and it provides this huge opportunity the engineers getting closer to the design side of things. That to me feels like a really healthy place to exist. In the teams that we work with, there’s always a ton of education that goes on and helping and talking to designers. It’s no, we’re not asking you to give up your livelihood and the things that you’re very skilled at. But what we are asking you to do is to direct that at the actual software, to make sure that your vision makes it in there.”

API design

But the most important aspect of the chat is when Brad, Evan and Chris discuss API design; basically what goes in and out of a component. Evan Lovely: “I feel like there could be a big shift in how we work, where we come together to talk about the API design. A lot of times we refer to that as the spec, but a bunch of people coming together to be like, all right, we have a need for something that takes an image, a title, optional call to action.”

Brad Frost: “I think that that it’s like a very seemingly technical thing, but what we’re really doing is talking about building a language together, building a vocabulary together.”

And if this sketch library is truthful and is on par with what is in code, you are able to effectively have these hundreds of designers/agencies producing hundreds of different designs that are all realistic; they’re all able to be implemented using the coded design systems components.

Op de hoogte blijven?

Maandelijks maak ik een selectie artikelen en zorg ik voor wat extra context bij de meer technische stukken. Schrijf je hieronder in:

Mailfrequentie = 1x per maand. Je privacy wordt serieus genomen: de mailinglijst bestaat alleen op onze servers.