Tognazzini

Bruce Tognazzini è una delle figure di spicco di NN Group, specializzato in human-computer interaction. Ha lavorato 14 anni in Apple durante il primo periodo di Jobs, dove ha fondato lo Apple Human Interface Group; nel 1996 è entrato come designer in Healtheon, la società di Jim Clark poi diventata WebMD.

I principi di “Tog” enfatizzano apprendibilità (quanto velocemente si colgono le basi), efficienza (quanto si lavora bene una volta imparato), memorabilità (quanto si ricorda dopo una pausa), gestione degli errori e soddisfazione. Aggiornati nel 2014 per touch e wearable, offrono un punto di vista personale e senza peli sulla lingua — Tog si definisce fan di Apple, ma con parecchie riserve documentate.

Ho tradotto e adattato questi principi per attualizzarli e renderli comprensibili a un pubblico non tecnico.

Estetica

• Affida l’estetica a professionisti esperti (graphic e visual designer).
• La moda non deve mai prevalere sull’usabilità: anche i trend più moderni devono migliorare l’esperienza.
• Testa il design visivo quanto quello comportamentale: apprendimento, soddisfazione e produttività devono migliorare o almeno restare invariati — altrimenti l’estetica appena aggiunta va ripensata.

Esempio: il sito e-commerce può essere minimalista, ma “Acquista ora” resta visibile e accessibile.

Anticipazione

Offri agli utenti tutte le informazioni e gli strumenti necessari per ogni fase del processo, senza costringerli a cercare altrove. Per anticipare i bisogni devi comprendere a fondo contesto, compiti ed esigenze — e testare: se uno strumento c’è ma gli utenti non lo trovano, è come se non ci fosse.

La pena per la mancata anticipazione è rapida e permanente: l’utente non vincolato (siti e app pubbliche) semplicemente non torna. E anche se hai un “utente vincolato”, non hai un “cliente vincolato”: se i dipendenti del tuo cliente perdono tempo, i tuoi concorrenti avranno una bella storia da raccontare al prossimo pitch.

Autonomia

• L’interfaccia deve far sentire l’utente in controllo — le persone imparano in fretta quando sentono di avere la situazione in mano.
• Paradossalmente, non ci si sente liberi in assenza di ogni confine (Yalom, 1980): un bambino piange sia confinato in uno spazio troppo stretto sia lasciato vagare in un magazzino enorme e vuoto. L’ambiente giusto è esplorabile ma non pericoloso.
• Lascia decidere l’utente, anche quando sceglie male esteticamente: quale tastiera usare, come organizzare il desktop (anche se ama il disordine), quali app eseguire. Quando gli sviluppatori si arrogano questo controllo, gli utenti si arrabbiano.
• Esercita però un controllo responsabile: non dare “tanta corda da impiccarsi”. Il testo illeggibile per dimensione, i cursori posizionabili solo col “fat finger” senza tasti freccia, le soglie di attivazione dei link non regolabili: applicazioni irresponsabili del controllo.
• Usa meccanismi di stato accurati e sempre visibili: l’utente deve capire lo stato del sistema con un’occhiata. E lo stato deve essere vero: l’indicatore di aggiornamento che promette cinque minuti e ne prende sessanta lascia l’utente ingannato — e un utente ingannato non si sente autonomo.

Colore

Daltonismo — Ogni volta che usi il colore per trasmettere un’informazione, aggiungi un secondo segnale inequivocabile: circa l’8% dei maschi (1 su 12) e lo 0,5% delle femmine ha una forma di daltonismo. Prova il prodotto per vedere ciò che vedono loro.

Il colore come elemento vitale — Ma non evitare il colore perché non tutti lo vedono: toglierlo non aiuta il daltonico più di quanto spegnere lo schermo aiuti il non vedente. Servono canali alternativi: pattern visivi diversi per ogni colore (righe, sagome, cerchi), utili anche in bianco e nero e in stampa. E non eliminare o esagerare i colori per una moda passeggera: dopo ogni restyling, verifica con test che apprendibilità e produttività non siano peggiorate.

⏱ Mini-recap: estetica testata, bisogni anticipati, utente al comando (con protezioni), colore + secondo canale.

