Comunicazione tecnica e di prodotto: design per il mobile

Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR) Tel. / Fax: +39 045 6152381 Web: www.keanet.it | E-mail: [email protected]

1

Mobile Design Pattern Petra Dal Santo – KEA S.r.l. ([email protected]) | Dicembre 2016

Comunicazione tecnica e di prodotto: design per il mobile La documentazione tecnica e di prodotto è destinata a essere pubblicata sempre più spesso anche online, in particolare su dispositivi mobili e oggetti IoT (Internet of Things, internet delle cose): ecco perché ritengo utile approfondire le linee guida del design di applicazioni per il mobile partendo dal libro di Theresa Neil, Mobile Design Pattern Gallery: UI Patterns for Smartphone Apps, O’Reilly Media, Sebastopol, CA, USA, 2015.

Dal libro di Theresa Neil emergono spunti rilevanti per la comunicazione tecnica e di prodotto:

• L’importanza dei pattern ai fini dell’usabilità

• Il peso crescente dei contenuti visuali

• L’aspettativa dell’utente di poter manipolare direttamente i contenuti per fruirne in base alle sue esigenze (ricerca, ordinamento, filtro, zoom, ecc.)

• Il trend verso la cosiddetta ricerca implicita, ovvero la capacità dell’applicazione di proporre contenuti proattivamente, in base al profilo e al contesto operativo dell’utente

• La tendenza a supportare strumenti di input supplementari a quello testuale, in grado di collegare immediatamente mondo fisico e contenuti digitali (QR code [il più utilizzato], bar code, foto di prodotti, scansione della carta di credito, ecc.)

• L’accettazione da parte degli utenti solo di help contestuali e specifici, incentrati ognuno su un unico topic, redatto secondo un approccio di learning-by-doing (e, laddove applicabile, di gamification)

• L’importanza della raccolta e dell’ascolto del feedback degli utenti ai fini del miglioramento continuo dell’applicazione.

http://www.keanet.it/

mailto:[email protected]



2


Nell’introduzione alla seconda edizione del suo libro, Theresa Neil nota che nel giro di qualche anno le metafore mutuate dal mondo desktop/web hanno lasciato il posto a metafore specifiche delle interfacce mobile, e che si è compiuto il passaggio dal design neutrale rispetto al sistema operativo (SO) a convenzioni grafiche distinte per i singoli SO, in particolare per quanto concerne la navigazione.

Seguire i pattern significa rendere più facilmente riconoscibili all’utente la struttura e le funzionalità della app, semplificandone l’uso: l’interfaccia tende a diventare invisibile, non causa attrito, e l’utente può concentrarsi sullo svolgimento dei compiti che si è prefissato.

Navigazione Theresa Neil sottolinea l’importanza di distinguere con rigore fra tab bar, che contiene gli elementi della navigazione primaria, e tool bar, che contiene gli strumenti di cui l’utente dispone nel contesto di una videata e/o di un contenuto.

La navigazione è primaria ed eventualmente secondaria, persistente (sempre visibile) oppure a scomparsa.

La navigazione persistente orizzontale è indicata in questi casi:

• Gerarchia piatta (voci di pari grado) • Poche voci (tendenzialmente 3 in Android, 5 in iOS) • Esigenza di indicatori di stato (es. presenza di notifiche) • Necessità di visibilità costante e di accesso rapido.

La navigazione persistente verticale è indicata in presenza di un numero maggiore di voci e/o quando le etichette più lunghe o composte da titolo e descrizione di dettaglio. Tuttavia, ruba spazio ai contenuti, soprattutto se le etichette sono lunghe e/o composite (le etichette solo grafiche occuperebbero meno spazio, ma rischiano di non essere chiare).

Theresa Neil raccomanda che la tab selezionata differisca graficamente da quelle non selezionate per indicare all’utente la posizione in cui si trova.

Navigazione a scomparsa:

• Tendenzialmente è laterale, a sinistra. Può essere collocata anche a destra oppure in alto (nel qual caso non deve coprire per intero la videata), mai in basso

• Alla prima apertura della app è opportuno aprire il menu, cosicché l’utente ne scopra l’esistenza. Successivamente, il menu può essere aperto/chiuso mediante un apposito bottone

• Può essere gerarchica e contenere indicatori di stato • Non deve essere scrollabile.

Per navigazione secondaria Theresa Neil intende quella che permette di accedere a voci collocate all’interno di pagine successive alla prima. I pattern della navigazione secondaria coincidono con quelli della navigazione primaria, ma è necessario comunicare chiaramente all’utente l’esistenza di pagine seguenti (es.





3


con scrolling tab da sfogliare orizzontalmente oppure con accordion da espandere/comprimere verticalmente).

