In questo articolo proseguiamo con lo sviluppo della nostra applicazione di esempio sulle liste della spesa, concentrandoci sulla traduzione della mappa di navigazione funzionale in una serie di viste (canvas) che prototiperemo velocemente e poi trasformeremo in template HTML5 + CSS3 da sottoporre a una serie di test per la verifica dell‘esperienza utente.

Dove eravamo rimasti…

Lo scorso articolo ci eravamo lasciati con questa piccola mappa di navigazione funzionale che aveva il compito di riassumere, in maniera sommaria, i flussi funzionali dell’applicazione.

Figura 1 – La mappa di navigazione funzionale.

Essendo l’applicazione molto semplice, la mappa funzionale, che descrive l’applicazione a macro sezioni, e la mappa di navigazione vera e propria quasi vengono a coincidere.

In applicazioni complesse questo non accade spesso, poichè una sezione funzionale non necessariamente ha una corrispondenza 1-a-1 con la rispettiva vista utente: prendiamo ad esempio una form di registrazione complessa rappresentata da una singola sezione funzionale; questa in fase di progettazione UI deve essere decomposta in più sottoviste per divenire fruibile.

Dalla mappa funzionale alla interfaccia utente

È importante che la validazione con il cliente avvenga sulla mappa funzionale, sia a livello contrattuale che di validazione requisiti, piuttosto che su quella UI, in quanto la progettazione UI, per essere “sana”, deve comunque sottostare alle regole di contesto: la medesima vista funzionale di cui sopra in un contesto mobile potrebbe avere un output totalmente differente; oltre a questo, la progettazione UI deve essere sottoposta a buon round di test utenti.

Evolvere da una vista funzionale a una di UI è un processo lineare e per nulla complesso. Possiamo utilizzare gli strumenti più adatti al flusso di lavoro a cui siamo abituati; l’unica accortezza è quella di usare un tool che ci permetta di essere il più efficienti possibile in caso di reiterazioni esplorative che ci costringano a rivedere più volte il nostro lavoro.

Per questo progetto ho utilizzato Sketch 3 [1] di Bohemian Coding, un’applicazione per grafica vettoriale nata appositamente con lo scopo di facilitare la vita a UX/UI designer che in passato dovevano barcamenarsi avanti e indietro fra Adobe Photoshop e Illustrator e il defunto Fireworks.

Figura 2 – Sketch 3, un’applicazione di grafica vettoriale per Mac OS X.

Sketch 3 è un’applicazione per Mac OS, potente, flessibile e con una curva di apprendimento bassissima. Il grosso vantaggio di Sketch rispetto ai concorrenti è, oltre al costo decisamente accessibile, l’estrema pulizia dell’interfaccia e un piccolo sottobosco di estensioni [2] [3] [4] nate grazie al flessibile sistema di scripting e a una nutrita e crescente community.

Direttamente con Sketch, prendiamo la mappa funzionale e creiamo tanti canvas (aree di lavoro) quanti dovranno essere le viste UI previste, andando ad aggiungere quelle necessarie per completare il progetto, ad esempio viste di notifica, login o sottoviste.

Per ogni vista, espandiamo il mini proto-wireframe in qualcosa di più consistente, ricordandoci sempre l’obbiettivo di questa fase: non la precisione, ma la visione globale che possa farci da guida progettuale per creare un MVP (“Minimum Viable Product”) per poter testare sia la nostra supposizione di prodotto commerciale che la nostra idea di design (più che estetico, funzionale).

Figura 3 – Le canvas, ossia le viste UI derivate dalla mappa funzionale.

Tempo di incubazione per questo lavoro: poco più di un’ora. Il risultato visuale è più che soddisfacente: il flat design ci viene davvero in aiuto a creare prototipi che non sembrino effettivamente prototipi, e sicuramente ci risparmierà del lavoro quando dovremmo creare i template HTML.

Primo reality check del design

È il tempo di fare il primo pit stop di design, un piccolo reality check per comprendere se quello che è stato prodotto rispecchia le premesse con le quali è stato pensato.

Vi ricordate i nostri personas, Marie e Jonathan?

Figura 4 – L’uso di personas nel design della UX è stato trattato diffusamente nell’articolo precedente della serie.

E le loro Job Stories?

Figura 5 – Le job stories sono state illustrate nell’articolo precedente della serie.

Per comodità, per non farvi saltare da un articolo all’altro le ho riportate anche in questo. Il primo reality check che possiamo fare è ripercorre il design del prodotto con gli occhi di Marie e Jonathan, utilizzando gli scenari e le forze descritte nelle Job Stories e capire se il prodotto risponde a quelle esigenze in maniera puntuale e precisa.