Coerenza

I quattro principi di coerenza, nel loro insieme, danno al progettista enorme libertà di manovra nell’evoluzione del prodotto senza distruggere ciò che conta per l’utente.

A. Livelli di coerenza — L’importanza di essere rigorosamente coerenti varia per livello (e l’ordine è il contrario di quello che molti si aspettano; dal meno al più esigente):

1. Top level: coerenza di piattaforma (standard de iure e de facto) e in-house (l’aspetto comune ai tuoi prodotti comunica il brand e accelera l’adozione).
2. Suite di prodotti (Office, Creative Cloud): l’aspetto comune comunica familiarità.
3. Aspetto generale della singola app: un linguaggio visivo mirato, modellato dai test.
4. Strutture visibili (icone, simboli, pulsanti, scrollbar): aspetto strettamente controllato, o le persone passano metà del tempo a capire come scorrere o stampare. Dove ha senso, standardizza anche la posizione.
5. Strutture invisibili: oggetti che non si vedono — il bordo “magico” di Word, i controlli comparsi-a-hover di Apple. Se insisti a usarli, la coerenza diventa vitale, e la regola segreta dev’essere chiara e ovvia (“puoi trascinare i bordi delle finestre”), non “prova un po’ di cose e vedi che succede”. Gli oggetti che trasmettono informazioni non vanno mai resi invisibili (le scrollbar di iOS che scompaiono: subdolo).
6. Interpretazione del comportamento: il livello più sacro. Cambiare l’azione abituale di un utente è una delle cose peggiori che puoi fargli: le scorciatoie devono mantenere il significato, il pulsante che da 30 anni sta in basso a destra non si sposta in alto a destra. Esempio lampante: chi usa insieme Photoshop, InDesign e Illustrator riprogramma il cervello a ogni cambio di finestra, perché le stesse azioni hanno shortcut diverse.

B. Incoerenza indotta — Vale anche l’inverso: ciò che si comporta diversamente deve sembrare diverso. Se il tuo “cestino” non permette di recuperare i file, scegli un inceneritore, un trituratore — qualsiasi cosa tranne un cestino. E le pagine che hanno subito un cambiamento devono sembrare cambiate, o l’utente le userà come ha sempre fatto — e non funzionerà.

C. Continuità — L’obiettivo non è l’uniformità (il prossimo prodotto identico all’ultimo) né la coerenza museale: è la continuità, un filo conduttore che guida gli utenti attraverso versioni e prodotti senza incatenarti al passato.

D. Coerenza con le aspettative — “The most important consistency is consistency with user expectations” (William Buxton). Non importa quanto sia logica la tua soluzione: se gli utenti si aspettano altro, parti in salita. Se la tua strada non offre un vantaggio palese, segui le aspettative.

Defaults

• I valori predefiniti nei campi devono essere facilmente eliminabili: all’attivazione del campo, il contenuto si auto-seleziona (select-on-entry) così Backspace o la digitazione lo sostituiscono.
• I default devono essere intelligenti: non tutto merita un default. Se non puoi prevedere un candidato vincente, non offrirlo — esaminare un default sbagliato costa più che inserire il valore giusto.
• Sostituisci la parola “Predefinito” con termini che dicono cosa accadrà: “Ripristina le impostazioni iniziali”, “Usa impostazioni standard”. E testa: il vocabolario e il design devono comunicare la portata del ripristino — se sembri distruttivo l’utente non ti userà; se bruci ore di personalizzazione senza avvisare, peggio ancora.

Discoverability (Rilevabilità)

