Theme token layer
Brand values, seasonal overrides and component tokens resolved in a fixed order, so a campaign can restyle everything without touching a component.
- brand/surface
- season/accent
- card/bg
- card/border
Design SystemsGrove
A retail design system that survives a seasonal rebrand
Four brands, one codebase, and a merchandising team that changes the look of everything twice a year.
- Design system
- Tokens
- Theming
- Client
- Grove
- Discipline
- Design Systems
- Engagement
- Design system and tokens
- Platforms
- Web and email
- Duration
- 13 weeks
- Delivered
- 2023
01The problem
What we walked into
Grove operates four retail brands on one commerce platform. Each brand has its own typography, colour and tone, and merchandising reskins all four twice a year for seasonal campaigns.
Every reskin was a three-week engineering project involving hand-editing stylesheets across four brand folders, because theming had been implemented as four near-duplicate copies of the same CSS. Campaign deadlines were routinely missed by the theme rather than the content.
The email templates were worse: a separate set of hand-maintained files that had drifted so far from the site that customers regularly reported the emails looked like a different company.
02Goals
What the work had to achieve
Agreed in the first fortnight, written down, and used to settle every argument afterwards.
- G01
One codebase, four themes
Brand differences must live entirely in token values. No brand-specific components, no forked stylesheets.
- G02
A seasonal reskin in a day
Merchandising should be able to change the campaign look by editing values, not by opening an engineering ticket.
- G03
Email inside the system
The same tokens have to produce email-safe output, so site and inbox cannot drift apart again.
- G04
Contrast guaranteed, not hoped for
With four themes and seasonal overrides, accessibility cannot depend on someone remembering to check.
03UI approach
The decisions that shaped the interface
Four moves that did most of the work. Everything else on the project followed from them.
- 01
Theming as a token layer
Components reference semantic tokens only. Each brand is a set of values, each season an override on top of it, and swapping either is a data change rather than a code change.
- 02
A theme editor for merchandising
We designed an internal interface where the merchandising team sets campaign values, previews them across twelve key templates, and publishes without engineering involvement.
- 03
Contrast checked at build
Every token pair that can appear together is validated against WCAG AA when the theme is built. A failing pair blocks the publish and names the two tokens involved.
- 04
Email as a build target
The same token source produces an inlined, table-safe email stylesheet, so a brand change reaches the inbox in the same release as the site.
04Components and design system
What got built underneath
The reusable parts, and the tokens they were built from. This is the layer that keeps the interface consistent after we leave.
Product card
One card handling six merchandising configurations, from plain product through to badge, swatch row, countdown and sold-out overlay.
- card/media-ratio
- badge/sale
- swatch/size
- overlay/sold-out
Email component set
Nine table-safe blocks generated from the same tokens as the site, tested across fourteen mail clients including the difficult ones.
- email/container
- email/button
- email/rule
05Outcomes
What changed after release
Measured by the client, on their own reporting, over the period noted against each figure.
- Seasonal reskin time
- 3wk → 1dSeasonal reskin timeMerchandising now publishes campaign themes without engineering.
- Stylesheet codebases
- 4 → 1Stylesheet codebasesFour near-duplicate brand folders collapsed into one themed source.
- Contrast failures shipped
- 0Contrast failures shippedFailing token pairs block the theme publish and name themselves.
- Mail clients verified
- 14Mail clients verifiedEmail now built from the same tokens as the site.
The first campaign after launch went live four days early. The merchandising lead had built the theme herself while waiting for a meeting.
06Gallery
Screens and system, laid out
Layout diagrams of the interface as delivered, with a note on what each one is doing.
- 01 / 04
Token resolution
Brand values, seasonal overrides and component tokens resolved in a fixed order.
Interface layout diagram from the Grove project.
- 02 / 04
Theme editor
The internal tool where merchandising sets campaign values and previews twelve templates before publishing.
Interface layout diagram from the Grove project.
- 03 / 04
Product card configurations
One component covering six merchandising setups, from plain product to sold-out overlay.
Interface layout diagram from the Grove project.
- 04 / 04
Four brands, one component
The same card rendered under each brand theme with no component-level differences.
Interface layout diagram from the Grove project.
07Take it with you
The one-page version
Everything above, condensed to plain text. Copy it into a brief, or download it to circulate internally.
Case study summary
Plain text, ready to paste into a brief or a board pack. Saves as baseline-studio-grove-commerce-system-summary.txt.
BASELINE STUDIO / CASE STUDY SUMMARY
================================================================
Client: Grove
Project: A retail design system that survives a seasonal rebrand
Discipline: Design Systems
Engagement: Design system and tokens
Platforms: Web and email
Duration: 13 weeks
Year: 2023
OVERVIEW
================================================================
Grove runs four retail brands on one commerce platform, reskinned seasonally by merchandising. Theming had been implemented as four near-duplicate stylesheets, making every reskin a three-week engineering project, and email templates had drifted into looking like a different company.
We rebuilt theming as a token layer with brand values, seasonal overrides and component tokens resolved in a fixed order, designed an internal theme editor so merchandising can preview and publish campaigns without engineering, added build-time WCAG AA contrast validation that blocks failing publishes, and made email a build target of the same token source.
Delivered across 13 weeks: a themed token architecture with four brand sets, a theme editor interface, 31 components including a six-configuration product card, nine table-safe email blocks tested across fourteen clients, and contrast validation wired into the build.
Results: seasonal reskin time down from three weeks to one day, four stylesheet codebases collapsed into one, zero contrast failures shipped since launch, and email rebuilt from the same tokens as the site.
OUTCOMES
================================================================
3wk → 1d Seasonal reskin time
Merchandising now publishes campaign themes without engineering.
4 → 1 Stylesheet codebases
Four near-duplicate brand folders collapsed into one themed source.
0 Contrast failures shipped
Failing token pairs block the theme publish and name themselves.
14 Mail clients verified
Email now built from the same tokens as the site.
CONTACT
================================================================
Baseline Studio
studio@baseline.design
+1 (415) 555 0142
Figures describe a specific product, team and period, and are
published to explain the work rather than to predict a result.05Start a project
Working on something similar?
Tell us where your product is getting stuck. We will tell you honestly whether this is the kind of problem we are good at, and what we think it would take.
- Prefer email
- studio@baseline.design
- Current availability
- Taking on two engagements for the coming quarter.
- Typical reply time
- Two working days, from a partner rather than a form.