Ricordiamo che le Job Stories sono a tutti gli effetti requisiti di progetto e non soddisfare uno di questi obiettivi significa esporre il fianco a un rischio evitabile. Il nostro stakeholder o il committente non ha ben compreso a fondo l’utilizzo dei personas, ma si è trovato perfettamente allineato con le job stories perchè in fondo hanno una lieve reminiscenza di “casi d’uso”.

I risultati del primo controllo sul design

È fondamentale che sulle job stories vi sia fra voi che progettate e il cliente un completo allineamento, onde evitare incomprensioni legate agli obiettivi in una fase avanzata di progetto. Si possono dare sostanzialmente tre scenari, da quello ottimale a quello decisamente pessimistico. In genere le cose rientrano in un criterio di caso “reale”, in cui non tutto è perfetto, ma non siamo neanche in situazioni disastrose.

• Caso migliore: durante la progettazione non abbiamo mai perso di vista l’esperienza; tutte le job stories sono soddisfatte e i personas possono verosimimente utilizzare il servizio in diversi scenari.
• Caso peggiore: le job stories non sono congruenti con il progetto e dobbiamo tornare al tavolo di progettazione.
• Caso reale: torna praticamente tutto, ma abbiamo progettato delle funzionalità che, per il nostro committente sono fuori budget, non sono accettate per varie ragioni, o non sono supportate dai processi organizzativi.

Ad esempio, la job story che sta alla base del requisito di “avere uno storico“, potrebbe essere troppo onerosa per i tempi e il budget che l’azienda si è prefissata. Scendiamo quindi a compromessi, avendo l’accortezza che la scelta che concordiamo non vada a condizionare gli altri elementi di progetto.

Una volta che siamo in pace con noi stessi, passiamo a ragionare a un grado di dettaglio maggiore, ragionando sempre in ottica di MVP (“Minimal Viable Product”, cioè un prodotto funzionante, con un limitato numero di funzionalità core e che può comunque evolvere in base agli sviluppi concordati con il cliente).

In dettaglio: esplorazione, validazione, test

Ogni schermata della nostra applicazione servirà ad un duplice scopo:

• esplorazione sul comportamenti degli utenti;
• validazione delle supposizioni che abbiamo fatto in quanto progettisti.

Per questa ragione, nel progettare queste viste, dobbiamo tenere presente sempre le verifiche, valutando cosa vogliamo o dobbiamo sottoporre a test, e in che modo farlo.

Nel nostro mondo ideale avremmo una infrastruttura di test in grado di supportare e registrare tutta una serie di comportamenti utenti: potremmo utilizzare AB test e test multivariati, e tutti gli altri strumenti di verifica che esistono. Ma non sempre ci troviamo nel mondo ideale: fortunatamente al giorno d’oggi possiamo fare test efficaci con strumenti a costo bassissimo, ad esempio Google Analytics.

Con Google Analytics imposteremo una serie di obiettivi ed eventi per tracciare i diversi comportamenti; per dare un senso a questi test, dobbiamo tracciare una tabella di ipotesi/assunti – test – risultati.

Ipotesi e supposizioni

Con ipotesi/assunti intendiamo “prese di posizione” di business o funzionali che vogliamo convalidare o invalidare con dei dati reali: rappresentano punti di vista basati su opinioni, che generalmente sono quelle dei committenti, ma spesso anche quelle dei designer “rockstar”.

Test

Con test invece andiamo a verificare dubbi o problemi su cui non ci possiamo pronunciare perchè oggettivamente non abbiamo sufficienti informazioni. Cerchiamo quindi di capire quali siano le soluzioni di design che siano in grado di supportare meglio gli utenti sui loro obiettivi.

Nei paragrafi seguenti, vedremo come queste ipotesi/assunti e i test si applichino alle diverse viste UI della nostra applicazione, quelle che abbiamo riportato sopra in figura 3. Ecco l’analisi, pagina per pagina.

Homepage

La homepage è molto semplice, con immagine evocativa.

Introduciamo un errore di design non inserendo nessuna call to action per ottenere maggiori informazioni dato che, per scelta comunicativa, il testo scritto descrittivo è praticamente assente

Figura 6 – La homepage.

Requisito tecnico

Disporre di un sistema di login / account.

Assunto 1

Gli utenti utilizzeranno comunque il nostro servizio per curiosità, anche se non spieghiamo prolissamente di cosa si tratta. Ci aspettiamo di misurare la proporzione delle persone che proveranno a usare il servizio piuttosto che abbandonarlo subito.

Test 1

Il designer e il committente non sanno decidersi su dove inserire il link per la login: in mancanza di un AB test, proviamo a inserirli entrambi in maniera poco intrusiva e vediamo quale ottiene le preferenze. Se entrambi forniscono buoni riscontri, potremmo decidere di mantenerli tutti e due

