[UI] Software per la realizzazione di mockup per l’UI presentation

I mockup sono utili per capire cosa effettivamente vogliono i vostri clienti e per farsi una prima idea di progettazione della User Interface, sia essa web o mobile.
Infatti, è partendo da una rappresentazione grafica, magari di impatto, che il cliente riesce a “toccare con mano” ciò che vuole e su cui si può anche condurre una intervista per la raccolta dei requisiti di business.

Spesso si confondono le definizioni di mockup, wireframe e prototype; ecco un ottimo articolo che ne chiarisce le differenze: WireFrame, Prototype e Mockup – Dove sta la differenza.

Dunque, per la presentazione di mockup di una vostra applicazione, vi consiglio di utilizzare alcuni software, semplici ed immediati (alcuni li trovate negli articoli linkati in seguito in “Riferimenti utili”).

Per la realizzazione di un “concept” preliminare della user experience, capire dove posizionare gli elementi grafici sulle vostre pagine e come impostare la navigazione, è consigliabile realizzare un primo prototipo “statico” con Balsamiq Mockup. Questo utile software, free per il primo mese, ma accessibile come prezzo nella sua versione completa, vi permette di creare in pochi passi le varie schermate, mettendovi a disposizione dei widget abbastanza comuni nelle nuove applicazioni, sia web che mobile. Il risultato sarà un mockup statico, da esportare in PDF o in formato immagine.

20140216-204721.jpg

Esiste anche una ricca collezione di template condivisi da altri web designer e che potete consultare qui: MockupToGo Balsamiq.

Se la grafica dell’applicazione non è molto complessa, potete addirittura esportare il tutto in HTML, utilizzando un altro software, ossia Napkee. Quest’ultimo prende in input i sorgenti di Balsamiq ed esporta il tutto in formato HTML, generando anche i CSS e i Javascript e fornendo un minimo di interattività per alcuni componenti (come tab, accordion, select, link, ecc.). I risultati non sempre sono ottimi, anche perché Napkee è ancora in versione alfa. Può essere utile per pagine semplici e potete comunque agire su HTML e CSS/Javascript generati, modificandoli a mano.
Purtroppo, al momento si può soltanto partire dal sorgente statico Balsamiq, importarlo in Napkee e generare gli HTML, ma non il contrario.

Se il mockup statico non basta e vi occorre realizzare un prototipo interattivo più complesso (prototype), allora smanettate a livello di codice. Cercate qualche libreria di stile, come Metro UI, set di widget in stile Windows 8, che utilizza Bootstrap e JQuery.

20140216-205423.jpg

 

Riferimenti utili:

Principi di buon design per progettare oggetti semplici e di facile uso

Caffettiera del masochista

“Quando cose semplici hanno bisogno di istruzioni per l’uso, è segno di un cattivo design.”

Una frase tratta da un saggio di scienze umane e un manuale indispensabile per il progettista. Questo è il libro di Donald A. NormanLa caffettiera del masochista – psicopatologia degli oggetti quotidiani“. Una riflessione sulla cattiva progettazione di oggetti che utilizziamo nella vita quotidiana, ma che ormai siamo abituati a maneggiare nel modo in cui ci è stato imposto e che spesso creano ripetute frustrazioni. Consigli su come evitare di commettere gli stessi sbagli quando li si realizza. Lettura indispensabile e mattone fondamentale per chi si occupa di design, di qualsiasi tipologia di oggetto, tangibile e non, reale o virtuale che sia. Si parla di psicologia dell’interazione tra persone e oggetti e di quella che è detta filosofia dei sistemi centrati sull’utente, di cui trovate un’altra mia riflessione qui: User-centered design: progettare considerando i bisogni degli utenti.  

La progettazione è l’applicazione successiva di vincoli e limitazioni finché quello che rimane è un prodotto unico.

La tesi centrale del libro è, appunto, quella di propugnare un design centrato sull’utente, una filosofia progettuale basata sui suoi bisogni edi interessi, che miri alla realizzazione di prodotti usabili e comprensibili.

“La gente si sente in colpa quando non riesce a usare le cose semplici, colpa che non è sua ma piuttosto dei progettisti e produttori degli oggetti”

Comics Easy to use

La colpa di una cattiva progettazione è dell’industrializzazione. Secondo Norman, lo studio del design degli oggetti è indissolubilmente legato a quello del funzionamento della mente umana (human information processing). Spesso vengono trascurati gli aspetti “naturali” e la rilevanza pratica, considerando soltanto quelli legati al fattore economico, alla semplicità nella produzione (come avviene in ambito industriale) e alla velocità di distribuzione sul mercato.  La maggior parte della colpa di una cattiva progettazione è dovuta proprio all’industrializzazione: le aziende vogliono qualcosa che possa essere prodotto in poco tempo e a basso costo.

