WebQuality   Note sulla qualità del Web

Indice sinottico

1. Prototipizzazione a bassa, media, alta fedeltà
2. Livelli di dettaglio di un prototipo
3. Che aspetti coprire con un prototipo?
4. Per riassumere
5. Approfondimenti

Prototipizzazione a bassa, media, alta fedeltà

La prototipizzazione dell'interfaccia utente (UI) è una tecnica di indagine di usabilità perché permette di produrre conoscenza (relativamente agli aspetti coperti dal prototipo e rispetto agli scopi per cui lo si è costruito) che prima non si aveva. Essa ha dirette implicazioni sulla qualità del sito che si sta sviluppando ex-novo oppure che si sta modificando. È una tecnica che qualsiasi progettista o direttore di progetto deve conoscere e saper impiegare: essa permette di migliorare la qualità dei siti prodotti e al contempo di risparmiare tempo e fatica.

Queste note discutono i vari tipi di prototipi della UI (a bassa, media, alta fedeltà, orizzontali o verticali) e i loro possibili utilizzi.

Cosa sono i prototipi

Un prototipo è una versione parziale e temporanea di un sistema il cui scopo è ridurre i rischi di conseguenze negative di decisioni di progetto. Così come un progettista aeronautico crea un prototipo (modello) di un'ala e la sottopone a dei test nella galleria del vento, e un ingegnere civile crea un modello del ponte e lo sottopone a dei test di carico, anche chi progetta del software (e quindi siti web) spesso deve creare dei prototipi e validarli.

Il prototipo permette di ridurre i rischi di un progetto perché ci permette di mettere prima a fuoco alcune caratteristiche del sistema e capire se sono adeguate o meno. Prima di aver allocato risorse (tempo, denaro, persone, infrastrutture) in attività di progetto che vanno in una direzione sbagliata.

Per questa ragione i prototipi vengono costruiti relativamente presto nel ciclo di vita di un prodotto e, svolta la loro funzione, vengono gettati via. Tutto del prototipo viene scartato, tranne le idee e le considerazioni che dalla sua analisi sono emerse. La ragione è semplice: lo scopo del prototipo è verificare determinate proprietà, e per ottenere questo scopo vengono investite le minime risorse necessarie. Quindi tutti gli altri aspetti del sistema (ad es. la qualità del codice, la sua efficienza, affidabilità, la completezza dei compiti supportati) non vengono curati in un prototipo.

Perché produrre prototipi?

Esistono tre ragioni per costruire un prototipo che corrispondono a tre tipi di prototipi:

Dimostrativi

Questi prototipi vengono costruiti allo scopo di dare forma ad un'idea e di dimostrarne la fattibilità o appropriatezza. Esso permette di illustrare le sfacettature di un'idea e mostrarle in maniera visuale e interattiva. Tale prototipo è di norma relativo ad una parte di un sistema, ad una parte di una UI o ad un sistema nuovo e innovativo.

Tale prototipo raggiunge il suo scopo quando ci si è convinti che l'idea è tecnicamente fattibile, che sembra potenzialmente adeguata all'audience a cui è rivolta, che sembra competitiva rispetto ad altre.

Esplorativi dell'interfaccia utente

Lo scopo è di validare il progetto di una UI oppure di confrontare versioni alternative di una UI. Il criterio per valutare un tale prototipo può riguardare una qualsiasi delle proprietà della UI: per verificare se la UI è usabile, gradevole, facile da realizzare, scalabile in termini di funzionalità e opzioni, o altro ancora. Alternativamente, in presenza di più progetti alternativi, ci si potrà chiedere quale delle alternative è più usabile, gradevole, realizzabile, scalabile.

Tale prototipo svolge la sua funzione quando ci ha permesso di rispondere a qualcuna di tali domande. Questo tipo di prototipo gioca un ruolo fondamentale nella progettazione di un sito web, e la ragione per cui esso sia così importante risiede nel fatto che anche i migliori progettisti non sono infallibili, e il prototipo permette di validare determinate scelte prima che sia troppo tardi.

Una prerogativa di questo tipo di prototipi è che essi vengono usati quasi sempre all'interno di uno sviluppo iterativo: si costruisce un prototipo, si validano alcune scelte progettuali e si trovano difetti da risolvere; dopo averli risolti, viene costruito un altro prototipo con lo scopo di validare queste nuove scelte; e cosí via fino a quando tutte le scelte critiche sono state validate.

