Articoli della categoria 'interaction design' ↓

Le 5 metriche di usabilità - come citate nel sito useit da Jacob Nielsen nel 1997 - sono:

• Apprendibilità: quanto è facile per gli utenti portare a termine compiti di base la prima volta che si trovano di fronte all’interfaccia?
• Efficienza: Una volta che gli utenti hanno appreso l’itnerfaccia, quanto rapidamente riescono a eseguire dei compiti?
• Memorabilità: Quando gli utenti tornano all’interfaccia dopo un periodo di inutilizzo, quanto gli è facile usarla di nuovo in modo efficiente?
• Errori: Quanti errori fanno gli utenti, quanto sono gravi, e quanto facilmente possono ritornare alla situazione precedente?
• Soddisfazione: Quanto è piacevole usare l’interfaccia?

Unitamente a queste possiamo considerarne altre 7 - ISO 9241- 110:2006 (Ergonomic requirements for office work with visual display terminals):

• Adeguatezza al compito: le informazioni e i comandi necessari per l esecuzione delle azioni da parte
  dell utente devono essere sempre disponibili e percettibili
• Autodescrittività: le informazioni e i comandi necessari per l esecuzione delle azioni devono essere facili da capire e da usare
• Conformità alle aspettative dell’utente: stessi simboli, messaggi e azioni devono avere gli stessi significati in tutta l’interfaccia
• Controllabilità: l’interfaccia deve comunicare il suo stato e gli effetti delle azioni compiute (quello che Norman chiama golfo dell’esecuzione e golfo della valutazione);
• Adeguatezza alla personalizzazione: l’interfaccia deve tener conto di profilature individuali e di differenti contesti d’uso
• Tolleranza degli errori
• Adeguatezza all’apprendimento

Questo articolo è in risposta a quanto scritto da Sefano qui.

Innazitutto credo fermamente che la metodologia agile sia applicabile a progetti Web, e concordo con quanto scritto da Stefano sul fatto che questa vada adattata, essendo il contesto e gli attori differenti.

Il team degli sviluppatori nell’agile classico viene sostituito dal team nella sua interezza, dal team agile UX: programmatori, web writer, information interaction designer, graphic designer, SEO specialist, …

Quando si pensa a chi è il constraint sul progetto, il collo di bottiglia, si deve pensare a tutto il team, non solo ai programmatori.

Per quanto riguarda la “pubblicazione” del sito, anche nella metodologia Agile classica si fa riferimento al MMF: Minimum Marketable Features, ovvero il minimo insieme di funzionalità che il prodotto deve avere prima di essere lanciato sul mercato. Non è vero che dopo il primo sprint si ha sempre un qualcosa che possa diventare pubblico. Anzi. Nell’Agile UX questo corrisponde al minimo set di funzionalità che rendono un sito pubblicabile, anche se in versione alpha o beta.

Per quanto riguarda la progettazione dell’architettura dell’informazione ritengo sufficiente una mappa del sito e dei flowchart che mostrino quali sono le azioni da fare per portare a compimento i processi/task principali. Fatte queste, per ogni sprint si creano wireframes e mock-up da condividere con il team e con il cliente. L’approvazione del cliente è determinante. Mock-up ben fatti salvano un sacco di tempo al team e permettono di fare test di usabilità. Non importa che il cliente veda del software funzionante quando può avere un prototipo che fa la stessa cosa. In questo mi dissocio dall’approccio Agile che dice “niente documentazione solo software funzionante”, ma non perchè sia contrario all’idea, ma perchè semplicemente lo scenario qui è diverso.

Il coinvolgimento del cliente, anche 30 minuti alla settimana, è fondamentale e irrinunciabile. E’ col cliente che si fa il planning game, che si introducono nuove storie, ed eventualmente se ne tolgono altre, perchè tutto il lavoro deve essere fatto in un timebox ben determinato. Al cliente bisogna spiegare che per ogni nuovo story point che entra nel progetto ne deve uscire uno tra quelli già pianificati (magari senza spaccare il capello…).

