Over the course of a few months, I led a grassroots effort, proposed a roadmap, ran workshops with the core product team and built a component library in Figma whilst responding to adoption issues along the way.
Reusable primitives and component library drawn within Figma that has been fully adopted and is currently being gradually integrated in code.
Design Team – Contributors
Jack Westbrook – Frontend
Myself – Design Systems Lead
Casumo was growing at a pace we hadn't foreseen. As time went by, different product experiences began to sum up to an inconsistent whole with fragmentation at key touchpoints, leftover experiments and a mounting design debt.
Realizing our roadmap and product strategy felt like it was getting harder for the wrong reasons.
Our design system, lovingly named CUDL or Casumo Unified Design System wasn't exactly helping us out either. The project itself had course corrected multiple times and kept cycling between being sidelined and green-lit.
Since CUDL had a few false starts, I wanted to learn more about where previous efforts came short. To do that, I talked to some members of the core product team. What I learned was that there was:
In, short, there was a lot of housekeeping to do.
Given CUDL's history some people, understandably, weren't too sold on the idea of having a designer (and later on a frontend engineer) work full-time on something that wasn't a feature release.
Besides, all they've heard so far is nagging around how many inconsistent button styles there were.
I needed to reframe the problem into something non-designers cared more about which was:
This new vocabulary that I used at meetings and workshops wasn't the only tool in my arsenal, I made sure to couple it with a few artefacts I created to further my case.
One of those artefacts was an inventory spreadsheet which helped visualize debt. The breadth of permutations we'd seen wasn't just a sight for sore eyes though, as we uncovered a host of different opportunities where we can merge, extend or remove components.
Producing these documents and holding workshops was just the first step though. For this project to have legs, it needed some form of accountability. So I played the part of a product manager and introduced a few things:
I wanted to make sure we had asynchronous cadence through bi-weekly ceremonies such as check-ins and open forums, where we would discuss a change and it's impact upon different streams of work. This would happen through:
Having tried different team models in the past, including a federated approach, we recognized this project needed velocity and a dedicated responder to begin with.
So we opted to start with a mix between a solitary and centralized approach, which would be kept in check. Even though this model wasn't scalable and encourages gatekeeping, we needed speed to demonstrate value early.
Thankfully, I wasn't alone as I was lucky enough to have allies within the product design team as well as a few engineering counterparts including the native team and a few members from the frontend team.
I was fairly lucky to have found Jack, a frontend engineer, who had worked on previous iterations of CUDL. Over time, he had made a lot of progress in tokenizing primitives in an effort to make them readily available to every platform our product supports.
Since the product team was stretched a bit too thin, engineering was always slightly behind design when it came to implementation mostly due to the fact that Jack wasn’t afforded as much time as I had to build this out. This was perhaps one of the tradeoffs I was most reluctant to accept.
I took it as an opportunity to get the design-engineering pipeline to a healthier state so that the spec that an engineer is building from, is using components and primitives from the same source of truth which designers would be pulling from.
I didn't want to make any presumptions around how components should be organized, given that looking up something is part of the workflow around adoption. There was also the age old problem of referring to the same component in ten different ways.
Is it a modal? An overlay? A takeover? We needed to speak the same language.
Since there were a couple of remote participants, I hosted the workshop on Figma. We paired up, picked a player journey and categorized every component we saw. Once we were done, we named the component and wrote down what we thought its purpose was. Unsurprisingly, that latter part fuelled some heated debate.
A bi-product of this workshop was that both designers and engineers who participated felt a greater sense of ownership since they had named and even rationalised why a specific component exists. There were even points in which people discussed merging or deprecating single purpose components.
Before I started building the kit, the rest of the designers and I agreed upon a structure that loosely followed atomic design barring the granularity, so that we can preserve context for individual components.
We had Primitives which were the look and feel and Components which were the lego blocks of the interface.
I spent a lot of time thinking about how I can best organize every page and file within Figma, to enable anyone to confidently navigate the contents.
In the Primitives file you can find everything you'd expect to theme an interface with usage guidelines around Color, Typography, Iconography and Layout. I also included two seperate pages called Assets and Content Samples which were aids that helped our mocks use actual data.
Perhaps, one of the most difficult things besides actually building this kit, was doing so in the middle of a rebrand. Consolidating both existing and incoming styling proposals which saw the color palette completely change, proved to be challenging.
What the rebrand did help us do however, was address some longstanding issues, such as reconfiguring our palette to meet accessibility standards, having more meaningful categorization within our icon suite or understanding multi-language implications on text length, to name a few.
The change in palette gave us the space to think about a more usable color system that didn't have arbitrary hue or lightness deviations which made it confusing to know when or how to use a color.
Thanks to Lyft's incredibly useful tool, called ColorBox we were able to generate a spectrum of functionally transformed colors for our product palette. As a result we collectively pruned the set to just 21 colors.
Since there's a tendency to gloss over written documentation, I included guidelines such as dos and don'ts for each Primitive category to describe why and how certain visual design decisions were taken.
So now, all the unspoken rules around things like how to gracefully add an icon that respected the entire suite or how to use color in the right context can be challenged, since the underlying rationale was exposed.
As for components, besides finding a way to gracefully theme everything using the new palette we were also having to work backwards and add new core components to be used in a newer version of the product.
Whilst drawing the components was mostly grunt work, there was still a workflow I followed for each component group which looked something like this:
Whilst this may seem prescriptive, knowledge of the workflow certainly helped in bringing people in at different stages of building a component which might have had an impact on their respective work stream.
We had our work cut out for us when we came across components that were intended to work on mobile but never gracefully scaled to a larger viewport. To solve this, we followed platform conventions to ensure a seamless experience across devices.
To break the start-stop cycle, I maintained an active role in designing processes, gauging adoption through surveys along with Figma's handy library analytics and responding to emerging needs.
From a frontend perspective, Jack also adopted a similar role where he onboard other engineers onto using and contribute to early versions of the component library.
Admittedly we were slightly behind on component documentation which I had traded off on at the start for the sake of velocity, which now looking back, should have been part and parcel of the deliverable.
I'm currently in the process of writing component documentation that describes different examples and details concise usage guidelines that doesn't drown engineers or designers with too much information.
As adoption grew, so did the amount of Slack DMs and threads. All the unspoken system rules around how new components were introduced, how existing ones were extended or retired and who was responsible for what, needed to be more transparent.
So to make sure I wasn't blocking teams, I drafted a few process documents which I'm planning on turning into more visual flow charts because let's be real, very few people like reading documentation.
This was the first step in taking CUDL from being just a visual scrapbook of elements to a 'How To' Field guide on how to build Casumo products.
Since introducing both the Primitives and Component libraries, there's been a positive response from both design and engineering teams.
I've been hesitant to call this a design system since we still have some ways to go before we close in on the fabled one-to-one parity from code to canvas.
The goal however, isn't just parity, it's productivity and problem focus.
The next steps are to have a v1 of the component documentation which will live in a microsite, continue driving adoption, help engineering get to the same readiness state as design and keep tending to different needs from the product design teams.
I'd be lying if I didn't say that at some points this project felt like it was on its last legs. Looking back, I should have broken the work down into smaller manageable releases, which would have tamed the scope of the rollout and helped early adopters to look past the scrappiness.
Despite these shortcomings, there's still some valuable lessons I picked up along the way which I'll be referring to when building and maintaining design systems: