loveholidays Rebranding

I led the product-side rollout of the loveholidays rebrand for We Love Holidays Ltd, translating a refreshed brand identity into a conversion-safe, measurable customer experience across the discovery-to-booking funnel. loveholidays is a UK-first online holiday booking platform, and the whole point of the work was to keep the booking experience fast and trustworthy while a new brand rolled through it.

The customer-facing brand refresh launched publicly in late 2022 (trade-press coverage on 5 Dec 2022). From there the work moved through system translation and product adoption in H1 and H2 2023, then a phased funnel migration and optimisation programme through 2024-2025. Localisation became real during expansion, including the Germany launch as weloveholidays on 2 May 2023, and brand expression deepened further with campaign activity such as the first national brand campaign on 1 Feb 2024. Koto led brand strategy and identity foundations (logo and colour foundations, tone-of-voice principles, and expression directions such as illustration); I owned the product translation, which is what this case study is about: tokens, components, UX patterns, performance and accessibility guardrails, experimentation, and rollout across the customer surfaces.

My role, and who I worked with

I was Product Design Lead, accountable end-to-end across UX, UI, content patterns and design-system governance, owning the token model, the component strategy, the rollout playbook and the funnel-critical UX decisions. We ran as a core working group of ~10-15 across Product Design, UX Research, Frontend, Backend and Platform, and Brand and Marketing, with my day-to-day partners being the Head of Product Design, the Brand and Marketing Director, Design System and UX Engineering, the Frontend Tech Lead, the Analytics Lead, and the Experimentation and Performance owners.

Surfaces, users and the funnel in scope

The primary surface was the responsive web booking experience from discovery through the booking funnel, supported by CRM and transactional templates (confirmation and manage-booking communications) and by cross-surface parity rules for the native iOS and Android apps (typography, colour, tone and key components), with app adoption sequenced separately from the web funnel migration. The customers were families after best-value packages with clarity on rooms, board basis, transfers and baggage; couples moving quickly from inspiration to a confident booking; budget and deal seekers who need price clarity and filters that avoid surprises; and last-minute bookers who need speed plus reassurance. Five funnel steps were in scope: Search to SRP, SRP to PDP, PDP to checkout start, checkout and payment, and Manage Booking. All of it ran inside hard guardrails, conversion and rollback thresholds, Core Web Vitals budgets, WCAG 2.1 AA accessibility, PCI and payment constraints, and localisation readiness, which the Challenge details.

The job was to deliver the new loveholidays brand across the highest-value booking journeys, SRP to PDP to Checkout to Manage Booking, without hurting conversion, while actively reducing the customer anxiety caused by price ambiguity and buried reassurance. Travel booking is fiercely competitive and the customer experience is what earns loyalty and preference, yet customers struggled to navigate the platform, understand the range of holiday options, and find clear booking information. The opportunity was to redesign the experience to be more intuitive, engaging and reflective of the rebrand, with a particular focus on the communication around managing bookings and expectations.

Why it was hard

• Highest commercial risk sat at payment. The payment step, and the step immediately before it, had the tightest tolerance for UI change and the most visible failure modes.
• Mixed-brand migration risk. Old and new UI had to coexist, and any seam could look like a price change, reduce trust, or confuse the funnel.
• Performance was part of trust. Typography, colour and illustration changes could regress LCP, INP or CLS on high-traffic pages like SRP.
• PCI-adjacent constraints. We had to avoid destabilising hosted and isolated card-entry fields, 3DS and auth flows, and payment submission behaviour.
• Localisation readiness. Expansion, including Germany from 2 May 2023, required patterns that tolerate longer strings, different formats and market-specific terms.

The failure modes we designed against

Three specific ways this could go wrong shaped the work: a perceived price change from mixed-brand seams shifting the hierarchy between total, per-person and deposit; a loss of reassurance about what is included (bags, transfers, board basis) at the decision point; and payment anxiety from unfamiliar patterns or unclear error handling.

The non-negotiables (guardrails and rollback)

Because payment stability was paramount, success was defined defensively, with threshold-triggered rollback:

• Checkout completion: roll back if the conversion index dropped < 98 vs control for ≥24 hours, or < 97 for ≥6 hours.
• Payment-step drop-off: roll back if the drop-off index exceeded 103-105 sustained for ≥6 hours.
• Payment error rate: roll back if the error index exceeded 110-120, or if any critical category (gateway or auth) spiked for ≥60-120 minutes.
• Core Web Vitals budgets: LCP p75 ≤ 2.5s, INP p75 ≤ 200ms, CLS p75 ≤ 0.1.
• Accessibility baseline: WCAG 2.1 AA across funnel-critical flows.