• Qualsiasi tentativo di nascondere la complessità finisce per aumentarla. Il software può somigliare a una Porsche, ma non a una Porsche senza volante e pedali. Dagli anni ‘90 molte aziende nascondono i controlli di base per creare l’illusione della semplicità per i potenziali acquirenti — a grave discapito degli utenti reali.
• Se vuoi nascondere la complessità, fallo solo nello showroom. Il software può presentarsi semplice in demo e poi schiudersi come un fiore man mano che l’utente cresce. Impoverire l’interfaccia aiuta la vendita iniziale ma allontana la tua vera forza vendita: i clienti storici.
• Se l’utente non lo trova, non esiste. Solo i più ostinati vanno a caccia del tesoro; gli altri passano alla concorrenza.
• Usa l’Active Discovery: non aspettare che le persone trovino una funzione — proponila. (1) Segnala la funzione quando potrebbe servire; (2) ripeti a intervalli intelligenti, non in continuazione; (3) smetti quando è stata adottata. Se molti disattivano i suggerimenti, stai esagerando in frequenza o tempismo.
• I controlli necessari devono essere accessibili in ogni momento; eccezioni solo su mobile, dove lo schermo minuscolo lo impone e un gesto standard li richiama tutti insieme.
• Non esiste un’eccezione di “eleganza”: nascondere le funzioni indebolisce l’utente e ti rende un bersaglio per la concorrenza.
• I controlli non stanno nell’area del contenuto (smartphone a parte, con un trigger standard che esponga tutto insieme). I web-developer meritano da sempre l’accesso alla barra dei menu del browser: costruire un concorrente di Photoshop dentro i menu di Word ti sembrerebbe folle, eppure è ciò che chiediamo a ogni web-app.
• Comunica il vocabolario gestuale con diagrammi visivi: una pagina d’aiuto che mostra i gesti compresi dall’app, presentata al primo avvio e sempre ritrovabile — come l’overlay di Snapseed che spiega simboli e gesti in un colpo solo.
• Ricerca l’equilibrio: non siamo più nel 1980, non serve un’icona informativa accanto a ogni elemento.
• Testa la rilevabilità: con utenti del livello di esperienza previsto, verifica che identifichino, imparino e usino gli strumenti necessari. Se non ci riescono, itera. Nessuno degli errori qui sopra sarebbe mai arrivato in produzione con test di usabilità di routine.

⏱ Mini-recap: coerenza a livelli (comportamento sopra tutto), default intelligenti, complessità visibile e scopribile — l’illusione della semplicità si paga.

Efficienza dell’utente

• Metti al centro la produttività dell’utente, non quella del computer: le persone costano molto più delle macchine. Costringere a inserire il telefono senza spazi risparmia una riga di codice e produce numeri illeggibili e errati — il tempo perso a rintracciarli spazza via il risparmio.
• Tieni occupato l’utente, non il processore: ogni attesa del sistema è denaro buttato.
• Massimizza l’efficienza di tutti, non del solo reparto IT: una soluzione che riduce i costi informatici ma la produttività aziendale è un pessimo affare. Formula onesta per deciderlo: (salario orario × 3) × n. dipendenti × tempo attività × Δ produttività — un numero positivo vende il progetto, uno negativo evita un errore costoso.
• I grandi guadagni di efficienza stanno nell’architettura, non nel maquillage dell’interfaccia.
• I messaggi di errore devono aiutare: scritti da un copywriter esperto, devono (1) spiegare cosa non va, (2) dire esattamente cosa fare, (3) lasciare aperta la possibilità che il messaggio nasca da un malfunzionamento del sistema. “Errore 404” non fa nulla di tutto questo. Il QA dovrebbe respingere ogni messaggio che non soddisfi i tre criteri.

Interfacce esplorabili

• Offri vie e punti di riferimento ben segnalati, poi lascia correre: la sicurezza e prevedibilità del paesaggio fisico, senza intrappolare in un unico percorso. Così neofita ed esperto finiscono il lavoro in fretta, e chi vuole esplorare non si perde.
• A volte serve un solco da seguire: più l’utente è all’inizio della curva, più va guidato. Un’app per un compito singolo e sconosciuto richiede più direzione di uno strumento usato ogni giorno da esperti.
• Dai segnali stabili di “casa”: il logo su ogni pagina — inclusa ogni pagina di pagamento — che riporta alla home fa sentire sicuri. Paradossalmente, chi sa di poter tornare facilmente, torna meno.
• Rendi le azioni reversibili: le persone esplorano anche oltre la navigazione; a volte vogliono vedere cosa succede, a volte sbagliano e basta. La reversibilità permette di esplorare e di lavorare rilassati. L’utente perfetto è un utente pigro.
• Consenti sempre l’Undo: l’alternativa sono le finestre “Sei davvero, davvero sicuro?” — e senza nemmeno quelle, le persone rallentano. Uno studio l’ha mostrato: in un ambiente pericoloso non si sbaglia di più, si lavora molto più lentamente. Risultato: crollo di produttività.
• Consenti sempre una via d’uscita: mai far sentire l’utente in trappola.
• Annullamento & wizard: nei wizard l’uscita è vitale — lascia uscire in qualsiasi momento, comunicando dove si potrà riprendere. Nei test, riporta le stesse persone dopo due settimane e osserva dove cercano di riprendere il lavoro: se cercano in due punti, metti la funzione in entrambi.
• Rendi il soggiorno facile e attraente: un checkout a schede etichettate consente di tornare a correggere un errore e riprendere il flusso. Se proibisci di tornare indietro — o distruggi i dati a chi lo fa — forse concluderanno l’acquisto, ma non torneranno.