Test 2

Sia accedendo che usando la call to action, prevediamo di transitare nella popup di login. Siamo interessati a sapere se l’obiettivo di usare il servizio sia più forte di quello di fare login, anche se sappiamo bene che “fare Login” non è mai un obiettivo utente.

Login

Pagina minimale e via popup, perchè non vogliamo interrompere il flusso e far desistere l’utente. Prevediamo il login unicamente via Facebook e per tale ragione mettiamo una bella postilla rassicuratrice sul fatto che non posteremo mai in nome dell’utente.

Figura 7 – La pagina di login.

Requisito tecnico

Integrazione con Facebook

Assunto 2

“Chi al giorno d’oggi non ha Facebook?”. Partiamo proprio da un assunto irrazionale, vale a dire che tutti usino Facebook e che tutti siano ben disposti a concedere i loro dati alla prima startup con un nome bellissimo… sperando di essere smentiti: nessuna creazione di account, ma solo login via Facebook. Ci aspettiamo un basso tasso di abbandono.

Test 3

Quante persone sono interessate davvero alla propria privacy? Dal momento che siamo di parte, perchè stiamo progettando il servizio migliore del mondo, speriamo che le persone siano poco interessate alla privacy, altrimenti dovremmo riprogettare quella parte.

Test 4

Quante persone sono davvero motivate a usare il nostro servizio senza però utilizzare Facebook? Creiamo un’azione apposita per tracciare questo comportamento e capire se vale la pena di pensare un metodo di login alternativo.

Figura 8 – La pagina che verifica quanto interesse c’è nell’usare il servizio senza essere però iscritti a Facebook o senza voler collegare questo account a quello Facebook.

Chiaramente, in nessuna delle due casistiche siamo attrezzati (o vogliamo attrezzarci) a fornire il servizio, indi per cui transiteremo in una comoda schermata informativa che non fa altro che tornare indietro. A questo stadio abbiamo già effettuato il tracciamento dell’informazione che a noi pare rilevante.

Selezione del destinatario

La prima schermata funzionale utile è la schermata di destinatario. Ricordiamo che Einkaufsliste è una lista della spesa inviabile a una persona; quindi la prima cosa che facciamo è proporre questa schermata. L’utente ha cliccato su un bottone che chiaramente aveva la dicitura “Crea la tua Lista” e noi siamo vincolati dal testo a onorare questa promessa.

Figura 9 – Si crea una lista della spesa, scegliendo il destinatario a cui inviarla.

Requisito tecnico

Poter recuperare l’avatar dell’utente, i suoi amici con i rispettivi avatar e poterli filtrare per nome.

Assunto 3

Le ipotesi che vengono fatte in questo caso sono che il numero degli amici sia “gestibile” senza paginazione, e che l’avatar sia veramente identificante. Compiamo un errore di design non visualizzando almeno il nome delle persone: l’informazione dovrebbe avere almeno due punti di accesso, in questo caso visuale e testuale… e cerchiamo di capire se questo possa essere solo una turba del designer.

Test 5

Agli utenti non importa se devono scrollare. Ma siamo certi che non preferiscano “filtrocercare” la lunga lista? Siamo interessati a capire se la selezione diretta via avatar abbia il sopravvento rispetto al filtro di ricerca, in maniera tale da poter potenziare la paginazione o l’algoritmo di ricerca amici.

Test 6

Avere subito la scelta del destinatario disorienta? Non sarebbe forse meglio avere l’elenco delle Einkaufsliste già create? Vediamo quanto gli utenti usano la “emergency exit” ossia le vie di fuga dal flusso di lavoro progettato: convenzionalmente la più ovvia è il link alla “home” in alto a sinistra.

Aggiunta elemento

La prima schermata funzionale utile è la schermata di destinatario. Ricordiamo che Einkaufsliste è una lista della spesa inviabile a una persona, quindi la prima cosa che facciamo è proporre questa schermata. L’utente ha cliccato su un bottone che chiaramente aveva la dicitura “Crea la tua Lista” e noi siamo vincolati dal testo a onorare questa promessa.

Figura 10 – Aggiunta di un elemento per la lista della spesa da inviare a un determinato destinatario. Presente anche l’unità di misura, da valutare per una eventuale pre-ottimizzazione che leghi unità di misura precisa a tipologia di merce.

Requisito tecnico

Gestione CRUD di Einkaufsliste, Item e Autocomplete.

Einkaufsliste:{
    id: int
    userId: int
    userName: string
    destinatarioId: int
    destinatarioName: string
    dataCreazione: date
    status: int
    dataInvio: date
}

Item:{
    id: id
    testo: string
    unitaMisura: String
    userId: int
    userName: string
    einkaufsliste: int
    dataCreazione: date
    posizione: int
}

