E-commerce · Design System
Handed off
·
2024
Role
Product Designer, UX/UI
Team
Design system team, 2 designers on templates
Timeline
H2 2024 – early 2025
Company
Grupo Soma
Signals
brands served by one white-label system
white-label templates built in 5 days
brands themed to validate the model
Competencies
Design Systems
Context
The company is a fashion group with an e-commerce operation spanning ten brands. A dedicated design system team already existed, but it worked project by project: build the system for one brand, hand it over, move on to the next.
My role
I took part in the whole process, from component mapping to brand theming. The 28 templates were built by me and one other designer.
Problem
Each brand got its own design system, and each one was treated as a one-off project instead of a product. Once handed over, a system had no dedicated owner, so it fell out of date quickly — to the point where the first brand’s system had to be rebuilt from scratch.
The fix was to change the model: the design system team keeps owning the system as a living product, and a single white-label system serves all ten brands.
Discovery
How might we
Solution
A white-label system, built in five steps:
1. Component mapping. Starting point for the white-label library.
2. Token definition. Foundations in two layers: Root, where each brand expresses itself, and Context, which translates those values to components.
3. Component building. Components split into Core, Team and Not in DS, and built in layers to keep variations down.
4. Templates and flows. 28 white-label templates built from the finished components in five days.
5. Brand theming. The system applied to two brands to validate the model before expanding.
Key decisions
Two token layers. Root holds each brand’s values and is never applied directly to components. Context translates Root to components with a strict naming standard defined up front, so every component absorbs a theme the same way across brands.
Three kinds of component. Core components share one structure and only change style. Team components are more complex and can change structure between brands, like the product card. Not in DS components belong to a single brand, so designers don’t feel creatively boxed in.
Layered components, to reduce variations and make maintenance easier.
Documentation per component: a short description, category, templates it appears in, components that depend on it, and an up-to-date changelog.
Three files per brand: Foundations, Components and Templates.
Validate on two brands before expanding to all ten.
Results
The structure was ready and being implemented on two of the ten brands for validation when I left the company in early 2025. I didn’t follow the outcome, so I can’t speak to adoption or time saved.
What’s next
Next I’d confirm how the two-brand validation went, track how the Context layer holds up as new brands join, and measure whether keeping a dedicated owner stops the system from going stale.