Un progettista che si lascia influenzare da tali aspetti, si perde in dettagli inessenziali, dimentico dell’obiettivo a cui l’oggetto è destinato e “violenta” il normale processo di comprensione ed interpretazione delle procedure d’uso da parte degli utenti finali.

La colpa all’incentivazione della mal progettazione è anche nostra, perché se la gente continua ad acquistare prodotti progettati male, industriali e progettisti penseranno di aver fatto bene e continueranno a produrre le cose allo stesso modo.

 

Tenere conto di vincoli, condizioni ed istruzioni semplici. Quando si costruiscono gli oggetti occorre tenere imprescindibilmente in conto i vincoli ambientali e le condizioni d’uso, rendere le istruzioni semplici per l’utilizzatore finale, in modo da creare un prodotto pratico e semplice. E ancora, secondo Norman, la maggior parte degli errori che vengono commessi dall’uomo quotidianamente è dovuta ad una cattiva progettazione degli oggetti che utilizzano.

Un esempio emblematico è quello della porta: per capire come aprire una porta, le parti giuste devono essere visibili e devono trasmettere un giusto messaggio (i cosiddetti “segnali naturali“), come i cardini, la maniglia e il sostegno. Dove l’oggetto non è semplice da utilizzare, le istruzioni devono essere comprensibili e semplici. Inoltre, l’attenzione all’estetica può rendere cieco il progettista (e l’acquirente) alla scarsa funzionalità.

Affordance

Affordance degli oggetti. Indica le proprietà reali e percepite delle cose materiali che determinano come si potrebbe verosimilmente usare un oggetto in questione. Per esempio, quando vediamo una porta in vetro, è dallo spessore della maniglia che possiamo percepire quanta forza occorre applicare per poterla aprire.

Altra regola fondamentale: le cose complesse possono richiedere spiegazioni, ma quelle semplici non dovrebbero averne bisogno. Quando una cosa semplice esige figure, scritte o istruzioni, vuol dire che il design è sbagliato. E’ il progettista che deve essere abile a rendere chiaro il funzionamento della sua “creatura”, tenendo in considerazione la psicologia umana, ossia come un utente può desumere per proprio conto come “muoversi” (grazie ad una esperienza personale di come funzionano le cose del mondo esterno).

 

Principi di design per la comprensibilità e l’usabilità. Due sono i principi fondamentali per una buona progettazione:

  1. fornire un buon modello concettuale, grazie al quale possiamo prevedere gli effetti delle nostre azioni mentre utilizziamo un oggetto
  2. rendere visibili le cose. Il principio di visibilità è, secondo Norman, continuamente contraddetto negli oggetti quotidiani e, in molti schemi costruttivi, le parti cruciali sono accuratamente occultate.

Rendere le parti di un oggetto visibili, per renderne facile l’utilizzo. Ma non inserire troppe di queste parti, altrimenti l’oggetto stesso diventerebbe troppo complesso. Inoltre, l’affidamento eccessivo agli automatismi, può annullare la capacità di cavarsela in loro assenza.

Conceptual Models NormanPer capire la figura precedente, riporto la didascalia riportata nel libro, che ci fa ben capire qual è il “gap” che separa il progettista dall’utente finale.

“Il progettista deve costruire preventivamente un modello concettuale dell’oggetto, che dal suo punto di vista è detto modello progettuale, immaginando gli effetti e come gli utenti potrebbero utilizzare il suo prodotto e trarne beneficio. Il modello dell’utente è il modello mentale sviluppato attraverso l’interazione con il sistema. L’immagine del sistema risulta dalla struttura fisica che è stata costruita (compresa documentazione, istruzioni, etichette, ecc.). Il progettista si aspetta che il modello dell’utente sia identico al modello progettuale. Ma non parla direttamente con l’utente, visto che la comunicazione avviene attraverso l’immagine del sistema. Se l’immagine del sistema non rende chiaro e coerente il modello progettuale, l’utente finirà per formarsi un modello mentale sbagliato. ”

 

