Back-Office Web App | Internal | 2020

ERP: Contract Pricing Module

UX Design
UX Research
Product & UX Strategy
Case Study


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

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.

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

Overview & Background

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

Business Goals

Increase the Company's Competitiveness

The team was responsible to make the company competitive, and thus increase the profitability.

Make System Easier & Faster to Use

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 Team Make Decisions

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.

Reduce Errors

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.

Understand & Align

Company Department Blueprint


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.

Mapping of the company's departments, systems, and their relationships

Contextual Inquiry & Interviews


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.

Observing users performing their daily tasks

Heuristic Evaluation


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

Observing users performing their daily tasks

Task Flows & Task Analysis

End-to-End Task Flowsto add a contract
Task Flows of the Yield Department
High LevelTask Analysis

User Pain Points

Too Many Properties to Manage

The team had to manage and adjust pricing (markups) for over 9000 hotels (this is not a dragonball reference!)

Ambiguity in Data

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.

Fragmented Information Spread Across Multiple Tools

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.

The System Didn't Inform the Team for New Entries

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.

Too Much Manual Work

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.

Markup Requirement Analysis


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.

Analysing the requirements
Illustrating the impact and complexity of what was requested

Design, Test & Iterate

Propose New IA and UI Concept


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

Requested VS proposed Information Architecture
View using the requested Information Architecture
View using the proposed Information Architecture

Product Level Markups


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.

Showing all the relevant data on one screen

Activity Log On Each Level


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.

Showing the last 5 updates on each level

Sales Level Markups


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.

Showing all the relevant data on one screen

Scheduled Markups


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.

Showing all the relevant data on one screen
Creating scheduled markups

Markups Breakdown


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.

Breakdown of applied (SUM) markups from all levels

Usability Testing Prototypes


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.

Providing the tasks via google forms
Using Axure RP prototype to test


Key Outcomes

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

UMUX-lite Results & Benchmarking


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.

UMUX-lite score between versions
Perceived usability and utility between versions

Want to see more?

Work Samples