I form¹ sono elementi interattivi della pagina web molto importanti per tutti i siti che, oltre a presentare informazioni, hanno bisogno che l’utente fornisca informazioni e interagisca con il sito. Sia rispondendo a questionari, inviando una richiesta, acquistando qualcosa o registrandosi ad un servizio. Sono il fondamento di qualsiasi applicazione web, dove attraverso i form gli utenti modificano impostazioni, gestiscono dati in inserimento, in visualizzazione e in modifica.

Esistono form semplici e complessi, basati solo sull’HTML oppure modificati con javascript, per utenti smaliziati o novizi. Stabilire linee guida rigide per i form valide e sufficienti per tutti i casi per la mia esperienza è quasi impossibile. Può essere di aiuto distinguere diversi aspetti sui quali i form possono essere valutati, secondo linee guida o principi che vanno prima di tutto interpretati e capiti, piuttosto che applicati rigidamente: nel compiere qualunque analisi bisogna infatti capire se una certa regola può portare benefici alla specifica applicazione oppure no.

Propongo qui, partendo dalla mia personale esperienza di analisi, oltre che dalla letteratura di settore, una serie di aree di valutazione distinte, che possono non essere sempre applicabili a tutti i form, ma che possono aiutare a costruire un proprio insieme modulare di linee guida, adattato al proprio sito e alla propria situazione. In seguito integrerò queste analisi con link e spunti di approfondimento ad altri siti. Le aree di analisi che per convenienza distinguo sono nove:

1. Comprensibilità linguistica
2. Operabilità
3. Messaggi e recupero dell’errore
4. Comprensibilità della procedura
5. Percepibilità
6. Organizzazione spaziale
7. Semantica convenzioni/affordance
8. Punti di azione

Altre fonti sui form

• Le basi per costruire form in html accessibili e usabili sono fornite ad esempio dal sito del LAU del Csi Piemonte. Se volete potete provare a scaricare anche un mio vecchio modello di pagina per form html accessibili costruito per il mio libro. Un po’ datato, ma può essere un punto di partenza per chi non ha esperienza.
• Marlenek (Daniele Vietri) pubblica sul suo blog due interessanti esempi reali di problemi con i form, che ricadono in alcune delle categorie già viste.
• Claudio Garau commenta un articolo di Gerry McGovern sull’uso dei tasti Ok/cancel negli alertbox (in breve, “Ok” va usato solo quando è appropriato al contesto: per segnalare un errore far premere ok è fuorviante e alla lunga può portare a errori: non c‘è niente di ok nel segnalare un errore, e l’utente finisce per premere il tasto per abitudine, non perché capisce quello che viene comunicato).
• Può essere interessante anche un riepilogo di Nielsen sul perché il più delle volte è bene evitare il tasto Reset nei form (foriero di errori non eliminabili…)
• Su Html.it vi è la traduzione di un articolo presente su Alistapart per migliorare i propri form.
• Luke Wroblewski ha pubblicato un libro dedicato interamente ai form. Sono disponibili anche delle sue interessanti slide (è un PDF di quasi 4MB) presentate ad un convegno del 2007.
• Se siete amanti delle soluzioni di codice, Peter Paul Koch spiega come migliorare i form nascondendone alcuni finché non diventano necessari agli utenti attraverso javascript e l’uso del Dom del W3C.
• Molto interessante infine la pagina di usability.gov sul processo di creazione di un form, dalla carta ai test di usabilità. Consigliatissimo.

Un lettore, riprendendo un discorso fatto qualche tempo fa su questo sito, pone sul suo blog un quesito interessante: se è vero che gli utenti comettono errori perché “usano prima di capire”, dice, non sarà bene sfruttare i loro errori per progettare le varie funzionalità? Interpretare cioè i loro errori come consulenze gratuite? Attraverso l’errore l’utente ci suggerisce come si aspetta di usare il sistema. Ci insegna il suo modello mentale.

Questo è proprio il punto di forza dell’usabilità: imparare empiricamente dall’utente. Nei commenti di quel sito però qualcuno ammonisce: assecondare sempre l’utente può dar vita ad incongruenze. Ed è vero anche questo. Dovremmo “assecondare” gli errori che hanno un’elevata probabilità di essere commessi anche da altri (sebbene non da tutti) a patto di non introdurre modifiche peggiorative.

Ma come capire quali errori devono dar vita a modifiche e quali sono idiosincratici, o, peggio, ci porterebbero a fare modifiche dagli effetti collaterali negativi?

Il caso delle caselle di input che non comunicano chiaramente la propria funzione

Un esempio può aiutare a capire meglio. Supponiamo che io scambi la casella di iscrizione alla newsletter per la casella di ricerca di un sito e invece di inserirci il mio indirizzo email ci inserisca il termine che voglio ricercare, commettendo così un errore.

Può darsi che quel giorno io sia mezzo addormentato, cosa non improbabile, oppure che ci sia un problema dell’interfaccia. Se lo stesso errore viene commesso da diversi utenti, probabilmente quella casella è mal disegnata. Ma anche se non viene commesso da molti utenti può darsi che la casella sia comunque migliorabile. Come capirlo?

Analizzando posizione, forma, colori, testi utilizzati. Forse è posizionata dove molti si aspettano un motore di ricerca. O forse c’è una cattiva comunicazione del formato del dato, o magari etichette verbali confondenti. Una casella senza anticipazione del formato (ad esempio attraverso il testo di segnaposto) o con messaggi generici è più “fraintendibile”:

Fig. 1 – Nonostante il titolo “newsletter”, un utente distratto può scambiare questo elemento per un search box, se posizionato in posizione ambigua, complice anche l’assenza di informazioni sul dato nella casella e la genericità del bottone. Infatti, mentre il titolo può essere “sorvolato”, casella e bottone hanno maggiori probabilità di essere visti.

Fig. 2 – In questa alternativa, il contenuto dell’input box riduce la probabilità di errori

Fig. 3 – In quest’ultimo esempio, il formato del dato viene esemplificato e il verbo nel bottone cambiato, riducendo al minimo l’ambiguità.

