Le peggiori anti-pattern UX e come risolverli

La settimana scorsa ho provato a modificare le preferenze sui cookie sul sito di una grande compagnia aerea. Il pulsante 'Accetta tutto' era di un blu acceso, impossibile da non vedere. Il link 'Gestisci preferenze'? Testo grigio, font da 11px, nascosto sotto un paragrafo di legalese. Quando finalmente l'ho trovato, mi sono ritrovato in una pagina con 47 interruttori singoli, tutti attivi per impostazione predefinita, e nemmeno l'ombra di un pulsante 'Rifiuta tutto'. Sono rimasto lì per un minuto intero a cliccare interruttori prima di arrendermi e cancellare manualmente i cookie.

Non è un caso isolato. È la norma. Una cattiva UX non è solo fastidiosa, è ostile. E la parte peggiore? La maggior parte di questi anti-pattern ha soluzioni semplicissime, che richiedono meno tempo da implementare delle acrobazie dei dark pattern che sostituiscono. Sviluppo web app da oltre dieci anni e mi lascia davvero perplesso che continuiamo a rilasciare queste cose. Quindi parliamo dei peggiori colpevoli e di come eliminarli.

Dark pattern che trattano gli utenti come prede

I dark pattern non sono incidenti. Qualcuno si è seduto a una riunione, ha guardato le metriche di conversione e ha deciso che ingannare gli utenti fosse una strategia di business accettabile. Ed è proprio questo che li rende così irritanti: sono deliberati.

Confirmshaming: il senso di colpa come elemento dell'interfaccia

Li avete sicuramente visti. Appare un modale che ti chiede di iscriverti a una newsletter. Il pulsante di accettazione dice « Sì, voglio risparmiare! ». Quello di rifiuto dice « No grazie, preferisco pagare il prezzo pieno ». Questo è il confirmshaming, ed è ovunque: siti e-commerce, flussi di onboarding SaaS, persino alcuni strumenti per sviluppatori. Funziona su una piccola percentuale di utenti e allontana tutti gli altri.

La soluzione è imbarazzantemente semplice: usare un linguaggio neutro per entrambe le opzioni.

<!-- BEFORE: Manipulative confirmshaming -->
<div class="modal">
<p>Join 50,000 smart developers!</p>
<button class="btn-primary">Yes, sign me up!</button>
<button class="btn-link text-sm">
No thanks, I don't care about my career
</button>
</div>
<!-- AFTER: Respectful, neutral options -->
<div class="modal">
<p>Get weekly frontend tips — no spam, unsubscribe anytime.</p>
<button class="btn-primary">Subscribe</button>
<button class="btn-secondary">No thanks</button>
</div>

Notate che la versione corretta elimina anche la prova sociale gonfiata e aggiunge una promessa chiara sullo spam. Il rispetto genera più fiducia della manipolazione. Il vostro tasso di conversione a lungo termine ve ne sarà grato.

Il Roach Motel: iscrizione con un clic, disdetta in sette passaggi

Iscriversi richiede 30 secondi. Per disdire bisogna andare su Impostazioni > Account > Abbonamento > Gestisci piano > Annulla piano > Dicci perché > Sei sicuro > Parla con il servizio clienti > Annulla davvero. Alcuni servizi richiedono ancora una telefonata. Nel 2026. Per disdire un abbonamento che hai attivato con un solo clic.

Non mi interessa cosa dicono le vostre metriche di retention. Gli utenti intrappolati non sono clienti fedeli, sono ostaggi che generano chargeback e recensioni da una stella. Rendete la disdetta esattamente facile quanto l'iscrizione.

Mettete l'opzione di annullamento nelle Impostazioni account, dove la gente se l'aspetta
Massimo due passaggi: « Sei sicuro? » e poi « Fatto, il tuo account è stato annullato »
Non nascondete il pulsante di annullamento dietro un link « Contatta il supporto »
Se offrite uno sconto di retention, va bene, ma non rendetelo un passaggio obbligatorio del flusso
Inviate un'email di conferma con un link per la riattivazione invece di far sembrare l'annullamento irreversibile

Interruttori ambigui e controlli UI confusi

