When my design doesn’t work, my phone rings.

The phone is where I hear the problems

Dispatch means pricing the trip, sending the quote, and picking up when a passenger is stuck. Before the redesign, a lot of those calls were the same question: how do I book this? The only way to confirm a quote was a 110-character link in the body of the email.

So I redesigned the email, and the phone told me whether each version worked. It took ten. Quote-to-booking went from 29% to 61%, and the calls now are about wait times and grace periods. Not price, and not how to book.

The whole story, mistakes included, is in the case study.

I noticed the problems before I knew the job had a name

I was born in Uzbekistan and moved to Warsaw for a bachelor’s in international business and marketing at Collegium Civitas. In Warsaw I worked as a data governance analyst, reviewing posts and videos on Facebook and Instagram. Every item needed a decision: fine, against the rules and deleted, or unclear and escalated for the team to discuss.

Then I moved to the United States for a master’s in business analytics at Florida Atlantic University. Analytics is how I found my way to UX. I’d always noticed the friction in things, like a traffic light, a road, a car or an app, and wondered why nobody had fixed something so obvious. It turned out there’s a profession for that: find the problem through research, solve it, and see the business improve.

Today I work two jobs. I’m the owner-operator of a bakery, where everything relies on me. At Seattle STS I dispatch, look for new accounts, and do the UX.

How I work

Research

I go through a product the way its users would and write down what gets in their way. For Morikami, that was the garden’s own website, read as a visitor. At STS, the phone does most of it.

Design

In Figma when there’s a canvas: the Morikami design system has 23 components, 22 icons, 174 variables and an AA colour mode for the accessible screens. In words and references when there isn’t: the STS email lives inside a booking system’s templates, so it never had a Figma file.

Build

Prototypes with real behaviour, not linked pictures. The Morikami one knows the garden is closed on Mondays and times out for real. The STS email was built with AI inside the booking system; I explained each fix from a UX standpoint and reviewed every render.

Ship

In versions, and I keep the ones that didn’t work. Neither of the email’s two main fixes was right the first time, and one did worse than the old email before it did better.

Measure

A before and after, with the caveats written next to the number.

Accessibility is the showcase, not a checkbox

In the Morikami concept, accessible mode isn’t a settings page. It’s a second, calmer way through: one question per screen, no time limit, and a booking code short enough to read out loud. Access needs ask for quantities, never proof.

The words carry as much of it as the contrast does. Labels stay plain enough to find, and the warmth goes where people worry. I wrote that up in Plain labels, warm sentences.

A product people love still has to pay for itself

I don’t treat that as a trade-off; running a bakery doesn’t let you. The new STS email is clearer for passengers and books more than twice as often, and both came from the same fixes.

It also has to be honest. I took an “8 spots left” counter out of the Morikami flow: the garden isn’t busy enough for it to be true, and invented scarcity is pressure to buy.