Why You Should Skip Current-State Mapping

Current-state mapping is considered a foundational step in service design. Map what exists before designing what should exist. Document the as-is before proposing the to-be. It is taught in every design school and expected in most consulting engagements.

In in-house practice, it is often the fastest way to stall a project before it starts.

The Hidden Cost of Documenting What Everyone Already Knows

The teams inside your organization — engineering, UX, customer service, operations — already know what the current state is. They live it every day. They have built workarounds for its failures, developed institutional knowledge of its gaps, and accumulated years of frustration with its limitations.

When a service designer arrives and spends three months mapping what those teams already understand, two things happen. First, the organization loses momentum at the exact moment when enthusiasm is highest. Second, the designer produces an artifact that insiders find redundant and outsiders find overwhelming.

"The current state, the capability gap, and how we'll get there is not my job. That's the job of many teams."

Current-state mapping confuses documentation with understanding. The goal of journey work is not to produce a record of the present — it is to create the shared conditions for improving it.

What Matters More Than the Current State

The question that drives useful journey work is not "what is happening now?" but "what is holding us back from delivering a better experience?"

Those are different questions, and they lead to different work.

The first question produces inventories: lists of touchpoints, process steps, system dependencies, and interaction flows. The second produces priorities: the specific pains customers experience, the organizational pressures that prevent resolution, and the opportunities worth pursuing.

Focusing on pains, gains, needs, and pressures means starting where the organization can act — not where it is already overwhelmed. Teams that feel heard about what is not working are far more likely to engage with what could be better. Teams that are asked to document what they already know tend to disengage quickly.

When Current-State Mapping Does Make Sense

There are scenarios where documenting the current state is genuinely necessary.

If a company is undergoing a major platform migration and needs to map existing integrations before rebuilding them, current-state documentation is essential — but that is engineering work, not journey work. If a regulatory audit requires evidence of existing service flows, a service blueprint is the right tool — but again, that is compliance work, not design work.

The confusion arises when these legitimate documentation needs are conflated with the strategic work of improving customer experience. Journey mapping and service blueprinting are related but distinct disciplines. A journey map operates at the strategic level of the customer experience. A service blueprint operates at the operational level of service delivery. Mixing them produces a document that serves neither purpose well.

The Practical Alternative

Instead of mapping the current state, begin by mapping what is not working — in the customer's experience and in the organization's ability to deliver.

Start with internal discovery: conversations with the people who know where the friction lives, where customers complain, where teams are duplicating effort. Then validate with customers themselves: what they need, where they struggle, what would make the experience worth recommending.

This approach takes two to four weeks rather than three to six months. It produces insights that are immediately actionable rather than observations that require further interpretation. And it creates the kind of shared picture that teams can align around in a single workshop.

The granularity of the work must always match its purpose. When the purpose is strategic alignment, strategic-level data is what the work needs — not a comprehensive inventory of everything that currently exists.