10 reflections on designing a design system
After two years of working on a design system team, there are a few things I’ve learned…
The Carbon for IBM.com Library is an extension of IBM’s Carbon Design System that focuses on the creation and governance of design standards for one of the biggest websites in the world: ibm.com. Over the course of two years, the team behind this library has helped to modernize [just a tiny fraction of] IBM’s corporate web experiences, document digital design best practices, and scale them to serve the needs of hundreds of design system adopters and, of course, thousands of end-users.
The work of my teammates is by no means finished — in fact, they’re just getting started. Here are my 10 🔥 hot takes on what can make or break a design system and the team behind it.
1. Design systems work is hard.
Honestly, it takes a village to build and maintain a design system. From the outside, a design system might look like a bunch of pixels turned into pretty components. On the inside, there are real human beings tirelessly working to create dependable, exciting solutions that solve countless amounts of UI and UX problems. Being part of a design system team requires relentless collaboration, patience, and energy.
Constant communication with stakeholders will help the team to define a strategy that serves the needs of the business, ensure that team members have the right support and resources to do their job, and ultimately grow the system to serve its audience in the best possible way. Most importantly, a tight working relationship between the designers and developers leading the system will enable everyone to reach excellent outcomes in a healthy, trustworthy, and agile way.
2. Research, research, research.
A design system is regarded as the single “source of truth” by system adopters. Designers and developers will go to the system to learn how something should be used or applied. They enter with an expectation that what they are about to learn is credible, timely, tested, and reliable. So, please don’t disappoint by sharing fake news. Every component, pattern, and guideline should be informed and validated by research before it is made available to the masses. Bonus points are given to design systems that provide raw research data, early design studies, and prototypes to adopters.
3. Start with the basics.
Understanding what a design system is and how to get started can be somewhat overwhelming for first-time visitors. Keeping on top of updates and new releases is an investment in time for regular adopters. To ease their burdens and to make the system more accessible to everyone, be sure to provide the most basic guidelines and resources as a first step.
Provide foundational information like how to get started, where to find important tools, what code packages to use, and who to reach out to when something goes wrong. This will make it easier for adopters to understand why the system is the way it is. It might sound like an obvious first step but leading with this kind of information will help to establish a sense of trust. This trust goes a long way when, at a later stage in the journey, adopters are asked to use components in a prescribed and systematic way.
4. Content is queen.
It’s the responsibility of the design system team to offer design solutions to common problems. In the context of digital, a lot of those problems occur because, unfortunately, content strategy and copywriting is often an afterthought. When a component or pattern does not address content requirements successfully, they lose effectiveness and scalability. Sure, one could argue that UI components should be content-agnostic and serve only functional, UI-based tasks in order for them to meet the needs of many different users. In response, I would argue that every button or form or modal is simply an abstract shape on a screen if implemented without content. The nature of that content and how it is structured is integral to the design.
The bottom line is, content will be designed whether there is an expert in place to do it effectively or not. Providing appropriate guidance on things like content types, tone of voice, recommended character count, and globalization requirements will help adopters make better decisions when using the system.
5. Decentralize knowledge across the team.
Over time, design system team members will gain a wealth of knowledge about aspects of the system they spend most of their time on. Design systems require team members to have deep expertise in their respective fields in order to provide the right direction, support, and governance. However, when a single person becomes the owner of secrets and keys it’s a sure way to guarantee miscommunication, oversight, and burnout. When the system goes down or slows to a halt, hundreds—potentially thousands—of people and products will be impacted.
Ensuring that the system lights stay on means ensuring team members can share responsibilities and knowledge in a balanced and sustainable way.
6. As a service, not a product.
A design system is not a finite library of static components. A true design system should provide end-to-end support to system adopters: from getting started guidelines to UI templates to production-ready code to customer service support and everything in between. A system is a continuous commitment, one that doesn’t end in a single output.
Much like a healthcare service provider, a design system should be there whenever information, assistance, or fixes are needed. In keeping with this analogy, people require different types of information, assistance, or fixes at different moments throughout their life — there is no one solution that fits all.
7. Stick to the system.
A system helps to make sense out of many complex and disparate ideas. It enables designers and developers to turn those ideas into unified, reusable solutions through thoughtful design and clean code. The result? A consistent user experience across multiple brand touchpoints. But this can only be achieved if users of the system adopt and apply it as intended. So how can adopters use a component or pattern for bespoke or niche use cases that are not accounted for in the system? When this kind of request arises, it’s important to extend what’s already in the system rather than expand the universe.
Design system teams should hold off on building net new solutions at every turn unless research and recurring feedback indicate the urgency and need. If the core system does not cater to an adopter’s edge use case immediately, encourage contributions or feature requests.
8. A system is ever-changing.
It may seem counter to my previous statement, but a design system needs to constantly grow and change in order to stay relevant. However, a growing system does not necessarily mean it needs to get bigger and more complex. It may mean that it needs to mature in terms of its quality of documentation or broaden in terms of its outreach and engagement with adopters. And of course, over time, its components may require design touch-ups or development refactoring.
A systems team must be prepared to maintain, update, and finesse all aspects of the design system if it is to stand the test of time.
9. Document, document, document.
Documenting every design decision, file change, or code update is probably not a realistic goal. But making an effort to do it as often as possible will save a design system team oodles of time and headaches in the long run. Providing a change log keeps both the team and adopters informed of updates. Documenting research questions and findings in a report helps answer stakeholder queries and address adopter concerns. Writing draft guidelines for a component or pattern as the design is nearing final approval — and when the details are fresh in the mind of the creator — is far easier than waiting until it reaches production.
The point is, failing to document as you go will result in a backlog that will last an eternity.
10. The system is only as good as the community.
A design system exists to serve product designers, web developers, content strategists, and so on. Its purpose is to give these “makers” the goods they need to make their product or experience truly excellent in the eyes of their users. Without these makers (or adopters as I previously referred to them), a design system has no need to exist. Without the input, feedback, and participation of these makers, a design system team can’t possibly understand how they can better serve them.
A healthy feedback loop, robust contribution models, active support channels, and regular communication between community members is crucial to the success of the overall system.
Carbon’s what’s happening is a great example of the importance of community to a design system.
All of these learnings and humble suggestions reflect my own experience working on a design system. There are many incredible experts out there with much more to say, share, and teach.
🤙 Here are some folk you should know about:
– Jina Anne — Design Systems Guru, Founder of Clarity Conference
– Mike Abbink — Executive Creative Director, Carbon Design System, IBM
– Hayley Hughes—UX Manager, Polaris.Shopify
– Alex Skougarevskaya—Design Manager, Atlassian
📕 And some things you should read:
– Design Systems by Alla Kholmatova—Smashing magazine
– Atomic Design—Brad Frost
– Design Systems Handbook — InVision
– Carbon Design System Medium publication
At the time of writing, Lara Hanlon was a Senior Designer at IBM based in New York City. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.
