Siarhei Bekish, senior product designer in Warsaw. Seven years of B2B and fintech web products: document flows, banking accounts and CRMs.
I take legacy systems that grew without design and turn them into clear flows people use all day. I test ideas with real users, build design systems and work closely with developers. Most recently, four years at Flo Health adapting product UI for 20+ languages.
I'm a product designer with 7+ years of experience in B2B, fintech and SaaS. I've designed CRM and back-office systems, banking account areas for individuals and businesses, and an e-invoicing platform that went to production. At Flo Health, I adapted product UI for a global audience in 20+ languages. I enjoy turning messy workflows into clear, scalable interfaces.
experience.log3 entries
Flo HealthDesigner · Localization, UI and visual design
2022–2026
SoftClubSenior Product Designer · B2B and fintech
2019–2022
INDIUX/UI Designer · Mobile app and admin
2018–2019
Contact
Have a product that can't go wrong?
Open to remote and B2B contract roles in product design.
Designing the client cabinet of a B2B EDI platform
I designed the client cabinet for creating, signing and tracking legally binding electronic documents, and it shipped to production. In 2025 I came back to my own work and rethought it. This case shows both.
The 2025 version: four waybills selected, one action bar to sign them.
Context
A legally critical product with an interface nobody designed
The product
SC-EDI is a B2B platform for exchanging legally binding electronic documents between companies: waybills, orders, shipment notices and acts. Documents are signed with a digital signature and checked against national requirements for product marking and traceability.
The users
Accountants, logistics and sales staff at client companies, who create, sign, send and track documents every day.
Problem
Outdated interface
The cabinet was built by developers without a designer and had no consistent visual logic.
Problem
Confusing document creation
Many fields, unclear order and no guidance made creating a document slow and error prone.
Problem
No overview
It was hard to see which documents needed action and where each one stood.
Goal: make everyday document work fast and clear, without changing the legal logic behind it.
What the client told us
The hardest part for the client was creating a document. It was one very long page with many forms and no clear hierarchy. Required and optional fields were mixed together, so people never knew what they had to fill in and what they could skip.
This became the main problem I set out to solve.
Process
Validated with a real client before development
I mapped how the existing cabinet worked and where users got stuck, then built an interactive prototype. Instead of waiting for release, we tested it with one of the platform's key clients.
What I tested
The full path of creating a document, from the first dialog to the last field. The question was simple: is the new form clearer than the old one, and can the client fill it in without help?
What changed after
The new structure worked: the client understood the sections and the required fields. Their comments were about where some forms sat on the page, so I reordered and regrouped those blocks before handing the design to development.
Audit of the legacy cabinet
User flows for core tasks
Interactive prototype
Feedback sessions with a key client
Iterations, UI and design system
Handoff and support in development
What shipped
The cabinet I designed, in production
Two of my original screens of the shipped cabinet, in Russian, as clients used them. Click to see them larger. Company names are demo values.
A form split into sections. The waybill is grouped into blocks such as shipper, consignee and delivery. Each block can be collapsed, and required fields are marked with a star.
Optional fields on demand. Rarely used fields are hidden behind "+ add" links, so the form shows only what most documents need.
Folders and status tabs. Document types live in a sidebar, and tabs split incoming, outgoing and draft documents.
Clear document statuses. Accepted, partially rejected and rejected documents each have their own icon in the list.
ShippedDocument list
ShippedWaybill form in sections
Part 2 · 2025
Rethinking my own design
Three years later I came back to the cabinet with more experience. I kept the structure and flows that worked, and changed what I would design differently today. This version is a portfolio project, not a shipped release.
Shipped vs. rethought
The same form, three years later
The shipped form solved the client's main problem, but it still showed everything at once. Here is the same waybill: what shipped, and how I would design it today.
ShippedMy design in production
2025The same waybill, rethought
One section open at a time. The shipped form showed all sections on one long page. Now the section in work is open, and the rest collapse to one line.
Progress you can see. Users had no overview of what was left. Now navigation on the right shows done, current and missing sections.
One main action. Six buttons of equal weight sat at the bottom, from Send to Cancel. Now one primary action leads, and the rest step back.
Sections as cards. Sections were separated only by headings. Now each one is a card with a clear edge, so the eye finds its place faster.
Key decisions
The decisions behind the new version
Document types in a side navigation
document types
Document types get their own navigation
In my first version, the document type hid behind a small switcher next to the title. I tried a segmented control and type cards, then chose a side navigation: type, then status, then document, a clear hierarchy. To keep the table readable, consignee and delivery place now share one column, with the name on top and the address below.
status tabs · markers
See what needs action, at a glance
Status tabs (Waiting, With partner, Draft, Completed) get counters, and every row gets a colour status marker. I renamed "In supplier" to "With partner", because users did not read it as "waiting for the other side".
column filters
Find any document fast
Every column of the table has its own filter, and filters can be combined: for example, a partner and a period. Accountants work with hundreds of documents, so search had to be part of the table, not a separate page.
bulk actions
Sign only what is ready
A floating action bar appears after selection. If one of the selected documents is an unfinished draft, the button says "Sign 3 of 4" and a hint explains which one is skipped and why, with a link to open it.
create dialog
Start from a type or from a copy
Many shipments repeat: the same partner, the same goods. The create dialog lets users pick a document type or find a previous document by number or partner and start from its copy.
partner search
Pick a partner, not five fields
Users typed the consignee's name, address, VAT and company code by hand. Now the name field searches the partner directory by name or GLN, and the rest of the card fills in automatically.
sectioned form · progress
Always know what is left
Each section is a card that follows how a waybill is filled in. The navigation on the right shows done sections and how many required fields are left in the others, and the header repeats the total next to the main button.
review · sign
Review, then sign and send
The form button became "Review and sign", so users know what happens next. The preview has one main action, "Sign and send". Delete moved into the "⋯" menu, away from everyday actions.
Screens
Seven screens from the 2025 version
The same flows, redesigned and in English. Click any screen to see it larger.
Side navigation and status tabs01
Signing only what is ready02
New document or a copy03
Partner search and progress04
Commodity section, ready to sign05
Adding a product06
Review, then sign and send07
Design system
One set of components behind every screen
The new version is built from a small component library in Figma: buttons and inputs with all states, table rows, form sections and the progress navigation. Every document type uses the same parts.
Colour, type and core components of the 2025 version, assembled from my Figma screens
Result
Released to production and used by the platform's clients
Outcome
My cabinet replaced a developer-built interface and was released to production. The key client's feedback on the prototype was built into the design before development.
What I learned
In B2B products with legal requirements, the hardest part is not the visuals but the structure: how to make a complex, regulated process feel simple. Testing a prototype with a real client early saved the team from building the wrong thing. Coming back to my own work three years later showed me how much calmer a dense B2B screen can be.
"What shipped" shows my original production screens from Figma. Part 2 is my 2025 redesign of the same product, made for this portfolio. Website and code: designed by me in Figma, built with help from Claude.
Redesigning a CRM for housing and utility services
Housing office staff use this system every day to manage residents' personal accounts, charges, payments and reports. I redesigned a legacy interface that developers had built without a designer.
RoleSenior Product Designer
ScopeUX, UI, usability testing, handoff
TeamCross-functional, 10+ people
Duration4 months
Rebuilt from my original layouts: six accounts edited in one panel.
Context
A system that grew without design
The product
An internal system for accounting, calculating and billing housing and utility services. Housing offices use it to manage residents' personal accounts, record payments, edit building data and prepare reports.
The users
Staff of housing maintenance offices, who work in the system the whole day and handle hundreds of personal accounts.
Problem
No design behind it
Developers built the interface without a designer. Screens had no shared logic for layout, controls or states.
Problem
Overloaded screens
Dozens of fields, columns and buttons competed for attention on every screen.
Problem
Complex everyday tasks
Finding an account, changing its data or preparing a report took too many steps.
Goal: make daily account work clear and fast for housing office staff, while keeping the existing business logic.
Process
Tested with the people who use it every day
I audited the legacy system and mapped the core tasks of housing office staff. Usability testing with employees showed the key pain points, and the new version addressed them. Then I designed the main flows, dialogs and reports and prepared specs for development.
Audit of the legacy system
Map of core tasks
Usability testing with employees
Redesign of main flows
UI kit and specs
Handoff to development
Key decisions
What changed and why
Filters that step aside
account list
Filters that step aside
The account list opens with four key filters: organization, address, account number and status. One link hides them, so the table gets the full screen once the search is set, and the filters are saved for the next visit.
analytics
Find debtors in two clicks
Analytics starts from an address tree, so staff pick a building instead of typing filters. The most common questions, such as debt periods, benefits or empty apartments, became one-click filters with live counts.
account card
The card starts with a summary
The account card opens with the address and the five numbers staff check first: opening balance, charges, subsidies, payments and closing balance. Secondary details sit behind one link, and services, payments and meters live in tabs.
bulk editing
Edit many accounts at once
Staff often change one rule for a whole building. They select the accounts and open one side panel where every field has its own Edit link, so only the fields they touch change, from a clear start date.
reports
Reports as a three-step wizard
Report forms showed every parameter at once. I split them into scope, filters and format, and used a two-list picker to include or exclude service organizations.
Screens
Five key screens
Accounts, the account card, analytics, bulk editing and reports. Click any screen to see it larger.
Personal accounts01
Account card02
Analytics with popular filters03
Editing many accounts04
Report wizard05
Result
Handed off to development
Outcome
The redesigned flows, dialogs and reports were handed off to the development team with specs. I left the company before the release, so I can't share production metrics.
What I learned
In internal systems, people spend the whole working day in the interface. Small changes, like hiding filters or editing in bulk, save more time than visual polish. Testing with real employees showed what to fix first.
The original screens are under NDA. For this portfolio I rebuilt the key screens from my original layouts with a refreshed visual style, in English. All names, addresses and numbers are fictional. Structure, flows and decisions are the ones from the project.
