The How, and Why, of Creating an Empathetic Design System

Software engineer Jennifer Wong explains how empathy can help shape an ever-changing, morphing design system and whom you should make it empathetic towards.

Jennifer Wong
Aug 19, 2019 · 7 min read

It’s incredibly important to create design systems empathetically. Empathy can solve many frustrating problems that may arise during the creation of a new UX process. In this article, I’ll first define design systems and empathy. I’ll also describe in depth some of the key takeaways from a case study on creating design systems with little empathy, the problems that arose, and how empathy helped solve them.

Image for post
Image for post
Illustration: Justin Cheong.

What are design systems?

According to Nathan Curtis

“A design system is:
a kit of reusable, interconnected parts,
a set of cohesive, interconnected products, and
a community of collaborative, interconnected people.”

Typically, a component library refers to a set of commonly used elements for use across an entire company. A pattern library refers to a set of design patterns for use across an entire company. And a style guide refers to static documentation that describes the design system itself, i.e. how products should look and feel, use cases for UI patterns, correct typographic scales, and more.

What is empathy?

Image for post
Image for post

Putting empathy and design systems together

When discussing UX process issues with coworkers in application development, you’ll often hear answers run the gamut. Everything from testing with users, clarifying requirements with product managers and designers, collaborating between multiple feature teams, or handing off designs to engineers. Each of these is different, but note that each is related to empathy, whether that be for users or coworkers. So to help solve the UX process problems, inject a bit of empathy!

A case study

Image for post
Image for post

We dedicated an entire frontend platform team to this project. They included three of the most senior front-end engineers, three new engineers hired out of boot camps, and up to 15 designers contributing at any point in time.

Additionally, this front-end platform team made the decision to move from Backbone to React as part of the design system process.

What we did well

Documentation: On the homepage of the design system, we described the atomic system used, how to contribute, and information on the component approach we took.

Planned approach: In order to contribute to the design system, you had to create a document with a standard set of information.

Accessibility: We used the `eslint-plugin-jsx-a11y` package to help automate some accessibility across the design system. We also paid special attention to the new modals, which can be accessibility nightmares, to ensure they were accessible as well.

Image for post
Image for post

What we did… not so well

Naming things: Naming things is hard. Initially the design system was under a code name, Black Panda, which could be confusing to newcomers. Later the name was changed to the company’s design system, but was often referred to as CDS. Acronyms by their nature obfuscate what they represent. So we didn’t do much better in the name change.

Deprecation: When components were deprecated, they just showed a banner that said, “Component is unstable and subject to change.” But what do “unstable” and “subject to change” mean? Should you just not use the component, or is it ok to move forward with it?

Image for post
Image for post

Another time, a feature team was the first to use a component called “Text Input,” not knowing that the “Input Field” was a new fangled component that the designers created to replace the former. The feature team was delayed many weeks because they ended up tasked with the new component creation.

Component confusion: We had components called Dropdown, Dropdown Menu, Select, and Select Field. It was difficult to tell what the differences between all of these were. Not only that, but the Select Field was a subcomponent of the Input Field. Again, naming things is hard.

Designer inclusion: Because we moved our system to React and a component based architecture, it was more difficult for designers to make minor changes. React has a steep learning curve, and the CSS folder architecture was difficult to navigate.

CSS `display` property conflicts: As part of the move into the future, the design system’s new grid system used Flexbox or `display: flex`. Unfortunately, we carried over our alignment classes, which used `display: inline-block`, a relic of the old style guide. These two would overwrite each other when used on the same component, causing weird layout issues.

Release process: Only the frontend platform team could release the design system and only once a week. This meant only three engineers out of over one hundred had the ability to do so. After that, the latest version design system needed to be “bumped” in our core repository. This caused delays for product teams as they waited for new components to be available for development work on new features.

All in all, we took many missteps on our way to a design system. How did we fix these issues, and could we have avoided them altogether?

Fixing the problems: Empathize it!

Better communication

We stopped using code names and acronyms, and purged the code base of both.

Clearer labeling

We changed the wording and user interface around deprecated components to make it clear and obvious when not to use a component in the design system.

Inclusion

The release process started happening twice a week. Additionally, one engineer created a bot that tagged a new engineer each time to run the release process. That way, every engineer was empowered to do so in the future.

What should you do?

We had a team of six engineers and up to 15 designers just for the design system. Think about what resources you have before planning a full blown design system.

And most of all, use empathy when building a design system. Consider who will be using it, contributing to it, or marketing it. Engineers, designers, product managers, marketing, or external stakeholders?

Here are some resources to help you along the way:

Learn about Adobe XD, our all-in-one design and prototyping tool:

Originally published at https://theblog.adobe.com on August 19, 2019.

Thinking Design

Stories and insights from the design community.

Jennifer Wong

Written by

Civil to Software Engineer. Conference speaker. Creator of SF 💩 Map. LWVSF Board & Observer Corps. SF born & raised. Loves food & sleep. Unhindered Ruiner.

Thinking Design

Stories and insights from the design community.

Jennifer Wong

Written by

Civil to Software Engineer. Conference speaker. Creator of SF 💩 Map. LWVSF Board & Observer Corps. SF born & raised. Loves food & sleep. Unhindered Ruiner.

Thinking Design

Stories and insights from the design community.

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