Reframing a Niche 2FA Tool into a Mainstream Login Method
In this case study, I’ll show how I helped transform a niche security tool into a clear, trusted, and scalable login experience for millions of users.
To comply with my NDA, some details have been changed. The information in this case study is my own and does not necessarily reflect the views of Yandex.
Overview
Yandex ID as a part of Yandex Fintech provides authentication and identification services for all Yandex products. By 2025, the login process still relied heavily on SMS, which is an expensive and unreliable method on a Yandex scale.
Meanwhile, Yandex Key was a small tool used mostly by tech-savvy employees and early adopters. This audience was no longer strategically important to the company, while two new mainstream user segments — everyday users without paid options and profitable users with multiple accounts and subscriptions — were completely underserved.
The team made a strategic decision to turn Yandex Key into the primary login solution for millions of users under the new Yandex ID brand.
The goal was to increase adoption of app-based login and reduce the company’s reliance on costly SMS verification.
My Role
I led the content creation for all communication channels, including product interfaces, marketing and promotion in stores, ASO, onboarding and the help centre. This ensured a consistent and clear flow, as if it were a one-to-one human dialogue.
I collaborated closely with a small, engaged team comprising a designer, a product manager, a marketing specialist and a UX researcher.
My mission was to develop new communication principles through all idendity flows and on all surfaces.
??????
The Challenge
The core challenge had four layers:
The product was designed for the wrong audience. The previous core segment (tech-savvy employees) had lost its strategic value. However, the app still spoke exclusively to this audience, using jargon and system terms.
We now needed to serve three very different audiences:
- ordinary users (mainstream login),
- families and multi-account users,
- remaining advanced users who depended on TOTP codes.
The old language did not work for two of these groups.
The flow was too technical even if address to . It begins on one device, and continue on the other. It used a lot The terms were messy and wordy. '2FA', 'OTP', 'verification codes', 'one-time passwords' - four terms for one thing.
Users weren’t convinced that they needed an app instead of SMS.
Adoption required lowering cognitive barriers. Trust had to be earned through clarity. Identity is high-stakes: one confusing screen is enough to lose a user. This was not a “copy refresh”. It was a complete reimagining of the app.
My Approach
I treated language as a strategic tool, not just for decoration.
1. Benchmarking the industry:
I researched both Authenticator Apps like Google Authenticator, Apple Passwords, and end services like Dropbox, Gosuslugi and Mos.ru, among others.
Every day, millions of ordinary people in Russia use Gosuslugi, a leading state service, to communicate with the government.
Here are some of my insights:
Leaders avoid technical jargon.
They use one consistent term ('code'), not four.
They communicate convenience first and security second.
Process
Step 1 Understanding of the task
I started with empathy.
I used to run an online store myself, so I know firsthand how stressful it can be when something goes wrong during peak season. That experience helped me see business partners not as abstract “users,” but as people whose revenue depends on clarity and reliability.
Before making any changes, I studied how leading fintech platforms named and described their features — looking for natural, familiar terminology that business owners would immediately recognize.
Then I reviewed all active and in-development services, collecting texts from Figma, dashboards, and partner documentation to build a complete picture of the communication landscape.
Step 2 Finding problems and misunderstandings
Once I understood the context, I analyzed how partners interacted with each service — from setup and connection flows to payment and tipping modules.
I looked for places where wording or structure caused hesitation, errors, or unnecessary support requests.
The patterns became clear quickly:
Actions were described inconsistently — Connect, Activate, Turn on.
Confirmation dialogs were vague — users weren’t sure what would happen next.
Those inconsistencies weren’t cosmetic — they created real business risks.
A partner could disable a module by accident and lose payments for hours or days.
That insight became the starting point for building a unified and predictable communication system.
I’ve been in that situation myself — when one vague setting cost me a weekend of lost sales. That’s why I’m obsessed with making sure every word in a business interface works as clearly as a switch: on means on, off means off.
Step 3 Crafting clarity and confidence
Once the core problems were defined, I focused on rebuilding confidence into every interaction.
My goal wasn’t just to make things clear — it was to make them feel trustworthy.
I reviewed all texts — buttons, warnings, tooltips, and settings — and created a shared system where each term had one unambiguous meaning.
Unified key actions: simplified activation and management verbs across all services.
Improved confirmations: replaced vague prompts like “Are you sure you want to remove this service?” with calm, confident phrasing — “Delete service X?”
Consistent microcopy patterns: aligned the tone and structure of toggles, modals, and alerts so that partners always knew what to expect.
Clear and coherent messages prevent any misclicks
I wanted the interface to sound like a competent colleague — calm, clear, and never in a hurry. Someone who earns trust, not demands it.
Step 4. Scaling clarity
To make the new system sustainable, I documented the key patterns and created compact writing guides for designers and developers.
I worked with engineers to standardize message keys for recurring states (errors, validations, confirmations) and ensured that new products would automatically follow the same logic.
I also added these principles to our internal wiki — turning ad-hoc writing into a reusable system.
Impact
The results were immediate and long-lasting:
New services started using consistent language without additional help.
Cross-team misunderstandings decreased.
Partner onboarding became smoother and required less support.
The platform began to sound and feel cohesive, even as the product lineup kept expanding.
Reflection
This project reminded me that language is infrastructure. When it’s clear and consistent, everything else moves faster.
UX writing in B2B fintech isn’t about “pretty words” — it’s about trust, predictability, and risk reduction.
And the real success is when teams start using your principles naturally, without even realizing it.