Form

Login / Sign-in Nel modulo di login Theresa Neil consiglia di:

• Includere solo i campi per l’inserimento delle credenziali, il bottone Login, un help (es. funzione di recupero delle credenziali) e, se previsto, il link al modulo di registrazione

• Visualizzare la password in chiaro (per facilitarne la verifica da parte dell’utente), offrendo l’opzione per mascherarla

• Valutare l’opportunità di includere funzioni di social login • Nel caso di app meno sensibili (es. non quelle in ambito bancario, finanziario, sanitario, ecc.),

valutare l’opportunità di salvare nelle impostazioni il nome utente alla prima apertura della app, chiedendo per gli accessi successivi il solo inserimento della password.

Il modulo di login va posizionato nel punto in cui è richiesto il passaggio da funzioni/contenuti pubblici a quelli destinati all’utente registrato.

Registrazione Nel modulo di registrazione Theresa Neil consiglia di:

• Non richiedere la conferma dell’inserimento di e-mail e password • Etichettare i campi in modo chiaro, collocando le etichette al di sopra dei campi cui si riferiscono

(anziché a sinistra, per motivi di spazio) • Fornire all’utente feedback in-line in fase di compilazione, anziché al momento della richiesta di

invio del modulo • Visualizzare la password in chiaro (per facilitarne la verifica da parte dell’utente), offrendo l’opzione

per mascherarla • Se un utente già registrato, cioè con un indirizzo e-mail già in uso, tenta di registrarsi nuovamente,

reindirizzarlo alla pagina di login, con opzione di recupero delle credenziali.

I moduli multi-step, fra cui sono da annoverare anche i configuratori, possono presentare ogni passaggio in una videata o in un DIV dedicati, indicando sia il numero complessivo di step previsti, sia il numero dello step a cui si trova l’utente. Funzioni di avanti/indietro permettono all’utente di percorrere i passaggi in modo non lineare. Va prevista una lista delle opzioni selezionate.

Check-out (del Carrello) Per il check-out Theresa Neil consiglia di:

• Prevedere, oltre al login, anche un profilo Guest (Ospite) per gli utenti che non intendono registrarsi, con l’opzione di convertire i dati guest in registrazione a check-out avvenuto





4


• Realizzare una sola pagina di check-out con DIV espandibili per completare le informazioni richieste al completamento dell’acquisto

• Offrire shortcut, es.: riprendere automaticamente dall’account dell’utente informazioni note; proporre vari metodi di pagamento; supportare la funzione di scansione della carta di credito (per rendere l’input più rapido)

• Supportare il check-out rapido per utenti già registrati, che abbiano salvato tutte le informazioni necessarie a completare l’acquisto (es. l’acquisto 1-click proposto da Amazon)

• Innovare, es.: all’interno dei punti vendita Walmart permette al cliente di scansionare i prodotti che desidera acquistare, pagare con carta di credito e saltare quindi la fila alla cassa; all’atto della scansione del prodotto, fornire informazioni su promozioni anche personalizzate per l’utente; nelle vetrine dei negozi (in particolare nei giorni/orari di chiusura) e nelle pubblicità fisiche, inserire QR code che permettano all’utente di scansionare il prodotto e acquistarlo online.

Tabelle A causa degli spazi ridotti, le tabelle sono un punto dolente delle app. Ecco alcuni consigli per migliorarne la fruibilità:

• Le tabelle di base dovrebbero essere caratterizzate da separatori solo orizzontali, intestazioni fisse, righe a lettura facilitatati, allineamento dei dati a sinistra per i testi e a destra per i numeri

• In caso di tabelle senza intestazioni, ogni riga visualizza tutte le informazioni relative a un singolo record, con il dato primario (es. il codice articolo) in evidenza

• In presenza di tabelle composte da numerose colonne, valutare l’opportunità di fissare la prima colonna di sinistra, rendendo le altre scrollabili orizzontalmente. La sfida sta nel comunicare chiaramente all’utente la possibilità di scorrere per accedere ai contenuti delle colonne “nascoste”

• Se la tabella espone dati raggruppabili per sottoinsiemi omogenei (es. anno, categoria merceologica), evidenziare il raggruppamento con un titoletto interno

• Se la tabella espone dati sintetizzabili o visualizzabili sotto forma di diagramma, inserire il sommario/diagramma di sintesi al di sopra della tabella di dettaglio

• Fare attenzione alla leggibilità e a non creare un sovraccarico di informazioni se la tabella include indicatori visuali (es. pittogrammi, diagrammi, ecc.).

Ricerca La ricerca può essere implicita o esplicita.

