Nurturing the design-system

“Dream big, start small and grow fast”, that’s the mantra for modern day agile product development. And that’s how I approached this ‘personal’ project.

I write ‘personal’ project, as the company wasn’t quite aware of the need for a design-system. To build adaptation for it within the company, I picked for a strategy the path of showing the added value the design-system was bringing to the D-GEO Suite team, to other product teams. I presented the way we worked and its outcomes to software engineers, testers, product owners and managers, and had even architects present what their team gained from having this way of working using a design-system.

A design-system needs a certain level of UX maturity.

Let’s be clear: A design-system is not just a set of shared (nowadays often Figma) design components with their respective states. Yes, we do need to have those design components to support rapid design iterations, but that alone doesn’t make it into a system. The term system already indicates things should relate. What things then? Ideally everything, but let’s keep things practical.

From my perspective, a design-system is in place to support the product development in all its stages for all competencies. And as we’re talking about product development, we certainly need to have the end-user be part in this process. And that’s where UX comes in. The UX domain supplies in research and creative processes to support the product development. So before a design-system can be of any help, we need to have the user-centred aspects of product development in place in some sort of way. In short: we need a UX professional in the team to do research that answers the ‘what’ and ‘why’ questions and to design the ‘how’.

The whole team benefits.

The design-system is beside the design components, also a repository for product related insights and findings during the research activities. And also for the product related decisions made by members of the team. It documents or forms the glue between all the product development activities. That enables to revisit findings from research or design decisions on for example why a certain decision was taken 3 years ago, and now is being reconsidered as it’s blocking progress of the development of a new desire.

The documentation also includes how UX is part of the DOR and DOD of the team’s agile process. On the business level of product development we document things like stakeholder maps, proposition-canvases and user journey maps to share the insights of the markets.

When there’s no (active) CRM in use, the shared stakeholder management between PO and UX finds its log also as part of the design-system, since UX has most likely the most intense communication spikes with stakeholders.

Measure outcomes over output.

The growth or maturity of a design-system can be seen as progress. A measure for success, but is it? Does it matter how many components you have documented in your library or repository? It is an easy measurable factor, but from my point of view it’s of no value. A design-system’s success is measured by its adoption grade/level. The more teams use and contribute to it, the better. This brings me back to my earlier statement: “a design-system is not just a bunch of components”, it’s a way of working – a strategy to accelerate and increase efficiency of the product development process in general.

Onboarding new designers

A great way to stress-test a design-system on the design level, is to hand it over to another designer and have them use it and work by its principles and guides. We learned that the hard way. In the last years we’ve had the oportunity to experience to extend the design team and switch designers. This learned us to think of knowledge transfer for designers. We needed some onboarding process to garant a smooth transition into the product development team.

Testing the design-system in a whole new context

It took quite some time before I found a viable opportunity to actually put the design-system to the test on its full scale. I wanted to test with a product way out of the context of the D-GEO Suite to find proof for its versatility. Luckily a project in a totally unrelated domain required a redesign of its user-interface. Such a project is ideal to test your design-system as requirements and expectations are outspoken and already evolved over the years.

To set boundaries for technical and functional requirements, I started with some desk research on the current state of the product. A big help was the information from user interviews gathered by the product team earlier. By conducting additional interviews with stakeholders I could verify my understanding of the product and the way it was used by customers. Together with the team I created a set of usage scenario’s for distilling functionalities the new product should provide in its most minimal but viable form. With that as a reference, I could start researching on how this product would comply with the design-system and all the design rules and principles in it.

First I sketched a flow of screens that supported the scenario’s to give me an idea of blocking design principles and what components were missing in the design-system. After having that flow confirmed with stakeholders, I could start to drop in components from the design-system. I was actually surprised to see the product was coming together way faster than I expected. Most of the actual design effort went into the creation of new components and its foreseen interactions.

Connecting the dots

At forehand I had quite some confidence on the effectivity of the design-system, but it performed actually much better. When the PO showed the new designs to a select group of SME’s to gather feedback, all that returned was love and the expected desire for even more. After a small development team did some research, they could build an impressive amount of UI in just a few days re-using software components from the D-GEO Suite team. This shows, that even software architecture and the development of components has a place in the design system.