L’errore, se viene rilevato, deve sempre dar vita ad un ripensamento. Ma non tutti gli errori devono dar vita ad una modifica dell’interfaccia. Se cambiare l’interfaccia significa sconvolgere le aspettative degli altri utenti – ad esempio invertendo le posizioni di casella di iscrizione alla newsletter e casella di ricerca, per venire incontro al mio incauto errore – potremmo addirittura peggiorare le cose. Ad esempio, potremmo scoprire che ora è la maggioranza degli utenti che inserisce l’indirizzo email nella casella di ricerca! Al contrario, la modifica illustrata nelle immagini qui sopra è sicuramente migliorativa, perché non introduce altre ambiguità, ma, anzi, le elimina.

Gli errori vanno insomma filtrati e analizzati. Ed è questa è la parte più difficile del lavoro.

L’utente “tipo” non esiste, eppure ci assomiglia

Una delle critiche che vengono rivolte all’usabilità è che:

“ogni utente è diverso, non esiste l’utente tipo, perciò il designer deve prendersi le sue responsabilità e progettare, non farlo fare all’utente”.

Vero. Ma alcuni errori curiosamente ricorrono. Dipendono anche dall’interfaccia e possono essere evitati. E gli utenti hanno in comune molto più di quanto si pensi:

• Il verde e il rosso nella nostra cultura hanno più o meno lo stesso significato simbolico un po’ per tutti, anche se ciascuno di noi è diverso.
• Il verso di lettura è sempre da sinistra a destra e dall’alto in basso.
• Il fuoco dell’attenzione, fino alla prossima mutazione genetica, è sempre uno solo.
• Le regole di organizzazione percettiva sono simili.
• E molto altro…

Certo, poi ci sono le differenze. Di conoscenze, di ragionamento, di attenzione. A volte queste differenze generano problemi, altre solo diversi modi di usare l’interfaccia, perfettamente accettabili. Alcuni “heavy users” di Gmail non si rendono ad esempio conto che esistono le label e che è possibile filtrare le mail, mentre altri utenti che a rigor di classificazione dovremmo chiamare “inesperti” le usano quotidianamente con gran successo e senza difficoltà di comprensione. Questo non impedisce però a Gmail di essere usata proficuamente da entrambi i gruppi di utenti.

Per queste ragioni le modifiche delle interfacce sulla base degli errori devono essere del tipo “win-win”, come si dice in epoca di globalizzazione… Fare il bene di alcuni utilizzatori senza penalizzarne degli altri, o almeno fare in modo che il saldo finale fra facilitati e penalizzati sia positivo. E per far questo bisogna discriminare, analizzare, verificare.

Come valutare gli errori dell’utente

Se proviamo a stilare alcune linee guida o, meglio, dei criteri euristici su come valutare quando gli errori dell’utente debbano portare veramente a modifiche dell’interfaccia, otteniamo un elenco del genere:

1. Quando l’errore, qualunque esso sia, è compiuto da più di un utente. Se più di un utente in un test commette l’errore, è assai probabile che molti altri lo faranno nella realtà.
2. Quando l’analisi dell’errore evidenzia una scarsa chiarezza delle label verbali, siano esse testi, titoli, etichette di bottoni, testi interni ad elementi dei form, link. Una label verbale ambigua genera nel migliore dei casi dei rallentamenti dovuti a dubbi, nel peggiore dei casi errori.
3. Quando l’analisi mette in evidenza che vi sono segnali non verbali, ma dotati di valore semantico (icone, colori, posizioni) poco chiari. Si fa presto a fare un test di comprensibilità delle icone. Mettetele fuori contesto e chiedete a una decina di persone di scrivere sotto a ciascuna di esse cosa significhino secondo loro, senza dire altro. I risultati parleranno da soli.
4. Quando l’analisi dell’errore mette in evidenza che la causa potrebbe essere una mancata coerenza dell’interfaccia. Ad esempio, un elemento che assomiglia ad un altro, presente altrove, che si comporta in un modo diverso, e che dà vita a conseguenze diverse. Bottoni che cambiano colore, labeling o posizione, menu che cambiano ordine delle voci o fanno sparire voci, sono esempi di incoerenze che possono creare errori.
5. Quando l’errore si può eliminare con una modifica ovvia e poco costosa dell’interfaccia.
6. Tutto questo a patto che la modifica, rianalizzata, non introduca uno dei casi precedenti.

Più difficile è stabilire quando non cambiare l’interfaccia. Ecco alcuni casi tipici:

1. Quando non si è capito perché avviene l’errore; in tal caso è necessario approfondire le ragioni prima di ipotizzare la soluzione.
2. Quando la soluzione non rende l’interfaccia più chiara.
3. Quando la modifica interferisce con altre convenzioni diffuse o introduce ambiguità semantiche.
4. Quando la modifica penalizza qualche altro gruppo di utenti (elimina o modifica funzionalità gradite o usate dagli altri) che noi non vogliamo penalizzare.

I limiti dell’osservazione degli errori dell’utente

Queste “linee di condotta” si applicano a modifiche puntuali, focalizzate, dell’interfaccia. Non riguardano i cambi completi di modello concettuale, ovvero del funzionamento complessivo del sistema. Le “rivoluzioni”, quelle che modificano il nostro modo di lavorare con un software.

Un software consolidato difficilmente può permettersi modifiche di tali portate, perché deve tener conto degli utilizzatori già acquisiti, che hanno dunque imparato alcuni automatismi che la “rivoluzione” renderebbe inefficaci, innalzando, almeno inizialmente, il tasso di errore e di insoddisfazione. E’ accaduto anche per una delle recenti versioni di Microsoft Office, per esempio, con l’introduzione del ribbon, che all’inizio pare abbia disorientato qualche utente, anche se si tratta sicuramente di una modifica utile dell’interfaccia, una volta appresa.

Per quanto riguarda i siti di contenuti, un redesign solo estetico o piccole modifiche architetturali dovrebbero portare a problemi contenuti, perché tali siti sono meno orientati ai task e i cambiamenti interferiscono meno con la memoria procedurale.

