When delivering new work in a design system, quality and speed are often competing goals. Chasing quality over adoption may not always be the best tradeoff, but it depends on the goals and maturity of your design system.
There's a few reasons to favour speed over quality. Namely that delaying a component to improve its quality may not make the component more enticing for feature teams. That extra time spend could have gone into other projects to increase adoption.
Importantly, it's possible to improve quality iteratively. Non-breaking changes (such as design-only) are trivial to update. Additionally, the quality of design/code needed for a feature team is often lower than what the design system team strives for.
Lowering quality has its own disadvantages too. It can lower the perception and trust of your design system overall, and undoing incorrect work can be more expensive overall. Getting crap out of a design system is notoriously difficult to get out.
The tradeoff often depends on how mature your design system is. A focus on quality is often only possible for mature design systems.
https://amyhupe.co.uk/articles/design-systems-quality-over-speed/ https://superfriendly.com/design-systems/articles/measuring-speed-with-design-systems
[[20231027111000-design-system-speed]]
[[adoption]] [[designsystem]] [[product]]