The situation

In 2025, a previously well-performing home broadband sign-up journey started quietly failing customers at one of its most important steps. The business found out from a stakeholder escalation, not a dashboard. There wasn't yet a clear picture of what, specifically, was broken, only that conversion wasn't where it should be.

The stakes

This was a flagship acquisition journey: every week of underperformance was directly lost revenue, and every failed sign-up was a customer likely lost to a competitor. Just as important, the failure had surfaced through an escalation rather than monitoring, which meant confidence in the digital channel was already damaged before the diagnosis had even begun. A rushed, wrong fix would have made both problems worse.

My decisions

The result

The combined fixes delivered a 28% increase in completed orders and a 16% increase in cart additions for the home broadband journey, with conversion recovering to pre-incident levels within weeks. Sustained focus on the related support journeys also drove roaming call centre demand down from 20,000 to under 15,000 calls per month, and billing calls fell from 28,000 to around 13,000 over the same period, a direct and continuing cost-to-serve saving.

What I would do differently

Earlier, more active monitoring of the analytics, so an issue like this is flagged before it needs an escalation to surface it. And more in-person sessions alongside the remote ones, to get a sharper read on exactly where people were struggling, not just that they were.

What travels: the pattern here isn't telecoms-specific. Triangulate before you touch anything, and sequence fixes so you can tell which one worked.

The situation

By 2025, the SIM Calculator had become a management challenge before I became involved. The tool was strategically important, the business had flagged it at senior level, and previous approaches had not delivered the uplift needed. The project was stalled, with a lot of stakeholder attention on it.

The stakes

Beyond the direct revenue, the risk was methodological: under pressure, the easy path was to rush straight into a live A/B test on guesswork, which could have damaged the existing experience and produced noise instead of answers. Part of my job was making sure the designer could focus on getting it right rather than getting rushed into a fix that wouldn't hold up.

My decisions

A regression, diagnosed together

Mid-project, usage data showed a sudden split: customers who had previously interacted with the calculator and gone on to purchase were now stalling at the same point after a release. My early hypothesis was that a UI change was responsible: a background colour had been removed, breaking the visual grouping that tied related sections of the page together. But a hypothesis isn't a diagnosis. Rather than act on assumption, the designer and I worked with the CRO team to test it properly, pairing their experiments with unmoderated sessions where customers talked through the journey aloud. The combination confirmed it: without the visual structure, the calculator's steps read as disconnected, and people lost confidence partway through.

Screens are from the shipped product; the "before" state is reconstructed for illustration.

This was as much a coaching moment as a design one. The designer came out of it with a sharpened diagnostic instinct, and the whole team learned to treat visual-only changes as carrying real UX risk, not just cosmetic risk.

The result

A 29% overall conversion uplift across the evolution of the calculator, with the most recent iteration live and showing a continued positive trend. The qualitative-first, iterate-then-A/B methodology became the standard approach for conversion optimisation work across the site.

What I would do differently

The background-colour regression should never have reached production unexamined. It's part of why I later formalised a design review gate covering visual consistency alongside usability and accessibility: cheap to run, and it catches exactly this class of "harmless" change.

What travels: any sector with a conversion funnel has this exact failure mode. Visual changes shipped as "cosmetic" that quietly break comprehension.

The situation

Accessibility at Three didn't become a personal focus because of a policy. It became one because I watched a participant try, and fail, to buy a phone. Back in 2014/15, early in my time as UX Architect, I worked with an accessibility agency, DAC, to bring one of their participants in for a stakeholder demo. He had a visual impairment and used a screen reader as a vital part of his everyday life. We sat him in front of a computer connected to a projector and asked him to do something simple: buy a phone and a plan, the same task most customers complete in a few minutes. He couldn't do it. Stakeholders watched him stall at the first real obstacle and never recover. That session didn't fix anything by itself, but it changed how I thought about accessibility: from a compliance line item to a design failure with a face attached to it.

The stakes

Nearly a decade later, running the enterprise programme between 2023 and 2025 with the authority to act at scale, I found the cultural problem hadn't gone away. Short deadlines meant accessibility was routinely the thing signed off "to fix later", and later rarely came. The stakes were threefold: vulnerable customers locked out of essential services, a growing regulatory exposure as accessibility law tightened, and, heading into the VodafoneThree merger, intense scrutiny on every pound of spend. There was a real, vocal view that we'd "spent loads of money on accessibility before and it brought no benefit, why waste more again."

My decisions

What the work surfaced

While running the programme, the same pattern from the DAC session kept showing up in our own usability testing. We started asking participants directly whether they had specific accessibility needs, and found recurring difficulty among people with dyslexia and autism, who frequently struggled with information density and decision overload, not just the more visible access needs people usually design for first. That finding changed how the team wrote and structured content, not just how it built interfaces.

The result

100% of critical and high-severity issues were resolved to the WCAG 2.2 AA target. Accessibility moved from a pre-launch afterthought to a standard part of the definition of ready, and the team built genuine in-house competency rather than relying on external auditors for everything. The discipline held after the programme ended, which was the real test.

