Don't Repeat Yourself

Software development has a lot of catchy acronyms. KISS. RTFM. YAGNI.

DRY.

Having watched a small organization (40 people) become a large one (1,000 people), I've seen the needless churn and thrash we caused by trying to build a design system before we really needed it, and I've seen the waste we've incurred by failing to effectively adopt the design system once we did get one built.

A design system needs to be fast.

That means an accessible, friendly interface for learning to apply it, and a supported library integrated with your design software.

It also means you need me to make sure your designers have a quick, effortless feedback mechanism for getting things in the library fixed, adjusted, or updated to reflect how they're used. If you don't have that, the discrepancies between what the designers need and what the library provides will push the teams away from the product.

A design system can't impede progress.

Early versions of our design system were not structured as peer dependencies with the react libraries they drew from. It created an awkward, inchworm-effect on team's interface development methods, and led to lots of teams avoiding the design system in its infancy.

Once we configured out systems correctly and started being disciplined about keeping them up-to-date, the cost of implementing and maintaining them dropped significantly.

A design system can spark joy.

When a properly implemented design system is applied by a designer who cares about a user's pain points, the result is software that inspires confidence, reduces errors, and increases capability.

I've seen the advantages a good design system an provide firsthand. The one that Kessel Run uses now has demonstrated a marked increase in feature delivery throughput when it was rolled out and fully supported across a product line.