Tra le applicazioni (desktop o web), quelle nuove hanno la possibilità, esordendo sul mercato senza la preoccupazione di perdere vecchi utenti, di proporre nuovi modi per svolgere attività vecchie. In quel caso, la rivoluzione riguarda l’intera interfaccia e non va applicato un modello “incrementale” di modifica come quello qui sottinteso. Questo modello va però applicato anche in queste nuove applicazioni a partire dalle successive iterazioni del progetto, per migliorarlo e raffinarlo.

Gli errori degli utenti sono in definitiva importanti strumenti di “consulenza gratuita” a patto che siano elaborati correttamente e non presi – ma nessuno lo pretende – come unica risorsa progettuale. A rendere più morale la (quasi) gratuità della consulenza – non dimentichiamo infatti che ai test gli utenti vanno in qualche modo compensati – c‘è il fatto che i maggiori beneficiari di questa consulenza dovrebbero essere, alla fine, proprio gli utenti stessi.

Uno dei problemi più ricorrenti che gli utenti incontrano nei test di usabilità riguarda l’uso dei motori di ricerca interni ai siti che visitano. Di solito questi motori offrono risultati irrilevanti e non consentono di trovare ciò che viene cercato. In una parola: sono terribili. La cosa è confermata un po’ da tutti i professionisti. Addirittura Nielsen nel suo più recente libro trova che il tasso di successo nei compiti di ricerca sia del 33% contro il 66% della generalità dei compiti.

In alcuni test, coloro che hanno usato in precedenza il motore di ricerca interno ad uno specifico sito e non l’hanno trovato soddisfacente, dichiarano di non volerlo più usare, preferendo utilizzare il motore generalista (Google, Yahoo, ecc.) anche per trovare documenti interni ad uno specifico sito: la probabilità di successo è molto più alta!

Eppure i motori di ricerca interni ai siti dovrebbero avere un compito molto più facile, dovendo indicizzare un numero molto inferiore di pagine. Come si spiega una prestazione così negativa? Le possibili cause sono molte e l’argomento è complesso sia dal punto di vista tecnico che da quello dell’interfaccia. Scusandoci per l’eccessiva semplificazione, metteremo qui in luce tre aspetti in particolare.

La lemmatizzazione

La prima ragione è che i motori di ricerca interna ai siti costruiscono indici secondo algoritmi differenti rispetto ai motori generalisti. Compilano un elenco di lemmi e li associano ad un elenco delle pagine che li contengono. La ricerca viene effettuata poi scorrendo l’indice anziché i documenti.

Questo va bene per costruire ricerche lessicali: trovare una parola o una serie di parole nel corpus dei testi. Ma spesso questi motori di ricerca (specialmente se interni ai CMS con cui vengono gestiti i contenuti del sito) non tengono conto della lemmatizzazione (stemming). E’ un’operazione che si fa su tutte le parole al momento di costruire l’indice che il motore userà nella ricerca. Serve a ridurre le parole alla forma più generale presente nel dizionario (da “mangiai” o “mangiando” a “mangiare”). In questo modo quando si cerca una parola si tiene conto delle possibili forme variabili o derivate: i verbi coniugati, i nomi con numero e genere differenti, eccetera. I motori di ricerca della maggioranza dei siti, cioè quelli messi a disposizione dai blog-tool e dai CMS di uso comune (ma anche alcuni strumenti dedicati), compiono spesso una ricerca solo sulle parole inserite e non sui termini che ne stanno alla radice, insomma. Cosa che invece i motori di ricerca generalisti fanno regolarmente.

Il Latent Semantic Indexing

Anche se compiono la lemmatizzazione, la grande differenza fra motori di ricerca interni ai siti e motori tipo “Google” è che questi ultimi usano, fra le altre cose, un sistema di indicizzazione semantica (Latent Semantic Indexing). Ne abbiamo già parlato a proposito dell’usabilità semantica: è un metodo che ricostruisce, grosso modo, le co-occorrenze delle parole in un corpus di testi (le pagine da indicizzare). Così facendo riesce a tener conto dei contesti nei quali le parole si presentano più frequentemente, e accorgersi, per esempio, che “Materazzi” si presenta spesso associato a “Zidane”, ma solo da una certa data in poi. Questo sistema viene chiamato “semantico” perché da queste regolarità nelle co-occorrenze è possibile dedurre “tracce di significato” (che ci sia stato qualche evento in comune fra Materazzi e Zidane, per esempio, attorno ad una certa data).

Il sistema non è “intelligente”: le correlazioni vengono fatte automaticamente, senza intervento umano. E tuttavia questo consente una miglior disambiguazione di alcuni termini di ricerca in rapporto a possibili risultati, in base al contesto. Il risultato migliora se l’utente scrive più parole (e migliora di molto se si tiene traccia delle sue ricerche passate, come Google fa…). Inoltre è meno sensibile ad alcuni trucchi usati per ingannare i motori di ricerca basati sull’aumento artificioso della frequenza delle parole in un testo. Riesce cioè ad eliminare un po’ di falsi allarmi dalla ricerca.

La LSI (o LSA, Latent Semantic Analysis: Google usa una variante brevettata) è molto più complessa di così, ma ciò che ci preme sottolineare è che fa grande differenza rispetto alla qualità dei risultati. Oltretutto la LSA è più efficace su un corpus di contenuti grande e dunque meno adatta a siti piccoli. I motori di ricerca interni, anche se la adottassero, avrebbero molte meno pagine da analizzare rispetto ai motori generalisti, il che porterebbe comunque a risultati di minor precisione.

La popolarità esterna delle pagine

Infine, come sappiamo, i motori generalisti usano la loro conoscenza sulla struttura dei link nel web per valutare la reputazione delle nostre pagine. Non basta che una pagina sia fortemente correlata alle chiavi di ricerca: a parità di correlazione, vengono privilegiate le pagine che hanno molti link in ingresso, cioè che altri hanno linkato sulle loro pagine, giudicandole, si presume, interessanti.

