Tinkoff Junior is a banking app and a card for kids from 7 to 14 y.o. with 600K users as of March 2021. It’s the first and, for a long time, only banking app in Russia designed especially for kids.

Kids are really into all things tech and want to be like adults in many ways. For example, to use contactless payments. But adding a card to the Apple Wallet or Google Pay can be a stretch for a young user, especially given that payment services have kid-specific rules and restrictions.

Luckily, Tinkoff Junior has an AI-powered chatbot to guide kids through the process.

We had a basic chatbot scenario answering questions like "Can I pay with my phone?" "How do I add a card to my phone?" etc. Under the hood, we tried to identify the operating system of the device the kid was writing from and provide them with an OS-specific answer (which remained pretty generic, though).

For example, if we learned that the kid had an iPhone, the chatbot came up with the following: "Go to the 'Main,' choose the card, and tap the 'Add to Apple Wallet' button."

Approximately 35% of all dialogs ended in chatbot-to-human handoff (and these were only the cases when kids made it clear that the chatbot’s answer was ineffective).

We strived to reduce the share of chats ending in chatbot-to-human handoffs and provide kids with more relevant answers.

In this project, not only was I a conversation designer, but I also had to take a deep dive into user research and analysis.

Conducting AI-chatbots UX research is a challenging task. In most cases, you can’t just follow the pre-arranged plan because everything changes unpredictably once a respondent chooses a different phrasing and triggers some other intent, not the one you planned to look into. If your respondents are kids, double or triple these unforeseen issues.

Luckily, we had artifacts — chat logs. I read dozens of them and thus discovered some typical problems kids faced trying to implement the bot’s instructions.

In most cases, they couldn’t add the card to the wallet because of Apple’s and Google’s age restrictions or problems with the card itself.

Another case worth noticing was kids with Huawei and Honor phones. These are Android-based phones, so the bot provided instructions for Google Pay. However, Google services were not available on Huawei and Honor phones because of U.S. business restrictions against China. Meanwhile, this was a frequent case because Huawei and Honor phones are usually the first choice for kids in Russia as they are cheap.

Our chatbot is a complex system that interacts with several banking databases and can dig out lots of information about the user and their device. E.g., we could check under the hood:

• The kid’s age. We needed this to see if the kid is old enough to be using mobile wallets according to the providers’ rules. E.g., to use Apple Pay, a person should be at least 13 y.o., Google Pay — 16. The age threshold depends on the region.
• The brand of the device. Thus, not only could we learn the device's OS, but we could also distinguish Huawei and Honor users not to give them irrelevant instructions on Google Pay. But we had a blank spot there: we couldn’t identify the very model of the device, so we didn’t know for sure if the kid’s phone supports NFC. We took the risk and assumed it supported.
• The OS of the device. Thus, we could provide the kid with at least an OS-specific answer in case the brand check fails.

Not to pull back the curtain too much, I’ll say that sometimes kids can’t use their cards at full because of compliance, security, and other restrictions. For example, if the card was frozen or blocked. Also, as it was the parent who issued the card, some problems could occur if the parent’s accounts were not OK. What's more, when adding the card, the kid had to confirm the action only via SMS, not push — otherwise, it just didn’t work out.

Apple Pay and Google Pay were the most popular payment services in Russia, nonetheless suited not everyone — take the Honor and Huawei users I’ve mentioned above. I had to think of alternatives to offer. Luckily, we had a local substitute — Cardsmobile Pay by Cardsmobile, the app for storing and issuing loyalty program cards.

Also, I considered that kids wanted to use wearables such as Apple Watch or Samsung Watch.

Long story short, I came up with the following list of payment services to cover in the scenario:

• Apple Pay
• Google Pay
• Cardsmobile Pay
• Samsung Pay

Once the groundwork was done, I was off for the sweetest part.

A "happy path," in our case, would be more of a "happy step": a kid writes a message, we successfully run all the checks (age, OS, card status, etc.) under the hood, and provide the most relevant answer.

1. First, we checked the card status and other banking stuff. Thus, we shortened the unhappy path for the kid: if anything was wrong at this step, they couldn’t do anything about it and had to reach out for their parent’s help.
2. Then we checked if the kid specified the payment service ("How to add a card to Wallet") or asked a general question ("How to pay with a phone").
3.1. If payment service was specified, we checked if the kid was old enough to use it.
3.1.a. If the kid was old enough, we provided guidelines on adding the card.
3.1.b. If the kid was too young, we told them that it was impossible to add the card.
3.2. If the payment service wasn’t specified, we tried to figure out the brand of the phone. If we failed — we checked at least the OS of the device. Thus, we got a set of payment services available tech-wise. Then, we checked the kid's age, picked out only the services they could use, and provided the guidelines. Or told that the kid was too young.

At each step, I had to think of unhappy turns and how to get the user back on track. I added clarifying questions and chips. Also, I necessarily named the device's brand or OS as we had recognized it — thus, the kid would be able to understand whether the answer was appropriate. I also added a "Not [brand-name]" chip so that the kid could choose the right one and get help no matter what.

I used Diagrams.net to communicate my ideas to developers.

Having checked that everything was feasible tech-wise, I started working on the texts. They had to be friendly, simple, and short, as kids from 7 to 10 have a short attention span — about 15-20 minutes. Taking cognitive load, this window of opportunity was even less. Ideally, the whole scenario — including asking parents for help if needed — should’ve fitted into this period.

Here are some examples of conversations between kids and the chatbot.

Branching the scenario out and enriching it with under-the-hood magic helped us reduce the number of handoffs by approx 10%. What’s more, we got no negative feedback. On the contrary, kids were down with it and often surprised at how clever the bot was. Bot guessing the brand of the phone produced a wow effect.

We decided to reuse this approach in further scenarios refactoring.