January
26
Tags
Customer experience is a decision problem, not a design problem

Most organisations believe they have a customer experience problem. And, if like me, you believe CX is the unifying theory of everything for marketing, that is bad news.
Journeys feel fragmented. Personalisation feels awkward. Automation feels efficient but oddly cold. Teams redesign touchpoints, refresh interfaces and rewrite tone of voice, yet the experience stubbornly fails to improve in any meaningful way.
The uncomfortable truth is this: customer experience rarely fails at the surface. It fails upstream.
Experience is not primarily shaped by what customers see. It is shaped by the decisions organisations make long before a customer ever arrives.
That is why customer experience needs to be understood through two distinct but connected lenses: decision architecture and choice architecture.
The real source of customer experience
Every customer experience is the outcome of two invisible layers.
Decision architecture determines how an organisation decides what should happen.
Choice architecture determines how those decisions are presented to customers as options.
Together, they determine why experience manifests as it does, regardless of intention. This is structural, not aesthetic.
Decision architecture: Where experience is really shaped
Decision architecture is the internal logic that governs experience before it is ever expressed.
It includes:
- Strategic priorities and trade-offs
- Rules, policies and eligibility criteria
- The data signals that are trusted or ignored
- Incentives, KPIs and performance measures
- Automation thresholds and escalation rules
- Governance, accountability and risk controls
This layer answers a critical question: Why does the experience behave the way it does?
When organisations optimise for efficiency
Poor decision architecture: A bank automates account closures to reduce call centre costs. The decision architecture includes no human review threshold for long-standing customers. A customer with 30 years of history who triggers a fraud flag due to unusual but legitimate spending finds their account frozen, then closed, with only a generic email explanation. The efficiency saving is real. The customer is gone.
Good decision architecture: The same bank automates routine closures but builds in escalation rules based on customer tenure and value signals. Long-standing customers trigger human review. The efficiency gain is slightly smaller, but trust is preserved where it matters.
The choice architecture – the email, the interface, the tone – is identical in both cases. The decision architecture determines whether efficiency serves the relationship or replaces it.
When organisations optimise for short-term conversion
Poor decision architecture: An e-commerce site prioritises next-purchase conversion above all else. The decision architecture rewards immediate sales but doesn’t constrain promotional intensity. Email frequency climbs. Discount depth increases. Customers learn to wait for bigger offers. Margin erodes. Customers who would have bought anyway are trained to expect discounts. Revenue rises quarterly, then plateaus as the only remaining lever is more aggressive discounting.
Good decision architecture: The same retailer optimises for conversion but includes constraints: maximum email frequency per segment, discount depth limits by product category, and a customer lifetime value model that penalises cannibalising full-price purchases. Short-term conversion is still pursued, but within boundaries that protect long-term value.
Again, the emails, the offers, the website experience look similar. The decision architecture determines whether conversion is pursued sustainably or extractively.
When organisations optimise for growth at all costs
Poor decision architecture: A fintech app optimises for account sign-ups. The decision architecture rewards volume with no qualification thresholds. Identity verification is minimal. Onboarding friction is removed entirely. Sign-up rates soar. Fraud rates follow. Genuine customers find themselves locked out while the system fights abuse. The growth is real but fragile. Regulatory attention arrives.
Good decision architecture: The same fintech optimises for growth but builds verification thresholds, velocity limits and risk scoring into the decision architecture from the start. Sign-up is still fast for legitimate customers. Fraud is contained. Growth is slower initially but sustainable. The product can scale without breaking.
The onboarding interface – the screens, the copy, the progression – could be nearly identical in both cases. The decision architecture determines whether friction is removed intelligently or recklessly.
The pattern
These outcomes are not accidents. They are decisions, even when no one explicitly names them as such.
In every case, the difference between good and bad outcomes is not what customers see. It is what the organisation decided before the customer arrived.
Poor decision architecture optimises for a single outcome without constraints.
Good decision architecture optimises for an outcome within boundaries that protect what must not be sacrificed.
Choice architecture cannot repair this. It can only dress it up, and only temporarily.
Choice architecture: Where customers feel the consequences
Choice architecture is where internal decisions become human experiences.
It shapes:
- Which options customers see
- What is included, excluded or bundled
- Defaults, framing and sequencing
- The effort required to act
- Timing, reassurance and feedback
This layer answers a different question: How does the experience feel in the moment of choice?
Default settings and pre-selections
Poor choice architecture: An insurance renewal auto-selects all optional extras the customer purchased last year, with a single “remove all” link buried at the bottom of the page. The customer must actively deselect each item or start over. Most don’t notice until the payment goes through. The decision architecture may allow customer choice, but the choice architecture makes inaction the profitable path.
Good choice architecture: The same renewal presents last year’s selections clearly but requires active confirmation for each optional extra. A simple “keep everything” or “review individually” choice is offered upfront. The effort to maintain coverage is equal to the effort to change it. The customer feels in control rather than managed.
The decision architecture is identical – the customer can choose either way. The choice architecture determines whether that feels like autonomy or manipulation.
Information sequencing and framing
Poor choice architecture: A subscription service shows pricing annually by default (“just £8.25 per month – billed yearly at £99”). The monthly option exists but requires clicking through to “see other plans”. The decision architecture offers both choices. The choice architecture makes one feel like the default and the other like an afterthought.
Good choice architecture: The same service presents monthly and annual pricing side-by-side with equal visual weight. The annual option shows the saving clearly (“£99 annually – save £20 vs monthly”). Both options are presented as legitimate choices, not as a preferred option and its alternative.
The decision architecture provides the same options and the same economics. The choice architecture determines whether customers feel guided toward value or steered toward commitment.
Explanation and reassurance
Poor choice architecture: A mortgage application rejects a customer with the message: “Unfortunately we are unable to offer you a mortgage at this time.” No explanation. No next steps. No indication of what changed or what might help. The decision architecture may be sound – the customer genuinely doesn’t qualify. The choice architecture leaves them confused and abandoned.
Good choice architecture: The same rejection explains: “Based on your current income and the property value, the deposit required would be 25% rather than the 10% you indicated. This is because [specific reason]. You could: reapply with a larger deposit, consider a lower-priced property, or speak with an adviser about other options.” The decision is identical. The choice architecture makes it understandable and actionable.
The decision architecture determined the outcome. The choice architecture determined whether the customer learned something or just felt rejected.
Timing and interruption
Poor choice architecture: A retail website interrupts checkout to offer a loyalty card sign-up, requiring either registration or explicit dismissal before proceeding to payment. The decision architecture may value loyalty enrolment. The choice architecture makes it feel like a barrier rather than an offer.
Good choice architecture: The same offer appears after purchase completion: “Thank you for your order. Would you like to earn points on your next purchase? Join our loyalty programme now or we’ll remind you next time.” The timing respects the customer’s immediate goal. The offer feels helpful rather than obstructive.
The decision architecture wants the same enrolment. The choice architecture respects or ignores the customer’s current intent.
The revealing test: when good choice architecture meets bad decision architecture
Even excellent choice architecture cannot repair flawed decision architecture.
Consider a payday loan application with exemplary choice architecture: clear pricing, prominent warnings about debt risks, fair default settings, comprehensive explanations. Every element of choice architecture is well-designed.
But if the decision architecture sets interest rates at levels that make repayment systematically difficult, or targets vulnerable customers specifically, or optimises for repeat borrowing, no amount of clear presentation changes the fundamental outcome.
The customer may feel fully informed and in control at the moment of choice. The damage occurs later, when the decision architecture’s true priorities become apparent.
This is why choice architecture cannot be the starting point. It can make good decisions feel better or bad decisions feel more honest, but it cannot transform the decision itself.
The pattern
Good choice architecture helps customers feel guided and confident. Poor choice architecture makes customers feel rushed, manipulated or confused.
But crucially, choice architecture cannot repair bad decision architecture. It can only disguise it, and only temporarily.
The real work happens upstream, where decisions are made about what customers will be offered, under what conditions, and optimised toward what end.
That is why customer experience must be understood as a decision problem first, and a design problem second.
Why most CX initiatives struggle
Most CX programmes focus almost entirely on choice architecture.
They improve:
- Interfaces
- Journeys
- Content
- Messaging
- Service scripts
But they leave decision architecture untouched.
The result is familiar:
- Better-looking journeys with the same outcomes
- Personalisation without trust
- Automation without accountability
- Activity without progress
Experience improves cosmetically, then stalls.
The missing discipline: Designing decisions before designing experiences
If customer experience is shaped by decisions, those decisions need their own design process.
This is not about documenting existing decisions or mapping current logic. It is about deliberately constructing the decision architecture that will shape experience.
That requires answering four questions before any customer ever encounters the result:
What evidence will we trust? Not what data we have, but what signals we will treat as valid and where uncertainty remains acceptable.
Whose outcomes will we prioritise? Not which customers we serve, but whose needs take precedence when trade-offs become unavoidable.
Which opportunities will we pursue? Not what looks attractive, but what we can deliver while maintaining the promises that matter.
What will we actually optimise for? Not what we claim to value, but what our incentives, metrics and constraints will enforce in practice.
These questions create decision architecture. They make the invisible layer visible and subject to design.
This is where the ICONIC framework operates.
Where ICONIC fits in the CX system
ICONIC is not a customer experience framework. It should never be positioned as one.
ICONIC is a decision framework. Its role is to create the decision architecture that shapes experience.
Through Investigate, Customers, Opportunities and Numbers, ICONIC constructs the logic that governs:
- What evidence is trusted
- Whose needs are prioritised
- Which trade-offs are accepted
- What the organisation actually optimises for
Implementation and Contribution then express and evaluate those decisions in practice.
ICONIC does not explain how customer experience forms. It designs the conditions under which experience emerges.
The relationship is clean:
Decision architecture and choice architecture explain how customer experience forms. ICONIC creates the decision architecture that feeds that system.
ICONIC sits upstream. It governs the decisions. It does not replace the experience itself.
The leadership implication
Customer experience cannot be fixed at the edges. It must be designed at the centre, where decisions are made.
When organisations take responsibility for decision architecture first, choice architecture starts to work properly. Trust becomes structural, not performative. Experience stops being something delivered to customers and becomes something they can rely on.
That is the foundation.
But there is a second shift coming, and it is more uncomfortable than the first.
Because as AI, automation and agentic systems become embedded in organisations, those decisions are increasingly made by machines. That changes the nature of customer experience completely.
Discover more from jam partnership
Subscribe to get the latest posts sent to your email.