Esplorativi della tecnologia

In questo caso lo scopo è verificare se determinati componenti software possono essere accoppiati tra loro, oppure per determinare se determinati strumenti e componenti possono essere impiegati per realizzare determinate soluzioni. Questo tipo di prototipo lo si analizza verificando se la soluzione è fattibile da un punto di vista tecnico, che tipi di prerequisiti infrastrutturali, tecnologici o di conoscenze sono necessari, se determinati livelli di prestazioni sono raggiungibili, se il sistema risultante è sufficientemente affidabile, portabile, modulare, modificabile

Questo prototipo svolge la sua funzione quando si è capito che una determinata soluzione tecnica non è fattibile (oppure lo è), che non supporta determinati livelli di carico, ecc.

Al ritmo con cui nuove soluzioni tecniche e nuove tecnologie emergono, virtualmente in ogni tipo di progetto software è necessario procedere con prototipi di questo tipo, dato che raramente la tecnologia necessaria per un sistema è tutta già conosciuta e sperimentata.

Nel seguito di questa sezione ci limitiamo qui a discutere solamente i prototipi esplorativi di UI.

Livelli di dettaglio di un prototipo

Il livello di dettaglio è il grado di fedeltà che il prototipo ha rispetto al sistema finale (se questo venisse costruito seguendo le idee incarnate dal prototipo). Si può distinguere tra prototipi a bassa, media e alta fedeltà.

Prototipi cartacei

Chiamati anche prototipi a bassa fedeltà.

Il prototipo viene realizzato a mano usando carta, matita, gomma, colla, Post-it, lucidi e pennarelli. Con questi strumenti vengono realizzati esempi di finestre, dialoghi, pulsantiere, pagine web, form HTML, radiobutton, checkbox, campi di testo, menu a cascata. Usando questa tecnologia vengono rapidamente (e senza aver bisogno di particolari competenze tecniche e strumenti tecnici) assemblate le pagine o le videate dell'applicativo che costituiscono l'ambito del prototipo.

Con un prototipo siffatto è possibile poi svolgere vari tipi di analisi. Lo si può esaminare per verificare quali principi di buona progettazione si sono violati (ad es. con il metodo della valutazione euristica). Lo si può anche usare per svolgere delle sessioni di user testing:

