My transition from product design to service design

systems thinking and service design model by Martin Sandstrom.

2022 was the year when I realised that I cannot succeed in my current role at Legal & General unless I adopted the mind and skillset of a service designer.

This was not an epiphany. I didn’t wake up one morning and thought ‘I need more service design in my life!’. I’ve been working with digital products and services since 2007 and my career path has followed a typical trajectory of starting hands-on, learning the ropes and adding enough experience to start seeing the mechanics of the system. And once I started to ‘get it’ all of a sudden it became less and less interesting to work with surface level UI challenges.

More and more, system design was what really interested me. Business models, value propositions, designOps and service design. So one can say that the interest for system thinking and service mapping had existed for a while. Although I had practised service design here and there in my roles as a product designer I had not yet been in a role as a service designer.

And there is an important difference.

Doing service design and being a service designer is not the same thing. I had to learn this the hard way.

From UX to EX

When I joined Legal & General in 2021 it was to fill the role of senior experience designer. I assumed the work would be things like requirements gathering, user research, product design and testing for our customer facing self-serve portals etc. The typical UX stuff.

But after I joined I was immediately given the sole responsibility to work on our internal systems, services and products. This was a new area given to the division and important enough to dedicate a full time designer on it. What ‘it’ referred to was less clear. Slightly outside the comfort zone for a contractor like myself who’d normally request or co-create a very clear brief and statement of work before any work will commence.

Turns out ‘it’ had something to do with the fairly recently coined term Employee Experience (EX), which was the natural progression after employee engagement. The HR community had realised that employees could benefit from a more holistic approach, similar to the one applied in Customer Experience (CX).

So off I went, farther and farther away from my comfort zone, looking to create my own brief whilst reaching out to people who had titles sounding like they had something to do with EX. All remotely, of course since we were in the midst of the pandemic.

Writing your own brief when you don’t have a budget, remit or even a name and reputation that means anything to anyone, is a bad idea. You won’t get anything done. I did a bit of user guides, intranet pages, EX research and principles work, tried to get some traction in an EX strategy and collaboration between departments, but in the end it was a pretty weak existence. It was not something I was used to but indeed a sober wake-up call.

Product design has a very limited area to operate in in the world of EX where the organisation doesn’t own any of their employee facing products. And this is where my mindset shifted to service design.

What’s the difference between product and service design?

Think about it this way; screen design is very much a tangible thing. The information architecture, user flows and content strategy are less tangible but still pretty easy to understand with good visualisation tools. All of this is backed up by user research and the goals that are defined for the product. That’s product design in a nutshell, right? Who delivers these things? The product design team normally (read my take on the design dream team here).

Now let’s take a look at a service: Onboarding a new employee when they join a company. How do you design this service? Immediately we realise that a service design team can’t be the ones delivering this, because the service has a lot of interdependencies between teams and divisions such as HR, Finance, IT fulfilment, IT support, Security, Employer brand and Legal. All of these teams might no be hands-on when the employee joins but they will have been involved at some point on process or policy level.

This is why service design is intrinsically co-creative. Although a service design team might be responsible for delivering the blueprint, or solution, it never happens without the involvement of the teams that the solution will feed back into. A product team will no doubt involve other teams in the creation of the product, but in the end they will be the owner of the solution. That’s not the case in service design. The solution is co-owned by many teams and everyone needs to be onboard.

Despite the title, service designers don’t do design. We don’t own design decisions and we don’t do design in the traditional sense that many of us are used to from previous roles.

A service designer’s job is to facilitate the orchestration of systems to produce human-centred, positive change.

We’ll get back to that definition in a bit.

Why is service design so difficult?

Compared to service design, product design is easy. There is certainly an overlap and no digital products live in a service-less vacuum. There’s a service behind every product. But the part of product design that isn’t bothered about the service processes that support it is comparatively easy.


Because a product team is (at best) a self-sufficient task force on a mission to deliver, and everyone is working towards the same goal. Introduce more teams, more policies, more agendas and your road bike just got swapped for a tricycle. Because things get exponentially harder the more people involved. People make things messy and complexity rises.

As a service designer you’ll be introducing teams to new ways of working, encouraging them to collaborate for the benefit of the user and slowly nudging the system towards a new state. Unless you have a senior management sponsor to push things along with sticks and carrots it can sometimes feel like an impossible task.

