Building a B2B Payment solution ecossystem
A story about complex problems, unpredictable paths, resilience, and hard-earned success.
*The prototype screens should appear in Portuguese, as it is a Brazilian product.
First, a brief reflection on design processes
Since I began my career transition to UX/Product Design in 2020, all the design gurus and playbooks guided beginners towards the same goal: finding their own design process, based on the many frameworks available in the market to create a linear storytelling of discovery, definition, ideation, and delivery (with their variations and cyclical movements between stages).
I won’t say that this is a wrong way of thinking, as this method worked well at the beginning of my career, helping me to master the tools at a time when pressure and responsibilities were lower, had more available time, and information, problems and demands came to me in a more structured way — most of the time, the final deliverable was somewhat clear and predictable even before the process began.
However, as I matured as a designer, dealing with more complex projects and balancing the 9–5 job with freelance projects, I realized that the reality of a designer is much more about being aware and choosing the tools or activities that help to understand and better expose the uncertainties that arise at every moment, than believing that a rigid process will remain constant and replicable for any project.
Being a designer is about having resilience to find the creativity to suggest paths and clarify trade-offs during moments of doubt and delivery pressure.
I will try to exemplify some of this reflection throughout this case.
About the Challenge
After a few months working in the team responsible for acquiring and onboarding retailers at Tino, I was tasked with creating a payment interface to be the flagship product of the company, using technology integrated into suppliers’ e-commerce platforms with the primary goal of increasing conversion (between signing up and completing a purchase using Tino), which was around 40%.
In general, Tino is a startup that operates in transactions between retailers and suppliers (B2B), with the value proposition of ensuring more flexibility for the buyer and, consequently, boosting the sales of the supplier.
There are many constraints when the business is small, so it is crucial in this market to ensure more compliance, better cost, and provide more possibilities for SMEs.
This is where Tino’s business model comes in: the retailer uses credit to make purchases, pays in installments via boleto — a kind of brazilian bank slip, and the supplier has the guarantee of receiving payment on time.
However, the company’s more user-centric solutions were much more linked to the final payment stage than to the initial stage of choosing the payment method in the purchasing journey itself.
We found ourselves in a scenario where the retailer had little or no visibility about Tino, often thinking the available credit was from the supplier itself, and not understanding that it was provided by Tino. (Not even knowing that Tino existed, to be honest).
On the other hand, the supplier had full control over the shopping experience, which depended 100% on their autonomy (and goodwill) to educate about Tino or facilitate their journey.
Deep dive
I needed to better understand how to materialize this solution, first exposing the intricacies of this purchase flow to find the main pain points and behavior patterns (of the user, the supplier, and our internal system).
After many discussions and a relentless search for needles in the haystack of existing documentation, it was possible to realize that the problem was much more complex than I had imagined.
First, we found several entry points in the Tino flow, with two main relevant purchasing journeys, each with its operational specificities:
The online purchasing journey, where the retailer selects the option to pay with Tino credit at the supplier’s e-commerce checkout and goes through almost 8 steps to complete an initial purchase and 12 more steps to complete their registration and finalize the payment of the order.
The offline purchasing journey, where the retailer receives a visit/call from a salesperson, places the order, and if they choose Tino credit, the salesperson completes the purchase, leaving us with the only task of sending the final boletos.
Additionally, retailers are companies, so they have a group of internal personas (owner, sales, financial, and purchasing) each with their own permissions and responsabilities that often intersect because they are mostly small companies that share their functions, but legally they need a series of bureaucracies to operate on behalf of the company and go through the Tino flows.
Considering only this fragment, we can already highlight very strong problems, such as:
- Current flow full of manual processes and daily incidents;
- Issues with purchase approval/confirmation and receipt of payment bills;
- Narrative inconsistencies with a broken experience throughout the journey;
- Lack of awareness, identity, and reliability in the brand;
- Lack of control over retailer payment preferences and experience;
- Lack of visibility on internal operations and retailer personas.
Amongst other problems that are so important and complex that they would deserve a dedicated case just for them — but let’s consider here that all problems outside the scope of the purchase have been addressed to equivalent contexts (such as onboarding stages, legal issues, credit analysis, final payments, business rules, etc).
Vision and business premises
With this arsenal in hand, we started to raise some hypotheses that could help us visualize solution opportunities, also considering the remaining flows that directly or indirectly impacted the purchase journey, but didn’t necessarily need to be part of it for all use cases.
After some chats with customers, stakeholders, benchmarks, dynamics, and internal iterations, some of these hypotheses were turned into product premises that helped guide the solution aligned with business goals:
- Modularity: By modularizing the experience, we create consistency in the narrative, regardless of the entry channel and the merchant’s status, increasing conversion.
- Omnichannel: Allowing access to the payment method through multiple channels engages the merchant in both journeys and can contribute to usage, conversion, and activation.
- Enchantment: Reinforcing the brand identity increases reliability and contributes to choosing Tino as a payment method, increasing conversion.
With a few ideas in mind, it was now time to get to work.
Modularity: Marauder’s Map
The first step was to question what was absolutely necessary for the user to be able to complete their task in any usage scenario.
Starting with the happy paths, and digging into each of them to find edge cases and raise discussions, we mapped out some steps, elements, and processes that should happen and others that we would like to happen to complete the user experience.
This was a very important step to define the roadmap and prioritize what would be worked on at each moment in synergy with other teams to achieve a common goal, since this was a multidisciplinary project that involved almost all teams in the company.
I dubbed the studies of these flows the Marauder’s Map, in analogy to the rooms and corridors at Hogwarts so we could know exactly where to find the customer at each moment of the journey.
These studies gradually provided visibility on which modules should be included throughout the customer’s journey (beyond the purchase flow itself), and helped us map out some risks, blockers, and priorities for action at each stage.
However, it was used more by designers than by any other area of the company, which made updating and ensuring alignment across teams very difficult, especially at a time when the organization was constantly changing and there was no defined holistic view of the product company-wide.
Omnichannel: Google like
To address the initiative of promoting consistency in the experience, regardless of the entry channel, we proposed an experience like the Login with Google: a responsive web interface to which the user would be directed when (1) choosing Tino as the payment method at the supplier’s checkout, in the online purchase journey and (2) by clicking on the payment link they would receive from the salesperson via whatsapp or email, in the offline purchase flow.
This solution would allow us to scale and evolve to even more channels (integrated or not), and would give us control over the entire navigation flow until the purchase was completed, allowing us to monitor, standardize and test multiple scenarios.
It took a lot of alignment, especially with engineering and product, to understand the business expectations and the technical limitations that could occur during the process.
Enchantment: 2-click payment method
After experimenting design with a lot of possibilities and facilitating many iterations and critiques, we decided to go ahead with an MVP conducting the user to perform their tasks in 2 simple clicks:
- Select the payment plan and number of installments they want to split the purchase into;
- Check the due dates of the installments and confirm the order.
Each task would act as a solution to an existing pain point for the customer, who sometimes prefers to split the amount into smaller payments and, depending on the amount, prefers to pay it all in one go.
It also gives the user visibility of the due dates they have chosen, which used to be at the mercy of the supplier’s invoicing time, making them often confused and frustrated.
This solution would also make it possible to adapt the content to the different deadlines set by suppliers, and could be used with any contract model, mimicking the busy routine of the customer, who wants the freedom to choose how to pay for their purchases as quickly as possible.
With no time to test the usability, our plan was to implement this MVP with one of our smaller suppliers, rolling it out little by little, starting with recurring heavy users, with some fakedoors in the payment plans to understand the real need for all the features and the usability of the screens before launching the official product, with all its complexities and parameterizations.
Looked like a good plan to put the product on the streets and see what happens.
But the path is not strewn with roses
All done and ready to go, we suddenly lost the contract with this supplier and the company articulated new strategies for launching, selling the product to one of our largest and most important suppliers. Nothing could go wrong with this one.
We had to rush to design and prepare the development of these adaptations, also aligning new dashboards with data team, since the product would have to work with a more complex technology and we would once again be relying on the supplier’s internal code to display our interface inside an iframe, without much control over how the layout would behave on different devices, which could hinder the user experience and take us back to where we started.
At the same time, we were building a new registration flow supposed to be embed in this experience in order to make Tino safely available to all customers, which was not ready due to it's internal data complexity and we would need to make sure that the experience could only be made available to verified users, otherwise the risk of exposure and possible fraud would be gigantic.
Go go power rangers
We rushed and tested the experience in guerrilla mode, accompanying salespeople on sales routes, without much user engagement, trying to quickly understand how to improve the product without significantly compromising the effort and development time that was already tight.
It was of the utmost importance to warn and align stakeholders about the trade-offs of lauching decisions, to mitigate security risks that could have an huge impact on the experience, as well as possibly serious incidents for our operation.
We made some small improvements to the interface, added a login step and what had been a fakedoor was transformed into a feature. A pilot that was supposed to serve as a test model for secure clients ended up becoming our launch product, robust and released for rollout.
My stomach churned and I was super nervous about launching the product, with no evidence that the interface was clear and intuitive enough to generate the engagement we were hoping for.
Fortunately, we won the first battle and started the rollout with heavy users, which at least mitigated the security risk that worried me beyond the experience, and we also ended up pushing the omnicanality to a later date.
The result
After a few months of monitoring and minor adjustments, we could see the results of our efforts: conversion went from 40% to 94% and we almost tripled the weekly TPV! We hit two business targets and we got to celebrate the product’s success with company happy hours.
We continued to monitor the metrics, make improvements and work on the other modules to take into account the various scenarios of customer use and there were still a lot to improve, but we set out on the path to achieve our vision of promoting a modular, multi-channeled and delightful experience for our customers.
It still appears difficult for customers to understand Tino, but today they can see that there is a separation between the payment method and the supplier, which is a major step forward in reinforcing our value proposition as a company for both our users personas.
Here’s a video of the product as it is so far in this case, with new features already evolving:
Learnings and reflection wrap-up
After so many anxious and nervous moments, there was a sense of relief when I realized that my designer’s feeling was in the right direction, but we can’t always rely on intuition.
As designers, we have to think in a systemic and analytical way and I learned a lot from this process about how to position yourself, clarify concerns, how to approach different teams and always place yourself as the guardian of the experience.
Having the resilience to make processes more flexible in the face of business changes, unforeseen events and new product parameters was fundamental to keep calm, look at the ecosystem as a whole to anticipate problems and use creativity to bring alternatives to solve those new problems that appear along the way.
It is also fundamental to reinforce the need to insert time for iterations and tests on roadmaps, before and after the launch of products and improvements, to prevent similar problems.
I used this mental model to build another of our products for suppliers, when we launched a very simple MVP for a few customers to test the product before spending a lot of time and effort developing a robust solution.
It was a much faster and less chaotic process to evolve the solution and it also made it possible to evolve the technology of our main purchase product around omnicanality.
To wrap up this reflection, it is important to acknowledge that we don’t design alone. We need to nurture relationships with the other experts involved in the product to raise concerns, possibilities and align expectations at every step, always relying on the efforts of each individual to achieve common goals.
Kudos to the entire Tino team for their initiatives and high level of problem-solving skills, and especially to my master and design leader Pedro Naif, who nurtured my confidence, helped me in times of doubt and always gave me the space and autonomy to create and think about design.
