Art of Diplomacy

7 soft skills toward a successful design system

I began developing design systems on the agency side at the beginning of responsive web. The work tripled, while our resources and time didn’t. A templated, modular system was the only way to accomplish large site redesigns. I lovingly built these systems out, each with robust documentation, and handed it off to the client. Months later a subpar version launched with many new colors, type styles, and components that weren’t in the pristine original.

What the @#!$ happened?

In 2017 I went in-house and Linda Dong and I set out to create Lyft’s first product design system. Oh… farts. No wonder it wasn’t working before! I’d only been doing half the job and lobbing the hardest part over the fence. Systems design is not only scientific and meticulous, it’s the mastery of interacting with people in a sensitive and effective way. It takes human connection and empathy to go from a sticker sheet to a living, thriving system. The time we invest in relationships with designers and engineers (and their bosses, their bosses’ boss, their project managers, and the accessibility guru down the hall) is as important as building the system itself.

Empathize with teams & their users

Adopting and migrating a product to the system is a huge task for any team. To accomplish this with the least amount of thrash, we have to drive home the benefits a system provides and, arguably more important, how much we truly care about them and their user’s needs:

• We work with leadership to make it a shared business goal rather than a grassroots effort.
• We pitch, through presentations and demonstrations, the system’s goals: universal system across platforms, visual and interaction design coherency, reduced tech debt, and raised quality.
• We highlight what they get for free and may not have time to do themselves: platform specific solutions, all states of a component (especially worst case scenarios), polished animations, accessibility and legibility.
• Lastly, we bring in members of another product, who are already successfully using the system, to give a real world perspective of how it’s working.

Reassure stability

After teams are bought in and start using the system, piecemeal updates and additions can be overwhelming and make the system feel unstable. Creating a consistent, batched workflow and announcement process sets expectations and documents why we did what we did.

Every Wednesday we post on our communication channels the changes to existing and new system elements. For existing system elements this gives product teams a week before the next release to migrate and catch any bugs. For new components we only announce when they are code complete on all platforms and we have a adoption & migration plans for 2–3 related elements at a time.

Educate, don’t enforce

We see ourselves as teachers, not the police. We create documentation as a resource and we present as if we were in front of a classroom. When reviewing work, we always ask questions around the decisions made and follow along the process to how they got there. We studying our designers, and their habits, in the same way that they look at their own users — to try to serve them better.

We fly at different levels: product designers know their users & business goals while we can speak to solutions across all products and the inclusivity of all users. We move at different paces: they know the fast tested metrics while we can do deep research to offer alternative solutions. With a shared respect, we can learn valuable things from each other.

Be flexible

Our product teams are closer to our users and innovate faster than us. We know that sometimes the the system won’t cover all their edge cases. By approaching our system as a living document, it remains flexible enough to be open to new ideas, challenge what we’ve created, and pull in new paradigms as they are proven successful.

We categorize our system elements to set expectations for how flexible they are to add to and how flexible they are to change:

• Rigid Our foundation (layout, type, color, and the like) is rigid, hard to add to and change. A solid, robust foundation is key because all other components and templates are built off of it.
• Viscous Some foundational elements (elevation) and components (selection controls) can be added to or altered with a strong use case.
• Flexible Components (buttons, list item, etc) whose purpose may vary greatly from screen to screen and will need to solve many edge cases are fluid. In code we build them flexibly enough that a team can override certain elements to suit various needs, while still getting the benefits of the original.

Share ownership

Designers and engineers desire ownership of their work and that can be difficult when using a system they didn’t create. By creating clear pathways to get involved, we can share ownership:

• Reviewers Product representatives who attend reviews of system elements to give feedback on how it would or would not work within their product.
• Partners Creators who contribute into the system and help with migration of new foundational elements and components into their product. We give ours lapel pins!
• Product owners Partners who own the components that are only re-used within their product. Many of these components migrate into the core set, that our team owns, when another product starts to use them. We’ve created a component creation checklist to help these amazing folks out.

Construct communication avenues

Direct messages distract and only provide the answer to one person. We have constructed communication avenues, with a 16 hour response time promise, to protect our valuable work time:

• Presentations & Workshops Educational and interactive group events where we teach about new system elements and the reasoning behind them.
• Slack An open forum for questions that is widely used across the organization. Followers often become evangelists and answer questions for us.
• JIRA Task tracking software used for requests and bugs to keep everyone involved in the loop.
• Office hours Four 20 min slots used to review work and answer questions in person. 1.5 hours, twice a week.

We block off time at the beginning of the day to read and comment on these avenues, including the DMs, rather than getting distracted throughout.

Stay Positive

It’s important to remain positive when communicating with others because we are the physical embodiment of the system. If we are easy to work with, so is the system. If we are intimating, so is the system. This may seem simple, but it’s hard to do when receiving feedback, questions and requests at scale — especially in duplicates or on the weekend. We have a few hacks to keep from getting burnt out:

• Account for communication Half of our time is answering questions, attending meetings, and giving presentations — we need to account for that vs pretending it’s a side hustle. We double the initial time estimate of all new work and share our target dates publicly in a status sheet to reduce questions and set expectations.
• Save responses If we’re getting asked the same question or request many times, we write a positive response once, save it and paste it everywhere else. Our tone doesn’t drop as the question increases. If it’s asked enough, we add it back into the documentation as an FAQ.
• Celebrate wins We create tangible milestones for ourselves by breaking our work up into batches and versions. We celebrate the completion of those with kudos, small gifts, or a party.
• Turn off notifications When we leave work, we turn on Airplane Mode (or at least turn off notifications.) This job can easily take over our personal life if we let it. The happier we are outside of work, the happier and more productive we are at it.

At the end of the day, the system is an internal tool and our coworkers are it’s users. They’re human, just like us, and they want to do a good job, just like us. By empathizing, reassuring, educating, remaining flexible, sharing, communicating, and staying positive we’ve overcome many hurdles and are excited to take on new challenges in the future.

I’m Linzi Berry, currently design systems manager at Lyft. I sweat the details so you don’t have to. Please subscribe!