When NOT to Use a Design System - Sparkbox

June 4, 2018

Sometimes, a CMS gets built and the work is done. It gets used by content editors and is occasionally upgraded, but the development team and budgets are reallocated to other priorities, and the world moves on. This pattern is especially common with time-sensitive projects (event websites, marketing campaigns, etc.).

Design systems don’t make sense here because a design system demonstrates its value in times of active development. It’s when a designer is working on a new notification message and needs to know what colors to use. Or when a developer is building a new form and needs to see what field types already exist.

If you don’t anticipate a lot of new development on a project, then a robust design system may not make sense.

Had some related discussion in the Q&A during during my UI Patterns session at Texas Camp this weekend - specifically on the actual value of creating an external pattern library in a typical Drupal project. I'm a believer that even just the opportunities to decouple front end and backend efforts can be worth the effort in many projects, but I also agree that you need to sensible in the amount of effort that gets invested into the pattern library. If the pattern library starts to feel like its own product, you might be going overboard. This post encapsulates those concerns pretty nicely.