Ecco un esperimento divertente: vai nelle impostazioni del telefono e conta quanti interruttori non riesci a capire subito se sono attivi o disattivati. Aspetto.

Il toggle ambiguo è uno dei difetti UI più comuni che incontro nelle code review. Un toggle dovrebbe comunicare una sola cosa: lo stato attuale. È attivo o disattivo? Tutto qui. Eppure gli sviluppatori continuano a rilasciare toggle dove i due stati sembrano quasi identici, oppure dove il colore è ambiguo, oppure dove il toggle mostra cosa succederà dopo invece di cosa sta succedendo ora.

/* BEFORE: Both states look nearly identical */
.toggle {
width: 48px;
height: 24px;
background: #d1d5db;
border-radius: 12px;
cursor: pointer;
}
.toggle.active {
background: #9ca3af; /* barely different from inactive */
}
/* AFTER: Unmistakable state difference + accessible */
.toggle {
width: 48px;
height: 24px;
background: #d1d5db;
border-radius: 12px;
cursor: pointer;
position: relative;
}
.toggle[aria-checked="true"] {
background: #2563eb; /* strong contrast from inactive */
}
.toggle .label {
font-size: 10px;
font-weight: 600;
color: white;
}
.toggle[aria-checked="true"] .label::after { content: "ON"; }
.toggle[aria-checked="false"] .label::after { content: "OFF"; }

Tre regole per toggle che non confondono le persone: colori distinti per ogni stato (con contrasto sufficiente anche per gli utenti daltonici), un'etichetta di testo dentro o accanto al toggle e attributi aria-checked corretti, così gli screen reader possono annunciare lo stato. Se vi affidate solo al colore, avete sbagliato sia la UX sia l'accessibilità con una sola mossa.

Smettete di reinventare i controlli nativi dei form

Faccio molte review di PR frontend, e un pattern mi fa uscire di testa: i menu a tendina costruiti da zero che rompono la navigazione da tastiera. Uno sviluppatore passa due giorni a costruire un select elaborato da zero con un mucchio di div e gestori di click. Nella demo sembra fantastico. Poi un utente prova a navigare un form con il Tab, arriva sul dropdown personalizzato e non succede nulla. Nessun supporto per i tasti freccia. Nessuna ricerca per digitazione. Non funziona con i password manager. Si rompe su mobile.

Nel frattempo, l'elemento nativo <select> o una libreria ben testata come Radix UI o Headless UI gestiscono tutto questo gratuitamente. L'API popover HTML e l'elemento <selectlist> hanno ormai un buon supporto nei browser. Usateli. Ai vostri utenti non interessa che il menu abbia un'animazione personalizzata. Interessa che funzioni.

Anti-pattern di accessibilità che escludono gli utenti reali

L'accessibilità non è un optional. Non è una funzionalità da aggiungere in uno sprint futuro. Oltre un miliardo di persone nel mondo convive con qualche forma di disabilità, e il report WebAIM Million rileva costantemente che il 96% e oltre dei primi un milione di siti web presenta errori WCAG rilevabili. Non sono casi limite oscuri: sono pulsanti rotti, etichette mancanti e immagini senza testo alternativo.

Ecco cosa vedo più spesso:

Immagini senza testo alternativo: gli screen reader dicono solo « immagine » e passano oltre
Rapporti di contrasto sotto 4,5:1: il testo diventa illeggibile per gli utenti ipovedenti
Nessuna navigazione da tastiera: se non si può usare il Tab nell'app, gli utenti da tastiera e quelli che usano dispositivi switch restano esclusi
Focus trap nei modali: l'utente apre una finestra di dialogo e non può uscirne senza il mouse
Etichette dei form mancanti: lo screen reader non sa a cosa serva un campo di input
Video a riproduzione automatica senza pulsante di pausa: disorientante per chi soffre di disturbi vestibolari

La vittoria più rapida è aggiungere controlli automatici di accessibilità alla pipeline CI. Non intercetterà tutto, perché gli strumenti automatici trovano forse il 30-40% dei problemi, ma blocca le cose evidenti prima che arrivino in produzione.