Perchè non possiamo sfruttare queste conoscenze per migliorare i piccoli motori di ricerca usati sui nostri siti? Be’, la lemmatizzazione potrebbe abbastanza facilmente essere introdotta in qualunque motore di ricerca interno ad un sito (si fa per dire: diciamo che è una tecnica abbastanza consolidata). La LSI (o LSA) anche, ma è meno nota, esiste un minor numero di implementazioni diffuse e c’è il limite del minor numero di pagine da indicizzare che porta a risultati meno precisi. La barriera maggiore è probabilmente l’uso dei link esterni come stima della reputazione delle pagine: decisamente fuori portata per la maggior parte dei siti. Queste ragioni spiegano abbastanza bene perché i motori generalisti sono in grado di fare regolarmente meglio rispetto ai motori interni dei siti.

Nessun motore di ricerca è meglio di un cattivo motore di ricerca

Se questi limiti sono difficili da superare, come migliorare l’esperienza degli utenti? Per siti non molto grandi, la soluzione migliore può addirittura essere paradossale: non inserire alcun motore di ricerca. Se il tasso di successo medio della ricerca è infatti più basso rispetto ai compiti basati sulla navigazione, inserire il motore vorrebbe dire abbassare il tasso medio di successo, e toglierlo vorrebbe dire aumentarlo!

Tuttavia, vi sono siti che hanno necessità o traggono vantaggio, per il tipo di materiale e per la sua organizzazione, da un buon motore di ricerca interno. L’indicazione è in questi casi di investire in un servizio dedicato di una terza parte che abbia qualità paragonabile a quella dei motori che i vostri utenti usano di solito.

Linee guida per il motore di ricerca

Per quanto riguarda l’usabilità della funzione di ricerca e della pagina dei risultati, semplificando molto il tema, il consiglio principale è di rimanere aderenti alle convenzioni che gli utenti conoscono meglio. E dunque:

1. Inserire una casella di ricerca semplice, composta da un unico campo
2. Inserire un bottone chiaramente visibile che senza ombra di dubbio sia riconoscibile come il bottone che dà il via all’azione
3. Evitare le ricerche estese a tutto il web: se gli utenti vanno sui motori generalisti anche per cercare nel vostro sito, è improbabile che vogliano fare l’inverso
4. Evitare opzioni inutili (caselle di spunta, tendine, ecc): vanno tutte interpretate, cosa che gli utenti in fretta di solito non fanno; vietatissimo inoltre usare opzioni impostate di default in senso restrittivo o anomalo.
5. Mantenere la casella di ricerca abbastanza lunga (Nielsen suggerisce una trentina di caratteri): il motore di ricerca è un’interfaccia a riga di comando, e, sebbene molti utenti inseriscano poche parole, è bene provare ad indurli ad usarne di più, perché migliorerà la qualità del risultato
6. Il punto precedente, naturalmente, prevede che il motore funzioni di default con un AND logico e non con l’OR. In questo modo tutte le parole chiave prese insieme concorreranno al risultato. L’uso dell’OR fa aumentare irragionevolmente i risultati diminuendone la rilevanza. Se cerco “usabilità dei motori di ricerca”, non ha senso che mi compaiano tutte le pagine che includono la parola “usabilità”, poi quelle che includono “motori”, poi quelle che includono ricerca, poi quelle che includono le diverse combinazioni di queste parole… Se avete pochi contenuti e di conseguenza soffrite di horror vacui, eliminate il motore e concentratevi sul miglioramento della navigazione, finché non avrete più pagine
7. Offrite opzioni di suggerimento se l’utente non trova risultati o se i termini di ricerca sono anomali, anche con algoritmi di suggerimento ortografico
8. Ripresentate nei risultati il termine di ricerca usato, già inserito nella casella per successive modifiche
9. La pagina dei risultati dovrebbe contenere per ogni risultato tre informazioni basilari:
   1. Il titolo della pagina del risultato, linkato alla risorsa; di solito per il testo viene usato il tag TITLE dell’html, dunque per gli autori di contenuti è vitale scegliere accuratamente soprattutto le prime parole del title, quelle che gli utenti scorrono per valutare i risultati
   2. Tre-quattro righe di estratto del testo della pagina, compreso un frammento che contenga la chiave di ricerca; è meglio usare come testo il contenuto della pagina piuttosto che un metatag di descrizione, perché quest’ultimo potrebbe non essere ugualmente significativo per tutte le chiavi di ricerca che riguardano quella pagina; ed è bene che questo testo contenga informazioni ulteriori rispetto al titolo, che consentano all’utente una migliore valutazione del risultato
   3. L’indirizzo della pagina di destinazione.
10. Poiché l’ordinamento dei risultati dall’alto al basso dovrebbe già seguire un ordine di rilevanza, è pleonastico (e può risultare confondente) indicare percentuali di rilevanza.

Altre linee guida vanno naturalmente tenute in considerazione per specifici aspetti e casi dell’interazione, come la paginazione dei risultati, i messaggi di errore e di feedback in generale, nonché per tipi particolari di ricerca, ma ci ritorneremo eventualmente con maggior dettaglio in un successivo articolo.

La ricerca avanzata

Un’ulteriore considerazione la merita la ricerca avanzata. Benché utile in specifici casi (banche dati, utenti professionalizzati, ricerca su un corpus definito di testi, consultazione di orari), sulla maggior parte dei siti è una complicazione inutile. Inoltre, laddove possibile, è bene seguire la tendenza generale dei principali motori di ricerca sul web, che è quella di utilizzare un unico campo per tutte le selezioni, riducendo al minimo la necessità di spostarsi fra i campi e di interpretarne il ruolo e il formato.
Ad esempio, una selezione per data può essere fatta scrivendo direttamente gli estremi nella casella della ricerca, anziché manipolando diverse tendine. Per esempio scrivendo “usabilità e motori di ricerca, agosto 2008-settembre 2008”.

Questo sistema a campo unico è più efficiente. Si noti per esempio come si possono cercare località su Google Maps usando un unico campo rispetto, per esempio, all’insieme di campi su siti come Mappy o Tuttocittà.

Esempi:

In questo esempio tratto da Google Maps, tutti i parametri della ricerca possono essere scritti in un unico campo, senza spostare le mani dalla tastiera, compiere operazioni mentali specifiche per le selezioni dei diversi campi, controllare l’esattezza del formato, e così via.

