So, you’ve managed to convince your company that it’s time to build a design system team but you’re not sure where to start, and you want to make sure you have the right people to help scale and grow the design system. Well, you’ve come to the right place.

When it comes to design systems we often talk about tools and methodologies to begin and maintain it, but above all, the human beings behind it are what guarantee longevity and internal adoption. At the end of the day, a design system team is a people thing and a people project. It changes as you hire more people, and it’s important to adapt to the new influx of people, requests, structure, and other factors.

This is why we believe that to scale a design system and get wide adoption, the ideal is to have a dedicated, multidisciplinary team, with dedicated time to work on it. It is also crucial to give this team the authority and power to make decisions, to make them as effective as possible.

Team set-up

Depending on the size of your company, your company goals, and how far along you are with your design system, you will need to fill in a few basics. This team is the control tower that will provide the cross-functional vision necessary to guarantee the overall coherence of the product experience. There are other aspects that must be considered to contribute to its success, including promotion for adoption, establishing processes for maintenance, updates, and communication aspects.

Keep in mind that not all profiles will be a fit for a design system team, even if there may be someone on your team who is an amazing designer or engineer – If they are not able to see the big picture of what you’re trying to accomplish it may be detrimental. There are a certain set of skills that lend themselves well to design system specific roles (more on this below).

Building the right team helps to avoid gatekeeping from other departments. For a highly functional design system team, one specific department shouldn’t ‘own’ it. This is also the same for the team itself. If it’s only made up of designers or only engineers, as you won’t only be able to deliver what you need to, but you’ll also be lacking the perspective needed to get the job done as well as it could be.

How many people should you have in your design system team?

I strongly agree with Deliveroo’s vision suggesting that you should start with at least 1 full-time designer, 1 full-time software engineer. As a really nice to have, having a product owner or lead is great as well, to help manage, strategize, plan and move things along with your product roadmap. Having an ideal setup for a design system would be having multiple roles to help design, build, communicate and manage the design system. As the team grows you can add more designers, engineers, as well as UX writers, content designers, user researchers, data analysts, motion designers, and other relevant resource.

T-shaped team

I like to picture the design system team as a T-shaped team, meaning that you’ll need folks who are, in general, broad generalists, but have deep discipline expertise in one or two areas.
No matter if you are a team of one or a hundred, it is essential you keep in mind your design system has some needs you can’t avoid (communication, user centric approach, empathy…). These needs are your broad skills every member of your team should own.
Then, it’s ok to have individual people in your team who embody a deep discipline expertise that would help your design system, whether that’s design system specific knowledge (eg. experience in how to scale contribution models) or broader skillsets that will help (eg. figma or sketch plugin development to fill gaps in your libraries). These deep discipline expertises can be more or less important, depending on your design system level of maturity. A good rule of thumb is the more mature your design system, the more specific the skillsets can become.

Design system team essential skills

As mentioned above, there are some broad skills that every design systems team member should have. Here are some that we’ve thought of:

System thinker

Someone who thinks in how parts work together to create a holistic, coherent user experience for customers. Someone who is comfortable with breaking things down, and tirelessly advocating for taking a wider view. This skillset speaks for itself.

Customer and user-focused

Having the ability to put yourself in the user’s shoes and understand their needs. Someone who listens closely to all avenues of feedback – who loves to be the voice of the customer to the wider product team.

This feels like it would be a must-have for most product designers, but when you’re slightly further away from the end-to-end product process, it’s even more important to make sure you’re building components that are tied to user needs.

Strong communicator

Someone who is comfortable representing their team and product, presenting the vision and priorities to stakeholders, customers, and partners. They enjoy speaking opportunities and have proven experience presenting to large teams and leadership.

Especially in earlier stages, this cannot be understated. The design system will need championing internally to get people onboard, from implementation through to senior leadership buy in.

Passionate for design

Passion for design systems is crucial (non-negotiable). It sounds like a no-brainer, but if someone is actively interested in design systems, they will either have inbuilt knowledge on best practices, or be willing to seek it out.

Self-aware

People who contribute to areas in the field that need the most help, can easily recognize their skills, and know where to insert themselves to make things better. They pick up the slack of problems areas that need solutions. Again, this is particularly important in early stages of a design system.

Curious

Curiosity and the ability to question best practices. Someone who cares about building and refining processes. Want to understand how things are built and have an interest in learning them. Designers/Engineers who care about building and refining processes.

