I came to design through engineering, which means I approach a broken product the same way I’d approach a structural problem – find where the load is going, fix that first.
Ten years in UX design services and UX consulting across logistics, finance, and enterprise software. In London for the last six.
I have a habit of finding the one thing nobody wanted to say out loud about a product and saying it in the first meeting. Clients find this either useful or slightly alarming. Usually both.
I grew up in Ukraine, in a small industrial city, which probably explains the engineering degree.
It felt like the serious choice, the one that made sense in a city built around making things work. I liked the logic of it. I liked understanding why things held together and, more to the point, why they didn’t.
I moved into game development first – two years designing interfaces for things that didn’t exist yet, worlds that needed systems before they needed stories. It was the best possible training for design and I didn’t realise it at the time. The jump to UX Design felt obvious in retrospect. It is just engineering with more ambiguity and fewer load tables, and I still find the ambiguity more interesting than the certainty.
I was invited to the UK by the British Government through Tech Nation’s Global Talent programme – the UK’s way of saying the work was worth something, which I appreciated more than I expected to. It’s a strange thing to have your career validated by a visa, but there it is. I also run DNSK.WORK – embedded designers inside client teams, long-term. A separate thing from UareUx, same conviction behind it.
I have strong opinions about most things. The ones worth writing down ended up in a personal blog and the book. The ones worth judging got me onto the Awwwards jury. The rest stay in the first meeting.
If you’re here because you’re thinking about working together – bring the product itself, not a description of it. I will have opinions quickly, and most of them will be about something you had stopped noticing.
I’ve been doing both long enough to know which one a project actually needs.
It is not always the one people come in asking for.
Brand identity, a prequalification app, and a homeowner portal for a clean-energy financing company – the illustrations made it look simple; the flows made it be.
A mobile-first landing page for a realtor-matching service – the client brought wireframes; the work was making the page convert, starting with the phone number.
Wrong structure, wrong flow, wrong hierarchy. Sometimes all three. Here’s what fixing that looks like.
The questions people ask before they’ve decided anything, which are usually the honest ones.
Where I start. Engineers are trained to find the part actually taking the strain, which is rarely the part that visibly cracked. Products are no different, and it means I spend the first week somewhere nobody expected me to be looking.
Different work, and mostly other people’s hours. If a project here needed more of me than I had, I would say so rather than spread thinner and hope nobody noticed.
Then we argue about it, which is usually productive. Being wrong in front of each other early is a great deal cheaper than being polite about it until something has been built.
Most audits end with a document. Nobody has ever been persuaded by a document. This ends with a decision about what to do first, which is a shorter conversation and a harder one.
More than you would think, and less than I would like. Support tickets, session recordings and the sales team’s least favourite objections cover a surprising amount. But some things only users know, and no amount of inference substitutes for that.
