Taking turns leading the flock
Scaling the output of your design systems team without scaling the team
As a kid fascinated by nature, one of my favourite TV shows was The Living Planet series narrated by Sir David Attenborough. I remember the episode on birds. I was awestruck by the group behaviour migratory birds use to conquer the seemingly insurmountable task of flying halfway around the world. They achieve this by taking turns at leading the flock. Flying at the head of the formation is more tiring than flying at the back. The bird at the head takes the brunt of the air resistance. It ‘breaks the air’, thus reducing the flying friction for those behind it. If one bird remained at the head of the formation for too long, it would tire and be left behind.
Like transcontinental migration, building a design system can seem insurmountable. And, like migratory birds, we can lean on each other to conquer the challenge in front of us.
Over the last three years, design systems have become a hot topic in the design community. Tech companies are spinning up design systems teams to build more features, faster.
Rewind back two or three years and designers were trying to justify investment in style guides to our organisations. If we were lucky, we hired the first, and often only, design systems designer and/or engineer.
The benefits of design systems are now understood. Yet many organisations still struggle to scale the teams building them. Defining typography, colour and a few common UI components is as far as most go. An even bigger challenge is actually adopting those components across your products.
I’ve spoken to many peers in other companies about this. Under-resourced teams comes up as the main reason for struggling to scale and adopt design systems.
Many companies have now ticked the proverbial ‘we have a design system’ checkbox. Yet, there is the ever present tension between growing the design system team and growing teams that build features.
So how do we address this tension? How do we keep evolving our design systems and improve adoption by our product teams?
My experience at Zendesk has shown that we can learn from the behaviour exhibited by migratory birds.
Our design system team consists of two full time designers and three engineers. Depending on your perspective, this may seem like a tiny or a huge team.
Here’s what it looks like from our perspective:
- we build seven products across seven countries and four continents
- our product design team is around 40 strong
- we have dozens of product teams consuming our design system
The team is not tiny, but it could be bigger.
Leading the flock is tiring
Leading the design systems development and adoption is tiring. If left on the wings of a small team, the team will fatigue.
It’s not only the volume of work that makes developing design systems a daunting task. The design system team doesn’t have the same product knowledge as the teams building those products. The design systems team must allow product teams to guide them with context they’ll use the components in.
Taking turns
In product development, each team’s priorities shift and change countless times. The design systems team is no different. It is unrealistic to expect the design systems team to jump and react to every request for a new component.
The design systems team should act as facilitators for contributions to the design system. This reduces the temptation for product teams to develop their own custom solutions when the pressure is on.
When a product team has a pressing need, they are able to design, develop and contribute new components to the design system. Now, the solutions to the product teams’ needs are no longer rogue one-off solutions. They become reusable design system components available for consumption by others.
Making it work
Over the past year at Zendesk, I’ve observed three key ingredients allowing product and design systems teams to take turns in leading the way. For greatest effect, read the next section in Sir David Attenborough’s voice.
Strong foundation
The design systems team has to set the bar for quality of work. Research, evaluation of options, testing and documentation are all critical in building a design system. Leading by example, the design systems team encourages high quality of external contributions.
Clear process
A clear, easy to follow process that allows others to achieve the same quality is critical. Our product development team spans across seven countries. This makes regular syncs between the design systems team and the product teams a key part of our process. These syncs provide an opportunity to identify team needs and overlaps. The process we follow for documenting design proposals is simple and non-prescriptive. We use a range of collaboration tools for discussion and documentation and we rely heavily on Abstract for reviews, and decision history.
Letting go
Empowering others to propose and drive design system changes creates a wider team of willing and able contributors.
This can be hard, especially for a team that has nurtured and guided the design system from its infancy.
Personal experience
Recently I lead the redesign of typography used in Zendesk products. Given the diversity of interfaces across our products, this could have been a daunting task. It wasn’t. I started by running a workshop at our Singapore office to identify the requirements for our typographic system. Following the workshop, a small group of us proposed four typographic scales. Each of the scales had to be stress tested across our products.
Enter the wider design team. A designer from each product took on the task of testing the proposed scales in their product. With detailed product understanding, they were best placed to identify the most challenging interfaces for our proposal.
This is exactly the type of exercise that could lead to fatigue if resting on one individual. If I had to do this myself it would have taken longer, and I would have had to ‘sell’ the new design to each team. Taking turns driving the project allowed us to deliver a more considered design earlier.
This collaboration took place over three months of part time effort, with designers in six cities working together. Our regular syncs via Zoom gave us a chance to discuss trickier aspects of the design in person. Throughout the process, we utilised Abstract to keep track of and comment on each other’s work.
We’ve added the new typographic scales as a set of CSS utility classes and React components in Garden.
While there are notable exceptions (Google, Airbnb etc), the likely reality is that you work in an organisation where the design systems team could do with more resources. Don’t let this be a hindrance or a source of fatigue. Create an environment and processes that empower others to take turns in leading. Give your design systems team a chance to take a breath at the back of the flock. Let the team plan and refocus its efforts on the next challenge, before they take their place at the head of the flock again.
Check out design.zendesk.com for more thought leadership, design process, and other creative musings.
Follow us: Team Instagram | Team Dribbble | My Instagram | My Twitter
