Is your digital problem really a service problem?
A form that asks for information your team already has. A confirmation email that arrives after someone has already called to check. An onboarding flow that hands users off to a process nobody has designed. These are not UX problems. They are service problems — and fixing the interface without fixing the service just makes a broken process look better.
We map the full picture: what users experience, what your team does to support it, and where the two fall out of alignment. Then we design both sides — the front stage and the back stage — so the service actually works the way the screen implies it does.
How service design works
-

Service blueprinting across every touchpoint: what users encounter, what triggers each step, what your team does in response, and where the handoffs happen. The current-state map usually reveals the problems faster than any survey or complaint log.
-

A redesigned service model that aligns the user experience with the operational reality behind it. New touchpoints, revised workflows, and the process changes your team needs to deliver what the front end promises.
-

Service design does not end with a document. We work with your team through the operational changes required to make the new service model real — process documentation, team briefing, and the connection to any digital products being built alongside it.
What does service design cover?
Service blueprinting
End-to-end visualisation of the full service: user actions, touchpoints, front-stage interactions, back-stage processes, and support systems. The tool that makes the invisible visible.
Touchpoint design
point of contact between your users and your service — digital, physical, and human — designed to be consistent, intentional, and connected to what comes before and after it.
Operational process design
The workflows, handoffs, and team processes that support what users experience. Designed to be practical, documented to be repeatable, and aligned with the digital products your team uses to deliver them.
What does a service design project look like?
Take a service most businesses run: a customer books a job online. The form asks for details the business already holds. The confirmation email lands an hour later, so the customer rings to check it went through. The person who answers re-keys the booking from the email into the job system, and the field team finds out about it from a printed list the next morning.
Redesigning the booking form would make the first step look better and change nothing else. A service blueprint shows where the time and the errors actually come from: the gap between the form and the job system, the confirmation that waits on a person, and the handoff to the field team that happens on paper.
The future-state design fixes those handoffs in order. The form pre-fills what is already known. The confirmation is sent the moment the booking is saved. The job system receives the booking directly, and the field team sees it on the day it is made. Some of those changes are software. Some are a change to who does what and when. The blueprint shows which is which, so you only build what the service needs.
Fixing the interface without fixing the service just makes a broken process look better.
Tools and methods
What we use to do the work
Service blueprinting
Journey mapping
Stakeholder interviews
Co-design workshops
Touchpoint auditing
Process mapping
Operational design
Swim-lane diagrams
Contextual research
Pilot testing
Change documentation
Figma
Service design questions we get asked
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.
Most engagements start with a Rapid Insight Workshop at a fixed $9,000 + GST, which maps how the service runs today and returns a prioritised roadmap about three weeks later. Larger redesigns are scoped and quoted fixed-price before they start, so the number is agreed before any work begins.
Hire if you have a steady stream of services to redesign and someone to lead them, though hiring a senior person can take months. One hire is one skill set, and a service redesign often needs research, design and the systems work that follows. An outside team suits a defined piece of work with a clear end.
Related design services
Service design sets the whole layer. These go deeper on the parts customers touch.
UX Design
UX design decides how software behaves before anyone draws it. Research, journey mapping, wireframes, and testing with the people who will use it.
UI Design
Before your software is built, a UI designer should hand over production-ready Figma files with documented components, defined tokens and interaction notes. Developers can build from those without guessing, so what ships matches what was designed as the product grows.
