battleface x Expedia
Battleface is a global insurtech MGA that designs modular travel insurance products and distributes them primarily through enterprise partnerships. They support the full policy lifecycle from quote to claim across six major markets using a proprietary platform and partner API.
In 2024, Battleface entered talks with Expedia.
I was in the early stages of a roadmap initiative internally known as the Dynamic Purchase Path1 when negotiations with Expedia began. After stakeholders committed the DPP as a core capability, it became mission-critical to the partnership.
Impact & Outcome
I led the design of a config-driven consumer purchase path, the foundations for a no-code purchase path configuration UI in Battleface’s internal platform (Marvin), and a new reporting feature for the Battleface partner portal.
Successfully shipping the DPP and supporting platform features clinched a strategic partnership with Expedia and significantly boosted Battleface’s go-to-market velocity across global distribution channels.
The Challenge
While Battleface possessed industry-leading actuarial capabilities, our speed-to-market was throttled by a hardcoded, "one-off" legacy. Launching a single partner purchase path took an average of 3.5 weeks, and updating anything required a developer familiar with that specific implementation.
what up dudeThe current approach resulted in a collection of independent, rigid checkout flows that created:
- Engineering Bottlenecks: Excessive lead time due to high-touch developer intervention.
- Splintered UX: Inconsistent customer journeys that diluted brand trust.
- Data Silos: Unreliable analytics across different regions and product types.
Vision
Our objective was to transition internally from a service-dependent model to a platform ecosystem with self-service capabilities, while delivering a first-rate, global, consumer experience that supported a wide range of product configurations and met Expedia's standards.
Deconstructing the sprawl
Mapping the existing ecosystem was the most obvious place to start. I partnered with our PM to audit all existing purchase paths. We broke the partner implementations down into a catalogue of reusable primitives grouped by stage and documented their data sources.
We identified two product types, taking on two product formats, rolled out across five regulatory environments, and running on two different versions of the Battleface partner API.
The audit confirmed a heavy reliance on hardcoded data, which we aimed to eliminate in favor of a 100% configurable, API v2.0-generated model.
Picking up the pieces
Early assessment & Defining Scope
After consulting the insurance team to identify any missing regulatory requirements, I worked with our PM and engineers to assess the introduction of key fields and logic that previously existed only in manual workflows to ensure Marvin (our enterprise platform) could support a fully dynamic product composition.
These technical constraints directly shaped the scope for MVP 1, defining the boundaries for both the internal configuration and consumer experience.
Universal Checkout Exploration
Leaning on user insight from previous work on the US purchase path and fresh from cataloguing our global presence, I explored how other players in the insurance space tackled the quote-to-bind experience, with a focus on how they handled quoting and plan customization.
We locked in a few high-level conventions found in competitor patterns and began ideating around how we could leverage them in the DPP.
1. Four-Stage Flow
I established a standardized four-stage flow: Guided Quote, Quote Summary, Personal Details, and Payment. This structure was strategically chosen to align with our underlying microservice architecture and provided a predictable mental model for the user.
2. Multi-Step Guided Quote
To accommodate the dynamic nature of global products and regions, I designed the initial quote stage as a multi-step process. This offered several strategic advantages:
- Scalability: It allowed for the dynamic injection or removal of questions based on specific product or regional requirements.
- Cognitive Load: We could deliver contextual information without overwhelming the user.
- Behavioral Psychology: It introduced "positive friction"—leveraging the sunk cost effect to build user momentum and anticipation. While A/B testing showed no clear winner between single vs. multi-step forms, this approach best addressed the user's need for real-time guidance identified in past research.
3. Modular eCommerce Feel
Once through the guided stages, the experience transitioned to a modular e-commerce layout.
- Mobile Friendly: Expedia's customer base skewed heavily mobile. A solid mobile experience would be critical.
- Familiarity: By mirroring modern e-commerce conventions, we minimized cognitive load and signaled brand maturity.
- Real-time Manipulation: Research indicated that users expect immediate price feedback. The layout ensures that "price levers" and the total quote remain visible simultaneously, allowing for seamless adjustment.
4. Visible End-to-End Progress
A persistent visual progress indicator was implemented to provide a constant sense of orientation. This reduced "drop-off anxiety" by clearly mapping the journey from start to finish.
I designed for extreme permutations, testing how the layout handled both the simplest and most complex data sets.
It became clear that the 'package card' and the 'cart' would do a lot of the heavy lifting. I started with these components, building the rest of the experience around them.
Package Card
Arguably the most critical component in the DPP, the package card needed to be robust enough to handle variable configurations, yet streamlined enough to avoid cognitive overload.
The audit revealed that the most common manifestation of a package in a modular plan included only one benefit and zero options for customization. This insight drove the direction for the card's canonical form and extensible structure.
Selecting intuitive affordances visually communicated functionality. These choices were grounded in research, prioritizing a 'play without consequences' environment to encourage exploration.
Complexity was hidden behind component logic. I designed and documented the rules for progressive disclosure and logic-driven UI expansions that mapped to backend configurations.
After (endless) rounds of ideation, prototyping, testing and review, I landed on an iteration of the card that met MVP spec, got a green light from global compliance, and met Expedia's expectations.
See for yourself how the component responds to different configurations!
'Package icon' was a new optional field we introduced to offer more brand control and draw the eye to the package cards. I extended our icon set (originals created by Studio Freight) to include eight new icons.
Using the Battleface Partner Portal, a partner would be able to opt out of displaying icons, upload their own, or roll with the default Battleface icons.
Cart
The core tenet of e-commerce conventions. To make this decades-old mental model work for us, we needed to align traditional standards with unique business scenarios across the last three steps of the DPP.
The new cart gracefully handles different product types and formats, regional elements like currencies, taxes, fees, and links to regulatory material, and varying degrees of available data without breaking. Clear grouping and a thoughtful hierarchy keep the information easy to understand.
We learned from research that users expect immediate price feedback and are likely to use price levers to manipulate the cost of their plan. The cart was designed with this in mind, able to recalculate the quote without a full page reload for a smooth experience.
End-to-end Design
Delivery of the DPP was executed with a rolling handoff. Responsive layout and global navigational elements were delivered as early as possible. Detailed components and logic were then finalized and passed to engineering while they were building the core.
The Expedia implementation of the DPP in the US successfully converted 6.7% of quotes to bound policies within its first month of operation, with a 55% start to quote rate.
To keep things manageable, this write-up only covers key highlights. Reach me at hello@ethanwalpole.com to talk more about my involvement, including a themeable design system, edge cases, and how we handled tracking.
Platform features
To fully harness the power of the DPP, several features needed to be made available across the platform ecosystem.
Marvin Purchase Path Manager
To shift control of the DPP into the hands of internal users and partners, we needed a way to configure the purchase paths beyond making changes to the underlying product or partner. I conceptualized, wireframed and prototyped two no-code config UI feature concepts for Marvin, which I then presented to the team.
This is as far as we got before the decision was made to postpone the Marvin Purchase Path Manager feature and go with an interim engineering-driven solution for MVP 1. Unfortunately I never got to revisit this.
Partner Portal
Expedia needed a way to reconcile our numbers with their own internal ledgers. They weren't the first to request the ability to run reports in the partner portal, but they were the biggest. We gladly took the opportunity to make this addition.
I worked directly with our PM and Expedia's product team to shape a reporting feature that would both provide Expedia the insight they wanted and juice up our offering when entering future negotiations.
Reporting was launched via an exclusive pilot with Expedia. Co-designing the UX against enterprise-scale requirements allowed us to refine the feature in a live environment and ensure it was hardened and high-performing before a general release.
Lessons learned
This project taught me (again) how much real leadership comes down to making smart, sometimes uncomfortable tradeoffs under pressure. I got much better at spotting the difference between healthy standardization that saves time and effort, and the kind of forced uniformity that quietly starts hurting outcomes.
Standardization across regions was a win, but across products was restrictive. Looking back, a better path would have been to create a few high-level templates that all use the same reliable blocks (components, logic, data model) but allow each product type enough breathing room to adapt in a way that is most advantageous to its format.