Canale Telegram "UX, CX and the Other Xs"

UX, CX and the Other Xs

Public

Attenzione : È importante fare le proprie ricerche prima di fidarsi di qualsiasi informazione, in particolare se è coinvolta una richiesta di denaro.

Non riesci ad unirti? @UXCXPX

211 Membri

Aggiornato: March 11, 2026 at 9:35 AM

UX, CX and the Other Xs

Source-backed UX/CX insights: research, patterns, and anti-patterns

Join @UXCXPX for exclusive sourcebacked and research content and discussions in 1

Classifica

Classifica globale

#3823Nessun cambiamento

Classifica per lingua

#847Nessun cambiamento

Classifica per categoria

#15Nessun cambiamento

Crescita abbonati (Ultimi 3 giorni)

Totale: 211

Crescita 24h: +22 12%

Ultimi post

UX, CX and the Other Xs

11 mar 2026, 18:11

📷 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.

532

UX, CX and the Other Xs

11 mar 2026, 18:11

📷 Photo

🤖 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.

UX, CX and the Other Xs

11 mar 2026, 18:11

📷 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

11 mar 2026, 18:11

📷 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

11 mar 2026, 18:11

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

454

UX, CX and the Other Xs

11 mar 2026, 18:11

📷 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

11 mar 2026, 18:11

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

465

UX, CX and the Other Xs

11 mar 2026, 18:11

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

406

UX, CX and the Other Xs

11 mar 2026, 18:11

Channel created

UX, CX and the Other Xs

11 mar 2026, 18:11

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/

393

Showing 10 of 10 posts

No more posts

Loading posts...

Valutazione

Accesso richiesto

Recensioni degli utenti (0)

Nessuna recensione ancora. Sii il primo a condividere la tua opinione!

Loading reviews...

UX, CX and the Other Xs

Source-backed UX/CX insights: research, patterns, and anti-patterns

Join @UXCXPX for exclusive sourcebacked and research content and discussions in 1

Classifica

Classifica globale

#3823Nessun cambiamento

Classifica per lingua

#847Nessun cambiamento

Classifica per categoria

#15Nessun cambiamento

Crescita abbonati (Ultimi 3 giorni)

Totale: 211

Crescita 24h: +22 12%

Ultimi post

UX, CX and the Other Xs

11 mar 2026, 18:11

📷 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.

Loading posts...