Expectations and responsibilities for design system teams
Part of starting a design system team is hiring. Design system is essentially a platform team, and such team needs people with special skills to be successful. When they get on board, they need a clear set of expectations and a launchpad for their career at the company. The tool through which you, as the team’s leader set that in motion, is crafting and deploying job descriptions.
In this post, I’m gonna try to summarize a few things that go into writing job descriptions specifically for design system teams. Mind you, my experience is limited and my knowledge is pretty shallow, so there’s probably going to be a handful of edits in the next couple months and years, but I hope that it’s useful enough anyway that you can get something actionable out of it.
This post assumes you’ve hired people before and are familiar with the process of writing a job description, but looking for tips on how to cater specifically to design systems.
Start with the jobs
Platform layer requires a patchwork of small but valuable things to be done every day.
There’s a collection of those things that are hard to put your finger on but that need to be done. This is true for every team, and a design system team is not an exception. Sure, there are permanent roles (or, job titles, the ones you put on LinkedIn), and typically each team member is assigned with a permanent role (such as “product manager”), and there are temporary roles (more commonly referred to as roles, and it’s a bummer LinkedIn doesn’t favor those) which people take on a project basis (such as “tech lead on project ABC”). But then there are these things in between that need to be done. Since I’m bad at finding awesome, gimme-gimme labels for things, I call them jobs. Writing user documentation is a job. Hosting a meeting is a job. Interviewing people after they had made a request or contribution to the design system is also a job. Listening with a purpose is a big and very important job.
R2Someone has to do them, but who? The answer is: every person on the team. In the beginning, distributing them evenly across the team members might be a good idea, but in a well-shaped, established team, you want people to leverage their natural strengths and pursue things they’re genuinely interested in. Still, at the team level, these jobs need to be fully covered.
So it’s a good idea to start looking for each of those distinct things that the team does on a daily basis, even if the team is just you. Some (actually, most) of them are going to be more or less recurring, which means that each can become an integral part of someone’s role expectations.
Some of the jobs are glue work. Still, it’s a good opportunity to make them explicitly part of the expectations and responsibilities. Staying at the platform level only multiplies the “invisible work” effect, so if you want to help people feel more aligned with what the team needs to succeed, write these things down and make them part of the formal job description.
A rule of thumb for platform work is that about one-half is non-production work, meaning it’s not about directly building something and it does not create any tangible deliverables. A big part of that half is communication, a lot of it. You want that on the list of expectations and responsibilities, because you want to filter the candidates on that, encourage people who made it to the team to continue doing this work, and proactively manage it.
If you’re just starting out, I would recommend not trying to guess what jobs are going to pop out on the team. Instead, go in with an open mind and figure things out along the way and as fast as possible. And again, if you’re starting a design system team, it’s probably because the org sees the benefit of having one, which means the org is big enough to notice the difference: there should be people in the org who are genuinely interested in this work and whom you can recruit, even if temporarily, to help make early progress and seed your staffing plan with early knowledge.
R2Define the permanent roles on the team
Think about the permanent roles on the team. Keep the number as low as possible and hire with agility in mind: if the design system team is successful, there’s going to be a few state transitions that will challenge the set of permanent roles you have. However, you do not want to respond too quickly and change the org chart around the team. On the other hand, folks on the team deserve at least some degree of certainty about their roles, and formal job titles can give them that.
In my case, we started with a product designer, product manager, and two frontend engineers. No one had any specially named permanent role (job title) that mentioned the design system or UI platform. At that early stage, this was the least important thing: we were focused on creating value. Everyone was doing everything, and the what we thought was “everything” was a rather limited set of tasks. When I look back, it feels right.
When you’re starting a team, you might not have a huge budget. If “design systems” is something the org, especially senior managers, haven’t heard enough of, they’ll treat it less as a predictable way to make the org more productive and more as an experiment in org design and scaling. If they are sufficiently informed, you’re in a much better spot to start as ambitious as possible with staffing the team.
There’s a lot of ways to name a permanent role, but for the most common ones, I typically see “UX engineer” or “frontend engineer”, “product designer” or “UI designer”, and “product manager”, with the suffix “design system”. Here, I want to encourage you to do some research and simply skim the job boards to see how companies name these permanent roles. Staying aligned with the market on how the permanent roles are called will help reach more candidates. The times of design ninjas and rockstar engineers are over (or, if you believe in job market pendulum and waiting for another swing, are yet to come).
Connect the jobs with the permanent roles
Once there’s a plan for the permanent roles (aka job titles) and a good understanding of the jobs on the team, it’s time to cross-match the two sets.
This exercise is messy, because mapping one big set onto another is never easy, but the point of this exercise is not to come up with a perfect plan. Instead, the point is to reach a good-enough state and go with it. Things will keep changing anyway, and it typically takes a few people to join the team before the permanent roles and the jobs on the team both stabilize.
A few obvious omissions might come up. For example, actually implementing the changes: that’s the opposite of glue work, but it should be on the expectations and responsibilities for the relevant roles. A product designer on the design system team might be responsible for keeping Figma in a good shape, components in the library useful and discoverable. A UX engineers might be responsible for maintaining the code and keeping it in sync with the visual tools that designers use.
Most of these obvious omissions are going to be each permanent role’s primary responsibilities. Those are typically the ones that are on the ads on the job boards. In fact, most managers start with those and often stop there, relying on inductive thinking. But we just did it the other way around: we deducted primary responsibilities from the negative space that all the jobs on the design system team take.
Awesome!
Summarize a lot, generalize a little
When crafting expectations and responsibilities for the permanent roles on the design system team, it’s tempting to go big and put things like “drive the success of the design system”. There seems to be a threshold after which these statements become just too vague to remain actionable. To avoid that, make sure you mostly summarize things that exist and only occasionally broaden it up. And even if it happens, it should happen with purpose.
If a product designer on the team fulfills the jobs of writing “do vs. don’t” guidelines for UI patterns and components, and writing release notes for the new changes that are about to be published, both these things sound like “internal communication”. This might go well on a job ad on the internet, but for an expectations and responsibilities doc it’s a tad too ambiguous. You probably want to add two separate statements that emphasize the difference: “regular communication with internal stakeholders” and “design system documentation that is used frequently with productive outcome”, or something like that.
But please don’t generalize it too much. A never-do-that example of unnecessary generalization would be a statement like “ensures proper usage of the design system through communication”.
In fact, even in my own example of one of the primary responsibilities for a product manager: “Ensuring data-driven decision-making for the design system as a product that is aligned with its long-term vision” — I’m not sure about this one, it sounds too broad to be useful.
Involve the team, publish, and iterate
Once the expectations and responsibilities for each of the roles on the design system team are documented, it’s time to publish them.
Depending on the org culture, this might not be a good idea to share something that is purposefully incomplete and subject to frequent changes. Organizations that tend to avoid rework and value perfection over usefulness are the ones that often inadvertently punish managers who prefer iterating in public. Conversely, organizations where imperfection and frequent changes are part of the norm tend to prefer that over changes that turn around too carefully and slowly.
One thing holds true in either way though: the people who are directly affected — people on your team — want to be involved. And you want them to be involved! If you’re hiring the first person into the role that you just crafted expectations for, be open about how flexible those are. This, in fact, seems to be a standard practice in the industry: to announce upfront that things are very flexible and likely to change when interviewing first hires for a new role.
Okay, hit the “publish” button already? Congratulations!
Also: metrics and rituals
Usually it’s the primary responsibilities that get assigned with metrics that more or less accurately track performance. But the jobs — most of them are very hard to track. I found that ditching attempts to turn them into metrics and instead focusing on making them team’s rituals pays off pretty well. It takes time, it lags behind the team formation cycle, and it’s very hard to keep up as you restaff the team with new hires or local reorgs. Doing that doesn’t scale and it doesn’t seem to be appreciated by the org that much, which might feel like high-effort, low-impact work for your personal career, but it makes — bit by bit — a profound impact on the design system team and the surrounding organization. So, worth doing it regardless!
So again, I have a pretty modest first-hand experience hiring specifically for a design system team, and there might be some blank spots or controversial points that I made in the post. Still, hopefully you could take some of the information and apply it or use it to adjust the way you set expectations and responsibilities for the permanent roles on your team. If that’s the case, awesome!