đ¤ 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.
783
4
0
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
đˇ Photo
â 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. đĽ°
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
đˇ Photo
â ď¸ 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.
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
đˇ Photo
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/
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
đˇ Photo
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.
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
If your UI relies on subtle shades, it will break in system modes
You can get a UI looking âperfectâ with tiny color nuances: borders slightly darker than the background, disabled states a bit faded, secondary text â20% lighterâ. In normal mode, it works.
But once a user enables Dark Mode / High Contrast / Forced Colors, the browser and OS start protecting legibility and may override your colors. Those nuances turn into noise: states become indistinguishable, dividers disappear, links look like plain text. That âwho gets to recolor whatâ is exactly what the latest W3C update is about.
What to do (practical):
1. Donât encode meaning in âslightly different gray.â
If something must be distinguishable, it needs a second cue beyond color: underline for in-text links, a clearer outline or background, thicker stroke, an icon, spacing, or shape. (Color can be one signal, just not the only one.)
2. Test in system modes â itâs the fastest crash test for your design system.
For example, in Chrome: DevTools â More tools â Rendering â set prefers-color-scheme: dark (or enable âautomatic dark modeâ).
If meaning disappears (states, dividers, links, focus), your UI depends on shades.
3. Make sure the browser understands you support dark color schemes.
Otherwise you get the classic mismatch: dark page, but âlightâ native controls (inputs/scrollbars) because the UA doesnât know your page is dark-mode aware.
Source: https://www.w3.org/TR/css-color-adjust-1/?utm_source=chatgpt.com
https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Color_adjustment?utm_source=chatgpt.com
528
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
Scale kills custom: why enterprise more often embeds payments than builds them đ¸
A recent Stripe data point: large SaaS platforms are almost 3Ă more likely to adopt prebuilt embedded payments/finance components than startup platforms.
Stripeâs explanation is âcomplexity at scale.â Hereâs what that actually means in product terms:
1. Compliance + localization multiply the UX surface area
Once you go multi-country, payments UX stops being âone flow.â Requirements diverge (data, verification, copy, documents, edge cases), and a custom variant per market turns into ongoing operational debt.
2. In money flows, the cost of failure dominates the value of perfection
In payouts, disputes, and onboarding, âsmall UX glitchesâ are rarely small: they become support load, trust loss, and financial risk. At enterprise scale, the winning solution is often the most predictable and standardizable one - not the most bespoke.
3. Enterprise ships continuously
Stripe points to continuous shipping as a driver. One example they cite: Kajabi delivered an integration with Xero in 6 weeks, versus a âtypicalâ 6-12 months timeline. Or when legal drops a new requirement at any time - how fast can you update the flow? đ
Time-to-production becomes part of product quality in money flows: stability and scalability beat bespoke polish.
Your design system needs a way to host ânon-nativeâ UI.
Source: Stripe analyzing how SaaS platforms are shipping payments and finance products in days https://stripe.com/blog/analyzing-how-saas-platforms-are-shipping-payments-and-finance-products-in-days
592
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
đˇ Photo
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
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
Contextual menus are not a discoverability problem. They are a decision-making problem.
As everyone already knows, contextual menus trade visibility for focus. Nothing new here â this is a well-established pattern. What breaks products is not that users âdonât findâ actions. Itâs that teams use contextual menus to avoid committing to hierarchy.
NN/g is right about the basics: contextual menus work best for infrequent, secondary, or expert actions. The misuse starts when menus become a dumping ground.
Hereâs the failure mode I see over and over. Actions are moved into a contextual menu not because they are secondary, but because they are uncomfortable to prioritize â too controversial, too political, or too unclear in value. So they get hidden âfor now.â The menu becomes a design escrow account.
The cost is subtle but real. Users donât fail to discover actions; they fail to understand what matters. When important and unimportant actions live in the same invisible space, users stop building a mental model. They click to explore not because they understand, but because they guess.
One practical check I use: if this action were removed tomorrow, would the core task still feel complete? If the answer is no, it doesnât belong in a contextual menu. Resolve the decision first. Then design the menu.
Source: Nielsen Norman Group â Contextual Menu Guidelines
http://www.nngroup.com/articles/contextual-menus-guidelines/
489
UX, CX and the Other Xs
May 17, 2026, 04:14 PM
How to tell if a new feature Is alive without fooling yourself with conversion
We often measure features by clicks or overall conversion â and then spend weeks arguing whether it âworkedâ. The problem: those metrics answer âDid people touch it?â, not âDid it create value?â
A feature is alive only if it creates incremental impact â i.e., outcomes would be worse without it.
What to track instead of clicks/conversion
1ď¸âŁ Define the target user (Target)
One sentence: âThis feature is for users who _ and get stuck at _.â
2ď¸âŁ Pick a value event (Adoption)
Not âopenedâ or âclickedâ, but the action that proves value: created, submitted, saved, applied, completed a step.
3ď¸âŁ Check repeat use (Retention)
If people donât come back, the feature is either not needed, too hard, or poorly embedded in the flow.
4ď¸âŁ Ask one question (Satisfaction)
To real users of the feature: âDid this make task X easier?â (1â5 scale)
How to stop debating âeffect vs coincidenceâ
You need a control: A/B test (best) or a staged rollout by segment. Otherwise youâre measuring background noise, not the feature.
One honest business number
Saved outcomes = (Outcome with feature â Outcome without) Ă number of target users.
No saved outcomes â the feature isnât product value (itâs decoration or a workaround).
If you want the full framework and how itâs structured as TARS, read: Smashing Magazine â http://www.smashingmagazine.com/2025/12/how-measure-impact-features-tars/?utm_source=chatgpt.com
613
UX, CX and the Other Xs
Mar 26, 2026, 11:47 PM
Channel created
0
0
0
Showing 11 of 11 posts
No more posts
767
5
0
699
5
0
642
3
0
650
4
0
4
0
4
0
608
4
0
2
0
3
0
No reviews yet. Be the first to share your experience!