When you’re constantly evaluating why something should be what it is, and trying to find efficiencies for other people, an inbuilt curiosity helps. Design systems teams are great for people who want to understand how people tick, and what can be done to help them do their work better.

Qualities to avoid

Similarly, there are definitely some red flags when it comes to design system team hires:

Mavericks

Avoid designers who constantly look to reinvent the wheel or create things from scratch. These folks can be valuable people in your product teams, but a lot of the time, design systems work is more about refinement and less about being a creative visionary…

No interest in engineering

It may sound obvious, but avoid anyone that has no interest in the design system team function and process. This is especially true of engineers, who are only interested in the engineering function improvements that could be made, instead of looking at the holistic product processes that could be improved with systems.

Getting deeper

As we mentioned before, the bare minimum, table-stakes of a design system team are design, engineering and ideally some kind of product leadership. However, there are a number of roles that are important on your team, especially as your system grows in maturity.

The “should have” roles

Content strategists and ux copywriters are roles that only seem to get mentioned in big, high-functioning design system teams. In fact, in the How We Document 2022 survey, only 2% of respondents were in content. Content strategists especially are a valuable resource to have when it comes to writing clear, user-centered documentation, and for communicating outwards to the company about progress, goals and process. Contribution models and governance processes are made infinitely better when you’ve got someone who’s specialty is communication. Out of the five teams we talked to when researching this article, this was the one role that came up again and again.

Another area that will become vital as your system grows is to have dedicated UX researchers in the team. All of your components, patterns and guidelines, as well as your internal processes, feedback mechanisms and touchpoints, should be tested thoroughly with users. Having the dedicated resource for this means that it won’t be an afterthought.

The “nice to have” roles

Now we’ve covered off the ‘should have’ roles, let’s get to the nice to haves. These can be essential in particular teams, but usually won’t require dedicated resource until your system has reached a certain size or level of maturity. The first you’ll likely come across is data analysts. Sadly, this is almost non-existent in most teams, as measurement on systems is still very immature. However, as design systems as a practice matures, so will the need to justify and fight for budget and resource. Data is integral to this.

Next up we have the specific design skillsets. These are things like motion design, sound design and illustration. While most systems will get by with generalist knowledge of these, particular products lend themselves to having elaborate or frequent motion, sound or illustration needs.

Finally, we have engineering specific skills. The first role you may consider is a design technologist, who would be responsible for building out plugins, integrations and hacks that help fill gaps in your design and engineering processes. However, as teams grow, it would make sense to include more specialist devops and platform specialisms to cater to the growing infrastructure that design systems creates.

Go big or go home?

Now, you might be wondering, how big does the team need to be? The truth is, every team and product is different based on needs, but to give you perspective across other products, we conducted a survey last year to get a better idea of design system team structure across the industry. Check out our full report, How We Document for more details, but here’s a snippet:

How many people are in a design system team?

What is the team makeup?

Building success with communication and diversity

Design systems are not all sunshine and rainbows. You need to remember to communicate and build relationships in the greater organization. In order to make a design system known and used by everyone, it’s essential to have champions through the organization, and amongst the different disciplines that touch the system. These are your design system evangelists inside their own teams – the “trojan horse” to make your design system more visible.

However, a design system needs a champion at a senior level, whether that be somebody embedded in the team, or someone outside of the team within senior leadership. This is someone who can comfortably communicate to senior leadership and heads of department, in order to avoid being siloed, not getting enough resource, or worst of all, getting deprioritized.

Finally, we’ve talked a lot about diversity in role, but it’s also worth noting that, just like any team, ensuring that your design systems team has diversity on a wider scale (such as gender, race, culture) is important in making it as good as it can be. People from different backgrounds bring a diversity of experience, opinion, perspective and thought that will ultimately make your end product richer, nuanced and more inclusive. A system built by and for a single group of people will probably be pretty darn boring.

Closing thoughts

We often mention libraries, components, tools and much more for design systems. But actually, I do really think design systems is human after all. It’s about communication, training, evangelization, awareness and pedagogy. All these things that automated tools and processes will never be able to do better than humans.Your design system can have the best library and tools in the world, but if nobody is using it, it’s useless and your design system is doomed.
However, suppose you have a solid and motivated team who will promote it. In that case, you have the best chance to get your design system on track and be successful.

You should consider building your design system team like building your foundations: it’s on the people behind the system it will lie, so it better be solid.
And if you only need to remember one thing from this article that sums up everything: design systems are made by humans, for humans.