Over two days, the Clarity 2023 design systems conference brought together presentations on a variety of topics, including why we should leverage browser standards (1, 2) and invest in accessibility (1, 2, 3), understanding that perfection is not the goal of a design system (1), how we can leverage a diverse variety of voices for better UX (1), and proposing new ways of categorizing design tokens (1). It also included how to understand the business-end stakeholders (1) and plan roadmaps together (1).
This article is a summary of my talk that focuses on communication tools. I show how to involve stakeholders, explain workflows, and gather a crowd around the topic of design systems in your organization.
Table of contents:
- What makes you love a product? Why might you love a design system?
- Gap Glasses: see stakeholders’ needs
- Multi Maps: handoff maps, phase maps, near/far maps
- Consensus Collectors: the one-pager, one chat channel, the replay
- Passion: the missing ingredient
What makes you love a product?
Everywhere you go, someone is trying to get you to buy their product. But fashions come and go, hot kitchen gadgets aren’t so hot anymore, and those consumer electronics start to gather dust. But what about products that are your go-to devices? Why do you keep them in your life? Why do you fall in love with them?
I think products you love have these attributes:
- Exceeds expectations: It delivers all the basic functionality and then goes beyond to excite and delight. It can do the work of several gadgets. It can save you time and money.
- Reliable: It’s always available and produces consistent and predictable results.
- Customizable: It comfortably fits your current situation or expresses your style. And as your style changes, it changes too.
Design systems are products
A “design system” is more than a code library with React Components, design tokens, and assets like fonts and icons that are consumed by engineers. And, it’s more than a design library with its Figma components, layout templates, styles, and icon resources that are consumed by designers. The DS may include hosted assets from other departments like brand logos and marketing illustrations. It has usage documentation, guidelines and principles, and training materials. Examples and interactive playgrounds might be on a server. There are communities of users and support channels.
A design system gets consumed and therefore is a product. So why might you love a design system? Using the same lens as with products:
- Exceeds expectations: The DS goes beyond basic needs to give you superpowers. Its documentation and examples are clear, and you feel productive and excited.
- Reliable: The DS is robust over a variety of devices and can handle many pains like accessibility and SEO.
- Customizable: The DS can evolve with the needs of your users, like adding new variants or components, and it can change as your branding changes.
Gap Glasses: see stakeholders’ needs
Whether you are creating a design system from scratch, enhancing an existing one, or just trying to get better adoption, there can be many hurdles you have to overcome such as:
- Barriers to starting: You may have to get buy-in from your leadership, acquire resources, align with business goals, and allocate budget for licenses or equipment.
- Challenges: People may need new skills, Naming Is Hard, and technology may need upgrades.
- Time pressure: You may start several months away, you might have less time, and there may be dependencies running late.
- Dragons: These are things that can derail the project, prevent shipping, and may be so surprising that the project is no longer feasible.
Wouldn’t it be nice to get the best plan in place before embarking on an intense journey?
First, get people talking
Getting people to talk in groups is effective when generating lists of requirements and identifying challenges. You want to get a diverse set of consumers (possibly end users!) to make sure you know what people expect of the design system. These are the “table stakes” to making the design system viable. But to exceed people’s expectations we can:
- Show how the DS can consolidate patterns
- Demonstrate the DS team’s knowledge of solving accessibility, SEO, and UX challenges
- Inform consumers how the DS will make their workflow more efficient
- Clarify what is part of the DS and what is not part of the DS
Form two groups of people
Different groups of people think differently. There are two groups I have seen be effective:
- Steering Committee: For the DS to have a seat at the table, it needs to demonstrate business value. And there’s no better group to hear this from than the organization’s leadership. Forming a steering committee of leaders such as the VP of Engineering, Chief Marketing Officer, and Head of Product lets you know the goals of the organization and the time frames they are targeting. Then, the DS team can demonstrate how it fits into the workflow and improves the organization’s ability to deliver. Tip: The DS team should always be visible.
- Champions: It is best to hear from the people directly using the DS, like the designers and engineers. Having one representative from each design team and engineering team is a great way to understand the pieces of the design library and code library that are needed. Furthermore, including champions from Quality, Marketing, and Product adds additional perspective! Tip: You can have Champions meetings every month and create a mailing list to keep them informed.
Reduce surprises through storytelling
Allowing a group of people to walk through a user flow may uncover information and other teams that were not previously considered:
- Tell the story forward: Talk about the logical progression from one interface to the next. You may uncover error states, failure states, and training needs. Tip: Look for integrated systems, changing devices, email or text confirmation, copywriting, and moments of delight.
- Tell the story backward: Given that the user is on a particular page, how did they get there? What was required to get there? Tip: Look for devices, software versions, APIs required, platforms required, how long did it take, and how many steps it took to get there.
Summary: why Gap Glasses are good
- Get requirements and expectations from two perspectives: top-down Steering Committee, bottom-up Champions
- Show the value of the DS: how it bridges gaps, how it accelerates product development
- Reduce surprises: uncover additional requirements and dependencies
Multi Maps: simple drawings for broad communication
Drawings have the power to communicate your workflows and ideas. It excels in showing grouping and relationships. And simple drawings reach a broader audience.
Simple drawings often have:
- Big boxes or big circles to show the boundary of a group
- Small boxes or small circles to indicate an item
- 1–3 words inside the item to clarify if the item is a thing or perhaps a step
- Small arrows from item to item show the flow of information or the next step
- Large arrows to indicate a time axis or the relationship between groups of items
Dedicated diagramming tools often lead to technically-dense drawings. In contrast, try drawing on paper, on a whiteboard, or even using slides. If you must use software, consider simple ones like FigJam or Miro.
Handoff Maps: deliverables and dependencies with formats
Workflows within a team and between teams are often a product of relationships. The problem is that those relationships are in people’s heads and not agreed upon by the entire team. Handoff Maps make this transparent and encourage creative collaboration to achieve outcomes. When you continually refer back to the same drawing, people will rely on it as the primary resource for the workflow.
In a Handoff Map, placing teams next to each other in columns helps show the main teams involved. Within each column, a workflow shows the transformation of work from one step to the next. (Use small arrows to show which step leads to the next.) Then, when work passes from one team’s step to another team’s step, use an arrow with a label describing what kind of work.
Tip: Show this diagram often to reinforce the workflow.
Phase Maps: simple roadmaps
Project planning is a fast-paced activity that usually involves the leaders of the organizations. Individual Contributors on teams may be unaware of the shifts in priorities. A Phase Map is quick to draw and update, and leaders and ICs can understand it.
A Phase Map only needs 3 or 4 boxes to be effective. Drawing the arrow of time (usually crossing all the boxes) divides the box into heading and details sections. Quarters are a good time frame for each box because they are short enough to feel agile while long enough to accomplish a project development cycle (planning, production, QA, release). Each box should only have a handful of key items, and each containing 1–3 words.
Tip: Show this diagram during quarterly planning or beginning conversations with a stakeholder.
Near/Far Maps: resource planning
Rarely do we draw the shape of organizations; most of us are only familiar with the “org chart” top-down graph. The Near/Far Map inspires how teams can change and grow to meet the needs of the business. It encourages teams to take on only what they can realistically handle. Also, it inspires how the team members may align to particular focuses — and even grow their careers.
Start with a box that shows the current team focus areas and the number of resources. Then, create the next set of boxes that describe the team focus in the near future and how many resources are dedicated. (Tip: make the box size relative to the number of people.) Then, inspire the future organization by showing how the team may grow (or consolidate) to meet the upcoming focus areas.
Tip: For managers and leaders, this is a good way to show your plans for the organization. For ICs, this helps you get an idea of where you might be more effective or even take the next step in your career.
Summary: why Multi Maps are good
- Drawings are good at showing grouping and relationships
- Simple drawings reach broad audiences
- Inspire the future, align to business goals
Consensus Collectors: gather a crowd
The first step in getting groups to work towards the same goal is to plant the same vision in everyone’s heads. In our distracted workaholic culture, we need bite-sized communication styles and ways to check understanding quickly.
One-Pager: project-based goals alignment
The goal is to create a document with just enough detail to get agreement that the project is something worthy of our time and investment. You want something that readers can consume in a couple of minutes, has short summaries, and even some simple drawings for visual interest. It encourages all parties to comment and update so that we can all agree before detailed PRDs and Tech Specs get produced.
Create a shareable document that begins with the primary goal as its title (e.g., “Q2 Icons Consolidation One-Pager”). Then it has sections:
- Summary: 1–2 sentences explaining the current state or problem to be solved and the general outcome when the project is complete.
- Goals: 2–5 main outcomes that will be true when the project is complete.
- Plan Overview: 1–2 paragraphs giving a brief historical context, a proposed solution, and why this solution may be the best option. Add a graph to show steps and relationships.
- Roles (optional): A table of people’s names, their Key Deliverable, and a column for them to Accept. The table ensures everyone knows who the knowledgeable individuals are.
- Resources: A living list of resources that point to the complete set of details, such as the PRD, tech spec, Jira board, Smartsheet, and Slack channel.
Commenting and changes to the One-Pager should be encouraged; this is a collaborative mind meld!
Tip: Highlight relevant sections in the document and tag individuals for comment. This helps get the collaboration starting and lets people respond when they have time to read and understand.
One Chat Channel: concentrate DS chats
We are overflowing with chat channels at work, and many channels are private and invite-only. This fragmentation impairs the ability of people to come together over the design system and form a community. The magic of concentrating people’s focus on one main channel comes when members of the channel begin helping each other! (Yes, the DS channel can become too busy, but that is a separate topic.)
Creating an obvious design system channel name (e.g., #design-system, #design-system-central, #design-system-guild) is best. It should be called “design system” and not confused with “front end,” “UI,” or “product”.
- Announce releases and post helpful tips on this main channel.
- When giving presentations, invite people to join the channel and show its name.
- At-mention the channel in other channels or private chats.
Tip: Add the channel name as part of your slide templates.
The Replay: summarize with next steps
All of us have too many meetings. The result is that people join late, leave early, and get distracted in the middle of meetings. Paying attention in meetings is just hard. But what if you could ensure that everyone left with the same thinking?
The “replay” is a summarization technique that I often apply at the end of a meeting to make sure all participants know what’s needed next to make progress on a project or to clarify everyone’s roles.
At the end of a meeting or a long chat thread:
- State the original problem or reason we came together
- Recap in a short list what might have been the solutions discussed
- Shortly summarize the solution
- Get every participant to react with an OK or 👍
Tip: Post a short version of the replay to the relevant Slack channel.
Summary: why Consensus Collectors are good
- Bite-sized information improves engagement
- Fewer words encourage collaboration
- Summaries align people’s thinking
- Accepting in writing or an in-meeting 👍 ensures commitment
Passion: the missing ingredient
I hope that if you’ve gotten to the end of this article, attended Clarity, or watched Jina’s Clarity video archives, it is because you have a passion for design systems. When we come together and talk about DSes, use DSes in our work, improve DSes, and build communities to support DSes, we can improve products for all people at scale while also improving the organizations we work for.
The energy and love you put into building design systems creates interest in this topic and makes others want to put their effort into it, too. The result is a thriving community that makes products and services that people love.
Sketch notes by Raquel
Follow Raquel: https://medium.com/@raquel
Do you want to create awesome patterns that create good UX and care about users? Join our community on the Design System Slack: https://www.design.systems/
💖
