[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.— Melvin E. Conway
I felt like I’ve heard of “Conway’s Law” before, but I think I was confused with John Conway. I thought the law had something to do with mathematics and his Game of Life and numerous videos on Numberphile. I was mistaken and didn’t realize how much I aligned to the idea first formally introduced in 1967, nearly 60 years ago.
What Melvin is saying above is similar to something that I’ve been saying for many years. Design systems should be a reflection of the people who are using them. However, in my experience this hasn’t been the case. There have been so many stories of the struggle of having the larger organization adopt a design system. Lots of different techniques and strategies developed and spoken about. However, I haven’t seen many truly succeed.
What is success?
We’d like to think that success is 100% adoption. Everyone in the organization is using design system resources, no deviations, no overrides, total happiness. We all know this isn’t realistic. But why isn’t it realistic?
What would happen is some team would dream up some new pattern to try, and it wouldn’t be supported in the design system. There’s several directions this could take, including but not limited to:
- Feature team builds it on their own from scratch and it lives with them.
- Design system team thoughtfully tries to include it in the design system.
- Feature team uses the pieces of the design system to create the new pattern.
The first example seems undesirable from a design system maintenance standpoint. If every team has their own stuff, how could we possibly keep it consistent? How could we know they are aligned to best practices and standards?
The second example seems undesirable from a feature team perspective. We don’t have time to wait for the design system team to prioritize, research, and ultimately deliver something we already know we need. Our team is fully capable of building this component. Why would we wait for another team who doesn’t feel the need like we do?
And the third seems like a reasonable approach, until the feature team needs to dive into the design system’s inner workings, deep patterns and guidance, and strict rules. It’s taking longer to review this repository of information than initially thought. The feature would have been built faster if either the feature team did it themselves (without the guidance) or the design system team did it (with the guidance). It seems no matter how you slice it, friction is inevitable.
Stone tablets
Unfortunately, there’s lots of design systems out there that we assume are successful because they are backed by large companies and even have their own branding. Material by Google, Polaris by Shopify, Spectrum by Adobe. However, many of these systems are wonderclout. Brand and marketing tactics to suggest the company as a whole is onboard with these design systems and to get people excited about the organizational design strategy.
As many of us in the profession know, culture eats strategy for breakfast. When our design system is delivered using stone tablets down from the hilltop, it is often rejected. Even if it has made its best attempt at accurately reflecting what the culture is doing. As design system maintainers, we can’t help ourselves to bias the deliverable with structure, and those small tweaks could be enough to turn your teams off to the design system. Even with the best intentions, and the largest carrot on a stick, the culture often will not truly accept this.
In many cases, what we’ve done in practice is attempted to show and tell how things could be. We could have a consistent experience so users will trust the flow. We could all use the same components so feature teams don’t need to build anything new. We could make large branding changes in a few hours using design tokens. And the demos are often very enticing. However, once we try to make our work behave in the legacy systems and culture, breaking years of doing things because “that’s the way we’ve always done it” becomes a serious risk that teams aren’t often willing to take.
So what are we meant to do?
Chaos reigns
A few weeks ago, I had the opportunity to debate the future of design systems with Alex Wilson at UXDX in New York. In the prep meeting for the session, Alex and I were trying to find areas where we disagree. The main area was specifically this: should teams be allowed to do whatever they want?
Alex was on the side of the traditional design systems practitioner. This makes sense from what many of us have been doing in the field for years. Of course we can’t trust these teams with best practices, they are too deep in trying to make their feature successful. There is no way they can keep up with also trying to cross-reference what the other teams are doing. That’s the job of a design system maintainer, to help keep everyone stepping to the rhythm of the same drum.
I am on the other side. I’ve already said that I’m done with components. And it was then where I introduced the idea of the marketplace. This would be where everyone could simply add whatever components they wanted and it would immediately be available to everyone. If that produced 20 buttons, then so be it.
I vividly remember Alex asking the audience if this seemed like chaos, and after the audience cheered, he said “that’s because it is.” And it’s true, it is chaos. But it’s only chaos because your organization is chaotic.
What I’ve proposed is to show your dirty laundry to the whole organization. This is the direct opposite of peacocking a stone tablet design system. It’s showing all the cards. It shows where the cracks are and what we might want to address first. With a transparent marketplace, if leadership is comfortable with 20 different kinds of buttons, then it’s OK. If leadership sees value in reducing that to a more reasonable amount, then they will drive the initiative to reduce this set. The fact is that leadership must have the data to act on. And if they cannot see the live audit of what the design organization is doing, they cannot address it.
This comes from years of seeing support for child component libraries meant to support feature teams. Where the feature team is now not only responsible for their feature, but also the infrastructure to support their own child component libraries and often fail at keeping them in sync with the parent design system resources. They’re often incompatible. The design system team often has the runway for upgrades and improvements while the feature team is struggling to be just in front of deprecated projects.
If we had a mature and transparent marketplace, I believe that marketplace would truly reflect the culture of the organization. How it wants to operate, not its ideal state but its accurate state. From here, we might even see design attractors; a self-organized design system that comes from the reflection of the organization’s culture.
What’s next
I know this is a large pill to swallow. I’m suggesting that we pivot from imposing order to embracing chaos. However, I’d recommend thinking about it in a different way. I know that the most helpful channel of support is always the design system team. So, let’s think about how we can help our peers with this new idea. Let’s create the infrastructure for them to make it as easy as possible to create that new timeline component. Let’s get it on the marketplace as soon as it’s available in production for everyone to see it. Let’s make it easy to discover what things other teams have already built. Let’s have metrics around usage, testing, accessibility, localization, etc. that are already showing the quality of our work. Stop trying to own the artfacts, own the infrastructure.
If the organization values quality pieces, efforts will be made to improve those pieces. If the organization doesn’t, the product may suffer because of it. The bottom line is, the organization can’t know how well it’s doing without this transparency. Otherwise, it’s just another pretty system for our teams to ignore.