Nota degli editori: Siamo lieti di condividere un estratto dal Chapter 3 del nuovo libro di Dan Brown Practical Design Discovery, disponibile ora presso A Book Apart.
Uno dei problemi di design più difficili su cui io abbia mai lavorato è stato per un’azienda che aiutava i gruppi IT nella gestione del rischio. Il loro prodotto era incentrato su componenti open source, poco costose e ampiamente supportate da un’enorme comunità, ma spesso vulnerabili a causa di falle nella sicurezza.
Quello che ha reso questo problema di design difficile è stata la complessità della struttura sottostante al prodotto, un triangolo di concetti astratti collegati tra loro. Per lavorare sul problema, abbiamo creato una serie di sketch che ci hanno aiutato a comprenderlo.
Il risultato è stato un prototipo relativamente semplice, un modello della struttura generale dell’applicazione. Sebbene fossimo stati ingaggiati per creare un design dettagliato, il nostro cliente ha ammesso più tardi che sapevano che non ci saremmo riusciti, ma che avevano una grande considerazione per l’impegno messo nel risolvere la struttura sottostante. Questi sforzi hanno impostato la direzione per qualunque altra cosa nel prodotto.
Affermazioni che impostano la direzione#section1
In maniera molto simile a quando inquadriamo i problemi, possiamo fare delle asserzioni che impostino la direzione e descrivano le decisioni di design. Queste decisioni saranno piuttosto di alto livello, il che significa che riguarderanno una visione olistica del sito o del prodotto. Le decisioni sui dettagli verranno in seguito, sebbene vedrete che alcune affermazioni diventeranno piuttosto specifiche come modo di chiarire e testare la direzione.
Ci sono tre tipi di asserzioni che potete fare sulla direzione del design:
- I principi definiscono cosa dovrebbe o non dovrebbe fare il design. Queste dichiarazioni si fondano sulla ricerca e quando non le si può legare alla ricerca, si può far riferimento ad esse come a implicazioni.
- I concetti stabiliscono un approccio generale al prodotto espresso come un tema centrale o un’idea.
- I modelli descrivono il prodotto in modo astratto, mostrando l’architettura sottostante, la struttura, il flusso o l’approccio. Offrono un senso del modo in cui il prodotto funzionerà (senza l’effettiva funzionalità).
Se cercate di prendere delle decisioni tattiche troppo presto, potreste creare un precedente senza capire in che modo influenzi quello che viene dopo: è difficile tracciare le decisioni di basso livello a uno specifico obiettivo o a una dichiarazione di problema. Perché il pulsante è blu? Non c’è obiettivo di progetto nel mondo che possa giustificare una tale decisione.
Al contrario, prenderete alcune decisioni di basso livello insieme alle vostre asserzioni, usando dei campioni per illustrare, chiarire e dimostrare l’applicazione delle decisioni di alto livello. Per esempio, potreste arrivare al principio di design che il tono del sito dovrebbe essere amichevole senza essere troppo casuale o informale. Potreste dimostrarlo con il design e il contenuto di alcune schermate di esempio, che mostrino messaggi che dicono “Thanks!” invece di “Thank you very much” che è troppo formale o “You rock!” che è troppo casuale.
Esplorare le grandi decisioni attraverso esempi potrebbe incoraggiarvi a riconsiderarle o a trovare dei posti nella product experience in cui servono delle variazioni. Magari la palette dei colori è insufficiente per tutto quel che vi serve o la voce autoritaria non è appropriata per alcune pagine.
Azzardando una soluzione non state semplicemente chiedendo “Funzionerà?”, ma anche “Ho sufficienti conoscenze per sapere se questa funzionerà?”, ossia, gli step verso la risoluzione del problema potrebbero far scattare ulteriori insight o domande riguardanti il problema. Una grande fase di discovery implica che si fornisca solo sufficiente forma e definizione in maniera tale che il team si possa allineare dietro a queste e seguire tale direzione per il prodotto.
Principi e implicazioni#section2
I principi sono regole che aiutano i designer a valutare le proprie decisioni sul design. Forniscono una guida sotto forma di dichiarazioni assolute su quello che il design dovrebbe o non dovrebbe fare. Detto ciò, nessun insieme di principi può essere esaustivo. A volte, sembrano dei comandamenti: regole che potrebbero essere applicate a vari tipi di decisioni di design e pertanto aperte all’interpretazione.
Non c’è uno standard del settore sul modo in cui vadano scritti i principi di design, quindi non violerete alcuna regola se userete dei pittogrammi o scriverete un dialogo, ma i principi sono solitamente costituiti da una frase, spesso scritta usando l’imperativo.
Fa di più con meno (Microsoft Design Principles)
Progetta per il cliente e infondi sicurezza (Intuit)
Usa i dati per prendere decisioni e migliorarle (Principles for 21st Century Government, Code for America)
Queste mi piacciono ma non sembrano specifiche per un prodotto o un’azienda. I principi sono più potenti quando sono direttamente rilevanti. Questi usano frasi più elaborate che sono in stretta relazione con il prodotto:
Più di quadrati su uno schermo (Google Calendar)
Le interfacce transitional sono più facili da apprendere e più piacevoli da usare (MapBox)
Il tempo è denaro, quindi crea per le persone in movimento (Windows User Experience Design Principles)
A volte, troverete dei principi resi come frasi nominali di una o due parole, come se completassero l’espressione “Il principio di ______.”:
Maggior contrasto (10 Principles of Codeacademy.com)
Consistenza (First Principles of Interaction Design, Bruce Tognazzini)
I principi a volte sono seguiti da descrizioni più approfondite e da esempi. La mia variazione preferita di questo è tratta dai Windows User Experience Design Principles. Questi principi includono domande che i designers dovrebbero porsi riguardo alle decisioni di design:
- Personalizzazione, non customizzazione
- La feature permette agli utenti di esprimere un elemento di sé stessi?
- Avete fatto la distinzione tra personalizzazione e customizzazione?
- La personalizzazione deve essere una nuova feature o può usare feature e informazioni esistenti (come la posizione dell’utente, l’immagine di background o tile?)
Indipendentemente dall’approccio che prenderete nell’inquadrare i principi, usate un linguaggio e delle strutture consistenti, anche se solo per renderli più semplici da ricordare e usare. Se partite con un verbo, partite sempre con un verbo. Se scrivete una frase concisa o una frase completa per esprimere il principio, fate sempre così. Se scrivete principi di una singola parola, beh, c’è un posto speciale tutto per voi in purgatorio.
Nella pratica, io formulo i principi come dirette conseguenze di quello che ho imparato nella ricerca. Li chiamo implicazioni e le preferisco perché vanno bene nella narrazione: “Abbiamo imparato che gli utenti spesso perdono l’orientamento nel sistema. L’implicazione è che la UI dovrebbe avere come priorità chiarire il contesto”.
Le implicazioni rispondono alla domanda: “Quindi?”. Avete generato molti dati e adesso dovete spiegare perché tutto ciò è importante. Tipicamente, io lo documento in un foglio di calcolo che identifica le domande di progetto, le risposte che ho scoperto e le implicazioni risultanti (Fig. 1).

