Dalí

When booking a trip, many people will go to a travel agency in person. With the assistance of an agent, they will build the trip of their dreams.

That also puts a burden on travel agents, who have to work hard and dedicate a lot of time to meeting and talking with potential clients, and only a percentage of them close the deal.

Behind the scenes, every proposal was built by hand. City write-ups, hotel descriptions, and photos lived in separate documents and spreadsheets; flight fares had to be requested and copied in one by one; and everything was assembled into a static PDF. Putting a single proposal together could take an agent a couple of days, and every change request meant redoing part of that work, and often another visit to the agency.

Since Dali Travel offers luxury experience travels, they wanted to offer a better service for their clients, so they looked for me to help.

There, the user would have the ability to view the itinerary and hotel room photos, make changes autonomously, mix & match items like rooms and flight tickets, see maps and vouchers, make and manage reservations, and more, all with a friendly interface to help the decision-making process.

From the travel agency perspective, it would allow agents to auto-generate proposals pulling information from data sources. Content that used to live in scattered files became a library the system draws from: when an agent selects a city, the available hotels come in with photos and descriptions ready to drop into the proposal, and an integration with airline ticketing systems pulls in current flight options and fares. It also let agents create templates that could be replicated for different users while remaining easily customizable, and opened the opportunity for the agency to partner with restaurants, car rental companies and hotels.

For the traveler, the closed PDF gave way to a link: a responsive micro-site that works just as well on a phone or tablet as on a desktop, always shows the latest version of the trip, and can be shared with travel companions in one tap.

We interviewed travel agents and travellers to understand every side of the journey, and we sat with them while they performed real tasks: assembling a proposal, comparing hotels, requesting a change. Watching the work beat asking about the work: the friction showed up in places nobody thought to mention.

The sessions produced a long list of pain points. Written next to each one is the answer that eventually made it into the product, which is how we later argued about what deserved to be built.

Asking "why" until the answers stopped changing pointed to four root causes:

With the team and the agency in the room, we turned each root cause into "how might we" questions. They set the brief for ideation without prescribing any answer.

Open idea sessions with designers, developers, agency staff, and travellers generated the raw material: dozens of feature cards, from mapping with points of interest to QR code readers. At the concept level, four directions competed:

By the end of a session the wall looked like this: one idea per note, no filtering yet, the good and the doomed side by side.

Inside the chosen direction, every feature was written as its own card. This is the full inventory that came out of the sessions, including the ones we argued for and then let go.

Several of those features only work if something feeds them. The integrations were part of the same conversation, since they decide what an agent has to type and what arrives on its own.

Each idea card from the sessions was placed on a priority matrix of resources needed versus benefit to the user. The placement was done by the entire team, designers, developers, and users together, so the trade-offs were argued in the open. Cards in the "cheap and useful" corner, like online payment, vouchers, and mix & match, shaped the MVP; the "expensive and irrelevant" corner, like QR code readers, was let go without guilt.

The prioritized features were organized into a story map: themes on top, epics under them, and user stories below, still high level on purpose, since stories break down further before development. A condensed view:

The interviews condensed into three personas: two travellers with opposite relationships to time, and the agent, who is a user of the same system from the other side.

Before mapping anything into rows and columns, we drew the journey as a storyboard, ten scenes from landing on the site to using vouchers at the destination. It made the experience easy to feel, and it paved the way for the structured map and for prioritization.

The full customer journey map covers the whole relationship, from researching a destination to coming back home. For each phase: what the traveller does, what they want, how it feels, and how we measure it.

The user flow follows the journey: enter, explore, decide, pay, travel. Solid boxes are screens; dashed ones are views inside a screen.

The information architecture keeps the trip as the center of gravity: everything hangs off the client's current proposal.

Wireframes were presented to users and to developers, and adjusted to match what users expected to see and what the team could build. During that phase, we made sure that every single requirement was captured by the mockups.

The clickable prototype then went through acceptance rounds: travellers and agents performing the real tasks, find a hotel, swap it, comment, check out, with us watching where they hesitated.

The rounds trimmed the design rather than reinventing it: labels renamed to the travellers' own words, the mix & match tray made permanently visible, and the checkout reduced to fewer, calmer steps. When the tasks stopped generating questions, the design was ready for the pixel-perfect handoff.

We created a clickable prototype on InVision, but also a detailed document covering all interactions, a PDF with 30+ pages making it clear to the development team how the tool should behave, look and feel. This was instrumental in reducing rework and back-and-forth between team members.

This is an important part of the process, alongside the specs file, also created and provided to the team, which contained the pixel-perfect specifications of the screens.

The biggest shift was in the agents' time. A proposal that used to take around two days of manual assembly, hunting content across documents and spreadsheets, requesting fares, and laying out a PDF, can now be put together in about an hour, with cities, hotels, and live flight options pre-loaded in the system. Revisions that used to mean redoing the document and booking another meeting became same-day adjustments the client sees instantly.

Travelers got a better deal too: instead of a static PDF that aged with every change, they can open the latest version of their trip anywhere, on any device, share it with companions, and adjust it on their own.

Dali Travel's emphasis on customer satisfaction and innovative features set it apart from traditional travel-planning tools, one that caters to the modern traveler's needs and preferences.