Context
We build the bank's unified notification platform.
Through this platform clients receive SMS, pushes and other messages — about payments, transfers and other important events.
The goal is a single notification platform that guarantees reliable delivery and a unified message standard.
What is the constructor
It's where notification texts are composed for every channel — SMS, push and more.
Previously templates were assembled in code; mostly only people with strong technical backgrounds could work with them.
Now there's a usable constructor: configure a template through a simple form, or open the code editor when you need it. People without deep technical skills can now work with notifications.
The bank gets a unified message standard, fewer template authoring errors, and the ability to scale new notification scenarios faster.
Problem
Old legacy interfaces were clunky, error-prone and slowed feature rollout.
The bank decided to migrate services onto the new Omni UI design system and refresh interfaces along the way.
Task
Rework the form support staff use to author SMS, push and rich-push messages.
Audience: about 50 support-team staff across different departments, including support lines.
Mission: make working with templates clearer and faster, cut errors, and improve the interface.
Business goal: a seamless migration of every notification service to the new platform, unified through the design system.
Success criteria: faster template authoring; every service successfully migrated; positive feedback from staff (internal surveys + demo sessions).
Discovery
Interviews and demos with the support team — fields were overloaded, errors regular.
I started with the current template form and the support-team workflows.
Ran interviews and demo sessions with users to find where the form gets in the way. Collected feedback: fields were overloaded and template-authoring errors happened regularly.
Analyzed the legacy system's constraints and the business request to unify around the new Omni UI.
How a notification is assembled
Raw data → template transformation → clear text for the client.
1) Raw data is taken — amount, balance, card number.
2) The transformation template turns that data into readable text.
3) The client sees a clear notification on the phone: “1,050.50 ₽ debited from card *4977. Balance: 251.51 ₽”.
Hypotheses & rough mocks
Two big bets: a form-style constructor, and structuring push parameters visually.
I dug into how admin UIs are structured (Mobbin benchmarking) and sketched the possible shape of the new form.
Hypothesis 1: The current solution is too technical, mostly accessible to engineers. A form-style constructor with push parameters surfaced as fields would let support staff author templates faster without diving into code.
Hypothesis 2: If the constructor's UI mirrors what a push actually looks like (title, description, image, button with deeplink) plus a visual preview, staff orient faster and need fewer clarifications.
Prioritization
Value ÷ effort. Modes (form + code editor) won the first iteration.
Form + code editor mode had high value at moderate effort. We took it first.
For the second hypothesis we kept just the structured form (title, description, image, buttons). The visual preview itself was tabled — engineering cost was too high for round one.
Scoping
MVP scope: new field grouping, basic hints/validation, design-system integration.
More complex improvements — advanced template search, change history — were pushed to later releases.
First iteration
Drawer-form prototype in Figma. Demo with support. Implementation audit.
Studied every Omni UI guideline. Built clickable Figma prototypes of the new form inside the design system. Ran a demo with support staff and collected feedback.
After handoff I audited the implementation on staging: fields, statuses, alignment with the rest of the admin's scenario logic.
First launch & the Drawer problem
Authoring long copy inside a side-panel didn't work. We switched to a full page.
After the first test-environment release the feedback was: working in a side panel is painful — you can't see all fields when editing long copy.
The design system pattern said Drawer was the right shape for these scenarios — but the real experience said otherwise. I raised it with the design-system team and we agreed to evolve the pattern: full-page form instead of drawer.
Results
Shipped to production. Faster authoring, fewer errors, positive stakeholder feedback.
The redesign shipped successfully: staff noted the form felt noticeably more usable and faster; every service migrated off legacy; template errors dropped; stakeholders gave positive feedback.
Every success criterion met — staff work more efficiently, the business has a stable, scalable tool.
My role
Sole designer — full cycle: research → design → DS alignment → implementation audit.
Beyond the mocks themselves, I owned user/stakeholder meetings and pushed change-arguments through the design-system team.
Lessons
Even guideline-blessed components need a real-usability check.
End-user feedback often surfaces problems analytics can't.
Build iteration time into the plan, and be ready to push back when the change improves usability.