How to build and maintain a design system
that developers actually use
The days when we created a nice styleguide, called it a “design system“ and lived happily ever after are long gone.
You still need a styleguide, typography rules, colors, every UI element you can shake a stick at, a tone and voice guide and so on, but these days it not only needs to live in code, it also has to tie into your team’s AI driven workflow.
You know, so Claude actually uses the correct components and does not make crazy s*#t up all the time.
This is what we did at deepico.
The usual suspects, all kinds of Radio Buttons
The usual suspects #2: Color definitions
The usual suspects #3: tables! The bread and butter of any ERP system
I first did the obvious thing and started defining some things that were not well defined before. Taking an Atomic Design approach (but not calling it that to avoid copyright infingement) I started out with what I call base components.
The first concern was to not re-invent the wheel, don’t stray too far from conventions and build each component up in Figma comme-il-faut, meaning with variants, and variables and styles, so they would be very easy to use by my fellow designers – and myself of course.
This made sure, the designers (me included) would actually use the correct components when designing. This was step one.
Step two was working with the Dev team to actually create the components. Or in some cases just re-paint some of the existing ones.
We decided together that we would use React Aria components moving forward. These are non-styled, barebones react components that focus on accessibility and usability. Another crucial decision was to rely on Font Awesome icons. They are really easy to use for both designers and devs, look decent and are very well maintained.
Now all of these components live in the repo, which is our source of truth. All components are actually visible on our test system, so I can always check the behavior of any given component if needed.
It’s the fate of many a design system to be created, used and eventually falling in disrepair. We did not want this to happen. I meet with the devs on a regular basis, where we discuss what is new, needs to go or will be improved in the design system. We then assign tasks and that way mainenance is actually kinda fun. especially when you do that on a Friday afternoon, with cold beverage in hand.
