Rebranding and Redesigning Quizizz

In a fixed three-month window, I led the end-to-end execution of Quizizz’s product rebrand across design, engineering, product, marketing, sales, and support. The launch happened during the US Back-to-School season with no phased rollout.

Design System coverage increased from roughly 27% to 95%, enabling a safe rollout at scale. A high-risk domain migration was executed in a single release, avoiding long-term SEO and operational risk.

Around 95 percent of the planned scope shipped on time, with the remainder intentionally de-scoped. The rebrand launched publicly at ISTE and rolled out across the product without major disruptions, resulting in stronger teacher sentiment and a Design System ready to scale forward.

The problem we were solving

Quizizz was widely seen as a fun, gamified quiz tool. That perception helped early adoption but increasingly worked against the product.

This gap showed up in enterprise credibility, sales conversations, and expansion opportunities. The rebrand was meant to correct understanding, not just change visuals.

Internally, Quizizz had grown into a full classroom platform with Lessons, Interactive Videos, Whiteboards, asynchronous assignments, accommodations, and admin workflows. Externally, that depth was not visible.

My role

I led the execution of the rebrand across all product surfaces, working closely with the leadership.

Product Rebrand (Milestone 1)

• Logo and visual identity updates

• Domain redirection and migration

• Updates to all user-facing and internal tools

Design System Transformation (Milestone 2)

• Modernizing the visual language

• Increasing DS coverage toward 100%

• Creating a scalable foundation beyond launch

Design principles for Design System

1. Teachers should not feel like they’re in a new product

The rebrand could not introduce new navigation, screen hierarchy, or flow changes, only Design System migration and essential hygiene fixes were allowed.

2. Design for scale beyond launch

Any change that didn’t materially improve Design System scalability or long-term maintainability was deprioritized, even if it improved launch visuals.

3. Marketing and product must share a system, not an expression

Marketing and product could diverge in visual expression, but both had to be grounded in the same underlying brand and Design System primitives.

Am I underestimating scope?

Such projects often fail due to hidden dependencies. To avoid a cold start, I partnered early with a senior engineer to answer foundational questions.

Instead of relying on documentation, Senior engineers created a test setup where Design System components were visually highlighted in the product. Teams could audit flows simply by looking, without reading code.

Ownership became clear, audits accelerated, and conversations moved from ambiguity to action. This unlocked execution across teams.

A strategic constraint that preserved velocity

Given the timeline, we chose not to rebuild the Design System.

Component structures and semantics remained intact, while a new visual theme modernized typography, color, and surface treatment. Core interactions stayed familiar to teachers.

This approach reduced engineering risk while still delivering a clear brand shift.

From alignment to execution

Once the approach was locked, Engineering Managers formed task forces to migrate the flows they owned. The Design System team finalized tokens and components in parallel, while product designers updated flows against the new system.

To maintain quality under speed, we enforced Figma and Storybook parity, conducted design QA directly in Storybook, and tracked progress through a shared execution dashboard with clear ownership.

At peak, the effort involved more than 150 engineers, 20 designers, 20 Product Managers, and close coordination with sales, marketing, support, and customer success.

Explorations on Design System

We decided to improve our foundational pallette while maintaining consistency with our new brand visuals. The approach was to refresh the UI by making it more modern.

This is how our existing product looked:

Exploration 1:

Exploration 2:

Final Version:

The highest-risk decision

The most consequential tradeoff was domain migration.

Running parallel domains would have eased short-term transition but introduced long-term operational and SEO risk. Immediate redirection enabled a single, clean launch but required schools to whitelist a new domain.

We chose immediate redirection and mitigated risk through proactive customer outreach, a public status page, and tight coordination with sales and support.

Outcome

About 95 percent of the planned scope shipped on time, with the remaining work intentionally de-scoped.

Design System coverage moved from roughly 27% to 95%. Figma and Storybook were brought into parity, developer confusion dropped, and the product felt more cohesive and modern.

The rebrand launched at ISTE (International Society for Technology in Education) and rolled out across the product without major disruptions.

Some images from the launch day!

Launch video of rebranding

My Learnings:

This project fundamentally reshaped how I approach design leadership. I learned that at scale, progress depends more on clarity than creativity. The most valuable work I did was not in Figma, but in making systems visible, setting constraints that teams could rally around, and making difficult calls early enough to avoid chaos later.

I also learned to separate ambition from responsibility. Choosing not to rebuild the Design System was a hard call, but it preserved momentum and trust. That balance between long-term quality and short-term execution is something I now approach with much more discipline.

To keep this case study focused, I’ve highlighted only the highest-impact decisions and outcomes. Many operational details, trade-offs, and learnings are intentionally left out. If you’d like to go deeper into any part of the work, I’d be happy to chat.