Help Center

Managing a scrappy, informal, or federated design system team

Michelle Chin

Design systems have to start somewhere, and typically it’s with a scrappy team, limited resources, or, if you’re lucky, people representing all your org’s different products. While this might seem OK initially, you’ll quickly realize it’s not ideal. After the initial momentum, deadlines slide when people can’t “fit in” the design system work, or there’s a lack of tooling, or it just takes too long to make decisions and progress.

In this article, I’ll cover the following:

• More accurate expectations of a scrappy design system
• Goals of a scrappy design system
• How you can make the most of what you have, and 
• How to get your design system to the next step – more people and resources.

I’ll speak from my experiences running several grassroots, scrappy design system iterations and from what I’ve seen working with design system teams while at zeroheight. 

Being scrappy should only be temporary

Before we jump into how, it’s essential to recognize that being a scrappy design system team should only be temporary. Consider “temporary” to mean a few months or a year, hopefully not longer. Managing a design system initiative can be such a heavy lift that we quickly can get complacent with how things are even when they’re not ideal.

It’s easy for design systems to live in a state of long-term scrappiness. They start because designers and developers desire efficiency in their workflow. As a result, employees often create them as side projects. Among managers and stakeholders, there can be an unspoken “tension” with design systems. They see the value in them, but they’re hesitant to fund them. This is because the business value of a shiny new feature resonates more than a design system’s value. And it’s also because if designers and developers so badly need them, won’t they fit it in—for free? Why should they invest in something that they can get for free?

As you manage the design system, remember its scrappy state is temporary until you can justify the need for a resourced design system effort. So let’s get back to how you’ll manage the effort until then.

Goals of a scrappy design system

The goals for a scrappy design system will be different than your design system’s end goals. (Think of end goals like IBM’s Carbon or Google’s Material Design – neither was built overnight on a scrappy budget.)

Goals for a scrappy design system should focus around:

• People – making sure you have the right people, enough of their time to work on it, and you’re not burning them out
• Design system – creating the design system itself
• Adoption – ensuring teams start using it

The key to achieving these goals (and justifying further resources) is to make the work as visible and tangible as possible. This means everything from being transparent to making diagrams people can see on calls to letting everyone know there’s a design system. 

People

Most design system “teams” start with one or two people interested in making a UI kit to make the team work more efficiently. While this is great, I’ve often seen designers create these kits during their personal time on evenings and weekends. This should never be the case. Design systems are the infrastructure that teams need to be successful.

When people work on it in their own time, it makes the design system work “invisible” – as if it just magically appeared. This gives the rest of the team, managers, and stakeholders the wrong impression that it was easy to create, quick to make, and “free.”

Instead, make the need for people and their efforts visible. Here are a few ways to do that:

• Provide them time to create the design system during work. Give them the bandwidth they need. This might mean reducing their efforts on other projects rather than giving them a typical project workload AND design system work.
  
• Walk managers through resourcing plans. Design teams are typically understaffed, so managers are reluctant to give up their designer’s time for things that aren’t immediately providing them value. In previous organizations, I drew up a rough plan for who I would need for a federated team and why. I showed them our product portfolio and who I had in mind to be their design system representatives. It almost made them feel like they’d be left out if they didn’t say yes. 😉 I also managed expectations around the time commitment needed. It was specific, like 2 hours for meetings and no more than 6 hours per sprint. That roughly came out to be, at most, 10% of their time in a two-week sprint. It was much easier to agree to something tangible.
  When working with developer teams, your approach might need to be different. They could also be as reluctant to provide resourcing, too. Check to see what options they have to include this in existing work.
  
• Get a Design Program Manager (DPM). I recently wrote about how a DPM can help a design system team. They can navigate a partially resourced team well to make things run smoothly.

Design System

There’s a lot that goes into a design system. But remember, you don’t need to add everything at once; you can include things over time. I talk about what to prioritize when starting a design system in this article, so I won’t go into all the details.

At a high level:

• Start with creating components in the tools your team uses
• Determine how the team will make decisions
• Create a backlog for everything, use a kanban board, and question the impact of things
• Celebrate wins
• Keep things simple and go with the flow

Here are a few more things to consider when running scrappy:

• Work the design system work into existing workflows. The team might not have the luxury of focusing solely on components. Instead, see where you can tackle components as part of other design efforts. For example, if a feature needs a form, this is an opportunity to allocate some time to create form components for the design system. Similarly, see if dev teams can do the same thing.
  
• Treat the design system like an actual project. This means talking about it in daily standups, weekly syncs, design critiques, etc. This could also mean tracking work through tickets (via Jira or Trello) and planning the work with sprints. Keep it as visible as possible.
  
