Help Center

Design of people systems

Dan Donald

Talking to people in all kinds of scenarios with design systems, means I get to share some learnings that might help you on your journey. There are many differences between each set-up but one thing that stands out for me is how much a part of the success of a design system is the people around it. As such, there are a lot of variables around individuals, experience, team, and organization structure – the ‘people systems’ of our design systems.

It’s not just a question of designers and developers but more consciously creating structures to enable not just the design system to flourish but product teams to be empowered by it. This encompasses all specialisms in some way as, whether you have a dedicated design system team or not, the system itself needs to be properly supported and work for the teams that will come to rely on it.

Before jumping into what should be in your design system, it’s worth looking at the structures that are in place that could enable or hamper its progress. Defining the scope of the system, who and what needs to be in place for it to deliver what product teams need along with who might be potential advocates for the system, can help with adoption.

You may be familiar with running an audit of the design side of what might become your design system; looking at what exists already and looking for patterns. This isn’t the only kind of audit we can do to help us as we look at creating or maturing our system. The processes and ways that we work together can be designed, starting with how you work today and mapping out how your design system can coexist and adapt existing structures. All of this can form part of your governance model. Let’s start by exploring workflows.

Workflow audits

Let’s look at some possible workflows you and your team might have today. If we look at it in an overly-simplified way, a multi-disciplinary product team may have a process a little like this…

We have a relatively linear path from our problem space to releasing some live code for our audience to use in this example. You might iterate and work collaboratively for the most part or be very much waterfall but with a few notes, we have a simple visualization. Looking at your design system team’s workflow, it may be similar but have some differences. While components may be created in a centralized team, there would be different focus areas such as how they apply at a system level to ensure a robust shareable result.

This first step might not be as clear-cut as it appears. It’s where you can step into the role of facilitator to help learn as much as possible about how your colleagues actually work and their current pain points. It could be as simple as a whiteboarding session to get the reality laid out for everyone to see.

From our product team workflow, we can start to explore how we build in the use of the design system…

This starts us thinking about how in a simplified product workflow audit, you could add some references to the design system. As part of the work in the design phase, you go off to the design system to check what solutions we might already have that might help build our solution. If there’s something new that’s needed, you have an option here to create a loop for our contribution model, which we’ll cover later. 

Already, documenting workflow can prove useful. You don’t want to add more friction to the product workflow but do need contributions to the design system. Depending on your structure, you might not have a team that can pick that up; being pragmatic, what’s the best way of flagging that there’s either a new requirement or contributing a new component that’s been designed for a specific user journey?

One difference we have is in the way we think about our new component. When we think about naming, in a product workflow, we might give it a name related to its current use case. From a system thinking perspective, we might spend some time thinking about its broader use cases and find a clearer name, which may be more generic.

This one step of workflow could have a negative impact on our product workflow if we’re not careful. This is the balance we need to strike: enabling product teams to solve their problems alongside the needs of the design system. Over time we might not feel much impact as the range of solved problems (components) in the system increases and our contribution model matures. All of this assumes a federalized or hybrid structure whereby the creation of things for the design system isn’t the sole responsibility of a single team. 

Contribution models

This segue is an important one; giving people clarity over how additions and modifications can be made to the contents of the design system. That could be to documentation or to components themselves but setting expectations and giving even minimal guidance is a great place to start.

A contribution model could be something like this…

Here we start with a proposal stage which may be a road-tested component created in a product squad. How should someone volunteer this for inclusion? What is it that we need to know about it in order to know if inclusion is appropriate?

• What is its purpose?
• What problem does it solve?
• What use cases does it have?

This proposal may come from the design stage and be critiqued before it’s been built-in code. It may exist both in a design tool and in code at around the same time and so the process for inclusion might require pull requests in Github (or similar) for code-based contributions as well as how to incorporate the design into the library. In Figma, branching now exists, which roughly mirrors the branches developers might use in Git. This is work that you can do that doesn’t affect the main codebase or design file until it’s changed have been merged in.

• What state is the proposed component in?
• What work might be needed to ensure it’s in the right format for the system?
• Are there any dependencies on this work being included in the design system?

Talk of refactoring is common in development; a process where you go back over some code to see how it can be improved upon. This same process may be needed with a component submitted for inclusion in the design library – some degree of consistency might be needed in how the component has been built so the designer’s experience of using them all is predictable and reliable…as a developer’s experience of using a component should have consistently named props and ways of consuming them. This is where the details and application of systems thinking can add real benefit.

