Garth Braithwaite

@garthdb
124 Followers
80 Following
150 Posts
Design System Engineer at Adobe. Previously of Spectrum CSS, currently the keeper of the tokens.
#designsystems #designtokens #cssengineer
Spectrumhttps://spectrum.adobe.com
Websitehttps://garthdb.com

We can’t AI ourselves out of a messy design system if the system doesn’t codify the context needed to clean it up.

AI will just amplify whatever structure already exists.

Well-named, well-typed, versioned design data → leverage

Sloppy, implicit, inconsistent systems → faster chaos

And how do we compare them?
How do we choose which ones are worth investing in?

I think the hard part might not be building components, it’s making design intent legible to engineers, tools, and future teammates.

Tokens, schemas, APIs, docs, naming conventions; these aren’t outputs; they’re translation layers.

So, which layers are hardest to maintain? Which ones break down?

All design and engineering teams collect decisions.

The question is where those decisions live:
– in people’s heads
– in Slack threads
– in Figma comments
– or in versioned, inspectable systems

Design systems are just one outcome of codifying decisions.

Curious where this framing breaks down.

As payment for any future discussions about design system thinking, here is a picture of Tot with a perfect ear configuration while sleeping.
Tot has those good pinto beans.
Feeling pretty special to have my podcast interview on the Adobe Design site. https://adobe.design/stories/our-people/design-systems-podcast-scaling-spectrum-adobe-s-design-system
5/5 Start where you can
“Start with a spreadsheet of colors and work your way up. It’s better to do the wrong thing than to do nothing.”
4/5 Being public improves quality
"I found that when we went public with the Spectrum website, our standard of quality increased. The things that were sufficient for documentation like this for internal only suddenly wasn't good enough for external."