Legge di Fitts

• Il tempo per raggiungere un bersaglio dipende da distanza e dimensione: bersagli grandi e vicini si acquisiscono prima. Usa oggetti grandi per le funzioni importanti, piccoli per quelle che preferiresti non venissero usate.
• La legge (formulata da Paul Fitts nel 1954, sulla base del suo lavoro degli anni ‘40 sui cockpit degli aerei) predisse che il menu Start di Windows era costruito al contrario — le app più usate più lontane dal punto d’ingresso — e i test lo confermarono. E indica che i punti più rapidi dello schermo sono i quattro angoli (il mouse ci si “blocca” contro), eppure per anni i progettisti li hanno evitati con cura.
• Bersagli multipli: il tempo totale è la somma dei singoli tempi. Oltre a ingrandire e avvicinare, riduci il numero di bersagli necessari al compito. E ricorda che i bersagli sono sia virtuali (pulsanti, menu) sia fisici (tasti, mouse, aree touch).
• Vale per ogni dispositivo di puntamento — non è stata abrogata da smartphone e tablet: Fitts lavorava su controlli fisici di cabina, più simili a un’interfaccia touch che a un mouse. (Senza bordi fisici gli angoli perdono l’effetto-blocco, ma distanza e dimensione dettano ancora i tempi.)
• La verifica richiede test cronometrati.

⏱ Mini-recap: produttività dell’utente prima del processore; esplorazione sicura con undo ovunque; bersagli grandi, vicini e pochi.

Oggetti dell’interfaccia umana

Gli oggetti dell’interfaccia (cartelle, documenti, pulsanti, menu, il cestino) sono cosa diversa dagli oggetti della programmazione object-oriented. Possono essere visti, uditi, percepiti (le suonerie sono oggetti uditivi, anche se non li chiamiamo così); hanno modi standard di essere manipolati (i pulsanti si premono, i cursori si trascinano) e comportamenti standard (il documento nel cestino non è eliminato: serve “Svuota cestino”). Devono essere comprensibili, coerenti e stabili. E quando vuoi un’interazione o un comportamento diverso, usa un oggetto nuovo: se trascinare un documento sull’icona lo distrugge all’istante, non farla sembrare un cestino — le persone arrivano con le aspettative degli oggetti già incontrati, e tradirle è un pessimo affare.

Riduzione della latenza

• Dove possibile, sposta la latenza in background (multi-tasking): i browser moderni pre-caricano i dati per ridurre i tempi morti.
• Riduci la latenza percepita: riscontro di ogni clic/tap entro 50 millisecondi; intercetta i clic multipli sullo stesso pulsante (le persone ripremono, rendendo tutto più lento); tieni informati gli utenti su ritardi e attese.
• E, tanto per cominciare, rendilo più veloce: elimina senza pietà tutto ciò che non aiuta. Mobile ha ricordato a tutti che i computer possono essere rapidi; i wearable alzano ancora l’asticella — nessuno “aspetta” di vedere che ore sono. Le app per auto, poi: immagina l’utente che sfreccia a 27 metri al secondo con gli occhi sul display, in attesa di sapere quale brano degli AC/DC sta ascoltando. Immagina l’ironia quando il rapporto sull’incidente rivelerà che era “Highway to Hell”.

Apprendimento

