Izzi Design System

One design system, three izzi products, two very different visual languages.

ROLE: Product Design Lead
COMPANY: Izzi Digital
TIMELINE: Mar 2022 – Nov 2024
PLATFORMS: Web · SuiteWeb · Multi-product Suite

01 Context

An ed-tech suite with no shared backbone.

Izzi is the digital learning suite from Profil Klett, one of the largest educational publishers in the region. Three products sit under it. Bookshelf is the structured reading and learning environment for grades 5 and up. Playground is the hand-illustrated, interactive version for grades 1 through 4. Authoring is the tool the editorial teams use to produce the content behind both.

I was brought in as lead product designer for the suite. Three products growing in parallel, no shared design language, no shared library. That was the brief: connect them. Over the next two and a half years I built the system that did, and grew, mentored, and led the small design team that supported the work.

02 Problem

The system everyone needed, that no one had time to build.

Design systems get built in the gaps between product work. Izzi didn't have those gaps anymore. Three products were shipping in parallel, and three pressures were making the gap-less approach untenable.

Files outpacing their owners.
Multi-year accumulation across rotating designers and external agencies. Styleguides got started and abandoned. Components got duplicated faster than anyone could deduplicate. No single person on the team could explain the whole picture anymore, and the documentation that did exist had been written for a version of the product that no longer shipped.
Components that didn’t flex.
Most components had no auto-layout, no properties, no responsive behaviour applied. Breakpoints were inconsistent across product modules, and layout would break the moment a screen size changed. A button needed a new variant for every state, every size, every product. That made every change a project.
Two products drifting apart with nothing connecting them.
Bookshelf and Playground served similar functions for different age groups, but their visual languages had drifted in opposite directions. Bookshelf had gone clean, minimal, and universal. Playground had gone hand-illustrated, custom, and interactive. The contrast was a strength, but with no shared spine underneath, every component was being built twice.

03 Work

From chaos to a system that bent without breaking.

The work moved through four stages: audit, foundation, components, divergence. The audit named what existed. The foundation and libraries gave the system a structure. Each product's components got rebuilt to flex on top of it. The divergence let Bookshelf and Playground stay themselves without forking the foundation. Not parallel passes. A sequence.

Stage 01

Mapping what existed.

The first stretch wasn't designing. It was untangling. Auditing every product file, every abandoned styleguide, every component that called itself a master. Buttons defined four ways. Search bars defined three. Three different ramps for the same brand colour, all named 'Primary' across three files. The audit produced a single document describing the surface area of the suite, including everything that had to go.

Audit of duplicated components and overlapping colour ramps across product files

Same component, defined three times. Same colour, defined three times. The audit cataloged it all.

Stage 02

One foundation, three product libraries.

Three weeks pouring global tokens into a single file: colour, type, spacing, effects, motion. From that one source, three product libraries branched off. Bookshelf, Playground, and Authoring each inherit the same primitives but layer their own product-specific patterns on top. A token change at the root propagates to all three. LEGO sets with shared studs, built for different things.

Global tokens at the root, three product libraries inheriting downstream

Global tokens at the source, three product libraries inheriting downstream.

Stage 03

Components built to flex.

Once the chaos was named, the components got rebuilt. Each product's library got its own set, all built with the same techniques: auto-layout, constraints, slots, instance swap, and property models deep enough that within a product, a single base component could absorb every state, size, theme, and role that product needed. Without that depth, the system would have been a styleguide with a token sheet. With it, designers could actually build.

Bookshelf's Primary Brand and Unit Tile components, with their property panels exposed.

Stage 04

Same foundation, two very different visual languages.

Bookshelf serves grades 5 and up. Playground serves grades 1 through 4. Same underlying functions, dramatically different surfaces. Bookshelf is clean, minimal, and universal in feel. Playground is hand-illustrated, custom, and built for interaction at every turn. Each product got its own component library. Bookshelf's primary button and Playground's primary button are different components, not variants of the same one. What they shared was the foundation underneath: the same colour ramps, the same type scale, the same spacing primitives, and the same patterns for how components were structured. The components diverged. The system underneath stayed shared.

Bookshelf and Playground side by side — different components, same tokens

Bookshelf (left) and Playground (right). Different components per product, same tokens and patterns underneath.

04 Decisions

Two calls that shaped how the system landed.

Most of the design work was technical. These two decisions were not. They were about priorities and risk, and they're the ones I'd argue about with a peer if asked to defend them.

Call 01

Pour the foundation before building any of the libraries.

The visible-progress route was building one product library first. Pick Bookshelf, ship a quick win, demo it, let stakeholders see the system arriving. The slower route was three weeks on global tokens before a single product library got built. Same end state, very different shape of the first month.

What I chose

Tokens first. Three weeks of work with nothing demo-able at the end. Every product library that followed inherited the same primitives, which meant a single token change rippled across the suite. If I’d built the first library on hand-tuned values, untangling it later would have cost more than the demo was worth.

Trade-off

Three weeks looking unproductive from outside the design team. No product output, just a growing tokens file. Worth defending. Every week saved later on a colour rename or scale tweak paid that loan back ten times over.

Call 02

Let Bookshelf and Playground stay visually opposite, and bind them at the foundation.

The natural temptation with a design system is to homogenize. Pick a visual direction, line up the products behind it, ship coherence. The alternative was the harder route: let Bookshelf stay clean and minimal, let Playground stay hand-illustrated and playful, and force the consistency to live underneath where the user couldn’t see it.

What I chose

Let them diverge on the surface, share the foundation underneath. Same colour ramps, type scale, spacing primitives, motion. Same patterns for building components: auto-layout, slots, properties, instance swap. But each product’s actual components stayed its own. Bookshelf’s primary button is a different file from Playground’s, and that separation is what let each product stay itself.

Trade-off

Harder to defend at first glance. Stakeholders looking for visible coherence don’t see it. Worth it because the actual point of the system isn’t visual coherence. It’s token reuse across products, component reuse within each product, and predictable maintenance everywhere. All of that happens underneath the skin, regardless of how different the skin looks.

05 Outcome

What shipped, and what I'd do differently.

All three izzi products run on the same design system. Each keeps its own component library, all of them built on the same patterns and pulling from the same primitives. Designers and frontend engineers reach for tokens by the same names across the whole suite. The two products with the most visible visual contrast, Bookshelf and Playground, look nothing alike on the surface but are bound by the same root. None of that was true when I joined.

If I were doing it again, I'd put more of the team's working conventions in writing earlier. Decisions made out loud in design reviews lived only in the heads of whoever was present. Writing them down as they happened, instead of after the system was stable, would have saved my team weeks of pattern-matching as the system took shape.

3: products on one systemBookshelf, Playground, and Authoring. Each with its own component library, all sharing a global token foundation.
30%: faster delivery, on averageOnce the libraries were in use, design-to-handoff time dropped by roughly a third on comparable feature work.
3: designers, built and ledGrew the design team from one to three, with shared standards, regular reviews, and a practice we built together.
2y 8mo: from audit to shippedFrom the first file audit (Mar 2022) to the system running across all three products (Nov 2024).

Let's Work Together

I'm always interested in hearing about new projects and opportunities. Whether you need a design partner, want to collaborate, or just want to say hi. I'd love to connect!

Email Me

Izzi Design System

An ed-tech suite with no shared backbone.

The system everyone needed, that no one had time to build.

Files outpacing their owners.

Components that didn’t flex.

Two products drifting apart with nothing connecting them.