Back-Office Web App | B2B SaaS | 2022

ERP: Transfers Planning Module for Travel Industry

UX Design
UX Research
Product & UX Strategy
Case Study


The company had developed a Transfers and Excursions module -as part of a greater end-to-end management back-office system for the Travel Industry- based on the requirements of the Business Owner assigned by the client.

After the system had been developed, when the users tried it out, they were complaining to their management that they couldn’t work with the new system. The project was way over budget already, and in danger of missing critical dates for the client (high season that generates most of the annual income/profits).


Make the Transfers and Excursions planning module of the back-office system work for the client’s 27 companies across the world.Evaluate what works, fix what isn’t, and make sure that client’s employees want to work with such system.

Role & Team

I worked hand-in-hand with the senior PM assigned to the project in order to figure out what was working and what wasn’t. My role was to plan, conduct and analyse the necessary research -given the constraints- then propose solutions based on the evidence gathered. Also, I worked to create the strategy for the first two versions of the product

  • 1 UXer
  • 1 PM
  • 1 Front-end Dev
  • 2 Back-end Devs
  • 1 QA

Key Outcomes

User error reduction by 24%
Users across the 27 group-owned companies accepted and welcomed the module
Perceived tool usefulness ranked at top notch (UMUX-lite as baseline)
Built trust with initially skeptical stakeholders

Overview & Background

High-level view of the Business & Product Structure

Business & Product Structure

Our company was the software house of the Group (mothership). The main client was the 27 Destination Management Companies (DMCs) of the Group.

The product these DMCs sell is Hotel rooms, Flights, and/or Transfers services.
The transfers services have the biggest margin, thus the Group considered this project a priority and a strategic opportunity.

Business Goal Samples

Improve Data Reliability & Trust in the System

The system needed to gather and present reliable data so users could make decisions

Optimize the Planning for Quality and Profit

The goal of the system was to create the most profitable plan while keeping the travelers happy. Our goal was to make sure this was happening consistently, and as easy as possible.

Regain the Trust of the Client

The client was not satisfied as the product was way behind budget, and time. We need to make sure we got that trust back.

Create a Tool that Would Work for the 27 Companies

We needed to make sure that tool we were building would be acceptable and useful for 27 companies around the world (each working with different processes and constraints).

Create a Tool that Would Make Our Back-Office Stand Out

The tool we were designing would be a significant advantage for our offering. Especially as the company was selling the system as SaaS to third parties.

Figure Out What We Could Use from Existing System

We needed to make sure that we didn't wasted anything as the client had already paid for the system. There was pressure from top management (and client) to build around the existing tool as much as possible.

An (simplified) overview of the process we followed

Project Process Overview

This is a simplification of the process followed in this project. The actual process was a lot more iterative, with many back and forth as we gained new understanding and we received more insights and evidence.In this short selection of steps we wont see all the steps we followed

Understand & Align

Contextual Inquiries & User Interviews


Observing the user perform their daily tasks together helped us create a shared understanding of their key activities, needs and pain points. Having convinced the BO (Business Owner) to join us in these sessions, helped us get buy-in for key UX improvements that followed. Also, they opened the gates and enabled us to have access to more users

Together with the PM and the BO (business owner), we did a series of semi-structured interviews with experienced and newer (seasonal) employees of the Transfers planning departments. To do these, we had sessions with the BO, and other key stakeholders to make sure we didn’t miss any critical information.

We combined these sessions with some remote contextual inquiries (if we can still call them this in remote settings).

These sessions showed us that although there are some basic steps in each company, there are context differences and nuances in how they do business. Yet, the main flows, needs, and pain points are the same -although they handle them in a different way.

Last but not least, we observed that the use multiple tools in order to complete the tasks. All of which don’t share data automatically, so there is a lot of manual work, and the process is error prone.

Observing users how they do their daily tasks

Service Blueprint


We had a way to visualise the service parts that we needed to design for the first versions of the module. Having all the Actors, their interactions, relationships, and jobs, helped to better understand and orchestrate updates for the service

After talking with multiple people from the Transfers planning departments (from 9 countries/companies) we created a high level Service Blueprint to help us visualise the main flows and interactions across touchpoints.

Our goal was to be able to locate problematic areas, and pinpoint what could break if we make any changes in the system/service.

This also depicted a high level of the jobs the basic Actors of the system had to do in order to complete a transfer successfully.

At this point, we chose to focus on the parts that span from making the booking till the traveler(s) arrive at their destination. The rest would follow at a later stage as time was pressing.

Basic service blueprint

System Entities, Relationships & Actions


This mapping helped clarify the basic entities of the system, their relationships, and interactions. As a next step, this was helpful for create the Information Architecture of the system based on the Tasks Analysis, and the Entity Relationships/Interactions.

