Scott Walker

Case study

Shipping the replatform across thirteen markets

5 minute read

Client
Eurocamp (European Camping Group)
Year
2023
Role
UX Designer, acting as product owner
Contribution
Coordinated user acceptance testing, ran defect triage with the CMO, built the CMS content model, and trained the market content teams
Team
UK, NL, DE and PL market teams tested and used it · CamdenTech built the front end · Profound Digital wrote and uploaded SEO content · a digital marketing agency and overseas teams set up the additional domains · CMO and CRO manager set priorities
Platform
Web · responsive · 13 markets

Designing the replatform was half the work. The other half was getting it live across thirteen markets without a launch date to hide behind — because the old platform’s licence was expiring and the new site had to earn its traffic rather than be given it. I coordinated acceptance testing across four market teams, ran weekly defect triage with the CMO, built the CMS content model, and trained the people who would live in it.

Thirteen markets, eight languages

LanguageMarketsCount
EnglishUK · Ireland2
DutchNetherlands · Belgium (Dutch)2
GermanGermany · Austria · Switzerland3
FrenchFrance · Belgium (French)2
DanishDenmark1
ItalianItaly1
PolishPoland1
SpanishSpain1
Total 13
Shipped 2023 Three German-language markets, two Belgian ones split by language, and Ireland separate from the UK. Same language, independent market — which is what made the component model work for its living.

The people who tested the new site were the people who ran the old one.

Acceptance testing ran with individuals from the UK, NL, DE and PL teams — colleagues whose day-to-day work was the Tridion CMS we were replacing. They knew the old system’s every workaround, which made them the sharpest testers available and the ones with the most to lose.

My contribution was upstream of the tests themselves. I created the user flows, and those flows were what the test scripts were written from and signed off against. I part-owned the defect log — and it was the defect log, rather than any status report, that I took into the weekly review with the CMO.

SHOT 02 · PROCESS ARTEFACT One defect followed end to end: user flow → test script → defect log entry → triage decision. Job: evidence of a fork, not evidence that work happened. Reconstruct from the flows and the defect log, if either survives — see open items
UAT, November 2022 The chain my contribution actually ran through.

We didn’t move traffic on a date. We moved it when conversion said we could.

A licence expiry is exactly the pressure that produces a big-bang launch. Instead the new site ran alongside Tridion and had to prove itself on live traffic.

The CMO set the allocation. We monitored conversion rate with the CMO and the data team, comparing the new site against the old one running in parallel on the same days, in the same markets, with the same demand. Only once the new site cleared a satisfactory threshold did allocation increase — 20% of traffic first, then 80%, then the remaining markets.

I didn’t own that decision and I want to be precise about it: the CMO decided, the data team measured, and I sat in the room where it was read. What I did own was making sure the defects that would have depressed that number were found and fixed before each step up.

The rollout, February 2023

w/c 06 Feb w/c 13 Feb w/c 20 Feb w/c 27 Feb Mar → 1 Colleague beta Internal only. No customer traffic. 2 20% of live traffic to the new site◆ GATED ON CVR 80% still served by Tridion 3 80% of live traffic to the new site◆ GATED ON CVR 20% still served by Tridion 4 Remaining markets follow◆ GATED ON CVR NL, DE, PL, then the rest
Executed as drawn Four stages, each one gated on conversion rather than on the calendar. The old platform stayed live underneath every step.

Weekly, against risk, impact and effort — and I lost the argument about the map.

Every week I met the CMO and the CRO manager to triage what we’d found. We scored against three things: risk, impact and effort. Having a stated framework mattered more than the specific weightings, because it meant an issue could be deprioritised without it being a defeat for whoever raised it.

One I lost. The map carried regional polygons inherited from the old site. I argued they should go: they were business-defined sales regions rather than real geography, so they drew boundaries that didn’t correspond to anywhere a customer could point to. Presenting an inaccurate region seemed worse than presenting none. The polygons stayed, because they had always been there and deviating from the old site made stakeholders nervous. I still think that was the wrong call, and it’s a fair example of the caution the whole project was working against.

One I won. I argued for cutting the content above the fold so product cards came up sooner. Customers arriving on a search-led site don’t want to scroll past marketing copy to reach the thing they came for — the prices, and the sort and filter controls that let them act on them. That one landed, and it’s the same conviction as the search design itself: take everything out from between the customer and a price.

