Starting a design system at Learnosity
Gaining buy-in and collaboratively building the foundations of a design system
At Learnosity, a white-labeled assessment API platform serving 14.8 million monthly users, I led a two-year initiative to establish the foundations of a design system that would address our legacy codebase’s inconsistent interfaces and inefficient development workflow.
Project Overview
For more than ten years, Learnosity had been operating as a successful, development led organization. Over time, the codebase had accumulated a lot unchanged legacy code and inconsistencies emerged within the product interfaces and interactions. The result of this had a measurable impact on the product development workflow aswell as the end user experience.
Our initial audits highlighted a range of business challenges. Primarily we noticed an impact on efficiency which led to a lower quality experience for our users. We also needed to address the frustrations arising for designers and engineers who were working on the product.
Over two years, along with other existing priorities, the project went from an idea, then a concerted effort to get buy-in to having the core foundations and components being used in production.
My Role
My role as the lead designer for this project included:
- Gathering the research, proposing scope
- Building a business case including proposed phases with tasks and a timeline
- Fostering motivation for the duration of the project (glue work)
- Jumping into Figma to work on the component designs
Throughout the project I was also able to help other designers and developers contribute to the system.
Developing a business case for a design system
When I started at Learnosity, the first thing I did when I landed was try and get a lay of the land. How should I set up my design files? Is there a naming convention? Are there component standards I should follow? What is the product color palette? What are the processes for delivering my work and collaborating with development?
A lot of these processes and guidelines were yet to be created. Missing these crucial pieces of information caused inefficiencies in many areas of the product development process. Long back and forths on slack about what blue a button should be, working on a modal and not knowing what the pattern for the button placement should be, designers trying to rely on what exists and engineers having to recreate components for very similar designs.
These decisions were all related and if our team wanted to focus on the hard problems, we needed to make, document, and share these design decisions. The way to solve this problem was by having some form of design system.
There had been a few false starts at getting a style library created. To get buy-in from leadership I needed to be able to communicate why it should be prioritized and get on the road map. In that process I could also gauge the interest of the wider org, especially product people and engineers.
Next step… talk to people!
The Approach
It was key to understand what problems the system would be solving and to identify the internal stakeholders who would need to support the initiative. I designed a discussion guide to capture their knowledge around design systems, their expectation of the benefits, and what they see as the risks and challenges. I also wanted to fully understand their definition of what success looked like.
I also wanted to understand what the system’s user needs were going to look like. Initially I designed a short, company-wide survey to gauge interest. After that a more in-depth developer survey was sent to developers where they could share their knowledge or questions around design systems, what issues they were having, and what would help them in their day-to-day work.
From the long survey there were clear patterns in the frustrations developers faced. The perceived benefits that emerged added strength to the case I was building.
Building Consensus
Through facilitated workshops with cross-functional teams, I gathered input and built consensus around the need for a design system. These collaborative sessions were crucial for gaining buy-in across the organization.
Lastly, I organized short, collaborative workshops (customized version of Product, Parts, People by Nathan Curtis), with a representative from each user group including product managers, support staff, and even some remote participants!
The workshops gathered people who rarely worked together and created space for questions and conversations that could be compiled into a project outline.
The insights gained were presented to key stakeholders and received great feedback – engaging more colleagues than expected who had heard about the proposal. With an energized product managers support, the design system project was formalized and included in a product teams road map.
Audit and Foundations
For the business case I showed stakeholders examples of our current state through a lightweight audit of the product colors and a few components, including buttons.
The color audit showed us the extent at which we were declaring color variables in the code bases for colors that were visually indistinct. We were able to merge these down and improve our color contrast for accessibility. Across the codebases we were able to get from 375 colors down to a core palette of 30 colors with clear uses for each.
After the colors we focussed on auditing and defining our core foundations, typography, icons, and spacing, always learning a bit more about how and why we used each foundation in the products.
Implementation and Integration
Working closely with development teams, I integrated the design system foundations across our existing products. This involved creating documentation, establishing processes, and training teams on the new standards.
Impact
- Reduced color palette from 375 to 30 colors
- Improved color contrast and accessibility compliance
- Established reusable components and documenration
- Improved development workflow across product teams
- Created foundations of a shared design language between design and engineering
Learnings and reflections
Working on this project gave me an in-depth look at how design systems can work and how it is possible to get one started with a collaborative team and by engaging stakeholders early on.
I learned a lot about process development and file management, setting up and using Figma for our systems design files, and working with developers to define and build tools that will be used by us both—such as design tokens and our Storybook component library.
On top of the amazing insights from my colleagues, I was also able to leverage the excellent resources available online such as Nathan Curtis Eight Shapes articles and other design systems leading the way.
