Case 02 — Building the UX System
Building the UX System
Designing the process, methodology and feedback loops that made research-led product development real at LINK
When I joined LINK, there was no UX process. Designers produced screens. Product managers defined requirements. But the connective tissue between customer insight, product decision, and design execution didn't exist. Validation was whoever shouted loudest in a meeting.
Research happened informally or not at all. 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.
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.
The revamped Double Diamond
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.
But the standard Double Diamond wasn't enough. I adapted it to the specific constraints of LINK: a technically complex B2B platform, a distributed team across three countries, product managers new to UX methods, and stakeholders who needed tangible outputs at every stage.
Key constraint I introduced: no other step can start until research is complete. No wireframes during discovery. No feature specs. The pressure to skip ahead was constant. The rule was non-negotiable.
The four-phase process in practice
Step 1 — Discover: The PM defines the topic. The researcher runs primary work: customer interviews, sales and support interviews, legacy platform analysis, competitive analysis, data analytics. Output: raw research findings, not conclusions.
Step 2 — Define: The researcher synthesises findings into themes, builds opportunity areas using HMW questions, defines the core problems. I introduced the practice of presenting research findings formally before moving forward — a step most teams skip but that prevented expensive downstream disagreements.
Step 3 — Develop: With the problem defined, the solution builder begins ideation using Figma templates I created to standardise the process. Exploring many possible solutions before narrowing.
Step 4 — Deliver: The solution is prototyped, tested with real users, refined, and handed to engineering with full specs. I introduced Dovetail for recording and synthesising validation sessions, and Usersnap to capture continuous in-product feedback — making validation ongoing rather than a pre-launch event.
The research infrastructure
The methodology was only valuable if the team had the tools and contacts to execute it. Qualitative internal: structured interviews with sales and support teams across Northern Europe, workshops designed to extract knowledge that doesn't surface in interviews, systematic legacy platform analysis.
Qualitative external: customer interviews following a structured protocol with Think Aloud methodology, validation workshops with prototypes at multiple fidelity levels, all sessions recorded and synthesised in Dovetail.
Quantitative: product analytics tracking implemented from day one inside the portal — something that required sustained advocacy inside a company that historically measured very little. Support ticket analysis via Salesforce. Structured competitor and market analysis.
The Customer Program
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 surveys never would.
I started by talking to our sales representatives — the people who knew which accounts were engaged, forward-thinking, and willing to invest time. Participants received early access to new features and a direct line to the product team. In return, they committed to workshops, prototype testing, and interviews.
Over time, I built the program into the portal itself: customers can now sign up directly from within MyLINK, submit feedback through an integrated Usersnap widget, and participate in research on their own schedule. Customer insight stopped being something we had to go and find. It started coming to us.
In parallel, I built a broader contact database of 25+ external users across companies including DHL, DNB, Volvofinans Bank, and NAV — tracking which platform they use, what features they rely on, how frequently they log in.
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 different tolerance for friction.
We also beta-launched an AI-assisted message composer feature within the portal — the first AI-native capability in the product — in collaboration with an external AI partner. This gave the team direct experience with AI product design challenges: managing user expectations, handling failure states, deciding where AI adds value versus where it creates confusion.
4
Mandatory phases
Discover · Define · Develop · Deliver — no skipping
5+
Enterprise clients
In the Customer Program — including DNB and BAS
25+
External contacts
Research database — DHL, NAV, Volvofinans Bank and others
1
Searchable knowledge base
All research stored in Dovetail, accessible to every PM
3
AI tracks
Learning Hub — product design, UX practice, PM awareness
The hardest part of building this system wasn't the methodology — it was the culture change. Getting people to slow down before the first wireframe, to present research before proposing solutions, to treat validation as a prerequisite rather than a nice-to-have — that required sustained advocacy over a long period.
The thing that worked was making the process feel faster, not slower. I reframed research not as a gate that delayed delivery but as an investment that prevented rework. When an engineer avoided two weeks of wasted development because a research finding changed the spec, that was the argument. I made those moments visible.
“What surprised me most wasn't the business impact — though that was real. It was how much better the daily working life of the 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.”