Come fare una app: dal flowchart al wireframe

Stabiliti i quattro punti cardinali si può iniziare a progettare una app. Siccome ormai la differenza tra app mobile e desktop app è labile, se non invisibile, è bene progettare una app pensando anche al mondo desktop.
Siamo nel 2015 e, prima Google con il timido tentativo delle Chrome App, e oggi ancora più esplicitamente e in maniera efficiente Windows 10, ci stanno abituando a visualizzare le nostre app mobile anche su desktop (non a caso Windows 10 permette di impostare la modalità tablet anche sul proprio desktop, che questo sia con touchscreen oppure no).

Flowchart, o i flussi di navigazione degli utenti

Per iniziare è di grande aiuto realizzare un flowchart (diagramma di flusso, o navigazione) dell’app. Il flowchart traduce in task (passaggi) le operazioni e i percorsi che l’utente può effettuare. Ad esempio ogni singola scelta, ogni singolo pulsante che l’utente può toccare in una schermata. Per procedere con una corretta progettazione del flowchart è di grande aiuto seguire il modello della task analysis. Le domande che bisogna porsi sono:

1. Qual è l’obiettivo che vuole raggiungere l’utente?
2. Quali sono le attività, azioni, che l’utente può compiere per raggiungere l’obiettivo?

Una definizione più dettagliata appare su Usability.gov e su UsabilityNet.
Una volta strutturata la task analysis, e quindi ottenuto il processo utente, si può disegnare il flowchart della nostra app. Ci sono diverse regole che aiutano a utilizzare correttamente le forme e i simboli degli elementi di un flowchart; lo schema seguente prova a riassumerli.

Non pezzi di puzzle, ma funzioni graficamente distinte da collegare.

 
Il tema dei flowchart richiederebbe un capitolo intero e per questo mi limito a un suggerimento: i task START e END dovrebbero sempre occupare rispettivamente la parte alta centrale del vostro documento e la parte centrale bassa, evitando così flowchart arzigogolati dove non si capisce quale sia l’inizio e quale la fine.
Validi strumenti (free o trial-free) per realizzare in piccoli passi un flowchart sono Gliffy, LucidChart, Cacoo, Fluid, UXPin o Moqups, ma ne esistono molti altri.
Completato il diagramma di flusso con tutte le sue diramazioni, si procede con il wireframe.

Prima di tutto il mobile

In Mobile First, Luke Wroblewski introduce il libro in questo modo:

Prendete la metropolitana, fermatevi al centro commerciale o passate davanti a un liceo e vi confronterete con la più recente evoluzione della razza umana. Piccoli schermi luminosi attaccati alle mani delle persone compaiono dovunque si posi lo sguardo. Per fortuna non parliamo di una qualche bizzarra mutazione genetica, ma solo dei nostri amici, gli apparecchi mobile Che stanno dappertutto.

Questo rende bene l’idea di come i device mobile siano più utilizzati dei desktop computer e richiedano una maggiore attenzione e riguardo soprattutto per la progettazione delle interfacce.
È chiaro che ci troviamo pienamente nell’era dei multischermi e delle multirisoluzioni. Questo ha dato vita agli approcci del responsive e adaptive design. In pratica, la progettazione multipiattaforma delle interfacce utente per migliorare l’esperienza della nostra app (o sito web) sui diversi device con diversi schermi e risoluzioni.

Due percorsi diversi di esperienza coerente che rispetta l’apparecchio.

 
In breve, l’adaptive design è la soluzione che permette di creare una app o web app su misura per desktop e diverse altre per mobile, quindi due diversi codici sorgenti e una doppia manutenzione. Il responsive design invece, sfruttando logiche più raffinate con un CSS prestrutturato, adatta l’impaginazione dei contenuti rispettando le specifiche del designer e permette di creare una sola volta il codice della app o web app, la quale si adatta allo schermo che la ospita. In questo articolo Jerry Cao spiega nel dettaglio la differenza tra le due soluzioni.

L’esempio di Repubblica.it mostra come il sito nella versione desktop sia impaginato in un modo mentre, nella versione mobile, rimandi a un altro URL (m.repubblica.it), con una impaginazione del tutto diversa e adatta per i dispositivi mobile. Questa soluzione è l’ideale perché, in questo caso, è il contenuto che guida la progettazione dell’interfaccia e si può notare come, anche nella versione mobile, le notizie della prima pagina conservino la più ampia visibilità e facilità di accesso.

Repubblica online vista da un browser desktop.

La versione mobile ha un URL diverso, ma resta ben leggibile.

 
A differenza di Repubblica.it, il sito della BBC sembra offrire invece la soluzione completa del responsive design. Il sito quindi non cambia radicalmente aspetto ma si rimpagina conservando lo stesso URL. Nel responsive design è evidente come l’impaginazione sia strutturata in tile, caselle, modello introdotto efficacemente da Windows in versione mobile.

Il sito della celebre emittente inglese, visto dal desktop.

