• Back

Vodafone

From product design to a global Design System

Design Lead - Product Design & Design System / Sep 2017 - Jul 2020

Vodafone was where I started to move from thinking about individual digital products to thinking about the systems behind them.I worked across consumer digital experiences including My Vodafone, retail, IoT and chatbot experiences. A new project — TOBi, Vodafone's AI-powered chatbot — gave me the opportunity to try something different.What started as a product design challenge became the starting point for Source, Vodafone's global Design System.

TOBi

Designing a conversational experience

Vodafone needed to improve its customer service experience. Existing contact-centre technology wasn't meeting customer expectations, while customers needed easier ways to access information, support and account services.TOBi was introduced as a conversational AI experience designed to handle common enquiries and help customers complete tasks without always needing to contact a call centre.The challenge was that traditional interface patterns didn't translate directly into conversation.

Designing a new interaction language

I introduced a component and Design System approach to the project, creating a reusable pattern library specifically for conversational UI.Message bubbles, notifications, options, states, content and actions became reusable building blocks that could be combined into complete conversational journeys.Rather than designing every journey from scratch, we could assemble experiences from a consistent set of patterns.This made the work faster to design, easier to iterate and more consistent as the number of journeys increased.

How human should an AI feel?

Another challenge was deciding how human TOBi should be.We wanted the experience to feel approachable and personable, while remaining clear that customers were interacting with a chatbot.I helped establish principles around tone of voice, personality, emotional expression and visual behaviour.Vodafone already had the TOBi character, so rather than creating something new, I proposed using it as the foundation and developing a broader set of expressions that could respond to different moments in a conversation.These expressions became part of the system rather than isolated illustrations, with motion explored alongside a motion designer.

Simplifying complexity

The overarching design principle for TOBi was simple:Simplify complexity.Every interaction needed to make it clear:What's happening → What you can do → What happens nextThis principle influenced both the conversational experience and the reusable patterns behind it.

From TOBi to a Design System

The project changed how I thought about Design Systems.By designing TOBi through reusable components, tokens and patterns, we were able to move much faster than if every journey had been designed independently.I started asking:If this approach works for one Vodafone product, why couldn't we use the same principles across all of them?The opportunity wasn't just to create a better chatbot. It was to stop Vodafone's digital teams from repeatedly solving the same design problems.That became the starting point for Source — Vodafone's global Design System.

Source

Turning a project approach into a platform

I was asked to establish Source and initially became the sole designer working on it.I started with an audit of existing products and patterns across Vodafone, then defined an approach covering:- Design foundations
- Components
- Patterns
- Assets
- Documentation
- Tooling
- Governance
- AdoptionThe goal wasn't simply to create another component library.It was to establish a shared language between Design and Engineering.I remained hands-on throughout, designing and documenting components and patterns while working with product teams and Engineering on how the system could work across different requirements.The system supported the journey from:Structure → Interaction → Visual Design → DevelopmentThis meant Design Systems became part of the product design process rather than something added at the end.

Working with InVision

Because of the scale and complexity of what we were building, InVision worked closely with our team as we developed Source.I regularly met with their Product and Engineering teams to provide feedback on upcoming features and the challenges we were encountering at enterprise scale. We were often able to trial new capabilities before their wider release.This meant I wasn't just using the tools to build Source; I was helping shape how they evolved to support large, distributed Design System teams.

• Read the InVision article →

The first product - My Vodafone App

The My Vodafone App refresh became an important pilot for Source.It was a large, complex product that could properly test whether the system worked in a real product environment.The team adopted the library and began using its components to build real experiences.This created an important feedback loop:Product requirements → Design System → Product implementation → New requirements → Design System evolutionAs the system proved itself, other teams began approaching us.Adoption started to become pull rather than push.

Scaling beyond one product

Source expanded beyond the original consumer experience into very different Vodafone products, including:My Vodafone App · M-Pesa · IoT · EcommerceM-Pesa was particularly interesting because it was a mobile banking service aimed at customers who often didn't have access to traditional banking applications.The product and customer context were very different from the experiences we had originally designed.But the same underlying Design System could support it.Teams didn't need to rebuild the foundations. They could focus on the customer problem and the product experience.That was when I really understood the value of Design Systems:The system doesn't make products identical. It gives teams a better starting point.

Adoption & governance

As more teams adopted Source, I worked directly with markets and product teams to support onboarding, adoption, design reviews, documentation and library usage.I also worked with Design System champions across markets to create a network of people who could support adoption locally.Governance wasn't about controlling what teams could design.It was about creating enough consistency to make the platform useful while still allowing teams to solve their own customer problems.

Making the case for investment

A Design System needs continued investment.I regularly communicated adoption, reuse and delivery improvements to senior stakeholders so that the value of the platform was visible beyond the design team.By 2020, Source was being used by approximately:

The 40% figure reflected the wider delivery process rather than simply component production.For me, these measures were more meaningful than the number of components in the library.They showed that the platform was changing how teams worked.

Designing for multiple brands

Towards the end of my time at Vodafone, I also started exploring how Source could support multiple Vodafone brands through shared foundations and theming.The thinking was to separate:Shared functionality · Shared components · Shared codefrom:Brand expressionThe goal was to allow different brands to retain their identity without requiring completely separate systems.We weren't able to fully realise this during my time at Vodafone, but the idea became important in my next role at Smart Pension, where multi-brand and white-label support became a core requirement from the beginning.

My role

Over three years, my role evolved from Product Designer to establishing and leading Source across Vodafone.I combined hands-on product and Design System work with Engineering collaboration, governance, stakeholder management and adoption across markets.I wasn't managing a Design System from a distance. I was building it, using it and helping other teams adopt it.

What Vodafone taught me

Vodafone changed how I thought about design.I learnt that the biggest opportunity isn't always designing a better individual screen. It's creating the foundations that allow hundreds of experiences to become better, faster and more consistent.A successful Design System needs more than good components. It needs strong technical implementation, real product application, adoption, governance and trust between teams.The difficult part isn't building the button. It's creating something people want to use — and can build on.