magine you’ve started as a designer on a new team in a new company. The first few weeks are all about learning. Where do you find the tools you need to do your job? Who are the key people? If you have a question, where do you turn? What’s the right way to use the design system? When should you create new things? The questions compound.
Backbone of employee experience
For many organizations, a good employee experience is built around having the right tools and information, at the right time. If every employee can be set up to make the right decisions faster, everyone wins.
The primary objective for most design system teams is to support a good employee experience for designers and developers in their organization. They create reusable components, document decisions, and find ways to enable better processes. Understanding the biggest problems and opportunities is key to success.
How might we understand the employee experience more to build the right tools?
This understanding builds empathy which enables us to make things that aren’t just reusable, but also delightful. There are many many tactics to get there, but we’ll walk through how to identify primary users, map current experience to find the pain, and ideate on solutions as a team.
Understand your audience
Wait. First, who exactly your is audience? Before the team jumps into the current process and all the moving parts and swirling ideas, define the main folks you want to support. Organizations take different shapes, and design systems serve a unique set of users from company to company. Like any good product, it’s crucial to rally around a deeper understanding of people, their motivations, and their daily struggles.
A design system’s usual primary audience is designers and developers on product teams inside the company. Designers will be the ones combining components in prototypes and conducting research to validate ideas. Developers will be the ones making everything that ends up in the hands of the customer at the end of the day.
Unique spins include product owners, third-party product teams like agencies or contractor teams, and partner brands. For open source systems like Material, teams outside the company are a large group of consumers and contributors to the system. Because of this, it’s crucial that the system is approachable, themeable, and flexible. For mostly internal systems like Gitlab Pajamas or Microsoft Fluent, the decisions documented and the components created are geared towards specific products. They might be flexible and open to community contribution, but their main goal is to support their own teams, not the wide world of app creators.
Define your primary audience, their wants, their struggles, and the best ways to have positive impacts. Activities like empathy maps, stakeholder maps, and storyboards can help frame up the people we serve and ground the team in an audience more nuanced than “product teams”.
Define the problem
Let’s go back to traditional design. From my perspective, a shared understanding of the problem at hand matters more to the success of a product than any other factor. The stars aligning for a product team means little if the Northstar is off-center.
Building on top of your primary audience, what does their current workflow look like? If you’ve been on a product team in your current organization, lean on your own experience in the trenches. But better than that, talk to folks across teams, across segments, or portfolios in larger organizations. Personally, I lean on as-is and to-be scenarios maps to define the current workflow and how we could solve common pain points. Beyond stages and tasks, what are people thinking, feeling, and doing along the way?
Here’s an example as-is scenario map taking a look at how new designers find and join the team. For Janet, the new designer, notice the amount of time, energy, and emotion spent before starting on day 1. There’s hope coming in the door, which quickly turns to confusion and frustration, even fear. How might a design system team create a better employee experience for new designers?
This information can be gathered collaboratively based on what the team already knows and experienced, or it can be generated through surveys or interviews. No matter how it’s created, make sure the team gathers around it to develop a shared understanding. From there, we can brainstorm how the design system could help most effectively.
Right tools, right time
With the current journey understood (this is a constant practice, it changes often), find the most important or applicable pain points for your team to focus on. We can’t boil the ocean after all. It can be helpful to spend some time brainstorming around all the pain points, and then prioritize the ideas that come out of that with a tool like a prioritization grid. Another approach could be to pick the most applicable pain points through dot voting and rally the team around those.
With ideas in hand (please generate more than I did in the example above), map out the desired journey and the role of the design system in making this happen. Based on Janet’s scenario, let’s look at some examples that could be better…
Example #1 — welcome to the team
As-is scenario
When Janet first started interviewing, she might have heard about the design system at a high level or not at all. When she onboards, she might get a high-level picture during her first weeks. But from that high level, she’s in the deep end trying to create using the system in a real project with real deadlines. Her teammates are depending on her. Missteps can cause delays. She’s unsure about how to get help. Her immediate manager is great but seems too busy to field hourly questions and the last thing she wants to do is become a bother. She ends her first week feeling confused, anxious, and lost.
How might the design system hold her hand through that first project?
To-be scenario
Things stay high-level during interviews and onboarding. Janet gets a ton of information and needs to get one piece at a time. Once she’s nearing her first project, she gets a sample project playground in her design tool to apply the system. She’s guided by videos and is connected to a pro from her team who has used the design system routinely and even contributed to it. She gets direct feedback without fear of mistakes causing delays. Janet works through her sample project, makes a new friend on her team, and ends her first week excited and equipped for that next challenge. She made a lot of mistakes, but each time learned without negative consequences.
In this story, we’ve changed the pain points of onboarding and starting a new project into a positive employee experience with safety to fail and building levels of information. This idea comes from a Config talk by Jana Choi, which I highly recommend checking out!
Example #2 — ask a question
As-is scenario
Janet joins, onboards, and gets down to work. When she hits a snag or has a question, it’s very difficult to know who to reach out to. If it’s a design system topic, should she reach out to the design system team or her manager? The introduction to the design system during onboarding was pretty vague and it was given by a program manager who isn’t involved with the system. Navigating the company norms of communication culture is very tricky to get right. How many questions are too many?
How might the design system hold her hand through her daily work?
To-be scenario
Janet joins, onboards, and gets down to work. During onboarding, Janet got a high-level overview from a member of the design system team. Now she has a personal connection she can reach out to as well as a link to the design system Slack channel. In addition to the personal connection, there are entry points for asking questions right where she is working. In her design tool, component documentation links to support channels and bug reporting in Git. In the design system’s doc site, links to support channels are easy to find.
With findable entry points, Janet quickly finds the design system Slack channel and asks her questions. She gets a response that’s accurate and visible to the whole company so the whole community can benefit from the knowledge.
Example #3 — get the latest goodies
As-is scenario
Good news! I know we’re all wondering, and yes, Janet had a successful first project and now she’s been at the company for almost 6 months! Go Janet 🎉!
But she’s hit a snag. Developers on her team are raising some accessibility bugs with the design system components she’s been using diligently in her work. Everything looks right, but now the latest release of the product needs to be delayed until the team can find answers. Janet’s still fairly new, but now it’s on her shoulders to chase answers. She reaches out to the design system team, they inspect a bit and find outdated components that have gone stale. The solution is to update. Great, right? Wrong. This means more delays or applying a bandaid and accepting the tech debt.
How might the design system hold her hand through new releases and upgrades?
To-be scenario
Let’s go back in time a bit. Janet shipped her first project and felt a great sigh of relief. She started in on another project feeling more confident and saw a message from the design system team about some new releases for the month. They unpack what’s new and have guides on how to update according to best practices. Nothing looks new, but there are some updates to keep up with the ever-changing world of WCAG guidelines. She calls this out in standup with her team, and they plan to update it next month. Crisis avoided, and Janet gets kudos from her manager for being proactive in keeping things inclusive.
Proactive and clear communication changed Janet’s experience from confusion and delay to recognition and learning. Teams can be more successful when everyone’s guided and in the loop.
The list goes on
There are endless examples of how a design system team can support their organization based on deeper empathy for the teams they support. The pillar of success here is building that empathy initially and continuing to nurture it as a full team. From components to documentation to communication, everything a design system team does should be built around a shared vision of how teams could work better in the future.