Service Design

UX design focuses on the user's experience of a digital product: how it works, how it feels, how easy it is to use. Service design covers the broader experience: every touchpoint the user encounters — digital or not — and the operational processes that sit behind them. A great UX connected to a broken service still fails users. We treat both as part of the same problem.

Not necessarily. Service design is relevant wherever there is a service to design — whether that involves software, physical touchpoints, staff interactions, or some combination. In practice, most of our service design engagements connect to a digital build, but the service layer work stands on its own regardless.

The people who own the service and the people who deliver it. That typically means operations leadership, frontline staff who deal with customers or users directly, and whoever owns the digital products in scope. The more accurately we can map what actually happens today, the more useful the redesign will be.

A current-state service blueprint, a future-state service blueprint, and a set of design recommendations covering both the user-facing experience and the operational changes required to support it. Where a digital product is part of the engagement, the service design work feeds directly into the UX and product requirements.

Yes, and that is the more common brief. A new service is designed once. An existing service accumulates problems over years as it grows. We start with a current-state audit — what works, what does not, and where the gaps between the front and back stage are causing the most friction — then redesign from there.

You do — the research, the maps, the blueprints, and the files they were made in. Everything is handed over in a form your team or another agency can continue from, not locked in a tool only we can open.

A service blueprint takes as long as it takes to trace every handoff with the people who own it, so the size of the service sets the timeframe. A single service run by one front-line team, such as bookings or onboarding, is quick to map. A service that runs through a call centre, a field team and several systems takes longer, because each step has to be checked against what really happens, not what the procedure manual says. Most of the time goes into interviews and watching the work, not drawing. We agree the scope and the timeframe with you before we start, so you know which parts of the service are in and when the map lands.

You measure it against the things your team already counts, with a baseline taken from the current-state blueprint. That usually means calls from customers checking on progress, work that has to be redone, the time from a request to its completion, and complaints that trace back to a handoff. When we map the current state we note which of those numbers you can already pull from your systems, and which you will need to start recording. After the change goes live, you compare the same numbers over the same period. If a measure cannot be counted, we say so, rather than reporting a feeling as a result.

Then the recommendation is not digital, and we tell you that plainly. Plenty of service problems are fixed by changing who owns a step, removing a duplicate approval, rewriting a form, or giving front-line staff an answer they currently have to escalate. Those changes are cheaper than software and often faster to land. The blueprint shows each problem next to its cause, so it is clear which ones need a system change and which need a process or role change. Where software is part of the answer, the service design work feeds into the requirements. Where it is not, you get the process documentation and team briefing instead.