Context
Pushes are how a bank reaches a client cheaply and reliably.
I'm a senior product designer in the channel-apps team inside the notifications cluster at VTB. In plain terms — I own how a client enables, disables and generally interacts with notifications inside the VTB mobile bank.
The cluster raises push penetration. More clients on pushes and fewer on SMS means lower costs — SMS are expensive, pushes are practically free, so the strategy is to move communications to pushes wherever we can.
Sounds simple, but there are a lot of obstacles on the way. One of them — an inconvenient enablement flow — is what I took on.
Where the task came from
“Optimize the client paths for enabling pushes — somehow.”
The brief from leadership was that broad. The bank had a course to maximally move away from SMS — clients had to be able to enable pushes faster and easier.
I set up a meeting with my team lead and sat down to write the task understanding.
Mission: simplify enabling and disabling pushes. At the time a user had to deal with two different toggles in two different places — granting OS permission, plus a separate in-app toggle inside the VTB app.
Business goal: raise push penetration across VTB Online users. Higher penetration → lower SMS spend.
Audience: VTB's active client base. We support Android (native app) and iOS PWA (no native iOS app yet, but pushes work through the web shortcut).
Success criterion: growth of the share of users with pushes enabled.
Discovery
The worst-case path was 7 steps long.
I mapped every client path. A user has four starting states with respect to pushes, and I walked through every transition between them — that's where I found the bottleneck.
The longest path looked like this: 1) once at onboarding the client granted push permission; 2) enabled it in the bank via the internal toggle; 3) later turned pushes off in the OS settings (intentionally or by accident); 4) at some point wants pushes back on.
In that scenario enabling took 7 steps. Seven.
Then I looked at how others solved it — neighboring banks and broader best practice. The observation was simple: the fewer toggles you have, and the tighter they sit with the OS, the clearer it is for the user. Our two-level system felt like a rudiment that could be cut down a lot.
Hypothesis
Remove the internal toggle. Mirror the system setting.
If we drop the internal toggle and reflect the OS notification permission directly inside the app, the user always sees the actual push status and can jump into system settings with one tap to switch it on or off.
The 7-step flow collapses to 4 — almost half the length.
Lo-fi and selling the solution
Lo-fi prototypes, picked the working variants with the team, defended with leadership.
I went through where to place the status, how to phrase the jump into settings, what to show in the enabled state (like the list of devices), and how to handle the case where pushes are already allowed.
Together with the team we picked the working variants. I prepared slides and presented to the cluster's leadership. It went smoothly — the solution was obviously logical, no objections. Then on to hi-fi and handoff.
Hi-fi: three states
Designed the “Notification methods” screen for every realistic state.
Pushes disabled at the OS level — show a banner “Notifications disabled” with a link “How to enable” (on iOS PWA) or a button “Open settings” (on Android, where the deep link is supported).
Pushes enabled — status “Notifications enabled”, a list of connected devices with the current one marked, plus a “How to disable” link.
Android is the straightforward path: tap the button, land in system settings for the app, flip the toggle, return, status updates.
iOS PWA: separate case
Safari blocks deep-links to system settings. So we wrote the route out, plainly.
On iOS PWA you can't deep-link into system settings — it's a Safari restriction with no workaround.
Instead of an “Open settings” button we show “How to enable.” Tapping it opens a bottom sheet with step-by-step instructions: open phone Settings → Apps, pick VTB Online, tap Notifications and allow them.
From there the user reaches the system layer themselves, flips “Allow Notifications”, comes back. Not perfect — one or two taps longer than on Android — but honest: we say plainly what to tap.
Release & an unexpected case
Some users were quietly moved from SMS to pushes — and complained.
We rolled out to a small slice of users. Some had pushes allowed in the OS but disabled by the bank's internal toggle. For them the new logic read: allowed at OS level → pushes go through. They were automatically moved from SMS to pushes.
Tickets started coming in: “I used to get everything by SMS. Now I'm suddenly getting pushes. Did I do something wrong?”
From the business side — this was exactly what we wanted. From the user's side — product behavior changed without warning.
Results
Push penetration is up. Support load for this flow is visibly down.
The solution is still rolled out to a partial audience, so final stat-significant numbers aren't in yet. But the early signals are encouraging: push enablement is up, complaints about the enablement flow have dropped noticeably, and the new class of complaints (the silent SMS→push migration) is a signal for a targeted follow-up, not a rollback.
The main thing: the flow really did become 1.5–2× shorter, and it shows in the product.
My role
End to end: from task understanding through hi-fi and post-release iteration.
Task understanding and alignment with the PO. Analyzing client paths and states, finding bottlenecks. Competitor and best-practice benchmarking. Lo-fi hypotheses and design. Selling the solution to leadership. Hi-fi for three platforms (Android, iOS PWA). Handoff and design review. Post-release metric tracking. Triage of user complaints and writing follow-up design tickets.
Lessons
Knowing about a segment is not the same as having designed for them.
1. We knew there was a segment with OS-level pushes allowed but the in-app toggle off. We knew they'd be auto-migrated. We decided it would slip by quietly. It didn't. Lesson: when the change is meaningful for an audience, design not just the tech, but also the way you tell them — even when the change is technically right.
2. Phased rollout saves you. If we had shipped to 100% on day one we'd have had thousands of tickets instead of dozens. The partial rollout gave us time to notice the case, understand it and think calmly about the fix.
3. Constraints can always be softened. iOS PWA couldn't deep-link to settings. When you can't make it “like everywhere else,” sometimes the right move is to honestly tell the user where to tap. Not ideal, but better than a wall.
What's next
Full 100% rollout, stat-significant metrics, explicit notice for channel-changers.
Finish the rollout, collect stat-significant metrics, and design an explicit notice for users whose channel changes after the migration.