We’ve identified 11 entities that play a major role in the system. On each of these, the users must be able to perform certain actions in order to complete their tasks.

By creating a map of these, we were able to communicate easier with Back-End Devs and other Technical leads.

Last but not least, this helped a lot to create the update Information Architecture of the updated system.

Basic System Entities and their relationships

Defined Strategic Goals for the Product


By creating the Vision and the systems involved helped us to create a shared understanding with all the parties involved, get buy-in for UX improvements, and “unlock the doors for more research time with users”.

After having a shared understanding of the jobs to be done, the pains an opportunities, we created a Strategic Vision of how the Transfers and Excursions module would transform in a competitive advantage tool for Back-office, making it a differentiator from the competition.

We also mapped the systems that would need to be improved in order to complete reach the Vision state. This was helpful as we could use it to communicate with team leads and PMs from the other modules of Back-office and sync work.

We also noted some of the main questions/assumptions we had, so we can plan current and further research.

Existing and future systems linked to create strategic value

User Journey Mapping & Task Analysis

As-is user journey map (current state)
Taks analysis
To-be user journey map (desired state)

User Pain Point Samples

Too Much Manual Data Entry

Users had to enter data manually, even in cases where this was unnecessary as the data was already in the system in other places.

Had to Use Multiple Tools to Do the Job

There was no one system that enabled them to do their job. They had to use multiple ones. Increasing the workload and possibility of making mistakes.

Unreliable Data from the System

Users didn't trust certain data, thus they spent time researching and validating the values they saw in the system to avoid mistakes (really costly ones).

Lack of Automation & Information

In case something changed in one the planned services, the system did not inform them. This increased the doing costly mistakes, and having travellers without a transfer.

Inconsistent Processes & Tools

The client having 27 companies across the world, each working on multiple systems, and following their own processes, couldn’t have a reliable overview of what was going on.

Users had to Send Orders Manually

They needed to export data, and prepare custom emails done from scratch to communicate the orders to the suppliers. This got the last part of their job outside of the system, increased their workload, the error rates, and reduced visibility to the managers.

Design, Test & Iterate

Task Flow Samples


By creating the task flows we speed up the process and improved the collaboration with the Devs of the Team. Their early input helped to improve some parts of the flows, and make them easier to develop with our current capabilities.

Next we created the task flows for all main tasks -for all paths, not just the happy one. This was really helpful for the Devs and the QA, as we could first work together and make sure that we had all the cases handled in an optimal way -at least for a first iteration- and we could actually develop it in time and on budget.

Create suborder flows
Send order flows
Move/remove service from order

Main Screens

The module has 3 main screens.
First, a list of all the services added to the system.
Second, an order details screen, enabling users to fine tune the order.
Last, an order list, showing all the planning done, making sure everything is in order (pun not intended).

Services List
Order Details
Orders List

Service List Redesign V1


We adapted the information and actions to the tasks the users needed to perform irrelevant of the system used. We also outsourced some of the manual work to the system and automated the flight information updates to save time and reduce gruntwork

Service List is the first screen of the app that shows all the services (bookings that have a transfer service) that need planning.

We updated the structure of the information to make it easier to compare and see relevant information close to each other. We also added a distance field as this was something that helped the users understand and group the Services into Orders faster. The addition of the Status of the Service, help users to compare and optimise their planning (they did this manually, on other systems and then go back to Transfers Planning to fix them).

Last but not least, we introduced an API to check and update the flight details and information automatically saving the users a lot of time, and reducing the potential for human errors.

Initial redesign of the service list screen

Order Details Redesign V1


Improved visibility, and easier options for optimising the Orders created helped the users do better work, easier, and faster

We restructured the information and made easier to make adjustments as needed based on the tasks analysis. We made it easier to see the proce of the Order, the pickup and dropoff points and make changes to improve the experience for the travellers and reduce the cost for the company.

We created an module-wide indication of updated data on a service -as these could break the planning for the order and it was hard to find them with no notification from the system.

By adding the options to move around certain Services to other Orders, or create a new one for the ones selected, we were able to make things faster and easier for the users.

Initial redesign of the order details screen

Order List Redesign V1


Information comparison and most used tasks became easier, improving the speed in which Order optimisation could happen.We also automated the communications between the Transfers planning Team and their suppliers. saving them a ton of time, and reducing the possibility of costly mistakes

We introduced certain data fields that helped the users to view the cost and duration of the Order, as well as restructure the information grouping to be closer to what users needed to see in order to make decisions if an Order is good to go, or if it needs updates.

Also, we added states for each Order so that users know if there is an action they needed to make or not. In previous versions, and on other tools used, they had to keep an excel file for this, and if something changed, they needed to update the system manually.

