From pixel pushers to problem solvers,
how a design system broke siloed teams
3x Product Design
1x PM
4x Front-end
2x QA
3x Leadership
The Problem
After a few weeks of frustrating design team calls we realised that having sources of truth would solve a lot of our problems, so we decided to make 2 master Figma files.
The elephant in the room
While these files helped us create consistent, high-quality designs quicker one thing still bugged us, what users used very rarely matched our designs.
In Nigeria/Kenya people have been burned by scam businesses, sloppy looking websites look less trustworthy to them.
To solve the problem of production code not matching what we designed we knew we needed to create a design system.
Denial and proof
Previously we’d been working in a waterfall environment. Design hands over to PMs and they handle the delivery, it was rare for designers and developers to talk to each other. To break down the siloes we set up a weekly call with people from Product Design, Front-end development and QA.
At first we found our different mental models colliding, developers thought we were over-reacting about small things like the wrong shade of a colour or a slightly misaligned button. To understand how big of an issue designs and code not matching was we set up a little experiment.
This data was a real eye opener for developers and QA, when we dug into why this happened we found 3 main problems:
Negative conversations can be hard to have, but by ensuring everyone knew this wasn’t about blaming we were able to maturely discuss how we’d found a problem and now as a cross-collaborative team we wanted to fix it.
Seeing the world the same way
As product design, front-end and QA were previously siloed the first few weeks of calls focussed on how we’d best work together.
Leveraging Monzo’s “Working with me” document we each presented 1) What I’m good at, 2) What I’m not good at, 3) How to work with me.
Additionally we showed our Myers’ Briggs Personality Type and created a safe space to openly share both quick wins and bigger frustrations:
Knowing the present to shape the future
Before we could talk about how we’d build a design system we took a step back to understand how our current system worked.
After auditing our colours, type and components we found many inconsistencies we could fix by standardising new styles and rules in our Figma component library.
As we dug deeper we found ourselves asking some very important questions that would shape the way we’d build our design system:
Perhaps the biggest question though was around the scope, what’s our MVP?
Getting priority to build 60+ components wouldn’t be easy, any time spent building the design system would be time away from solving other important user/business problems. With this in mind we defined the MVP based on 3 things.
With this in mind we defined the MVP based on 3 things:
With this in mind we decided the MVP would focus on the 25 core components users needed to sign up, log in and onboard with us. Once we’d proved the value of the design system we’d get priority for creating the rest of the components in our transaction flow and other ancillary pages.
Anyone can be a designer
While front-end devs researched how to build the MVP with scalability in mind, product designers prioritised and estimated the effort to design each of the 25 MVP components.
Over the next few months each product designer created working Figma components which we demoed in our weekly team calls.
As well as ensuring we had a consistent visual language and user experience the demos helped in 2 other ways:
As an exec, I want to …, so that …
After several months of iteration we completed our Figma component library. With this, a front-end development plan and a bit of prioritisation it was time to get exec buy-in for building the design system in code.
At the start of the project the design team felt undervalued. I was frustrated with PMs and execs always deprioritising good user experiences, until one day I asked myself “why?”.
To better understand the PM and exec mindset I took a 6-week course in Product Management and Strategy. Throughout the course I learned lots of great skills around research, prioritisation and defining success metrics, but perhaps the greatest thing I learned was the idea of Mental Models.
It sounds obvious when you say it but people are different. Our different experiences, upbringings and skillsets mean we see the world in very different ways.
Let’s put on our empathy hat for a sec and imagine PMs and execs as users, what are their goals and desires, what challenges are they facing, how do they view the world?
With this perspective it’s understandable why UX was being deprioritised. To get priority for building the design system we reframed the project to what decision makers considered valuable.
With a design system we:
After solidifying our pitch, one by one we got buy-in from the heads. The head of QA, Front-end, product design and both the head PM/engineering manager for the customer-facing products. With the heads having bought into the project we got buy-in from both the CPO and CTO. This project was actually going to happen!
From planning to doing, the building of a design system
To ensure the design system went from Figma to code as expected, front-end devs taught the product design team:
As colour and type are the foundation of any design system we started with them, then 1 by 1 we created and prioritised tickets for each of the MVP’s 25 components.
Since this project would be the first time product design and front-end/QA worked so closely together, to ensure smooth collaboration we set up our own retros, planning and check-in sessions, as having an open door for anyone to ask any questions as and when they popped up.
Design as a service → Integrated design
After 5 months of working hand-in-hand with front-end devs/QA we achieved our goal of creating an MVP design system — everything we needed to deliver user-friendly, technically scalable products quicker. Check it out at here.
Looking back, we went from a waterfall environment where product design and development/QA didn’t talk, to designers being a valued and integral part of the delivery process.
A second elephant in the room
Soon after launching we knew there was 1 more issue we needed to address, developers/QA were getting frustrated by the ever-growing mountain of tech debt that they never had the time to fix.
Previously we thought we could launch a new product in 3 months, it ended up taking over 6 months.
Having proved the value of operational efficiency projects with the design system we kept up our momentum and piece by piece refactored our React applications, and shortly after, the product design team made the jump from waterfall to scrum.
2 years later: The value of a design system
We’re now delivering higher quality experiences faster:
What we learned
While creating a design system we learned lots of great hard skills from best practices for auto-layout to prioritising work, the most valuable skills we learned though were not hard skills but soft skills.
If we could do the project again I’d focus more on measuring quantitative than qualitative.
It’s amazing to see just how big of an impact this project had on the way the business approaches product development. We went from ‘Limited’ UX Maturity to ‘Emergent’ and over time we’re even getting closer to being ‘Structured’.