SHOT 04 · THE DECISION SHOT The regional polygons with business sales regions overlaid on actual geography. Job: show why I argued to remove them, and let the reader judge the call that went the other way. New capture of the live map + a geographic overlay
Shipped 2023 — the argument I lost Business-defined sales regions, drawn as if they were places.
  1. 1A polygon boundary that corresponds to no geographic, administrative or colloquial region.
  2. 2Two parcs a customer would consider neighbours, split across different regions by a sales boundary.
SHOT 05 · BEFORE / AFTER Above the fold, before and after. Copy pushed down, product cards pulled up. Job: the change made visible — and the argument I won. Wayback Machine pre-2023 + 2023 capture, cropped to the fold
Shipped 2023 — the argument I won What sat between the customer and a price, and what replaced it.

I configured the CMS myself, which is how I found out what the design system actually did.

Once design and development settled, I and one or two colleagues were given the CMS build: content modelling, component configuration, page building, and migrating existing content. It ran over several months. Profound Digital wrote and uploaded the SEO content onto the pages we created.

Configuring it taught me things designing it hadn’t. Which configuration options affected which markets. How shared components behaved against market-specific and static pages. Where the website’s structure and the development setup actually met. A component model looks sound in a design file; you find out whether it is when you have to instantiate it thirteen times — including three German-language markets and two Belgian ones that shared a language but not a configuration.

The thirteen markets were not my doing alone — it would be unfair to claim that. Overseas teams and a digital marketing agency set up the additional domains for launch. What I owned was the model they were configured from.

SHOT 06 · SYSTEM VIEW The content model: shared components against market-specific and static pages, and which settings cascade to which markets. Job: the systems half of the positioning. Storyblok component structure — export the schema and draw it
As configured, 2023 One model, thirteen instantiations.

Training ten people is how we found out what the component library couldn’t do.

We ran weekly training sessions with around ten people across the UK, NL, DE and PL content teams. The point was to hand over a system. What happened instead was that the system changed.

Two things surfaced almost immediately. Pages needed changing en masse and the CMS didn’t support it — a gap invisible from the design side, obvious within minutes to someone facing two hundred pages. And the component library needed adjusting to present real content well, as opposed to the content we had imagined while designing it. Components kept being optimised as more content came online, which shaped the site and improved conversion as it went.

Training was supposed to be the last step. It turned out to be a research method.

SHOT 07 · PROCESS ARTEFACT A component before and after training feedback, with the real-content problem that prompted the change. Job: show that training changed the system, rather than asserting it. Figma version history — check how far back it reaches
Changed during training, 2023 What ten people using it found that designing it hadn’t.

Prototype slot. A content editor making one change in the CMS and it appearing across market pages. Task-shaped, not a feature tour. Ships as <video controls muted playsinline preload="metadata" poster="…"> with no autoplay, so WCAG 2.2.2 is satisfied by construction, plus a static poster as the fallback.

To build One clip, one idea. It demonstrates the model rather than describing it.

What we rejected: turning Tridion off in one go.

A single cutover was the obvious answer to a licence deadline. It was cheaper, it was faster, and it needed no parallel running.

We rejected it because it offered no way back. A phased allocation cost weeks we didn’t obviously have, and bought a rollback path at every step — on a project where the fallback was a platform we were contractually obliged to leave.

Single cutover against phased allocation

Single cutover

Rejected

1

switch · no parallel running

  • Cheaper — one migration window
  • Faster to the licence deadline
  • No duplicate infrastructure
  • No way back if conversion fell
  • Failure discovered in production, at full volume

Phased allocation

Chosen · February 2023

4

stages · old platform live throughout

  • Cost weeks against a fixed licence expiry
  • Both platforms running in parallel
  • Conversion compared on live traffic
  • Rollback available at every step
  • Failure discovered at 20%, not 100%
Decided late 2022 The rejected option was cheaper on every axis except the one that mattered: what happens if conversion falls after the switch.

The result

Thirteen markets live from one content model, with the rollout gated on conversion at every step rather than on the calendar.

The component library that came out the other side had been revised by the people using it, not just the people who designed it.

SHOT 09 · OUTCOME The component library as first configured against its post-training state. Job: the outcome is the system, and the system was changed by its users. Figma version history — depends on how far back it reaches
First configured → post-training, 2023 What ten content editors changed about a library they didn’t design.

Reflection

The component library kept changing as real content arrived, which is a polite way of saying the model wasn’t right when we froze it — the content teams should have been in the room during content modelling rather than meeting it in training.

The bulk-editing gap we found in those sessions was a limitation we designed around rather than solved. And I’d fight the polygon argument again, better: I had the reasoning right and made it a taste argument when I should have made it a customer-comprehension one, with evidence.