About
Complex products need structure before they need polish.
I'm Ihor, a product designer. For ten years I've been designing the working side of software: the screens people sit in for eight hours, not the ones they scroll past.
Where I've been.
I started in e-commerce as a freelancer, where every pixel had a conversion number attached to it and I learned to argue with data instead of taste. At AltexSoft, a stretch in fintech taught me what "state" really costs when money is attached to it.
Then two and a half years in retail operations: point-of-sale workflows, marketplaces, and the admin tools teams build for themselves and then quietly hate. Most recently, travel and hospitality, where the product is a chain of hand-offs, and AI products, where I design the assistant as well as work with one.
What crossing domains taught me
A shop, a reservation desk and a payment flow look nothing alike, and they break in the same place: the moment context gets lost between two steps, two roles, or two screens.
So I stopped designing screens first. I draw the operation, its objects, states and owners, and only then decide what each surface has to carry into the next one. Polish comes last, and it comes easier.
Working principles
How I work.
- Understand the operation
- I start with the task, the objects, the hand-offs and the constraints, and I say out loud where the evidence ends.
- Build the system
- Hierarchy, interaction, content and states have to agree with each other. I'd rather ship one connected route than ten nice pages.
- Say what I know
- Artifacts are evidence. Where I don't have a number, I say so instead of inventing one.
About this site
The cases here are projects I worked on at AltexSoft. Each one names my role, the product stage, what could be published, and where the outcome claim stops.
The site is a small product of its own: built in Astro, designed dark-first with a light theme, and checked against WCAG 2.2 AA on every page. If a case raises a question the page doesn't answer, ask me.