Turning Systems Thinking into an Organizational Capability
Customer Service is not one experience. It is customers, associates, and drivers moving across products, teams, and operational systems, and the customer never sees the boundaries between them. I co-led this effort with Mohamed Noordeen. It 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.
Amazon, Customer Service · Product Designer & Program Co-Designer · early to late 2026
Finished maps, against a program bar of eight
Maps built in one afternoon, by people new to the kit
Builders and teams who have produced a map
The problem
Plenty of insight, no 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, one pattern
The same four moves showed up in every map
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.
Associate Journey Map. Open full screen ↗
Driver (DP) Experience Map. Open full screen ↗
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 pattern behind all four maps
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.
Building the system
Turning a design practice into a system
The maps weren't the thing to standardize. The method was.
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.
Handing it over
The method had to work without us
A capability isn't real if its creators are still required.
So I put it in front of people who had never used it. First with our own studio and PM partners, and then, the real test, at the studio Summit: six tables of designers, researchers, and product partners, thirty-one people in the room, one afternoon. I co-facilitated with Mohamed.
We wrote the bet down before we ran it: if tables new to the kit could build a quality map in roughly forty minutes, the method scales. Four of the six finished inside the build window. All six produced a usable map. The forecast resolved yes.
Built by people new to the kit. The one map a hand-built process would have cost, by the program's own estimate, is closer to two weeks of designer or researcher time.
We surveyed the room afterward. Ratings were high, but the result I care about most is quieter: 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
The CS UX studio and PM partners running the kit themselves.
Once the method proved transferable, the remaining constraint was access to the tooling itself. So we built a standalone tool, the CS UX Blueprint Builder, meant to let anyone turn their own sources into a map without an IDE or developer setup. It went from v1 to v7 in eleven days on stakeholder feedback.
Then I made the call to withhold it from the Summit. At triage it did not yet clear the functionality bar for a room of thirty-one people, and shipping something that broke live would have taught the room the wrong lesson. So every table ran the kit directly instead, and six maps still came out of that afternoon. That was the more important proof: the method held without the app it was supposed to need. The Builder is where the next phase of the work continues, carrying the enforcement checks the Summit exposed.
Seeing the ecosystem
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
Following one customer through the whole system
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. Tap to view the full timeline.
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. Tap to view the full timeline.
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. Tap to view the full timeline.
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
Four shifts in how the org works
From project artifacts to strategic inputs
Experience models became part of how priorities were discussed and evaluated, not just documentation of decisions already made.
Fourteen finished maps have come out of the program against a bar of eight, cleared four months early. One went through a VP review as the companion piece to a redesign strategy, on a journey that carries the large majority of total CS interactions.
From design documentation to a shared decision-making language
The customer experience became part of how initiatives are framed, rather than something evaluated after the product decision.
One PM moved her map out of the appendix of a PR-FAQ and into the body of the press release herself. Another is building a journey with the kit unprompted. When people carry the experience story into how they communicate an initiative, the map has stopped being a deliverable and become a language.
From static artifacts to a living model
The blueprint is becoming a foundation for connecting experience to the operational signals behind it.
The next phase moves from understanding a journey to measuring it: pairing the map with a data dashboard so experience structure and operational evidence read in the same view.
From individual expertise to organizational capability
Systems thinking began moving from a specialized UX practice into a shared way of working.
Eight builders and teams have now produced a map, and six were built in a single afternoon by people new to the kit. Adoption is starting on its own, and leadership has recommended the program as a studio goal for the next half. The method has begun to travel beyond its original creators.
Why it matters
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.