Reimagining our Design System
I work at Jumbo Supermarkten in software engineering. At Jumbo we have a big tech department (affectionately called the Jumbo Tech Campus, or JTC) where we work on all of our digital products: from eCommerce and planning applications to AI driven models for stocking and inventory. I'm going to focus mostly on the eCommerce branch, since this is where we can make a big impact on our customer experience.
For our tech stack: we have an eCommerce engine which is enriched by (micro) applications and components built in Vue.js and Nuxt.js. There are multiple teams working on fulfilling the eCommerce goals and in order to deliver user interfaces as effectively as possible, we've built a component library that (in general, but we'll get to that) follows the designs and design system.
Customer comes first
The vision of Jumbo is to put the customer first, which in practice translates to, among other things, providing a consistent UI across applications. Especially when the sum of these applications facilitate the shopping activity on our platform. A customer would typically interact with several applications while doing this. Ideally without noticing this.
We have a couple of mechanics in place in order to facilitate this: our designs come from a central design collection. When a designer from a team works on an interface, they always have an up to date version of the design components to work with.
Similarly, we have a single component library where a lot of the design components have found a place. Our component library is published as a package so each team has access to the components. Ideally, we want everybody to be on the most recent version, to ensure that any tweaks in UI or functionality are synchronised.
Conway's law in effect
We are noticing however ...discrepancies between designs and development. Sometimes a component in code would be given an update to match a requirement, without updating the design. Sometimes a component in code would lag behind a design. We were also discovering mismatches in naming convention. This was Conway's law in effect. Our designs and component library were maintained with best efforts, but a bit too little of a proces. Which led to organic grow, which led to entropy finding its way into our structure.
Entropy, if left unchecked, leads to chaos!
With a vision and strategy that bets on delivering even more applications and even multiple platforms on our component library, we had work to do.
Interviews and collaboration
To solve our problem, we started to dig. Our first realisation was that, while best efforts were good enough up until now, in order to mature, we needed something more. Our first step was to found a (small) dedicated design system team, consisting of a UX designer and me. Our responsibility and goal was to solve the current issues at hand and to create a new definition of the design system.
We started with mapping the current situation, to try and find patterns that we could improve. We interviewed all teams in terms of their experiences, pain points, expectations and the things that actually went well. Interviewing individual teams quickly surfaced topics that applied to everybody. We made sure to note them down to be able to address them during our investigation.
Apart from internal interviews, we also talked to other organisations with different setups and ways of working. Those too provided valuable insights.
We realised that when introducing change, we needed to make sure that all stakeholders are onboard with our advice and that they understand why certain changes are being made. The interviewing process helped in starting to build those connections and we made sure to include people when applicable. We were also leveraging chapter meetings in order to give frequent updates.
This is your steward speaking
So how do we identify ourselves? We don't want to be policing other people: we would much rather guide and inspire them. In one of the articles (by Nathan Curtis) we've came across the term steward, which is used by Shopify Polaris design system team as well:
Steward: An official appointed to supervise arrangements or keep order at a large public event; a person employed to manage another’s property.
This resonated with our situation as well. We're stealing this! Yoink!
A wheel is a wheel
With the characteristics of our own organisation in view, we also looked to the abundance of online resources of organisation that followed similar journeys. With our limited teams capacity, we figured that reinventing the wheel is plain stupid. We made sure to pick the resources that had similarities in the organisational structure of Jumbo, because we knew that it would be easier to fit a proces to an organisation than the other way around.
Weighing the options
We uncovered a pattern of levels: levels of contribution but also levels of components. A component that would only be used by one team would not need the same level of quality than a component that sits at the foundation of our design system. It's sort of a gradient, and for the sake of simplicity, we divided components into tiers:
Tier 0 would be the starting point and contain our design tokens;
Tier 1 would hold our basis of components, the foundations of a certain platform (web or app);
Tier 2 is for components that are shared between multiple teams in a certain domain (i.e. eCommerce related components);
Tier 3 is what happens within teams.
Components can be promoted to a higher quality tier, if the need arises. Having this setup allows teams to weigh their options in terms of component usage and development. It makes it clear what level of quality you can expect for a given component in a tier. At least, once we're done laying those rules and foundations. It's a work in progress!
Apart from placing the components, we also looked at the types of contributions. They too impact the way we work and how easy it is for teams to contribute. We're distinguishing three levels of contribution:
A light contribution improves an existing component without introducing any breaking changes;
A medium contribution improves an existing component by changing it and maybe introduces a breaking change (say: renaming a property or changing the way it works);
A heavy contribution adds a new pattern or component or heavily modifies an existing component. It can, but doesn't have to, introduce a breaking change.
Those three levels of contribution, cross referenced with the tiers, result in sort of a matrix of possible scenarios. These help us on providing processes for these.
We are now here
Well, this is where we currently are. We have some work to do in terms of defining and validating our new processes. We have ideas, but we need to both work on validating our current models and our envisioned processes.
So far, it's been received well by stakeholders we've shared this with. This gives us good hope that we're on the right direction. 🧭