Case Study
iOS, Android | B2C IoT | 2022-2023
We were tasked to create the Contract Pricing module of the back-office system used by one of the most profitable companies of FTI group.
This module is one of the most important ones, as it directly affects the profitability of the company. In other words, if this doesn’t work, then the company is loosing a lot of money.Someone had created a prototype app so that the Yielding department could to a really basic version of their work, but this was outside of the back-office system, so the data flow was not complete and automated
Work to bring the test Yielding tool in the existing back-office system, then redesign and improve it in order to meet the growing needs of the department
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.
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
The team was responsible to make the company competitive, and thus increase the profitability.
This was the main tool of the team. It needed to be as easy, and fast to use as the team had way too many markup areas to handle.
Help the team to gather all necessary data in order to make decisions that would make the company's product more competitive. This meant to have the right data, in the right place, at the right time.
Making errors meant that the company's product wouldn't be as competitive, and thus wouldn't sell as much. The team's actions were directly linked to the company's profitability, so, it was crucial to keep them at a minimum.
Having a shared understanding of the situation we’re faced with
A recent visit the company’s headquarters in Dubai enabled us to create a high-level map of the departments, their relationships, interactions and the systems they use to get things done.
As it is seen in the map (and the task flows on the next page), the complexity of the processes is really high.This is because the company has many systems, and the flow of information is fragmented.
This helped us to create a shared understanding with the Team and Stakeholders.
Capturing the process the department follows, and digging for the reasons behind the Why they do so, helped us to have deeper understanding. This part played an important role in the rapport building with the users, and helped us to keep an open line for the rest of the project
We observed users do their daily tasks using multiple tools. They had to be on point, as they copy and pasted data from one platform to another in order to gather the information they needed to make a decision.
We pinpointed usability issues and how people used the existing system, finding the workarounds and reasons behind these.
We started by doing a heuristic evaluation of the existing system in order to find, test, and fix usability issues.
We also observed how people used the system, and all the workarounds they had to do in order to complete their tasks
The team had to manage and adjust pricing (markups) for over 9000 hotels (this is not a dragonball reference!)
The team didn't trust the data the system showed, as there had been cases with mistakes that lead to incorrect markups being applied, and thus loss of profit.
The team had to use multiple tools to gather valid data in order to understand what is going on in the market, and adjust markups in order to keep the company successful and profitable.
When new properties entered the system, the team didn't got any kind of notification or indication. This meant that the company was selling at a loss. In order to handle this, the team had to create additional tasks, and work a bit longer.
Having to use multiple tools, meant that the team had to do a lot of copy-paste from one app to another. Transferring data manually made the whole process tiresome, inefficient, and error-prone. Making a mistake on such a critical position, meant the loss of a lot of money, this increased the stress level of the team.
Visualising and making sure that the needs would be met, helped the stakeholders and users understand and improve on the requirements, as well as the team to get a better grasp of what was needed
We worked with the PM to analyse and visualise the requirements in order to make sure that business, stakeholders, and users understood what these requests would mean for the system (tenfold increase in processing power) and huge increase in interface complexity.
This exercise helped us to work with the business unit that requested this tool, to make improvements on the requirements and create a better result.
We were able to restructure the Information Architecture and improve on the interface and interaction direction.
We managed to reduce the number of pages needed to do the same work, from 23 to 3
We were able to restructure the Information Architecture and improve on the interface and interaction direction.
To do this, we created visual artefacts and quick interactive prototypes
Make the operations faster, and offer a greater overview at a glance. Group the product level operations on a single screen
By having all the product level markups on the same page, the users were able to view at a glance how they stack up and how much these would be for selected Hotels and Rooms.
This provided easier overview and updates, with less unneeded clicks.
Enabled users to find the information they needed faster, with no back-and-forth to the activity logs. After this change, they could also see the reasoning of the changes, and let business stakeholders and analysts do the same
One of the things we observed users doing frequently, was to visit the activity log of the system and look for previous values, when these were changed and by whom. Then, if the change was a big one, they contacted their coworker and asked for the reason of this change.
This took time, and was a lot of unnecessary work. To remove this, we added a way for them to view the last 5 updates on the markups of each level, the date when this happened, the previous values, by whom this change had happened, and for which reason.
That last one, was an addition that came out of the research sessions, and helped other business stakeholders to have a better view of why updates were happening in the system.
Gorw the granularity and control of the markups users could create in order to become even more competitve in the market
We used the same Architecture to create the Sales Level markups, and offer the users higher granularity and control over their markup application.
This by itself, enabled them to have greater command of the prices certain customer (Agents) would get, for certain markets, etc.
Offering the desired granularity and tools for the users to experiments and prepare for the seasons with higher demand
With the introduction of the Scheduled Markups, users could create extremely granular markup criteria that could replicate conditional offers.
This allowed the to experiment as needed to become even more competitive, and to plan ahead for the most valuable periods of the year.
These markups have a start and an end date, and stack up to the previous ones defined in the Product and Sales Levels. closing the loop the department was asking for years.
Offer a way to know the combined markups for a selection in a fast and easy way. This eliminated a number of excessive app switching just to gather all the data they needed in order to make a decision
We added a new sidebar, that showed the existing base markups for a specific Scheduled Markup. This breakdown enabled the users to know wha the final markup for the selection would be -and adjust accordingly by tweaking the values.
This was something towards the direction the users were asking for years. A way to know the final markup, in the system, without having to switch apps etc. For future releases, we’ve planned an updated version that would calculate the exact prices a customer would get if they tried to book a room.
We reduced the code changes needed by testing with highly interactive prototypes. When the development started, we knew we were on the right track, and no major changes needed to happen
We tested all the product updates using Axure RP prototypes that were created with actual data from the databases. This enabled us to test with the values the users worked the previous dates, and have all the interactivity needed to do their work. An almost perfect simulation of what they’d see when using this system.
This enabled us to move a lot faster, and learn cheaper as the these took days, instead of weeks and months of dev time. Also, by reducing the changes, the Devs of the team were really happier, they had more time to work on infrastructure and optimisations, and to participate in some of the sessions an see how they users used the system.
We reduced the code changes needed by testing with highly interactive prototypes. When the development started, we knew we were on the right track, and no major changes needed to happen
Since the users of this system were an internal team of the company, we had the opportunity to usability test and benchmark each version against each other to see how much we moved the needle.
All new tests happened without the users having any actual explanation of the UI changes and additions of new features. This enabled us to have a sense of the learnability and understandability of the system.We initially tested with the version the team was working for some months (left side).
Then we tested with the updated interface, when we integrated the Yielding module to the UNPP back office (middle).
Last, we tested the redesigned application (right).On each iteration the Usefulness of the system increased, especially the perceived Utility of it. We observed a minor decrease in the usability, but this was expected since this was the first time the users interacted with a completely new interface. After some time of using the system we expect a rise in this as it happens in most cases.
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