Go Back
DESIGN SYSTEM LEAD
Building playful entertainment experiences at scale
2019 - Ongoing
Role
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.
Outcome
Reusable primitives and component library drawn within Figma that has been fully adopted and is currently being gradually integrated in code.
Team
Design Team – Contributors
Jack Westbrook – Frontend
Myself – Design Systems Lead
Overview
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.
Problem
Starting with a retrospective
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:
- An inexistent single source of truth
There were only a couple of references product teams would confidently refer to. That was either a Storybook environment, or digging through consolidation efforts that hosted a mix of work in progress and production-grade components. - Adoption and education were treated as an event
I always assumed there was a deep-rooted resistance around adopting CUDL. I couldn't have been more wrong. People are trying to ship, and the last thing they need is a design system throwing a wrench into the works. - A lack of governance brought us back to square one
Whilst going rogue enabled velocity, it soon led to statments like "Why are there six different ways of showing a modal?". With no active maintainers, our source of truth started to become unreliable.
In, short, there was a lot of housekeeping to do.
Process
Getting buy-in
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:
- Impacting the velocity at which we ship product updates due to the siloed workflows of both the engineering and design disciplines
- Holding back execution quality which players were now noticing, since fragmentation compounded with bespoke solutions instead of component reuse and focusing directly on the wider problem space.
- Objectively (and empirically) hindering player experience as a bi-product of the above mentioned issues
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:
- A set of OKRs which was updated whenever achieved
- A visualised roadmap of where we were, and what needed to happen, coupled with a few stretch goals where informed by the broader product team's input
- Measurables to gauge progress which included things such as confidence in adoption (which was measured through adoption satisfaction surveys), component usage across Figma files and UI specific Jira tickets
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:
- Our Slack channel called #cudl
- Loom which I often used to record walkthroughs
- Jira where incoming work was made visible
- Onsite in-person discussions when necessary
Kickoff
Starting solo and finding allies
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.
Naming
Establishing a vocabulary
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.
SETUP
Drawing a kit
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:
- Add the component parent group (e.g Inputs) as a JIRA ticket and list all the related components (e.g Numberic fields)
- Organize the component group into a nested structure that loosely follows the BEM methodology which is element/variant/modifier or in our case component/variant/state
- Build the component(s) in its respective page whilst making sure to:
- Use the Primitives
- Give it a descriptive name if it doesn’t have one
- Define the different states and variants
- Test the component by exhausting different types of content and trying it out at different constraints
- Communicate outwardly on the #cudl Slack channel, default to recording video walkthroughs instead of writing long paragraphs to show extensibility and keep advocating for component group to push for widespread adoption.
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.
Adoption
Driving Deliberate Adoption
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.
Results
How it's gone so far
Since introducing both the Primitives and Component libraries, there's been a positive response from both design and engineering teams.
- Better time/cost savings with far less 'visual nudging' tickets sitting in the backlog
- Almost full adoption of both libraries with some components needing revision due to product updates
- Newfound proactiveness from engineers to find opportunities for component reuse when translating spec to code, and avoid bespoke style logic
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.
Takeaways
What I've learnt
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:
- Collaboration is the first step towards adoption
Pairing with engineers and designers through component discussions, reviews, small workshops or even 'build-alongs' (where an engineer literally sits with a designer and quickly prototypes a complex component to get a sense of some of its properties and states ) can't be understated. It isn't just a way to plant a sense of ownership, it makes adoption flow so much better down the line. - Be flexible not fixed in approach
Taking up the role of enforcer is necessary sometimes, but overpolicing might actually drive people away. Instead the system should be built to embrace the nuances of a company's culture, acknowledging that there'll be some tradeoffs along the way. - Focus on people not patterns
Politicking, sponsorship, promotion and a host of other interpersonal competencies were far more important in not just closing the engineering and design gap, but also helping people build better products by default.
