CASE STUDYLINK Mobility · 2021 — Present

Building a research system
inside a company that had
never had one.

How I designed the methodology, infrastructure and culture that transformed how LINK built products — and made research-led design the default, not the exception.

UX Process DesignResearch MethodologyTeam BuildingCustomer ProgramAI Integration

confluence.linkmobility.com / ux-methodology

UX PROCESS · v3.2Active

The Revamped Double Diamond

01 — Discover

Customer interviews

Support ticket analysis

Data analytics

Competitive research

02 — Define

Research synthesis

HMW questions

Problem framing

Research presentation

03 — Develop

Ideation sessions

Wireframes & flows

Figma templates

Prototype variants

04 — Deliver

Usability testing

Dovetail synthesis

Engineering specs

Validation sign-off

Non-negotiable rule: No phase starts until the previous one is complete. No wireframes during research.

Client

LINK Mobility

Sector

CPaaS · Enterprise messaging

Role

VP of UX & Product Manager

Scope

Process · Tools · Team · Culture

Timeline

2021 — Present

01 — The situation

There was no shortage of opinions about what customers wanted. There was a shortage of evidence.

When I joined LINK, there was no UX process. There were designers who produced screens, and there were product managers who defined requirements. But the connective tissue between customer insight, product decision, and design execution didn't exist. Research happened informally or not at all. Validation was whoever shouted loudest in a meeting. Delivery often meant engineering built something nobody had tested with a real user.

This wasn't unusual for a company that had grown through acquisitions — each product team had its own habits, its own tools, its own definition of done. But it meant that building MyLINK Portal on top of that foundation was like building on sand. If we were going to create something that customers would actually use, we needed a shared system for understanding them first.

I built that system from scratch. This case describes how.

The design team produced screens. The engineering team built features. Nobody had spoken to a customer first. That was the problem I was there to solve.

02 — My role & scope

I owned the whole system. Not just the methodology — the tools, the team, the culture, and the buy-in.

Methodology design

Designed and implemented the four-phase Double Diamond process adapted for a distributed B2B platform team.

Research infrastructure

Built the tooling, templates and research contact network — Dovetail, Usersnap, Figma templates — that made research operationally possible at scale.

Customer Program

Created and scaled the co-creation initiative with enterprise clients — including DHL and DNB — turning ad-hoc interviews into a structured ongoing relationship.

Team development

Fortnightly retrospectives, shared Figma templates, and Confluence documentation that built a common working culture across Spain, Macedonia and Bulgaria.

AI integration

Launched the internal AI Learning Hub and beta-tested AI-native portal features — building the team's capability to design for AI-augmented workflows.

Organisational change

Built research credibility inside an organisation that had never formalised UX — turning scepticism into advocacy, one concrete outcome at a time.

03 — How I built it

Four interlocking pieces. Each one making the next one possible.

The methodology

I chose the Double Diamond as the structural framework — not because it was fashionable, but because it addressed the specific failure mode I saw at LINK: teams were jumping to solutions before they understood problems. The Double Diamond's core principle — doing the right things before doing things right — was exactly the discipline the organisation needed.

But the standard Double Diamond wasn't enough. I adapted it to the specific constraints of a distributed team across three countries, product managers new to UX methods, and stakeholders who needed tangible outputs at every stage to maintain trust.

The non-negotiable rule: no phase starts until the previous one is complete. No wireframes during research. The pressure to skip ahead was constant. The rule never moved.

Solution Building & Validation

Product Requirements Template

UX & Design Methodology

The infrastructure

The methodology was only valuable if the team had the tools and contacts to execute it. I built the infrastructure that made research operationally possible at scale.

For qualitative internal research: structured interviews with sales and support teams across Northern Europe, internal workshops to surface tacit knowledge, and legacy platform analysis to understand what customers actually used.

For qualitative external research: customer interviews using Think Aloud methodology, validation workshops at multiple fidelity levels, and all sessions recorded, transcribed, and synthesised in Dovetail — creating a growing institutional knowledge base rather than one-off insights.