Under all of it, the definition of a win stayed ordinary and human: a user-friendly, engaging and seamless booking experience that genuinely reflected the new identity, addressed how holidaymakers actually decide, and moved loveholidays toward being a leading choice in online travel booking, improving satisfaction, loyalty and conversion.

I ran the rebrand as a programme in phases rather than a single switch-over. The public refresh set the identity direction; from there, through H1 and H2 2023, I led the internal work to translate that identity into product-ready guidelines and guardrails: tokens, components, content patterns and documentation, with the 2023 deepening of brand expression (illustration direction and broader work with Koto) folded in so the product could carry the brand without harming clarity or performance. From May 2023 I added localisation-readiness rules (string-expansion tolerance, locale formats, template flexibility) as Germany launched as weloveholidays with an in-market team in Düsseldorf, and through 2024-2025 we ran the phased funnel rollout and optimisation across CRM templates, SRP, PDP, checkout and Manage Booking, timed so the product matched the brand promises as national campaign activity began.

Who I worked with, and the brand voice

A significant part of my role was leading the new brand personality and voice with the Head of Product Design, the Brand Director and Koto's team: a personality built to feel knowledgeable, trustworthy and engaging, aligned to the strategic goals and the brand promise. Brand and Marketing leadership plus Koto kept the implementation true to the identity (tone, colour, illustration boundaries) without harming scanability or trust; Engineering across Frontend and Platform implemented runtime theming, reduced mixed-stack seams and held the performance budgets; and Research and Analytics ran the usability and interview programmes and watched the guardrail dashboards during rollout. Governance ran through a weekly design-system council (design, frontend, brand, accessibility and performance) plus lightweight RFC reviews for new patterns and exceptions. The artefacts I owned were a component inventory with an old-to-new mapping, a migration tracker (routes, owners, readiness gates, feature-flag status), and the funnel guardrails dashboard and rollback playbook; the migration tracker and the guardrails checklist were the most-used across teams, because they let squads ship without re-litigating risk on every release.

How I tested it

Research combined roughly 24-36 moderated usability sessions (remote and in-person) with about 12-20 customer interviews spanning families and couples, first-time versus repeat, deal-seekers and last-minute bookers, alongside funnel analytics on consistent event definitions, a support-and-contact theme analysis, and funnel-safe experiment learnings during rollout. Sessions were weighted toward the riskiest scanning and decision surfaces: 10-14 on SRP, 8-12 on PDP, 4-8 on Checkout and 2-4 on Manage Booking. For Germany we combined German-language expert review of key templates, pseudo-localisation sweeps to stress-test long strings and layout resilience, and typically 5-8 in-market usability checks on the comprehension of pricing, inclusions and cancellation terms. We tested three end-to-end scenarios: find and book, a last-minute reassurance booking, and a Manage Booking cancellation or change. The contact analysis set the priority order: pricing and inclusions confusion (~30-40%), cancellation and change fees clarity (~25-35%), and payment and authentication issues (~15-25%).

What we built

I implemented the rebrand as a dual-theme design-system rollout rather than a single big-bang UI rewrite, so funnel-critical journeys could migrate incrementally while the conversion and performance guardrails stayed armed. The stack was React and Preact on Webpack, with semantic design tokens compiled to CSS custom properties for runtime theme switching by attribute or class: Preact carried the most performance-sensitive, high-traffic surfaces such as the SRP shell to keep bundle weight down, while React took the newer or more complex modules where its ecosystem and developer velocity mattered, and we reduced the mixed-stack seams as migration progressed. The tokens were layered so the brand could change without breaking UX meaning: global raw values (blue.500, yellow.400, neutral.900), semantic roles (color.bg.brand, color.text.primary, color.cta.primary.bg), and component-level tokens (button.primary.bg, price.total.emphasis), documented across Figma libraries, a Tokens Studio and Style Dictionary pipeline, Storybook for QA and parity, and zeroheight as the system hub.

To prevent mixed-brand seams the theme was feature-flagged by session and locked at funnel entry: a single theme assignment was persisted (cookie and local storage plus server-side flag context) and passed across routes, cross-theme navigation within a booking session was blocked, and shared entry points (deep links, CRM entry, Manage Booking) were forced to a consistent theme. Payment was ring-fenced: hosted and isolated card-entry fields, 3DS and auth flows, and critical submission behaviour were treated as do not touch, so changes stayed on the surrounding UI, error messaging, reassurance copy and non-sensitive inputs, with card capture kept isolated through provider integrations that reduce PCI obligations. The three hardest areas were the price module and breakdown (complex business rules, localisation formats, reassurance content and density all at once), SRP filters (information architecture, defaults and progressive disclosure at performance-critical scale), and checkout forms and validation (accessibility and error recovery under PCI-adjacent constraints); how each was resolved is in the Decisions.