• Use zeroheight to document your design system. zeroheight is easy for anyone to use, so maintainers will be more motivated to update documentation. And since the team is running scrappy, the documentation doesn’t have to be perfect. Focus on the content and if you have to, worry about grammar, etc., later. 

Adoption

All this work, even if it’s scrappy, will be for nothing if no one uses the design system. So the last goal of any scrappy design system is adoption. I cover adoption in more detail with this article, but for scrappy teams:

• Go where the people are. This means sharing the design system at existing meetings, kick-offs, showcases, etc. The more visibility you can provide, even if it feels tiring or repetitive, the better.
  
• Train people on how to use the design system. This could be hosting lunch and learns for design teams or dev teams on where to find tools, guidance, and so on for the design system. My previous teams would host a casual meeting where people could “beta test” the new UI libraries by recreating existing screens. This helps get people engaged and hopefully adopt the new kit.
  
• Work with PM and dev managers. Change can be challenging with anything new, even when it’s for the better. Creating a new code library might mean refactoring some code, which might delay things. If they’re hesitant about that, see what they’re willing to try in terms of adopting the design system. This could mean they pull from the component library in any new flow they code. And it could mean they’ll only refactor existing screens if they’re making other changes to them.

Evolving past scrappy

Getting past a scrappy design system team is the next hurdle. As I mentioned, people can stay in this phase for a while and grow complacent. But to truly level up your design system, you need to move past scrappy. Ideally, that’s having a hybrid governance model and adequate funding for staff and tools. Depending on your role (e.g., IC or director), comfort level, etc., you can carry this torch on yourself or build a team of advocates to help make a stronger case.

Evolving past scrappy involves some longer plays and prep time. Here are a few suggestions:

• Continuously talk about the design system. Talk about the team, their accomplishments in a scrappy capacity, the benefits they’ve brought, and how much better things can be when adequately resourced. You might sound like a broken record, but if you’re not talking about your design system, then no one is. I’d also encourage the folks on your scrappy team to talk up the design system as much as possible. There’s so much competing for your stakeholder’s time, attention, and investment that you need to be that squeaky wheel. The idea is to keep the effort visible so they don’t forget about it, and so there are no surprises when you ask for more resources.

• Demonstrate what you’ve done so far. This might take shape in a presentation you have on hand to show managers and stakeholders. If you can, build this along the way, so you avoid making this at the last minute. While it seems like one extra thing, it’s another way to create visibility. Slide decks (in addition to the documentation site) make the design system more tangible. A slide deck’s benefit is that people will share it once it exists – which is what you want.
  
• Propose more resources to stakeholders. Create a pitch deck when you’re ready to scale, and it’s an appropriate time to ask for resources (e.g., months before budget and headcount planning). Your deck should include the work the team accomplished and where you’d like to go. Explain the help you need to achieve those goals and the system’s impact on the business, not just the outcome. For example, an impact can be “we can quickly reskin companies we acquire” or “we can quickly stand up new product innovations.” If you have metrics you can tie in that prove business value and the team’s impact, please include those! If metrics are harder to come by, you can mention the risk of not doing something. Sometimes the risk of not doing will resonate more.
  
  I want to be realistic, though—it’s unlikely that you’ll get everything you want, so identify your single highest need. If they think you’re asking for too much, you can say that you’ll be happy if you could get “the one thing.” I proposed my design strategy in a previous company to move forward, and the stakeholders understood and agreed with everything. Unfortunately, the timing wasn’t right, but I got the green light on my one ask. (I asked for an “EngineeringOps Manager,” so someone like a DesignOps Manager to help scale the design system on the Engineering side.)
  
  Additionally, everyone left the meeting with the understanding that the design system is in its current state until further resourcing. And that’s something everyone, including me, had to be OK with.

Staying in scrappy mode

Sometimes, the team won’t get the resources or funding it needs. Often, it’s because stakeholders find the design system meaningful, but there are other higher priorities. As a design system maker, it’s hard to see there are higher priorities than something foundational. But consider how stakeholders are accountable for high-profile projects and other business goals.

While disappointing, this doesn’t mean giving up. Keep advocating for the design system, even if it takes longer to get the resourcing. This also means that everyone needs to be OK with the system’s current state, and if stakeholders want to level it up, they need to resource it adequately. And lastly, this isn’t where the team jumps in to “save the day” to create the robust design system everyone wants. This leads to burnout and contradicts the justification for legitimate resources. 

It might take time, but there is a way out of the scrappy phase. In our How We Document report, we’ve noticed companies resourcing design system teams and more people with “Design Systems” in their title.

DesignOps for Design Systems

This is one of many articles we’ll be writing about when it comes to leveraging DesignOps for design systems. If you have questions about how your design system can be managed better through DesignOps, feel free to contact us. We’re available on zheroes, our zeroheight Slack community.