Design Systems: the role of operations

How DesignOps teams are key to the success of Design Systems within large organisations.

Last week I spoke at the Global DesignOps Conference in Manchester alongside my colleague Ben Franck. The talk was focused on how we had shaped and implemented a Design Operations function within Centrica. (This was actually my last day working for Centrica, as I have now moved to BT Group as Head of Design Operations.)

During the talk we discussed how organisational changes and environments bought about the need for us to utilise DesignOps, to ultimately ensure our design team was set up for success. We also spoke about how we shaped the vision and goals for our DesignOps team and provided an overview of some of the key activities which we have focused on over the last 12–18 months, and the outcomes they have produced.

Due to only having 25 minutes on stage to share our journey with the receptive audience, there was a lot of content we decided to remove to ensure we could really highlight the breadth of our DesignOps discipline that we had set up.

One of the focus areas we decided to leave out was the role our DesignOps team plays in the operational side of Design Systems within our company. Even though Design Systems are a big part of our DesignOps strategy and roadmap, we really wanted to try to bust the myth that we find is growing within the industry at the moment, that DesignOps is fundamentally all about design systems, which it isn’t.

Since the emergence of DesignOps there has always been a strong correlation between DesignOps and Design Systems. Often talked about as the same thing, or one being the enabler for the other.

However, DesignOps is the practise of reducing operational inefficiencies in the design workflow (Credit to Andy Budd for this description.) — and design systems are one of the tools which can be utilised to help reduce these inefficiencies.

Put it this way, you can still have design operations without having design systems.

Codified Design Systems

Firstly, I really want to stress the word codified — I am a firm believer that until a design system exists in code it cannot be labelled a design system.

There has been lots of talks and articles written about design systems and the value they can bring to large digital teams and organisations. But I am going to focus on the role DesignOps plays in the operational side of design systems.

Education

One of our DesignOps strategic goals is to ‘Reduce waste and inconsistencies across the product.’ We identified design systems as a key tool to help achieve this goal. We were the drivers in bringing design systems into our company.

We educated teams and stakeholders on the value that having a design system could bring, highlighting inconsistencies in the current workflow:

1. The fact that we were seeing considerable waste and duplication of efforts across teams in trying to solve common problems.
2. The fact that more and more time was being spent trying to solve interface problems, rather than larger customer problems.
3. The fact that sign-off and approval processes were inefficient and slowed down caused by inconsistencies and misinterpretations of brand visions and guidelines.

All of these issues were seen as competing and blockers against the digital strategies of moving into more lean and agile ways of working.

Our first step was to gain sponsorship to have a dedicated team in place to focus on building out our design system. Previously, we had relied on senior designers and developers to be the advocates and provide governance of pattern and component libraries which had its limitations. But if we were to really make an impact we needed dedicated people in place.

Ownership

Our DesignOps team is responsible for the ownership of our Design Systems team. We run the recruitment, identifying what skills to bring into the team at various stages. We have a set budget we work to for the team and we look to find ways to maximise the impact the team is making by bringing in the right people at the right time. For example, in the early stages, we focused on having more strategic designers in the team who could help us to shape the roadmaps and longer-term adoptions plans alongside our DesignOps roadmaps.

Tooling

We work closely with the team in putting together tooling strategies and make sure they support the needs of wider teams and designers.

Adoption

And lastly, we work with leadership teams to help communicate out the adoption plans for the system. The big part of this work is collaborating with product managers to assess feasibilities of integrations and implementations of the system into their teams existing roadmaps and backlogs.

Key Outcomes

The biggest win for us has been getting a fully funded dedicated team in place that is now considered a product team. They have roadmaps, backlogs and KPI’s just the same as all our other teams.

Even though we are still in our infancy of implementing a design system, we have already seen some early wins through some of the new components which have gone live through improved SEO, performance and accessibility scores.

And lastly, a design system for us isn’t just a tool — it’s also acted as an enabler for a cultural change. It has helped to foster and grow a more collaborative community of designers and developers who now all feel like they have joint ownership of our guidelines and principles as they are continually involved in helping it grow. This increased collaboration is driving a reduction in design and development waste.

Recommendations

My first recommendation is for any design teams who are really struggling within their own organisations to get buy-in or momentum of getting design systems thought of as a valuable tool for their digital teams. It's hard to talk about the value a design system will bring, but it’s much easier to show this value. So I would recommend trying to secure sponsorship for a team for a short term period. Use this time to work on some quick wins and drive engagement. There will come a time when people start wondering how they managed without this team in place.

The second recommendation is to make sure the team works collaboratively and co-creates the system alongside other teams — if you want teams to be consuming the system make sure they feel like they have played a part in helping it grow.

And finally, and this is something which I have learned and changed my opinion on over time from seeing the impact the team has made working in a certain way; Early on in the process, I was championing the need to churn out new components so that teams had all the building blocks necessary to build their experiences.

This was wrong.

Yes, you still need to be building components, but much more time should be spent focusing on building relationships and awareness of the benefits of consuming the new system at the beginning. In the long run, this will help to increase the appetite for adoption.