In questo caso, da tuttocitta.it, l’inserimento deve essere fatto passando fra campi successivi, di cui è necessario capire il significato e il formato utilizzabile

In quest’ultimo esempio, tratto da mappy.it, non solo si devono usare più campi, ma l’ordine è diverso da tuttocitta.it, nonostante la configurazione visiva del form sia identica! Dunque chi è abituato ad un sito è probabile commetterà errori nell’altro…

La tendenza comune è quella di usare la casella di ricerca in maniera più possibile “intelligente”, cioè interpretando virgole, numeri, inferendo indirizzi, relazioni e formati. Il tutto è chiaramente reso possibile da un motore che non sia soltanto lessicale, ma che incorpori delle informazioni ulteriori: di tipo e formato del dato sulla base del contesto, di clustering semantico, di scopo. La supremazia dei motori generalisti si spiega anche così.

Lo User Centered Design (UCD) è un modo per progettare e costruire siti o applicazioni tenendo conto del punto di vista e delle esigenze dell’utente. Lo UCD è un processo composto di più attività. Si basa sull’iterazione di diversi strumenti di analisi od osservazione, progettazione e verifica. In italiano questo processo è noto anche come “Progettazione Centrata sull’Utente”.

Il processo è stato definito e descritto da diversi autori e persino da alcune norme ISO, come la 13407, Human-centered design process. Diverse fonti descrivono processi leggermente diversi, ma guidati dalla stessa filosofia: fondare il progetto sulle esigenze degli utenti.

La ISO 13407

Questa norma ISO stabilisce quattro attività principali per il processo di UCD:

1. Specificare il contesto d’uso
2. Specificare i requisiti
3. Creare delle soluzioni progettuali
4. Valutare il design

Solo quando le soluzioni progettuali rispecchiano i requisiti, allora il prodotto può essere rilasciato e pienamente realizzato.

Appare evidente l’importanza che viene data a ben due fasi di analisi prima della creazione effettiva di soluzioni progettuali. Il contesto d’uso è necessario per identificare quali persone useranno il prodotto, cosa ci faranno e in quali condizioni lo useranno.

I requisiti si concentrano a questo punto sia sui compiti che gli utenti dovranno portare a termine che sugli eventuali obiettivi di business.
Solo a questo punto il prodotto può iniziare a essere pensato e progettato, in forma di prospetto, schema, prototipo, fino ad un modello completo.

Ma il passo davvero fondamentale è l’ultimo, ovvero la verifica del prodotto, in particolare con utenti reali attraverso i test di usabilità, anche se non solo: interviste, questionari, analisi ispettive e secondo linee guida possono altresì essere utili.

Gli strumenti

Nelle diverse fasi del ciclo di progetto vengono portate avanti diverse attività con diversi strumenti.

Nella fase di analisi (1 e 2) tipicamente si compiono le seguenti attività:

1. Incontri con gli stakeholder (portatori di interessi) per capire vincoli e aspettative
2. Analizzare i prodotti esistenti
3. Conduzione di osservazioni sul campo
4. Conduzione di interviste con potenziali utenti
5. Conduzione di workshop con potenziali utenti
6. Questionari
7. Creazione di profili di utente
8. Creazione di elenchi di compiti
9. Creazione di scenari
10. Definizione di team multidisciplinari

Aggiungo che è bene fin dall’inizio creare dei modi agili per comunicare fra i diversi componenti dello staff, e non rigidi e immodificabili. In un lavoro di UCD non dovrebbero esistere membri del gruppo di lavoro che decidono indipendentemente dalle opinioni altrui.

Nella fase in cui si lavora alla creazione di soluzioni progettuali si usano i seguenti strumenti:

1. Brainstorming, riunioni e discussioni libere
2. Creazione di modelli e schemi di navigazione
3. Creazione di bozzetti e schermate, anche carta e matita
4. Conduzione di analisi e simulazioni cognitive sui bozzetti
5. Creazione di prototipi a bassa o alta fedeltà

Si può notare che accanto ad attività più propriamente progettuali (che comprendono il disegno dell’interfaccia con vari strumenti) si inizia già a condurre delle valutazioni e delle analisi sulla base dei documenti predisposti nella prima fase (scenari, compiti)

La valutazione avviene prima e durante l’implementazione vera e propria del sistema, attraverso:

1. Test con utenti
2. Questionari
3. Analisi euristiche e ispettive
4. Simulazioni cognitive

Alla fine il prodotto viene corretto e implementato con:

1. La modifica del sistema
2. La realizzazione definitiva di Html, css, grafica e programmazione

La fase di valutazione idealmente non finisce qui, perché si possono mettere a punto fasi di monitoraggio del sito o del software, grazie a:

1. Meccanismi di segnalazione di problemi
2. Questionari
3. Studi sul campo
4. Ulteriori test di usabilità per controllare gli obiettivi.

In definitiva, lo UCD è sia una filosofia che un processo che adottano una serie variabile e sufficientemente flessibile di strumenti.

Giova ricordare che tutti i prodotti vengono realizzati secondo un qualche processo. Questo può essere casuale o molto formalizzato. Attività di UCD possono essere inserite sia nell’uno che nell’altro caso, ma molto spesso non lo sono.

Perché lo UCD è raro?

Perché in Italia, ma anche in buona parte del mondo, i processi aziendali non vengono orientati alle esigenze dell’utente, con attività specifiche come quelle elencate qui sopra, anziché solo a parole? Per almeno 2 ragioni:

1. Perché lo UCD è una filosofia relativamente giovane e poco insegnata. Non è il modo di gestire tradizionalmente il processo di realizzazione di software e di siti. Non è il modo in cui funzionano le software house in Italia, ed è un metodo che capi-progetto e manager non sanno bene come gestire
2. Perché viene visto come un costo. Al contrario, vi sono stime che indicano che i processi UCD beneficiano di una rapida focalizzazione sui requisiti e le soluzioni giuste, evitano allungamenti di tempi legati a imposizioni o discussioni improduttive, e portano ad un prodotto soddisfacente in un tempo minore (Landauer, 1996¹)