Idealmente i prodotti non avrebbero curva di apprendimento; in pratica ce l’hanno tutti.

• Limita i compromessi: apprendibilità e usabilità non si escludono. Decidi prima quale conta di più, poi persegui entrambe con vigore. Come decidere? Guarda la frequenza d’uso: prodotto monouso o raro → vince l’apprendimento; uso quotidiano per anni → vince l’usabilità. Poi chiediti chi è l’acquirente: se chi lo userà ogni giorno decide anche l’acquisto, l’apprendibilità vende.
• Evita i test di solo-apprendimento: sessioni da 20-60 minuti con soggetti nuovi ti dicono tutto sulla curva iniziale e nulla sulla produttività a regime. Per le applicazioni abituali, ingaggia lavoratori temporanei per una o due settimane e misura nel tempo la curva reale.

Metafore, uso di

• Scegli metafore che facciano cogliere al volo il modello concettuale: le buone metafore evocano esperienze passate e fanno capire subito capacità e limiti del sistema.
• Rendile vive coinvolgendo i sensi. Se il concetto non è rappresentabile nel software, un’illustrazione compatta può fare miracoli.

🌍 Il caso HyperCard — Il precursore del web di Apple aveva una struttura a tre livelli (Background comune, Card di primo piano, livello logico). Chi non la capiva non poteva programmarlo — e quasi nessuno la capiva, finché la grafica Kristee Kreitman non disegnò un’immagine esplosa dei tre livelli. Al primo test l’hanno capita tutti, immediatamente. Venti pagine di testo perfettamente accurato dell’inventore? Niente. Una sola immagine? Successo.

• Espanditi oltre l’interpretazione letterale del mondo reale: copiare pedissequamente un oggetto fisico (skeuomorfismo) e limitarne le funzioni per fedeltà all’imitazione è spesso una pessima scelta. L’inverso — l’astrazione del flat design — ha però trasformato icone comprensibili in simboli vuoti: l’icona del browser dell’iPhone è una bussola, legata al web dalla più vaga delle astrazioni… e l’iPhone ha anche una vera app bussola. Due bussole: una ti dice dov’è il nord, l’altra ti collega al conto in banca.
• Se una metafora ti trattiene, abbandonala. DP Maps (2009) sovrapponeva le direzioni dei satelliti TV alla mappa di Google: perfetto nel parcheggio di Apple, inutile in un bosco dove diecimila alberi sembrano tutti uguali dallo spazio. Il consiglio: indossare “un nuovo paio di occhiali” — letteralmente. Via la mappa, dentro una vista magica che ti fa alzare lo sguardo e “vedere” i satelliti in orbita: cammini finché il cielo è libero, monti la parabola, fine. Nessuna interpretazione cartografica necessaria.

Proteggi il lavoro degli utenti

Principio pressoché assoluto: gli utenti non devono perdere il proprio lavoro per un loro errore, per i capricci della connessione o per qualsiasi motivo che non sia inevitabile come un blackout senza protezione elettrica. Siamo così abituati a perdere dati che spesso non ce ne accorgiamo nemmeno — non è normale, è progettazione pigra.

Leggibilità

• Contrasto elevato: testo scuro su sfondo bianco o giallo pallido; evita i fondi grigi.
• Dimensioni adeguate ai display previsti: chiedi al marketing la gamma dei dispositivi e adatta il rendering (i CSS sanno farlo).
• Caratteri più grandi per i dati che per etichette e istruzioni: l’utente abituale impara che la macchia grigia dice “Cognome”, ma il cognome inserito deve essere sempre nitido. Ancora più critico per i numeri: il linguaggio umano è ridondante e si “recupera”; le cifre no — ogni carattere va letto.
• Le parole chiave prima nelle etichette di menu e pulsanti: gli esperti leggono solo l’inizio; i molto esperti riconoscono la forma della prima parola senza leggerla.
• Testa sulla popolazione più anziana: la presbiopia colpisce la maggior parte degli over 45. Non fidarti dei tuoi giovani occhi — semplicemente non puoi.
• Esiste una relazione inversa tra “bellezza” del carattere e leggibilità: l’anti-aliasing ammorbidisce i bordi, ma il sistema visivo umano cerca i bordi netti — nei corpi piccoli il carattere più elegante può essere il più faticoso. Esistono tecniche di anti-aliasing che preservano la nitidezza: fai test di velocità di lettura sulle modifiche tipografiche proposte.