La ricerca implicita è la proposta proattiva di contenuti in base al profilo dell’utente e al suo contesto operativo (tempo, luogo, azione). Theresa Neil sottolinea che si tratta del trend emergente e che va considerata la prima opzione da valutare. Fra le ricerche implicite può rientrare anche il suggerimento delle ricerche popolari all’interno di una determinata community.

Per realizzare uno strumento di ricerca esplicita efficace, ecco i consigli di Theresa Neil:

• Nelle opzioni di default, includere solo il/i campo/i necessari o più utilizzati





5


• Inserire moduli di ricerca lunghi all’interno di una pagina scrollabile, anziché paginarli • Posizionare i bottoni invia/annulla secondo le specifiche dei diversi SO • Supportare varie modalità di input, oltre a quello testuale, es.: scansione di QR code, bar code o

foto; voce; manipolazione diretta di un oggetto (in particolare di mappe geografiche) • Salvare le ricerche in modo esplicito o consentirne il salvataggio esplicito (salva con nome…) da

parte dell’utente • In fase di input, visualizzare la lista di ricerche rilevanti già effettuate (salvate in modo implicito

dalla app o esplicito dall’utente) • Supportare l’auto-completamento, che gli utenti si aspettano di trovare e che Theresa Neil invita a

considerare ormai uno standard • Assieme all’auto-completamento, supportare anche il filtraggio dinamico, visualizzando via via solo

i risultati rilevanti rispetto all’input dell’utente. Il loading indicator va previsto solo se è vi è il rischio che i risultati siano in ritardo sull’input

• Se la app si articola in sezioni fortemente caratterizzare, valutare l’opzione di supportare la ricerca verticale (scoped search), suggerendo all’utente di selezionare la categoria (es. libri, musica, ecc.) in cui cercare l’espressione inserita. Il numero di categorie proposte dovrebbe essere compreso fra 3 e 5

• I risultati non vanno paginati e, se molto numerosi, visualizzati solo in parte, mentre l’app procede a caricare i restanti (lazy loading)

• Supportare notifiche in-app sulle ricerche esplicite salvate (es. se l’utente ha salvato la ricerca relativa a un prodotto, riceve una notifica in caso di variazione del prezzo o di errata corrige).

Ordinamento Le opzioni di ordinamento possono essere proposte in fase di input dell’espressione da cercare oppure a posteriori, sui risultati. Un’apposita icona permette all’utente di accedere alla lista dei criteri contestuali.

Filtri I filtri sono utili per grandi set di dati per ottenere un numero di risultati inferiore, ma maggiormente rilevanti. Un’apposita icona permette all’utente di accedere alle opzioni.

È opportuno prevedere il filtraggio dinamico, visualizzando via via solo i risultati rilevanti rispetto all’input dell’utente. Il loading indicator va previsto solo se è vi è il rischio che i risultati siano in ritardo sull’input. Va invece sempre prevista una lista dei criteri applicati, con la possibilità di modificarli e resettarli.

In alcuni contesti (es. mappe geografiche), l’input del filtro può essere dato anche dalla manipolazione diretta dell’oggetto.

Strumenti (tool) La tool bar (e l’eventuale tool box che raccoglie sotto-categorie di strumenti) è simile alla tab bar, ma contiene gli strumenti con cui agire sui contenuti della videata corrente.





6


La posizione della tool bar dipende dal SO: in iOS è in basso, in Android in alto (tenendo conto che la action bar contiene però anche gli elementi di navigazione, e che voci del menu e strumenti meno utilizzati vanno inseriti nell’overflow menu a scomparsa, accessibile tramite l’apposito bottone).

Per ragioni di chiarezza, è opportuno che le icone siano provviste di etichetta, eventualmente a scomparsa.

Se, all’interno della videata, l’utente può compiere solo una azione (oppure due azioni di cui una primaria e l’altra secondaria), è opportuno prevedere – anziché la tool bar – uno o due bottoni con call-to-action (CTA) esplicita. I bottoni possono essere contestuali oppure persistenti (collocati tendenzialmente in basso, al centro), se la app è dedicata integralmente al compimento di una sola operazione.

Se lo strumento agisce non a livello di videata, ma di singolo contenuto, il bottone diventa di una “in-line action”. Tendenzialmente si tratta di bottoni a 2 o più stati (es. lo stesso bottone cambia stato passando da “Scarica PDF” ad “Apri PDF” oppure a “Cancella” a “Sei sicuro di voler cancellare?” a “Cancellato”). Studi dimostrano che gli utenti preferiscono interagire con i bottoni multi-stato, anziché con le finestre di dialogo (poiché l’interazione è più immediata e veloce).

Dipendentemente dal tipo di contenuti e operazioni, valutare l’opportunità di supportare azioni bulk, es.: riordinare, cancellare, ecc. tutti gli elementi selezionati.

