One working day, a customer service manager wrote to the corporate messenger channel that he had received feedback from a user:

A landing party of competent employees immediately landed in the discussion of the problem with information about what needs to be done and how to help the user, and in general to explain the situation to each other, what is happening. This is where the problem originates, the solution to which stretched out over several weeks.

Below is the process of how we managed to make a decision to increase conversion and simply make the lives of users more convenient and the company's income a little more.

So, all those competent people who wrote in the discussion about what the user should do, of course, gave important information, but every time in each specific situation, describing to the complainers what needs to be done is not good. Moreover, 2 out of 10 users, if not 1, do not go to support at all. After this, most simply leave the site. And this is not to mention the fact that many leave even before they get to the trash.

And then one day the CEO came with a hypothesis that this problem has roots and now we are losing customers. Let's test this hypothesis and make a fix that will allow us to improve the user experience and, what is no less important, the conversion. No sooner said than done, let's go!

We organized a team sync and delved into the problem in more detail. What's going on?

When paying in the cart, users get errors that indicate that the payment system did not accept the card. Moreover, the error is not informative - it says that "the system rejected the payment". Of course, the user is angry, he does not understand why this happened, and simply leaves or goes to the support service, but this is rare.

We caught the focus on a specific example: a user from Kazakhstan wants to buy a product in Russia. That is, the user, physically located in Kazakhstan, changes the location on the site and selects a delivery address in Russia. Since the location was KZ by id, and therefore the currency of his version of the site was displayed in the local currency - Tenge. After changing the delivery address - Russia, the user's currency changed from Tenge to Rubles.

As a rule, the mechanism should work under the hood of the service. And no matter what card the buyer enters, the service should count it and write off funds at the internal rate and, of course, the buyer does not pay attention to the change in currency. He is sure that he will be able to use his Tenge card and the required order amount will be debited from him via internal conversion.

The user enters his card details or it is already linked in his personal account and clicks pay. And then an error occurs! The problem is in the change of location and the currency assigned to this location and which payment system services this currency!

After he has caught the error, he just needs to go to the footer and change the currency to the one in which he has a card (unless of course he has a ruble one). But we remember the principle of don't make me think. Actually, that's why we decided to add an improvement. The case also works in the opposite direction. When a user from Russia wants to buy something in Kazakhstan, he also wants to buy with a ruble card and enters the data into the currency payment system, as a result of which the card and the payment system are not matched, the user catches the error. We lose the client

We identified the most important points in the information received, synchronized with the analyst, how we would measure the result before and after, to see how much we would improve the result and whether we would improve it at all.

Since this problem in the payment system is displayed as an error with a specific number, by this parameter we will be able to measure the result of our work after implementing the feature, whether there will be fewer of these errors and how it will affect the conversion.

We took a break and went to prepare sketches, according to the proposed solution to this problem. We wrote down the flow to understand where the user encounters the problem and take into account all the break points. After that, we had another meeting with the mobile team, discussed our current solutions with them, synchronized and went to collect the first concepts

Option 1
In discussing the first concept, we came to the conclusion that the user, in principle, does not really care what currency the conversion on the site is done through. He has already agreed with the price and has already clicked pay. He needs the payment to go through, and if an error occurs, then there should be a quick solution at hand. That is why our first concept was to display a model window with a choice of card in the event that the payment system and his original card do not match.

Retro
We conducted a usability test on several respondents and found out that it is not very convenient to cancel the cart by going to another window. A little stress for the user and unwanted extra actions. There are already a lot of extra clicks in the payment process that should not be there. So we went on to think further.

Option 2

With the second concept, we took into account the mistakes of the first one and, as we found out after conducting a small survey, it is still important for people to see what currency they need to choose. In addition, as we understood earlier, exiting the cart to another window is unnecessary stress for the user. Therefore, we decided to place the currency selection buttons directly in the cart at the moment of payment error.

By the way, when we were working on the user flow, we discussed that it would be generally not bad to have the ability to notify the user at the moment of changing the location (choosing the delivery address), that such and such currencies are allowed as payment at this delivery address. But for now this task has gone to the backlog

Retro: This concept worked better, but it had some other problems. The pattern was not quite familiar to the user - choosing a currency via small radio buttons. The user did not think to click the payment button after clicking on the radio button. Usually there is something like an Apply button, but ours was Pay. This was a bit confusing, so we went on to refine this concept.

Option 3
In the 3rd concept, we took into account the feedback from previous options and decided to replace the small radio buttons with regular buttons. At the same time, we decided that these same buttons would be some kind of switches that would quickly reload the page for the user and bring him exactly here the payment system that his card is suitable for.

Yes, of course, there is one small inconvenience here in that the card data will still have to be entered again, since the payment systems are not connected to each other and, of course, the data is not transmitted

The third concept satisfied everyone and gave the most positive testing results, after which it went into development. During the development process, we also encountered a problem that could break all our previously achieved results, namely, we ran into the fact that the payment system could not give us a custom error text. It had its own default, and we thought that this would break everything for us. But later our wonderful guys from the back and front teamed up and were able to solve this problem.

A week after the update was launched, we received the first positive news. The number of errors in the payment system was much lower. And the payment system also displayed data that the conversion rate increased by 1.8. And this is only the first week. We did not roll out the update to other payment systems. And since the service has 4 of them and all had the same problem, this method proved its effectiveness and we went to implement it on the rest

I will tell you about the implementation results in the following posts, if this post shows its effectiveness and it will be interesting to you, visitors of my site. And in conclusion of this post, I would like to add screenshots from the chat, which were a certain point in the first segment of a large complex task, which at first glance looked very easy. But in the process we carried out a rather deep and serious stage of work, thanks to which we can apply a similar approach to other payment systems