Autocomplete{
    Items: [
        {nome: string, cardinalita: int}
    ]
}

Assunto 4

Facciamo una supposizione sul modo in cui le persone creano liste della spesa, ossia ipotizziamo che siano relativamente brevi e che quindi possano essere create e inviate nello stesso flusso, senza prevedere salvataggi intermedi. Possiamo in futuro anche validare l’assunzione di lunghezza di lista.

Test 7

Non sappiamo se l’aggiunta di un’eventuale unità di misura faciliti il data entry degli utenti: vediamo se l’unità di misura è usata o totalmente ignorata. Se è molto utilizzata, si potrebbe potenziare questo aspetto, legando l’unità di misura più frequente per la tipologia di elemento lista. Per ora ogni pre-ottimizzazione è budget investito male, e quindi aspettiamo di raccogliere i risultati prima di passare a questo tipo di aggiustamenti.

Test 8

L’avatar del destinatario non è cliccabile per tornare alla “selezione destinatario”: il nostro designer, francamente, non ci aveva pensato… Mettiamo comunque un evento sul click per capire se effettivamente gli utenti ci cliccano sopra.

Sull’invio dei dati, è sufficiente una semplice overlay popup di conferma.

Figura 11 – Un popup ci conferma l’avvenuto invio.

La finestrina di popup si dismette dopo i canonici 3 secondi di conferma. Non siamo certi che sia un tempo adatto: è forse troppo lungo?

Test 9

Prevediamo quindi anche un click to dismiss della popup e vediamo quanto viene utilizzato

Se un qualche elemento viene aggiunto da un collaboratore, verrà visualizzato il suo avatar di fianco all’elemento.

Figura 12 – Un elemento aggiunto da un altro utente viene “marcato” dall’avatar dell’utente che lo ha aggiunto.

Sul tap dell’elemento, proprio o di un collaboratore, si potrà editarne il contenuto e l’etichetta per le liste già inviate diventerà SALVA invece di INVIA.

Elenco delle Einkaufsliste

Una volta inviata la lista, arriviamo nella pagina principale delle liste, accessibile anche quando si procede a un login semplice.

Figura 13 – La pagina con l’elenco di tutte le liste della spesa.

Non ci sono elementi da testare di rilevanza in questa vista.

Il tap su una lista porta alla visualizzazione della lista, mentre l’unica call to action è l’Aggiunta di una nuova lista.

Requisito tecnico

Visualizzazione delle liste pregresse, gestione dei badge di stato della lista.

Gestione della lista ricevuta

Chi riceve la notifica ed è un destinatario valido di una lista, accede direttamente alla lista in cui è stato invitato. Se non è il proprietario della lista, l’unica azione possibile, è l’approvazione, che genera il cambio di stato della lista con conseguente badge visualizzato in elenco.

Figura 14 – La gestione della lista ricevuta prevede il pulsante “APPROVA”.

Requisito tecnico

Cambio di stato della lista ogni qualvolta un ospite aggiunge un elemento.

Un po’ di formalità

Come vedete, anche per un’applicazione semplicissima come questa, gli aspetti legati all’esperienza che andiamo a testare sono molti e variegati. Formalizziamo quindi gli obiettivi in una tabella, che utilizzeremo per andare a effetture un tracciamento sistematico con Google Analytics.

Figura 15 – La tabella con cui andremo a effettuare un tracciamento grazie a Google Analytics.

Conclusioni

Abbiamo visto come sia possibile prototipare una serie di viste UI per la nostra applicazione di esempio Einkaufsliste, presentando anche alcuni strumenti per farlo. Il concetto importante è quello di formulare delle ipotesi (non necessariamente tutte giuste) riguardo ad aspetti che potremmo già conoscere e stilare dei test che ci consentano di acquisire informazioni, da analizzare grazie a Google Analytics, nell’ottica di creare il nostro Minimum Viable Product.

Si tratta adesso di creare i template HTML da dare in pasto a Express, con la nostra sapiente maestria nel creare opere di artigianato con HTML5 + CSS3. Visto che sarebbe assai noioso trattare questa parte, ve la affido come compito a casa, in maniera che la prossima volta, potremo essere tutti preparati con i nostri template già fatti, pronti per integrare il tutto!

Riferimenti

[1] Sketch 3, applicazione di grafica vettoriale

http://bohemiancoding.com/sketch/

[2] Sketch App Sources, con un nutrito numero di template e di immagini

http://www.sketchappsources.com/

[3] BrilliantSketch offre risorse grafiche, modelli, tutorial e plugin per Sketch 3

http://brilliantsketch.com/

[4] Una directory di plugin per Sketch

https://github.com/sketchplugins/plugin-directory