Daniele Irsuti

frontend developer

Mi ero rotto le scatole.

Non sapevo spiegare perché quell’interfaccia non andava fatta, non riuscivo a capacitarmi sul perché mi sembrava così sbagliata. Così ho iniziato a studiare design partendo da “The Design of Everyday Things”, un libro di Donald Norman.

Beh, iniziamo dalle basi!

Affordance

Non è possibile parlare, anche solo accennare di design senza aver chiaro cosa sia l’affordance, per cui è doverosa una precisazione di che cosa stiamo parlando.

L'affordance è la relazione tra le proprietà di un oggetto e le capacità dell’utente che suggerisce quali azioni sono possibili in base alla sua forma, al suo aspetto o al contesto, senza bisogno di spiegazioni: è come una barzelletta, se te la devono spiegare vuol dire che non funziona.

Prendiamo ad esempio quest’oggetto:

Non occorre spiegare che cosa bisogna fare, giusto? La fisicità dell’oggetto suggerisce da sola cosa fare: premerlo!

Oppure ad esempio uno switch, solo che quest’ultimo presenta delle etichette che rendono chiaro lo stato: on/off. Queste etichette fungono da signifier e sono necessarie se la sola affordance non è sufficiente a capire quale è il loro scopo (nell’immagine, si abilita/disabilita il volume di una vecchia radio).

Ho fatto questi due esempi non a caso perché ci dimostrano una cosa: quello che avviene sul piano fisico, viene riportato anche su quello digitale e lo facciamo continuamente.

Ed è per questo che “strane trovate” e “grafiche stravaganti” non portano nessun valore a livello di design: non comunicheranno nulla, se ciò che rappresentano non esiste nel mondo reale - ci torneremo dopo.

Bottoni che passione

La divisione che si occupa del backend spesso prende in giro la nostra, di frontend, perché ci considera degli “sposta‑pixel/aggiungi‑bottoni”.

E c'hanno ragione.

Picciotti, i bottoni però sono una cosa seria: per questo, quando si sceglie di crearli da zero, bisogna ricordare che un bottone sembra tale solo se ha alcune caratteristiche.

Questo sembra un bottone: è di contrasto, presenta un’ombra, dei bordi arrotondati e questa caratteristiche suggeriscono anche una profondità che richiama ad una “fisicità tattile” che fa pensare: - questa cosa può essere cliccata.

A volte si preferisce dare un tocco più stilistico (per esempio, oggi va molto il neobrutalismo): si scelgono bordi decisi invece delle ombre, mantenendo comunque un’alta affordance percepita - anche se non propriamente "tattile".

Cosa succede se ad un bottone togliamo la sua fisicità? Se rimuoviamo bordi, ombre o persino il margine interno, è molto semplice: non sembrerà più un bottone, al massimo verrà scambiato per un badge, aumentando il carico cognitivo per l’utente. Questo vale tanto sul web quanto nel mondo fisico.

Il mio amico Camillo, a casa sua ha degli interruttori BTicino che sono completamente piatti e la prima volta che li ho visti mi sembravano dei semplici tappi - questo è un esempio di non-affordance percepita. Questo perché probababilmente, ero abituato ai classici interruttori che puoi spingere sopra o sotto, quindi questo non sapevo se e dove premerlo!

Cos’è la discoverability?

Come il termine suggerisce, la discoverability (scopribilità) è una caratteristica fondamentale di un oggetto o di un’interfaccia: permette di capire a colpo d’occhio quali azioni sono possibili e in che stato si trova il sistema, senza bisogno di istruzioni o spiegazioni esterne.

Prendiamo in prestito una situazione quotidiana: entriamo in una stanza semi‑buia. Qual è la prima cosa che verrebbe in mente di fare? Probabilmente accendere la luce. Se l’istinto è quello, ti metterai a guardarti intorno per cercare un interruttore, esattamente dove di solito vengono posizionati: vicino all’ingresso. È una nozione appresa, un gesto che ripeti ogni giorno, in ogni luogo. Se l’interruttore è lì, beh, c’è poco da aggiungere: ottima discoverability!

Spostiamoci sul web: siamo su google.it e dobbiamo effettuare una ricerca. Come si fa? L’interfaccia è minimalista e la discoverability è ottima: al centro hai una grossa casella di testo, sotto un pulsante con scritto “Cerca con Google”. Tutto quello che ti serve è lì, immediatamente evidente.

La discoverability è un concetto facile da capire e da spiegare, ma non è sempre… semplicissima da applicare.

Su un’interfaccia che inizia ad affollarsi le cose potrebbero complicarsi.

Lo spazio si riduce, le funzioni aumentano e serve trovare un compromesso che accontenti tutti: i designer devono districarsi tra ciò che vuole l’utente, ciò che possono fare gli sviluppatori e ciò che chiede il reparto marketing - bottoni rossi, bottoni rossi, gialli, amaranto ovunque.

Quanto è importante la discoverability?

Da buon programmatore, la risposta a tutto è “dipende” ma provo a contestualizzare.

Tutti con il tempo impariamo e, con esercizio, ci abituiamo a fare cose complicatissime anche in poco tempo.

Ma questo è vero se, e solo se, c’è esercizio.

Ipotizziamo di aprire frequentemente un’applicazione, ostica da morire: i primi tempi sarà difficile, la odieremo con tutto noi stessi per quanto sia controintuitiva ma a forza di usarla ci abitueremmo e smetteremo quasi di farci caso.

