UX & UI Real World Vademecum
Parte III: Psicologia e Processo
Finora hai imparato come ragiona l'utente e come costruire mattoni visivi per guidarlo. Ora è il momento di mettere in pratica questa conoscenza nel mondo reale, dove le persone sbagliano di continuo. Il design qui si trasforma in indagine scientifica: estrarre veri problemi sul campo, mitigare i disastri in anticipo testando con utenti veri e colmare il distacco che c'è tra gli obiettivi dell'azienda e quelli della persona.
La Psicologia dell'Interazione
L'utente ha una parte logica e una psicologica, ma è la seconda a decidere. Progetta per quella.
24. Modelli Mentali (Il Termostato Bugiardo)
Un modello mentale è la rappresentazione che una persona si costruisce di come qualcosa funziona. Non è necessariamente corretta, ma è quella su cui basa le sue azioni.
Il Gap tra Modello e Realtà
Quando fa freddo, la maggior parte delle persone imposta il termostato a 30°C pensando che la casa si scalderà più velocemente. Non funziona così: la caldaia va sempre alla stessa velocità, cambia solo quando si ferma. Ma quel modello mentale ("più alto = più veloce") è talmente radicato che combatterlo è inutile.
Come designer hai due strade. La prima è educare: mostrare un feedback che dice "Tempo stimato per 20°C: 15 minuti", così l'utente capisce che mettere 30°C non serve a nulla. La seconda è adattarsi: fare in modo che il sistema funzioni comunque, anche se l'utente lo usa "male". La scelta tra le due dipende da quanto il modello sbagliato costa all'utente: nel caso del termostato gli costa soldi ed energia, quindi vale la pena educarlo. Se invece un utente preme "Salva" dieci volte sullo stesso documento pensando che così sia "più salvato", non ha senso correggerlo. Progetterai il sistema in modo tale che salvi una volta sola e ignori i click in più, qualora non ci siano nuove modifiche.
Il principio più generale è che un modello mentale non deve essere scientificamente corretto per funzionare. Deve solo permettere all'utente di usare bene il prodotto. Se l'utente pensa che i file "vivano" dentro le cartelle del suo computer, non ha importanza che tecnicamente siano solo puntatori a blocchi sparsi sul disco. Il suo modello è sbagliato a livello di implementazione ma perfetto per spostare, copiare e organizzare i file. Il compito del design non è insegnare come funzionano davvero le cose, è dare all'utente un modello che funzioni per i suoi scopi.
I Tre Elementi
Norman identifica tre elementi in ogni interazione. Il modello di progettazione è come il designer ha pensato che il prodotto funzionasse. Il modello dell'utente è come l'utente pensa che funzioni. L'immagine di sistema è il prodotto stesso: l'aspetto, il comportamento, le risposte, le istruzioni, tutto ciò che l'utente può vedere e toccare. Non è chiamata "modello" perché non vive nella testa di nessuno, è l'oggetto reale che fa da ponte tra i due modelli mentali. Il designer non parla mai direttamente con l'utente, gli parla attraverso l'immagine di sistema. Se questa comunica male il modello di progettazione, l'utente se ne costruirà uno sbagliato e userà il prodotto in modo scorretto.
Un esempio quotidiano di immagine di sistema fallita è l'icona "condividi" di iOS (il quadrato con la freccia che esce verso l'alto). Il designer sa che quel pulsante apre il menu di condivisione, ma l'icona non lo comunica a chi la vede per la prima volta: alcuni utenti la interpretano come "invia", altri come "esporta", altri ancora come "carica". L'immagine di sistema è ambigua, e ognuno si costruisce un modello diverso. Un altro caso è il menu a tre puntini (⋯) usato per le opzioni secondarie: l'utente vede tre puntini e non ha nessuna idea di cosa ci troverà dietro. Scopre il contenuto solo cliccando, e se quello che trova non gli serve, il click è stato uno spreco. Il design non ha il compito di avere un modello corretto, ha il compito di comunicarlo bene attraverso ogni dettaglio che l'utente vede e tocca.
La lezione pratica è questa: usa i tre puntini (o icone ambigue come "condividi") solo quando davvero nascondono un insieme eterogeneo di opzioni secondarie. Quando invece dietro c'è una funzione precisa e identificabile, l'icona corretta esiste quasi sempre e costa zero (un ingranaggio per "Impostazioni", una matita per "Modifica", un cestino per "Elimina"). Scegliere i tre puntini per comodità del designer significa scaricare sull'utente il lavoro di indovinare, e ogni click per "vedere cosa c'è dietro" è un'incertezza che si poteva evitare.
Il Modello di Implementazione vs il Modello Rappresentato
Questo concetto viene da Alan Cooper. Il modello di implementazione è come il sistema funziona davvero sotto il cofano, la struttura tecnica che lo sviluppatore ha costruito. Il modello rappresentato è ciò che l'utente vede e percepisce mentre usa il prodotto. L'errore classico è esporre il primo al posto del secondo: la logica del codice diventa la logica dell'interfaccia, e il risultato è un prodotto che ha senso per chi l'ha scritto ma è faticoso per chi lo usa.
L'esempio più tipico è un gestionale costruito attorno alla struttura del database. Supponiamo che il database abbia tre tabelle: Clienti, Prodotti, Ordini. Lo sviluppatore traduce letteralmente questa struttura in tre schermate separate: per creare un ordine l'utente deve prima entrare in "Clienti" e selezionare il cliente, poi uscire e andare in "Prodotti" per scegliere gli articoli, poi entrare in "Ordini" per collegare tutto e confermare. Tre schermate, tre cambi di contesto, tre occasioni per perdere il filo. Il modello di implementazione è stato esposto così com'è, e l'utente paga il prezzo della comodità dello sviluppatore.
Il modello rappresentato giusto potrebbe essere un flusso unico: "Nuovo ordine" apre una schermata dove scegli il cliente da un campo di ricerca, aggiungi i prodotti da una lista, vedi il totale aggiornarsi in tempo reale e confermi. Dietro le quinte il sistema continua a gestire tre tabelle separate, ma l'utente non lo sa e non deve saperlo. Questa è la regola operativa: il codice porta il peso della complessità perché l'utente non debba mai sentirlo. Se ti trovi a rispecchiare la struttura tecnica nell'UI, non stai progettando, bensì trascrivendo.
Regola: non combattere il modello mentale dell'utente, adattati o educalo gentilmente con il feedback. Non esporre mai il modello di implementazione. L'immagine di sistema deve comunicare il modello corretto.
25. Slips vs Mistakes (Lo Scivolone e l'Errore)
Don Norman distingue due tipi di errore fondamentalmente diversi, e la distinzione è importante perché le soluzioni sono diverse.
Slip (Lo Scivolone)
Volevi fare la cosa giusta ma l'esecuzione è fallita. Stavi mettendo lo zucchero nel caffè ma per distrazione hai preso il sale. Sapevi cosa fare, la mano ha sbagliato.
Negli ambienti digitali gli slip sono ovunque. Stavi per rispondere a un amico su WhatsApp ma hai toccato la chat sopra e hai mandato il messaggio alla persona sbagliata, perché sullo schermo piccolo del telefono la distanza tra una riga e l'altra è di pochi millimetri. Stavi scrivendo un'email e hai premuto "Invia" invece di "Allega" perché le due icone sono affiancate nella toolbar. Avevi venti tab aperti e hai chiuso quello del documento su cui lavoravi da un'ora, convinto che fosse una ricerca Google tra le tante.
La soluzione per gli slip non è educare l'utente ("stai più attento!"), è ridurre la probabilità che accadano. Tasti distanziati per azioni opposte, colori diversi per azioni costruttive e distruttive, undo sempre disponibile, conferma per le azioni davvero irreversibili. Il tuo software deve partire dal presupposto che l'utente lo userà mentre cammina, con un bambino in braccio, nella metro, con la mente su altro.
Ricorda sempre che lo slip non è un'eccezione, è la condizione normale d'uso.
Mistake (L'Errore Cognitivo)
Il piano stesso è sbagliato. Metti un maglione di lana in lavatrice a 90°C credendo che si pulirà meglio. Hai diviso correttamente i capi, dosato il giusto detersivo e avviato il programma. L'esecuzione è tecnicamente perfetta, ma il ragionamento di partenza è fuori strada e il maglione esce rovinato.
Nel digitale, il mistake è più insidioso dello slip perché manca il momento della consapevolezza. Con lo slip ti accorgi subito che il dito è scivolato sull'icona sbagliata. Con il mistake clicchi esattamente dove volevi, sicuro di essere nel giusto. L'utente disattiva le impostazioni di notifica pensando di zittire le email di offerte, ma in realtà sta spegnendo anche gli avvisi di sicurezza sul conto. Oppure genera un report scegliendo "ultimo mese" convinto di scaricare tutto marzo, mentre il sistema intende "gli ultimi 30 giorni da oggi" e gli restituisce dati sfalsati.
La soluzione per i mistake non si affida all'undo rapido o ai tasti lontani, ma sta tutta nell'informazione: devi mostrare all'utente le conseguenze reali prima della conferma. Un generico popup "Sei sicuro di voler procedere?" qui è inutile: l'utente cliccherà "Sì" senza esitare, perché è convinto che il suo piano funzioni. Fagli invece leggere il risultato finale: "Attenzione, stai per disattivare email promozionali, notifiche in-app e avvisi SMS di sicurezza. Procedo?". Oppure: "Verranno estratti i dati dal 13 marzo al 12 aprile. È questo il periodo che cercavi?". Mostrando la vera conseguenza fai crollare l'idea sbagliata dell'utente e blocchi il mistake sul nascere.
Errori di Modalità
Il classico errore di modalità lo commetti quando digiti la tua password senza sbagliare una singola lettera, ma il sistema te la respinge perché avevi il Caps Lock acceso. Oppure quando in uno strumento come Figma clicchi su un rettangolo convinto di spostarlo, ma inizi a scriverci dentro perché avevi lasciato attivo lo strumento di testo.
È un problema subdolo, dove lo stesso identico gesto (battere sui tasti o cliccare col mouse) produce conseguenze diametralmente opposte a causa di uno "stato" nascosto in cui sosta silenziosamente il software.
La via più logica è eliminare queste ambiguità alla radice: un bottone o un gesto fanno sempre un'unica operazione prevedibile. Qualora le modalità si rivelassero obbligatorie (nessun software complesso farà mai a meno di una toolbar), lo stato attivo deve dominare la visuale periferica in maniera decisa. Il cursore prende immediatamente la forma di un mirino o di una croce. Il campo della password ospita un avviso luminoso ben visibile. Il bottone in uso stacca nettamente dagli altri con marcature nette e fondi saturi. Se costringi l'utente a guardarsi intorno per chiedersi "In quale configurazione è rimasto il programma?", stai preparando il terreno a un errore assicurato.
Recovery: il Cestino Batte la Conferma
"Sei sicuro di voler eliminare?" è una domanda che dopo la centesima volta diventa un click automatico. L'utente non la legge più, clicca "Sì" per abitudine. La conferma non previene l'errore, lo ritarda di un click.
Una soluzione migliore è il cestino: l'elemento viene "eliminato" immediatamente (scompare dalla vista), ma resta recuperabile. L'utente ha una vera seconda possibilità, non un'illusione di protezione. Applica lo svuotamento automatico a 30 giorni per i dati di consumo transitori (foto dello smartphone, caselle email): l'esigenza qui è liberare i dischi, e il cestino fa solo da paracadute a breve termine. Per CRM, software gestionali o conti finanziari, l'auto-svuotamento rappresenta invece un enorme pericolo. Se un operatore cestina il recapito di un fornitore, l'azienda si accorgerà dello sbaglio magari sei mesi dopo durante un audit.
Il pattern ideale: l'azione avviene immediatamente, un toast appare con "Elemento eliminato" e un bottone "Annulla" per 5-10 secondi. Se l'utente non fa nulla, l'elemento va nel cestino. Se clicca "Annulla", torna tutto come prima. Così facendo ottieni zero attrito per le azioni intenzionali ma massima protezione per quelle accidentali.
Regola: gli slip si prevengono con distanziamento e undo. I mistake con feedback e vincoli. Il cestino batte la conferma. Riduci le modalità al minimo e rendile sempre visibili.
26. L'Errore è del Designer (Non dell'Utente)
Nel 1983, un aereo della Korean Air fu abbattuto perché i piloti avevano programmato male l'INS (il sistema di navigazione inerziale). Era successo tre volte quell'anno. La compagnia voleva punire i piloti. Norman dice: no. Se lo stesso errore si ripete con piloti diversi, il problema è dell'INS, non dei piloti.
L'Errore Utente Non Esiste
Scaricare la colpa sulla distrazione dell'utente è la via d'uscita più semplice. Se però lo stesso identico sbaglio viene replicato da persone senza legami tra loro, il problema smette di essere un caso isolato e diventa una questione di sistema.
Quando qualcuno commette un errore, di solito c'è una buona ragione. Le informazioni disponibili erano probabilmente incomplete o fuorvianti. La decisione era probabilmente sensata al momento con le informazioni a disposizione.
Il Paradosso dell'Estetica
La Federal Aviation Administration aveva bisogno di due nuovi uffici. L'architetto di Los Angeles progettò un edificio che vinse numerosi premi di design. L'architetto di Seattle non vinse nulla, ma parlò costantemente con i dipendenti durante la progettazione. Risultato: l'ufficio di Los Angeles non registrò alcun miglioramento delle performance lavorative. L'ufficio di Seattle migliorò la produttività del 7%.
Se il tuo design vince un premio di estetica ma l'utente si blocca disorientato chiedendosi "come si torna indietro?", hai appena costruito l'ufficio di Los Angeles. Evita l'inseguimento di un'eleganza estrema e pulita a scapito della chiarezza.
Il Designer Non è l'Utente
I designer diventano così esperti del prodotto che hanno progettato che non riescono a credere che qualcuno possa avere problemi. L'interazione con utenti reali deve avvenire dall'inizio del processo, non alla fine quando è troppo tardi per cambiamenti fondamentali.
Non fare il test con i colleghi sviluppatori. Fallo con le persone che useranno davvero il prodotto. Una versione brutta testata con utenti reali è infinitamente più utile di una versione perfetta mai testata.
Regola: se l'errore si ripete, il problema è il design. Il designer non è l'utente. Testa con utenti reali dall'inizio, non alla fine.
27. Le Posture del Software (Sovereign vs Transient)
Alan Cooper introduce un concetto che influenza ogni decisione di UI: la postura del software, determinata da quanto tempo l'utente ci passa dentro.
Software Sovrano
Il software sovrano è il banco da lavoro dell'artigiano. L'utente ci vive dentro per ore: Excel, VS Code, Figma, un gestionale di fabbrica, un sistema di ticketing.
Il design sovrano ha regole precise. I colori devono essere neutri e smorzati, perché dopo 8 ore di lavoro i colori accesi stancano gli occhi e distraggono. La densità di informazioni deve essere alta: l'operatore vuole vedere quanti più dati possibile senza dover scrollare, perché ogni scroll è tempo perso e contesto perso. Le scorciatoie da tastiera sono fondamentali e non opzionali: l'utente esperto che usa il software 40 ore a settimana deve poter fare tutto senza toccare il mouse. Lo spazio non deve essere sprecato: i margini ampi e gli spazi "decorativi" che funzionano su una landing page sono un disastro in un gestionale dove ogni pixel di schermo ha valore.
Pensa a come usi VS Code o Excel: toolbar compatta, molti pannelli, colori sobri, zero decorazione. Questo è un design sovrano fatto bene.
Software Transitorio
Il software transitorio è il cameriere che porta il caffè. Arriva, fa una cosa, sparisce. La calcolatrice, un popup di conferma, il widget meteo, il dialogo di salvataggio, la schermata di login.
Qui le regole si invertono. I pulsanti devono essere grandi perché l'utente non ha tempo di cercare. I colori possono essere più accesi perché devono catturare l'attenzione immediatamente. Le istruzioni devono essere chiare al primo sguardo, perché l'utente non "impara" un'app transitoria, la usa e se ne va. La densità è bassa: poche opzioni, poche informazioni, una sola azione chiara.
Pensa alla calcolatrice del telefono: bottoni enormi, nessuna toolbar, zero complessità. Apri, calcoli e chiudi.
L'Errore di Scambio
Se progetti un gestionale di fabbrica (sovrano) con lo stile di una landing page di marketing (grandi spazi, pochi dati, immagini decorative), l'operatore impazzirà per lo scroll continuo e la sensazione di "non vedere abbastanza". Se deve controllare 20 macchine, non puoi mostrargliene 3 alla volta con 48px di margine tra ogni card. L'operatore non è impressionato dal tuo spazio bianco, è frustrato dalla mancanza di informazioni.
Se progetti un popup di conferma (transitorio) come se fosse un gestionale (testo piccolo, molte opzioni, terminologia tecnica), l'utente andrà nel panico. "Vuoi salvare le modifiche al buffer non persistente dell'istanza corrente?" Non è il momento di essere precisi, è il momento di essere chiari: "Salvare le modifiche?".
Regola: software sovrano = neutro, denso, con scorciatoie. Software transitorio = grande, chiaro, immediato. Adatta la densità alla durata dell'uso.
28. Gamification e Retention
Gamification non significa "mettere badge e punti a caso", bensì applicare alcuni meccanismi psicologici del gioco per trasformare un compito in un'abitudine.
Loss Aversion (La Paura di Perdere)
Duolingo non ti fa studiare spagnolo perché ti piace la grammatica. Ti fa studiare perché hai una streak di 50 giorni e hai il terrore di vederla tornare a zero. La loss aversion (avversione alla perdita) è un principio psicologico per cui perdere qualcosa che hai già fa più male che guadagnare qualcosa di nuovo. Duolingo lo sfrutta con le streak. LinkedIn lo sfrutta con il "Profilo completato al 90%". L'utente farà di tutto per non perdere quella percentuale.
Goal Gradient Effect
La produttività aumenta quando ci si avvicina al traguardo. Duolingo mostra un percorso che sembra un cammino, focalizzato solo sui prossimi step vicini a quello completato. Non ti fa vedere la totalità delle lezioni, perché sapere di essere al 10% del percorso sarebbe demoralizzante. Mostra solo il prossimo obiettivo raggiungibile.
Netflix e la Personalizzazione
Netflix non ti mostra la stessa home page del tuo vicino. Ti dice "Visto che ti è piaciuto Breaking Bad, ecco Narcos". Ti fa sentire ascoltato e capito. La personalizzazione non è solo un algoritmo, è un messaggio: "ti conosciamo, sappiamo cosa ti piace".
Feedback Positivo (La Dopamina)
Quando l'utente finisce un task noioso, premialo. Un'animazione soddisfacente (magari con un check verde gigante, un suono piacevole) crea un piccolo rilascio di dopamina che il cervello associa al tuo prodotto.
La progress bar sfrutta l'effetto Zeigarnik: il cervello odia le cose incomplete. Il "Profilo completato al 90%", crea un'urgenza psicologica di chiudere il cerchio.
Regola: la gamification è dare un senso di progresso visibile. Loss aversion per le streak. Goal gradient per i traguardi vicini. Feedback positivo per il completamento.
29. Accessibilità (Progettare per Tutti)
L'accessibilità non è un favore che fai a "qualcun altro". È un principio di design che migliora l'esperienza per tutti.
Il Curb Cut Effect (l'Effetto Rampa)
Le rampe per le sedie a rotelle sui marciapiedi sono state progettate per le persone con disabilità motoria. Ma le usano tutti: genitori con il passeggino, corrieri con il carrello, viaggiatori con la valigia, ciclisti. Lo stesso vale per l'accessibilità digitale: i sottotitoli nei video aiutano chi è sordo, ma anche chi è in un ambiente rumoroso. Il testo alternativo sulle immagini aiuta chi usa gli screen reader, ma anche chi ha una connessione lenta. Le etichette chiare nei form aiutano tutti.
Tre Tipi di Difficoltà
Le difficoltà non sono unicamente permanenti, ma si presentano anche in forma temporanea e situazionale. Pensa a chi ha un solo braccio (permanente), a chi si è slogato un polso (temporaneo) o a chi deve tenere in braccio un neonato che piange (situazionale). Pur vivendo condizioni totalmente opposte, davanti a uno schermo condividono lo stessissimo bisogno: usare l'interfaccia con una mano sola. L'accessibilità nel design mira a coprire tutte queste tre casistiche contemporaneamente, in un colpo solo.
Le Regole Pratiche
Il touch target (l'area cliccabile) deve essere almeno 7mm, idealmente 10mm. Un testo leggibile ma troppo piccolo per essere toccato è un problema di accessibilità.
Il contrasto deve rispettare le linee guida WCAG AA. Testo piccolo richiede un contrasto minimo di 4.5:1 con lo sfondo. Testo grande (18px+ o 14px+ bold) richiede 3:1.
Non affidarti al solo colore per comunicare informazioni (lo abbiamo approfondito nella sezione 12). Aggiungi sempre un secondo canale: icone, testo, pattern.
Testa l'interfaccia solo con la tastiera: se riesci a navigare tutto con Tab e Invio, l'accessibilità da tastiera è coperta. Se un elemento è interattivo ma non raggiungibile con Tab non va bene.
Testa l'interfaccia in scala di grigi: se capisci ancora tutto, il tuo design non dipende dal colore.
Per un approfondimento tecnico sull'implementazione dell'accessibilità in HTML, la sezione 13 dell'HTML Real World Vademecum copre ARIA, lang, skip link e focus management.
Regola: l'accessibilità non è un optional. Touch target minimo 7mm. Contrasto WCAG AA. Non affidarti al solo colore. Testa con tastiera e in scala di grigi.
Riepilogo (Psicologia in Sintesi)
| Concetto | Regola chiave | Trappola comune |
|---|---|---|
| Modelli mentali | Adattati al modello dell'utente, non combatterlo | Esporre il modello di implementazione (le tabelle del database diventano schermate) |
| Slips | Previeni con distanziamento e undo | Bottoni "Salva" e "Elimina" adiacenti |
| Mistakes | Previeni con feedback e vincoli | Azioni irreversibili senza spiegazione delle conseguenze |
| Recovery | Il cestino batte la conferma. Toast con "Annulla" per 5-10 secondi | "Sei sicuro?" come unica protezione |
| L'errore è del designer | Se si ripete, il problema è il design | Dare la colpa all'utente "che non legge" |
| Posture del software | Sovrano = denso e neutro. Transitorio = grande e chiaro | Gestionale con lo stile di una landing page |
| Gamification | Progresso visibile, loss aversion, goal gradient | Badge e punti senza una logica |
| Accessibilità | Touch target 7mm+, contrasto WCAG, non solo colore | "Lo aggiungiamo dopo, se c'è tempo" |
| Effetto rampa | L'accessibilità migliora l'esperienza per tutti | Pensare che sia "per le persone con disabilità" |
Il Processo UX
A un occhio inesperto il design può sembrare un mestiere artistico, quando in realtà è saldamente ancorato al problem solving. Quindi, non aspettare l'ispirazione: usa un metodo per estrarre la soluzione direttamente dai dati.
30. Empatia come Ricerca (Non come Gentilezza)
L'empatia nel design UX non è "essere gentili con gli utenti". È raccogliere dati qualitativi grezzi per capire il vero problema da risolvere. In fabbrica, se un macchinario si rompe, non inizi a svitare bulloni a caso. Prima chiedi all'operatore: "Cosa stavi facendo? Che rumore ha fatto? Quando succede?". Devi prima diagnosticare il guasto.
Il Bias dell'Ingegnere
Chi viene dal mondo tecnico tende a saltare direttamente alla soluzione: "Serve un database!", "Mettiamo un filtro!", "Aggiungiamo una funzione!". L'empatia ti costringe a rimanere nel problema. Forse non serve un database. Forse serve un tasto più grosso perché gli operai usano i guanti. L'unica persona che lo sa è chi usa il prodotto ogni giorno.
Ricerca Primaria vs Secondaria
La ricerca primaria è raccolta diretta dagli utenti: interviste, osservazione, sondaggi. Ti dà insight specifici e contestualizzati per il tuo progetto. La ricerca secondaria si basa su informazioni esistenti: report di settore, studi accademici, analisi di mercato. Ti dà contesto generale. La ricerca secondaria ti spiega le regole teoriche di un mercato, la primaria ti fa toccare con mano la realtà quotidiana di chi userà il tuo prodotto.
Empathy Mapping
L'empathy map è uno strumento che sintetizza le osservazioni dalla ricerca in quattro quadranti: Says (citazioni testuali, le parole esatte dell'utente), Thinks (cosa pensa, inferenze dai segnali non verbali), Does (le azioni concrete che compie), Feels (i sentimenti espressi o percepiti).
L'empathy map individuale si concentra su un singolo utente. L'empathy map aggregate sintetizza pattern da multiple interviste, eliminando le peculiarità individuali per far emergere i bisogni comuni. Se hai intervistato 10 utenti, l'aggregate ti mostra cosa hanno in comune.
Regola: l'empatia è ricerca, non gentilezza. Resta nel problema prima di saltare alla soluzione. Empathy map per sintetizzare le osservazioni.
31. Indagine Contestuale (L'Apprendista e il Maestro)
Questo concetto che viene da Alan Cooper in About Face è il più potente (a mio avviso) nella ricerca UX: osservare l'utente nel suo contesto reale, non in una sala riunioni.
Il Metodo dell'Apprendista
Non fare l'esperto. Fai l'Apprendista. Tratta l'utente come il Maestro nel suo contesto reale. Non portarlo in una sala bianca con telecamere e questionari. Vai dove lavora, guarda cosa fa, chiedi di mostrarti come svolge le sue attività quotidiane.
Il relazionarsi come apprendista cambia completamente la dinamica. Se entri come l'esperto che viene a "valutare" il processo, l'utente si mette sulla difensiva, razionalizza, mostra la versione "da manuale" del suo lavoro. Se entri come l'apprendista che vuole imparare, l'utente si rilassa e ti mostra come fa davvero le cose, così facendo i problemi emergono naturalmente.
Cosa Dicono vs Cosa Fanno
Se chiedi a una persona "Come usi questo software?", ti darà la versione da manuale. Se la osservi mentre lavora, vedrai il post-it sullo schermo con la password perché se la dimentica ogni lunedì, il doppio click sulla scrivania del desktop perché non sa che basta uno, il workaround improvvisato con un foglio Excel perché una funzione del gestionale non fa quello che dovrebbe.
Nessuna di queste informazioni emerge da un questionario e, cosa più importante, l'utente non le considera "problemi", le considera "procedure". Per lui, il post-it con la password è una soluzione pratica. Per te, è un segnale che il sistema di autenticazione è troppo complesso.
La differenza tra "cosa dicono di fare" e "cosa fanno davvero" è il cuore dell'indagine contestuale. Le persone non mentono deliberatamente, ma il loro racconto è sempre una versione semplificata e razionalizzata della realtà.
Il Metodo Colombo
Fai domande "ingenue" come il Tenente Colombo: "Mi scusi, un'ultima cosa... perché ha scritto quel numero sulla mano?". "Ah, interessante... perché ha aperto anche Excel se il gestionale ha quella funzione?". "Scusi la domanda stupida, ma perché ha cliccato due volte lì?". Mostrarti spaesato disarmerà l'interlocutore: abbassando le difese l'utente non si sentirà sotto esame e inizierà a portarti in dono un tesoro di piccoli escamotage quotidiani che teneva nascosto.
Un caso concreto: osservando operai in un magazzino, un designer notò che usavano guanti spessi che rendevano impossibile premere i piccoli bottoni del tablet di gestione. Nessun operaio aveva mai segnalato il problema perché "ci si abitua", ma quando il designer ridisegnò i bottoni il doppio della dimensione originale, la velocità di completamento dei task aumentò (ovviamente) drasticamente.
Regola: osserva l'utente nel suo contesto reale. Fai l'apprendista, non l'esperto. La differenza tra ciò che dicono e ciò che fanno è dove trovi i veri problemi.
32. Personas e User Journey
Personas (L'Archetipo dell'Utente)
Una persona è un archetipo utente basato su dati reali, non su supposizioni. Ha un nome, caratteristiche, obiettivi, frustrazioni e una frase che cattura la sua essenza.
Perché servono: senza una persona definita, il team usa l'utente elastico. Quando conviene, l'utente è "esperto" (quindi niente istruzioni). Quando conviene, è "stupido" (quindi togliamo funzionalità). La persona elimina questa ambiguità: Mario l'operatore ha alta manualità, bassa alfabetizzazione informatica, va di fretta e odia leggere testi lunghi.
Le personas umanizzano i numeri. "Il 45% degli operai sbaglia l'inserimento dei dati a sistema" è una noiosa statistica. Ad esempio, completando l'osservazione nel magazzino dell'aneddoto precedente si scopre che "Mario, svelto di mano ma sempre impaziente, lavora con guanti protettivi spessi che rendono lentissimo compilare i form". Il team progetterà l'interfaccia ricordandosi dei guanti ingombranti di Mario, non ricorderà certo del 45%.
L'anti-persona è altrettanto utile: definisci per chi non stai progettando (il criminale informatico, l'utente che vuole abusare del sistema) per creare vincoli di sicurezza senza rovinare l'esperienza di Mario.
User Journey Map
La user journey non inizia quando l'utente apre l'app. Include il prima (la frustrazione che lo porta a cercare una soluzione), il durante (l'interazione con il prodotto) e il dopo (il sollievo, la soddisfazione, o la frustrazione residua).
Spesso i problemi di UX non sono nel software ma nel contesto. L'app richiede internet, ma in magazzino non c'è campo. L'app chiede di scannerizzare un codice, ma l'operaio ha le mani sporche. La user journey ti mostra questi "buchi di trama".
La user story traduce il bisogno della persona in un requisito: "Come [tipo di utente], voglio [azione] così da [beneficio]". "Come operaio con i guanti, voglio scannerizzare il codice senza togliere i guanti, così da non rallentare il lavoro".
Non progettare solo per l'happy path (il percorso ideale dove tutto va bene). Progetta anche per gli edge case: cosa succede se il codice non si scannerizza? Se la connessione cade? Se l'utente chiude l'app per sbaglio?
Regola: le personas eliminano l'utente elastico. La user journey include prima, durante e dopo. Progetta per gli edge case, non solo per l'happy path.
33. Le 10 Euristiche di Nielsen (La Checklist del Pilota)
Prima di decollare, il pilota scorre una checklist: flap ok, carburante ok, strumenti ok. Le euristiche di Nielsen sono la tua checklist pre-lancio. Non servono a creare il design, servono a verificare che non abbia buchi.
1. Visibilità dello stato del sistema. L'utente deve sempre sapere cosa sta succedendo. Se premi il pulsante dell'ascensore e il pulsante non si illumina, lo premi altre 10 volte con rabbia crescente. Lo stesso vale nel digitale: spinner, barre di progresso, skeleton screen, breadcrumb. Se l'utente si chiede "si è bloccato?", hai violato la prima euristica.
2. Corrispondenza tra sistema e mondo reale. Parla la lingua dell'utente, non quella del database. Non "Errore di scrittura su /dev/null", ma "Il cestino è pieno". Non "Query timeout", ma "Il server sta impiegando troppo tempo a rispondere, riprova tra qualche secondo". Usa icone e termini che l'utente incontra nella vita reale: cartelle, scrivania, carrello, cestino.
3. Controllo e libertà dell'utente. L'utente clicca per sbaglio. Sempre. Dagli una via d'uscita, come il maniglione antipanico delle uscite di emergenza: non importa come sei entrato, devi poter uscire subito. I tasti "Annulla" e undo sono sacri. Non intrappolare mai l'utente in una modale senza una X per chiudere o in un flusso senza un "torna indietro".
4. Consistenza e standard. Se il rosso significa "stop" in tutta l'interfaccia, non usarlo per "vai" in una sola schermata. Se il bottone primario è in basso a destra nelle prime 10 schermate, non metterlo in alto a sinistra nell'undicesima. L'inconsistenza crea domande ("perché è cambiato?", "dove è finito?") che erodono la fiducia.
5. Prevenzione dell'errore. La presa USB-C non può essere inserita al contrario. Questo è il livello a cui devi aspirare. Nella UI usa un calendario invece di un campo testo per le date. Disabilita "Invia" se il form è incompleto. Mostra solo le opzioni valide in un menu. Il miglior messaggio di errore è quello che non hai mai dovuto mostrare.
6. Riconoscimento anziché ricordo. Un esame a crocette (riconoscimento) è più facile di un esame a risposta aperta (ricordo). La "RAM umana" tiene circa 5 elementi non correlati. Mostra la cronologia recente invece di far ridigitare la ricerca. Mostra le voci di menu visibilmente, non nasconderle dietro comandi da ricordare. Se l'utente deve ricordare qualcosa dalla schermata precedente per usare quella attuale, stai sovraccaricando la sua memoria.
7. Flessibilità ed efficienza d'uso. La città ha le strade normali per i turisti, ma i tassisti conoscono le scorciatoie. Accogli i novizi con percorsi chiari, ma offri agli esperti scorciatoie da tastiera (Ctrl+C, Ctrl+V, Ctrl+Z), personalizzazione della dashboard e macro per azioni ripetitive. Le scorciatoie non devono essere visibili per default, ma devono comunque poter essere scoperte.
8. Design estetico e minimalista. Ogni informazione in più nell'interfaccia compete con quelle rilevanti e ne riduce la visibilità. Il rapporto segnale/rumore: se urli 10 cose insieme, nessuno ne capisce una. Togli tutto ciò che non serve all'obiettivo corrente dell'utente. Non è solo "fare spazio bianco", è togliere contenuto superfluo.
9. Aiutare a riconoscere e recuperare dagli errori. Un medico che ti referta "sospetta piressia idiopatica" ti spaventa senza dirti nulla. Un medico che dice "Hai la febbre (il problema), prendi questo (la soluzione)" è utile. I messaggi di errore devono essere in linguaggio umano, indicare con precisione il problema e suggerire come risolverlo. "La connessione è caduta" (cosa è successo) + "Riprova tra qualche secondo" (come risolvere). Mai "Unknown Error" e codici criptici.
10. Aiuto e documentazione. Un buon software dovrebbe usarsi senza istruzioni, lasciando alla documentazione il solo compito di scialuppa di salvataggio: speri di non usarla mai, ma se la nave affonda deve essere lì e pronta. Usa FAQ contestuali (non una pagina di FAQ generica, ma l'aiuto messo direttamente nella schermata dove si trova l'utente), una search bar nell'help center e guide brevi focalizzate su un compito ("Come fare X"). Non esagerare con la lunghezza, deve risolvere il problema nel modo più veloce e semplice possibile.
Regola: scorri questa lista prima di ogni rilascio. Se violi un'euristica, devi avere un motivo molto forte per farlo.
34. Obiettivi vs Compiti (Il Viaggiatore del 1850)
Questo concetto viene da Alan Cooper e cambia il modo in cui pensi al design.
La Distinzione
Nel 1850, l'obiettivo di un colono era "arrivare in California sano e salvo". I suoi compiti erano: riparare la ruota del carro, caricare il fucile, accendere il fuoco. Oggi, un uomo d'affari ha lo stesso obiettivo. I suoi compiti sono completamente diversi: chiamare Uber, passare il metal detector, allacciare la cintura.
L'obiettivo non è cambiato dopo 2 secoli. I compiti sono irriconoscibili.
Se ti concentri sui compiti, progetterai un fucile più leggero per il colono. Se ti concentri sugli obiettivi, inventerai l'aereo. La domanda non è "come rendiamo questo compito più efficiente?" ma "perché l'utente sta facendo questo compito? Qual è il suo vero obiettivo?".
Non Digitalizzare la Burocrazia
L'errore classico: prendere una scheda cartacea d'inventario e trasformarla in un PDF editabile sul tablet. Hai "digitalizzato", ma non hai migliorato nulla: l'operatore deve comunque digitare decine di codici alfanumerici a schermo. La domanda giusta è: "Perché stiamo compilando questa scheda?". Se l'obiettivo reale è riordinare i pezzi esauriti, non costringere l'utente a trascriverne il nome o il lotto. Sfrutta il tablet per fargli scannerizzare il codice a barre sullo scaffale vuoto e lascia che il software compili l'ordine in autonomia. La tecnologia non deve limitarsi a trasferire la burocrazia dalla carta ai pixel, deve disintegrare o automatizzare il compito intermedio per farti arrivare dritto all'obiettivo.
Magic Thinking
Nel design industriale questa pratica prende il nome di Blue Sky research: il team rimuove artificialmente il tetto dei vincoli tecnici per poter sognare il prodotto ideale. Cooper porta questo esercizio nel software: immaginare l'interazione ideale calpestando i limiti della tecnologia attuale. Mario entra in fabbrica, il tablet intuisce già che turno è e gli mostra solo ed esclusivamente le macchine che userà. Disegna l'esperienza magica come requisito base.
Per darti un esempio concreto, Spotify ha fatto esattamente questo. Tutti erano abituati a scaricare MP3. Spotify ha detto: "E se al click la musica partisse subito?". Sembrava impossibile. Hanno lavorato duramente sul buffering per rendere reale quella magia.
Regola: concentrati sugli obiettivi, non sui compiti. Non digitalizzare la burocrazia, eliminala. Immagina l'interazione ideale, poi lavora a ritroso per costruirla.
35. Prototipazione e Testing
Prototipazione (Misura Due Volte, Taglia Una Volta)
Costruire un muro di mattoni e poi scoprire che va spostato di 10 centimetri è un incubo costoso. Spostare una riga su un disegno tecnico è gratis. Lo stesso vale nel software: risolvere un problema di design quando sei ancora nella fase di prototipazione costa una frazione di ciò che costa dopo lo sviluppo. Cancellare un rettangolo su Figma richiede un secondo. Rifattorizzare un componente React richiede minuti.
Il wireframe a bassa fedeltà (rettangoli grigi, testo segnaposto) serve per testare la logica del flusso. "Il percorso ha senso? L'utente capisce dove andare? Manca un passaggio?" Se il flusso funziona con i rettangoli grigi, funzionerà nel codice. Se non funziona con i rettangoli grigi, non funzionerà nemmeno con i colori e le animazioni.
L'approccio alternativo, quando il cliente non è un colosso e non hai mesi di burocrazia, è saltare il wireframe a bassa fedeltà e andare direttamente all'alta fedeltà. Il vantaggio è che il cliente vede subito qualcosa di concreto e realistico. Esiste anche una variante intermedia: la UI in scala di grigi; utile quando vuoi testare la gerarchia visiva senza che il colore distragga. Ma se hai già una palette e un design system definiti, aggiungere il colore costa poco: ha più senso andare direttamente alla versione completa.
C'è una grande differenza tra un bug e un errore di design in produzione. Un bug si corregge con una patch: l'utente non sa nemmeno che esistesse. Un flusso sbagliato lascia invece una traccia: l'utente lo ha già interiorizzato, e porta con sé la frustrazione di aspettative che non si sono realizzate. Correggerlo non basta, perché devi anche convincerlo a reimparare.
Usability Testing
Jakob Nielsen ha dimostrato che 5 utenti trovano circa l'85% dei problemi di usabilità. Non servono centinaia di tester. Servono 5 persone che rappresentano il tuo utente reale e che usano davvero il prodotto cercando di completare task concreti.
I test moderati danno profondità perché sei presente: puoi fare domande, approfondire un'esitazione, cogliere una reazione che un questionario non cattura mai. La domanda "perché hai esitato lì?" apre motivazioni che i dati quantitativi non raggiungono. I test non moderati, dove l'utente procede da solo e la sessione viene registrata, danno invece scala: puoi testare con 20 utenti in parallelo e raccogliere pattern difficili da ignorare. Conviene sempre combinare i due approcci.
I KPI da misurare durante i test: il tempo per completare un task, il tasso di errore (quante volte l'utente sbaglia strada), il tasso di abbandono (quanti rinunciano a metà percorso), il tasso di conversione (quanti arrivano al traguardo).
Prioritizzare i Risultati
Dopo il test devi stilare una lista di problemi. Non tutti hanno la stessa urgenza. La prioritizzazione segue tre livelli:
P0 sono i problemi critici che impediscono al prodotto di funzionare. L'utente non riesce a completare il task principale. Esempio: Il pulsante "Avanti" nel flusso di onboarding non è riconoscibile come azione principale: tutti gli utenti testati si sono fermati lì senza sapere come proseguire. Risolvi questi prima di tutto.
P1 sono i problemi significativi che peggiorano l'esperienza ma non la bloccano. L'utente riesce a completare il task ma con fatica o frustrazione. Esempio: Gli utenti trovano il pulsante di ricerca dopo 10 secondi in media. Risolvi dopo i P0.
P2 sono i miglioramenti che ha senso fare dopo aver risolto tutto il resto. Esempio: l'utente preferirebbe che i filtri fossero in un ordine diverso. Importante ma non urgente.
Il processo è ciclico: test → analisi e prioritizzazione → fix dei P0 → ritest per verificare che le modifiche funzionino e non abbiano creato nuovi problemi → fix dei P1 → ritest → fix dei P2 → ritest. Ogni ciclo migliora il prodotto in modo misurabile.
Competitive Audit
Analizzare i competitor serve per imparare, non per copiare. Ti deve interessare capire cosa fanno bene, dove sbagliano, e soprattutto cosa il mercato non sta ancora offrendo. Analizza 5-10 competitor: un mix di diretti, stesso prodotto e stesso pubblico, e indiretti, stesso pubblico ma prodotto diverso. I secondi sono spesso più illuminanti dei primi.
Il competitive audit è un punto di partenza, non una destinazione. Ti dice "questo è lo status quo". Sei poi tu a decidere dove andare.
Regola: prototipa prima di sviluppare. 5 utenti trovano l'85% dei problemi. Prioritizza P0 → P1 → P2. Il competitive audit informa, non detta.
Riepilogo (Processo UX in Sintesi)
| Concetto | Regola chiave | Trappola comune |
|---|---|---|
| Empatia | Ricerca, non gentilezza. Resta nel problema | Saltare alla soluzione senza capire il problema |
| Indagine contestuale | Osserva nel contesto reale, fai l'apprendista | Intervistare in sala riunioni e prendere per buone le risposte |
| Personas | Basate su dati, eliminano l'utente elastico | Inventare personas senza ricerca |
| User journey | Include prima, durante e dopo. Progetta per gli edge case | Progettare solo per l'happy path |
| Euristiche | Checklist pre-lancio, non strumento creativo | Ignorarle e scoprire i problemi dopo il rilascio |
| Obiettivi vs compiti | Concentrati sul perché, non sul come | Digitalizzare la burocrazia invece di eliminarla |
| Prototipazione | Risolvere quando costa poco, non quando costa tanto | Sviluppare senza prototipare |
| Testing | 5 utenti, 85% dei problemi. P0 → P1 → P2 | Testare alla fine invece che dall'inizio |
| Competitive audit | Punto di partenza, non destinazione | Copiare i competitor invece di imparare da loro |