UX, CX and the Other Xs

🎯 Outcome-driven CX metrics: measure resolution, not “how people felt”

Many teams measure CX with survey scores — short questions like:
“How satisfied are you?”
“Would you recommend us?”

These are easy to collect and easy to report. But they don’t prove the key thing:
Did the user finish the task and did the problem actually get solved?

ISO 9241-11, the usability standard, says that experience quality is measured first by whether users achieve their goal. Next, it looks at how much time and effort it takes. Only after that does it consider how satisfied they feel.

Outcome metrics to center your CX:

1. Completion rate
Did users complete the flow you designed?
Track it in analytics: started → finished.

2. Resolution rate
Funnels can look “good” while users still leave without solving their issue.
Add one simple question after the task: “Did you solve your problem today?” (Yes / Partly / No)

3. Repeat contact
If support is part of the journey, measure if the issue stays solved:
Did they contact us again within 7 days about the same problem?

4. Time + friction
How hard was it?
When users succeed, check how hard it was: Time, steps, errors/retries.

Guiding principle: survey scores provide context. Experience quality is best shown by task completion and problem resolution.

🧚‍♀️ A design system needs an enforcer or it will drift

A design system doesn’t fail because components are imperfect.
It fails when no one has the authority and responsibility to keep teams aligned.

When there is no clear owner, teams do what they must to ship:
• they copy a component and tweak it for one case
• they create a custom token
• they build a parallel version and promise to merge it back later

That is how design drift starts. Small exceptions become many almost-the-same versions, and consistency disappears.

An enforcer is not design police, but a person or small group with decision rights to keep the design system usable and consistent.

Their job is to:
1. drive adoption by removing friction and blockers
2. turn local fixes into shared updates so variations become system changes, not one-off patches
3. handle real exceptions fast with a clear decision that stays visible

The part most teams miss is decision rights plus speed.
If system updates take weeks, teams will bypass the system. An enforcer needs clear ownership and a fast response time.

Two metrics show how your design system works in real life:
1. adoption or coverage: how much UI uses system components and tokens
2. deviations or drift: how many custom variants appear in production

Read them by trend. If deviations rise sprint by sprint, drift is already happening.

A design system is a shared contract. Without enforcement, it becomes documentation, and teams will keep building their own versions.

🧈Less choice, less friction (CX trend 5)

Early in my career, the 5±2 rule was a must-have principle for UX designers. The idea was simple: too many options slow people down.

Our own testing showed the same thing: when there were too many options, especially when they were hard to compare - people hesitated, postponed, or dropped the flow.

What’s changed now? Not much. Designers still aim for fewer comparisons, fewer mistakes, and fewer regrets. But the data shows the problem is still very real.

Checkout is a clear case of decision overload: many “fields” are actually decisions. Baymard’s benchmarks show there’s still a lot of room for improvement. A typical checkout shows ~23 form elements, while a strong flow can be ~12 - 14.

How you can reduce choice without removing flexibility:

1. Recommend the best fit
Make the default path obvious. But let power users go deeper.

2. Ask one intent question before showing options
Narrow the set first, then show the shortlist.

3. Show consequences next to the choice
Fees, refunds, delivery, feature loss - right where the user decides.

One of the metrics that tells you it’s working: option-change rate. If people stop switching after selecting, you’re not just simplifying - you’re reducing second guessing.

🔗 Context continuity is expected, not appreciated (CX trend 4)

Users don’t see “we remember your context” as something special. They see it as the minimum standard. If they have to repeat the same details after switching a channel, frustration rises fast.

Salesforce data shows the expectation reality gap clearly: 79% of customers expect consistent interactions across departments, but 56% still have to repeat or re-explain information to different reps. From the business side, broken handoffs also increase cost-to-serve - you pay for repeat contacts and extra time spent searching for the same data across different systems. 

What to do in product design:
1. Create a portable “context package” that moves with the user across your product and channels:
• case/ticket ID
• current status
• actions log (what the user already tried)
• entered data (what the system already knows)
• recommended resolution (the next best step)

2. Enforce a handoff summary at every transfer (bot → agent, agent → another team, chat → call):
• problem in 1 line
• what was done (2–3 bullets)
• what the next person needs to do
This prevents the classic “tell your story again” moment.

3. Measure context loss directly, not only CSAT (Customer Satisfaction Score):
Track % of handoffs where the user repeats at least one fact the company already has (e.g., order number, address, issue description, previous troubleshooting). This metric shows exactly where continuity fails.

When continuity works, users rarely say “thanks for remembering.” They just move on. But when continuity fails, it affects their overall perception of your brand - fast.

🤖 Explainability over Automation

Automation is no longer a competitive advantage. It is a baseline.

What breaks customer experience in 2026 is not automation itself, but automation without explanation.

Products increasingly make decisions on behalf of users: blocking payments, changing limits, hiding content, rejecting actions. From a system perspective, this is efficiency. From a user perspective, this is loss of control.

As a result:
1. users don’t understand what caused the decision
2. users don’t know how to change the outcome
3. support becomes the only path forward

Multiple studies across UX and AI research confirm the same pattern.

