Your strategic
product {{ typed }}
8+ years turning qualitative insight and data into product strategy across apps, travel, and e-commerce.
Lead designer on the FlixBus and Greyhound apps with 10m. users.
Turning Trip Delay to Engagement
Reframed delay frustration from an operational problem to a communication gap. Pivoted a blocked Live Activities initiative into a shippable contextual home screen card.
From Seat Conflicts to Revenue Retention
Field research on live trips uncovered how boarding friction was eroding seat reservation revenue. Designed and shipped a seat map across six vehicle scenarios.
AI-Powered City Discovery
A conversational prototype built in 30 minutes that became the evidence base for FlixBus’s investment in a full AI search feature, now in implementation.
Frequently asked questions
How I work, how I decide, and what I look for in a team.
{{ item.a }}
Let's work together.
Looking for a product design role where I can own complex product areas and drive decisions through research.
Included with me: Simeon Bulka Bubochka — Senior Meeting Listener and Professional Bug Catcher.
Turning trip delay frustration into a +19% lift in app engagement
Delay-related complaints made up 8.6% of all App Store reviews — spiking to 25% in peak months. I proved the real problem wasn't delays, it was invisibility, then shipped a contextual home screen card that increased app sessions by 19% and unblocked a year-stalled Live Activities initiative.
We couldn't stop delays. But we could stop losing trust.
Delay-related reviews made up 8.6% of all App Store reviews, spiking to 25% in peak months. The business impact was measurable: decreased NPS during delayed trips, increased support contact volume, lower customer LTV.
I analyzed qualitative feedback and found a consistent pattern: users weren't frustrated about delays — they were frustrated about not knowing what was happening, whether the app was accurate, and whether they could rely on it.
To validate this, I partnered with our data analyst to compare NPS between passengers who received proactive SMS notifications and those who weren't informed. Notified customers scored higher across every delay range — regardless of duration.
How might we reduce frustration around delays by making real-time trip information more visible, trustworthy, and easy to access?
Five routes to the same outcome.
Before committing, I mapped every route to the same outcome: a passenger who knows what's happening without having to ask.
One route wasn't new. A year earlier, during an internal hackathon, my team had explored Live Activities to surface trip status on the lock screen — it stalled without a business case. Now I had one, so I put it back on the map.
Rewrite the notification so it carries the actual delay.
Delay data changed too frequently to state a time, and the surface was owned by a team without capacity. Not mine to experiment on.
Fix clarity inside the existing tracking view on both platforms.
iOS ran a web view, Android a separate native screen with the same problems. A full rebuild on two stacks couldn't be justified by a visibility issue.
Let the new support bot handle “where is my bus” at the moment people ask it.
Support was mid-redesign and building the bot itself — no capacity to extend it into the app. It also answers only the passengers who bother to ask.
Rebooking and compensation flows for when the delay has already cost someone their connection.
Valuable, but it treats the consequence. The reviews weren't asking for a refund — they were asking to be told what was happening.
The strongest concept in testing — visible excitement, universally well received.
Required dedicated backend nobody would fund. Parked deliberately, not abandoned.
Every route was closed — by another team's roadmap, by cost, by infrastructure, or by solving the wrong problem. The strongest concept was the one nobody would fund. So I stopped looking for a better idea and started looking for a surface that needed nothing new.
Testing decided the direction — not assumptions
I tested two concepts with real iOS users during continuous interviews: a Ticket View and a Trip Progress view.
I chose Trip Progress over Ticket despite Ticket being technically simpler — because it aligned with our engagement metric while Ticket actively worked against it. I deprioritized a "nice to have" in favor of a feature that served both user needs and product goals.
The constraint that shaped the strategy
Live Activities required dedicated backend support our team didn't have. Multiple teams declined — the project could have died here.
I identified a key insight: the real-time data already existed in the app. Live Activities needed new infrastructure — a contextual in-app home screen card did not. I proposed a two-step strategy: ship a low-dependency contextual card first to prove value with data, then use those results to build the business case for Live Activities.
This wasn't a compromise — it was a deliberate choice to de-risk a larger investment before asking for scarce backend resources.
Contextual home surfaces had existed in our Android app for six years without iteration. Before building for iOS, I ran an unmoderated usability test on the Android version: users were unsure whether the trip was from or to the destination, time hierarchy was unclear, and secondary buttons were largely ignored.
I redesigned the card from scratch using Live Activities visual language — prominent departure and arrival times as primary hierarchy, reduced cognitive load at the moment it matters most. I prepared and tested 3 designs. Version 3 performed best.
What shipped — and what it unlocked
Shipped as a reusable component in the design system. A/B tested over 4 weeks among users with an active ticket:
The card made the home screen more useful and gave users a reason to open the app before their trip. The bigger win was organizational: I secured an internal sponsor who committed backend support for Live Activities — the initiative that had been blocked for over a year.
What I'd actually designed wasn't a screen, it was a loop. An approaching trip is the trigger. The card is the reward for opening the app — arrival time answered before you think to ask for it. The payoff is the feeling of knowing. Repeat that across trips and the app becomes the first thing you check when something feels off, instead of the last resort after support.
Worth being precise about the evidence: the A/B test measured sessions within an active trip, not return rate across trips. The 19% proves the trigger works. Proving the habit needs cohort retention over several bookings — that's the measurement I'd set up next, and the reason the roll-out below matters more than the result above.
Cutting seat-conflict complaints by 71% and protecting ancillary revenue
Passengers who paid for seats kept finding someone else sitting in them — and it was killing repeat purchase intent, dropping likelihood-to-rebook from 4.1 to 3.1 out of 5. I conducted field research that uncovered the boarding friction, then designed and shipped a seat map that reduced seat-related negative App Store reviews by 71% YoY.
Reducing seat conflicts, protecting ancillary revenue
Seat reservation is a key ancillary revenue stream. But operational and communication gaps were creating friction at the exact moment it mattered most — boarding.
User problem: passengers struggle to find a seat if they haven't reserved one but were assigned it. Passengers who reserve seats are annoyed by seeing other people sitting in the seats they paid for — which discourages them from booking one again.
Business problem: seat-related issues reduce repeat seat-reservation revenue. A significant share of NPS respondents report trouble finding their seats, and for those who experience problems, likelihood of reserving a seat again drops sharply — from 4.1 to 3.1.
For a long time, the apps team focused on booking experience and conversion. Nobody was looking at what happened after the ticket was purchased. In Q4 2023, together with a colleague from the Android team, I conducted a field study — observing and interviewing customers during their actual trips.
I shared these findings with the Ancillaries team. They independently confirmed the pattern through their own NPS investigation, based on ~1,000 survey respondents. This wasn't just a UX problem. It was a revenue problem.
Aligning stakeholders on the direction
A cross-functional workshop with Ancillaries, Android, and iOS teams mapped operational seat conflicts on board, user confusion around auto-assignment and free seating, and the impact on repeat reservations and revenue.
Three directions came out of it. Two delivered the right information at the wrong moment.
Explain auto-assignment and free seating in booking copy, confirmation and FAQ.
A rule read at booking doesn't help two weeks later on the bus. People weren't confused about the policy — they couldn't see where their seat was.
Pre-trip email or push reminding passengers of their seat and the seating rules.
Easy to overlook — one more message in a pre-trip inbox, arriving before the moment it's needed. The channel also belonged to another team and couldn't show the actual layout of that bus.
The layout of the actual vehicle, in the passenger's hand as they board.
Available at the moment of conflict, on a surface we owned, and the only option that scaled across every vehicle type.
I advocated for prioritizing in-app transparency over communication updates — because the conflict happens at boarding, not during booking or commuting to the station. We aligned on a Seat Map in the app as the most scalable solution.
Designing for clarity under real-world constraints
Due to limited engineering capacity, a native implementation wasn't feasible — the Seat Map could only be integrated via WebView in a bottom sheet. This constraint shaped my design philosophy: clarity over interaction richness.
I identified two primary scenarios requiring different levels of clarity: assigned seats (the user needs to find a specific seat quickly) and free seating (exact layout data is often unavailable, requiring approximate visualization).
Testing before building
To de-risk before development, I ran two unmoderated usability studies covering both scenarios.
I translated findings into two concrete recommendations: disable non-free seats to prevent misinterpretation, and add row numbers for physical orientation on the bus. Both were implemented before launch.
After validation, I adapted the Seat Map to support six key scenarios. Accessibility was built in from the start — color contrast validated to meet standards, VoiceOver labels added for screen reader compatibility.
From launch to a 71% reduction
The Seat Map launched at the beginning of Q2 2024. I partnered with the business team to run an in-app survey focused on perceived helpfulness and future purchase intent (~1,000 respondents, Apr 22 – May 12):
Transparency at the boarding moment moved satisfaction — but the number I cared about was the second one. 42.1% said they'd buy a seat again on their next trip, which reframes the feature from a one-off conversion to repeat-purchase behaviour: the paid add-on is only worth its engineering cost if the first purchase doesn't end in a conflict. Removing the friction protects the next sale, not just this one.
Post-launch survey — helpfulness perception and intent to rebook.
Building a working AI prototype in 30 minutes — and shifting product strategy
Travelers open the app without a destination in mind — and pictures and prices alone don't help them decide. I built a working AI chat prototype in 30 minutes to test whether conversational discovery could close that gap. It validated the concept and became the evidence base for FlixBus's investment in a full AI search feature, now in implementation.
Users don't always know where they want to go
AI is becoming increasingly capable of helping people make everyday decisions. I wanted to explore what that could mean for FlixBus — without adding AI just because it was new, and without losing sight of the actual user problem.
Could AI help travelers decide where to go?
User problem: people don't always start with a destination in mind. Sometimes they just know they want to travel, but need inspiration or help narrowing down their options.
Business problem: many travelers, especially in the US, simply don't know where they can go with FlixBus. Our network isn't obvious the way a single well-known route is — discovery is the barrier before booking even becomes a question.
What Knuspr taught me about AI done right
During a strategy workshop, a colleague mentioned that she loved the AI feature on Knuspr — it had helped her plan her child's birthday party, right down to figuring out how much food to prepare for the number of kids attending.
That was the moment it clicked: AI shouldn't be a feature bolted onto a product. It should solve a real problem for a real person, in the most convenient way possible.
I remembered from earlier research that pictures and prices alone aren't enough for users to decide where to travel — they need to know what there is to see, what's happening locally, what a place feels like.
That was enough signal to move forward — users were already solving this problem with AI tools outside our product, which meant we risked losing the discovery moment entirely.
30 minutes to a working chat prototype
I built the first fast prototype in Figma Make. The result was a fully interactive chat experience — something not achievable with a regular Figma prototype.
I shared it with my team, gathered feedback, and iterated. I also discovered I could switch the underlying model in Figma Make to Claude — which sped up my workflow and improved output quality.
Speed vs. polish. I prioritized interactivity and conversational realism over responsive design, because the goal wasn't a shippable UI — it was proving whether the concept held up with real users before investing more time in fidelity.
Testing decided the direction — not assumptions
Together with Claude and UserTesting's "Create with AI" feature, I ran a think-aloud study, asking participants to interact with the prototype to validate three hypotheses:
A single, well-scoped recommendation feature was the safer, faster bet — but the research showed it would underdeliver on what users actually expected. I pushed for the harder, slower option because shipping something incomplete risked damaging trust in the feature more than not shipping at all.
The prototype didn't ship — the decision did
A couple of months later, I presented the work at a workshop with the Figma team. They gave strong positive feedback and were surprised by how detailed the prototype was — more than they'd expected to see built with the tool. They suggested I turn it into a template for others to build on.
The prototype itself didn't ship as-is — instead, it became the evidence base for a bigger decision: the team chose to invest in a comprehensive AI search feature rather than a single destination-recommendation moment. That feature is now in implementation, led by another designer on the team.
The prototype didn't need to ship to have impact. It de-risked a bigger bet and helped the team commit to the right scope early.
AI produces. I decide.
I don't use AI as a replacement for UX thinking. I use it as a force multiplier for exploration — to process information faster, generate first drafts, and make ideas tangible earlier in the process.