From January to May 2020, I contracted as Product Manager for the design system at Babylon Health. You can read about setting up the Babylon Health design system in this post by Jack Roles.
One of the reasons I was hired was because of my involvement in establishing a contribution model for the GOV.UK Design System. It was hoped I could help to introduce something similar at Babylon.
But at the point of establishing that contribution model, we’d been working on the GOV.UK Design System for 18 months. It was relatively stable, supported by a good-sized team, and it already housed a comprehensive collection of styles, components and design patterns.
At Babylon, the design system was in its infancy. When I joined, we were still a few weeks away from launching it. The team working on it was much smaller, with just 4 of us working on it full time, and there was a lot of work to do to populate it with even the most basic building blocks of Babylon’s UI.
What’s more, unlike the GOV.UK Design System—which only needed to support web—the Babylon design system also needed to support Babylon’s native apps for iOS and Android.
With so much work to do to get the foundations in place and build adoption, designing a contribution model felt like a distraction we couldn’t afford.
Nevertheless, our colleagues were understandably eager to contribute, and we didn’t want to waste that momentum. They were the ones working on Babylon’s products day in and day out. We—being one step removed from Babylon’s users—didn’t want to act as gatekeepers. So we had to think about how to enable contribution in a way that was manageable, and didn’t detract from our work on building the design system.
Proactive versus reactive contribution planning
One feature of the GOV.UK Design System’s contribution model is that it was reactive, from the perspective of us in the team maintaining it. If someone wanted to contribute, we’d work to support them in doing so, diverting our attention from other things if needed.
For the reasons I’ve outlined, I knew this approach wouldn’t work at Babylon. We needed to stay in control of our backlog while we were putting the foundations in place and avoid distractions.
So instead of waiting for contributors to come to us, we decided to create specific touchpoints for contribution. And instead of opening the floor to any kind of contribution, we planned to ask people to contribute to the components we were working on at the time.
This would allow us to keep progressing through our backlog and building the design system, whilst getting valuable input from our community of colleagues along the way.
Contribution as co-creation
We started to run weekly sessions called Atomic Thursdays, with each week dedicated to reviewing and improving a single component.
We’d advertise the session internally each week on our Slack channels, telling people what we’d be focusing on, so they could decide if it was relevant for them, or not.
To prepare for the sessions, Jack, our designer, would gather examples of the component from across Babylon’s products and from other organisations’ design systems. Based on this, he’d create an initial design for the proposed design system component and present it—together with the examples—on a Figma frame.
During the sessions, we’d ask attendees to spend a few minutes reviewing the component, and then add their questions and suggestions.
Once we’d collected everybody’s feedback, we’d talk through the comments one by one, and note down any actions we agreed along the way.
We’d hear from designers and developers who were using the components day-to-day about how to improve them based on actual user experience.
The sessions also included representatives from our team, who understood how to systematise them, and internal experts in content design, accessibility, engineering and visual design, who would provide feedback using their subject matter knowledge.
After the sessions, we’d write a summary of the feedback and next steps, and share it in our Slack channels to keep ourselves accountable.
Through this process, we made our components richer and more representative by co-creating them with experts in our organisation, and we created a space to share knowledge and learn.
Evolving contribution as a design system matures
I left Babylon while the design system was still in its early stages, but I’d hope to have seen this approach evolve as it matured.
As important as contribution is to a successful design system, it’s often not possible to design, test and maintain a process for supporting it, whilst simultaneously building the system to a point that’s useful enough for teams to start working with. After all, no one wants to contribute to a system that no one’s using.
And though some may argue that contribution could help you to grow the system more quickly, in my experience that’s never the reality. (See point 5 in my previous article on enabling contribution.)
With that in mind, a small design system team with limited capacity needs to make some trade-offs in the early stages of its development.
Finding a way to proactively encourage contribution to the components and patterns you’re already working on is one way to do this—but this practice should evolve over time.
As a system matures and starts to stabilise, it makes sense to loosen the reins and allow the system's users to contribute organically: to let them share what they’ve discovered and find a mechanism for them to centralise and share that knowledge and experience with others in the organisation.
Constraints are always critical but, over time, those constraints can become system standards, providing helpful guardrails that focus more on the how, and less on the what.