Schoox: Finding the pattern behind the interface

Sometimes designing the component was the easy part. Finding which version was real wasn’t.

THE CHALLENGE

When I joined Schoox, the team was already modernising a large legacy interface through Sigma ~ a newer generation of design-system components gradually being introduced across the platform. The challenge was not starting a system from scratch. It was understanding how an established one actually behaved across design, code and production before adding more decisions to it.

That transition meant the same pattern could exist in several realities: legacy UI in the product, its newer Sigma definition in Figma, its Chameleon implementation in code, and varying levels of adoption in the live product.

Three things made the system harder to reason about

01 · Fragmented sources of truth

A component could be current in Figma but unavailable in Chameleon, or implemented in code but adopted in only a small part of the product.

02 · Historical complexity inside components

Variants, properties and exceptions often mixed genuine product requirements with decisions accumulated over years of product evolution.

03 · Knowledge spread across people and artefacts

Documentation, implementation and team knowledge did not always line up. Finding the right answer could require tracing the same pattern across several people and places.

SYSTEM DECISION 1/3 ~ Map the gap before designing into it

Working with a frontend engineer, I reviewed components across Sigma, Chameleon and the live product. I turned that into a working component inventory showing what existed, what had been implemented, what was still legacy and where adoption was incomplete. Combined with Figma usage data, it separated components that merely existed from patterns people were actually using.

SYSTEM DECISION 2/3 ~ Turn a local UI problem into a reusable pattern

A brief to refresh a learner-progress sidebar initially looked like a small UI task: six metrics in a dense space. But the same sidebar hosted progress, announcements, games, news and other content throughout the platform. Instead of optimising one widget, I explored a container-based hierarchy that could organise different kinds of supporting information. The pattern was adopted into Sigma and developed further by the Design System owner as the reusable component; the Summary Card.

SYSTEM DECISION 3/3 ~ Make complexity justify itself

As I worked on buttons, icon buttons, tags, list-view items and other components, I started separating genuine requirements from historical inconsistency. Instead of asking how many configurations a component could support, I looked for the smallest set it actually needed. Sometimes a new variant was justified. Sometimes an existing property already covered the use case. And sometimes the best system decision was not adding anything at all.

OUTCOME & REFLECTION

The visible output of design-system work is usually the component. The less visible work is comparing design with production, checking implementation, questioning exceptions, documenting decisions and coordinating with the people who build and use the system.

The strongest outcome was not a single screen. It was a clearer way of reasoning about the relationship between Sigma, Chameleon and production ~ and recognising when a local product problem could become a reusable system pattern.

What I learned

Good design systems do not remove complexity. They decide where complexity belongs. Finding consistency often starts with finding clarity first.

The work nobody notices is often the work that keeps the system understandable.