Ora immaginiamo invece di aprire la stessa applicazione solo di rado: i primi tempi sarà difficile, la odieremo con tutto noi stessi, la useremmo il minimo indispensabile e la chiuderemo, sperando di non doverla riaprire più. Poi, dopo un mese, la riapriremo e il ciclo si ripeterà: continueremo ad odiarla. Perché? Perché non c’è stato abbastanza esercizio, quindi non la impareremo mai davvero. Un ciclo d’odio che non si spezzerà.

Questo per dire che più frequentemente usiamo un’interfaccia, più velocemente ne impareremo percorsi e scorciatoie; contrariamente, meno la usiamo, più faticheremo ogni volta a ritrovare quello che serve.

Perché parlare di questi dettagli?

In passato, quando ero alle prime armi con lo sviluppo web e facevo qualche sito per tirare a campare, mi è stato chiesto di realizzare cose assurde, reinventate, difficili. Specialmente Quando sei alle prime armi è molto probabile che chi ti chiederà di fare qualcosa del genere, proverà a sopraffarti facendo valere delle strane argomentazioni infilando delle parole in mezzo come “disruptive”, “out of the box”, “innovazione”.

Nell’ostinata (ostentata, alle volte) ricerca della “diversificazione” ci si dimentica che “pensare fuori dagli schemi” non dovrebbe implicare che gli utenti debbano reimparare - ad esempio - a compilare un form perché hai scelto di adottare una qualche velleità grafica.

No. Cerchiamo di farci valere con argomentazioni più convincenti - e se non c'è peggior sordo che non vuole sentire, alla prima occasione SCAPPA.

Il motivo risiede in due concetti chiave introdotti da Donald Norman per descrivere le lacune nell’interazione tra utente e sistema.

Introduzione ai “golfi”

Esiste un momento in cui tutti dobbiamo interagire con una cosa nuova e bisogna capire cosa fare. Sta nel designer realizzare un interfaccia che - molto importante - sia di immediata comprensione.

Esistono dei “pattern” che l’utente apprende navigando sito dopo sito, ad esempio come una casella di testo che mostra un calendario: l’utente sa che probabilmente si aprirà un menu a tendina e gli si aprirà un selettore per la data, è prassi così consolidata che se l'aspetta.

Treatwell, che è un portale che permette di prenotare un servizio presso dei centri estetici, barbieri, parrucchieri, ecc. ha realizzato questo tipo di componente in questo modo.

Probabilmente, avranno osservato che gli utenti sono più propensi a vedere le disponibilità dei centri e poi in base ad esse trovare uno slot comodo, secondariamente avranno pensato a quella tipologia di utenti “last minute” fornendogli delle selezioni rapide per oggi e domani. Dopodiché, possono fare ricerche più mirate, aggiungendo data precisa e orario desiderato.

Infine, il pulsante che conferma ogni tipo di scelta effettuata.

Questo era da desktop, però qualche motivo, da mobile il pulsante di conferma non è rappresentato allo stesso modo.

Selezionata la data, mi aspettavo un pulsante di conferma che però non ho trovato subito perché ero particolarmente distraibile: ero sul divano con la tv accesa, mentre la mia compagna mi diceva qualcosa a fianco. Eppure se notate, era lì: “Fatto” era dentro quello sfondo blu.

Prima di darmi dello stupido - l’utente non è mai stupido, anzi, vuol dire che qualcosa nel design non funziona - vorrei tornare al discorso sui bottoni. Cosa rende un bottone… un bottone? Beh, qui manca ogni tipo di signifier! Un testo bianco su uno sfondo blu di certo non lo qualifica come pulsante.

La mia intenzione era di confermare la data scelta, doveva essere una cosa semplice e scontata ma ho dovuto cercare come fare sotto, sopra per poi accorgermi che era in fondo, in un risicatissimo e poco accessibile spazio tra quello sfondo blu e la barra del browser.

Golfo d’esecuzione (Gulf of Execution)

Per usare la terminologia di Norman, questa anomalia ha ampliato il cosiddetto “Golfo d’esecuzione” che si distingue in 4 fasi:

• Goal: definire l’obiettivo generale (voglio prenotare una rasatura barba prima di capodanno)

• Intention: formulare l’intento specifico per raggiungerlo (ok, scrivo la data e poi confermo - qui mi blocco: come faccio?)

• Action Specification: specificare la sequenza di azioni (premo su “Fatto”)

• Execution: eseguire l’azione.

Golfo di valutazione (Gulf of Evaluation)

Comunque, la mia ricerca è andata avanti e sono riuscito a cercare barbieri disponibili in zona.

Con un esito per niente confortante.

Di buono c’è che il feedback è stato chiaro e ho capito che prima di capodanno la barba devo farmela da solo.

Il “Golfo di valutazione” non è stato assolutamente lacunoso come quello di esecuzione. Anche in questo caso, Norman suddivide in 3 fasi:

• Perceive: percepire lo stato del mondo/sistema dopo l’azione (ehi, la pagina è cambiata)

• Interpret: interpretare ciò che è percepito in base alle aspettative (mi aspettavo che la pagina mi fornisse delle opzioni)

• Evaluate: valutare se l’obiettivo è stato raggiunto, eventualmente iterando (non ci sono barbieri liberi, proverò in un’altra zona)

Conclusione

Abbiamo visto che affordance e discoverability sono certamente elementi importanti per la riuscita di un buon design.

Nel prossimo articolo parlerò di un altro tassello fondamentale: Feedback e stato.

👍 Se ti è piaciuto, lascia un commento.

🤙 Se ho detto inesattezze, correggimi!