Per quanto riguarda i test di usabilità parafrasando Jakob Nielsen si può dire che è comunque sempre meglio testare un utente 10 minuti che non testare affatto. Credo che 10 minuti li si possa trovare tutti.

Grazie Stefano per l’ottimo articolo!

Due colleghi in pair programming

User Experience 2008 - 16 Nov

Un breve rissunto della giornata, per chi non c’era.

Relatori: Jakob Nielsen, Hoa Loranger and Kara Pernice

Introduzione

Un po’ di consigli utili in base agli ultimi studi di ricerca. Buona notizia è che l’usabilità dei siti migliora di anno in anno sia come percentuale di task completati con successo sia come tempo impiegato per concluderli.

Nell’89% dei casi (fonte: User Experience 2008) gli utenti cominciano la propria navigazione da un motore di ricerca. Il 25% delle volte da qui raggiungono la home page, il 75%  una pagina interna. Questi dati rivelano una diminuita preponderanza della home page sulle altre pagine del sito; ne segue che ancora maggior attenzione vada posta nella progettazione delle pagine interne.

Sui motori id ircerca il 95% degli utenti non procede oltre la prima pagina (i primi 10 risultati, di solito), e solo il 48% scolla la pagina per vedere i risultati non immediatamente visibili (fonte: User Experience 2008).

E’ aumentato l’uso della scrollbar: nel 70% dei casi gli utenti scoprono altro contenuto se la pagina è più lunga dello schermo (fonte: User Experience 2008).

La lunghezza delle stringhe di ricerca nell’ 82% dei casi è inferiore ai 30 caratteri, con una prevalenza - moda - di 18/21 caratteri. Jakob Nielsen consiglia vivamente di lasciare abbastanza spazio affichè l’utente possa leggere per intero tutto quanto viene scritto nel box di ricerca.

E infine la borsa: il valore di un utente:

• 1.31$ se proviene da da motori di ricerca, risutati organici
• 1.91$ se viene da un link sponsorizzato
• $5.69 se raggiunge il sito scrivendo l’indirizzo o richiamandolo dal bookmark

Fidelizzare gli utenti sembra essere un buon investimento.

L’usabilità dei contenuti

Grande enfasi è stata posta sui contenuti e la posizione dell’utente al centro, invece che l’azienda che costruisce/finanzia il sito, nelle scelte di design. Questo porta a ragionare come l’utente e fornire contenuti a lei utili all’utente (vedi task analysis & flow), usando un linguaggio comprensibile, scrivendo frasi brevi, e senza essere autocelebrativi. In modo particolare i relatori sono soffermati sui seguenti elementi di interfaccia:

1. link e titoli
2. testi
3. immagini
4. messaggi di errore

Il testo dei link o dei titoli deve essere una promessa fatta all’utente: deve raccontare cosa “succede poi”, deve permettere all’utente di predire cosa stia dall’altra parte del link o quale sia il contenuto di ciò che segue un titolo. In passato ho letto spesso che “click here” è cattivo design, oggi Jakob Nielsen ha affermato che “more…” e “read more…” lo sono altrettanto. Gli oggetti prominenti dovrebbero essere cliccabili. L’area di click il più grossa possibile. Ovviamente per Nielsen i link sono blu e sottolineati, ma con gli anni si è ammorbidito e oggi accetta anche link non blu. Purchè sottolineati.

I testi devono essere formattati, possibilmente non usare parole inutili o complesse. La Nielsen Norman Group ci ricorda che poco meno della metà degli utenti Web (per l’esattezza il 43% - fonte: User Experience 2008) hanno una scolarizzazione non sufficiente per:

• sintetizzare informazioni contenute su più pagine
• confrontare informazioni complesse (es. le caratteristiche di diverse carte di credito)
• determinare causa ed effetto
• riconoscere lo scopo dell’autore