Diagrammi Ogni diagramma deve raccontare una storia, evidenziando relazioni importanti fra i dati esposti. Se più diagrammi contribuiscono alla narrazione di una storia unica, possono essere collocati all’interno di una dashboard. In questo contesto possono risultare utili le “spark-line”, mini-diagrammi che visualizzano solo le informazioni di base, permettendo di accedere alla versione completa.

Titolo, etichetta degli assi e dati sono gli ingredienti di base di ogni diagramma.

Il tap va supportato per ottenere dettagli su uno specifico data-point, procedendo eventualmente anche per approfondimenti successivi.

Nel caso di diagrammi a estensione orizzontale, è opportuno supportare la rotazione dello schermo per vederne meglio i contenuti, nonché le consuete funzioni di pinch e pan per zoomare e navigare il diagramma.

Feedback Theresa Neil suggerisce che:

• I messaggi di errore siano ben visibili, chiari all’utente tipico della app e proporre una soluzione. Nella compilazione dei moduli è preferibile prevenire gli errori, fornendo all’utente feedback in-line, mentre sta compilando il modulo





7


• I messaggi di conferma siano limitati per azioni critiche e visualizzati in modo tale da interrompere il meno possibile il flusso di lavoro (es. mediante messaggi “toast”, che scompaiono automaticamente dopo 5 secondi o meno)

• I messaggi di stato del sistema siano incentrati sulla comunicazione del progresso verso l’obiettivo, non sull’attesa in sé. Valutare l’uso di “skeleton screen”, i cui contenuti si caricano via via, a partire da quelli più leggeri (l’utente non deve attendere il caricamento di tutti i contenuti per iniziarne la fruizione).

Affordance Si tratta degli stilemi grafici convenzionali, anche specifici per ogni SO, che indicano all’utente che è possibile fare tap su un elemento, sfogliare una pagina, scrollare una videata, trascinare o zoomare un oggetto, ecc.

Le invitation, particolari tipi di help contestuali, possono aiutare l’utente a scoprire funzioni nuove e/o avanzate presenti sulla videata o sul contenuto. Le invitation possono essere persistenti (visualizzate finché l’utente non compie l’operazione suggerita) oppure a scomparsa. Per essere percepita positivamente dagli utenti, ogni invitation deve essere contestuale e specifica, concentrandosi su un solo topic.

Help Theresa Neil passa in rassegna i vari tipi di help:

• How-to per illustrare step-by-step i passaggi delle procedure operative • Manuale/help online: più approfondito e da organizzare per topic. Dovrebbe essere contestuale al

compito che l’utente sta cercando di portare a termine • FAQ: raccolta di coppie domanda/risposta basate sui quesiti reali degli utenti e organizzate in base

alle reali priorità • Tutorial: studi dimostrano che, di tutti quelli sopra elencati, è quello meno sgradito agli utenti,

poiché possono imparare facendo e, se possibile, divertendosi • Valutare l’opportunità di integrare User Feedback Tools, come User Voice o Get Satisfaction, che

rendono facile catturare il feedback degli utenti, basilare per il miglioramento continuo della app.

Theresa Neil sottolinea che le guide non sono generalmente bene accette, ma fornisce alcuni consigli per realizzarle al meglio in caso di necessità. Esse:

• Non devono caricarsi automaticamente alla prima apertura della app • Devono privilegiare interazione e multimedialità all’esposizione testuale, ed essere quindi

improntate al learning by doing e, se applicabile, alla gamification • Devono essere contestuali • Vanno integrate nella progettazione della app e sottoposte a miglioramento continuo, basato sul

feedback degli utenti.





8


Anti-pattern Fra gli esempi negativi da non seguire spiccano:

• Elementi dell’interfaccia grafica non standard per il tipo di applicazione (app, web, desktop) e per il SO, esposti nelle linee guida ufficiali

• Introdurre elementi di complessità a discapito dell’efficienza con cui l’utente può portare a termine il suo compito

• Scegliere la metafora errata a livello di applicazione (non corrispondente allo schema mentale dell’utente tipico) e/o di interfaccia

• Inserire finestre di dialogo inutili, che interrompono il flusso di lavoro dell’utente (es. richieste di conferma su azioni non critiche)

• Introdurre nei diagrammi ornamenti grafici non funzionali alla comprensione dei dati • Portare la app dalla piattaforma originaria a un’altra piattaforma, senza “localizzarne” l’interfaccia.

Autore: Petra Dal Santo – KEA S.r.l. ([email protected])





Comunicazione tecnica e di prodotto: design per il mobile

Mobile

Transcript of Comunicazione tecnica e di prodotto: design per il mobile