When teams don’t show up to workshops, critical decisions get put on indefinite hold and every step you explore in your process map opens up three new ones, owned by teams you’ve never heard of, it’s very easy to settle for some ‘quick wins’ on UI level that you can actually control. Erika Flowers puts it beautifully in her modern classic on Medium. I can relate to every point she makes, and sadly say that it’s still very true in 2023.

What skill set do you need to dial up when you transition into service design?

If you’re not put off yet and you’re still up for the challenge, here are some tips on what to focus on from my own experience. Here’s my definition of the service designer role again:

A service designer’s job is to facilitate the orchestration of systems to produce human-centred, positive change.

Let’s dissect that definition to better understand what’s asked of us when we step into a service designer role.

To facilitate:
Make (an action or process) easy or easier.

The secret sauce that service designers often bring to a project is to be the glue/catalyst/mediator between different stakeholders. We see this all the time. Everyone is busy in their own part of the world and along comes a change initiative that forces different teams to either start talking to each other or feel the pain later. Sometimes there isn’t even a change initiative from above and you have to work laterally in the organisation without any sponsorship. That’s really when these skills become a life saver.

As a facilitator you help those conversations along, by building rapport with teams, running workshops, agreeing accountability and setting up transparent communication channels. Workshop skills are hugely beneficial here, but also the importance of soft skills like patience, empathy and confidence cannot be emphasised enough.

Orchestration of systems:
The planning or coordination of the elements of a system to produce a desired effect.

This is where the plan of action is shaped. It happens mainly with visualisation tools like process maps, user journey maps, service blueprints and prototypes. Learn them, feel confident in using them and don’t get too bogged down in design methodologies and theory. Early on I spent a lot of time trying to figure out if I should use a process flow or a journey map. A blueprint or a system map. But it really doesn’t matter. They’re just slight variations of the same thing with different names, i.e. a model of a system that will help you and your stakeholders align and focus on the right thing, in order to know what to do next.

These maps are not deliverables, they’re just tools. They should evolve over time so don’t spend too much time perfecting them. You can wing it. Start small and add to it as you learn more. My maps are Frankensteins created from all sorts of diagram theory. But they get the job done.

Mapping exercises takes place in many different settings. You can map on your own, you can co-create with end-users by showing them a draft and let them tweak. You will co-create to-be and as-is maps in workshops with your stakeholders, and you might sit down with a subject matter expert and iron out parts of a map in a 1-2-1.

To get to grips with the all the bewildering theory my first port of call would be the bible-like status, go-to resource for all service designers; This is service design doing. From there the list of literature is endless, but that’s for another post.

Computers, technology, systems, etc. that are designed to work in ways that people can easily understand and learn.

If facilitation is the secret sauce we bring to change projects, human-centred thinking is what separates us from business analysts and solution architects. The skills needed here, part from the mindset you probably already possess, lie within user research. Human-centred design without user research doesn’t exist. Even if you simply do best-practise usability and accessibility you’re still applying someone’s recommendations that were derived from research.

If you don’t have a researcher on the team you’re likely the one specifying the research goals, creating the plan, collecting the data and synthesising the results. So it’s very useful to pick up skills in user research from a professional source. There are many pitfalls.

Positive change:
Changing something for the better.

Not as much a skill as it is a virtue, but a moral compass will help shaping you long term. In service design you often get to work on larger change projects than in product design, and they can have a large impact on people, animals and environment. Considering the big picture is a cornerstone of systems thinking, and we need to remember that doing the right thing for one part of the system could have a negative effect somewhere else.

For a completely hypothetical example, changing from fossil fuel to green energy is great to combat pollution, but if the solution is more off-shore wind farms that affect the marine life in a negative way we have to think again. Stay true to your moral compass and often switch lens to zoom in and out to better understand the intricacies of the system and how it will respond to change.

To conclude

You can definitely make the transition into service design from product design, just be prepared for what’s to come. It’s slow, it’s messy, it’s political. But it can also be very rewarding. I’m just at the beginning of my transition and we’ll have to wait and see if I’m just here to dabble and then return to product, or if it catches on and I make a full transition. Either way, what I’ve experienced so far has taught me a lot and forced me to grow so I encourage anyone who’s interested to go for it. Be patient, and be kind to yourself and your stakeholders along the way.

Previous ArticleNext Article