Mapping e feedback. Ecco altri principi a cui occorre rifarsi per una buona progettazione:

  • Mapping: indica la relazione fra i comandi previsti per un oggetto e i risultati che ne derivano nel mondo esterno. In pratica, occorre stare attenti a non inserire troppi comandi nel nostro oggetto e fare in modo che ad ognuno di essi sia associato un determinato comportamento/effetto. Evitare le combinazioni di comandi, altrimenti all’utente risulterà complicato eseguire determinate operazioni. Infatti, quando il numero delle funzioni e operazioni richieste eccede il numero dei comandi, il progetto diventa arbitrario, innaturale e complicato. Si rende così il dispositivo più difficile da usare ed imparare.
  • Feedback: indica l’informazione di ritorno che dice all’utente quale azione ha effettivamente eseguito, quale risultato si è realizzato, dandogliene un effetto e riscontro immediato e facendolo entrare in sintonia con l’oggetto.

Rispettando tali principi, l’utente può: 1) indovinare il da farsi, 2) capire che cosa sta succedendo, interpretando lo stato del sistema.

Per semplificare il processo di apprendimento ed interpretazione, avrebbe senso standardizzare tutta una serie di procedure che l’utente è abituato ad eseguire quotidianamente quando utilizza oggetti destinati allo stesso compito. Purtroppo, quest’ultimo punto è di difficile attuazione, visto che occorrerebbe mettere d’accordo i vari produttori.

 

Come può il design segnalare le azioni appropriate? Un insieme importante di segnali ci arriva attraverso i vincoli naturali degli oggetti, vincoli fisici che limitano le possibilità di azione. Un altro insieme di segnali viene da quelle che abbiamo chiamato affordance, gli inviti forniti dagli oggetti, che trasmettono messaggi circa i loro possibili usi, azioni e funzioni. Gli inviti d’uso suggeriscono la gamma delle possibilità, i vincoli limitano il numero delle alternative. L’uso intelligente di inviti e vincoli d’uso combinati nella progettazione fa sì che l’utente possa determinare prontamente il corso esatto delle azioni anche in una situazione del tutto nuova.

Dunque, per far sì che l’utente sappia cosa fare quando utilizzare l’oggetto occorre “imporre” i seguenti vincoli:

  • Vincoli fisici: sono i più utili ed efficaci perché sono facili da vedere e interpretare, e limitano l’insieme delle azioni prima ancora di eseguirle.
  • Vincoli semantici: si affidano al significato della situazione per circoscrivere l’insieme delle azioni possibili, basandosi sulla conoscenza del mondo e della situazione stessa.
  • Vincoli culturali: sono vincoli “imposti” da convenzioni culturali accettate. Ogni cultura ha un insieme di azioni permesse in varie situazioni sociali e gli oggetti devono rispettare degli “obblighi” culturali.
  • Vincoli logici: quando si crea un rapporto logico fra la disposizione spaziale o funzionale dei componenti e le cose da questi controllate (o da cui queste dipendono).

 

Evitare gli errori. I progettisti devono essere attenti affinché gli errori possibili non comportino gravi conseguenze.

Se un errore è possibile, qualcuno prima o poi lo farà. Il progettista deve partire dal presupposto che tutti i possibili errori saranno commessi e impostare il progetto in modo da ridurre al minimo le probabilità di errore in primo luogo, o i suoi effetti una volta che esso sia verificato. Gli errori devono essere facili da individuare, devono avere conseguenze minime e, se possibile, i loro effetti devono essere reversibili.

Per far ciò, occorre focalizzarsi sullo scopo dell’oggetto, sugli effetti che realizzerà nel mondo esterno e verificare tali effetti. In sintesi, occorre effettuare una esecuzionevalutazione degli effetti (ciclo dell’azione).

Human Error

Progettare in vista dell’errore. Il progettista fa lo sbaglio di non tener conto dell’errore. Ma ecco la prassi che dovrebbe seguire:

  1. Capire le cause di errore e impostare il progetto in modo da ridurle al minimo
  2. Rendere le azioni reversibili – dare la possibilità di annullare il già fatto – o rendere più difficili le azioni irreversibili
  3. Facilitare la scoperta degli errori che comunque avvengono e renderne più facile la correzione
  4. Cambiare l’atteggiamento verso gli errori. Pensare l’utente come una persona che cerca di eseguire un compito e che ci arriva attraverso approssimazioni. Non pensarlo come un soggetto che commette errori: pensare piuttosto le azioni che esegue come approssimazioni di quanto richiesto.

Si deve progettare il sistema in modo tale che ci sia un margine di errore, consapevoli che il comportamento normale non è sempre esatto. Il progetto dev’essere tale che gli errori siano facili da scoprire e suscettibili di correzioni.

