TravelTriangle ·
payment dashboard
There are 100s of Travel Agents active on TravelTriangle’s marketplace platform on any given day serving 1000s of Travelers. Some of the agents have as many as 150 or more leads to follow up in the pending or upcoming payment funnel of their business. All payment transactions are supposed to be done through the marketplace making it a triangular structure with multiple stakeholders(characters) in the process.
Breaking Down Information Overload in Financing
In this case study, we are looking at a part of the entire payment process called the ‘Voucher and Payment Module’ which is shared with all the stakeholders but each of them have a different view. Here we are discussing the Travel Agents’ view, which is quite a BEAST among the three with many unresolved use-cases and complex corner cases. It deals with ledger adjustments, recoveries, cancellations, tax information, commissions, offers, discounts and also the recalculations made to fix the deviations made on a standard set of processes to name a few. These cases create a lot of subplots within the story.
​
The primary stakeholders involved in this process are the Travel Agents, the Finance Team at TravelTriangle and the Travelers. The core objective(the central plot) of the main stakeholder here(A Travel Agent) is to close the account of each trip with ‘zero balance’ between them and the other stakeholders. Because any number they see in the balance sheet is the money they will lose when the account is closed. Hence we thought that should be the central thread(motivation) to tie everything else into.
​
This module was originally created a long time ago with various log entries from the database. The visual hierarchy and the information architecture was probably not the top priority at that point in time. The long story short… it was time for us to relook at the user experience and fix the broken communication of the module as it started impacting the efficiency of the Travel Agents, which is indirectly affecting the services we offer to our end customers(Travelers). That is the context of why we decided to tell the same story but with a better narrative.
Voucher & Payment (Old Design)
A basic version of the product as designed earlier when the requirements were minimal and the scale of business was much smaller.
Strategy and Solution
After understanding the current system of payments, the needs and the wants of the users we converged into the following strategy.
​
The primary focus was to reduce noise using Progressive Disclosure so that we can enable our users with quicker prioritization. We also looked at the existing behaviors and learnings of the users, for improving the visual hierarchy of the module, along with more appropriate use of microcopy (those tiny pieces of text used in the interface) using the lingo that the users are familiar with.
​
The final solution has two parts. A summary view(collapsed card) and a detailed full view(open card). The summary view carries just the critical information enabling the users to make quick prioritization through the use of color, composition, and form. At this level, the dependency on the text or any calculations is kept to almost none.
​
The summary view carries the central plot, while the detail view carries all the subplots- just like how a flashback in a movie would unfold the events one after the other explaining why, when and how did it happen. If there are no errors highlighted in the summary view, the users could move on to the next task at priority to optimize their time. The power to decide is still with the user.
The Summary View (Central plot)
Each card represents a unique trip with minimum information that provides a quick overview of its payment.
The collapsed view unfolds the central plot of the narrative. It gives an opportunity to prioritize the tasks quicker. The top-left area is darkened to guide the users’ eye which is also the starting point.
A detailed view: The important metrics of the summary view. (The left side view of the summary card)
Here, each summary card represents a unique trip. The four elements on the left side in each of the cards tell the most necessary information regarding payments information. The central plot here is to bring the number in the top left area (grey box) to ZERO. To do that, the user needs to resolve all the red errors if there are any during the process.
​
The other three numbers are to give an immediate explanation of the number seen in the top left area. The errors are communicated through text and with the use of basic colors and icons.
Voucher and payment proof related information (the right side view of the summary card) with color-coded status in order to identify and prioritize the next action item.
The Detailed View (Sub plot)
A design that unfolds different parts of payment relate information of a single trip in the right order.
This pattern is designed to encourage the users to read from left to right (from A-G) so that the story is delivered in the simplest way possible.
The above image explains the new narrative strategy. It guides the user to discover the information in a certain manner to make it more meaningful and less confusing. Although it may look loaded with information in the first look, space is highly optimized to hold much-needed information that was missing in the previous version. This has been tested with the real users and they were able to connect with it immediately and the patterns of use were also as expected. This gave us much confidence in the new narrative and the process of iterations would continue from here.
Voucher & Payment Module
(The New Design)
(This showcases only the payment module and not the entire dashboard view)
The current UI and color palette used in this mock-up is made to match the existing(old) design guidelines. It was necessary to keep the visual consistency across the product for the time being.
The Sub-Modules
Detailed views from the mock-up screens (the numbers will not add up, it is only representational). The structure here is inspired by ‘bills’ we receive from any purchase- a conscious attempt to reduce an additional learning curve for the users.
With this project and its contrasting solution from the past, I realized, even more, the importance of paying attention to narratives in product communication. The thing is, even when one does not use a ‘narrative strategy’ consciously, the products would still have some narratives in them; because these digital products are not just two or three-dimensional entities. They have more dimensions and the users often have multiple journeys within the same product experiences. ‘Time’ plays an important role in creating product experiences. In fact, one of my favorite model of creating experiences is the 5E model where the journey of the user is defined through a passage of time using the following five E’s — Entice, Enter, Engage, Exit and Extend.
​
In my understanding, not having a narrative in product design isn’t really an option, but having a good narrative would certainly help to make the communication more meaningful- without which information is just noise. If used well, Narrative strategies can certainly be one among the top problem-solving tools to bring a great deal of clarity and enhance the user experience for products, especially for those overloaded with information.
An anecdote of how an analogous Inspiration influenced the problem solving
Keeping an eye open for any analogous inspiration is a default item in my design process. Naturally, I started to pay special attention to the receipts and invoices from the beginning of the project. Soon I came across an interesting restaurant invoice from a lovely dinner I went with my partner. Ever since I started collecting them to study, I have not found a better tiny piece of paper that gave me so much clarity. This one had done it for me.
​
This receipt that I am referring had led to much clarity to the role of ‘Applied Amount’ and familiar structures. The applied amount part was missing in almost all other invoices I collected later. It gave immediate clarity and transparency on the amount they are charging a service tax or a commission. It could be a bit difficult to make sense of the whole picture if the applied amount is not mentioned. This incident inspired me to look more into how invoices have been designed and it gave me new ideas to implement.
​
In this case study, TravelTriangle charges a commission to the agents as well a 1% TDS(Tax Deducted at Source). These charges are only applied to certain amounts and not all. It gets complex when one of the items or the entire trip is canceled, on such occasions, clarity about the applied amount will help the user to add things up better.
​
What I learned from this incident is that account keeping and ledgers are a basic part of any business or even for an individual in their daily life; which means it is better to use the existing familiar structures than burdening the users with a new learning pattern.
Like what you see?
.png)