EE
Lead Product Designer
Mobile Web
A self-serve platform to purchase, activate and manage EE travel eSIMs without friction.
A self-serve platform to purchase, activate and manage EE travel eSIMs without friction.
A self-serve platform to purchase, activate and manage EE travel eSIMs without friction.
My Role
My Role
My Role
I was brought in midway through this project as the lead product designer for eSIMs, my role entailed designing the post-purchase web self serve experience for inbound UK travellers who have a time-limited eSIM.
Design outcomes
Design outcomes
Design outcomes
Delivered flow under tight timelines with limited resourcing and no formal research/dedicated researcher
Created a scaleable self-serve flow that supports early EE ID creation, setting up future cross-sell opportunities
Delivered flow under tight timelines with limited resourcing and no formal research/dedicated researcher.
Created a scaleable self-serve flow that supports early EE ID creation, setting up future cross-sell opportunities.
TL;DR
Scroll down for full case study
- Sole Product Designer across 3 squads, worked closely with Solution Architects, Business Analysts, Engineers and Content Design.
- Led UX design for a 2 month project around platform limitations, leveraging known usage scenarios to guide decisions.
- Aligned the MVP with commercial goals by designing a scalable entry point for travel eSIM customers.
- Simplified tasks like viewing pass status’ and introduced CTA’s to reduce hesitation using behaviour-led logic; decisions validated through stakeholder feedback.
Understanding the business needs01
Business context
EE had no dedicated travel eSIM proposition despite having strong technical infrastructure. Uptake of EE ID accounts was also low among short-term or first-time users, especially inbound travellers.
This proposition aimed to establish EE’s presence in the travel eSIM market, while encouraging early EE ID creation as a foundation for future digital services and account-based upsell opportunities.
This proposition aimed to establish EE’s presence in the travel eSIM market, while encouraging early EE ID creation as a foundation for future digital services and account-based upsell opportunities.
Design Goals
We aligned on clear UX goals focused on reducing decision friction and supporting confident data management.
Enable quick, intuitive pass management: Build a clear self-serve flow for viewing, activating, and re-purchasing eSIM passes.
Minimise drop-off in early decision points: Reduce cognitive load by simplifying layout, hierarchy, and CTA logic.
Surface control and reassurance: Support key user behaviours (e.g. refund checks, pass status) with clear patterns and error state copy.
Deliver a flow that fits EE’s component and delivery constraints: Design within system rules while enabling flexibility for edge cases and future enhancements.
Opportunity targets
- Untapped market: 60% of travellers arrange connectivity before arriving however EE had no presence in this space.
- Trust-building: Engaging with users pre-arrival helped plant early brand familiarity.
- UX challenge: Assumed low user familiarity meant the flow needed to minimise friction and surface clarity early to support confident decision-making.
Raised constraints from stakeholders
- Solution architect: Raised error state concerns for unintended access by existing EE users, who may encounter the platform despite not being the target audience.
- Business analyst: Flagged that technical feasibility might change during build, potentially altering design requirements.
TL;DR
Scroll down for full case study
- Sole Product Designer across 3 squads, worked closely with Solution Architects, Business Analysts, Engineers and Content Design.
- Led UX design for a 2 month project around platform limitations, leveraging known usage scenarios to guide decisions.
- Aligned the MVP with commercial goals by designing a scalable entry point for travel eSIM customers.
- Simplified tasks like viewing pass status’ and introduced CTA’s to reduce hesitation using behaviour-led logic; decisions validated through stakeholder feedback.
Understanding the business needs01
Business context
EE had no dedicated travel eSIM proposition despite having strong technical infrastructure. Uptake of EE ID accounts was also low among short-term or first-time users, especially inbound travellers.
This proposition aimed to establish EE’s presence in the travel eSIM market, while encouraging early EE ID creation as a foundation for future digital services and account-based upsell opportunities.
This proposition aimed to establish EE’s presence in the travel eSIM market, while encouraging early EE ID creation as a foundation for future digital services and account-based upsell opportunities.
Design Goals
We aligned on clear UX goals focused on reducing decision friction and supporting confident data management.
Enable quick, intuitive pass management: Build a clear self-serve flow for viewing, activating, and re-purchasing eSIM passes.
Minimise drop-off in early decision points: Reduce cognitive load by simplifying layout, hierarchy, and CTA logic.
Surface control and reassurance: Support key user behaviours (e.g. refund checks, pass status) with clear patterns and error state copy.
Deliver a flow that fits EE’s component and delivery constraints: Design within system rules while enabling flexibility for edge cases and future enhancements.
Opportunity targets
- Untapped market: 60% of travellers arrange connectivity before arriving however EE had no presence in this space.
- Trust-building: Engaging with users pre-arrival helped plant early brand familiarity.
- UX challenge: Assumed low user familiarity meant the flow needed to minimise friction and surface clarity early to support confident decision-making.
Raised constraints from stakeholders
- Solution architect: Raised error state concerns for unintended access by existing EE users, who may encounter the platform despite not being the target audience.
- Business analyst: Flagged that technical feasibility might change during build, potentially altering design requirements.
TL;DR
Scroll down for full case study
- Sole Product Designer across 3 squads, worked closely with Solution Architects, Business Analysts, Engineers and Content Design.
- Led UX design for a 2 month project around platform limitations, leveraging known usage scenarios to guide decisions.
- Aligned the MVP with commercial goals by designing a scalable entry point for travel eSIM customers.
- Simplified tasks like viewing pass status’ and introduced CTA’s to reduce hesitation using behaviour-led logic; decisions validated through stakeholder feedback.
Understanding the business needs01
Business context
EE had no dedicated travel eSIM proposition despite having strong technical infrastructure. Uptake of EE ID accounts was also low among short-term or first-time users, especially inbound travellers.
This proposition aimed to establish EE’s presence in the travel eSIM market, while encouraging early EE ID creation as a foundation for future digital services and account-based upsell opportunities.
This proposition aimed to establish EE’s presence in the travel eSIM market, while encouraging early EE ID creation as a foundation for future digital services and account-based upsell opportunities.
Design Goals
We aligned on clear UX goals focused on reducing decision friction and supporting confident data management.
Enable quick, intuitive pass management: Build a clear self-serve flow for viewing, activating, and re-purchasing eSIM passes.
Minimise drop-off in early decision points: Reduce cognitive load by simplifying layout, hierarchy, and CTA logic.
Surface control and reassurance: Support key user behaviours (e.g. refund checks, pass status) with clear patterns and error state copy.
Deliver a flow that fits EE’s component and delivery constraints: Design within system rules while enabling flexibility for edge cases and future enhancements.
Opportunity targets
- Untapped market: 60% of travellers arrange connectivity before arriving however EE had no presence in this space.
- Trust-building: Engaging with users pre-arrival helped plant early brand familiarity.
- UX challenge: Assumed low user familiarity meant the flow needed to minimise friction and surface clarity early to support confident decision-making.
Raised constraints from stakeholders
- Solution architect: Raised error state concerns for unintended access by existing EE users, who may encounter the platform despite not being the target audience.
- Business analyst: Flagged that technical feasibility might change during build, potentially altering design requirements.
Designing without formal research02
Research limitations
Due to limited timelines, we couldn’t conduct dedicated research.
Instead, we leaned on known behaviours from past design work and used regular walkthrough sessions with internal teams to anticipate and correct friction points early.
Instead, we leaned on known behaviours from past design work and used regular walkthrough sessions with internal teams to anticipate and correct friction points early.
How I handled it
To compensate for the lack of formal research, I leaned on known behavioural patterns and internal insights to guide design priorities.
- Designed for core behaviours: Checking usage, buying new data passes and requesting refunds.
- Spotted known friction points early: Partnered with our BA to review internal tickets to identify common pain points (e.g. unclear expiry dates, pass status).
- Enabled quick iterations: Worked with Product and Engineers to ensure the UI would support low-friction flow with real-time feedback, and aligned with our design system (Loop)
Designing without formal research02
Research limitations
Due to limited timelines, we couldn’t conduct dedicated research.
Instead, we leaned on known behaviours from past design work and used regular walkthrough sessions with internal teams to anticipate and correct friction points early.
Instead, we leaned on known behaviours from past design work and used regular walkthrough sessions with internal teams to anticipate and correct friction points early.
How I handled it
To compensate for the lack of formal research, I leaned on known behavioural patterns and internal insights to guide design priorities.
- Designed for core behaviours: Checking usage, buying new data passes and requesting refunds.
- Spotted known friction points early: Partnered with our BA to review internal tickets to identify common pain points (e.g. unclear expiry dates, pass status).
- Enabled quick iterations: Worked with Product and Engineers to ensure the UI would support low-friction flow with real-time feedback, and aligned with our design system (Loop)
Designing without formal research02
Research limitations
Due to limited timelines, we couldn’t conduct dedicated research.
Instead, we leaned on known behaviours from past design work and used regular walkthrough sessions with internal teams to anticipate and correct friction points early.
Instead, we leaned on known behaviours from past design work and used regular walkthrough sessions with internal teams to anticipate and correct friction points early.
How I handled it
To compensate for the lack of formal research, I leaned on known behavioural patterns and internal insights to guide design priorities.
- Designed for core behaviours: Checking usage, buying new data passes and requesting refunds.
- Spotted known friction points early: Partnered with our BA to review internal tickets to identify common pain points (e.g. unclear expiry dates, pass status).
- Enabled quick iterations: Worked with Product and Engineers to ensure the UI would support low-friction flow with real-time feedback, and aligned with our design system (Loop)
Reducing decision friction03
What I tackled
I designed for clarity in a high-friction context. Users needed to check expiry, request refunds, or activate a new pass without guidance.
Design moves I made to reduce friction
Mapped out usage scenarios (e.g. expired pass, active pass, partial refunds) to anticipate friction points
Sketched low-fidelity wireframes to test layout clarity and action hierarchy early, before committing to UI
Audited available components, adapting the design system to support key interactions with minimal friction
Refined the flow structure, surfacing the most common and confidence-building actions ( “View”, “Help with eSIM”, “Buy a new data pass”)
Accounted for refund pathways, ensuring legal requirements were met without overwhelming the landing page.
Design trade offs that mattered
Restructured layout to meet constraints:
- Removed filtering (due to backend constraints) and reordered passes by urgency surfacing active first, then prompting repurchase.
Enabling refunds through consistent UI patterns:
- Refunds were legally required but complex. I used recognisable components to surface refund actions only when eligible, helping users self-serve confidently without exiting the flow, reducing support tickets, and reinforcing trust through consistent UI.
Reducing decision friction03
What I tackled
I designed for clarity in a high-friction context. Users needed to check expiry, request refunds, or activate a new pass without guidance.
Design moves I made to reduce friction
Mapped out usage scenarios (e.g. expired pass, active pass, partial refunds) to anticipate friction points
Sketched low-fidelity wireframes to test layout clarity and action hierarchy early, before committing to UI
Audited available components, adapting the design system to support key interactions with minimal friction
Refined the flow structure, surfacing the most common and confidence-building actions ( “View”, “Help with eSIM”, “Buy a new data pass”)
Accounted for refund pathways, ensuring legal requirements were met without overwhelming the landing page.
Design trade offs that mattered
Restructured layout to meet constraints:
- Removed filtering (due to backend constraints) and reordered passes by urgency surfacing active first, then prompting repurchase.
Enabling refunds through consistent UI patterns:
- Refunds were legally required but complex. I used recognisable components to surface refund actions only when eligible, helping users self-serve confidently without exiting the flow, reducing support tickets, and reinforcing trust through consistent UI.
Reducing decision friction03
What I tackled
I designed for clarity in a high-friction context. Users needed to check expiry, request refunds, or activate a new pass without guidance.
Design moves I made to reduce friction
Mapped out usage scenarios (e.g. expired pass, active pass, partial refunds) to anticipate friction points
Sketched low-fidelity wireframes to test layout clarity and action hierarchy early, before committing to UI
Audited available components, adapting the design system to support key interactions with minimal friction
Refined the flow structure, surfacing the most common and confidence-building actions ( “View”, “Help with eSIM”, “Buy a new data pass”)
Accounted for refund pathways, ensuring legal requirements were met without overwhelming the landing page.
Design trade offs that mattered
Restructured layout to meet constraints:
- Removed filtering (due to backend constraints) and reordered passes by urgency surfacing active first, then prompting repurchase.
Enabling refunds through consistent UI patterns:
- Refunds were legally required but complex. I used recognisable components to surface refund actions only when eligible, helping users self-serve confidently without exiting the flow, reducing support tickets, and reinforcing trust through consistent UI.
Aligning teams and enabling delivery04
Delivery and Launch
To support a smooth launch, I focused on alignment moments that reduced ambiguity and kept things moving:
- Ran live walkthrough sessions with engineers, architects, and product to align on flow logic and component usage.
- Presented a tribe-level design showcase to present final designs and secure stakeholder confidence.
- Annotated all components in Figma, including edge cases and system logic, to reduce development ambiguity
- Collaborated closely with product to implement late requirements without delaying delivery
- Maintained an open feedback loop to support implementation and clarify handover questions in real-time
What success looked like04
Result and what happened next
- Delivered MVP with minimal ambiguity or dev blockers, despite technical trade-offs.
- Stakeholder praised the clarity of flow, especially around pass status visability.
What i’d do differently next time06
- Push for early usability testing to better validate assumptions around pass state and refund logic.
- Explore a phased approach for filtering, balancing backend limitations with a more scaleable UI