// BEFORE: No accessibility testing at all
test('homepage loads', async ({ page }) => {
await page.goto('/');
await expect(page.locator('h1')).toBeVisible();
});
// AFTER: Accessibility violations fail the build
import AxeBuilder from '@axe-core/playwright';
test('homepage loads and is accessible', async ({ page }) => {
await page.goto('/');
await expect(page.locator('h1')).toBeVisible();
const a11yResults = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa'])
.analyze();
expect(a11yResults.violations).toEqual([]);
});

Cinque minuti di configurazione. Gira su ogni PR. Individua automaticamente testi alternativi mancanti, ruoli ARIA errati, contrasto insufficiente e decine di altri difetti. Non c'è scusa per non farlo.

Sovraccarico cognitivo: la pagina impostazioni infernale

La memoria di lavoro umana contiene circa quattro-sette elementi alla volta. Non è un consiglio, è un limite cognitivo rigido. Quando l'interfaccia riversa 200 opzioni su una sola pagina senza gerarchia, non state dando agli utenti il controllo. State dando loro una paralisi decisionale.

Una volta ho contato le impostazioni di uno strumento di project management che usavamo al lavoro. 347 opzioni. Una pagina. Nessuna ricerca. Nessun raggruppamento oltre a categorie vaghe come « Generali » e « Avanzate ». Metà del team non aveva mai cambiato un'impostazione, perché la pagina era così opprimente che la chiudevano subito.

La soluzione è la divulgazione progressiva. Mostrate le cinque impostazioni che le persone cambiano davvero. Mettete tutto il resto dietro sezioni espandibili chiaramente etichettate. Aggiungete una barra di ricerca. E per amor del cielo, fornite valori predefiniti sensati, così la maggior parte degli utenti non avrà mai bisogno della pagina impostazioni.

Se la vostra pagina impostazioni ha bisogno di una sua documentazione, il problema è la pagina impostazioni.

Il sovraccarico di notifiche insegna agli utenti a ignorare tutto

