Role
Senior Product Designer
Platform
Customer Journey Map
Company
Console Connect
Year
2024-2025
Approach
Stakeholder and user interviews → Journey mapping → Gap analysis → Identify Opportunities → Onboarding Improvements
The Challenge
Console Connect customers move through several connected experiences: setting up an account, becoming eligible to order, placing an order, completing provisioning steps and managing an active service. Different teams owned different parts of that journey, but no one had mapped what customers experienced from beginning to end.
That made it difficult to see where a customer might be waiting, what information they had received or what they needed to do next. Some steps had also been carried forward from manual booking processes, even though customers were now completing much of the journey online.
We needed a shared view of the full experience before we could make confident decisions about where to improve it.
Timeline: 3 months
9 Stakholder/SME interviews 6 User interviews
3 revisions
Understanding what wasn't working
Audit first. Build second.

Before creating anything new, we needed to understand what we already had.
The design team audited and documented existing Motif components, identifying inconsistencies, duplication and gaps in the library.
But looking at components alone wouldn't tell us why the system was difficult to use.
We asynchronously gathered feedback from designers and developers to understand the challenges they experienced working with Motif day to day.
This surfaced issues around inconsistent terminology, difficulty finding appropriate components, gaps between design and implementation, limited documentation and friction caused by the underlying technical architecture.
Creating shared ownership
A design system couldn't belong to design alone

One of the most important changes was how we worked together.
We helped establish a Design System Community of Practice (CoP), bringing designers and developers together to discuss the system and make decisions collaboratively.
The CoP gave us a shared space to discuss component requirements, naming, implementation constraints, technical considerations and emerging patterns.
It also helped establish something Motif had previously lacked: governance.
Start with the essentials → Prove the approach → Learn → Then expand.
Simply layering new components onto the existing implementation risked carrying the same problems forward. Our goal was to reduce inherited technical debt while creating a foundation that could support both Gentu and future products.
Designing the system
With the foundations established, we began designing essential components and patterns in Figma.
Rather than treating components as isolated UI elements, we considered how they would behave as part of a larger system.
That meant thinking through variants, states, interaction behaviour, accessibility, naming conventions and how individual components combined into larger product patterns.
We also worked towards greater alignment between Figma and development.
Establishing clearer terminology and component structures gave designers and developers a stronger shared language.
The goal wasn't to create the biggest possible component library. It was to create a system teams could understand, trust and reuse.
Documentation became part of the component
A component isn't truly reusable if people don't know how or when to use it.
We created a dedicated website to document the design system and worked with developers to capture guidance alongside implementation.
Documentation went beyond showing what a component looked like. It helped explain when to use it, how it behaved, what variations existed and how it should be implemented.
This created a clearer source of truth for both design and development and reduced reliance on individual team members knowing how something was supposed to work.
Building while delivering
We couldn't stop product development while building Vitality.
Instead, we divided ownership across the team, prioritised essential components and progressively expanded the system as product needs emerged.
New product work became an opportunity to test components in real scenarios. When something didn't work, those learnings could feed back into the system.
It became something we could continuously iterate and improve.
Impact

User
Greater consistency across components and interaction patterns helped reduce unnecessary variation across frequently used healthcare workflows.

Product
Reusable components and patterns created a stronger foundation for building new experiences without repeatedly solving the same UI problems.

Team
A shared language, clearer documentation and closer collaboration helped reduce ambiguity between design and implementation.

Organisation
Built a scalable design-system practice supported by reusable components, documentation, governance and shared ownership.
The biggest change wasn't visual
The most valuable outcome wasn't any individual component. It was changing how we approached the system.
Motif became less about maintaining a library of UI elements and more about creating shared infrastructure for product design and development.
The audit showed us what needed fixing. Listening to designers and developers helped us understand why. And establishing shared processes helped ensure we weren't simply recreating the same problems in a cleaner Figma file.
A scalable design system isn't created by components alone. It's created by the shared language, documentation, governance and collaboration that allow those components to evolve.




