Case Study: Building a Design System

Project Profile 💼

In a snapshot:

  • Time Winter 2021 – Summer 2021
  • Role UX Designer
  • Team 1 Lead UX designer, 1 product manager, partnered development teams
  • Location Remote

My main contributions:

  1. Build critical MVPs with product & tech
  2. Develop UX involvement in product planning
  3. Evolve WCAG 2.0-compliant atomic-based design system
  4. Research and explore new dashboard ideas to simplify administrative tasks

Introduction & Background 📖

The LaCalle Group’s Continued brand for its EdTech verticals was in need of a design system, with the anticipation of revamping its entire legacy platform to a more polished and modern SaaS app. With the majority of the platform having relied on CakePHP and jQuery, the proof-of-concept utilized a combination of Vue.js with Vuetify and Nuxt.

The Challenge 🧗

To streamline every visual aspect of the application, the design needed to move out of the Photoshop/Illustrator design stack into Figma and InVision. What’s more, the design system wasn’t only going to be visual face lift with a new UI kit but rather an overhaul to thinking into more modular terms — atomic design. We chose this direction to allow us to scale the design efforts of the application, while also allowing the development teams to have a lower technical lift to code all the new features.

The Requirements 📋

Since Continued’s EdTech offerings are within the education sector, everything had to comply to WCAG 2.0 standard, most notably meaning that the design system would account for people with visual deficiencies. Moreover, the move from regular design to atomic design meant thinking modular components rather than one-off designs. With the very definition atomic design being centered around creating atoms, molecules and organisms, the overarching goal was to adopt this thinking pattern for our frontend development team.

To ensure the WCAG 2.0 compliance was met, we used the Contrast plugin for Figma to test the contrast ratio on all of our elements. Furthermore, our Frontend team integrated accessibility testing within their CI/CD workflow.

The Process ✍️

Saying you’re “building a design system” doesn’t necessarily sound all too complicated. However, it’s quite the opposite in that you’re building everything backwards. That is, you can’t create all the required atoms for the system, until you’ve gotten a good grasp on what components you’ll need to build out the application. Likewise, once a component is designed, it doesn’t mean that it’s completed. In fact, here were the steps to produce just one atom:

  • Design the atom in Figma
  • Test its accessibility
  • Send over to Frontend Development via Jira
  • Test component (and its variations) in Storybook
  • Approve/Deny component via Chromatic prior to being merged into the repository
  • Repeat last three steps in case component needed further adjustments

To put that into perspective, we have about 50-60 components in our library with many of them having many variations.

Results 💪

With the implementation of our design system, we were able to increase our prototyping velocity by more than 40% and development velocity by 20%, while still keeping everything compliant and aesthetically consistent. In fact, by having lead the charge in creating this system, I was able to create dozens of high-fidelity prototypes with relative ease. Here are some examples:

Additional Notes 📝

The current system is designed with a custom themed version of Bootstrap, so for additional context, here’s a screenshot of what we’ve upgraded: