Turning Systems Thinking into an Organizational Capability

Customer Service is not one experience. It is customers, associates, and drivers moving across products, support capabilities, teams, and operational systems, and the customer never sees the boundaries between them. As the initiative lead, I co-led an effort with Mohamed Noordeen that started as a way to make journey maps faster and became something bigger: turning a specialized design practice into a capability the whole organization could use.

We had plenty of insight. We lacked a view of the system.

Across CS UX, teams were already producing journey maps, service blueprints, narratives, and ecosystem views. The work was good, but it was project-specific: each artifact explained one experience, for one team, at one moment in time.

The deeper problem was structural. We could understand individual experiences well. What we did not have was a scalable way to see the system connecting them, or a repeatable way to build that understanding without starting from scratch every time.

Four Maps Revealed the Pattern

Four experience models were being developed across different Customer Service domains. I owned the Associate Journey Map, presented to L10 and L8 partners and now referenced across teams in OP1 documents and PR-FAQs, and the Driver (DP) Experience Map. In parallel, Mohamed owned the HITL and Case Management journey maps.

These were different domains, built independently. But placing them side by side, I noticed that each one required the same fundamental operations, regardless of domain: gather the evidence, find the relationships, give it structure, apply a narrative.

The obvious question was "could we make journey maps faster?" That is a tooling question. The more interesting one was different: what if we stopped treating systems thinking as a specialized design exercise, and made the method itself a capability the broader organization could pick up and use?

That reframe is the whole project: not a faster artifact, but accessible systems thinking.

The maps weren't the thing to standardize. The method was.

Turning a Design Practice into a System

I co-led the development of the CS UX Service Blueprint Kit, capturing the underlying method rather than standardizing a single artifact. It encoded how to gather evidence, structure relationships, create a narrative, and produce a useful experience model. Crucially, the kit did not just help people build a journey map; it helped them apply a narrative to it, so the map could tell a story and a team knew how to use it. A team could go from nothing to a map and its narrative within a day.

A map is not a story

A journey map shows what happens. On its own it does not make a stakeholder act. I realized the kit needed to do more than structure evidence: it needed to help teams make a case for action. So the heart of the kit is a narrative structure that turns a raw map into a story a leader can read cold and walk away convinced. That structure is why the Driver map became the Driver Blueprint.

Three, five, or six parts depending on the evidence. The Driver Blueprint below is that narrative applied.

From Map to Blueprint

The DP Experience Map was the first thing to evolve through the kit. Rebuilt on the kit's methodology and design system, it became the Driver Blueprint. The point is not that it was a nicer artifact. The point is transfer of expertise: the method could reproduce the quality of a previously bespoke design exercise without requiring the original designer to recreate it.

The Method Had to Work Without Us

A capability isn't real if its creators are still required.

I deliberately handed the method over before I considered it finished. We ran a workshop with the CS UX studio and our PM partners, 28 designers, 6 researchers, and 6 PMs (40 in all), walked them through the kit, and then let them build.

We captured the session in a FigJam board and surveyed the room afterward. The rating was high, but the result I care about most is this: most participants trusted the output because they could trace it back to their own source material.

Trust through provenance matters more than speed. If people believe an artifact because they can see where it came from, the method can travel, and it becomes the foundation for letting a system reason over the same structure later.

"It took me from scattered notes to something structured enough to bring to leadership, in an afternoon."
Product manager, CS UX studio workshop

For a PM, that afternoon would normally be closer to two weeks: partnering with a UX researcher to organize the data, then a UX designer to shape it into a journey map. The kit collapsed that into a single working session.

The CS UX studio and PM partners running the kit themselves.

Once the method proved transferable, I saw the remaining constraint: access to the tooling itself. So we built a standalone tool, the CS UX Blueprint Builder, that let anyone create a journey map without an IDE or any developer setup. The bottom of that maturity curve was now real: not just a method other people could run, but a tool anyone could open.

Then We Used the System to See the Ecosystem

Once a consistent experience model was cheap to produce, the toolkit stopped being the destination and became infrastructure.

We used it to model the whole customer service ecosystem at five altitudes, from the product portfolio down to the moment-to-moment interaction, so the same system could be read at whatever zoom a question needed.

Five altitudes, abstract to concrete. Blueprints sit at L3; the Golden Thread cuts across them.

Modeling the ecosystem at every altitude exposed a gap none of the individual maps could close. I saw the remaining blind spot: we could model the system, but we couldn't follow the experience through it. Nothing followed a single customer as they moved across those altitudes and across the teams that own them. That missing view is what came next.

From Maps to a Model of the Experience

The Golden Thread is the logical consequence of everything before it. Once we could create consistent experience models, we could begin connecting them. Instead of asking how individual products performed, we could follow one customer's experience across time, across capabilities, and across organizational ownership. We followed one household across 16 support contacts, grouped into 6 phases over three weeks.

The lenses are not display options. Each one is a strategic question you can ask of the same timeline.

Emotion

What did the customer experience?

Instead of asking whether a product worked, we ask what the experience actually felt like as it rose and fell across the journey.

Emotion lens

Where It Frays

Where did the experience break down?

This lens distinguishes resolved from handed off from redirected. A handoff is not necessarily a failure, but a redirect can mean the customer has to leave one experience and figure out where to go next.

Where It Frays lens

Who Owns It

Who shaped that moment?

A single experience can pass through several owners, and the customer feels every seam between them. Putting ownership on the same timeline is the clearest answer to the opening line: the customer never saw org boundaries, but the experience was shaped by them at every step.

Who Owns It lens

Product Drill-Down

Where does a capability help or hurt the experience?

We can drill into a single capability, like the CS chatbot, and see which moments it resolves, which it hands off, and which it redirects. The question changed from "Is this product working?" to "Where does this capability help or hurt the experience?"

Product drill-down

Strategic Impact

We Changed the Unit of Design

We were not just making journey maps. We were changing what design operates on.

The toolkit created the artifacts, the ecosystem model let us understand the system, and the Golden Thread gave us a way to follow the experience through it.