At the PDP, the commitment point, I standardised the price, inclusions and reassurance module into a fixed order so customers met the answers in the sequence they actually ask them: first the total price (including what you pay today when a deposit or instalments apply), then what is included (board basis, baggage, transfers and key fees or taxes), then reassurance (protection, support and a cancellation summary), and finally expandable detail (the per-person breakdown and optional add-ons). The module sat immediately above or beside the primary CTA, with a sticky summary on scroll for mobile, so people stopped re-checking and hesitating before they committed.

SRP: a high-signal hierarchy that does not inflate the page

On the results page I regrouped filters into a small set of high-intent clusters, Essentials, Budget, Location and Hotel quality, with progressive disclosure for the long tail. Cognitive load came down by promoting the high-value filters, demoting the rarely used ones, and using sensible defaults such as a Recommended sort with clear override states, all while protecting performance on a very high-traffic page.

Reassurance microcopy, systemised

I documented reusable reassurance lines so customers saw consistent language at every decision point:

• Financial protection: "Protected booking (ATOL/financial protection applies)."
• Transparent inclusions: "What's included in this price: flights + hotel + [key items]."
• Flexible payments: "Low deposit today, pay the rest later."
• Cancellation clarity: "Cancellation terms shown before you pay."
• Support availability: "Help is available in-app and online if plans change."

Localisation-ready layouts and content rules

So the same patterns could scale to new markets, including Germany, layouts were built to wrap before they truncate and to avoid fixed-height containers, legal copy sat in responsive containers with expansion tolerance, currency and date formats followed the locale, designs tolerated +30-50% text length without breaking hierarchy, and breakpoints preserved price and inclusion emphasis over pixel-perfect alignment.

We measured funnel impact through phased rollouts and controlled comparisons. The headline readouts below are expressed as indexed changes from a baseline of 100, evaluated over a 4-week post-release window at roughly 50% traffic exposure, with the rollback triggers armed throughout.

What we learned, and what changed

Three findings from usability testing drove the biggest design changes, each with a measured comprehension outcome:

• "What's included?" was the confidence-breaker on PDP. Customers repeatedly could not explain baggage, transfers or board basis without hunting across the page, so I moved the price, inclusions and reassurance answers next to the primary CTA in a fixed order. Inclusions comprehension (task success) improved: index 100 → 120-135.
• SRP was dense enough to hide good matches. Under time pressure customers scanned past relevant options and found the filters heavy, so I rebalanced the hierarchy to make price, board basis, rating and key perks the primary scan targets and regrouped the filters. SRP decision speed (time-on-task) improved: index 100 → 110-120.
• Cancellation fees and outcomes drove Manage Booking anxiety. Customers could not state what fee would apply or what refund to expect, matching the cancellation-and-change theme from the contact analysis, so I clarified the quote breakdown and standardised cancellation language across Manage Booking and the CRM templates. Cancellation comprehension (task success) improved: index 100 → 125-145.

Funnel outcomes (guardrail-first)

• Checkout completion: index 100 → 99-102, held within guardrails throughout the rollout.
• SRP to PDP click-through: index 100 → 101-108.
• PDP to checkout start: index 100 → 100-110.
• Payment-step drop-off: index 100 → 98-103, within tolerance.
• Payment error rate: index 100 → 95-105, stable. The top monitored categories were authentication and 3DS failures, validation errors, gateway and provider errors, and timeouts.

Support, performance and delivery

Contacts per booking reduced slightly (index 100 → 92-98), with the biggest movers aligned to the known pricing-and-inclusions and cancellation-and-change themes while payment-related contacts held flat or reduced. On performance we held the Core Web Vitals budgets as release criteria and tracked them via RUM p75: LCP improved (index 100 → 110-140), INP improved (index 100 → 105-130), and CLS improved (index 100 → 110-160); after font subsetting and preloads we reduced FOIT and FOUT incidence and improved LCP by approximately 5-15%, validated with RUM web-vitals, Lighthouse spot-checks and repeatable lab runs on representative devices. The delivery machine behind this shipped with roughly 60-90 components and 250-450 semantic tokens, was adopted by about 4-8 squads, and was governed by the weekly council plus roughly 4-10 RFCs per month, which kept bespoke UI out of the funnel and prevented regression during the dual-theme period.

Specific commercial metrics are withheld due to company confidentiality policies. Results are expressed as indexed changes, ranges and guardrail outcomes validated through controlled experiments and phased rollouts.

A few lessons are worth keeping. Dual-theme only works with strong session locking: feature-flagging alone was not enough, and locking the theme at funnel entry while guarding deep links is what prevented the most damaging "a seam looks like a price change" perception. Token semantics protect UX meaning: keeping global, semantic and component tokens separate is what let us tune brand expression without breaking price hierarchy, contrast or density. And two safety rules earned their keep: mixing React and Preact by where performance versus tooling mattered kept the Core Web Vitals budgets realistic during migration, and treating card capture and 3DS as an explicit do-not-touch boundary reduced risk while still leaving room to improve errors and reassurance.

