Context
A letter of credit guarantees that a seller gets paid once agreed conditions are met. A subsidised one adds money from a government programme, for example housing support for a family
I joined Sber in April 2025 as the second designer on Letters of Credit. Business asked us to design the full lifecycle of the subsidised version: opening, amendment, closing, execution and subsidy discrepancies. The same business logic had to work in two internal systems, SBOL.pro and RM CPR, with different engineering teams and different design systems
Both systems and their design systems are under NDA, so no interface screens are shown here
The gap
Designing the opening flow, I hit a question the requirements didn’t answer
Customers came to a branch with a subsidy agreement in hand, but often didn’t know the exact name of their government programme. On the second step, the employee had to find that programme in a search field among about 250 names
The real question wasn’t how the selector should look. It was how an employee reads the customer’s document, what they type into search, and what they do when the document doesn’t make it obvious. No one had asked for research. I proposed it because guessing here would have shipped a step people couldn’t complete
Research setup
The research ran on the opening flow in SBOL.pro, the system branch staff use with the customer in front of them. Testing only experts would have hidden the problems newer staff face, so both groups took part. Prototypes covered happy paths and deliberately unclear situations, so I could watch what people actually did rather than ask what they thought of the interface
For each hypothesis I recorded the situation, observations per respondent and a conclusion, then compared the two groups and turned it into a findings deck for the team
What we found
Round 1, 9–10 July 2025, five employees: three who don’t work with subsidies and two who do
| Step | Result | Hypothesis |
|---|---|---|
| Finding the new product in the registry | 5/5 | Confirmed |
| Choosing the programme type | 5/5 | Partly |
| Finding the programme name | 0/5 | |
| Understanding the customer is both subsidy recipient and payer | 3/5 | Partly |
| Checking the recipient’s details against the document | 4/5 | Confirmed |
| Filling in contract data and tranches | 4/5 | Confirmed |
| Letter of credit details: reading the script, understanding the amounts | 4/5 · 3/5 | Partly |
| Execution conditions and documents | 5/5 | Confirmed |
| Status screen: reading the script, printing documents | 5/5 | Confirmed |
Nobody found the programme by name. Everyone looked for it in the agreement, and three of five tried typing the agreement’s title into search. On a tablet the keyboard covered the list, and scrolling through about 250 names was painful
The decision
The interface asked for information the employee didn’t have. The fix had to change what search understands, not how the field looks
I brought the findings to business. Together we revised part of the business logic for how this widget handles subsidy programmes, and engineering changed the backend search accordingly. I then redesigned the step around the new search
Validation
Round 2, 24 July 2025. Same task, redesigned step, three different customer cases: a gas connection subsidy, financial aid and housing purchase. All five employees found the right programme for each case. One new insight: staff confused the abbreviations of different agreement types, which we noted for the copy
Round 3, 28 July 2025. Document submission, four employees. All four found where to add documents and understood partial execution. All four read “one of the documents” as “any of them”, which showed the need for a note that the customer can submit as many documents as they brought
After validation I took the solution through design platform review and engineering, and followed it to production
Outcome
The research also became the start of regular research on the Letters of Credit team, which I initiated during my time there
Also in Letters of Credit
Preparing for the new design system
Moving Letters of Credit to a new design system was a chance to fix outdated logic. With system and business analysts I reviewed each process against current requirements before redesigning it. Where standard components couldn’t handle complex banking cases, I designed custom patterns with frontend
With the second designer I set up a shared migration board tracking every process from analysis to design, review and implementation readiness. Business and engineering used it as their reference too. When I moved to Escrow, my part of the migration was designed, and my colleague took it through the remaining stages