Quando ogni evento genera una notifica (un collega è entrato in un canale, qualcuno ha reagito con un'emoji, un deploy è terminato, un evento del calendario inizia tra 30 minuti), gli utenti imparano a ignorarle tutte. Avete trasformato il vostro sistema di notifiche in rumore bianco. L'unico avviso critico che conta davvero? Sepolto sotto 47 notifiche non lette.

La risposta sono impostazioni predefinite prudenti. I nuovi utenti dovrebbero ricevere solo notifiche critiche. Raggruppate le cose non urgenti in un riepilogo giornaliero. E sempre, sempre, permettete di silenziare o personalizzare direttamente dalla notifica stessa, non da una pagina preferenze nascosta a tre clic di distanza.

Un'interfaccia lenta è un'interfaccia rotta: le prestazioni come problema di UX

Un pulsante che impiega due secondi a rispondere non è lento. È rotto. Gli utenti non pensano « ah, il server sta elaborando la mia richiesta ». Pensano « il clic è stato registrato? » e cliccano di nuovo. Ora avete invii duplicati, stati confusi e un utente che non si fida della vostra app.

Oltre 100 ms sembra lento. Oltre un secondo spezza il filo del pensiero dell'utente. Eppure continuiamo a rilasciare bundle JavaScript da diversi megabyte, script di terze parti che bloccano il rendering e spostamenti di layout che fanno cliccare l'elemento sbagliato. La soluzione non è complicata: richiede solo di preoccuparsene.

// BEFORE: User clicks, waits 2 seconds, nothing happens
async function handleLike(postId: string) {
const result = await fetch(`/api/posts/${postId}/like`, {
method: 'POST',
});
if (result.ok) {
setLikeCount(prev => prev + 1); // UI updates after network round-trip
}
}
// AFTER: Optimistic update — UI responds instantly
function handleLike(postId: string) {
// Update UI immediately
setLikeCount(prev => prev + 1);
// Sync with server in background
startTransition(async () => {
const result = await fetch(`/api/posts/${postId}/like`, {
method: 'POST',
});
if (!result.ok) {
// Rollback only on failure
setLikeCount(prev => prev - 1);
toast.error('Something went wrong. Try again.');
}
});
}

Aggiornamenti ottimistici, skeleton screen al posto degli spinner, JavaScript non critico caricato in modo lazy e monitoraggio dei Core Web Vitals come metriche reali, non come ripensamenti. Non sono tecniche avanzate. Sono aspettative di base.

Anti-pattern UX mobile che non vogliono morire

Il mobile ha una sua categoria speciale di peccati UX, soprattutto perché gli sviluppatori continuano a testare su un iPhone nuovo di zecca e a considerare il lavoro finito.

Aree di tocco che richiedono una precisione chirurgica

Le linee guida di Apple prevedono un minimo di 44x44 pixel CSS per le aree di tocco. WCAG 2.2 è d'accordo. Eppure vedo ancora pulsanti di chiusura da 20 pixel nei modali, link minuscoli incastrati nei footer e pulsanti icona praticamente impossibili da colpire su un telefono. Per gli utenti con disabilità motorie è ancora peggio.

/* BEFORE: Tiny, frustrating touch targets */
.close-btn {
width: 20px;
height: 20px;
font-size: 12px;
}
.footer-links a {
padding: 2px 4px;
font-size: 11px;
}
/* AFTER: Actually tappable elements */
.close-btn {
min-width: 44px;
min-height: 44px;
display: flex;
align-items: center;
justify-content: center;
}
.footer-links a {
padding: 12px 8px;
font-size: 14px;
/* spacing between adjacent targets */
margin: 4px 0;
}

Interstitial a schermo intero che bloccano il contenuto

Toccate un risultato di ricerca. La pagina si carica. Prima che possiate leggere una sola parola, un modale a schermo intero chiede il vostro indirizzo email. Non avete ancora visto il contenuto. Perché dovreste iscrivervi?

Google penalizza gli interstitial invasivi nel ranking di ricerca dal 2017. Persistono perché qualcuno, da qualche parte, guarda una dashboard che mostra un tasso di acquisizione email del 2% e la considera una vittoria, ignorando il bounce rate del 40% che provoca. Usate banner inline o bottom sheet. Aspettate che l'utente abbia davvero interagito con il contenuto prima di chiedere qualsiasi cosa. Un lettore che ha finito tre articoli si iscriverà volentieri. Un lettore interrotto tre volte se ne andrà e non tornerà più.

Come costruire una cultura della qualità UX (non solo correggere bug singoli)

Correggere gli anti-pattern uno alla volta è necessario ma non sufficiente. Se il vostro processo continua a produrli, serve un processo migliore. Ecco cosa funziona davvero:

Aggiungete axe-core alla pipeline CI: controlli a11y automatici su ogni PR
Rendete la revisione UX parte della code review, non un processo separato solo per il design
Testate con 5 utenti reali prima di rilasciare funzionalità importanti: 5 utenti fanno emergere circa l'85% dei problemi di usabilità
Monitorate i tassi di completamento delle attività e di errore, non solo le visualizzazioni di pagina e il tempo sul sito
Usate un design system con componenti accessibili già pronti, così i singoli sviluppatori non risolvono da zero gli stessi problemi di interazione
Usate il vostro stesso prodotto senza sosta: quando lo sviluppatore che ha creato la pagina impostazioni la deve usare ogni giorno, viene sistemata in fretta

Il miglioramento UX più bello che abbia mai fatto è nato dal fatto che ho provato il nostro flusso di checkout sul telefono e ho scritto messaggi di sfogo al canale del prodotto alle 23.

Ogni anti-pattern di questo articolo ha una soluzione semplice. Nessuno richiede tecnologie all'avanguardia o riprogettazioni massicce. Richiedono di preoccuparsene. Iniziate oggi con una correzione. Fate un audit di accessibilità questa settimana. Testate con un utente reale questo mese. La buona UX non sta nei gesti eclatanti, sta nello scegliere costantemente il rispetto per gli utenti rispetto alle metriche a breve termine. La distanza tra il software che la gente tollera e quello che la gente ama è più piccola di quanto pensiate. Sono solo mille piccole decisioni, prese bene.