System Backbone, Components
Vodafone
I.
WS10 supports more than twenty markets.
Over time, Card accumulated parallel versions, local interpretations, and inherited structures.
The aim is a unified internal model: clear to read, flexible to configure, and stable across products and markets.
II.
Landscape
The component existed in more than fifty versions. Structural regions appeared in different orders depending on the library.
Certain implementations exposed properties that others kept internal.
Naming diverged over time, and several markets maintained their own interpretations of the component’s structure.
III.
Decisions
— Define a fixed hierarchy for all structural regions, ensuring a consistent order across every configuration.
— Align the layer tree with the expected HTML structure: container, div, span and list elements placed according to function.
— Replace variant-driven growth with a slot-based model that scales without creating new components.
— Establish naming and property order for the entire system so design files and codebases describe the same structure.
— Remove non-essential layers to keep the component focused on its core model.
— Frame the component as part of a system: one structure recognised across journeys, not tailored to isolated screens.
IV.
Model
The work focused on two axes:
the component API exposed to designers, and the internal structure (slots and layers) that bridges design and engineering.
Each property answers a specific question: what should be configurable, and how can that logic be exposed clearly and safely.
— Properties are grouped by function and hierarchy, not by panel order.
This makes the model readable, not just editable.
— Subcomponents use fixed naming: Container, Text, Image, Actions.
The same names carry through documentation, inspection, and handoff.
— Behavioural props (description, metadata, actions) are conditional.
They appear only when the slot exists.
— Surface and State are scoped to the container.
They apply where semantic meaning lives.
— Layout defines orientation (vertical, horizontal, overlay).
It controls slot distribution without creating new variants.
The result is a clear contract between structure and tooling — a decision model, not a list of toggles.
Each component follows a shared internal rhythm—layers named by purpose, ordered by logic, grouped by function.
— A fixed hierarchy is defined for all structural regions: container, media, text blocks, actions. This order remains consistent across every variation.
— Layer names reflect their semantic function, not their appearance.
— Layers are grouped to reflect ⌥ HTML structure. This ensures a predictable mental model when jumping from design to implementation.
— Decorative or marketing-only slots are excluded from the core layer stack. The card remains focused on its role as a system unit, not a visual playground.
— No additional ◇ variants are created for spacing or layout shifts: slot positioning follows predictable constraints, avoiding overrides or duplication.
V.
Refinements
The Card structure became the model for renaming layers, reducing duplicated tokens and aligning slot logic across the system.
This clarity made components more legible — to engineers, to designers, and to accessibility tooling.
Not a redesign — a redefinition.
The work wasn’t loud.
But it changed how the system thinks.
VI.
Reach
Naming, props and slot logic became shared language — reducing friction between design and engineering, across teams and countries.
No extra variants. No duplicated decisions.
Just a system that travels well.
VII.
Form
The documentation mirrors the architecture of the component itself — not just what it shows, but how it thinks.
A.
Usage
Outlines the component’s core behaviour: interaction, composition, do’s and don’ts. Every example highlights system logic, not screen design.
B.
Overview
A single place to track configuration: variants, tokens, and implementation notes. Props, states and slots are grouped by function — not by tab, theme, or team.
Each component includes semantic roles, keyboard behaviours and screen reader expectations. Structure is explained in terms of how it’s read, not just how it’s built.
D.
Tokens are defined by function and rhythm. Examples clarify which transitions apply — and when. Motion is not a decoration, but part of the system’s tone.
VIII.
Notes
This piece aligned structure, naming, and accessibility into a shared mental model.
It reduced friction across teams, simplified adoption in 24 markets, and reshaped how contributors understand components inside the system.