Izzi Design System
One design system, three Izzi products, two very different visual languages.
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.
Izzi brought us in to lead product design across the suite. Three products were growing in parallel with no shared design language and no shared library. The brief was to connect them. Over the next two and a half years we built the system that did, and shaped the working practices of the small design team around it.
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 made 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 one on the team could explain the whole picture anymore, and the documentation that existed 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. Breakpoints were inconsistent across modules, and layouts broke the moment a screen size changed. A button needed a new variant for every state, size, and 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, and 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.
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.
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.
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, type scale, spacing primitives, and the same patterns for how components were structured. The components diverged. The system underneath stayed shared.
04 DECISIONS
Two calls that shaped how the system landed
Most of the design work was technical. These two decisions weren't. They were about priorities and risk, and they're the ones worth showing the reasoning behind.
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 WE CHOSE
Tokens first. Three weeks of work with nothing demo-able at the end. Every product library that followed inherited the same primitives, so a single token change rippled across the suite. Building the first library on hand-tuned values would have cost more to untangle later 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 many 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 the products up behind it, ship coherence. The harder route was to 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 WE CHOSE
Let them diverge on the surface, share the foundation underneath. Same colour ramps, type scale, spacing primitives, and motion. Same patterns for building components. 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 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 it underneath the skin regardless of how different the skin looks.
05 OUTCOME
What shipped
All three Izzi products run on the same design system. Each keeps its own component library, all 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 contrast, Bookshelf and Playground, look nothing alike on the surface but are bound by the same root. None of that was true at the start.
One lesson carried forward: put the 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 happen, rather than once the system is stable, saves weeks of pattern-matching as the system takes 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.
- 1
- shared foundationOne token source of colour, type, spacing, and motion feeding three separate product libraries.
- 2.5y
- from audit to shippedFrom the first file audit to the system running across all three products.
