At Tanzu Labs, we love Lean and Agile because of the flexibility it affords us to iterate quickly and build valuable products. You know to identify and buy-down risk, understanding where you can afford to make assumptions and where you cannot. Unfortunately, there are risks associated with design systems that far too often go unnoticed or underestimated leading to costly mistakes. Bouncing back from a poorly-made design system choice can feel like you’re trying to stir the cream back out of your coffee.
There are ways to avoid making bad decisions. If you or your team is in the position to choose***** the design system you use (or whether you use one at all), there are plenty of things to do to buy down your risk and feel confident in the decisions you’re about to make. Rallying as a balanced team to ask the right questions about yourselves, and your product can make all the difference.
*If you’re in a position where these decisions have been made or will be made for you, check out these pointers around Inheriting a Design System in the section later on in this guide
Early in your engagement, try to have a session with your team that allows you to gauge your team members’ comfort-level with design systems, without making anyone feel bad. Some goals of a session like this could be:
The following are suggestions for prompts and questions to help get the conversation started:
Also early in your engagement, make sure your discovery covers learning about some of the needs of your product and of the ecosystem in which it will live. Having answers to these questions is immensely helpful in weighing your design system options. Some important things to find out:
Once you’ve had discussions within your team and learned as much as you can about the needs for your product, you’ll want to examine your options and make the choice that’s best for your unique situation. Since the decisions around design system approaches can be costly to walk back, it’s very helpful to understand the trade-offs before deciding.
What we mean
Fully adopting an existing open-source system and staying largely (or entirely) within the lanes it provides. For example: Google Material, IBM Carbon, VMware Clarity or Microsoft Fluent.
|Low cost||Low brand differentiation.|
|Shortcut to polish/fidelity.||Less customization.|
|Vetted patterns and interactions.||Made for everyone, and for no one.|
|Can make things like responsive behavior more attainable.||Like or fight the template.|
|More likely to find familiarity among designers and developers.||More consumer-leaning patterns.|
|Usually include some ability to customize colors and fonts.||Sheer number of options can create challenges in consistency (especially for portfolios).|
|Good systems have invested in accessibility and browser compatibility, which you will get for free.||Tethered to the maintainers of the system—no input in direction.|
|You get bug fixes and updates for free.||Difficult decision to walk back from.|
What we mean
Starting with an open-source system as a foundation, but building custom translation layers for things like themes or domain-specific components. For example: Layering a set of branded themes built on a Material UI foundation.
|Provides a little more customization and differentiation than straight adopting.||Higher cost than adopting a system.|
|Lower-cost than a custom system.||Adds a translation layer to build, learn and maintain.|
|Requires some resources to manage and maintain (maybe not dedicated).|
What we mean
Taking the DIY option and creating a custom system entirely from scratch. From color choices to browser compatibility, type scale to responsive grids, design assets, coded components, and contribution and maintenance processes. Everything according to your needs and vision.
|Full customization.||Likely requires a dedicated team.|
|High brand differentiation.||Takes time to get going.|
|Long-term gain of replication at scale.||You don’t get anything for free.|
|Full control over choices, processes, direction and maintenance.||High cost (possibly extremely high).|
|Requires creation of documentation. and training materials.|
|Difficult decision to walk back from.|
What we mean
Taking the option to skip a design system entirely or to let one evolve from an organic need. Maybe a key stakeholder loves the Craigslist look and you can meet their needs without any fancy UI. More likely than the Craigslist lover, you might have a young portfolio of apps who choose to start with only common styles—as they grow together, they can then identify valuable places for consistency and create a shared library of common components over time, if doing so would provide needed value.
|Cheaper than starting off with a design system||Scaling is not trivial|
|Creates a unique learning opportunity for practitioners||Limited by the skills of the team|
|Provides a way to test components that might later become a system||Risky (can be short-sighted)|
|Benefit of customization without cost of a dedicated team||Risky (can be short-sighted)|
|Can be speedy||Difficult decision to walk back from|
This is worth repeating: not everyone needs a design system. With their current surging popularity, this can be a difficult idea to sell. If you think a design system might not be the right choice, consider starting with something lightweight like a style guide paired with a basic process for sharing reusable patterns, and then pulling the design system lever when (and if) you’re confident that you’ve hit the value-add tipping point.
Oddly enough, the relationship we find ourselves in with design systems can make it feel almost like a family member: we interact with it constantly, we get to know its strengths and quirks, and once it’s there, we’re mostly stuck with it. Occasionally, we do get to choose members of our family like our spouse, but there’s a good bit of family that we don’t get to choose—plenty of us inherit a pile of in-laws upon marriage, and I don’t know about you, but I had very little input into my parents’ decision to have my brother and sister.
If you are inheriting a design system, either by joining an established team who already has one in place, or by being in a position where the choice is not up to your team, you probably won’t have a lot of control over the system itself. Even if that’s the case, there are still some things that are important to discuss and understand, and it’s worth it for your team (not just your designers) to take the time to understand the landscape you’re entering into, so that you can navigate it gracefully and effectively.
Always remember to meet people where they’re at. If you encounter an immature or incomplete design system, or an incomplete understanding of the system being adopted, try to help teams and individuals grow their understanding and/or their system by helping identify and address gaps or problem areas. Don’t just complain or tell people they’re doing a lousy job with the system—this helps no one.
Seek to understand as much as you can about the current ecosystem, and keep an eye out for opportunities either to reinforce something that’s being done well, or to identify something that could be done better. We know this is just another bullet list in a not-exactly-short document, but we cannot overemphasize the importance of channeling your inner truffle pig, and sniffing out as many of these things as possible
**If you find yourself inheriting a half-baked client system, see if there are places you might gently inject yourself and some of your expertise while the bun is still in the oven. In our experience, there are often places where design system teams can benefit from collaboration, guidance, and influence, but these opportunities won’t be gift-wrapped—you will have to seek them out and build relationships in order to have a positive influence.
If products have already been built using the system, get to know them
Circle back to the interviewing of current teams. You’ll probably dig up some good dirt. For example: