problem

a post-booking page should feel like reassurance — your flight's confirmed, here's what's next. ours felt like four different departments shouting over each other on the same screen.

prime, ancillaries, customer support, and hotels all had legitimate reasons to want prime real estate. historically, "solving" that meant just adding more — until the page became noise. nobody had defined:

that structural gap is what i was brought in to close.

what testing told us

we ran usability tests with 7 participants, plus 3 weeks of expi + fullstory data. three findings directly shaped my structural decisions:

solution

outcome

metric	before	target	achieved
hotel (hsa) weekly traffic	5k	8.8k	18,000+ (2x+ target)
contact rate (all devices)	0.13	0.07	0.07 (-46%)
chatbot adoption	10%	50%	50% (5x)
prime attachment rate	~1%	10%	13% (exceeded target)
revenue margin per booking	€0.43	€0.46	€0.48 (via ancillary sales)

the hotel redesign didn't happen in a vacuum — it worked because the navigation and template gave it a sane structure to sit inside. every other team's numbers moved too, which is really the point: get the structure right, and every product gets room to actually perform.

what's next

this was desktop — but the results made the case for themselves. with hotel traffic up 3.6x, prime attachment nearly 13x its baseline, and contact rate cut by nearly half, the next logical move is obvious: bring this same structural approach to mobile.

we're carrying forward everything this project taught us — the hierarchy logic, the shared template system, the "let people browse, don't force a decision" insight from hotels, and the ai personalization groundwork — into a mobile revamp, built on validated numbers instead of a hunch this time.

try it yourself on edreams (you need to purchase a flight though)

problem

this wasn't a single-page redesign — it's pillar 2 (pdp) and pillar 4 (plp) of a larger 5-pillar strategy (the others being product content, onsite search, and an ai shopping assistant). plp and pdp were prioritized first because they were the most direct blockers to conversion.

on plp, three problems compounded:

on pdp, the core issue was scale and clarity:

research & hypotheses

working alongside 2 dedicated researchers, we didn't just redesign on instinct — every pillar had a written hypothesis and success/failure criteria before design started. for plp and pdp specifically:

plp hypothesis: if we improve filters, add visual subcategory navigation, and enrich product cards, users will reach relevant products faster because they can narrow the assortment and compare products directly from the listing — without needing to click into a pdp just to rule something out.

pdp hypothesis: if we redesign variant navigation, availability states, and guided decision support, users will make more confident purchase decisions because they can quickly understand what's available, what fits their need, and what alternatives exist if their first choice is out of stock.

a key risk we flagged early and designed around: richer product cards might actually reduce plp→pdp clicks — but that's not necessarily bad. if users can disqualify products they don't want directly from the card, fewer (but higher-intent) clicks into pdp is a win, not a loss. this reframed how we'd read the metrics later, rather than optimizing for click-through in isolation.

solution

metrics we're tracking

since the project is mid-flight (design complete, ab testing ahead), here's what defines success once testing begins:

area	metric	what it tells us
plp	plp → pdp click-through rate	whether better cards/filters get users to the right products faster
plp	filter & sort interaction rate	whether the new filters actually get used, not just exist
plp	plp exit rate (no product click)	whether users are finding a path forward or giving up
pdp	pdp atc (add to cart) rate	the core conversion signal for the whole redesign
pdp	time to atc (add to cart)	whether the new hierarchy speeds up decision-making
pdp	variant selector interaction rate	whether the chip-based selector actually gets used over old habits
pdp	pdp → pdp navigation rate	a proxy for confusion — are users bouncing between products instead of deciding?
pdp	below-the-fold scroll depth	whether restructured hierarchy pulls users past the buy box into supporting content
business	revenue, cr, aov, cart abandonment	the executive-level scoreboard this all rolls up into

what's next

designs are locked and ab testing is in progress this quarter.

try it yourself on vidaxl

problem

users scrolling through the home page were hitting what the team called "carousel blindness" — rows of hotel cards that read as ads, not invitations. the data backed it up:

the real miss wasn't a lack of traffic. it was discovery intent going unserved — people open to the idea of a hotel, with no specific destination yet, and nothing on the page was built to catch that.

my hypothesis: a user-initiated, "stories-style" circular entry point would outperform carousels by tapping into a ui pattern people already trust from social apps — reducing the friction of "scroll and evaluate" down to "tap and see."

research — benchmarking the "story" mental model

i ran a competitive teardown across five products to see how the pattern gets used well:

product	what they do	takeaway i borrowed
revolut	stories introduce new verticals (stays, crypto) to users who came for one thing (banking)	stories are great for cross-selling a different product to an existing user base
hopper	circular bubbles for price watches / flash deals	circular ui creates a "curiosity gap" — feels like you're missing something if you don't tap
airbnb	circular category icons ("castles," "arctic")	sell the vibe with imagery before the destination name does any work
instagram	tap-to-advance, full-screen, instant	sets the performance bar — any lag kills the pattern entirely
spotify wrapped	data-driven personal storytelling	future direction: personalize based on search history, not just generic destinations

this shaped a clear principle: the interaction had to feel free and low-commitment — closer to flipping through friends' stories than clicking into a sales funnel.

validating it — usability testing (maze)

since i was the only designer on this, i ran the full research loop myself — moderated concept testing in maze to pressure-test the interaction before it went anywhere near engineering:

solution

outcome

metric	estimated	achieved
weekly visits to hotel funnel (this touchpoint)	~4,500	10,000+ (2.2x estimate)

the gap between projection and reality is the clearest signal that "discovery intent" was real, not a theory — people weren't just tolerating the stories format, they were actively engaging with it well beyond what static carousels ever pulled.

download edreams app on app store or play store

problem

kompyte didn't have a product design team when the first version of this release shipped — it was built by an external consultancy, under time pressure, with no usability testing along the way. engineering had to move fast, and ux was the trade-off.

by the time i joined and ran research interviews with the primary users (sales and marketing managers), the pain points were clear:

this reframed into three concrete design questions:

process — fast iteration, constant testing

as the only designer, i moved quickly between paper and digital prototypes, testing with users and getting feedback from internal sales executives and a mentor along the way. some iterations led to small polish fixes; others reshaped the direction entirely.

before locking a direction, i identified the specific features the design needed to support:

solution

i also used this project to build the foundation kompyte didn't have yet:

validating it

i ran usability testing sessions against a written script of scenarios, directly targeting the pain points identified at the start — then observed how people actually navigated the new prototype before it went to engineering.

outcome

metric	before	after
task completion time	19 min	6 min (-68%)
user satisfaction	1.8/5	4.3/5 (+139%)

post-launch, service desk complaints dropped noticeably, and feedback centered on how much time the simplified insight configuration saved users.

working with engineering

i built high-fidelity mockups in figma for direct engineering handoff, working closely with the front-end team to spec out interactions the mockups didn't fully cover — and reviewed every front-end ticket against the designs before it shipped, rather than treating handoff as the finish line.

what's next

the hardest part of this project wasn't any single screen — it was building a design system from scratch, solo, with no prior structure to build on. comparing that task to something like ios's or material design's system felt daunting at first, but getting it to a usable bar for the team was the real win here.

problem

this wasn't a blank-slate project — it was inheriting two years of research scattered across four different agencies (tribeone, ideo, madpow, langland), each with their own low-fidelity screens, their own validation methods, and no single coherent thread tying it together.

my first job wasn't designing screens. it was making sense of what existed.

turning fragmented research into a foundation

i structured the accumulated research into a single usable set of artifacts:

from that, i defined the actual problem statement, goal statement, and value proposition — the groundwork the rest of the team would design against.

prototyping with real clinical input

working within huma's existing design system, i built the first prototype and ran feedback sessions with healthcare professionals across multiple countries — not just patients. getting clinical buy-in early mattered here in a way it doesn't in most consumer products; this app needed to work for nurses and clinicians managing the treatment relationship, not just the end patient.

before testing began, i defined exactly what we'd measure:

testing with patients

i tested the first high-fidelity prototype with 20 patients, running individual interviews at 90 minutes each — a serious time investment per participant, reflecting how much nuance this population's feedback required.

every piece of feedback went into a structured table tracking: observation, evidence, recommendation, type, module, rating, proposed design change, priority, rationale, and whether it became an actionable task. from there, i ran prioritization sessions with the design team based on impact vs. effort, and assigned resulting tasks by each designer's module specialization.

outcome

the app shipped on the app store and play store, having gone through 7 design iterations, each reviewed not just by design but by internal clinical, regulatory, and technical teams at huma.

reported outcomes:

what made this different

this wasn't a typical "ship fast, iterate later" product cycle. certain modules (onboarding, profiles, caregivers, journal, medication) were treated as low-risk-of-change and could evolve — but other features were deliberately frozen based on the research-to-date in order to hit regulatory deadlines. balancing clinician needs, patient needs, and regulatory constraints simultaneously is what shaped most of the prioritization calls across those 7 iterations.