Semplicità

• Bilancia facilità di installazione e facilità d’uso: sono in tensione. Se puoi contare su almeno un utente smaliziato in casa, rendi pure l’avvio un po’ più impegnativo se questo semplifica per sempre l’uso quotidiano di tutti — l’approccio Nest: configurazione complessa per uno, vita più semplice per tutta la famiglia.
• Evita l‘“illusione della semplicità”: nei primi anni 2000 Apple si concentrò così tanto sull’apparire semplice all’acquirente da erodere la produttività reale. La vera semplicità si ottiene semplificando, non nascondendo la complessità (vedi Discoverability).
• Usa la Progressive Revelation per appiattire la curva: va bene alleggerire l’ambiente del principiante nascondendo percorsi avanzati, se li riveli quando l’utente è pronto. Riduce anche i costi di supporto.
• Non semplificare eliminando il necessario: nel 2014 sul Mac potevi impostare un promemoria “90 minuti prima” dell’evento; su iPad solo 1 o 2 ore. Nessun limite tecnico: una decisione consapevole di togliere possibilità alle persone, spacciata per semplicità.

Stato

• I prodotti browser-based vivono in un ambiente senza memoria di stato: la responsabilità di tracciarlo è nostra. Il sistema dovrebbe “sapere”: se è la prima visita dell’utente, dov’era rimasto, cosa ha esplorato, dov’è adesso e cosa sta facendo.
• Il maestro assoluto è amazon.com — potrebbe essere descritto come un sistema di monitoraggio dello stato che, tra le altre cose, vende anche libri: i suggerimenti incredibilmente pertinenti nascono dalla comprensione dell’intera tua storia sul sito.
• Le informazioni di stato si salvano cifrate al logout: l’utente deve potersi disconnettere e riprendere esattamente da dove aveva lasciato — il servizio per medici Physicians On Line lo fa in modo esemplare, anche a settimane di distanza e dall’altra parte del mondo.
• Chiarisci cosa memorizzi e perché: i dati di stato non sono buoni né cattivi, dipende dall’uso. Dichiaralo nella privacy policy, spiegando il vantaggio per l’utente; cifra e proteggi tutto.

Navigazione visibile

• Rendi visibile la navigazione: la maggior parte degli utenti non può e non vuole costruirsi mappe mentali elaborate, e si perde (o si stanca) se glielo chiedi. Il web è di per sé uno spazio di navigazione invisibile: vedi la pagina, non lo spazio tra le pagine.
• L’ideale è l’illusione di essere sempre nello stesso posto, con il contenuto che arriva a te: stessa intestazione, stessi menu, stesso footer su migliaia di pagine — più senso di padronanza, meno bisogno di mappe. Evidenzia però quale pannello si sta guardando (voci di menu attive) e offri i breadcrumb: NN/g Home > AskTog > Interaction Design.
• Come per lo stato, non accettiamo ciecamente ciò che gli architetti del web ci hanno consegnato: la navigazione invisibile è una sfida, non un’inevitabilità.
• Limita le schermate usando gli overlay: per le attività secondarie, una sovrapposizione col contesto oscurato dietro non richiede di memorizzare nulla — si vede ancora “dove si era”.

⏱ In 30 secondi Il set più lungo e più opinionato: apprendimento vs usabilità deciso dalla frequenza d’uso, coerenza a sei livelli col comportamento in cima, undo sempre, latenza sotto i 50 ms, metafore che si abbandonano quando frenano, il lavoro dell’utente sacro. Da rileggere una volta l’anno.

🔑 Dove si aggancia alle Chiavi Tog alimenta quasi tutte le Chiavi; i contributi che nessun altro dà: Efficienza ed efficacia (Fitts, latenza, stato, protezione del lavoro), Esplorazione e Mappatura (discoverability, interfacce esplorabili, navigazione visibile), Accessibilità (leggibilità, daltonismo) e Libertà e Regole (autonomia).

---