Inoltre, nella scrittura dei testi, è importante sapere che le persone leggono tipicamente:

• le prime due parole del titolo
• i primi due elementi di una lista
• le prime due riche di una pagina o di un paragrafo
• i due primi risultati di tornati da un motore di ricerca

se non trovano ciò che cercano passano oltre. Questa viene chiamata la regola del 2.

Altro punto fondamentale è la consitenza della struttura tra contenuti omogenei. Quindi se state ad esempio decidendo per struttura delle pagine che descrive i corsi della User Experience 2008, per esempio “Fundamental Guidelines for Web Usability“, allora potete optare per: what you will learn, course outline, format, handouts, who should attend, …

Le immagini hanno un ruolo importante. Così come il testo deve avere un buon contrasto con lo sfondo, le immagini devono risaltare il prorio messaggio. Interessante scoprire che siamo interessati (rivelazioni fornite da test fatti con eyetracking) alle immagini di altre persone, specialmente volti sorridenti che guardano direttamente in camera, e tendiamo a focalizzare lo sguardo in particolare sulle parti intime. Anche degli animali :-O

Le immagini devono comunicare, invece che essere delle blande risposte alla richiesta fatta al team di designer: “questo sito è triste, mettete un po’ di immagini per renderlo cool“.

I messaggi d’errore vanno posti vicini all’errore. Un indizio dovrebbe essere dato vicino a dove l’utente ha cliccato per procedere. I messaggi devono essere ben visibili e aiutare l’utente a risolvere l’errore. Se fosse possibile poi far si che non sembrino scritti da un automa (”errore: nome utente non valido”, con voce metallica) tanto di guadagnato.

Task analysis & flow

L’altro argomento importante affrontato oggi è come guidare l’utente attraverso una serie di decisioni, ovvero come farlo navigare sul nostro sito. Innanzi tutto bisogna iniziare a capire quali sono i bisogni dell’utente e formularli come se fossero compiti da svolgere (task). Fatta una lista di questi si va a lavorare in modo particolare su quelli che interessano anche a noi, ovvero a chi commissiona il sito.

Due esempi portati sono stati www.cheese.com e www.robbinsbros.com, rispettivamente un sito sui formaggi e uno sugli anelli di fidanzamento. In entrabe i casi è stato fatto notare l’ottimo lavoro fatto per cercare di capire come guidare l’utente nella scelta.

Altro ottimo lavoro è la homepage di jetblue dove non compaiono informazioni inutili e frasi autocelebrative, e gli utenti possono immediatamente iniziare a fare quello per cui sono arrivati. Anche la scelta del posto a sedere è estremamente intuitiva e inserita nel flusso di navigazione.

La regola dei tre click invece è una “cagata pazzesca” come direbbe Fantozzi. Inizialmente era stata data come regola generale per cercare di limitare i danni dovuti a un cattivo design. Il KPI (Key Performance Indicator) corretto non è quanti click fa l’utente per completare il task, ma quanto costa, in termini di sforzo mentale e di tempo, la catena dei click.

Il tempo speso in una navigazione per lo shopping online, nel caso di acquisto emozionale di prodotti, per una desired exploration del sito, non conta in termini di sforzo mentale: è un piacere.

I click fatti per rivelare nuovi elementi di interfaccia quando occorrono, non vengono percepiti come frustranti dagli utenti che navigano, ma forniscono una progressive disclosure delle informazioni, che compaiono al momento giusto.

Standard

Jakob Nielsen riprende la parola in chiusura e ci ricorda di seguire gli standard e ci parla di innovazione. Utilizzare gli standard porta ad avere utenti che si sono a proprio agio, senza stare a reinventare la ruota tutte le volte. Gli utenti vogliono trovare le cose nei posti dove sono soliti trovarle, beneficiando di una consistenza sia all’interno del singolo sito, sia tra altri siti analoghi.

