Disclosure: This case study is anonymized. Client branding, production screenshots, source code, internal architecture, customer data, and business metrics have been excluded.
Industry: Travel insurance
Project type: Digital quote and purchase journey
My contribution: Frontend development and API integration
Team:
Overview
Purchasing travel insurance appears straightforward: provide trip details, review a quote, choose suitable coverage, and complete the purchase.
The experience becomes more complicated when each stage depends on information collected earlier. Traveller details affect eligibility. Trip dates and destinations influence available options. Quote responses must be translated into information customers can understand. A failed request or incomplete field can interrupt the entire journey.
The process this project aimed to improve relied heavily on repeated data entry, manual assistance, and fragmented interactions. Customers could encounter delays or uncertainty before receiving a usable quote, while internal teams had to spend time supporting steps that could be handled through a guided digital experience.
Our team developed a web-based travel insurance journey to make the process more structured and self-directed.
My responsibility was to implement the frontend screens, connect them to backend services, and maintain a coherent experience as users progressed from entering trip information to reviewing options and completing the application.
The real challenge was preserving continuity
A travel insurance journey is not simply a collection of forms.
It is a connected sequence in which information collected during one stage influences what can happen next. Losing, duplicating, or misinterpreting that information can produce an incorrect request, an unclear quote, or a dead end for the user.
The frontend therefore had to maintain continuity across several concerns:
| Concern |
What the experience required |
| Trip information |
Dates, destinations, and travel details needed to remain consistent throughout the journey. |
| Traveller information |
Details for one or more travellers had to be collected and validated without unnecessary repetition. |
| Quote integration |
Backend responses needed to be translated into understandable coverage and pricing options. |
| Progression |
Users needed to know where they were, what remained incomplete, and what would happen next. |
| Recovery |
Validation problems and unsuccessful requests needed clear, recoverable states. |
| Purchase hand-off |
Selected information had to remain intact as the user moved toward completion. |
The difficult part was not building an individual input or card component. It was keeping the complete experience dependable while multiple screens, data requirements, and service responses interacted.
Why independent pages were not enough
The simplest implementation would have been to treat each stage as a separate page with its own form state and integration logic.
That approach can work for small, unrelated forms. It becomes fragile when the journey depends on shared information.
Independent pages can introduce:
Repeated data entry.
Duplicated validation rules.
Inconsistent loading and error behaviour.
Accidental loss of previously entered information.
Tight coupling between interface components and API response structures.
More difficult changes when requirements evolve.
Instead, the frontend needed to behave as one journey with multiple stages.
Each stage could own its immediate interface while participating in a shared flow for data continuity, validation, request handling, and progression.
Engineering principle: A multi-stage purchase journey should be designed around the lifecycle of its data, not merely the number of screens it contains.
My contribution
I was responsible for the frontend development and integration work required to turn the proposed experience into a functioning web journey.
My contribution included:
Implementing the screens across the quote and purchase flow.
Translating the approved designs into responsive frontend interfaces.
Connecting the screens to backend APIs.
Preparing frontend data for backend requests.
Interpreting service responses for presentation in the interface.
Handling loading, validation, successful submission, and recoverable error states.
Preserving relevant information as users moved between stages.
Coordinating integration requirements with the backend engineer.
Working with the product designer to keep technical behaviour aligned with the intended experience.
I did not own the insurance-domain calculations, backend services, or product design independently. My role was to build the customer-facing layer and ensure that it interacted reliably with the services behind it.
Structuring the journey around predictable stages
Each stage of the frontend flow was given a focused responsibility.
A stage needed to:
Present the information required from the user.
Validate what could be checked in the browser.
Preserve valid information for later stages.
Prepare the correct request when backend processing was required.
Interpret the response.
Either advance the journey or explain what needed attention.
This structure prevented progression logic from becoming scattered across unrelated components.
It also created a more consistent experience. The same journey should not respond differently to similar conditions simply because two screens were implemented separately.
Loading feedback, disabled actions, validation messages, and error recovery were treated as part of the product behaviour rather than as finishing touches.
Separating interface state from service behaviour
One of the central frontend challenges was translating between two different models.
The backend operated in terms of requests, fields, rules, and responses. The user experienced questions, choices, prices, progress, and feedback.
Those models could not be exposed to each other without translation.
Allowing UI components to depend directly on every detail of a backend response would have made the frontend harder to maintain. A service change could then affect several screens, even when the customer-facing behaviour had not changed.
The implementation therefore needed a clear integration boundary responsible for:
Preparing request data.
Triggering service calls at the appropriate stage.
Interpreting successful and unsuccessful responses.
Mapping technical errors to useful interface states.
Preventing incomplete requests where possible.
Keeping backend-specific structures away from presentation components.
This did not eliminate integration complexity. It gave that complexity a defined place to live.
Coordinating quote data with the interface
Quote-driven products create a particular integration challenge: the information shown to users is not always available when a page first renders.
A request may depend on several pieces of trip and traveller information. The resulting options must then be represented in a way that supports comparison and selection.
From the frontend perspective, this required careful handling of the transition between:
Information entered by the customer.
Data submitted for quote processing.
The waiting state while the request was processed.
Available options returned by the service.
The option selected by the customer.
Information carried into the next stage.
The interface also needed to account for unsuccessful or incomplete outcomes.
A technical failure should not leave the user staring at an empty section. A validation problem should identify what needs correction. A request in progress should not look like an unresponsive application.
These behaviors matter because a quote journey contains moments when the system knows more than the user does. The interface must close that information gap.
Keeping design and implementation aligned
The project involved close collaboration between design, frontend, and backend responsibilities.
The product designer defined the intended journey and interface behaviour. The backend engineer developed the services and business-facing integrations required by the flow. My role sat between those concerns.
That required more than reproducing static designs.
Interface decisions needed to reflect what the services could support. API requirements needed to account for how users entered and corrected information. Edge cases had to be represented in the experience even when they were not visible in a default design.
Examples included:
What happens while a quote is loading?
Which information can users edit after receiving options?
What happens to a previous quote when trip details change?
How should incomplete traveller information be presented?
Which failures can users recover from without restarting?
When should an action be disabled rather than allowed to fail?
Resolving these questions collaboratively helped keep the journey technically feasible and understandable to customers.
Outcome
The project delivered a customer-facing frontend for a digital travel insurance journey, connecting multiple stages of information collection, quote retrieval, option review, and purchase progression.
The work established several qualitative engineering outcomes.
A more coherent customer journey
Users could move through a structured sequence rather than navigating a fragmented collection of manual interactions.
Consistent data handling
Trip, traveller, and selection information could be managed as parts of one journey instead of being repeatedly reconstructed by unrelated screens.
More predictable integration behaviour
Requests, loading states, responses, and recoverable failures could follow shared patterns across the application.
Clearer separation of responsibilities
Presentation components, journey state, validation, and backend communication had distinct roles, making the frontend easier to understand and evolve.
Improved feedback during processing
The experience could communicate when information was incomplete, when processing was underway, and when users needed to take corrective action.
These are qualitative implementation outcomes. This case study does not claim measured improvements in conversion, revenue, quote accuracy, processing costs, issuance time, or customer satisfaction because supporting analytics and disclosure permission are not available.
What I learned
1. Quote journeys are data journeys
The screens are visible, but data continuity determines whether the experience works. Every edit, transition, and service response can affect what follows.
2. Integration code is part of the user experience
Request preparation and response mapping may be invisible to customers, but their effects are not. Confusing errors and broken progression often begin at the integration boundary.
3. Loading and recovery states deserve deliberate design
Products that depend on external processing cannot treat waiting and failure as rare exceptions. Those states are part of the normal journey.
4. Shared state should have clear ownership
Centralizing everything creates a different kind of complexity. The useful goal is not one enormous state object, but a clear understanding of which information belongs to the complete journey and which belongs only to the current stage.
5. Cross-functional questions prevent late integration surprises
Design, frontend, and backend decisions influence one another. Discussing edge cases early is generally less expensive than discovering them through a broken purchase flow.
Closing reflection
This project reinforced that building a digital purchase journey requires more than translating designs into pages.
The frontend had to preserve information across stages, coordinate with quote and purchase services, communicate system behaviour to users, and remain maintainable as different parts of the journey interacted.
My contribution was to build that customer-facing layer and manage the boundary between design intent and backend behaviour.
The most important result was not an individual form or comparison card. It was a connected frontend journey capable of turning a multi-stage insurance process into a clearer and more dependable digital experience.
Portfolio callout
What I demonstrated
Frontend development · Multi-step journeys · API integration · State and validation design · Error recovery · Responsive implementation · Designer–developer collaboration
Publication note
All accompanying diagrams and illustrations should be labelled representative or conceptual. They must not be presented as real screenshots, exact architecture, production analytics, or reproductions of the client’s proprietary process.
