Design system myths IMHO
Reflecting on the year behind me, I realize some of my assumptions were not only wrong, but nearly reversed. This is all just my experience and perspective, and is not meant to be universal truth. If your own findings are different or even opposite, I’d love to know!
Myth #1 — Contribution must be as easy as possible or it won’t happen. 🎯
If it’s too difficult or there are too many technical hurdles, people won’t want to do it. Keeping up with the demands of a full time job shipping features is more than enough work for designers and developers. Creating anything robust and reusable in addition is simply not going to happen.
Fact: simpler is better, but people want to be challenged, grown and rewarded.
Another fact: people need the time and space to do the great work they’re eager to do. To encourage contribution from an active community, getting buy-in from up above is crucial. Often, this means objectives that create space in sprints to codify components and share them. On the other side of the reuse coin, teams also need time and guidance to find the right things to reuse at the right times. They need to know how to extend those things when necessary to reduce the amount of work that begins from scratch.
Strong contribution also merits big recognition. Going above and beyond expectations should be rewarded in the best ways possible in your company. A solid contribution to the design system means benefits to many teams and new superpowers in the hands of more systems thinkers.
Myth #2 — Design system designers are unique lifeforms. 🦄
In order to spend your work week dedicated to design systems, you have to be a little weird; a passionate, in-to-the-weeds-a-bit-much geek. To join the design system team in the first place, you have to understand systems and have experience already. Systems must be your life’s calling.
Fact: most of the best systems designers I know are new to the design system game.
Many of us systems folk have only been working on systems for a few years. With the right growth mindset anyone can dive in and do the work, as long as the desire to learn and grow is there already. In the design organization I’m a part of, there are many rogue designers out there across product teams who are essentially creating local systems to support their teams and their business lines. To be really successful in digital product design, designers must understand how systems work and how to reuse in the best ways.
When I look around on my own team, which owns the design system at U.S. Bank, I see a wide range of experience levels. For many of my teammates (including myself), this is the first opportunity to focus solely on systems and the impact they can have. When I look to hire designers or recruit supporters from inside the company, experience with systems is much less important than a proven history of learning and a curiosity about how to help teams work together better. Basically, the things that make a good experience designer also make a good system designer.
Myth #3 — Design systems are a tool to boost efficiency and consistency. 📐
The primary reason for having a system in the first place is to make our products all look and work the same. Let’s set teams up to deliver features to market faster, so we can grab more customers and pivot faster.
Fact: consistency is just the beginning.
Consistency does rule a pretty decent municipality, but it isn’t king. The benefits of a vibrant design system can be much more engaging and meaningful than a lean towards copy/pasting. Uniformity does breed comfort and trust in users, but if it all ends there, it can also breed boredom.
Make space for innovation. Serve as a toolkit for iteration and rapid testing. Apply brand updates out quickly and cohesively. Create better team culture through tools and shared vocabulary. All of these more impactful benefits come after consistency, but if consistency rules the system, no one will be inspired to adopt.
Myth #4 — Design system teams should hurry to catch up with product teams. 🐇 🐢💨
We want teams to use our design system. And those teams are constantly creating new experiences. So those brand new experiences should use our system as much as possible when they hit the market. So every component in brand new experiences needs to be in our design system.
Fact: design systems document repeatable decisions proven by time in market.
Because everything in a design system will be reused hundreds of times in hundreds of products, it all has to be as robust and proven as possible. Product teams should be out ahead of the design system team so that they can experiment with new ideas and prove worth and stability before codifying them. Product teams should create new things on top of the core design system which can be shared with the community to promote reuse for common use cases. Before those new things are codified in the design system, however, they need to prove themselves in production over time.
And just to be clear, I’m not talking about making exceptions to the system or detaching willy-nilly. I’m talking about extending existing components, creating new components and experimenting with new themes to better embody the brand digitally. We should pressure test those approaches before we codify them in the system, and the process of codifying should take time to turn decisions into repeatable patterns that scale to many different contexts.
Myth #5 — “Governance” is icky
Creating a rigid process which guides individuals towards reuse and charts the course for contribution stifles creativity. People don’t want to be governed and will resist having decision power taken away. If we put too much definition around the community, system adoption will suffer.
Fact: teams welcome a path of least resistance and a break from decision fatigue.
Product teams face so many decisions on a daily (or hourly) basis that putting structure in place to guide decision making in repeatable and sustainable ways is welcomed. Often, when teams begin leveling up their system adoption, they come looking for better definition of governance and contribution. Clear expectations, standards and process means decision stamina is reserved for strategy questions that actually matter to the business line. Instead of getting fatigued from working out line height or accessible data visualization colors, teams can go deeper into empathy building or trying multiple solutions.
Governance as a term has a couple meanings. One definition is governing how the community uses, extends and contributes to the design system. Another definition is how the design system team internally makes decisions in a logical, repeatable way resulting in a more consumable product. Defining internal governance and sharing that more broadly helps the community understand why things are the way they are. It also helps the community join the hive mind and contribute in more effective ways.
Thanks for reading 🍻
Here’s to another year of exploring, learning and sharing! I’m grateful to be part of a team of brilliant people who constantly expand my brain. Again, all of these reflections come from my own limited knowledge and experience. If you feel differently or have seen other approaches, please let me know.