Secondo i dettami del design responsive, il sito si riadatta.

Quale strada seguire dipende quindi dal tipo di design che si vuole seguire e, soprattutto, del tempo che si ha a disposizione per progettare più versioni ad hoc, oppure una unica che si adatta a seconda del device.

Wireframe e GUI

Il wireframe è un documento che racchiude le specifiche di design in maniera schematica e… in bianco e nero. Un po’ come un geometra disegna lo schema planimetrico di un edificio, così lo UX Designer, raccolti i dati e tradotti in specifiche di progetto i quattro punti cardinali, elabora il wireframe partendo dal flowchart complessivo.

Una app nasce schermata per schermata, pulsante per pulsante.

Il wireframe serve a disegnare, schermata per schermata, l’app che dobbiamo realizzare. Con la disposizione dei pulsanti, dei testi e dei feedback. A questo riguardo iOS, Android e Windows indicano e suggeriscono standard che possono essere di aiuto per progettare una app ad hoc. In tutti casi viene sottilmente suggerito di rispettare questi criteri perché sono stabiliti per rendere massima la compatibilità con i diversi device che ospitano i sistemi operativi.
Windows suggerisce di seguire una struttura composta una navigation bar (parte alta dello schermo), un content box all’interno del quale impaginare i contenuti e le schermate aperte della nostra app, e una barra in basso che prende il nome di command elements.

La struttura base di una app per Windows in versione mobile.

iOS invece conserva la classica struttura composta da una navigation bar in alto, che ospita i tasti di navigazione back (angolo in alto a sinistra) e next (angolo in alto a destra), title (in alto al centro) e una tab bar con quattro o cinque tab che permettono di accedere alle sezioni principali dell’app.

iOS ha definito il prototipo della app, che continua a evolvere.

 
Android ha infine introdotto il Navigation Drawer (da usare con moderazione e solo per menu con molte voci) e il Bottom Sheet, una interessante soluzione di design per mostrare le diverse sezioni della app.

Tutte queste soluzioni contemplano la possibilità di usare anche l’hamburger button, un valido compromesso tra le diverse proposte suggerite dai tre sistemi operativi; suggerisco di usare con molta cautela anche questo ed evitare di usarlo come una disordinata cassettiera.

Ricorda un panino ed è sinonimo di tuttofare nelle interfacce mobile.

La mappa dell’app

Una volta progettate le singole schermate, creato quindi il flusso di navigazione e stabilita la GUI di riferimento, il risultato finale sarà come questo: una mappa completa che rappresenta, in maniera ordinata e collegata con frecce direzionali e gesture, il percorso dell’app.

.

Comincia a impressionare, ciò che sta dietro un’interfaccia…

 
Se dunque siamo riusciti a progettare il flusso applicativo, abbiamo consultato le linee guida dei diversi sistemi operativi e abbiamo completato il wireframe task per task, disponiamo di un valido strumento che può essere usato per sessioni di testing con gli utenti. In questo modo, mostrando loro una schermata alla volta, si potrà procedere con le più classiche delle domande:

• secondo te che sito/app è?

• di cosa si occupa/cosa offre?

• in quale sezione del sito ti trovi?

• che cosa puoi fare?

• eccetera.

I feedback generati (che vanno testati) verranno inseriti nel wireframe. Importante: annotare tutti i comportamenti che l’utente trova naturali (una ottima sessione di user test potrebbe richiedere una videocamera per rivedere il test successivamente). I commenti e i comportamenti degli utenti sono la soluzione per migliorare l’usabilità della app. Completate le fasi di testing e quindi ottenuta l’approvazione degli utenti, avrete le specifiche pronte per essere progettate graficamente e implementate.

Due articoli, un processo

Seguendo i quattro punti cardinali e il successivo processo di design (flow e wireframe) qui raccontato avete probabilmente guadagnato del tempo evitando di creare un prodotto che, secondo voi, sarebbe stato perfetto. Questo perché avete ragionato seguendo un modello che ha guidato alla progettazione per task, passando per le specifiche ufficiali dei diversi sistemi operativi, fino alla valutazione degli utenti finali.
Mi rendo conto che avremmo dovuto discutere anche di altri aspetti, soffermandoci anche sulle specifiche dedicate agli smartwatch Apple e Android (come anticipammo in Fuori dagli schermi) e sulle interazioni attraverso il side button o la digital crown di Apple, ma questo sarebbe veramente un altro capitolo.
In conclusione, quando pensiamo a #mifacciolaapp, che sia mobile app o web app, ricordiamoci sempre degli utenti che la dovranno e vorranno usare; non pecchiamo mai di presunzione come Kyle Soucy, UX designer, racconta in Sins of a UX Researcher.
Buona app a tutti!

In questi articoli i nostri autori esaminano da ogni punto di vista la creazione di una app, dal design alla programmazione al marketing alle questioni legali, sotto lo hashtag #mifacciolapp. Tutti i post della serie sono consultabili a partire dalla pagina Come fare una app.