Spesso per attuare quanto detto poc’anzi è indispensabili prevedere delle funzioni obbliganti, ossia una forma di vincolo fisico che “guidano” le azioni in modo tale che la mancata esecuzione di un passaggio impedisca il successivo, come per esempio:

  • interlock: obbliga le varie operazioni ad essere eseguite nella sequenza corretta
  • lockout:  dispositivo che impedisce certi comportamenti, come l’entrata in un ambiente pericoloso
  • lockin: mantiene in funzione un apparecchio, impedendo che qualcuno lo fermi prematuramente.

Un buon design esige spesso una funzione obbligante per minimizzare gli errori.

Consiglio. Partire dal presupposto che prima o poi ogni possibile contrattempo accadrà, e quindi prendere le giuste contromisure. Occorre far sì che le azioni siano reversibili.

 

L’evoluzione naturale del design. Un progetto non rimane inalterato durante il suo ciclo di vita. Anzi, si scoprono e si modificano suoi problemi e difetti in corso d’opera, a seconda del tempo, dell’energia e delle risorse a disposizione. E’ ovvio che l’obiettivo dell’evoluzione è quella di correggere gli aspetti negativi e di lasciare inalterati quelli positivi (“ascensione“).

Una forza negativa è esercitata dalle esigenze di tempo: i nuovi modelli sono già in progettazione prima ancora che i vecchi siano stati consegnati. Inoltre, raramente esistono meccanismi per raccogliere le esperienze della clientela e farne tesoro. Un’altra forza è il bisogno di distinguersi, di creare modelli che appaiano diversi da tutto quanto c’è stato prima. Sono rarissime le aziende che si accontentano di mantenere in produzione così com’è un prodotto valido, o che lo lasciano perfezionare lentamente dall’evoluzione naturale. No, ogni anno deve uscire un modello “nuovo, migliorato”, di solito corredato di nuove caratteristiche che non prendono le mosse dal modello precedente. In troppi casi i risultati sono disastrosi per il consumatore.

Una volta ottenuto un prodotto soddisfacente, ulteriori cambiamenti possono essere controproducenti, specialmente se il prodotto ha successo così com’è. Bisogna sapere quando è il momento di fermarsi.

 

Il progettista: un utente atipico. Spesso il progettista considera se stesso un utente tipico del suo oggetto. Tuttavia, spesso non “vede” tutti gli aspetti degli utenti reali, o meglio, conosce già come funziona il suo oggetto, dando per scontato che anche gli altri possano comprenderlo. Una regola di base della progettazione è di conoscere e studiare i reali utenti, a partire dalle prime fasi del progetto stesso, alfine di evitare di apportare cambiamenti radicali all’oggetto alla fine dello sviluppo. C’è differenza tra la competenza richiesta per progettare un oggetto e quella necessaria ad usarlo.

“Nel loro lavoro, i progettisti spesso finiscono per diventare degli esperti del dispositivo al quale stanno lavorando. Gli utenti spesso sono invece esperti del compito da eseguire mediante quel dispositivo”

Altra difficoltà è data dal fatto che spesso i clienti del progettista possono non essere gli utenti del prodotto. In tal caso, un cattivo design è spesso sintomo dell’attenzione ai costi, senza prendere in considerazione la facilità di uso.

 

Sette principi per trasformare compiti difficili in compiti facili. Ricapitolando, sulla base di quanto su scritto, ecco i 7 principi per una buona progettazione degli oggetti quotidiani:

  1. Usare sia la conoscenza presente nel mondo esterno che la conoscenza interiorizzata
  2. semplificare la struttura dei compiti
  3. rendere visibili le cose
  4. impostare bene le correlazioni
  5. sfruttare i vincoli, sia naturali che artificiali
  6. lasciare un margine di errore
  7. quando tutto il resto non serve, standardizzare

La caffettiera del masochista

User-centered design: progettare considerando i bisogni degli utenti

Semplicemente stupendo il libro che sto leggendo e di cui scriverò in questi giorni una sintesi su questo blog. Il libro è di Donald A. Norman e si intitola La caffettieria del masochistaRiporto un suo estratto che si collega ad una considerazione personale che avevo pensato di scrivere nei giorni scorsi.

comic-ease-of-use

Questa è una sorta di autocritica per chi come me si occupa di progettazione e sviluppo di software. Ecco il passo del libro in questione:

“Ma i progettisti sembrano particolarmente dimentichi dei bisogni degli utenti, particolarmente inclini a cadere in tutti i trabocchetti del design. Gli specialisti del design non sono interpellati quasi mai per questo tipo di prodotti. La progettazione è lasciata invece tutta nelle mani di ingegneri e programmatori, persone che di solito non hanno alcuna esperienza né competenza specialistica nel campo del design.