Nielsen racconta alcuni siti e fornisce un po’ di esempi. Un sano ripasso: “il box di ricerca in alto a destra, fatto solo di un campo per il testo e il bottone Cerca. Anche Vai va bene ma Cerca è meglio…”. Diciamo maestrino e un po’conservatore sul finale.

Mi sorprendono infatti le slide sull’innovazione, anche se anticipate dall’ammonizione “Pioneering can be Dangerous Business“.

Innovazione descritta con due equazioni:

1. new designs + usable = become standard
2. new designs + unusable = expire

Proprio come avviene per le lingue: un nuovo termine (innovazione) inizia a diffondersi; i più lo trovano utile e lo comprendono; questo crea un nuovo standard che diventa parte della lingua stessa (new usable designs become standard).

Ma non siate troppo ottimisti sull’innovazione, pare che l’evoluzione del comportamento degli utenti sul Web e delle Guidelines si stia stabilizzando.

Chi disegna interfacce di applicazioni di utilizzo quotidiano (sistemi di home banking, client di posta, word processor, applicazioni per call center e via dicendo) dovrebbe tenere a mente questi due comportamenti tipici degli utenti:

• la tendenza a usare un limitato set di funzionalità - ognuno le sue
• la ripetitività delle scelte effettuate in termini di visualizzazione dei dati

Queste considerazioni aiutano l’interaction designer a progettare applicazioni che aumentino le performance dell’utente e riducano l’overload mentale.

Vediamo un paio di esempi:

1) L’home page dell’applicazione dovrebbe riportare, salvo rare controindicazioni, la lista delle ultime n attività svolte o quelle svolte più di frequente.

Sul mio sito di home banking per esempio vorrei vedere:

• bonifico
• pagamento F24
• movimenti ultimo mese
• bonifico internazionale

Queste sono le operazioni che effettuo più frequentemente.

2) Se l’applicazione offre diverse modalità di presentazione dei dati allora dovrebbe ricordare le scelte effettuate quando l’utente accede nuovamente alla piattaforma.

Sempre parlando di home banking mi viene in mente l’analisi tecnica di un titolo; le scelte in questo caso sono numerose, si possono modificare gli intervalli temporali, la forma del grafico (candela, lineare, …), le medie mobili e numerosi altri indicatori. Pensate se queste scelte dovessere essere ripetute ad ogni accesso, quanto tempo sprecato!

Nutro un forte interesse per l’interaction design ormai diversi anni, più precisamente da quando ho seguito le indimenticabili lezioni della prof.sa Xristine Faulkner alla South Bank University di Londra, nel lontano 1999/2000.
In questi ultimi mesi l’interesse si è trasformato in passione sia per la scoperta di alcuni articoli e libri interessanti sia per il coinvolgimento professionale.

Vi segnalo:

• progettare applicazioni Web: hub, wizard e guide (parte 1, parte 2)
• tutti (o quasi) gli elementi di interfaccia utente spiegati: interaction design patterns
• una bella definizione di interaction design
• questi due articoli di Bruce Tognazzini: principi di interaction design e ridurre il Tempo Soggettivo

Abbiamo tradotto un nuovo articolo. Non passa giorno che non trovi utili gli insegnamenti di Bruce Tognazzini, presenti in questa sua pubblicazione di qualche anno fa: i principi base dell’interaction design.

E’ interessante vedere come a distanza di anni i vari principi abbiano determinato la proliferazione di interfacce utente ben fatte, in particolare, leggendo l’articolo, non vi stupirete dei contenuti se utilizzate OSX invece che Windows. Buona lettura!

Di tag cloud si sente parlare da un po’, ma soprattutto si iniziano a vederne parecchie in giro. Sono uno dei nuovi codici di comunicazione visuale che appartengono al “Web 2.0″ (cerco sempre di usare questa parola con parsimonia, ma in questo caso ci sta a pennello).

Una nuvola di tag/etichette, o tag cloud, è un insieme di etichette in cui ognuna ha una grandezza proporzionale al proprio peso o importanza. Il peso è generalmente reso visivamente con l’utilizzo di un font più grande.