• Are there established conventions that the component might need to adopt that it hasn’t already?
• With naming conventions, does it describe its purpose and intent for the broader system over its current use case?

After this process, the component has been integrated into both your design library and codebase. How do you know it’s doing what it should? It could be that a quick review with the person that submitted the component for review along with those that did the earlier review process may be enough. Maybe there are automated tests that could be written for the code? Perhaps a wider review across product teams might help with validation?

The work is now available for product teams to consume and use in their work. Great! You started with a few sticky notes and found that each step in the process could be relatively involved. Each time you go through it, there’s an opportunity to learn and see if we’ve got the balance between clarity for contributors, maintaining quality output, and not making this a time-sink. Contribution should be a positive thing so we need to be mindful of pain points that emerge over time and keep refining the process.

What’s important here is that however, your model works, given your structure, you communicate it clearly, are realistic about the time that may be needed, and provide feedback loops. Ideally, we want to find and remove as much friction as we can – so listening to contributors is key!

The map of our workflow, still just using stickies, is growing!

If we add in any creation of new components for the design system team, it might roughly mirror that of the contribution model if this simplified view but has more focus on systems thinking, testing and validation of the concept with representatives from product teams, etc. 

Viewing it like this, even simplistically, we can ask questions of ourselves; which should take priority? What resources do we have? If a contribution is made, how can we respond to it in a timely manner? 

Bugs! Bugs! Bugs!

Despite our best efforts, sometimes bugs still make it through and someone may report it to the design system folks to resolve. We can roughly mark this up on our workflow.

In this case, a bug could arise from either design or development and have a similar process to get to a resolution. Either way, we need to triage the report to gauge severity and whether a quick fix is advisable and possible or whether it’s actually a bigger piece of work to rectify. Assuming this centralized design system team has to resolve this, it’s another potential workflow that they need to be aware of. We now have new components, possible contributions, and now bugs/error reports that might come in.

If there is no centralized team, mapping in this way can help work out where responsibilities should lay. In a federalized model, a product team may do these workflows themselves, which can add some overhead to the product features or user journeys they’re working on. It can also be worthwhile looking at when and how communication should happen between teams so that everyone is clear on the current state of the system and when someone is picking up a design system task.

I’ve kept this advice quite generic to make it easier for you to apply to your situation but encourage you to audit your workflows; map out what teams are affected and can feed into the design system you’re creating. Working transparently and collaboratively at this stage can set the tone for the whole project. Like anything in design systems, it doesn’t mean it’s set in stone. In fact, having even a lo-fi method of visualizing workflows gives everyone something to refer to, challenge, or critique so it can be refined over time and can be a great way to start documenting your system.

Team and org structures

It also means that before you’ve even looked at your colors, you have a sense of how it might work and gives a shared space and focus of discussion. From a high-level view like this, we can break down various specialisms’ workflows and see where potential pain points might be, and see how any potential friction from there being a design system could be removed or mitigated. Going back to scoping your design system, if your scope ends at design or documentation then is there a step for review of a coded component before it’s released? If the scope is end to end (so coded components are considered part of the design system), then how can product teams feel empowered to solve their problems for their users?

As with many things that can become complex over time, start with something simple; use a whiteboard or Post-its and move things around until it maps how things work today and imagine how you might want them to work tomorrow. Get feedback, revise and share it in your documentation site. Maybe that’ll be the beginning of everyone having a shared understanding in a convenient, shared space.

There are a number of things this can help you with, some of which are finding the answers to questions like these:

• Who should be a part of conversations around workflow?
• How do things work today?
• What governance model do we think best describes how we’ll run the design system?
• With what we’re proposing to do with our design system, how might things work in the future?
• What points in the workflow can the design system improve?
• Where might the design system run the risk of adding friction?
• Where are the opportunities to embed good communication practices?

Before opening a design tool or writing a line of code, we should have an idea of how the design system might work and also gain some clarity on the impact it might have. All of this should be challenged and debated so the ways of working can come as much from the people doing the work than imposed upon them.

It’s always interesting to hear how people work on design systems. Are you doing something similar? Are you doing something completely different? What complexities have you come across? We’d love to carry on the conversations on zheroes (our Slack community). Join today and tell us your story!