The Design System Dream Team
Working on a design system can feel like you’re jumping between multiple products continuously. Switching contexts between theoretical, practical, micro and macro, many times in the same day. You can be working on a token naming conventions, org wide design governance models, answering support requests and triaging screen reader bugs all before lunch.
To me, it‘s felt like everyone is juggling 3 different full time roles, but deprioritising two thirds of the work. Our backlogs are full of essential things we know we’ll never get to.
You could argue this is true of any product or service but with Design Systems and their multiple, competing stakeholders, it feels like there is a minimum expected output that is always significantly greater than the capacity of the team.
While this is partly due to a misunderstanding of the work, I believe this is primarily due to people, stakeholders, users or otherwise placing higher importance on the parts of the system that will help them or their area the most. Designers aren’t too fussed about minimising breaking changes. The last thing the Development Lead wants to hear about is a UI refresh. You end up in a unique position where almost everyone thinks you’re not doing enough.
What would a team that could be enough look like?
Rather than thinking about what a team make up might be in terms of traditional job titles, I was wondering what it would look like if you designed a team around the activities that could benefit from full time attention.
This idea breaks the Design System team up into 4 smaller squads and some cross cutting roles.
- Delivery squad
- Documentation squad
- Discovery squad
- Community squad
- Cross-cutting roles
Delivery squad
This squad is responsible for the delivery and maintenance of the “live” system. This squad contains 4 roles:
- Library maintainer (UI Designer)
- Library maintainer (Frontend Developer)
- Token design and management (UI Designer)
- Token design and management (Frontend Developer)
The library maintainers are responsible for:
- Continuous improvement of the performance and features of the design system
- Investigate and implement new technical solutions. For example, how we might use new features of tooling
- Manage and fix bugs
The token design and management roles are responsible for:
- Tokenisation of design, structure and naming conventions
- Management and distribution of tokens
- Management of token tooling across platforms
The delivery team are collectively responsible for:
- Multi-brand implementations of components
- Quality assurance
- Release process management
- Versioning and breaking change support
This team is technical, it’s less concerned about the “why” of the system and more about the quality and efficiency of the output.
It may seem like a stretch to consider Tokens or Library Maintenance to be a full time job but ask yourself, how much time do you spend on it now? What does it stop you doing? What does not having someone working on this specifically mean for the overall health of your system?
Documentation squad
Small but essential, the docs squad maintain the front door to the system and ensure users of the system can find what they need.
This squad contains 2 roles:
- Documentation writer (Content designer / Tech writer)
- Documentation developer (Frontend Developer)
The documentation writer is responsible for:
- Usage and technical guidance for the documentation website
- README content in repos
- Content governance, for example A-Z of terms
The documentation developer’s activities may include:
- Maintenance of the documentation website
- Creating and managing technical examples
- Management of design system hosting requirements
Collectively they will also make continuous improvements to guidance through active research and feedback from the design system users.
Discovery squad
The discovery squad is made up of 3 roles:
- Component and Pattern Design (Interaction Designer)
- Component and Pattern Design (Content Designer)
- Component and Pattern Design (Frontend Developer)
The discovery squad will focus on activities like:
- Creation of new components and patterns in a single brand
- Scope, name and API of components
- Working with contributors of new components and patterns
- Auditing existing component usage and documenting needs
- Creating component blueprints
- Creating prototypes and templates
- Testing and Research
The discovery squad is less concerned about the delivery side of the system and more focused on the how and why of the contents. Should something exist? What should it do? What stance do we have on this?
Community squad
The community squad is more of a group of individual roles rather than people that work directly together. It includes:
- Community Manager
- Service Designer
- Service Support
The Community Manager will spend their time:
- Being the point of contact for teams
- Looking out for adoption opportunities
- Actively looking for contribution candidates
- Recording community requests and feedback
- Fostering active community channels and spaces
- Organising events
- Running drop in sessions and workshops
The Service Designer will aim to:
- Understand and record the multiple ways the organisation delivers products
- Understand blockers to adoption
- Design governance flows and processes
- Define component and pattern lifecycle and statuses
- Define the Design System eco-system and boundaries
Service Support will have one of the most important roles in the team:
- Answering and directing support queries
- Helping users get up and running
- Giving design and development advice
- Creating bug tickets
- Recording user feature requests and enhancements
Cross cutting roles
On top of the specific sub-squads there are some roles that need to either be across everything, or will not need to be full time in one sub-squad.
- Design System Lead(s) (Product Manager / Design Lead / Head of)
- Delivery Manager (Scrum master etc)
- Brand & Design Language Expert (Graphic / Digital Brand Designer)
- Accessibility Expert (A11y focused hybrid design / developer)
- User and Customer Research (User Researcher)
The Design System Lead will:
- Set the overall vision for the Design System
- Define high level priorities and initiatives
- Create and balance the team roadmap
- Be the primary point of contact for the business
- Provide guidance and mentorship to the team
The Delivery manager will:
- Run team ceremonies
- Manage team workflow and output
- Assist with organisational blockers
- Keep an eye on team health and availability
The Brand & Design Language expert activities will include:
- Being the liaison with brand team
- Develop the Digital Design Language for each brand. This will be zoomed out, no component design.
- Define core system styles (Colour, Typography, Layout etc)
- Asset creation, management and distribution
- Creation of Digital brand guidelines (wider scope than the Design System)
The Accessibility SME will work with all members of the team on:
- Creation of new Components & Patterns
- Bug triage and fixes
- Quality assurance
- Create A11y acceptance criteria and testing requirements for team activity
- Liaise with internal users on Accessibility issues relating to the Design System
The Design System Reality Team
It’s unlikely your team will have headcount for 17 roles. That’s why this is a dream team, not a reality team.
While some of the more well known systems that many of us may aspire to have 25+ people working on them, I believe the average is more like 3–5.
From my experience, I have come to the conclusion that any Design System team, whether it’s 3 people or 30 is expected to deliver everything I have described above and more. While some areas of focus may be seen as a one time thing, much of this work is actually continuous.
Of course, each organisation will be different and each stage the system goes through will be different:
You may not need 2 people working specifically on tokens if you only manage 1 brand and 1 platform, but 5 brands and 3 platforms?
You may not need to separate groups of people creating new things vs maintaining the existing. However, why do so many teams struggle to go back and improve existing components, keep the libraries and guidance up to date, successfully add new things and shepherd contributions through? Usually the most immediate concern wins — and that is often dealing with bugs.
Of course, you don’t need 15–20 people to have a design system team. If you have 3 people, maybe your focus should be 100% on maintaining a core UI kit and nothing else. If you have 6 people, maybe you can take on your own custom guidance website or accept a couple of external contributions every quarter.
But consider all of the activities thast could be full time roles and be realistic about what you can and can’t achieve with the team you have. When we try and do it all, we spread ourselves so thin that the work we do, however brilliant, goes largely unnoticed.
