When 10 to 20 systems become one experience: how mapping the full retailer journey revealed what the platform alone could not fix.
Context
Dodge this: How to design a system that bring value to end-users when business works against them
The starting hypothesis
The initial assumption was structural: the problem was systemic complexity, and the solution was consolidation. Retail agents were navigating between 10 and 20 different systems every day, each with its own login, its own logic, its own blind spots. A unified platform would, the hypothesis went, solve the experience by solving the architecture. Merge the systems, reduce the friction, restore the agent's ability to focus.
It was a plausible hypothesis. It was also insufficient and reductive.
"To provide a premium customer experience, it starts with a qualitative employee experience" a manager at Volvo once told me. A principle I carried into every scoping decision. The implication was uncomfortable: designing a better container meant nothing if the content inside it still fractured the agent's attention at the moment it mattered most.
End-user research conducted with retail agents across Sweden and Norway surfaced a finding that reframed the entire scoping conversation.
The problem was not that agents lacked information. It was that the same information existed in multiple systems simultaneously, inconsistently, and without a single source of truth.
A VIN search could return nothing in one system and surface the car immediately in another. Agents couldn't see what a colleague had done with a shared customer.
Over time, this bred something more damaging than frustration: a generalised mistrust of what the systems showed them. One agent captured the cost of that mistrust plainly: invoicing under the new direct-sales model took 15 minutes where a standard transaction took 2.
The job to be done was not harder, but agents had learned they couldn't trust the data they retrieved and the systems they had to use.
The turn is when I mapped the whole to-be experience: it became the compass for all
Product teams started to be created and every one was working on their dedicated scope struggling with visibility over the other teams. Design system may have started the conversation: I mapped the entire retailer experience, across the full customer to-be-journey, from lead creation to vehicle delivery.
The resulting map made visible what no single team could see from its own vantage point: gaps in the experience where no team had ownership, moments of duplication where two teams were solving the same problem differently, and junctions where a decision made in one feature directly impacted the usability of another.
This map became a strategic artefact. It helped confirm something that was already being felt but not yet named: the five-team structure needed to function as one coherent programme, not as five adjacent workstreams including cross-capabilities product: activities, notifications, and how they can support verticals.
Results
The platform was still being built when my engagement ended. There are no post-launch metrics to report. What exists, instead, is a set of structural outcomes that shaped what the programme became.
The experience blueprint became the reference document that allowed five product teams to align on scope, reduce duplication, and identify ownership gaps; work that would have required months of escalation to surface otherwise.
The feedback from the Volvo Retail Group Product Manager was direct: "Your ability to quickly understand the business problems has been commendable. This is a crucial skill in the UX domain, and you've showcased it brilliantly."
The reusable process: blueprint-first, cross-team, before scoping any feature. The experience map precedes the product brief, because the feature that looks well-scoped in isolation is frequently the feature that creates problems at the seam.
When system complexity clutters experience vision: product is obvious when service design has done its job first.
If you are building or scaling a design or research team and you need someone who can hold the strategic view — who moves between field observation, systems mapping, and cross-team facilitation without losing the thread — this is the kind of work I do at full depth.
If your programme has teams designing in parallel but no one has yet mapped how those pieces connect from the user's perspective, that gap is worth a conversation.