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…

Lara Hanlon
Oct 1, 2020 · 7 min read
Image for post
Image for post
A snapshot of UI components and elements created for ibm.com. Designed by a team of superhero designers, content strategists, and developers.

The 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.

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.

3. Start with the basics.

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.

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.

Ensuring that the system lights stay on means ensuring team members can share responsibilities and knowledge in a balanced and sustainable way.

Image for post
Image for post
Decentralizing knowledge and responsibilities leads to a more stabilized, interconnected team (and system).

6. As a service, not a product.

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.

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.

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.

The point is, failing to document as you go will result in a backlog that will last an eternity.

Image for post
Image for post
For those at the back: Document, document, document!

10. The system is only as good as the community.

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

Lara Hanlon is 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.

IBM Design

Stories from the practice of design at IBM

Thanks to Allison Biesboer

Lara Hanlon

Written by

Designing @ibm | TEDx and Creative Mornings speaker | Sometimes I write things http://www.larahanlondesign.com/

IBM Design

Stories from the practice of design at IBM

Lara Hanlon

Written by

Designing @ibm | TEDx and Creative Mornings speaker | Sometimes I write things http://www.larahanlondesign.com/

IBM Design

Stories from the practice of design at IBM

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store