Inserire lo UCD nel processo di progettazione richiede un cambio di mentalità e di procedure nelle aziende, che le renda più flessibili. Questo è abbastanza difficile in aziende grosse, perché, proprio come McDonald ha bisogno di standardizzare le procedure per produrre panini di identica qualità media, le grandi aziende hanno bisogno di standardizzare molto i processi per produrre software e siti di qualità standard qualunque sia la formazione e il grado di competenza dei dipendenti.

Tuttavia adottare l’UCD aiuta anche le aziende grosse a evolversi e a mettere in discussione le proprie rigidità.

Formazione

E’ urgente inserire lo UCD nelle scuole e nei corsi di webdesign. Negli anni 90 partecipai a corsi che non menzionavano in alcun modo queste attività. Negli anni 2000 ho insegnato in vari corsi che menzionavano tutt’al più l’usabilità. Lo UCD è più dell’usabilità: è l’applicazione di una filosofia tutta centrata e rivolta a identificare i bisogni dell’utente, nel rispetto di quelli di business.

Si fonda sulla credenza che sia possibile identificare i bisogni e i difetti di un prodotto attraverso l’analisi e il test. E che le evoluzioni siano misurabili. Richiede un cambio di mentalità verso la trasparenza e la chiarezza: le attività di test condotte durante il processo testimoniano l’evoluzione del prodotto e possono essere usate per vincere le resistenze di alcuni decisori.

Diversi autori hanno fatto evolvere il bagaglio di strumenti utilizzabile dentro procedure di UCD. Fra questi ricordiamo Alan Cooper, che ha ridefinito e migliorato il concetto di scenario e di personaggi (personae o personas).

UCD e accessibilità

La legge italiana sull’accessibilità cita una metodologia progettuale durante la quale dovrebbero essere effettuate alcune valutazioni che dovrebbero portare alla cosiddetta valutazione soggettiva. La metodologia indicata, identificata da un gruppo di lavoro diretto da Sebastiano Bagnara, uno dei pionieri dell’ergonomia in Italia, è né più né meno che un’applicazione dello UCD.
Questo sarebbe il modo giusto di progettare siti non solo tecnicamente accessibili, ma adeguati ai bisogni informativi e d’uso degli utenti, anche disabili. Anche all’estero si inizia a capire che l’accessibilità può esistere solo all’interno di una procedura di UCD.

Purtroppo, nonostante le iniziali speranze, questa legge ha marginalizzato questa procedura, rendendola non obbligatoria. Non solo: un recente chiarimento del CNIPA ha specificato che la valutazione soggettiva addirittura non deve essere fatta per i siti pubblici, con argomenti di difficile comprensione. Non ha speso una parola per sostenere l’applicazione di procedure di UCD nella progettazione di siti pubblici, sprecando così l’occasione di un salto storico nella mentalità progettuale dei siti pubblici.

Noi non perdiamo la speranza e sosteniamo che quella indicata nella metodologia sia la giusta procedura di progettazione dei siti, e auspichiamo che successive modifiche della legge, o successivi e più ponderati chiarimenti del Cnipa restituiscano a questa procedura la centralità necessaria.

Modi per orientare la vostra azienda allo UCD

E’ essenziale formare l’azienda alle procedure di UCD. Queste attività devono essere condivise non solo dagli esecutori (grafici, progettisti, programmatori), ma dai vertici dell’azienda, senza il contributo dei quali agli esecutori arriveranno sempre indicazioni contraddittorie. Per questa ragione le attività che hanno dimostrato di funzionare nel cambiare l’attitudine di un’azienda verso l’UCD sono le seguenti:

1. Incontri e workshop sul design centrato sull’utente con i diversi stakeholder: manager, dipendenti, eventuali politici di riferimento
2. Formazione specifica su specifici strumenti di UCD
3. Richiami periodici di verifica e risoluzione dei problemi

Potere contattarci per avere ulteriori informazioni circa queste attività. Ed è bello notare che anche altre realtà in Italia stanno lavorando per sostenere l’UCD: è il segno che qualcosa si sta muovendo e che tutti assieme possiamo raggiungere l’obiettivo di avere un web moderno, progettato attorno alle esigenze delle persone che lo useranno e non dei progettisti.

Sebbene le home page possano variare considerevolmente a seconda del tipo di sito, progettarle e' sempre un compito diverso dalla progettazione di pagine interne. Le differenze sono date dalle particolari funzionalita' di queste pagine. In questo articolo ci soffermeremo su alcune considerazioni che è necessario tener presente, dividendole per comodità in due categorie:

1. funzionalità
   ovvero quali compiti assolvono le home page
2. vincoli
   ossia i limiti che può essere necessario considerare.

Funzionalità