What the process taught me

Guardrails de-personalise debate. When brand expression collided with funnel safety, having an explicit hierarchy (conversion and payment stability first, then accessibility, then brand flourish) and defined rollback thresholds kept decisions fast and objective instead of a matter of taste. Migration artefacts were leverage: the migration tracker and the guardrails and rollback checklist did more to keep squads aligned, without slowing delivery, than any amount of documentation. And localisation rules should ship early: doing the Germany readiness checks (expert review, pseudo-localisation, in-market testing) up front prevented costly refactors once expansion stopped being optional.

What I would do next

Three things are queued, each with a real trade-off:

1. Extend design-system coverage to long-tail and edge-case flows (uncommon booking scenarios, rare inclusion combinations, edge reassurance moments). This needs the component library and token coverage expanded to handle edge states without bespoke funnel UI, buying less regression risk and faster iteration later in exchange for more upfront system work.
2. Strengthen localisation and content scalability by standardising multi-language templates and layouts across web, in-app and CRM, including longer strings and market-specific legal constraints. This means codifying content rules (wrap and expand), locale formats and template constraints into the system hub and release process, trading tighter content governance and slightly higher per-release coordination for far easier multi-market scaling.
3. Mature measurement with component-level attribution, instrumenting component releases so funnel changes can be attributed to system updates, with automated guardrail reporting for checkout, payment stability, contacts per booking and Core Web Vitals. This needs analytics and engineering investment in consistent tagging, dashboards and alerting inside the release workflow, an upfront cost before the iteration-speed benefit compounds.

What I deliberately deferred, and why

I intentionally deferred a deeper SRP redesign, personalisation, richer Manage Booking self-serve, animation polish and long-tail content pages, to protect conversion during the dual-brand migration and keep payment-stability risk low. What would justify picking that work up now is a stable baseline of funnel metrics over time with no guardrail breaches, higher design-system coverage so fewer bespoke elements remain in the funnel, clearly sized funnel opportunities backed by analytics and usability evidence, and localisation-ready patterns so improvements scale beyond UK and English, including Germany.

We designed to a WCAG 2.1 AA baseline across the funnel-critical journeys, and treated the common regressions as release-blocking rather than as backlog items. Contrast, focus and form errors stopped a release.

How we validated it

• Automated checks. axe and Lighthouse, plus component-level checks in the component explorer where that was feasible.
• Manual review. Keyboard navigation and screen-reader spot checks on the results page filters, the product page call-to-action modules, and the checkout forms.

What actually broke during adoption

• Focus visibility and focus order, especially on filters and long forms.
• Error messaging and its associations, making sure an error was announced and tied to the field it belonged to.
• Colour contrast, where new brand accent combinations risked failing AA.

Rollout sequenced by commercial risk

I sequenced adoption from the lowest commercial risk to the highest, so the system proved itself stable before it went anywhere near payment.

1. Customer messaging templates. High visibility, no checkout risk.
2. Search results page. Brand expression, navigation and performance gains.
3. Product detail page. Inclusions and reassurance.
4. Checkout. The highest risk step, and only once the system had proved stable.
5. Manage booking. Clarity on changes and cancellations.

Guardrails and the rollback playbook

Every phased release ran against funnel health with rollback triggers agreed in advance, so the decision to pull a release was made before anyone was under pressure to make it.

• Checkout completion. Roll back if the index falls below 98 for 24 hours or more, or below 97 for 6 hours or more.
• Payment-step drop-off. Roll back if the index stays above 103 to 105 for 6 hours or more.
• Payment error rate. Roll back if the index goes above 110 to 120, or if a critical category such as gateway or authentication spikes for 60 to 120 minutes.

Event definitions, so the numbers meant one thing

Checkout start is the first arrival on checkout step one, triggered by the product page call-to-action transition. Checkout completion is the booking confirmation success state. Fixing those two definitions is what made the guardrails comparable between releases.

How we resolved the standing tension

The tension never went away: brand expression against funnel safety, which in practice meant motion and image density against performance and clarity. We resolved it with an explicit order rather than case by case. Conversion and payment stability first, then accessibility, then brand flourish, validated with usability evidence and enforced through the guardrails above.

To respect confidentiality policies, commercial performance is reported using indexed changes, ranges and guardrail outcomes rather than absolute conversion or revenue figures. The dates cited are public launch anchors: the 5 Dec 2022 brand-refresh coverage, the 2 May 2023 Germany launch as weloveholidays, and the 1 Feb 2024 national campaign. This material is shared for portfolio purposes, follows Fair Dealing guidelines, and does not disclose confidential business information.