Context
Buying a used car, a phone or a service from a stranger means someone has to trust first. Safe Deal removes that: the bank keeps the buyer’s money until the deal is done
The product didn’t exist before May 2026. It was one of the cluster’s largest initiatives, announced by the bank’s executive directors, with three product teams contributing their own deal types. The first version went live in September 2026
My part
Each product designer owned the deal flows for their own product. I owned the shared layer around them:
- entry points: how people find Safe Deal in the app, through search and the services catalogue;
- the onboarding page for people with no deals yet;
- the choice of deal type: goods, services, car or real estate;
- the deal registry, its card and its state model;
- service availability states, with known and unknown recovery time
Everything in my scope shipped in the first release. Nothing was cut from the MVP
The registry problem
Designing the registry started with questions: who will use the first version, how many deals will they have, and on which side? I met with business and the research team to find out who we were launching for. The answers became the requirements:
- One person can be a buyer and a seller at the same time
- Deals on both sides move through four stages: applications, active, suspended, closed
- A seller may have dozens of near-identical deals, for example 100 of the same item
The registry had to show all of this compactly, let people recognise a specific deal and its status at a glance, and avoid turning into an endless scroll
Constraints
- New architecture. Safe Deal is the first product in the Sber mobile app built entirely on web widgets that update independently of app releases, while staying within the clean, consistent look of the design system. Nobody had shipped on it before, so every UI decision had to be checked with frontend
- Design system review. Each direction went through the design system team
- Data from three products. The registry card shows data from deal pages owned by other designers, so I had to agree what the backend passes into a shared card
Exploring the structure
I started with four structures for the registry, then added more once the widget constraints became clear. Each round went business → engineering → business → design system review
Header tabs lost to a platform constraint. The deal card was already a customised design system widget, and the Web Widgets environment allows only one frontend customisation: a second one for the tabs would have been impossible to support on the backend. So I moved the buyer and seller roles inside each stage widget, and a person who is both sees all their deals in one list
The deal card
I first explored the card freely, without design system limits. Then I deliberately went the other way and built it on an existing design system widget, originally made for selling products. A custom card would have cost more to build and maintain across independently updated widgets
That widget had no status model, so I added one, and checked with frontend that the HTML and CSS could be adapted without breaking the base component
What the card shows
I chose the attributes myself, designing for the case of many similar deals, and then presented them to business and research with the reasoning for why this set would work best:
- Title depends on category. Goods: the item name. Services: the description, and the creation flow nudges people to make the first two or three words distinctive. Cars: the licence plate first, then the model
- Price on the right of the first line
- Counterparty: phone number, first name and surname initial
- Status, colour-coded, and a category icon
I also agreed with the other product designers which data and statuses pass from their deal pages into the shared card, so a deal can be identified and understood from the list alone
Before the first deal
Someone opening Safe Deal for the first time has no deals. Instead of an empty registry they see an onboarding page: what Safe Deal is, how it protects money, that it’s free and how it works. I chose the content with the marketing team, picking what matters most to a first-time user
From there, starting a deal leads to the deal type choice, which hands over to the right product’s flow
Outcome
The product launched days ago, so there’s no usage data yet worth showing. I’ll be tracking entries into the product, the move from onboarding to a first deal, and the number of deals created