The many hats of the Systems Designer
Design systems are a fairly established reuse practice for creating software in a consistent way. Make a button once, use it over and over again. But the role of the System Designer is often murky and open to interpretation by leadership, the designer and even system consumers. Ambiguity can signal opportunity to define what’s unclear today, but there’s also a high risk of overload and mismatched expectations. Systems Designers need to play an active role defining the value they add and the ways they act.
What’s a Systems Designer?
Systems Designers can exist in many different contexts. The general role serves any type of business that needs to make their technical work or processes more effective. Today, I’m talking about Systems Designers in the context of creating enterprise-level design systems. Systems Designers spend part or all of their work hours (and sometime free-time) creating reusable tools in the shape of design systems. They make the components, variables and guidance to help product teams get new things to market faster at higher levels of quality.
The big picture is all about being competitive as an organization.
The practice of reuse and the skill of systems thinking can apply to the work of any designer and developer. Designers might create product experiences in a reusable way and collaborate with their engineering partners to do the same in code.
What’s a design system, anyway?
If design systems were only components, styles and guidance, this job would be pretty straight forward. But they aren’t, so it isn’t. Design systems can expand to contain a whole range of helpful services:
- Training product designers to create recipes or smart components
- Onboarding new designers to the system
- Answering questions on Slack or in office hours
- Educating executives on the value of systems
- Championing strategic ideas like deeper system revisions
All of these aspects are very valuable, but they also fall out of the typical designer’s initial career vision. You don’t study graphic design to end up in customer support, and it’s hard to shift from visual design to DesignOps. The most successful Systems Designers I know have found a way to embrace all the new hats by leaning on past experience and skills in unexpected ways. They’ve been open to discomfort because comfort is the enemy of growth. They’ve applied design thinking and service design to adoption and contribution experiences. They’ve leaned on their experience using design systems to have deeper empathy for their audience.
Flexibility & discomfort
It’s good to be flexible. Based on where a design system is at and the problems a team is trying to address, teammates might have to lend a hand in unexpected ways. This isn’t unique to the Design discipline. The designer might need to investigate developer painpoints and work on highly technical documentation. A developer might have to lead some cross-discipline strategy workshops. A product owner might have to focus on marketing to engage potential adopters. But if your role is entirely determined by the demands around you, things might shift or bloat faster and more continuously than is healthy.
It’s also good to embrace discomfort during seasons of growth. If a project seems like something that you can’t do on your own, consider taking it on anyways and leaning on those around you to learn by doing. But it’s also important to define expectations, responsibilities and desired growth. If Systems Designers are steered by the demands placed on them, they’ll almost never break free of the seasons of discomfort.
The many hats
The opportunities are bottomless and richly-varied for Systems Designers and their teams. Designers take different approaches based on personality, context and project goals. The hats they wear and how they operate result in a few archetypes which have strengths and risks. No one is locked into a single hat (that’s not how hats work) and designers might switch hats week to week and even throughout the day. Let’s take a look at a few:
The lone wolf 🐺
When there isn’t a dedicated design system team, it often falls on one person’s shoulders to make or continue a system and motivate others to join the cause. Early days, this person faces a mountain of work and stress but also enjoys massive satisfaction when things are trending up.
When there is a dedicated design system team, a lone wolf will attack deep problems with lots of heads-down-music-on time and come back to the team with brilliant ideas. This person can be the burst of inspiration and direction a team needs to keep moving, or they can be a bottleneck of decisions and information. At the very worst they come back with ideas that aren’t grounded in reality or the knowledge of the whole team, or they become the only person who truly understands historical rationale.
In either case, the lone wolf needs to invest time uniting with others and creating out in the open. For the sake of the team and their own mental health, remaining an island is not sustainable. This might look like bringing work back earlier in the process or taking ideas to peers individually for feedback to cover knowledge gaps. No matter the context, the lone wolf has to find a way to work with the pack.
The mad hatter 🎩
Because there are so many opportunities to make components, teach best practices, speak at conferences and generally improve the system, it’s very easy to move from one topic to the next without causing significant impact. The mad hatter can moves between topics very easily and sees the forest and the trees. But if they move too quickly they’ll never effectively clear the forest (or plant new trees deeply enough).
Mad hatters can also inspire teams to connect topics that might seem disparate. They can be very effective in forming strategy, but need help getting that strategy on paper and in action. Like the lone wolf, the mad hatter also needs to unite with others to see their vision in action. If they are on their own, they will need a way to dedicate the time to execute ideas.
The empathetic teacher 🫶
Being a good teacher is a great skill to have for Systems Designers. Teams using the system go through a journey from onboarding to daily use to updating and eventually contributing. At every point along the journey, there’s an opportunity to teach best practices. For Systems Designers who deeply understand the system and have a passion for teaching and helping, the opportunities are endless. There’s always more that can be done, from teaching sessions to office hours to consultation on contributions.
Empathy and a passion for helping others learn and grow can result scaling their impact across a large group of people through multiplication. But teaching needs to be balanced with the creation of new components, fixing bugs and refining design assets. The right balance can make all of these deliverables much more effective because the work is guided by a deeper knowledge of the people who will be using the system.
The biggest risk of being an empathetic teacher is rooted in time. As teachers connect with others and build more relationships, they can easily become the go-to person for more and more questions. This can establish recognition as a subject matter expert, but it can also soak up every minute of every day. Teachers need to be intentional with their time and work to set up better processes so things like support questions don’t fall solely on their shoulders.
The consistency police 🚓
Having a system is great, but how can we make sure teams are using it? If the design system team doesn’t mandate system use, who does? Often, the question of authority comes up. Do Systems Designers have the responsibility to make teams use the system or prioritize adoption? From what I’ve seen in my limited experience, the design system team has the passion but not the authority to mandate adoption. For the designer wearing the consistency police hat, things can get very tricky and stressful. They so badly want to see adoption trend up and consuming teams working more effectively, but they often have no control over this goal. They patrol critiques, escalate divergence and can feel a ton of anxiety as nothing changes. They mean well, but all their energy goes to fixing the symptoms instead of the root causes of unhealthy adoption levels.
The consistency police hat comes with insight into proper system usage and a strong drive to advocate for reuse. This is a big asset to the design system team. The opposite of love is apathy, and passion is a sure sign of belief. Find ways to apply this passion to the root cause instead of the symptoms. Make tools for designers and developers that set them up to more quickly adopt and use the system. A drive for consistency can result in plugins that automatically convert design files to replace hex codes with system styles. This designer can help others see how system application can open up new opportunities for creativity and a way to apply visual enhancements. Consistency doesn’t remove creativity; it applies creativity at scale.
This is self-reflection
The point here is to share some of the things I’ve observed and the hats I’ve worn in the past. These are largely the observed benefits and costs from my own experience. As Systems Designers, we face a tempest of change in organizational goals and technological possibilities. It’s all too easy to let the waves set the direction. Shifting our mindset by swapping hats can help designers tackle a wide range of opportunities more effectively.
This list of hats is far from complete. I’d love to learn about what you’ve done or observed working on deep system problems and building alignment!
