June 1, 2023

Organizing your team…

After all we’ve talked about, you might be ready to jump in, do a content inventory, interview all your digital product teams, and start building the MVP of your design system.

Good.

This is practical design systems, after all.

But if you build a product that multiple teams rely on to do their job, at some point you’ll need to think carefully about how the system gets maintained, how your team is organized, and how it interfaces with the rest of your company.

Let’s start by looking at some of the ways your design systems team can be organized:

• Centralized: This is the model a lot of people picture when they think of design systems, and it’s most common at large organizations that can afford to support a dedicated design systems team. It’s often paired with a centralized CMS/platform team. Too many startups jump to this model too quickly, when the cost of maintaining a big centralized design system isn’t warranted yet.
• Federated: Think Hunger Games without all the death. In this model, systems-minded tributes representatives from the various product teams form a motley design systems team, using part of their time to do design systems work: cleaning up contributions from other teams, promoting consensus around naming, standardizing component structures, automating tasks, connecting systems, etc. Sometimes a single dedicated lead will help coordinate this effort. This is a good approach for small to mid-size organizations just getting started with design systems work.
• Distributed: No single owner of the design system. Each team contributes to the part of the design system that touches their own product. Usually this model is a result of not securing support or funding for a formal design systems team. It’s a challenging model because it’s hard to achieve consistency and alignment (a core promise of design systems), but it can work if the organization has robust communities of practice (guilds) for their discipline that promote best practices and communicate standards across the org.
• Hybrid: Some mashup of the other three models. (Org charts can get messy, so don’t be afraid to get creative.) This may even be one person trying to advocate for building a design system — don’t lose heart!

Whatever model you decide best fits your organization, there are a few common roles to be filled on a design system team:

• Lead: Oversees strategy and execution and helps communicate that vision to leadership (and the org at large);
• Product Manager: Prioritizes work and manage the existing backlog, a key role for centralized teams that are at risk of becoming bottlenecks for other teams;
• Researcher: Helps the team understand what improvement should be made to the design system based on research and analysis;
• UX/UI Designer: Curates existing and designs new components and patterns, with the goal of making them usable, accessible, and suited to the needs of your company’s customers;
• Front-end Engineer: Similar to the designer, but focused on creating reusable code components that meet functional, performance, and accessibility standards and can be used by other engineers in the organization (and sometimes SDKs, APIs, and misc. utility applications like token transformers);
• Accessibility Expert: Weighs in on design and engineering choices like color contrast, keyboard navigation, screen read support, etc. to make sure that they work for people with a range of abilities and meet WCAG standards;
• Content Strategist: Defines the tone, voice, and guiding principles for the text in a design system — and often all products in an org (this is a less common role, but in my experience, one of the most important).

Keep in mind, the less structured your design system model, the more these roles may vary or be absent altogether. A single person may often function in more than one of these roles.

…

Finally, a few thoughts on how a design system team can effectively interfaces with the rest of the organization. This advice is going to be geared more toward a centralized team model, but I think the principles can be readily adapted to other models.

• Stay in touch with your users. Meet regularly with the various teams that build with your design systems tools. Ask them what’s working and what isn’t. Ask them what projects are coming up and how your team can support that effort. Incorporate their feedback, and be transparent with them about decision-making and future plans.
• Keep your documentation up-to-date. Leadership might get a sexy slide deck, but documentation is how the practitioners in your organization will see your design system. Make sure its discoverable, understandable, complete, and up-to-date.
• Make yourself available. Much of design systems work is education, so use every opportunity you can to answer questions, explain, and gather feedback. Run workshops and training sessions. Set up a help desk. Hold office hours weekly. Send out a newsletter with latest updates.
• Participate in planning. By joining planning ceremonies, you’ll get a big picture view of the business goals, what each team is working on, what the capacity constraints are, and where your team’s efforts might be most valuable.
• Promote your team’s work. Your design system is a product, and a good product team understands the importance of marketing. Celebrate wins. Talk about the value the design system brought the organization.

There’s so much more I could cover, because this is a big topic with a lot of “what if’s,” but this should at least get you thinking about what it looks like to set up a design system team and work within an organization. Tomorrow, we'll talk a bit more about maintenance, growth, and contribution.

—
Cheers,

Up Next: Nurturing a design system community…

← Full Archives