Passa al contenuto principale

UX & UI Real World Vademecum

Parte III: Il Processo Scientifico

Il design non è arte, è problem solving. Non aspettiamo l'ispirazione divina, usiamo un metodo scientifico per estrarre la soluzione dai dati.

Ricerca e Empatia​

13. Empatia come Data Mining​

Non è solo "Essere Gentili"

Cosa fa: Raccoglie dati qualitativi grezzi per capire il vero problema da risolvere.

L'Analogia: 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?". Questa è la fase di Empatia. Non stai cercando di farti piacere l'operatore, stai cercando di diagnosticare il guasto.

Il Bias dell'Ingegnere: Noi tendiamo a voler subito la soluzione ("Ah, serve un database!"). L'empatia ti costringe a rimanere nel problema ("Aspetta, forse non serve un database, serve solo che il tasto sia più grosso perché usano i guanti").

14. Indagine Contestuale (Sherlock Holmes in Fabbrica)​

L'Intervista in Sala Bianca è una Bugia

Cosa fa: Raccoglie la verità osservando l'utente nel suo habitat naturale, non quello che l'utente dice di fare.

L'Analogia: Se chiedi a una persona "Come usi questo macchinario?", ti darà la versione da manuale. Se la osservi mentre lavora, vedrai che ha attaccato un post-it sullo schermo con la password perché se la dimentica, e che prende a calci la macchina per farla partire.

Il Metodo Colombo: Non fare l'esperto. Fai l'Apprendista. Fatti insegnare il lavoro dall'utente (il Maestro). E fai domande "ingenue" come il Tenente Colombo: "Mi scusi, un'ultima cosa... perché ha scritto quel numero sulla mano?". Lì scoprirai i veri problemi di design che nessun questionario ti rivelerà mai.

Modellazione dell'Utente​

15. Personas: Il Bisturi​

La Scheda del Personaggio RPG

Cosa fa: Crea un archetipo utente basato sui dati per evitare di progettare per se stessi (o per nessuno).

L'Analogia: Il coltellino svizzero fa tutto (forbici, coltello, cavatappi), ma lo fa male. Un bisturi fa una cosa sola, ma la fa perfettamente. Una Persona è il tuo bersaglio.

  • Nome: Mario l'Operatore.
  • Skill: Alta manualità, bassa alfabetizzazione informatica.
  • Debolezza: Va di fretta, odia leggere testi lunghi.

L'Utente Elastico: Senza una Persona definita, il team di sviluppo userà l'utente elastico. Quando fa comodo, l'utente è "esperto" (quindi niente istruzioni). Quando fa comodo, è "stupido" (quindi togliamo funzionalità).
L'Anti-Persona: Definisci anche per chi non stai progettando (es. il criminale informatico o il burlone). Ti serve per creare vincoli di sicurezza senza rovinare l'esperienza di Mario.

16. User Journey Map​

La Sceneggiatura del Film

Cosa fa: Mappa l'intera esperienza, non solo i click sullo schermo, per trovare i punti di dolore esterni.

L'Analogia: Google Maps ti mostra la strada, ma non ti dice se piove, se c'è traffico o se sarai stressato perché sei in ritardo. La User Journey è il racconto emotivo del viaggio.

Oltre lo Schermo: La Journey non inizia quando l'utente apre l'app.

  • Prima: L'utente è frustrato perché ha perso un documento cartaceo.
  • Durante: Apre la tua app per risolvere il problema.
  • Dopo: Si sente sollevato o ancora più arrabbiato? Spesso i problemi di UX non sono nel software, ma nel contesto (es. l'app richiede internet, ma in magazzino non c'è campo). Solo la User Journey ti mostra questi "buchi di trama".

Validazione e Controllo Qualità​

17. Le 10 Euristiche di Nielsen​

La Checklist del Pilota

Cosa fa: È una lista di controllo universale per trovare buchi nell'usabilità.

