Fare design partendo dal testo
Quando comincio un nuovo progetto di design, o devo lavorare a una nuova funzione di qualche prodotto, parto sempre da un elenco testuale.
Fare elenchi mi aiuta a pensare meglio. In questo modo posso subito svuotare la mente dai mille pensieri affiorati, provando a capire come potrebbe essere organizzato quello che devo fare, e tutti gli aspetti (ed elementi) da prendere in considerazione.
In alcuni casi condivido subito questa parte con gli altri membri del team, in altri casi no, se penso che possa creare confusione. Una volta schiarite le idee, organizzo e dettaglio meglio l’elenco. A volte l’elenco diventa un documento di testo con immagini che aiutano a spiegare meglio il contenuto, altre volte diventa una mappa mentale (con MindNode) o un documento di Miro (o Mural), con una serie di post-it e frecce che mostrano un primo tentativo di organizzazione e connessioni tra gli elementi.
Partire dal testo aiuta tutto il team. In un articolo sul suo blog (pubblicato anche da UXDesign.cc), Ted Goas approfondisce bene questo punto, descrivendone i vantaggi. Confrontarsi con il testo permette a tutti, anche a chi non si occupa di design, di intervenire, rendendo più facile l’esplorazione di nuove idee, con più punti di vista differenti. In più, con un testo le persone si concentrano sul problema senza essere distratti da immagini o implementazioni specifiche.
Quel mio elenco iniziale, testuale, diventa poi visuale. Con Sketch (ora uso Figma, ma potrebbe essere XD) creo tutte le schermate principali, riportando una parola (o una frase) relativa a quello che ci sarà, collegandole tra di loro. Non è ancora un wireframe (o un wireflow), o forse in parte lo è, in ogni caso il testo resta l’elemento principale. Anche questa fase è utile perché tutti possono intervenire, ragionando sugli aspetti e gli elementi da considerare. «I wireframe sono troppo concreti e la parole sono troppo astratte», scrive Ryan Singer nel e-book Shape Up che racconta il processo di lavoro del team di Basecamp.
Quando si lavora subito al wireframe si definiscono troppi dettagli troppo presto, ed un continuo “non pensare all’elefante”, che porta a stimare in modo errato tempi e risorse necessarie. Guardare un wireframe, senza pensare al wireframe e immaginarsi subito come sarà un pulsante o una card, è complicato.
Singer scrive inoltre che anche specificare troppo il progetto porta ad errori di stima. Sembra controintuitivo, ma più si specifica più è difficile stimarlo perché l’interfaccia potrebbe nascondere complessità non visibili subito. In un wireframe elementi con lo stesso peso visivo (per dire, un campo di testo per la ricerca di un articolo o per il tracciamento di una spedizione) hanno livelli di difficoltà e problematiche diverse.
Allo stesso tempo, anche specificare troppo poco non è utile. Essere generici, con cose tipo “qui apparirà la ricerca”, non permette di capire agli altri membri del team cosa includere e cosa tralasciare.
A questo punto, a secondo del progetto, comincio a preparare wireflow (i wireflow sono l’unione di wireframe e flussi, ne abbiamo parlato in un altro numero di questa newsletter). La fase ancora successiva è quella relativa al design dell’interfaccia. Se esiste già un design system, ben organizzato, per i wireflow si possono subito usare gli elementi grafici e i pattern già disponibili. Se stiamo facendo un nuovo prodotto o servizio bisognerà impostare un design system, che dovrà essere strutturato su almeno tre livelli: brand; stile (il linguaggio visuale); componenti (gli elementi che andranno a comporre una schermata come tasti, form, modali, ecc.)
Parte del design system che andiamo a costruire (se non tutto) verrà utilizzato anche nella costruzione della comunicazione: il sito esterno, le campagne, il blog, l’help-desk e tutto quanto è necessario a promuovere e dare informare sul prodotto.
Per chiarire meglio quanto scritto finora azzardo un esempio pratico, che sono sempre difficili da fare. Immaginiamoci un servizio digitale che permetta di creare degli itinerari di viaggio o percorsi turistici (lo so, in questo periodo non proprio il tipo di progetto che potrebbe recuperare facilmente finanziamenti).
Con questo servizio, che chiameremo WeTravel, un utente può creare un pagina, dove inserire informazioni relative a un itinerario di viaggio, e vendere il pacchetto.
Prima dei link con gli esempi, una doppia premessa
Premessa 1: l’esempio è appunto solo un esempio. Serve a mostrare il flusso operativo che ho descritto sopra. La descrizione e la struttura del servizio è semplificata al massimo, senza nessuna ricerca su particolari esigenze o necessità su questo servizio. Il tipo di utente che mi sono immaginato potrebbe essere una persona esperta di una certa area geografica, in grado di organizzare un percorso e di accompagnare i visitatori (una cosa tra Airbnb Experience e i gruppi Facebook di varie associazioni che organizzano cose piccole e brevi, come camminate in montagna, visite ai musei e piccoli borghi, o più lunghe e articolate, come un tour del Rajasthan).
Premessa 2: sono abbastanza agnostico sui software. Sotto cito quelli che uso al momento, in passato ne ho usati altri, in futuro ne potrei usare altri ancora. Per fortuna, oggi ci sono decine di software che riescono a coprire le più svariate esigenze, tutti con una curva di apprendimento molto bassa e fatti molto bene. Bisogna solo cercare quello adatto al progetto, e al team.
Il flusso di lavoro di WeTravel, con esempi
Lavorando al progetto di questo servizio WeTravel, probabilmente in una prima fase avremo fatto delle ricerche, delle interviste e definito il tipo di servizio che servirebbe al nostro utente. Subito dopo cominciamo a organizzarlo il servizio, con un elenco puntato.
Elenco testuale
Se sono con il cellulare o iPad uso WorkFlowy. Quasi sempre questa parte non la comincio al computer, mi capita spesso di farlo anche a penna. Uso il computer per ricopiare l’elenco.
Esempio elenco puntato con WokFlowy →
Elenco testuale organizzato visivamente
L’elenco diventa un documento Miro (in passato per mostrare visivamente l’elenco ho usato MindNode, ancora prima Sketch e addirittura un paio di volte ho usato InDesign).
Esempio organizzazione con post-it con Miro →
Elenco testuale visuale, interattivo
Il wireflow testuale lo faccio con Figma, prima usavo Sketch, potrei anche farlo con Miro, ma preferisco separare le cose. In passato ho usato l’HTML-CSS, il risultato finale è lo stesso: una serie di schermate con un testo che ne descrive il contenuto, collegate tra loro.
Esempio struttura wireflow testuale con Figma →
La fase ancora successiva è quella relativa al design system e al visual design. In questo file Figma c’è un riepilogo delle cose che si dovrebbero fare per questo progetto immaginario (o anche per uno reale).
Processo di lavoro e desideri
Spesso i processi di lavoro sono una lista di desideri. So bene che è difficile riprodurre le cose in maniera lineare e che non esiste un “metodo” che vada bene per tutti (tra l’altro quello descritto più che un metodo è una sequenza).
Di solito applicando lo stesso metodo, per ogni progetto ci saranno differenze dovute a vari motivi. Le cose possono cambiare a seconda del tipo di progetto, progettare un nuovo prodotto per una start-up è diverso dal farlo per una banca. Le cose cambiano ancora se si lavora per un’agenzia e si sta progettando qualcosa per un cliente o quando si lavora all’interno dell’azienda che sta producendo quel servizio o prodotto.
In ogni caso fare layout dettagliatissimi, con centinaia di annotazioni e prototipi realistici, non può funzionare quando si lavora a un prodotto che si deve evolvere. L’unico modo è avere un flusso che permetta di correggere le cose in corso d’opera, senza far impazzire nessuno, distribuendo meglio e il più possibile la conoscenza. È utile quindi definire degli step dove si ha qualcosa di non completo, perfetto e definito che sia comunque comprensibile, che permette di essere evoluto e allo stesso tempo sia abbastanza poco permanente per decidere per cambiare strada.
Un’ultimo file. Qui trovate un riepilogo, su Figma, delle fasi relative alla progettazione di un’interfaccia, che sia un servizio digitale o meno.
Se vi va di condividere il vostro processo, in maniera informale (per scambiare pareri) o in maniera più articolata, scrivetemi a email@dispenser.design (o dove preferite).
|