Una tag cloud ha il vantaggio di fornire all’utente, in maniera immediata, un elenco di qualificatori che sono stati attribuiti all’oggetto a cui si riferiscono. Se l’oggetto è una collection di foto, come nel caso di flickr, la nuvola descrive sommariamente quali sono i tag principalmente associati alle foto presenti sul sito e permette di capire a colpo d’occhio quali sono i tag principali. Nella pagina “popular tags” di flickr matrimonio, vacanze e party sono sicuramente i principali.

Una caratteristica importante di questi tag è che sono dei link. Rappresentano infatti un supporto utilissimo alla navigazione. Cliccando su matrimonio nell’esempio precedente l’utente viene portato a una lista di foto che sono state etichettate in questo modo. All’interno di questa pagina, contenente tutte le foto legate ai matrimoni, si potrebbe ripresentare una nuova tag cloud (chiamiamola di secondo livello), che mostra le principali etichette associate non più a tutte le foto, ma a tutte e sole quelle foto con associato il tag matrimonio. Potrei quindi trovare ricevimento, fiori, sposa, amore, …

Ma chi se l’e’ inventate queste tag cloud? Di preciso non si sa, wikipedia cita questa pagina, ma non è più raggiungibile. Di per certo ho letto anni fa in Information Architecture for the World Wide Web di Rosenfeld e Morville, il concetto di navigazione multifaccettata. Ad ogni pagina/oggetto appartenente a un sito vengono attribuite delle etichette (faccette nel lavoro di Rosenfeld e Morville) e l’utente può raggiungere questi oggetti scegliendo non più una navigazione gerarchica (es. automobili -> renault -> utilitarie -> twingo) ma una multifaccettata. Le tag clouds sono l’elemento di interfaccia che consente di effettuare questa navigazione.

Un altro aspetto interessante è che i tag sono nella maggior parte dei casi attribuiti dagli utenti, quindi ci troviamo di fronte ad un autentico caso di user generated content. Tuttavia ci sono delle eccezioni, in cui è il redattore stesso del sito che decide di taggare i contenuti ad uso e consumo dei propri utenti, come si può vedere in questo sito - realizzato da 10people - in cui tutti i lavori di ricerca scientifica sono etichettati con parole chiave, che vengono poi usate per formare una nuvola di tag sottostante alla navigazione principale.

[add on per programmatori] Come si calcola la grandezza dei font? Riporto una parte del codice utilizzata in italian applications. Questa funzione, in base al numero (occorrenze) di lavori di ricerca (l’oggetto del sito) a cui è associato il tag restituisce la grandezza del font.
L’algoritmo è piuttosto semplice. C’e’ una grandezza minima del font e una massima. C’è un numero minimo e uno massimo di occorrenze per ogni tag associato a un oggetto. Se mettete la grandezza del font sulle ascisse e il numero di occorrenze sulle ordinate, unendo i due punti di min e di max ottenete una retta (l’algoritmo non è altro che l’equazione della retta passante per due punti), ovvero una funzione che dato il numero di occorrenze ritorna la grandezza del font corrispondente. (se fate un disegno tutto si chiarirà nella vostra mente :-))

const MIN_FONT_SIZE = 12;
const MAX_FONT_SIZE = 36;

public function getFontSize($weight){
   $count = $this->Page->DataAccess->queryMinMaxCountTags();
   return ceil(($weight-$count['min']-1)*(self::MAX_FONT_SIZE-self::MIN_FONT_SIZE+1)/($count['max']-$count['min']) + self::MIN_FONT_SIZE);
}

Ho di recente letto un vecchio articolo di Nathan Shedroff sull’argomento. In poche pagine riassume i principi fondamentali di una teoria e dà degli spunti di riflessione su questioni aperte, come il raggiungimento di una user experience degna di questo nome. Potete leggere anche la versione italiana se preferite.

Il libro? Mmm… non lo consiglio.