Hi, my name is Alisher, I am a UI / UX designer in the Beeline Kazakhstan team. Our company makes a lot of products, but as it turned out, we don't tell much about it. Therefore, not so long ago we began to hold internal meetups: meetings at which we tell all colleagues about what we are doing. And now we decided to share our experience also outside.
My report at the internal UX / UI meetup received a great response from colleagues, so I decided to write about it here too. In this article I will tell you what UX research is and what it is for. Let me share when I think a company needs to hire a UX designer. And with an example I will show how Beeline Kazakhstan products are changing thanks to research.
What is it about?
UX research is analytics that helps to find out the user's needs, feelings and emotions. Thanks to research, we can understand what the user thinks about the product, how the site or application should work in his view. Why do users leave the site when the product is already in the cart, or why they "jump" from tariff to tariff every month.
Roughly speaking, UX research helps us to "get into the head" of the user in order to design the interface of the site and application as conveniently as possible.
So do all companies need UX researchers?
In an ideal world, yes. A UX researcher is needed at the very start of a company or before a product launch: you came up with an idea, assembled a prototype, connected a researcher and studied the opinion of users, and then launched. That is, research is best done at the stage of product formation, planning concepts and hypotheses.
But this is the ideal.
In reality, the researcher is most often involved in improving an already working product. For example, you launch an application, it functions well and covers all the needs of the user, but you need to scale. At this point, it's important to connect UX research to explore the customer journey, build a backlog for new product goals, and optimize whatever you can.
Research is also needed at the so-called post-design stage. Let's say the designers have worked out the functionality of the site or application and handed over the work to the developers, and they have developed and rolled out the design into production. But the work doesn't end there. We conduct research on new functionality or design, collect feedback, make sure that we did everything right, simplified life and did not create problems for the user. Well, or vice versa. If we complicate the user's life, then, based on the results of the study, we fix the problems.
How it works in practice
Problem
Users of Beeline Kazakhstan often complained that at the time of writing off the monthly fee under the tariff plan, they did not have or not enough money on their balance. If the tariff cannot be charged, the subscriber is automatically connected to one of the daily packages.
People were furious and complaining about the connection of the daily package. Someone said that they would switch to another operator, someone poured out anger on social networks. The situation is unpleasant, we do not want the user to have such problems.
Decision
Create the functionality of auto payment from the card. This solution was proposed by both the users themselves and the development team.
At the start, four important questions arose, on which we needed to test hypotheses and concerns.
- What logic of write-off will be convenient for the user?
- What time is the withdrawal from the card?
- How to call this section: auto payment, auto payment, or auto top-up.
- Where should the auto payment section be located in the “My Beeline” application?
Case 1. What option will be more convenient for you to automatically top up the balance for writing off the subscription fee?
Variants
Let's say the tariff plan costs 2,590 tenge, I have 2,000 tenge on my balance. The team had two options for solving the problem:
- we write off 590 tenge from the card, add to 2,000 on the balance, the tariff is paid at zero;
- we write off the full amount of the tariff (2 590 tenge) from the bank card, ignoring the amount of money on the balance.
In my opinion, this is the most interesting case in this problem. To be honest, my team and customers, we were confident that people would choose a fixed amount - it seemed more convenient to us. Despite how much money is already on the balance sheet, the full cost of the tariff is written off, conditional 2 590 tenge. This is convenient, because you know exactly what the write-off will take place, and what the amount is, where it came from.
We conducted a survey of users and it showed that 63% of 400 respondents choose the option to write off the missing amount. A frequent comment was: "If I need to buy something else, I will replenish the balance myself with the required amount."
Output
Imagine what would have happened if we hadn't done the research. We would have followed the team's script and made a fixed-sum replenishment. Spent a month on development, and only 37% of 200,000 subscribers would use this functionality. Now we are developing functionality that will be used by almost 70% of subscribers.
Case 2. When do you want to receive replenishment for an automatically configured payment?
Billing (invoicing the subscriber) takes place somewhere from 12 am to 6 am. The question remains: when to send people a notice of debit, and is it not better to debit money from the card the day before the bill is paid according to the tariff.
57% of respondents chose the date of payment of the tariff as the time of debiting money from the card. That is, if I have the day of writing off the amount according to the tariff on November 1, then a few hours before billing we will write off the missing amount from the card. At night, during billing, the payment will be debited from the subscriber's account and the plan will continue.
This way we close the problem of switching to a daily tariff and do not upset the user. And this is the main task.
Case 3. What to call this section: auto payment, auto payment or auto-top up?
The team thought the auto-pay option was the right name. But, after conducting a survey, we received controversial options: 46% "auto-replenishment" versus 42% "auto-payment". And, as you can imagine, almost no one chose "auto payment".
As a result, we are leaning towards the "auto-completion" option. It won by a slight margin, but during the research process, we received comments. Users say that after all, the process is to replenish the balance, and only then pay according to the tariff plan. Which is mechanically correct.
Case 4. Where should the auto payment section be located?
The research method we used was First click test or first click test. It helps to understand what the user associates with the understanding of the task and the navigation component.
The result of this test is a heat map. You can see user behavior on it: the larger and redder the dot on the screen, the more people clicked on this section. So we see that we have four "main sections" for users in the application: "Replenishment", "Go to account settings", "My tariff", "Payments".
My team and I were of the opinion that to set up auto payment, everyone would go to "Top-up" and "Payments". But we never assumed that people would go to the "My tariff" section in order to set up auto payment exactly there. Testing gave us food for thought, so now we are working on all the functionality based on its results.
If you still have questions about UX testing or our case - write in the comments, I will try to answer them.