• fornendo una penna (o pennarello) all'utente, in modo da poter simulare la scrittura di testo o l'uso di un mouse
• chiedendo ad un nostro collaboratore di simulare il funzionamento di un computer e di realizzare la dinamica. Ad es. all'utente verrà fatta vedere una pagina, e lei simulerà l'attivazione di un link con la matita. A questo punto il collaboratore toglierà dal tavolo la pagina, e la sostituirà con quella destinazione del link attivato. In maniera simile si può simulare l'attivazione di un menu a cascata (il puntamento della matita fa sì che il collaboratore posizioni un Post-it con le voci del menu in una determinata posizione della pagina), la selezione di una voce da una combo-box (posizionando un Post-it ritagliato), l'immissione di testo in un campo di testo (permettendo all'utente di scrivere su un Post-it che verrà posizionato sul campo di testo oppure su un lucido posto sopra il disegno della videata), ecc.

Questo tipo di prototipo ci permette di validare alcune ipotesi di base relative alla UI come ad es. la struttura concettuale (la disposizione delle categorie, l'adeguatezza della vicinanza tra loro di determinate voci, di determinati comandi), la struttura dell'interazione (la disponibilità, in una determinata pagina, di tutto ciò che potrebbe essere necessario all'utente per completare o proseguire un compito), la comprensibilità di etichette (di menu, di categorie, di titoli, di link), la comprensibilità dei messaggi di errore, la comprensibilità del modello concettuale del sistema (cosa esso permette di fare, come i vari compiti si articolano, che tipo difeedback il sistema è in grado di offrire). Quindi, in questo modo, è possibile procedere a valutazioni sul contenuto del sito e sulla sua architettura informativa.

Con questo prototipo si possono svolgere dei confronti tra varie alternative di progetto e acquisire, oltreché delle osservazioni sul comportamento effettivo dell'utente, anche suoi giudizi e opinioni.

Questo prototipo però non ci permette di ottenere delle misurazioni su indici di prestazioni (ad es. il tempo necessario per completare un compito), non ci permette di simulare un gran numero di compiti o compiti molto complessi e variegati. Ed esso ovviamente non ci permette di valutare aspetti legati allo stile di presentazione delle informazioni (ciò riguarda anche molti aspetti di accessibilità della UI, ad esempio).

Figura 1: foto del prototipo cartaceo di una pagina di un'applicazione web per la gestione di dati clinici di pazienti

Gli strumenti usati e le competenze necessarie per realizzare questo tipo di prototipi sono molto limitati e assolutamente non vincolanti. In qualche caso è ragionevole pensare di disegnare alcuni componenti della UI al computer (con un programma di grafica o di creazione di presentazioni - ad es. Open Office - o di creazione di prototipi grafici - ad es. Visio), stamparli e ritagliarli.

Bisogna però sempre considerare che il vantaggio maggiore di questo tipo di prototipo è la facilità e velocità con cui il prototipo può essere modificato. Se durante una sessione di lavoro ci si accorge che un certo link manca in una pagina, basta sospendere la sessione di lavoro per 2 minuti, aggiungere il link nella pagina, e continuare l'analisi. Ogni artificio che viene aggiunto (ad es. la produzione delle pagine al computer per essere poi stampate e ritagliate) aumenta lo sforzo necessario a realizzare queste modifiche, e riduce proporzionalmente l'efficacia di questo prototipo.

Una variante di questi prototipi cartacei sono i prototipi statici, realizzati ad es. in HTML statico, oppure con un programma di creazione di presentazioni (es. Open Office). Essi permettono di ottenere una fedeltà maggiore su aspetti di presentazione (visuale) rispetto ai prototipi cartacei. Non catturano però alcun aspetto della dinamica di un sistema a meno che anche in questo non si simuli il computer selezionando a mano le pagine da visualizzare e simulando in qualche modo la possibilità per l'utente di interagire (attivando link, selezionando checkbox e radiobutton, immettendo testo, scegliendo voci da un menu). Questo aspetto rende questo tipo di prototipi poco utili, a meno che non vengano usati in una simulazione live come descritto poco fa.

Una ragione per sviluppare prototipi statici è la necessità di validare determinati contenuti, specie in siti web di tipo informativo che supportano il browsing. Questi prototipi consisteranno in pagine web dove la navigazione è limitata al massimo (e così pure la presentazione grafica), e l'enfasi è nella rappresentazione dei contenuti informativi del sito. Con queste pagine è possibile svolgere delle sessioni di test con degli utenti volte a determinare se quei contenuti sono adeguati (comprensibili, adatti, utili) agli utenti.

Un vantaggio non secondario dei prototipi a bassa fedeltà è che essi focalizzano l'attenzione sugli aspetti concettuali del sistema: le osservazioni che se ne ricavano sono molto spesso relative a cose che mancano, che non servono o che non si capiscono, piuttosto di commenti del tipo "questo non mi piace, preferisco quest'altro layout".

Prototipi a media fedeltà

Vengono realizzati con strumenti di prototipizzazione dove sia possibile implementare alcuni aspetti di dinamica. Gli strumenti più frequentemente usati sono pagine HTML associate a codice JavaScript oppure delle presentazioni (in Open Office o Powerpoint) a cui vengono associate delle macro. Quindi, a differenza dei prototipi a bassa fedeltà, il disegno della UI mediante calcolatore permette di ottenere una resa migliore e supporta la verifica di altre proprietà (ad es. se la gabbia grafica che si è utilizzata è adatta a contenere, come spazi e dislocazione spaziale, i contenuti che si sono previsti, per esempio un elenco di link disposti orizzontalmente).

Figura 2: la versione a media fedeltà della stessa pagina della figura precedente

Il fatto che si siano implementate alcune funzionalità, come ad es. il popolamento automatico di campi e controlli di una form, la validazione di alcuni controlli, la possibilità di seguire dei link, permette di verificare in maniera più fine l'effetto di queste interazioni sull'utente. Inoltre, in questo modo, è possibile simulare la connessione della UI al sistema di backend che si presuppone sia quello che produca ed elabori i dati forniti dall'utente. Ovviamente i dati che questo prototipo della UI permette di visualizzare ed elaborare saranno molto limitati come gamma, dato che nel prototipo non si saranno implementate tutte le funzionalità del sistema completo. Molto spesso i dati visualizzati dalla UI saranno sempre gli stessi, quasi sempre indipendenti da quelli immessi dall'utente, e quasi sempre fittizi.

Sub Vai
 oPage = ThisComponent.DrawPages.getByName("SecondaPagina")
 wait(2000) 'attendi 2 sec
 ThisComponent.getCurrentController.setCurrentPage(oPage)
End Sub 
      

La validazione che questo tipo di prototipi permette di svolgere può essere più fine di quelle dei prototipi a bassa fedeltà. Ad es. è possibile verificare:

• la dislocazione dei contenuti e dei controlli (pulsanti, link, campi, ...) nelle videate
• l'adeguatezza dei contenuti, delle categorie, delle etichette, delle interazioni rispetto ai compiti
• mediante think-aloud, l'adeguatezza della UI rispetto al modello mentale dell'utente
• determinate proprietà quantitative, come ad es. il tempo necessario per svolgere un compito -- in questo caso il prototipo provvederà ad aggiungere dei ritardi fittizi; oppure il numero di azioni necessarie; la facilità di recupero da errori; ecc.

Lo sviluppo di prototipi a media fedeltà è necessario per svolgere queste verifiche in tutti i casi in cui i prototipi a bassa fedeltà abbiano già supportato alcune verifiche precedenti e si abbia la necessità di approfondirle. Inoltre, se non sono stati usati prototipi a bassa fedeltà, allora è altamente consigliabile lo sviluppo di prototipi a media fedeltà.

Ovviamente nel realizzare tali prototipi bisognerà considerare il rapporto costo/beneficio: maggiore il numero delle funzionalità che si includeranno, e/o più complete esse saranno, e migliore sarà il prototipo (più fedele a quello che sarà il sistema).

Però aumenteranno considerevolmente le risorse investite nel prototipo (tempo, competenze, persone) e aumenterà considerevolmente la difficoltà di modifica del prototipo, rischiando di vanificarne lo scopo.

La costruzione di questo tipo di prototipi richiede delle competenze, che sebbene non siano avanzate, sono comunque più sofisticate di quelle necessarie per disegnare, ritagliare e incollare pezzi di carta. In ogni caso sia PowerPoint che OpenOffice offrono un ambiente molto semplice da usarsi per scrivere delle macro, e le macro che serve scrivere sono a loro volta alla portata di chiunque abbia scritto qualche programma, fosse in PHP o JavaScript.

Prototipi ad alta fedeltà

Si tratta di sistemi in cui la UI è in parte già sviluppata con la stessa tecnologia che verrà adottata nel sistema finale, ed essa interagisce già con un sistema \emph{backend} funzionante, almeno in parte. Ad es. se stiamo pensando ad un sistema basato su web per la ricerca e prenotazione di voli su aerei di linea, un prototipo ad alta fedeltà includerà una UI scritta in HTML, JavaScript e un sistema backend scritto in ASP, JSP o altro che include anche una base di dati.

Lo scopo di un prototipo ad alta fedeltà è di permettere una validazione più completa della UI, dell'interazione e dei dati accettati e forniti dal backend. Solo con questo tipo di prototipo si possono validare in maniera completa tutti quei compiti dove non poniamo vincoli all'utente per quanto riguarda i dati immessi.

Ovviamente, siccome la costruzione di questo tipo di prototipo è molto più costosa degli altri due, è necessario aver già validato con altri prototipi le ipotesi di progetto fondamentali: adeguatezza delle funzionalità, modello concettuale, schema delle interazioni, modello dei compiti, stile di interazione.

Con prototipi ad alta fedeltà si possono sperimentare diverse articolazioni di un determinato compito, diversi stili visuali dell'interfaccia. Si possono altresí sperimentare le soluzioni legate all'accessibilità (che con prototipi a bassa e media fedeltà non sono possibili).

La costruzione di un prototipo ad alta fedeltà richiede che si sia progettato e in parte costruito anche il sistema di backend, e quindi ciò richiede competenze di informatica specifiche. D'altro canto bisogna considerare che una volta progettato e costruito il backend ci sarà una notevole resistenza a cambiarne modalità di funzionamento o spettro di funzionalità che esso offrirà. Anche se l'esito della sperimentazione svolta sarà negativo, e suggerirà di apportare tali modifiche.

È per questo che è importante verificare in altro modo, più conveniente, la validità del modello concettuale del sistema prima di accingersi a progettare e realizzare il sistema di backend.

Che aspetti coprire con un prototipo?

Un prototipo potrà coprire tutto lo spettro di contenuti e funzionalità dell'applicazione, ma ad un livello minimo di profondità (prototipo orizzontale) oppure potrà coprire poche funzionalità, ma trattarle in maniera approfondita (prototipo verticale). Il prototipo orizzontale permette di verificare la comprensione, visibilità, orientamento dell'utente di fronte a tutti i contenuti e tutte le funzionalità potenzialmente offerte dal sistema; quello verticale invece permette di verificare l'usabilità di specifici compiti (solo quelli che la parte di UI realizzata supporta). Nel caso di un prototipo verticale si tratta di decidere quali aree della UI andare a coprire, e fino a che livello di profondità e fedeltà.

Una risposta generale alla domanda di quale tipo di prototipo costruire non esiste, se non che si può seguire uno dei seguenti criteri per aiutarsi nella scelta che ovviamente dipende pesantemente dal motivo per cui costruiamo il prototipo:

1. realizzazione di un prototipo che copra i compiti meno compresi, in modo da usare il prototipo per ridurre in parte l'incertezza; alternativamente si potrebbero coprire quei compiti che si sono compresi meglio al fine di validarli;
2. scelta dei compiti più (o meno) complessi, al fine di ridurre incertezze o validarli; in questo caso i compiti meno complessi richiederanno un prototipo relativamente più semplice;
3. scelta dei compiti più frequentemente usati dagli utenti, in modo da ridurre incertezza o da validare quella parte della UI.

Per riassumere

Nella gestione di un prototipo bisogna:

1. decidere a quale scopo lo si sviluppa, e quindi ciò ne determina il tipo (dimostratore, esplorativi della UI o della tecnologia)
2. decidere il livello di dettaglio (a bassa/media/alta fedeltà), e ciò determina il tipo di proprietà che potranno essere analizzate e validate tramite il prototipo
3. investire nello sviluppo del prototipo tutto quello che serve, ma non di più, dato che alla fine della fase di indagine esso verrà sostituito da uno nuovo
4. in nessun caso pensare di riutilizzare parti del prototipo nel sistema finale; le parti potranno sì essere riutilizzate, ma in altri prototipi, nel contesto di uno sviluppo iterativo del sistema
5. proprio per queste ragioni, nello sviluppare il prototipo privilegiare sempre la facilità di modifica del prototipo piuttosto di altre caratteristiche (ad es. prestazioni, robustezza, gradevolezza grafica, affidabilità, ecc.).

Approfondimenti

L'uso di prototipi viene ampliamente discusso in Goto e Cotler, 2002, Preece, Rogers e Sharp, 2002, Rosson e Carol, 2002, Goto e Cotler, 2002, Mayhew, 1999, Rubin 1996, Newman e Lamming, 1996. La pagina di Klee, 2000 propone alcuni utili stratagemmi nel gestire prototipi di bassa fedeltà.

• Goto, Kelly e Cotler, Emily, Web redesign: Strumenti e metodi per la riprogettazione di un sito Web, Apogeo, 2002, ISBN: 88-7303-968-5
• Rosson, M. e Carrol, J., Usability Engineering: Scenario--based development of human--computer interaction, Morgan Kaufmann, 2002
• D. Mayhew, The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design, Morgan Kaufmann, 1999
• J. Preece e Y. Rogers and H. Sharp, Interaction design, John Wiley and Sons, 2002
• W.M. Newman e M.G. Lamming, Interactive system design, Addison-Wesley, 1996
• Matthew Klee, Five Paper Prototyping Tips, www.uie.com/articles/prototyping_tips/, 2000
• Jeffrey Rubin, Handbook of usability testing, John Wiley and Sons, Technical Communication Library, 1994