02 – RESEARCH
Three findings rewrote the product plan.
Instead of treating research as a one-off stage validation, two separate research agencies supported continuous testing. Crucially, we tested with users who were actively living through the migration – capturing real behaviour and real anxiety.
1
Migrating means life admin – few people want it
The initial FAQ-style onboarding approach failed immediately because users simply weren't reading the pages. We realised the time and effort required to explore information had to shrink, not grow.
2
"Will my Direct Debit change?" was the real question
Customers didn't care about abstract "here's what's new" marketing copy. They needed specific, practical answers about their money first. Everything else was noise until that was resolved.
3
Migration and acquisition are fundamentally different jobs
A generic, one-size-fits-all template failed both audiences. Someone being forced to move and someone choosing to sign up needed completely distinct experiences, not shared copy with swapped logos.
03 – DECISIONS
Four audiences, four different pages.
To respect user context, our first structural decision was to reject a one-template-fits-all approach and design four distinct landing journeys for four distinct audiences.
DECISION 01
Separating Migration and Acquisition Architecture
The default assumption going in was a single template shared across both audiences – fewer templates to build and maintain. I pushed back: a shared template made the business's efficiency the priority, not the customer's understanding. Migration and acquisition needed different journeys, so the content spoke directly to the customer's actual situation rather than making them work to figure out which parts applied to them.
The information hierarchy in practice: reassurance came before anything else. A clear statement that nothing changes immediately–tariff, direct debit, or meter readings–sat at the very top of the page, before any other detail.
1
What's happening and when
A clear timeline of the migration process–setting out what will happen and when–before introducing any detail on what is changing.
2
What you need to do (almost nothing)
Most migrating customers needed to do almost nothing – but stating that plainly took more effort than leaving it implied or unsaid.
3
What's actually changing
Only after reassurance and process clarity did the page address what was genuinely new.
Decision 02
Search-First Architecture Over Browse-and-Expand
The FAQ accordion was the second major structural failure once we tested it. On mobile – where most migrating customers actually landed – long accordion lists buried the specific answer people were looking for underneath expandable headings nobody wanted to tap through. A search-first layout let people type their actual question and land on the specific answer directly, instead of scanning and guessing which heading might contain it.
Rejected
FAQ accordion
Scan 12+ collapsed headings
Tap, read, guess again if wrong
Built
Search bar, top of page
Type the actual question
Land directly on the answer
Decision 03
Modular Email System with Tone Calibration
While standard onboarding assumes a user chose to sign up, migration assumes the opposite. I designed the onboarding email sequence around a deliberate trust curve rather than a single corporate announcement, allowing the tone and content to shift intentionally as the relationship progressed
The onboarding sequence
Email 1
Nothing changes yet
Email 2
You're moving today
Decision 04
A Tone Framework that Scales Across Teams
Brand personality is usually applied uniformly – the same voice everywhere. That doesn't hold up in a migration. I built a framework defining when full brand personality helps a message land, and when it actively gets in the way of clarity that a customer under stress actually needs. Different teams writing migration comms needed a shared, simple rule for which mode applied where, not a static tone-of-voice document nobody consistently used.