For quantitative research: product analytics tracking in the portal from day one (something that required sustained internal advocacy), and systematic Salesforce ticket analysis to surface patterns that individual interviews couldn't reach.

Interviews & Workshop Guides

Support Tickets Research Methodology

Validation Workshop Guide

Research Methodology

Customer Program — enterprise clients including DHL, DNB, Volvo, Storebrand, Inditex

The customer program

The research infrastructure gave us methods. The Customer Program gave us relationships.

I created the Customer Program from scratch — a structured co-creation initiative that brought a small group of enterprise clients directly into the product development process. The goal was not to collect feedback at scale, but to build deep, ongoing relationships with clients who could tell us things that surveys never would.

I started by working with sales representatives to identify the right candidates: clients who were strategic to LINK, technically sophisticated, and trusted enough by their account managers to have an honest conversation about what wasn't working. The program offered early access to new features and a direct line to the product team. In return: workshops, prototype testing, and interviews.

The program eventually became self-service — customers could sign up from within MyLINK, submit feedback through an integrated Usersnap widget, and participate on their own schedule. That shift — from manually curated to embedded in the product — meant customer insight stopped being something we had to go and find. It started coming to us.

DHL Customer Program

The AI learning hub

In 2025 I launched an internal AI Learning Hub within the UX team — a structured programme to build capability for AI-integrated ways of working across three tracks: AI product design, AI-augmented UX practice, and AI-aware product management.

The curriculum was built on the premise that AI changes not just the tools we use but the type of user we're designing for. Customers who use AI daily have different mental models, different expectations of speed and intelligence, and different tolerance for friction. Our research methods and design patterns needed to evolve accordingly.

In practice, AI integration has already changed how we work. Research sessions are recorded and synthesised with AI assistance — reducing the time from interview to insight. Requirements documents are drafted with AI support. Workshop outputs are processed faster. We also beta-launched an AI-assisted message composer — the first AI-native capability in the portal — giving the team direct experience with the challenges of AI product design: managing user expectations, handling failure states, deciding where AI adds value versus where it creates confusion.

05 — Results

The numbers are a proxy. The real result is what changed in the room.

Mandatory phases
Discover · Define · Develop · Deliver — no skipping

Enterprise co-creation clients
Including DHL, DNB, Volvofinans Bank and NAV

25+

External research contacts
In the structured research database

AI learning tracks
Product design, UX practice, PM awareness

Searchable knowledge base
All research archived in Dovetail — accessible to every PM

Research phases skipped
Since the process became mandatory in 2022

Product managers who had never run a user interview now conduct research regularly. Engineering teams that were once sceptical of UX now ask for research before starting builds. The conversation between product, design and tech has changed — it starts with the problem, not the solution.

Most importantly: the system runs without me carrying it. New team members onboard into a documented process, access a library of past research, and connect with the customer panel through the portal. That's what a system looks like when it actually works.

06 — What I learned

Process change is culture change. The methodology is the easy part.

Process change is culture change. The methodology only works when the people using it believe it makes their work better — not more compliant. I spent as much time on the narrative around the process as on the process itself.

The argument that worked was always concrete: this engineer saved two weeks because a research finding changed the spec before build started. I made those moments visible, consistently, and the organisation's posture towards research shifted because of them. Show the cost of skipping. Not the virtue of not skipping.

The goal was always a system that runs without me. When new team members can onboard into a documented process, access a library of past research, and connect with the customer panel on their own — that's when you know you built something real.

In their words

“What surprised me most after establishing this process wasn't the business impact — though that was real. It was how much better the daily working life of the UX and frontend teams became. Less rework, less confusion, less of that exhausting cycle of building something and then being told it wasn't what was needed. People started enjoying their work more. The process gave them clarity, and clarity gave them confidence. That's not something you can put in a metric, but it's the thing I'm most proud of.”