Case Study
iOS, Android | B2C IoT | 2022-2023
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.
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
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.
The system needed to gather and present reliable data so users could make decisions
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.
The client was not satisfied as the product was way behind budget, and time. We need to make sure we got that trust back.
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).
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.
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.
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
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.
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.
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.
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.
Users had to enter data manually, even in cases where this was unnecessary as the data was already in the system in other places.
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.
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).
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.
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.
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.
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.
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).
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
iOS, Android | B2C IoT | 2022-2023
Back-Office Web App | B2B SaaS | 2022
Back-Office Web App | Internal | 2020
Web App | B2B2C SaaS | 2021
iOS | B2C SaaS | 2018 - 2019
Web AR App | B2C Concept | 2023