Viktoriia Ionova
← All projects
🖼
Property page — member price & registration (hero)

Role

Product Designer

Skills

✦ Constraint-driven UI design (locales + multi-currency)✦ Data-informed iteration✦ Stakeholder alignment (PM + Engineering + SEO)

Tools

✦ Figma✦ Analytics (PostHog)✦ AI-assisted exploration

Product & Problem

Context

Users from Google Hotel Ads skip our search page and land directly on the hotel page, so they're new, unregistered users seeing prices for the first time. This page is often our only chance to show them the product's value before they book.

Business goal

Increase registration from this traffic: registered users get better prices, so registration is the core business goal for these high-intent new users.

What changed

Earlier this year I redesigned the search-page cards and those changes carried over to the property page. Because GHA traffic lands outside our usual funnel, the first signal came from Google's side — their metrics on this traffic dipped. Our SEO flagged it and then I went into our own data to confirm and diagnose the cause.

Problem

The redesign moved the registration cue off the room photo (where it was easy to notice) into the text block, where it got lost. For high-intent new users, the member price has to be immediately visible: not loud, but instantly noticeable through hierarchy. If they don't see the reason to register, we lose them right when they're ready to book.

Challenge

Multi-language UI + multi-currency + technical constraints limited how explicitly we could surface the pricing and registration cue: the solution had to stay clear across long translations, worst-case price lengths and pages with many room cards.
🖼
Before / after — member price visibility on the card
Left: member price before the problem appeared. Right: after the redesign — visually secondary, easy to miss.

My Role & Contribution

  • Diagnosed the conversion drop and framed it as a UX visibility issue affecting registration (the core business goal)
  • Partnered with stakeholders (incl. GHA) to confirm constraints affecting performance and visibility
  • Designed and shipped a focused, low-risk change across a multi-language interface
  • Ran a 30-day performance read to avoid false wins from short baselines and communicated the nuanced outcome

Key Design Decisions & Process

Exploring the direction

I explored a wide range of directions, including quick AI-assisted ones, looking for a layout where the member price is immediately noticeable: not bright or loud, but seen right away through hierarchy and placement. Once I tested these against real conditions in Figma, the strong-looking options started to break — and each constraint shaped a specific decision: principle, what I explored, where I landed.

Localization-first layout

Principle: the layout has to hold up in every language, not just look right in English.

Explorations: I tried layouts with tighter, more compact arrangements of the price and cue. They looked cleaner in English but broke once long translations wrapped onto multiple lines. And fixed component widths couldn't absorb the variation between locales.

Final solution: a layout that doesn't depend on short copy or fixed widths — it stays clear and consistent across long translations and different locales.

Designed for multi-currency and density

Principle: stay readable with the longest possible prices and across a page that can hold many cards.

Explorations: I tested more prominent, heavier treatments of the price. They worked on a single card in EUR/GBP, but longer numbers in other currencies pushed key actions around, and the heavy treatment became overwhelming when repeated across 20–30 cards on one page.

Final solution: a layout that remains stable even with the longest prices and stays consistent when repeated — reliable rather than fancy elements that only work for one currency on one card.

Working within technical constraints

Principle: communicate the member value without depending on things the system can't do.

Explorations: the strongest concept put a dynamic, per-room price directly on the CTA button. But we couldn't render a dynamic per-room price inside the button, so this wasn't buildable.

Final solution: the card itself carries the member-value cue, so the message doesn't rely on button content — working with the technical limit rather than fighting it.

Clarity without fake preselection

Principle: the member price should be obvious, but never feel like a trick.

Explorations: I landed on a few strong candidates and showed them to several people in a quick hallway test. The most prominent version made the member price stand out so much that people read it as already selected — a kind of fake preselection. That wasn't honest.

Final solution: I reworked the UI so the member value reads clearly without pretending it was a choice the user had already made.

We don't run A/B tests in this setup, so I shipped first on the GHA landing page: a contained, high-intent audience, measured over 30 days, and rolled out to everyone only once the lift held.
🖼
Exploration mockups (rejected variants)
Exploration mockups (rejected variants).

Final solution

🖼
Final solution — property page card

Outcome

Result

The change made the member price and registration immediately visible on the card, and it moved the funnel:

Booking start rate: +17%(a clear improvement)

Membership created: +17%

Booking committed rate: +2%(essentially flat)

What this tells us: the change worked exactly where it was designed to — the top of the funnel. More users noticed the value, started booking and registered. Booking completion stayed flat, which makes sense: that depends on later steps like payment and availability, which this change didn't touch. So the impact is real and correctly attributed — it lifted the specific behaviour it targeted, without over-claiming credit for the whole funnel.
🖼
Old vs New — property page comparison
Toggle between the old and new property-page card.

Reflection

Reflection

Small changes can create real impact when they remove the right friction. Working within localization, multi-currency, and technical constraints, I improved clarity without adding steps — and measured it honestly, crediting the change only for what it actually moved.

What I'd do differently

This problem appeared because a change to a shared component (the card) quietly rippled to another page that reused it. Next time I'd map those dependencies upfront — checking every surface a component touches before shipping, so a change in one place doesn't cause a regression elsewhere.