Service Design: My SERVICE framework for designing products, services, and user journeys that work

Service design is the practice of intentionally shaping experiences for the people using a service and the people delivering it. Here is how I approach it with SERVICE.

My SERVICE framework to journey and product design

There are a lot of design frameworks out there. Double Diamond. Design Sprints. Lean UX. They are all useful in their own way, and I have borrowed from all of them.

But when someone asks me how I actually approach a service or product design challenge from scratch, I always come back to the same process. Not because it is the most sophisticated. Because it is the most honest about how good design work actually moves.

I call it SERVICE. Seven steps that follow the natural rhythm of how problems get understood, solutions get shaped, and change actually sticks.

Scope the project. Before you do anything else, get the team aligned on what you are solving for. This is not glamorous work. But skipping it costs you weeks later.

When I onboard a project team, the first thing we do together is build a hypothesis map: a shared view of what we think the problem or opportunity is, before we have done any research. It forces everyone to surface their assumptions early, when they are still cheap to change.

The output is a clear set of goals, key milestones, and deliverables. Everyone leaves the room pointing in the same direction.

Explore through research. Now you need to find out whether your hypothesis is right.

This is the UX research phase. You are validating or challenging what your team assumed in the scoping stage, while gathering the business and stakeholder requirements that will shape what is actually buildable. User interviews, usability testing, surveys, process mapping, desktop research. The method depends on the question.

The goal is not just to collect data. It is to understand the current journey well enough to spot where the real friction is, not just where people think it is.

Reframe insights and problems. This is the step most teams rush past. Do not.

Raw findings do not tell you what to do. You have to do the sense-making work: pulling insights across data sources, looking for patterns, and reframing the problem into design considerations and How Might We questions.

A well-written HMW opens up ideation. A poorly written one closes it down. The difference between “How might we make the form shorter” and “How might we reduce the effort required to complete this task” is the difference between a minor tweak and a genuinely better solution.

This stage also produces your design principles, the criteria you will use later to judge whether a solution is actually good.

Validate by co-creating solutions. Bring in the people who will own the solution. Brainstorming alone produces ideas.

Brainstorming with product owners, engineers, and subject matter experts produces ideas that can actually be built. I use structured ideation methods here to push past the obvious answers and get to approaches that address the deeper issue rather than just the visible symptom.

Validation happens in the room. When the people who will build and own the solution have shaped it themselves, you spend far less time selling it later.

Illustrate the future journey. This is where the vision becomes concrete. Take the best thinking from the co-creation stage and translate it into an envisioned user journey or service blueprint.

Write the epics. Prioritise the user stories for different releases. Specify the metrics that will tell you whether the experience is working.

A storyboard of the future journey is often more persuasive than a hundred slides of research findings. It shows what success looks and feels like from the inside, and it gives decision-makers something real to say yes to.

Craft a prototype. Test before you scale. Quick prototypes, usability sessions, and iterative refinement. Not everything survives contact with real users, and finding that out early is far cheaper than finding it out after the full product has been built.

This stage is also where the roadmap and go-to-market strategy take shape. A well-designed solution still fails if the people who need to use it are not brought along for the journey.

Evaluate and refine. Delivery is not the finish line. Evaluation closes the loop.

You measure the experience against the metrics you set in the Illustrate stage, surface what is working and what is not, and feed those findings back into the next cycle. This is the review and feedback loop that keeps the service honest over time.

A proposed future state is never a finished product. It is a foundation. The work is in returning to it, stress-testing it against reality, and building on it as the context evolves.

Why SERVICE and not just a list

Every step earns its place in the sequence. You cannot reframe what you have not explored. You cannot co-create before you have a problem worth solving. You cannot evaluate what you have not built.

But the process is not linear in practice. Real projects loop back.

You will finish the Reframe stage and realise you need more research. You will get to prototyping and discover a fundamental assumption in your journey design was wrong. That is not failure. That is the process doing its job.

The divergent phases open up possibilities. The convergent phases make decisions and move forward. Knowing when to do each is what separates good service design from expensive guesswork.

Credits to my team lead, Linyou, whose mentorship has taught me a lot about a good service design practice.