It’s possible to explain even the most complex products through design

In this case, I will share a bit about the design process used to explain Blu’s early payment cost and reduce the number of open support tickets by over 50%.

Blu is a payment platform that aims to facilitate the relationship between retail and industry. It is the ideal solution to assist the industry in making more secure financial decisions and is the only payment institution that anticipates credit card sales from any card reader at zero cost to pay suppliers.

NOTE: To ensure the security of collected data, no confidential information will be provided that exposes the company, its clients, or violates the General Data Protection Law.

Context and issues

The platform’s main selling point for retail profile customers, those who purchase from industries, is the zero cost to pay their suppliers using the future balance of their credit card sales.

Within the digital account offered, it’s also possible to perform other banking transactions such as transfers, bill payments, and taxes. In all these cases, it’s also possible to use the future balance to make payments, but the difference is that, in this context, there is a cost associated with the anticipation of these receivables.

One of the major challenges to the business was the uncertainty that arose whenever any anticipation cost was generated, which was reflected in the significant number of open support tickets, aimed at understanding how the charged amount was calculated.

Discovery

Throughout the discovery process, I sought to understand several topics:

1. What is the main reason causing uncertainties?
2. At which point in the journey do uncertainties occur?
3. How is the anticipation fee calculated?
4. Are there any other opportunities for improvement? What are they?

I gathered the necessary information to formulate new hypotheses and define how to approach the problem. The first step was to analyze the open tickets in ZenDesk and then conduct interviews with the support team, examine the available quantitative data in FullStory and MixPanel. Lastly, I sought to understand how the development team arrived at the final anticipation cost.

ZenDesk and support

After spending a few hours listening to the concerns of customers and the support team, I was able to notice the following:

1. The platform provided visibility only of the final cost, without presenting all the variables that influence the calculation.
2. The calculation is complex, and not all members of the support team knew how to explain the values charged clearly.
3. Some customers had difficulty understanding the concept of total balance (the sum of the available amount for immediate use and the total of future receivables, without deducting the anticipation cost). It was not clear that the cost should be deducted to cover the anticipation when trying to transfer the total amount.

FullStory e MixPanel

Observing users’ navigation within the portal, I highlighted other topics:

1. Uncertainty occurred during the payment journey and after completion when people checked the transaction in the statement.
2. There was a significant issue with the statement navigation. When clicking on an anticipation item, users were redirected to a screen displaying the gross amount anticipated for the day. However, what they were seeking were the details of a specific anticipation, not an overview.
3. There was no direct correlation between transactions within the statement.

Conversation with the development team

As the calculation is complex, it was necessary to understand how it worked in practice. To do so, I conducted a conversation with the developer responsible for the anticipation microservice, and in this discussion, I obtained extremely relevant information.

In a simplified manner, the total anticipation cost equals the anticipated amount multiplied by the effective rate for each client. To calculate the effective rate, it was necessary to consider variables such as the contractual defined prompt anticipation rate, which could be influenced by the company’s points program, and the average sales term in months (a period of 28 days).

Analysis and refinement of hypotheses

At this point in the process, after collecting and analyzing all relevant information, it was time to use this data and insights to start development and begin designing and testing solutions that met the needs of the business and users.

Opportunity tree

Within the three main questions, I identified six potential points for improvement along the current journey.

1. Providing visibility and explaining how the anticipation calculation is done
2. Displaying cost information during payment and in the statement
3. Separating payment and anticipation journeys
4. Providing visibility of the total amount available when making payments
5. Showing which balance is being used for payment
6. Linking payment and anticipation entries in the statement

Priority Matrix

During the demand alignment process, I worked closely with product and technology teams to understand the development cost of different solutions and determine which ones could truly add value to the product. This alignment enabled a more accurate analysis of the available options and guided decisions on which paths to follow in product development.

Knowing that the focus was on reducing the number of open inquiries, it was necessary to prioritize explaining the calculation, even though it would likely result in a slightly higher development cost. Additionally, we chose to develop other features with low implementation costs, which would also add value, such as displaying cost information during the payment process and providing visibility of the total available amount when making payments.

Delivery

The objective was to provide access to information in a simple manner without disrupting our users’ workflow. Therefore, besides including new information in the anticipation simulator in the payment flow, the mapped screens should allow users to access an explanation about the anticipation calculation.

After defining the changes and aligning with all stakeholders, I built the interface using all tokens and components from the design system.

Screens from the Blu App

Drawer with cost explanation

Screens from the Web Portal

Results

It’s important to highlight that, due to the company’s organization and the urgency of the request, we didn’t have time to conduct usability tests. Therefore, we decided to roll out the improvements to customers gradually, progressively over the weeks as we observed what worked.

Six months after delivering the first phase of the project, we managed to reduce the number of open tickets from 729 to 338, considering the same period of the year. This result is significant as it relieves the burden on the support team, which felt overwhelmed, and also reduces costs by avoiding unnecessary ticket openings.

Positive impacts of the delivery were noticed in the customer base and the company’s main Key Accounts, as evidenced by the positive feedback received.

With users spending less time trying to understand the final payment values, we observed a reduction of up to 1 minute in the conversion rate in payment flows.

Next Steps

Structural corrections are still needed in payment flows to simplify the journey, ensuring that users understand why there is an anticipation cost for that transaction.

Another area for improvement is the integration of these transactions into the customer’s statement. This was an aspect that was not prioritized due to high development costs, but it is considered a valuable feature for users.

In the coming months, metrics will continue to be monitored to assess if the scenario remains the same.

Conclusion

In this project, I emphasize the importance of seeking information and communicating with the right people. This helped to better understand the issues. Hearing directly from customers about how the problems affect them was essential for the project’s success.

Design is made for people. A product is only truly successful when all involved are satisfied; it’s never just about business.