Passa al contenuto principale

UX & UI Real World Vademecum

Parte V: Goal-Directed Design (Il Metodo Cooper)

Come trasformare la ricerca in strategia. Qui impariamo a distinguere ciò che l'utente fa da ciò che l'utente vuole ottenere.

Obiettivi e Strategia​

25. Obiettivi vs. Compiti (Tasks)​

Il Viaggiatore del 1850

Cosa fa: Distingue il risultato desiderato dalle azioni necessarie per ottenerlo, evitando di ottimizzare processi che dovrebbero essere eliminati.

L'Analogia: 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, l'uomo d'affari ha lo stesso obiettivo: "arrivare in California sano e salvo". Ma i suoi compiti sono: chiamare Uber, passare il metal detector, allacciare la cintura.

La Trappola Tecnologica: Se ti concentri sui compiti, progetterai un fucile più leggero per il colono. Se ti concentri sugli obiettivi, inventerai l'aereo. Non digitalizzare la burocrazia cartacea (es. fare un modulo PDF editabile). Chiediti: "Perché stiamo compilando questo modulo?". Se la tecnologia può eliminare il compito per raggiungere l'obiettivo diretto, fallo. L'utente non vuole "configurare le impostazioni", vuole che il sistema funzioni.

26. Modello di Implementazione​

Il Tubo Magico dell'Elettricità

Cosa fa: Nasconde la complessità del database dietro un'interfaccia che rispecchia il pensiero umano.

L'Analogia: L'utente pensa che l'elettricità scorra nel filo come l'acqua in un tubo. È fisicamente falso (gli elettroni non funzionano così), ma è un modello mentale perfetto per usare il tostapane.

Il Peccato dell'Ingegnere: Gli sviluppatori amano mostrare il "Modello di Implementazione". Se il database ha tre tabelle separate per Cliente, Ordine e Indirizzo, l'ingegnere creerà tre schermate separate. Questo è logico per il codice, ma infernale per l'utente. Il tuo lavoro di UX Engineer è mentire. Crea un "Modello Rappresentato" che sembri magico e semplice, e poi suda sette camicie nel codice per far funzionare quella magia. Se l'utente deve capire come funziona il database per usare la tua app, hai fallito.

27. Le Posture del Software​

Programmi Sovrani vs. Transitori

Cosa fa: Definisce quanto "pesante" e invasiva deve essere l'interfaccia in base alla frequenza d'uso.

L'Analogia:

  • Sovrani (Sovereign): Sono come il banco da lavoro dell'artigiano (es. Excel, VS Code, Photoshop). L'utente ci vive dentro per 8 ore.
    • Design: Colori neutri (per non stancare), densità alta di informazioni, scorciatoie da tastiera fondamentali. Non sprecare spazio con bordi giganti.
  • Transitori (Transient): Sono come il cameriere che porta il caffè (es. Calcolatrice, Dialogo di Salvataggio, Widget Meteo). Arrivano, fanno una cosa, spariscono.
    • Design: Pulsanti grandi, colori più accesi, istruzioni chiare. L'utente non deve "impararli", deve usarli e via.

L'Errore: Se progetti un gestionale di fabbrica (Sovrano) con lo stile di una landing page (grandi spazi, pochi dati), l'operatore impazzirà per lo scroll continuo. Se progetti un popup di conferma (Transitorio) pieno di testo piccolo e opzioni, l'utente andrà nel panico. Adatta la densità alla durata dell'uso.

Metodo Operativo​

28. Scenari e "Magic Thinking"​

Fingi che sia Magia

Cosa fa: Immagina l'interazione ideale senza i limiti della tecnologia attuale, poi lavora a ritroso per realizzarla.

L'Analogia: Ricordi il lancio di Spotify? Tutti erano abituati a scaricare MP3 (il compito). Spotify ha detto: "E se cliccassi e la musica partisse subito, come per magia?". Sembrava impossibile. Hanno lavorato duramente sul buffering per rendere reale quella magia.

Il Metodo: Scrivi lo scenario ideale. "Mario entra in fabbrica, il tablet sa già che turno è e gli mostra solo le macchine che deve controllare." Non preoccuparti ancora di come farlo (Bluetooth? GPS? Login?). Definisci la magia, poi lascia che l'ingegnere che è in te trovi il modo di costruirla.

29. Generazione e Sintesi​

Il Motore e il Volante

Cosa fa: Struttura il lavoro di team per evitare il caos del brainstorming improduttivo.

L'Analogia: Un'auto ha bisogno di un motore che spinge (Generatore) e di un volante che dirige (Sintetizzatore).

I Ruoli:

  • Il Generatore: Spara idee a raffica, anche stupide, anche impossibili. È l'energia pura. Se si ferma, il progetto muore.
  • Il Sintetizzatore: Non uccide le idee, le collega. Chiede "Perché questo funziona?", "Come si collega all'obiettivo di Mario?". Non litigate su chi ha ragione. Scambiatevi i cappelli. "Ora faccio io il generatore per 10 minuti". I team migliori sono piccoli (2-4 persone) per evitare l'effetto "assemblea condominiale" dove si parla tanto e non si decide nulla.

30. Prototipazione​

Misura due volte, taglia una volta

Cosa fa: Risolve i problemi di design quando costano poco (fase di disegno), non quando costano tanto (fase di sviluppo).

L'Analogia: Costruire un muro di mattoni e poi doverlo spostare di 10 centimetri è un incubo. Spostare una riga su un disegno tecnico è gratis.

La Critica all'Agile Estremo: Il mantra "rilascia presto e rompi le cose" va bene per il software puro, ma per la UX è rischioso. Cambiare un flusso di interazione via codice è complesso e introduce bug. Usa la "Bassa Fedeltà" (rettangoli grigi, lavagna) per testare la logica. Se funziona lì, funzionerà nel codice. Il design deve guidare l'ingegneria, perché cancellare un rettangolo su Figma richiede 1 secondo, rifattorizzare un componente React richiede ore.