Building and maintaining a design system

My friend Ethan tweeted this a while ago:

Creating a pattern library is great. Getting an organization to actually adopt it? And to maintain it over time?
That is the work, right there.

And I’ve been thinking about it since. I’ve spent a lot of time over the past years thinking about design systems, pattern libraries, style guides, etc and I’ve started to see some trends in the problems that come up, especially in larger organizations, when trying to build and maintain something.

Last year I worked with a large company that was moving towards a system to base their digital work on and saw first hand how many different forces can make this hard. This is a bit of what I saw that made it hard to get a system up and running and then maintain it.

Change is hard

We all know this, but wow, it is so hard to change a process and the larger the organization the harder and slower the change is. I’ve found that getting a small prototype of a system up and running can help people in the various teams see it’s potential to make their work easier and get them on board with the overall concept more quickly.

And, this probably should be the case, but having executives who are behind the work and believe in it is incredibly helpful. I like to word it more like an experiment that a small group can do and then once that group shows the speed at which they can create new features, etc, you slowly win people over. And that’s what I saw last year, it was painstaking at times for the team doing the initial work, but slowly and surely they were winning over the rest of the organization.

Organizational structure

How the organization is set up can be a hindrance to getting a system up and running. If the developers and designers are on separate teams and reporting systems it makes it much harder to get the work done and maintain the work. There needs to be a unifying force and I would argue they should be on one team, working together and reporting up through the same branch of the organization. But this isn’t always the case and battling through that can be difficult. If changing the structure isn’t possible, then the people at the top of the two different reporting chains need to be on the same page and champions for the work, otherwise it has a higher likelihood of failure.

Multiple teams

In larger organizations it’s fairly common to have several different teams that work on various products, sites, etc. I found when trying to get a design system in place some of those teams may feel like they’re losing autonomy, they may no longer feel freedom to do their work as they see fit, but instead are working off of someone else’s work, in this case the design system team’s work.

These teams may be used to working off of brand guidelines, but design systems usually do some work dictating code, accessibility needs, and more, so problem solving may not feel as fun for the various business unit teams. I’m not exactly sure how to solve this one, but being aware of the conflict that may come up can be extremely helpful.

These are a few of the things I’ve seen in companies and, it turns out, so have others. Robin Rendle’s written about the things he’s learned in getting a system up and running and Sparkbox just came out with survey results that point out many of the same things.

Change is hard. Communication and collaboration are absolutely necessary to make a system work. And the more people you can get involved from various disciplines the better chance you have of maintaining your system.