L'Analogia: Prima di decollare, il pilota non va a "sensazione". Ha una checklist: "Flap? Ok. Carburante? Ok.". Le euristiche sono la tua checklist pre-volo. Non servono a creare, servono a non schiantarsi. Scorri questa lista prima di ogni rilascio.

  1. Visibilità dello Stato del Sistema
  • Il principio: Il sistema non deve mai tenerti all'oscuro.
  • L'Analogia: Se premi l'ascensore e il bottone non si illumina, lo premi altre 10 volte con rabbia.
  • Pratica: Spinner, barre di progresso, breadcrumbs. Se l'utente chiede "Si è bloccato?", hai fallito.
  1. Corrispondenza tra Sistema e Mondo Reale
  • Il principio: Parla la lingua dell'utente, non quella del database.
  • L'Analogia: Non dire "Errore di scrittura su /dev/null", dì "Il cestino è pieno".
  • Pratica: Usa icone e termini familiari (Cartelle, Scrivania, Carrello) invece di termini tecnici (Directory, Root, Query).
  1. Controllo e Libertà dell'Utente
  • Il principio: L'utente clicca per sbaglio. Dagli una via d'uscita.
  • L'Analogia: L'Uscita di Emergenza con il maniglione antipanico. Non importa come sei entrato, devi poter uscire subito.
  • Pratica: Il tasto "Annulla" (Undo) è sacro. Non intrappolare mai l'utente in un modale senza una "X" per chiudere.
  1. Consistenza e Standard
  • Il principio: Non essere creativo sulle convenzioni.
  • L'Analogia: Immagina un'auto dove il freno è a destra e l'acceleratore a sinistra. Caos.
  • Pratica: Se il rosso significa "Stop" ovunque, non usarlo per "Vai". Segui la Legge di Jakob: l'utente si aspetta che il tuo sito funzioni come tutti gli altri.
  1. Prevenzione dell'Errore
  • Il principio: Un buon design impedisce il problema alla radice.
  • L'Analogia: La presa USB-C (o la spina elettrica polarizzata). Non puoi inserirla al contrario.
  • Pratica: Invece di dare errore "Formato data errato", usa un calendario che permette di cliccare solo date valide. Disabilita il bottone "Invia" se il form è vuoto.
  1. Riconoscimento anziché Ricordo
  • Il principio: Minimizza il carico cognitivo. La RAM umana è limitata.
  • L'Analogia: Un esame a crocette (Riconoscimento) è più facile di un esame a risposta aperta (Ricordo).
  • Pratica: Mostra la cronologia recente invece di far ridigitare la ricerca. Mostra le voci di menu visibili, non nasconderle dietro comandi da terminale.
  1. Flessibilità ed Efficienza d'Uso
  • Il principio: Accogli i novizi, ma velocizza gli esperti.
  • L'Analogia: La città ha le strade normali per i turisti, ma i tassisti conoscono le scorciatoie.
  • Pratica: Scorciatoie da tastiera (Ctrl+C, Ctrl+V), macro, personalizzazione della dashboard per utenti "Power User".
  1. Design Estetico e Minimalista
  • Il principio: Ogni unità di informazione extra compete con le unità rilevanti.
  • L'Analogia: Il rapporto Segnale/Rumore. Se urli 10 cose insieme, nessuno ne capisce una.
  • Pratica: Non è solo "fare spazio bianco". È togliere tutto ciò che non serve all'obiettivo corrente dell'utente. Se non serve, è rumore.
  1. Aiutare gli Utenti a Riconoscere e Recuperare dagli Errori
  • Il principio: I messaggi di errore devono essere scritti in linguaggio umano e suggerire una soluzione.
  • L'Analogia: Un medico che dice "Codice 404" è inutile. Un medico che dice "Hai la febbre (Problema), prendi questo (Soluzione)" è utile.
  • Pratica: Mai "Unknown Error". Sempre: "La connessione è caduta (Cosa), Riprova tra poco (Come risolvere)".
  1. Aiuto e Documentazione
  • Il principio: Il sistema dovrebbe usarsi senza istruzioni, ma se servono, devono essere facili da trovare.
  • L'Analogia: La scialuppa di salvataggio. Speri di non usarla mai, ma se la nave affonda, deve essere lì e pronta all'uso.
  • Pratica: FAQ contestuali, search bar nell'help center, e soprattutto: non scrivere manuali giganti, scrivi guide focalizzate sul compito ("Come fare X").

Uso Pratico: Prima di consegnare il design, scorri la lista. Se violi un'euristica, devi avere un motivo dannatamente buono.