• Back

Smart

Building a design system for a growing, multi-brand platform

Design Lead - Product Design & Design System / Aug 2020 - Jan 2024

Smart was a different challenge from Vodafone. The business already understood the value of a Design System. The challenge was turning that ambition into a scalable design and technology platform that could support multiple products, brands, users and markets.When I joined, experiences were inconsistent, accessibility needed improvement, and teams were often solving the same problems independently.My role combined hands-on Product Design and Design System work with leadership of the platform — from foundations and implementation through to governance, adoption and ways of working.

The challenge

Smart grew from around 150 to 800 people during my time there.The platform needed to support three core experiences:Member · Adviser · EmployerIt also needed to support multiple brands and white-label partners, new products and markets, multiple languages and increasingly complex customer journeys.The existing platform wasn't designed for that scale.Teams were working independently. Design and Engineering didn't have a common language. New features were increasingly difficult to introduce consistently, and improvements made in one product weren't necessarily available to others.The symptoms looked like UI problems.The underlying challenge was creating a shared platform that could scale with the organisation.

Building the Design System

I approached the Design System as a product rather than a component library.I worked hands-on across the core foundations:- Design tokens
- Components
- Patterns
- Templates
- Accessibility
- Responsive behaviour
- DocumentationDesign and Engineering were deliberately brought together around the same language and source of truth.I worked closely with engineers to make sure the design principles translated into a robust implementation, while using the implementation itself to identify where the design system needed to evolve.The goal wasn't simply to create reusable UI.It was to create a shared design and technology foundation for product teams.

From components to experiences

As the system matured, I pushed the work beyond individual components.We identified recurring problems across products and turned them into reusable patterns for things like:- Multi-step journeys
- Dynamic forms
- Validation
- Content structures
- User flows
- Complex interactionsThis meant teams could reuse solutions to common experience problems rather than starting from scratch each time.It also changed how I thought about Design Systems.The valuable thing isn't the component. It's the capability it gives a team.

Applying the system to real products

The Design System wasn't an isolated library.I worked with product teams to apply it across Member, Adviser and Employer experiences.This created a continuous feedback loop:Product problem → design solution → reusable pattern → system improvement → faster product deliveryWorking on real journeys exposed gaps in the system much faster than designing components in isolation.It also ensured that the Design System evolved around genuine customer and business needs.

Designing for multiple brands

Smart needed to support different brands and white-label partners without creating completely separate products.I helped establish a theming approach based on:Shared functionalityShared componentsShared codeBrand expression through configurationThe underlying experience could remain consistent while the visual expression changed for different brands and partners.This became increasingly important as Smart expanded internationally.The principle was simple:Don't create a new Design System every time a new brand appears.Instead, build the platform so brand differences can be expressed through configuration.

Designing for what comes next

Scalability also meant anticipating requirements before they became one-off problems.For example, we built support for right-to-left languages into the platform rather than treating Arabic as an isolated request.We also integrated localisation into the workflow so content could evolve independently from interface design.The principle was:Don't solve today's exception. Improve the platform so the next team doesn't have the same problem.

Making Design and Engineering closer

A major part of my role was connecting Design and Engineering around the same system.Storybook became a shared reference point.Designers could understand how components were implemented, while engineers could understand design intent, behaviour and expected states.This reduced ambiguity between design and development and made the system less dependent on individual people knowing how everything worked.The Design System became a shared product between Design and Engineering, rather than something handed from one discipline to another.

Governance and adoption

As adoption grew, governance became increasingly important. But we didn't want it to become an approval process.I established regular working sessions bringing together Product Designers, Content, Engineers, Product Owners and subject-matter experts around real customer journeys.Alongside this, I established the roadmap, contribution model, onboarding, knowledge sharing and stakeholder alignment needed to support adoption.The goal was shared ownership rather than central control.

Measuring whether it worked

The real test wasn't the number of components in the library.It was whether teams could deliver better products with less duplication.The US team adopted the platform from the beginning and reported approximately 50% faster delivery, including design, compliance, stakeholder review, iteration and development time.That was more meaningful to me than the size of the component library.The Design System was becoming a product delivery accelerator.

My role

By the end of the programme, I was leading the Design System as a product while remaining close to the design and technical work.I combined hands-on Product Design and Design System work with Engineering collaboration, platform strategy, governance, adoption and stakeholder alignment.This was where I started thinking about Design Systems as products — with users, capabilities, roadmaps, technical foundations and measures of success.

What I learned

Smart reinforced something I'd started learning at Vodafone: Design Systems don't fail because someone built the wrong button.They struggle when teams aren't aligned, ownership is unclear, knowledge is locked inside individuals, and the platform isn't connected to real product delivery.The technology matters. But successful Design Systems also need the right design practice, technical foundations, relationships, governance and operating model around them.For me, the most effective approach was to stay hands-on while creating the conditions for other teams to succeed.