01 - Overview
Maps
“My car broke down and I want to go home”
What happens at the insurance call center when a client rings to say their car has broken down in the middle of the country? Maps is the interface that helps the phone operator identify, organise and book travel solutions to help their client get to their destination.
The project name has been changed as it has not launched yet.
02 - Problem
The design challenge
Maps had to help assistance operators turn an unexpected disruption into a practical onward journey while they were still speaking with the client.
The challenge was therefore not simply to display transport results. It had to reveal the right level of complexity at each stage, display enough information to support a reliable decision, without overwhelming the operator or client during a time-sensitive call.
My role: User stories, interface and design system design, stakeholder workshops and development collaboration.
03 - Process
From user and business needs to product behaviour
The interface had to balance two competing needs. Operators needed a fast, manageable search while speaking with the client; the product needed enough information to determine eligibility and show bookable solutions.
Common journey details formed the default search flow, but conditional requirements, such as passenger details for train reservation, driver details for car rental, luggage, and animals were progressively revealed when relevant. This allowed the product to support complex cases without making every search feel complex. Having the user stories grouped up per type of transport solution helped identify the commonalities, vs. the fields that pertain to specific modes of transport.
Designing for the assistance operator
After verifying customer details, the assistance operator starts the process by entering the information required for the system to produce solutions.
Making different solutions comparable
Train, rental-car and taxi journeys contain different information and cannot be compared like identical products. I identified the criteria operators needed across every option, such as total duration, arrival time, price and connections, then used them to create a consistent recommendation structure. Labels such as “fastest” and “lowest cost” made the reasoning behind each recommendation immediately visible.
Designing journeys instead of isolated bookings
A solution could include a main transport mode and several taxi connections. I designed the journey as a continuous sequence of legs so operators could understand transfers, identify risks and explain the complete route.
Adding on to an existing design system
Maps uses an existing design system based on the client’s brand, but the product needs to evolve and develop its own colour palette, brand language and interface components. As the project went on, I had to keep updating the design system and document changes for the team to keep track.
04 - Delivery
Building an MVP and phasing releases
Collaboration with stakeholders and transport providers (for example, SNCF, Carbookr, Resacar) is essential to shape the MVP, as there were technical and business limits to keep in mind.
As new requirements and ideas emerged, I translated them into user stories and interface designs, building on the design system to keep the growing product consistent. Delivery was an ongoing effort, involving the design evolving alongside development and documentation.
Other screens and edge cases
A selection of supporting screens designed for alternative journeys, booking states and operational scenarios. Click on the image gallery below to browse through the screens
05 - Takeaways
In order to ship the MVP, we had to manage a lot of moving parts and ambition
Making complexity manageable
I learned that simplifying an interface starts with understanding the rules behind it. Deciding when to ask for information was as important as deciding how to display it.
Plan for growth, prioritise the first release
I learned that a strong idea doesn’t have to be part of the first release to have a place in the product. By helping stakeholders plan beyond the MVP, I kept future opportunities open while keeping the initial scope focused. In future projects, I’ll distinguish what needs to be built now from what should be explored once user feedback can guide the next step.
Creating shared understanding
Translating requirements into user stories made design discussions more concrete, helping stakeholders and developers agree on how the product should behave.