What I would do differently

More in-person or moderated remote testing, sooner. Issue counts and severity ratings are useful for prioritisation, but they don't build conviction in a room the way watching someone struggle does. I'd run more sessions like the DAC one, earlier and more often, because that's what actually changes how people design, not just what they fix.

What travels: the playbook of external audit, revenue-and-vulnerability prioritisation, then embedding into the definition of ready transfers to any organisation now inside the scope of accessibility law. Which is most of them.

The situation

From the announcement in 2023/24 through to completion in 2026, two large organisations with different design cultures, brand standards and digital estates were converging in the UK's largest telco merger. For the UX function, it represented both a significant risk (the potential loss of years of design standards and cultural investment) and an opportunity to demonstrate the strategic value of design at the highest level.

The stakes

The realistic downside was that UX would be treated as a delivery function during the transition: handed briefs, asked to execute, excluded from the strategic conversations that would define what the merged organisation looked like. Underneath the organisational question sat a human one: people's roles, confidence and standards were all in play, and a team that felt disposable would not have done its best work at the moment it mattered most.

My decisions

The result

UX emerged from the merger as a strategic partner. Design had a permanent seat at the table for flagship business decisions, Wider Leadership Team presentations became routine, and product decisions at the highest level were being made with UX insight at their core. Team engagement stayed rated 'Excellent' through the most turbulent period the function had faced.

What I would do differently

I'd have built the ROI evidence base earlier. The internal intranet documenting our methods and their commercial impact arrived partway through the merger; having that library ready before integration conversations began would have made every negotiation faster and would have pre-answered the scepticism that surfaced around budgets, particularly on accessibility.

Where it ended

There's a postscript worth being straightforward about. The merger changed the shape of the business, and in 2026 the restructure reached the design function itself. After 20 years with one organisation, it felt like the right moment to close the chapter rather than open a familiar one: the work I'd set out to do was done, the team and standards I cared about were in good hands, and the business I'd be staying in was no longer the one I'd built them in. I left in April 2026, by choice as much as by circumstance, ready for a new challenge. The function I left behind was stronger, more strategic and more commercially fluent than the one I inherited, and that's the outcome I was there to deliver.

What travels: the mechanics apply to any restructure or acquisition. Make design the continuity function, and it stops being the disposable one.

This case study covers two initiatives with one goal: making good design the path of least resistance. The Ecosphere fixed how the organisation saw its own journeys; the AI-augmented research practice fixed how fast the team could learn about them. Together they were the DesignOps layer everything else ran on.

Part one: one map, every journey

Before the Ecosphere, squads worked in silos. Product managers had their own roadmaps, designers their own Figma files, researchers their own libraries, but there was no single view of how journeys connected or contradicted each other. Late-stage redesign requests were frequent and costly, and accessibility issues were being caught too late.

I identified the gap during a cross-functional retrospective in 2024, secured buy-in from Product, Engineering and the Wider Leadership Team, and designed the architecture: journeys tiered by type, each carrying status, platform, research and Figma links. The SharePoint Customer Journey Library became the living documentation layer, Ecosphere updates went into the team's definition of done, and a design review gate used the Ecosphere as its audit baseline.

Late-stage design revisions dropped by 30%. For the first time, product, design, engineering and marketing were genuinely working from the same map instead of four separate versions of the truth. The library also proved unexpectedly valuable during the VodafoneThree merger, giving the incoming organisation a clear picture of Three's entire digital estate without us having to recreate it from scratch.

Part two: speed without losing rigour

The team was struggling to keep pace with product demand. Traditional research timelines were too slow and insight synthesis was a bottleneck. In 2025, I led the rollout of an AI-augmented research approach: synthetic user groups for rapid early-stage concept testing, AI note-taking across all in-person moderated sessions, and a workflow for automated transcription and thematic analysis, always paired with researcher review for quality assurance. A library of reusable research artefacts made each subsequent study faster than the last.

Research synthesis time dropped by around 60%, and the team ran three times as many studies in 2025 as it had in 2024. Synthetic users became a standard de-risking step before committing to full research programmes, never a replacement for them.

What this adds up to

Neither initiative used the word at the time, but this is DesignOps: shared journey governance, a research operating model, quality gates, and tooling that multiplies a small team. It's the work I'd expect to repeat, adapted, in any organisation serious about scaling design without scaling headcount at the same rate.

What I would do differently

Two things. I'd measure adoption of the journey library formally from day one; I know it changed behaviour because the arguments stopped, but "the arguments stopped" is weaker evidence than a usage dashboard. And I'd write the guardrails for synthetic users before the rollout rather than during it, because the temptation to let cheap synthetic insight substitute for real research is constant and needs a stated policy, not just a manager's judgement.

What travels: this is the operating model I'd expect to rebuild, adapted, anywhere serious about scaling design without scaling headcount at the same rate.