Experience Architecture
Intentional Curation of Customer Experience
I came to Experience Architecture the long way around. I had spent years sitting in readouts for redesign programs that did not change much, and at some point I stopped believing the redesigns were the problem.
This is what I have figured out so far.
Take it for what it is worth.
-AM
The redesign that did not move anything.
A while back I was in a readout for a customer experience program that had been running close to two years. New portal, new app, forms a competent designer had clearly spent time on. The satisfaction score moved a few points at launch and then drifted back to roughly where it had been before the program started.
Nobody in the room had a clean explanation. The work was good and the team was good, but the customer was walking through an experience that crossed marketing, product, billing, and service in sequence, and the program had only really touched the surfaces. The behavior underneath the surfaces had not changed.
Each of those functions could show you a green dashboard for the part they owned. Nobody had been asked to own the part between them.
XA is mostly about who owns the part between functions.
Most of what I now do under the Experience Architecture banner is not design work. It is figuring out who is going to be accountable for the part of the customer experience that lives between the functional owners.
That part is almost always where the customer feels the company being clumsy. The handoff from sales to onboarding. The moment a billing change has to be reflected in service’s view of the account. The point at which a self-service path fails and the customer has to start over with a person who cannot see what they were just doing. None of those moments belong to a single function and all of them are how the customer experiences the company.
The clients I have watched do this well have a person, usually senior, whose job is to sit at those points and make the calls that cost one function to benefit another. The clients who try to do it with a council or a steering committee mostly produce decks. I have been on both sides of that one.
Value streams, but not the way most people mean it.
I have mostly stopped saying “value stream” out loud in client conversations, because the phrase has been worn down to mostly mean a poster on a wall. Half the room thinks I am about to suggest a workshop, and the other half has already been through the workshop and would prefer not to repeat the experience.
What I mean by it is more boring than the workshop version. The path the work and the information have to travel to turn an unmet customer need into something they pay for, or come back for. That path crosses functions and systems, and almost never matches the org chart cleanly.
The mapping is the easy part, and most companies are pretty good at it. What separates the companies that get value out of the exercise from the ones that do not is whether anybody is keeping the map current six months later, whether the operating team can actually see what is happening inside it without asking somebody to pull a report, and whether anybody has the authority to act on what the instrumentation shows when it shows something. The clients who treat the map as a dashboard get somewhere with it. The clients who treat it as art produce a binder.
Empathy is doing less than people think it is.
I have started avoiding the word empathy in client conversations. Every executive I work with believes in it, and almost none of them can tell me what their empathy is doing on a Tuesday afternoon when somebody on their team has to make a real trade-off.
The version of it that earns its place in operating work is more mechanical than the word suggests. Can the operating team describe, without going to look it up, what state the customer is in when they show up to your channel, what they are trying to get done, what is in their way, and what they would do tomorrow if your service stopped existing. If the answers come fast and consistent across the team, you have something to work with. If they come slow, or differently from every person you ask, what you have is a value statement on a wall.
The way to build it is not a workshop, and it is not a research function reporting up to leadership. It is forcing the operating team to make a handful of real trade-off decisions every quarter using customer evidence the team gathered itself. The first time around is painful. By the fourth, the muscle is there, and decisions that used to take eight weeks of debate take an afternoon.
AI changes the listening more than it changes the deciding.
Clients keep asking me whether AI is going to remake all of this. It is going to do part of it, and the part it is going to do is mostly the listening.
The signal a competent team can now pull out of post-call transcripts, chat logs, survey free-text, and social mentions is a step change from what the old qualitative methods could surface in any reasonable timeframe. The teams using this well are catching problems in the customer experience weeks or months earlier than they used to, and surfacing patterns across channels that a research team reading transcripts manually would have missed. That part is real and the gap between the teams using it and the teams not using it is widening.
What AI is not doing, and is not going to do soon, is the deciding. If a model surfaces a handoff problem at two in the morning and nobody in the operating model has been given the authority to act on a handoff problem at nine, what you have bought is a more expensive dashboard. The companies pulling ahead are the ones that stood up the accountability for the seams first and layered the listening capability on top. The ones running it the other way are accumulating insight they cannot act on.
Most of what good XA does is take things out.
The instinct in a large company, when the customer experience feels off, is to add something to it. A new touchpoint. A new module. A new email in the sequence. Another notification. A personalization layer firing on segments somebody defined three years ago.
The clients I have watched fix this are mostly removing things rather than adding them. They look at a sequence that is not working and ask what would happen if a step came out, or a channel was retired, or a piece of personalization logic was turned off. Most of the time the answer is that nothing much would happen, which is the answer that tells you the thing should probably not have been there to begin with.
This is not a popular message in rooms full of people whose jobs were created by adding things. I understand that. I have been the guy who added the thing.
The cost shows up somewhere you are not looking.
The reason most leaders do not see the cost of getting this wrong is that the cost rarely shows up in the dashboards they built to detect it. Satisfaction scores move slowly, NPS moves slowly, and when those numbers do move, somebody on the team can usually find a seasonal explanation that defers the conversation for another quarter.
The cost shows up somewhere else. It shows up in the operations leader who has stopped raising her hand in the cross-functional meeting because she has watched the same handoff problem die in committee more than once. It shows up in the long-tenured service rep who can describe exactly where the sequence breaks and has stopped saying so out loud, because saying so for the last two years has not changed anything. It shows up in the customer who did not churn loudly, did not write the angry email, and just quietly stopped opening yours and stopped calling, and was already gone by the time the renewal conversation came around.
That last one is the one I keep coming back to. Most of the time, when this work is not done, that is what it costs you. A long slow quiet that the system was not built to detect.
That is the work, and it is mostly what I am doing now.
Cheers! -AM