Prodigy Education EdTech Design System Systems Thinking

Reimagining Prodigy's Backpack design system

Leading the reimagining of Prodigy's design system to improve consistency, speed to market, and scalability.

Role Lead Product Designer
Timeline 2024-2025
Team 5 Designers, 1 Engineer
Platform Web Application
Backpack design system overview

Click to expand

Prodigy Education is an EdTech company whose game-based learning platform reaches millions of students worldwide. As the product evolved and the team grew, the existing design system, Backpack, had become fragmented. Components were inconsistent across platforms, documentation was outdated, and designers and engineers were frequently rebuilding the same patterns from scratch.

When I joined the team, lack of buy in from senior stakeholders had stalled the redesign project. Alongside one brave Developer, I took on the role of leading and championing the redesign, shipping components strategically and transforming the system from a loose collection of broken components into a cohesive, well-documented system that could scale with the product and the team.

The redesign project faced a few fundamental challenges...

No stakeholder buy in

Feature work consistently won out over infrastructure investment, and previous efforts to prioritize the redesign had stalled.

Without dedicated resources or executive sponsorship, the project had no path forward.

Outdated source of truth

Components had diverged across web and mobile, with no single source of truth for design patterns.

Teams were creating one-off variations instead of reusing shared components and we had no reliable onboarding resource for design.

Slowed
velocity

Without a reliable system, design and development cycles were slower than they needed to be.

Designers and Developers wasted valuable time digging for components and repeating the same work over and over again.

Starting with a comprehensive audit

Before redesigning anything, I needed to understand what we were working with. I conducted a thorough audit of the existing Backpack system, cataloging every component across Figma libraries, the codebase, and the live product.

This audit revealed the full scope of inconsistency. Duplicate components with different behaviors, colour tokens that didn't match across platforms, inaccessible components, and variations in application of shadows, typography, and spacing values. It gave us a clear picture of where the gaps were and helped prioritize what to tackle first.

I used the audit to create a work list of everything that needed to be addressed. This allowed the design team to track the status of the project, priority of work, and identify what could be picked up next.

Design system audit findings

Click to expand

Scrappy approach to design system evolution

Instead of competing for roadmap space, I embedded design system progress directly into existing feature work. I partnered closely with a developer to identify moments where feature needs overlapped with gaps or areas for improvement in our design system. I then used those moments to create or refresh components and push them to Backpack as part of the feature work.

There were three key parts to this process that helped keep momentum high and avoid process overhead:

1
Feature-driven system evolution

Design system updates were embedded directly into feature work, avoiding roadmap competition and accelerating adoption.

2
Design-developer pairing

I collaborated closely with the developer to ensure components were practical to build, accessible by default, and scalable for both teams.

3
Continuous alignment & enablement

I implemented regular design system syncs to keep designers aligned, surface issues early, and ensure we were ready to ship updates when opportunities arose.

Rebuilding from the ground up

As the individual component work was ongoing, I focused on establishing a stronger foundation to support the new components. This meant reworking the core design tokens including colour, typography, spacing, and shadows to create a consistent visual language that worked across our products.

I worked closely with engineering to ensure tokens were structured in a way that mapped cleanly to code variables, reducing the translation gap between design files and implementation.

By establishing a shared token architecture between design and developers, we eliminated ambiguity and ensured that what designers built in Figma matched what engineers shipped in production.

Design token architecture and color system

Click to expand

Shadow implementation

Click to expand

Before Backpack redesign

Click to expand

After Backpack redesign

Click to expand

Designing a scalable component architecture

When it came to the library itself, creating simple to maintain components that were flexible and easy for component consumers to use was the key goal of the redesign.

I created a two tier system comprised of cogs like buttons and icons that could be fitted together to create a second tier of more complex components like menus and main navigation bars that would be used repeatedly in the product.

Keeping the components as clean as possible and avoiding over-engineering the library keeps the system maintainable and easy to build with.

Component architecture — primitives, composites, and patterns

Click to expand

Impact of the redesign

The redesigned Backpack system has already made a measurable impact on how the team works and what we ship.

Reduced design-to-dev handoff friction by establishing shared tokens and component specs that both designers and engineers reference

Improved cross-product consistency with a unified component library serving the teacher app, parent app, and marketing team

Increased system adoption across product teams through better documentation, contribution guidelines, and onboarding resources

Key learnings

What worked well

  • Collaboration with engineers from day one
  • Leveraging feature work to drive design system evolution
  • Treating documentation as a core deliverable

What I learned

  • Alignment between design and developers early saves significant rework
  • When used thoughtfully and strategically, scrappy workflows can be more effective than formal processes