1. Google People + AI Research shows that users trust automated systems only when they understand why a decision was made and when they should rely on it. Explainability helps users form correct mental models, not blind trust.
2. Recent empirical XAI studies (2024-2025) show that explainable systems significantly increase perceived control, trust, and user acceptance compared to black-box automation.

The conclusion is consistent: speed without understanding feels unsafe.

Practical UX rule

Every automated decision should clearly surface:
1. Decision - what happened?
2. Reason - why it happened?
3. Next step - how the user can proceed?

Automation without explanation is not smart UX. It is fast confusion.

✅ Self-Service shifts from Information to Resolution (CX trend 3)

For years, self-service meant explaining things to users through FAQs, help articles, and guides. This approach no longer works.

The problem is not that users don’t understand what happened.
The problem is that they can’t do anything about it.

As a result:
1. users get stuck in broken or partial states
2. “contact support” becomes the default outcome
3. operational costs grow without improving the experience
Information without the ability to act does not resolve a problem.

Products are more complex and automated than before.
When something breaks, users don’t ask:
“Can you explain this to me?”
They ask:
“How do I fix this?”

Self-service must be designed around resolution, not content.
Users should be able to, without waiting for support:
1. correct incorrect data
2. undo or retry failed actions
3. cancel or restart broken flows

If a user understands the problem but cannot fix it,
and the only available outcome is “contact support”,
this is not self-service.

Self-service is not about telling users what to do. It is about giving them control to do it. 🥰

⚠️ Failure-First Experience

Most products are still designed for ideal scenarios.
Errors are treated as exceptions, not as part of the experience.

As a result, error states are written by engineers, edge cases are covered by analysts — and no one owns the user experience when things break.

This leads to predictable outcomes:
1. Users don’t understand what happened, what to do, or where to go
2. Trust drops fast
3. Support costs go up

What Failure-First Experience means

Designing CX starting from:
1. Errors
2. Cancellations
3. Refunds
4. Rollbacks
5. Partial or broken states
Not as secondary screens, but as first-class scenarios.

For every critical screen, the product must answer:
How does the user understand that something went wrong?
What can they do right now?

Practical UX rules
Every error or failure state should clearly show:
1. Status — what is happening right now
2. Reason — why this happened
3. Next step — what the user can do

A user should never be left in a dead end.
If an error screen only says “Something went wrong”, this is not CX.

CX Trends 2026 ✨

CX 2026 is not about delight, wow effects, or emotional storytelling.
It is about clarity under stress, control in uncertainty, and the ability to recover when things break.

1. Failure-first experience
Customer experience is no longer defined by how smooth the happy path is, but by how clearly systems handle errors, edge cases, and recovery.

2. Explainability over automation
Automation without explanation breaks trust. Users expect to understand why something happened and what they can do next.

3. Self-service shifts from information to resolution
Customers no longer want to be informed. They expect to fix, undo, retry, and recover without contacting support.

4. Context continuity is expected, not appreciated
Remembering the user’s state across steps, channels, and time is no longer a differentiator. It is a baseline.

5. Choice reduction becomes a CX strategy
Great CX is about fewer options and clearer consequences, not unlimited flexibility.

6. Outcome-driven CX Metrics
Experience quality is measured by whether users completed their task and resolved their problem — not by how satisfied they felt.

Next posts: a deeper dive into each trend.

Positive Friction in Payments

Following the logic of desirable difficulty, HCI research shows a consistent pattern: when payment flows are optimized only for speed, error rates go up. That’s why we often see confirmations (OTP) or a final review step before a payment — a basic guardrail against autopilot mistakes.

This pattern is not accidental. Preventing errors is more effective than fixing them later, especially in high-risk flows. Yes, everyone wants less friction. But businesses win when users make fewer costly mistakes: fewer support tickets, fewer disputes, less regret, and a better overall experience.

There is an important balance, though. Too much friction irritates users. Overly complex payment flows increase drop-off and push people toward simpler alternatives — which is why phone-to-phone transfers feel so convenient. In many everyday cases, that simplicity is the right trade-off.

The key is selective friction: keep flows fast for low-risk actions like topping up an account, and add intentional friction for high-risk actions like withdrawing funds, where a mistake in payment details can lead to money loss.

In payments, intentional friction is not a defect. It is a risk-management tool that reduces the cost of errors — even if it slightly reduces the feeling of speed.

Some sources:
https://www.interaction-design.org/literature/article/positive-friction-how-you-can-use-it-to-create-better-experiences
https://www.nngroup.com/articles/preventing-user-errors/

Positive Friction: when resistance improves UX

In cognitive psychology, there is a well-studied effect called desirable difficulty. Robert Bjork (UCLA) showed that when learning feels a bit harder, people remember better and can apply knowledge in new situations.

A simple example: rereading notes feels easy, but self-testing (trying to recall without looking) feels harder — and works better. The effort is the feature.

This extra effort forces conscious thinking, reduces automatic mistakes, and improves later decisions.

Traditionally, UX tries to remove friction everywhere. Positive friction is different: slowing users down helps them avoid mistakes or understand consequences.

Another example, screen-time apps add a short delay before opening a “distracting” app. Those few seconds break autopilot — and often users choose to do something else instead.

Intentional friction is not complexity for its own sake. It moves users from automatic action to conscious choice.

To be continued.

Source: Robert A. Bjork, Desirable Difficulties in Theory and Practice