Skyscraper or garden?

I've been the lead on a design system project that serves dozens of development teams across a fairly large organization for a little over a year now. I've done a lot of work defining and documenting design standards in that time and have really enjoyed it.

As the project grows and real humans start to use it (sometimes abuse it), and improve it in ways I couldn't have imagined, I've been thinking a lot more about how the system needs to adapt.

I worked in a brand identity agency years ago and remember reading and article back then (I can't for the life of me find a link 😬, I'm sorry 🙏) about how companies tend to think of their brand as a solid structure like a skyscraper—something rigid that will never change. But really successful brands are more like gardens—you plant them and they grow and bloom. Sometimes they turn into something more beautiful than you could have imagined, and sometimes they become overgrown and need to be pruned back.

Maybe this is just a overblown metaphor for saying "Plan for change", but I think there's more to it than that. Before you fire up Sketch, write a line of CSS, or pick which front-end JavaScript framework you're going to use, I suggest you zoom out and spend some time designing how you'll manage the growth and ultimately, pruning of the system over time.

I don't have universal answers to how you design those processes, or what they look like, but I do have a handful of questions to get started.

Partial design system kick-off checklist

Looking back, here are few questions I wish I would've thought more deeply about before I jumped into building a design system.

  • How will you build a community around your design system?
    • Do you have a clear process for contributing to your system?
    • How do you recognize teams/individuals that are using the system well?
    • How do you get teams to share work back with you?
  • What happens when designers/developers deviate form the system?
    • What if the result of their deviation is good and would be a valuable addition to the system?
    • What if it's really inaccessible, or bad UX design?
  • How will you define the lifecycles of your design system?
    • How often will you do releases?
    • How do you retire components from your design system?
    • How do you deal with breaking changes?
  • How will you demonstrate the value of your design system?
    • How do you talk with change-averse folks who don't what to learn something new?
    • How do you talk to leadership about the value of a design system?
This post is a riff off of a post by Ethan Marcotte. He is much smarter than me, but I've thought about this post a lot since reading his.