Tap to Dismiss
Published in

Tap to Dismiss

Art of Diplomacy

7 soft skills toward a successful design system

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

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.

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.

  • 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:

  • 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:

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

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:

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



Sweating the details so you don’t have to

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