We added the most used options for updating an Order under a menu so that user don’t need to navigate in and out of the Order Details each time.

In the first version, we added the option to close the loop and send the generated reports directly from Transfers Planning -previously users needed to download these and send them manually via email.

Initial redesign of the orders list screen
Remote usability sessions using Axure RP prototype with latest database data

We found areas of improvement, and fixed minor usability issues faster and cheaper.The client and users were happy to see rapid iterations and improvements which helped us to get greater buy-in

Usability Testing

We created interactive mocks in Axure RP and used actual data to test in the new concept did the job as we expected and to find areas we could improve the designs before we even started coding.

This helped us find improvements and make adjustments cheaper and way faster, making client, stakeholders, users and developers happy.

Initial results and measurements

We had a quantitative baseline to compare future iterations of the module. This helped a lot with management as shown that our work, well, worked

Quantifying the UX (SUS & UMUX-lite)

After running a round of usability (qual) with 7 users using an Axure RP prototype, we asked the users to answer an SUS questionnaire (and added a question to also have a UMUX-lite).

We designed this study with users that haven’t seen the updated designs before, in order to test the understandability and learnability of the proposed system.

The results were promising as users understood how to use the designs, and were able to complete all the tasks.

Service List Redesign Improvements


Cleaning up the interface and adding options to compare and optimise the Orders enabled users to work faster.

After running Qual usability studies, and then interviewing users, some further improvements became clear to us. Enabling them to complete more ad-hoc scenarios that made their work even more streamlined and fast.

We’ve added an option to view all the Services for the dates chosen, including the ones added in Orders, the users were able to check if there is a way to further optimise these, by filtering and moving Services around. Also, we added an option to filter the Services based on regional offices, making it easier to use for users operating in countries with multiple offices.

Improvements on the services list screen

Order Details Redesign Improvements


We cleaned up the UI and added the options needed to work in certain locations. The process of adjusting the order of the pickups and dropoff was significantly improved and automated.

The information overview of the Order became clearer and easier to view.

Last but not least, we added checks to make sure the system would notify users in case they made a choice that would cost the company instead of creating profit

We’ve added system checks to make sure the planned Orders are as profitable and within parameters of each company.

Showing times that each stop would happen and updating these automatically helped to move faster and have greater control of the Orders. We’ve also added indications for updated services within the Order, and which data has been updated.

Last but not least, we’ve added the option to add Guides to the Order, completing a big part for multiple companies of the client.

Improvements on the orders detail screen

Antenna Services


We made it easier for users to plan complex Orders and optimise the earnings on these. This was a unique feature, and added to the goal of creating the best Transfers planning tool out there.

The users loved this one -when we shown them the prototypes, they asked if they can start using this right away

We offered the option to create sub-Orders, or Antenna services within the Order Details. This was necessary in order to optimise the planning for certain locations that have places inaccessible to busses for example.

By doing this, we enabled users to create bigger Orders, and then break them down to specific parts and assigning taxis to complete them for certain travellers. This greatly helped optimise the time and resources spent to plan in certain locations.

Creation of suborder (AKA antenna services)
Selection of services that need to be splitted
Selection of intermediary points

Orders List Redesign Improvements


Less error prone and easier to optimise Order’s profitability. We adapted the designs to fit some of the ad-hoc process certain companies had, without making it harder for others

We’ve added the option to filter Order based on the regional offices, and introduced system checks and indications to help users avoid sub-optimal Orders.

We also show the expected profit from each Order.

Improvements on the orders list screen


Key Outcomes

User error reduction by 24%
Users across the 27 group-owned companies accepted and welcomed the module
Perceived tool usefulness ranked at top notch (UMUX-lite as baseline)
Built trust with initially skeptical stakeholders

Automations Concept Test for V2


By automating the grouping of the Services based on the Criteria specified, we saved a ton time for the users, and made their lives easier. We were able to move towards a state that the users would help the system optimise the planning, instead of doing the nitty-gritty work themselves.

The more we worked on the module, observed and interacted with it’s supposed users, the prominent it became that there were a lot of thing we could do to improve the utility of the system, and make the working lives of it’s users a bit easier.

Together with the Front-End Dev, we created a rough concept of Service Automated Grouping in Excel using live data, and asked users to provide feedback on what was working and what it didn’t. The majority of the automated groupings worked like a charm, leading us to believe that this could a viable concept moving forward.So, we created a wireframe prototype to test the idea further, and we had a winner in our hands for the direction of the next iterations -when the Client would approve the budget.

Automatic grouping of services test using google sheets
Prototype of concept in Axure RP with live data
Presentation of the concept to C-Level executives from the company and the client

Want to see more?

Work Samples