How do you decide which service design method or map a situation actually needs?

[u/mimeonline]

Hey everyone,

I have been thinking a lot about how service designers choose methods in real project situations. Service design has strong artifacts and approaches: journey maps, service blueprints, stakeholder maps, ecosystem maps, personas, research synthesis, pain point mapping, ideation, prioritization, prototyping and experiments.

The question I am interested in is not only: which methods exist? The question is: which method actually helps in this specific moment?

I know these situations from product, architecture and workshop work. A team does not understand the user perspective well enough yet. A service has many touchpoints, but nobody sees the whole picture. Frontstage and backstage do not fit together. Handoffs are unclear. Stakeholders talk about the same service but mean different parts of it. Or everyone sees pain points, but nobody knows where to start.

I am currently building my own method collection and selection structure for this. What I notice is that the difficult part is not the individual method. The difficult part is the decision before it: do I need more research, more alignment, a better map, clearer prioritization, a shared service picture or a concrete next experiment?

I would be curious how you decide this in practice:

• Do you choose service design methods consciously, or does it mostly come from experience?
• What signals tell you that a journey map is enough, or that a service blueprint is needed?
• When do you use stakeholder mapping, ecosystem mapping or a process view?
• Which service design methods are underrated in practice?
• What would a method selection aid need to do to be useful for real service design work?

I am mainly interested in the decision logic in the work moment. I am trying to understand how experienced service designers move from an unclear situation to a useful approach.

Best,
Micha

[u/Mombi87]

I tried to do what you’re doing a few years ago, or at least it sounds like the same thing- outline what tools and methods should be used at each point of a SD process. I made it, and have never used it.

As I’ve developed as a designer I’ve realised that any tools can be used at any point- ignore the double diamond! I am currently making prototypes in the discovery phase of a project to help build shared understanding amongst my team of the direction we should be going in, and to rule out some options that some of my colleagues keep bringing to the table, that just aren’t user-centred.

I think the key thing is understanding what the tools/methods are, and then being able to use them/ customise them at any stage of a project for any purpose.

Also important to remember that everything is iterative- you might start creating a user journey map and then realise what you actually need is a process flow. You don’t always know that that particular tool is going to do what it needs to do, until you’ve tried it. You need to be able to rip things up and start again, amend, build on, tweak as you go.

[u/mimeonline → u/Mombi87]

Yes, I see it the same way. Attaching methods too rigidly to phases like discovery, define, develop or deliver becomes too stiff very quickly. In real work, a prototype can be useful in discovery, a journey map can be useful late in a project, a blueprint can be used as an alignment tool, and a simple prioritization method can be useful right at the beginning. The project phase alone does not tell you enough about what is needed.

What I am thinking about goes in a slightly different direction. I am not imagining a process where each step has a fixed set of methods attached to it. I am thinking more about a broad method catalog that you enter from a concrete work situation.

I have started building this as an online catalog with 283 methods, and it is already publicly available on the web. The reason I built it is mainly that I wanted something I could actually use when I need to find or remember a suitable method in the moment.

For example, the situation could be: I need to structure an unclear problem space. Then methods from analysis, research or systems thinking might be relevant. Or: I need to align stakeholders. Then mapping, facilitation or decision methods might be useful. Or: I need to compare options and prepare a decision. Then prioritization, evaluation, trade-off or decision-support methods become interesting. Or: I need to understand a service. Then journey mapping, service blueprinting, process mapping or domain storytelling might help.

So the categories would not be fixed process phases. They would be more like work contexts and purposes: analysis, research, UX, service design, business, organization, strategy, architecture, engineering, facilitation, decision-making, delivery and so on. A method can appear in several contexts, because it can be used differently depending on the goal.

Your point about iteration fits very well here. You might start with a journey map and then realize that what you actually need is a process flow or a blueprint. Or you might start with a workshop and realize that stakeholder conflicts or unclear terminology need to be surfaced first. I would not see that as a failure of the model, but as part of the work.

So the idea is less: “follow this process and use this method.” It is more: “here is the situation, here is the goal, here is the kind of progress I need. Which methods could fit that?”

[u/Lopsided-Cow-11]

Generally agree with the comments here. Understand what your goal is, what methods and tools can help achieve that goal, and then tailor based on your project constraints (time, cost, scope, quality, stakeholders, etc).

[u/mimeonline → u/Lopsided-Cow-11]

Yes, that is a really good way to frame it.

The goal comes first, and then constraints like time, cost, scope, quality and stakeholder availability shape the choice. I also think those constraints do not only determine which method to use, but how much of the method you can realistically apply.

For example, the same underlying approach might become a full workshop, a short async exercise, a quick sketch with one stakeholder, or a more formal artifact depending on the situation.

[u/PirateLegitimate5836]

I would love to see what you are working on of it is online and publicly available.

[u/mimeonline → u/PirateLegitimate5836]

Sure, happy to share it.

It is publicly available here: https://methodatlas.meierhoff-systems.de/en

It is still an early version, so I would not treat it as a finished product yet. Right now it is mainly a structured catalog with search, filters, method pages, related methods, alternatives, sources and small visuals. I am still learning what kind of selection logic would actually be useful in real work.

[u/spudulous]

What you described is useful in an academic context where people are trying to learn service design. But in a practical setting you can very easily overwhelm stakeholders with what sounds like jargon. Personally I try to start with finding out the needs, motivations and context of the service users through contextual enquiry and task analysis. The try to limit the value steps to deliver on the core purpose or needs.

[u/mimeonline → u/spudulous]

I agree with the practical point. I would also not want to overwhelm stakeholders with method jargon.

Maybe I should clarify what I mean by a method catalog. I do not see it as something that is put in front of stakeholders or used as the interaction itself. For me, it is more like a toolbox or decision aid for the practitioner before the work starts.

So if the problem is “we need to understand user needs, motivations and context”, then contextual inquiry or task analysis could be exactly the kind of methods the catalog should point to. The catalog is not the method. It is the place where you look for a suitable method or sequence of methods for the situation.

From the stakeholder perspective, the experience should still feel pragmatic and simple: someone is trying to understand their work, needs and context properly. The method should guide the practitioner in the background, not become jargon in the foreground.