Fig. 1: Raggruppare le attività genera risposte alle domande riguardanti il contesto o i requisiti.
In sostanza, i principi e le implicazioni fanno la stessa cosa, quindi non mi accanirò sulla distinzione tra esse. In entrambe i casi, fanno una dichiarazione che sì, guida il designer, ma fornisce anche un test: i designer possono confrontare un’idea con il principio e determinare quanto da vicino/attentamente aderisce alla guida.
Non c’è uno standard per i principi di design, sebbene ci siano molti suggerimenti là fuori (la sezione Risorse include alcune delle migliori). Ecco i miei suggerimenti per creare i principi di design.
Siate specifici#section3
I principi dovrebbero essere il più specifici possibili per il prodotto. “Facile da usare” non è un principio significativo perché si potrebbe applicare a qualunque cosa.
Per il progetto con l’azienda di risk management che ho descritto all’inizio di questo capitolo, abbiamo usato un numero di principi. Nelle prime versioni del loro prodotto, gli utenti si erano lamentati del fatto che fosse facile perdere il segno, quindi non riuscivano a tenere traccia di quello su cui stavano lavorando. Questo ci ha condotto al principio:
Mostrare sempre il contesto dell’utente all’interno del sistema, così che sappia dove si trova e su cosa sta lavorando.
Il contesto diventò qualcosa di cui si parlava molto. Ci ha obbligato a ragionare attentamente prima di spostare le informazioni a una schermata diversa o prima di lanciare una dialog box per fare un’azione. A causa di questo principio, ci siamo spesso chiesti: “L’utente sa dove si trova? La perdita di contesto qui va bene?”.
Mettete in discussione le vostre scelte#section4
I buoni principi vanno oltre la specificità: pongono una sfida diretta ai designer. Vi obbligano a dare una ricontrollata al vostro lavoro: il principio annulla qualcuna delle vostre decisioni? Fatti nel modo giusto, i principi dovrebbero farvi agitare un po’.
Nel prodotto di risk management, la complessità dei suoi requisiti ha inevitabilmente prodotto dei design densi ed esoterici. Delle visualizzazioni elaborate cercavano di catturare ogni sfumatura, di contenere ogni dettaglio. Allo stesso tempo, il nostro cliente aveva sentito che ai loro utenti non piacevano le visualizzazioni dense. Ci siamo mossi su un confine labile e ci siamo basati su questo principio:
Mostra solo l’informazione sufficiente per supportare le decisioni essenziali, niente di più, niente di meno.
L’auto-contraddizione borderline del principio ci ha spronato a riconsiderare quello che avrebbe dovuto esserci su ciascuna schermata mentre gli utenti lavoravano attraverso il processo. Abbiamo tolto troppo? È assolutamente necessario tutto quello che c’è su questo schermo? Da un lato, volevamo che gli utenti si sentissero sicuri su dove fossero, ma dall’altro, non volevamo che la pagina fosse sovraccarica di dispositivi di navigazione irrilevanti per il task corrente.
Ci siamo anche costantemente chiesti “Cosa vuol dire ‘giusto l’informazione essenziale’?” e “Quali sono le ‘decisioni essenziali‘?”. Ogni iterazione del design ha testato il significato di queste frasi chiave.
Ispirare il proprio team#section5
Principi specifici e provocativi potrebbero apparire come frustate: Fai così e fallo in questo modo. Ma un buon principio deve anche ispirare, indirizzandovi verso obiettivi ancora più nobili. Apre possibilità incoraggiandovi a esplorare e fornisce una base logica che definisce il punto di arrivo.
Nel suo riassunto di una talk di Stephan Hoefnagels di Microsoft del 2009, Luke Wroblewski scrive: “Gli obiettivi sono la cima della montagna che state cercando di scalare. I principi [di design] sono il sentiero che utilizziamo per raggiungere la cima della montagna.”.
Uno dei principi guida per il prodotto del mio cliente si basava sull’idea che il prodotto fosse focalizzato sulle cattive notizie: ogni schermata riguardava qualcosa che stava andando male nel dipartimento IT quel giorno, quando fosse seria la situazione e cosa non era in esecuzione. Tuttavia, come la maggior parte dei prodotti interattivi, questo doveva essere piacevole da usare. In breve, dovevamo trovare un equilibrio tra il vedere tutto nero e la soddisfazione derivante dal comprendere la natura e la portata delle cattive notizie. Ci siamo basati su questo principio:
Create fiducia dichiarando chiaramente i rischi e facendo in modo che si possa agire in base ai dati.
Sapevamo che l’obiettivo era di aiutare i clienti a gestire i rischi. Questo principio ha agito da sentiero verso la cima della montagna ispirandoci a concentrarci non solo sul riferire le cattive notizie ma anche sull’essere sicuri che i clienti potessero fare qualcosa a tal proposito.
Collegare i principi alla ricerca#section6
I principi con base nella ricerca producono dichiarazioni più forti. La campana a morto di ogni principio è l’arbitrarietà: se un principio deriva dalla preferenza soggettiva del Chief Something Officer o perché riflette il modo (disfunzionale) in cui l’organizzazione ha sempre lavorato, i designer lo ignoreranno. Il vostro principio potrebbe altrimenti essere perfetto ma se la fonte è sospetta, il team non lo prenderà sul serio.
Inoltre, qui è di cruciale importanza la partecipazione del team a tutte le attività di discovery. Dal momento che hanno contribuito alla ricerca, possono anche aiutare a scrivere i principi. Partecipando nella realizzazione dei principi, il vostro team li farà propri. Vedere i principi più in là nel tempo farà scattare dei ricordi delle osservazioni degli utenti, che possono integrare più prontamente nel loro lavoro.
I Windows User Experience Design Principles derivavano direttamente dalla ricerca. Nel leggere alcuni di questi principi, potete quasi sentire le frasi a supporto dette dagli utenti:
- Ridurre i concetti per far aumentare la fiducia.
- Le cose piccole contano, nel bene e nel male.
- Essere esperti di “guarda” e “fai”
- Risolvere le distrazioni, non la discoverability.
- UX prima di pulsanti e domande.
- Personalizzazione non customizzazione.
- Dare valore al ciclo di vita dell’esperienza.
- Il tempo è importante, quindi create per le persone in movimento.
Potreste argomentare che manca loro della specificità. Tuttavia, quando prendete in considerazione la portata del progetto (un intero sistema operativo) sono sufficientemente provocatori e ispiratori. “Risolvere le distrazioni non la discoverability” è un’affermazione audace, che offre chiare opportunità per rifinire il design senza dettare una soluzione in particolare. Apre delle conversazioni e inoltre le guida.
Concetti e grandi idee#section7
Una delle mie scene preferite in Mad Men, lo show televisivo sulle agenzie pubblicitarie negli anni ’60, è il pitch alla Kodak alla fine della prima stagione. Kodak sta presentando un nuovo prodotto, un vassoio circolare che rende semplice il posizionamento delle diapositive e la loro proiezione. Lo chiamano “La Ruota”, ammettendo “Sappiamo che le ruote non sono viste come una tecnologia esaltante”.
Il creative director Don Draper, il protagonista dello show, spiega che questo prodotto non riguarda la tecnologia: attinge ai nostri ricordi e alle nostre emozioni. L’agenzia poi svela il proprio concept per la campagna: la giostra.
Stabilendo un concetto centrale, un team (che sia nell’advertising o nel web design) ha una fonte singolare di ispirazione, un template per valutare le idee. E mentre i principi possono servire come punti guida, solo un concept può stabilire una vision. Con entrambe nel vostro toolkit, il vostro team ha una tensione potenzialmente interessante a cui attingere.
Usare una giostra per descrivere un proiettore di diapositive crea una metafora traboccante di significato e possibilità. Mostra due modi in cui possiamo esprimere una grande idea:
- Come vi fa sentire il prodotto: le giostre evocano la gioia del rivivere ricordi felici.
- Come funziona il prodotto: la giostra che gira mima il posizionamento e la visualizzazione delle diapositive dalla ruota.
Ciascun approccio può aiutarci ad esprimere la grande idea che sta dietro ai nostri prodotti digitali e siti web. (Sebbene io non abbia mai lavorato a un progetto che ci abbia fornito un concetto elegante come la giostra, che impiega entrambe gli approcci!)
Come vi fa sentire il prodotto#section8
Lo scopo e la funzione dei prodotti interattivi offre opportunità mature per metafore, ma la metafora non è l’unico modo per esprimere un concetto centrale. Per un progetto di un’applicazione web, il mio team ha espresso l’essenza con la frase “Potere con flessibilità”. Non è così immediato come la parola giostra, ma evoca la sensazione desiderata: che la app faccia sentire gli utenti come se potessero fare qualunque cosa.
L’abbiamo elaborata con le descrizioni del modo in cui le persone potrebbero fare esperienza di potere illimitato con il prodotto:
Fornire agli utenti uno status aggiornato così che sentano di avere il controllo
Ridurre le barriere in entrata
Permettere diversi stili di creazione di nuovo contenuto
Abbiamo anche descritto il significato di “Potere con flessibilità” dalla prospettiva dell’utente:
- Conoscenza: avere i dati giusti per far luce su bisogni immediati
- Reattività: essere in grado di fornire immediatamente risposte agli stakeholder
- Risultato: apprendere subito e bene un tool di importanza cruciale
- Controllo: essere in grado di ottimizzare il proprio contenuto per soddisfare bisogni diversi in situazioni diverse
- Comfort: vedere l’applicazione come un’estensione del proprio processo di ragionamento
Dal momento che questa era un’idea succinta, un po’ di elaborazione ha contribuito a farle avere un forte impatto sia con il cliente sia con il team di progetto.
Come funziona il prodotto#section9
I prodotti interattivi complessi traggono beneficio da un’idea centrale che descrive il modo in cui funzionano. Questo solitamente significa impiegare una grande idea per convogliare la struttura sottostante.
Il carrello della spesa, per esempio, è una metafora popolare usata sui siti di ecommerce. Potreste usarla anche se non steste lavorando a un sito di ecommerce. L’idea di “aggiungere cose al carrello” è una metafora famigliare che convoglia la struttura sottostante del sito. Abbiamo addirittura fatto affidamento su questa metafora nel nostro sito di career-guidance: gli studenti “aggiungono le carriere al proprio carrello” dopo essere stati valutati.
Ci sono alcuni altri framework affidabili per descrivere la struttura di un sito web. Per la applicazioni web, ce ne sono due comuni oltre al carrello:
- Hub-and-spoke: questo è probabilmente il pattern più comune per strutturare un sito web o un prodotto digitale. La metafora hub-and-spoke implica che l’applicazione web ha una schermata centrale dalla quale gli utenti possono far partire altre funzioni.
- List-detail: un altro approccio tipico consiste in una lista di item che gli utenti possono selezionare per maggiori dettagli, come la inbox dell’email.
Dovete usare una di queste strutture? Ovviamente no. Ma se il vostro sito si presta a uno di questi approcci, avete la vostra grande idea attorno alla quale ruota tutto il resto. (Non è un riferimento alla giostra, lo giuro).
Per siti focalizzati sull’invio di contenuti (piuttosto che sulla funzionalità di compravendita), i framework sicuri gestiscono di più il modo in cui è organizzato il contenuto:
- Topic: l’oggetto del contenuto o il tema di discussione
- Azioni: che task supporta il contenuto (come la ricerca di prodotti rispetto alla risoluzione dei problemi dei prodotti)
Queste non sono le sole strutture per categorizzare il contenuto ma sono i miei punti di partenza abituali.
Nessuno di questi è un design completamente sviluppato di per sé: sono tutti framework ben compresi che fungono da spina dorsale di un design più grande. Sono grandi idee che descrivono in che modo funziona il prodotto.
Non dovete fare affidamento su un’astrazione o metafora (come la giostra) per convogliare la grande idee ma al contrario attingere dall’emergente collezione di framework compresi. Il fatto che stiano diventando una parte dei gergo del web design è testimonianza del loro potere e della loro flessibilità.
C’è altro oltre a questo articolo!#section10#section10
Leggete il resto di Practical Design Discovery su A Book Apart.
Nessun commento
Altro da ALA
Webwaste
Uno strumento essenziale per catturare i vostri progressi lavorativi
Andiamo al cuore dell’accessibilità digitale
JavaScript Responsabile, Parte II
JavaScript Responsabile: parte prima