Building playful entertainment experiences at scale

2019 - Ongoing

This is a preview of the case study


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.


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:

  1. 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.
  2. 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.
  3. 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.
  4. In, short, there was a lot of housekeeping to do.


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.

These are a few images showing the different workshops and meetings I had with different members of the product team
Some of the workshops, meetings and 'convinceathons' that I hosted with different disciplines, where I refined the pitch and addressed the shortcomings the existing library had in a product designer's workflow

I needed to reframe the problem into something non-designers cared more about which was:

  1. Impacting the velocity at which we ship product updates due to the siloed workflows of both the engineering and design disciplines
  2. 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.
  3. 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.

This is a spreadsheet I created which collated 57 unique components
This was the inventory spreadsheet that grouped around 57 unique components across key product flows

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.

These are just a few slides from a roadmap meeting I had with a few key stakeholders within the product team
Excerpts from the slide deck I created to pitch the project and keep it on track

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
These are just a few slides from a roadmap meeting I had with a few key stakeholders within the product teamThe CUDL tool stack

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


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.

The images show a couple of captures from a slide deck which explained the team model at the start of the project
Excerpts from a slide deck explaining the team model and how we were going to start off with a mix between solitary and a centralized model and evolve to a federated one

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.

A few images of various meetings and component discussions we had over the course of the project
These are images taken at different points in the work around CUDL including component discussions, a naming convention workshop that I hosted with the native team amongst the attendees and a tree structure I had adopted to organize components and also help others follow a format when contributing where possible.

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.

He tokenized the Primitives library by fetching values from Figma for typography, color, spacing and other styles that can be described by a value. There was also a live sandbox environment he setup where anyone could explore component properties and see their extendibility.

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.


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.

These are just a few slides from a roadmap meeting I had with a few key stakeholders within the product team
This was a screenshot from the naming workshop which happened in Figma. The workshop itself was scrappy but it was also a first pass at trying to name components in a unique but recognizable and semantic way. It also served as evidence that we needed to invest in a shared language to remove any guesswork.

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.


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.

A preview of some of the pages within our Primitives file, which informed how we themed the interface
A preview of the Color and Typography pages, which define the color spectrum and type scale respectively. Both also come with a dos and don'ts section which was meant to serve as a brief usage guidelines.

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.

A preview of some of the pages within our Primitives file, which informed how we themed the interface
A preview of the Iconography and Layout pages, which contain the entire icon suite and the spatial system respectively. For iconography, I included guidelines for drawing up new icons whereas in Layout I defined things like layering logic and use cases for elevation.

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.

A preview of the work done for accessibility and line length testing for different languages
A small preview of the work done for accessibility and line length testing for different languages.

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.

A preview of the work done in pruning our color library from 63 unique colors down to 21
Pruning our color set from 63 different colors to 21 multi-purpose colors that fulfils different categories of intent ranging from text and button colors, to interface and support 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.

The image shows a quick preview of the Dos and Don'ts guidelines I'd written for different Primitive categories
This is just a snippet of the dos and don'ts I had written for iconography and color usage.

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
An image of the tree structure that helped us organize components better
To make sure our components were organized in a predictable format, I drew out a tree structure for each component group using the names we had generated in our workshop
  • 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.
On the left is some of the Loom updates where I walked through the component library and gave milestone updates, and on the right are a few text snippets from how I'd reach out to the team on Slack
Loom and Slack were my tools of choice when it came to announcements, discussions, explain rationale or fast track 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.

A preview of different component groups. Every component was organized by general categories these being: Buttons, Cards, Inputs, Navigation, Lists, Controls, Overlays, Notifications, Feedback Indicators, Messaging, Tables and Specialty. There was also a Helpers category I added which included frequently used containers such as mobile browsers, third party views, utilities and platform-specific items.
A preview of different component groups. Every component was organized by general categories these being: Buttons, Cards, Inputs, Navigation, Lists, Controls, Overlays, Notifications, Feedback Indicators, Messaging, Tables and Specialty. There was also a Helpers category I added which included frequently used containers such as mobile browsers, third party views, utilities and platform-specific items.

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.


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.

An image showing component library analytics
Checking component usage through Figma's handy library analytics.

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.

An adoption survey I distributed amongst the product designers to measure day-to-day usage of CUDL

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.

All the governance and process documents that I had started to draft
A few of the process documents I started to draft to shed light on the unspoken rules around upkeep

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.


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.


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.

Building responsible & playful entertainment experiences at scale

This is a preview image for the case study