Il carattere astratto del computer propone una sfida tutta particolare. Il funzionamento è elettronico, invisibile, senza alcun segno esterno delle azioni che vengono eseguite. E i comandi vengono impartiti mediante un linguaggio astratto, un linguaggio che specifica il flusso interno dell’informazione, con le relative istruzioni, ma che non è particolarmente tagliato a misura dei bisogni dell’utente.

I programmatori specializzati lavorano su questi linguaggi  per impartire al sistema le istruzioni necessarie per eseguire le operazioni richieste. E’ un compito complesso e i programmatori devono possedere un ampio repertorio di competenze e talenti naturali. La messa a punto di un programma esige infatti una combinazione di capacità specialistiche, della preparazione tecnica della conoscenza del compito, fino alla cognizione delle esigenze e delle capacità degli utenti.

Ai programmatori non dovrebbe essere addossata la responsabilità delle interazioni tra la macchina e gli utenti:non ne hanno la competenza specialistica, né dovrebbero averla. Molti dei programmi esistenti per le applicazioni da parte degli utenti di base sono troppo astratti, richiedendo manovre che hanno un senso per le esigenze del computer – e agli occhi dello specialista di computer – ma non sono coerenti, ragionevoli, necessarie o comprensibili per l’utilizzatore normale. Per rendere il sistema più facile da usare e capire ci vuole una gran quantità di lavoro in più. I programmatori hanno tutta la mia comprensione, ma tuttavia non posso scusare il generale disinteresse per i problemi degli utenti. ”

 

E ancora condivido la considerazione di Norman sulla poca presenza nei programmi universitari di materie relative all’usabilità e alla progettazione “usercentric” dei sistemi, non solo informativi. Il cosiddetto user-centered design.

” La scienza del computer ha lavorato finora allo sviluppo di potenti linguaggi di programmazione che permettono di risolvere i problemi tecnici di calcolo. Deboli sforzi sono stati compiuti in direzione di efficaci linguaggi interattivi. Ogni studente di un corso per programmatori viene istruito sugli aspetti computazionali dei computer, mentre sono rarissime invece le lezioni sui problemi che si pongono all’utente. In generale questo tipo di insegnamento non è richiesto nei piani di studio, né peraltro sarebbe facile fargli posto negli orari già fittissimi e massacranti cui devono sottoporsi gli studenti d’informatica. Il risultato è che la maggior parte dei programmatori sa scrivere programmi capaci di eseguire operazioni mirabili, ma inutilizzabili per chi non è uno specialistica del ramo. Quasi nessuno di loro pensa ai problemi che deve affrontare l’utilizzatore. Da qui la sincera sorpresa che li coglie quando scoprono che le loro creazioni sottopongono l’utente comune a una dispotica tirannia.”

 

E’ importante lavorare con persone creative. Ho conosciuto professionisti capaci di applicare principi di buon design e di usabilità nella progettazione di software, sia web che mobile. Dai grafici attenti a questi principi si impara e si trae una esperienza professionale positiva, oltre a produrre software di buona qualità e piacevole per l’utente.

La cosiddetta user experience merita un’attenzione particolare; dovrebbe essere un processo a parte nello sviluppo del software. Specie nelle società ICT italiane, spesso si confondono le figure di progettista, analista, sviluppatore, oltre a non esistere quelle di graphic o user experience designer. Ma per mantenere alto il livello di qualità e competitività del prodotto, occorre essere coscienti della forte specializzazione delle competenze da mettere in gioco.

Cito due massime efficaci per trarre le seguenti conclusioni:

  1. Chi nasce tondo, non muore quadrato” – dividiamo le competenze e le responsabilità delle figure coinvolte in un progetto.  Ognuno faccia il proprio mestiere, senza confondere le professionalità. Dalla interazione di queste professionalità, nasce il buon presupposto per realizzare un prodotto di successo.
  2. Lo sparagno (cit. risparmio) è mal guadagno” – il cosiddetto “triplo vincolo” di un progetto (costo, tempo, qualità), andrebbe spostato sempre più in direzione della qualità. Per far ciò occorre dotarsi di figure competenti per coprire i vari ambiti della progettazione software (analisti, grafici, sviluppatori, progettisti, ecc.). Provate a far fare ad uno sviluppatore la grafica, nella maggior parte dei casi produrrà qualcosa di poco piacevole ed usabile per l’utente finale.