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

Hey everyone,

I have been thinking a lot about method selection in business analysis. In practice, the challenge often does not feel like a lack of methods. There are requirements workshops, stakeholder maps, process models, journey maps, root cause analysis, decision matrices, assumption mapping, risk workshops, prioritization frameworks and many other approaches.

The harder question for me is: which method fits this specific situation?

I know this from architecture, product and analysis work. You start with an unclear problem, conflicting stakeholder statements, a scope that is too broad, a missing decision basis or a process that everyone describes differently. Of course, you can start with conversations, notes and documentation. Sometimes that is enough. Sometimes a more structured approach would be much more productive if it was available at the right moment.

I am currently building my own kind of method catalog for this, mainly to structure these choices better. What I notice is that the interesting BA question is not only the individual method. The interesting part is the heuristic behind it: how do you recognize whether you are dealing with a requirements problem, an alignment problem, a scope problem, a process problem, a decision problem or a stakeholder conflict problem?

I would be curious how you handle this in practice:

• Do you choose methods consciously, or does it mostly come from experience and habit?
• Which situations almost always need a structured method in your work?
• Which method do you use more often than outsiders would expect?
• Would you search by problem type, artifact, project phase, stakeholder situation or desired outcome?
• Are there methods that are overrated or underrated in BA contexts?

I am not looking for a method collection here. I am trying to understand the decision logic behind it: how experienced BAs move from a vague work situation to a useful way of approaching it.

Best,
Micha

Hey everyone,

I am trying to understand whether method selection counts as a real productivity problem. I know this from my own work: I need to prepare a workshop, structure a discovery session, compare options, create clarity or prepare a decision. Quite often, the next step is not the actual work on the problem. It is first finding a suitable way to approach it.

I built a small free web tool for this called Method Atlas. The idea is a visual method catalog for product, UX, strategy, architecture and workshop work. You start from the work situation, filter by context, goal or expected outcome, and then find suitable methods, alternatives and related approaches.

What I am mostly interested in here is the productivity angle. For me, a useful tool in this space saves time because it helps me move faster from “what should I use now?” to “this is how I will work on the problem.” At the same time, it is not a task manager, calendar, notes app or habit tracker.

So my question is:

• Would you consider something like this a productivity app at all?
• When would it be useful: before a meeting, during preparation, inside a workshop or mainly for learning?
• What would the search or filtering need to do to actually save time?
• Would a suggested sequence of methods be more useful than a single method?
• What would make this kind of tool feel too niche or not useful?

I am asking about the category and workflow first. What would help me most right now is understanding whether this use case makes sense outside my own work context.

Best,
Micha