La prima cosa da sottolineare è probabilmente ovvia, ma è meglio non darlo per scontato: la home page è probabilmente la via di accesso principale ad un sito (anche se certo non l'unica possibile). Si troverà così a ricevere due grandi categorie di visitatori:

1. Utenti che arrivano sul sito per la prima volta
2. Utenti che conoscono già il sito e vi ritornano.

Gli utenti che arrivano per la prima volta si pongono per lo più 2 tipi di domande:

• Dove sono? Cos'è questo sito e cosa offre? Ho qualche motivo per visitarlo (cioé mi propone qualcosa di interessante)?
• Dove posso andare da qui? Come mi muoverò alla ricerca di ciò che sembra promettente o come troverò ciò che stavo cercando?

Fornire identità e orientamento sono dunque le due funzionalità principali di un'home page.

Gli utenti che ritornano sul sito lo conoscono già. E' quindi è probabile che cercheranno soprattutto:

• News: informazioni sui più recenti aggiornamenti, sulle modifiche e sulle offerte del momento.
• Scorciatoie e utilities: metodi meno standardizzati e più veolci per raggiungere le informazioni gradite, o accessi per utenti registrati.

Quelli che seguono sono alcuni dei principali modi per assolvere a queste funzionalità in un'home page. Non sono probabilmente gli unici, ma sono quelli che hanno dimostrato nel tempo di possedere una certa efficacia, assumendo il ruolo di convenzioni. I motivi sono tutt'altro che arbitrari, come vedremo. Di conseguenza, qualora si intendesse violare queste convenzioni, è bene farlo a ragion veduta.

1. Fornire identità

…ovvero rispondere alle domande che l'utente si pone: cosa fa questo sito? chi è l'azienda?
Un modo standard per assolvere a questa funzione è naturalmente quello di inserire il logo in bella evidenza nell'home page. Che l'azienda sia famosa o perfettamente sconosciuta, il logo serve a identificare il luogo in cui ci si trova.
Il logo andrebbe posto in alto a sinistra per un motivo molto semplice: è il punto gerarchicamente più importante della pagina. Spostarlo da lì significa rischiare di inserire qualcosa al di "sopra", e se qualcosa sta sopra il logo nella gerarchia della pagina, si possono creare dubbi e confusione all'utente. Se siete certi che non si generano confusioni, allora, in virtù di un'impaginazione particolare, il logo può anche essere posto in qualche altro luogo rilevante della pagina. In ogni caso, non vi devono essere conflitti gerarchici con altre immagini o elementi. Don Norman sostiene che "fra gli oggetti e la loro localizzazione deve esistere una corrispondenza spaziale naturale: in altre parole deve esserci una ragione per collocare gli oggetti nel luogo in cui si trovano". Ogni volta che si dispongono gli oggetti (non soltanto il logo) sulla pagina bisognerebbe tener presenti queste affermazioni.

Inserire il logo non è però tutto: siete sicuri che la vostra pagina dica chiaramente cosa offre il sito? A chi si rivolge? Perché dovrebbe essere interessante? Non datelo per scontato. Spesso un semplice logo non è affatto sufficiente.
Uno dei sistemi utilizzati a questo scopo è quello di inserire negli immediati dintorni del logo un piccolo slogan, una frase esplicativa che introduca in maniera chiara e accattivante il servizio. E' importante però evitare gli slogan magniloquenti e vuoti: si deve soprattutto capire!

[Usabile.it ha scelto un'altra strada. Nella prima versione dell'home page abbiamo inserito nella colonna a destra una serie di risposte alle domande esplicite "di cosa si parla" e "a chi è rivolto il sito". Quest'ultima categoria permane nell'attuale versione, mentre il "di cosa si parla", dopo qualche mese è stato sostituito da un "abbiamo parlato di", seguito da una serie di link diretti ad alcuni articoli. In questo modo abbiamo anche fornito una scorciatoia a utenti abituali (che così non devono necessariamente passare per la pagina dell'indice per recuperare tutti i vecchi articoli), mantenendo il più possibile in evidenza il range di argomenti affrontati.

Non vi è una scelta ottima: avremmo potuto scrivere vicino al logo "argomenti dal mondo della web usability", o qualcosa di simile. Ma poiché al momento della pubblicazione del sito l'argomento era solo emergente, qualcuno avrebbe potuto non sapere cosa fosse la web usability. Fornire la chiara indicazione degli argomenti che avremmo affrontato è parsa la scelta migliore.

Tutto semplice? Anzi… alcuni utenti ci hanno segnalato un problema di… usabilità! La barra a destra è ormai convenzionalmente considerata barra di link, al pari delle barre a sinistra. Di conseguenza questi utenti tentavano di cliccare sugli argomenti, benché privi di sottolineatura e colorati in nero come del normale testo (evidentemente non tutti i link devono essere blu e sottolineati per essere percepiti come tali…). La somiglianza con barre simili di altri siti era per alcuni un segnale molto forte.

La soluzione (senza procedere ad un oneroso redesign…) è stata quella di attendere di avere qualche articolo in archivio e passare a fornire una scorciatoia agli articoli in luogo del "si parla di", avvicinando così la funzione della barra a destra alle aspettative degli utenti (in questa maniera si marca anche una differenza con la tabella sottostante, non linkata e contenente solo un'indicazione delle categorie di utenti cui ci rivolgiamo).]

La verità quindi è che l'intera pagina, nel suo insieme, deve presentare informazioni semplici ed efficaci sull'identità del sito. Ricordatevi di non dare per scontato che l'utente vi conosca o che sappia cosa offrite: l'home page deve indicarlo senza lasciare dubbi.

2. Orientamento e navigazione

L'home page deve rispondere anche alle domande: dove posso andare? cosa posso trovare? Come faccio per arrivarci? Questa funzionalità viene assolta generalmente in tre modi (che sono comunque molto più complicati di quanto non si possa esporre qui…):

1. con la presenza di chiari menu di navigazione. I menu dovrebbero utilizzare etichette verbali che indichino il più esattamente possibile cosa si trova al di là del link. Non fidatevi di quelle che vi possono sembrare geniali metafore se prima non ne avrete valutato la comprensibilità. Allo stesso modo, l'uso di icone senza etichette verbali non è consigliabile, perché non vi è accordo sul significato della grossa maggioranza delle icone… Ricordate anche che gli strumenti di navigazione principale sono al secondo posto nella gerarchia d'importanza degli elementi di una pagina. La scelta di collocarli in una barra orizzontale sotto al logo o nella colonna a sinistra riflette questa gerarchia. I cambiamenti sono possibili, ma tenete conto del messaggio complessivo che la vostra impaginazione offre.
2. con directory che raccolgano le sezioni principali del sito. Con un solo click potete consentire all'utente di entrare in una sezione che gli interessa particolarmente, dove potrà effettuare scelte più precise.
3. attraverso funzioni di ricerca testuali. Tipicamente, la casellina di ricerca interna al sito, utile soprattutto se il vostro sito ha molte pagine.

3. Che c'è di nuovo? News e offerte.

In molti casi (non sempre) l'home page è anche la pagina che presenta le novità. Nel corpo della pagina, gerarchicamente in posizione inferiore rispetto a logo e navigazione, prevedete uno spazio dove presentare le novità del giorno, della settimana o del mese… E, chi lo sa, potreste aver bisogno di proporre servizi speciali, offerte, partnership. Prevedete uno spazio per tutto questo fin dal principio. Ricordate di inserire una data accanto alle novità, perché non sempre chi arriva sul vostro sito sa con quale frequenza lo aggiornate, ed è spiacevole approfondire una novità per scoprire poi, in marzo, che è riferita alle feste natalizie (naturalmente è consigliabile aggiornare il sito più frequentemente di ogni tre mesi…).

4. Scorciatoie o altre utilities per utenti abituali

Abbiamo già discusso di una possibile scorciatoia parlando dell'home page di usabile.it. Le scorciatoie possono avere diverse forme, ma si tratta per lo più di link ridondanti o di accessi diretti a zone del sito. Tra queste ultime vi sono anche le funzionalità di accesso per utenti registrati. Se il sito le prevede, è bene inserire fin dall'home page il form per l'inserimento di password e nome utente. Alcuni siti invece utilizzano in home page un link ad una pagina di ingresso vera e propria. Ma perché aggiungere un link in più? Questo genere di funzionalità non occupa molto spazio. Se la inserite direttamente nella home page, gli utenti registrati ve ne saranno grati.

Vincoli

Progettare un' home page non significa soltanto pensare a funzionalità e facilitazioni per gli utenti. Vi sono spesso delle altre scelte da compiere, alcune delle quali sono a volte dei vincoli in sé, come i banner. In altri casi si tratta di scelte di fondo, per effettuare le quali bisogna avere coscienza di alcuni vincoli cognitivi (per evitare di sovraccaricare l'attenzione dell'utente) e tecnologici (come i vincoli di peso in kilobyte dei documenti, collegati alla scarsa ampiezza della banda passante).

I banner

Sebbene la percentuale di click dei banner sia costantemente in calo dal momento della nascita del web a oggi, e alcune ricerche abbiano dimostrato che gli utenti hanno ormai imparato a ignorarli, per molti siti i banner sono ancora una delle fonti principali di guadagno. Vi sono tre accortezze da tenere presenti a proposito dei banner in home page:

1. Al momento del design prevedete già lo spazio per i banner, evitando che appaiano posticci e mal integrati nella pagina.
2. Non inseriteli MAI prima del logo. Dà alla pagina un 'impressione di estrema commercialità, nel senso spregiativo del termine. Sembra, insomma, che vi importi molto di più il banner del vostro sito. Il che forse sarà anche vero, ma non è una buona idea renderlo così esplicito…
3. Evitate gli eccessi. Un banner è più che sufficiente. Se ne dovete proprio inserire degli altri, è opportuno che si differenzino. Spesso i banner di piccole dimensioni sono comunque efficaci, e vengono da alcuni siti inseriti in una delle colonne ai lati della pagina. Non sono un esperto di pubblicità, e non so quanto rendano. Certo l'effetto sull'utente di una pagina che sembra un albero di natale lampeggiante non è dei migliori. Se potete, prevedete una o due postazioni fisse per i banner, e ruotate i diversi sponsor (anche se questi il più delle volte preferiscono la presenza costante). In questo modo l'utente sarà attratto dal non trovare sempre lo stesso banner in quella posizione. Valutate comunque altre forme di sponsorizzazione, come le partnership o gli annunci testuali.

In generale, comunque, è bene ricordare che le animazioni (tutte, non solo i banner) sono dei distrattori! Usatele con parsimonia, si tratti di Gif animate o di moduli in Flash, perché disturbano l'attenzione dell'utente invece di favorirla e interagiscono negativamente con i contenuti testuali.

Intro animate e "pagine copertina"

Le intro animate sono moduli, solitamente in Flash, di animazione vettoriale multimediale, usate per introdurre l'ingresso al sito vero e proprio. A volte è prevista la possibilità di saltarle, a volte no (e in tal caso al web designer che ha omesso questa possibilità fischieranno le orecchie… soprattutto se per l'utente non è la prima visita al sito).

Le pagine copertina sono quelle costituite da un'unica grande immagine, che una volta caricata ha l'unica funzione di essere un link alla home-page propriamente detta.

Hanno entrambe lo stesso problema: sono lente da caricare e allontanano la pagina vera e propria. Perché utilizzarle, allora? Per motivi di immagine, si dice alle volte. Per dare un'esperienza estetica o multimediale. Siete sicuri che l'utente medio (che non ha alcun interesse a intraprendere il mestiere di web designer) gradisca questi rallentamenti privi di funzionalità?
Le stesse norme di usabilità della Macromedia sconsigliano vivamente l'utilizzo delle intro animate in Flash. Le intro possono essere linkate in home page, così se qualcuno ne è appassionato le potrà scaricare come libera scelta, invece di imporle anche a chi non ne vuole sapere (o non ha il plug-in e non intende scaricarselo).
Per le "pagine copertina" invece, nessuna speranza: vanno abolite, ora e definitivamente. Se volete mostrare la vostra arte, progettate una sezione portfolio, e sfogatevi là…

Problemi di peso

Le home page sono pagine che si devono scaricare velocemente. Se possibile (ma spesso non lo è…) più in fretta delle pagine interne, dato che devono 'agganciare' l'attenzione dell'utente. Generalmente è difficile che siano più veloci, perché le pagine interne si possono a volte avvantaggiare dal mancato scaricamento di alcuni file grafici in comune con la home, che in tal caso sono già presenti nella cache memory del browser. A maggior ragione, mantenete il peso complessivo del codice html più i file grafici associati entro i 50Kbyte (se possibile ancor meno), limite considerato massimo per garantire un tempo di scaricamento ragionevole.

Queste considerazioni sono delle linee guida, e come tali vanno usate senza eccessiva rigidità. Il loro scopo è quello di porre l'attenzione sui motivi che stanno alla base delle scelte che si fanno.
E' bene ricordare che ogni sito ha i suoi obiettivi: definiteli chiaramente. Se, in base agli obiettivi, ritenete di avere una ragione valida per violare queste linee-guida, be', allora fatelo. Ma valutate attentamente i pro e i contro: accertatevi (con dei test di usabilità, per esempio) che anche i vostri utenti gradiscano queste modifiche!