Concetto: Progettazione incentrata sull'utente
La progettazione incentrata sull'utente è una progettazione dell'applicazione che considera le esigenze e l'efficacia dell'utente finale come preminenti.
Descrizione principale

Cos'è la progettazione incentrata sull'utente?

Non esiste una linea comune sulla definizione di cosa costituisce una progettazione incentrata sull'utente. Tuttavia, John Gould ed i suoi colleghi in IBM hanno sviluppato un approccio negli anni 80 denominato Progettazione per l'utilizzabilità [GOU88], che comprende la maggior parte delle definizioni comunemente accettate. Si è sviluppato dall'esperienza pratica su diversi sistemi interattivi, il più noto il sistema IBM di messaggistica delle olimpiadi del 1984 (IBM Olympic Messaging System) [GOU87]. L'approccio è formato da quattro componenti principali, descritti di seguito.

Focalizzazione sugli utenti

Gould suggerisce che gli sviluppatori devono decidere chi saranno gli utenti e di coinvolgerli alla prima opportunità possibile. Suggerisce diversi modi per familiarizzare con gli utenti, le loro attività ed i loro requisiti:

·    Parlare con gli utenti.

·    Visitare le ubicazioni del cliente.

·    Osservare gli utenti che lavorano.

·    Videoregistrare gli utenti che lavorano.

·    Informarsi sull'organizzazione del lavoro.

·    Mettersi alla prova.

·    Fare in modo che gli utenti pensino ad alta voce mentre lavorano.

·    Progettazione partecipativa.

·    Includere gli utenti esperti sul team di progettazione.

·    Eseguire un'analisi dell'attività.

·    Utilizzare le valutazioni e i questionari.

·    Sviluppare obiettivi testabili.


 Nel RUP (Rational Unified Process), i workshop vengono utilizzati in diverse fasi chiave, ma devono essere completati dai tipi di attività descritte da Gould, qualora si desiderasse creare una descrizione precisa. (Fa parte dell'argomento anche il fatto che la gente descrive spesso le proprie azioni in modo abbastanza diverso rispetto al modo in cui le esegue. Le attività comunemente eseguite e i dettagli apparentemente insignificanti come la collocazione del lavoro o l'esistenza di "misteriosi" pezzi di carta vengono spesso dimenticati o omessi perché non fanno ufficialmente parte del processo corrente).

Progettazione integrata

Si consiglia di eseguire le attività di utilizzo in parallelo all'inizio dello sviluppo. Tali attività includono la creazione di bozze dell'interfaccia utente e delle guide per l'utente o della guida in linea. Gould sottolinea inoltre che l'utilizzabilità dovrebbe essere responsabilità di un gruppo.  

Una caratteristica importante della progettazione integrata è che l'approccio generale - il framework - per   la progettazione dell'interfaccia utente dettagliata viene sviluppato e testato in una fase iniziale. Questa è una differenza importante tra la progettazione incentrata sull'utente e altre tecniche puramente incrementali. Essa assicura che la progettazione incrementale attuata in fasi successive si adatta facilmente al framework e che l'interfaccia utente sia consistente in aspetto, terminologia e concetto.

All'interno del RUP, è possibile stabilire questo framework utilizzando un modello di dominio per assicurare che tutta la terminologia e i concetti che verranno visualizzati nell'interfaccia utente sono conosciuti e vengono compresi all'interno del business in generale e dagli utenti in particolare. (Vi saranno anche sottoserie del modello di dominio rilevanti solo per specifici gruppi di utenti. Prestare attenzione per assicurare che il modello del dominio sia organizzato in modo che tali sottoserie possano essere identificate con facilità). Con l'avanzamento della progettazione dell'interfaccia utente, molte delle classi di dominio verranno rappresentate come elementi dell'interfaccia utente. Tali elementi e le relazioni tra di loro dovrebbero essere coerenti con il modello del dominio e dovrebbero essere rappresentati coerentemente per tutte le parti del sistema in fase di progettazione. (In questo modo non solo si fornisce assistenza agli utenti, ma si migliora anche il riutilizzo dei componenti dell'interfaccia utente).

Verifica iniziale dell'utente

Verifica iniziale dell'utente indica la creazione iniziale di uno storyboard e lo sviluppo iniziale dei prototipi poco fedeli. I prototipi più fedeli compariranno in un secondo momento del processo.

E' possibile utilizzare gli storyboard insieme ai casi d'uso per scrivere scenari concreti da utilizzare per il sistema in fase di progettazione. Tali storyboard possono acquisire il formato narrativo o narrativo illustrato (utilizzando i modelli dell'interfaccia utente come esempi). Essi, insieme ai sondaggi (con gli utenti) e ai gruppi di focalizzazione degli utenti, sono approcci che potrebbero non risultare familiari per molti sviluppatori di software. Tuttavia, sono chiaramente più efficaci in termini di costi rispetto alla rilevazione di una progettazione inappropriata o dei requisiti fraintesi una volta che l'implementazione è in corso.

Progettazione iterativa

Lo sviluppo OO (Object-oriented) è diventato sinonimo di un processo iterativo. La progettazione iterativa è adatta a problemi che necessitano di un perfezionamento di conoscenza e presentano requisiti mutevoli. Senza alcuna sorpresa, la progettazione iterativa è un componente chiave della progettazione incentrata sull'utente. Ciò è, in parte, dovuto alle esigenze variabili degli utenti nel tempo, ma anche alla complessità inerente della produzione di soluzioni di progettazione che possano soddisfare diverse richieste.

Tenere presente che in metodi incentrati sull'utente, le progettazione iterativa avviene all'interno di un framework integrato. Viene deliberatamente evitato uno sviluppo incrementale, al di fuori di un framework concordato, che potrebbe condurre a una soluzione temporanea.

Perché la progettazione incentrata sull'utente?

Rispetto delle esigenze dell'utente

I sistemi interattivi affidano il proprio successo alla capacità di soddisfare le esigenze degli utenti. Ciò significa non solo identificare diverse comunità di utenti, ma anche riconoscere la gamma di skill, esperienza e preferenze dei singoli.

Sebbene sia allettante per sviluppatori e responsabili percepire di avere compreso le esigenze dell'utente, ciò avviene raramente nella pratica. L'attenzione è, spesso, incentrata sul modo in cui gli utenti dovrebbero eseguire le attività, anziché su come preferiscono farlo. In diversi casi, la questione delle preferenze è molto più che avere il pieno controllo, sebbene sia importante in se stessa. La preferenza verrà anche determinata dall'esperienza, dalla capacità e dal contesto d'uso. Tali questioni sono considerati sufficientemente importanti per il processo di progettazione, al fine di garantire uno standard internazionale, [ISO 13407], intitolato human-centered design processes for interactive systems. Le questioni standard e correlate vengono discusse in termini generali nel resto della presente pagina.

Progettazione dell'interfaccia utente

Gli utenti comprendono e interagiscono con un sistema tramite la relativa interfaccia utente. I concetti, le immagini e la terminologia presentata nell'interfaccia deve essere adeguata alle esigenze degli utenti. Ad esempio, un sistema che consenta ai clienti di acquistare i propri biglietti sarà completamente differente rispetto a uno utilizzato professionalmente dallo staff di vendita dei biglietti. Le differenze principali non sono nei requisiti o nei casi d'uso dettagliati, ma nelle caratteristiche degli utenti e negli ambienti in cui opera il sistema.

L'interfaccia utente deve inoltre provvedere a una gamma potenzialmente ampia di esperienze almeno lungo le due dimensioni, esperienza del computer e del dominio, come viene mostrato nella figura 1, riportata di seguito. L'esperienza del computer include non solo la familiarità generale con i computer, ma anche l'esperienza del sistema in fase di sviluppo. Gli utenti con scarsa esperienza dei computer o del dominio del problema, mostrati nel vicino angolo sinistro della figura, richiederanno un approccio sostanzialmente differente nell'interfaccia utente rispetto agli utenti esperti, mostrati nel lontano angolo destro.

Diagramma descritto nel testo di accompagnamento.

Figura 1: Gli effetti dell'esperienza del computer e del dominio sulla facilità di apprendimento rispetto alla facilità d'uso

Considerare che non è scontato affermare che gli utenti inesperti diventeranno esperti con il tempo. Diversi fattori potrebbero contribuire ad impedire ciò, ad esempio una frequenza scarsa di utilizzo, una scarsa motivazione o un'elevata complessità. Di contro, è possibile che alcuni sistemi dispongano di utenti generalmente esperti. In questo caso i fattori potrebbero essere addestramento, elevata frequenza di utilizzo o buona motivazione (dipendenza dal lavoro). Alcune di tali questioni e i relativi effetti sulla progettazione dell'interfaccia utente sono mostrati nella Tabella 1.

 

Scarsa

Elevata

Esperienza del computer

Stile dell'interfaccia di menu o web (con collegamento ipertestuale) semplice, con compilazione moduli e domanda e risposta semplice

Stile dell'interfaccia di menu o web (con collegamento ipertestuale) complesso, compilazione moduli complessa (la compilazione moduli semplice o a domanda e risposta sarebbe molto frustrante per utenti esperti)

Esperienza del dominio

Concetti e terminologia comuni

Concetti e terminologia specifici del dominio

Addestramento

Incentrato sulla facilità di apprendimento (coerente, prevedibile, memorabile)

Incentrato sulla facilità d'utilizzo (diretto, personalizzabile, non invadente)

Frequenza di utilizzo

Semplice da imparare e da ricordare, stile dell'interfaccia semplice

Semplice da utilizzare, tecniche e collegamenti multipli per consentire il controllo dell'utente

Motivazione

Soddisfacente da utilizzare, potente senza sembrare complesso.

Sofisticato con numerose funzioni avanzate e personalizzabili.


Tabella 1, Alcuni fattori che influiscono sulla progettazione dell'interfaccia utente

I sistemi interattivi devono essere progettati per soddisfare una gamma apposita di circostanze e di esperienze dell'utente o è necessario effettuare alcune fasi per restringere l'universo della progettazione. Ad esempio, è possibile utilizzare l'addestramento per ridurre il requisito per la semplicità di apprendimento in un sistema complesso. In alternativa, è possibile ridurre l'ambito di un sistema affinché soddisfi meglio i requisiti principali dei relativi utenti (un suggerimento viene fornito da Alan Cooper nel suo libro The Inmates Are Running the Asylum [COO99]).

Legislazione e standard

Come parte della progettazione incentrata sull'utente, occorre considerare gli skill e gli attributi fisici degli utenti. Tali questioni stanno diventando sempre più parte della legislazione. Essa si rivolge principalmente agli utenti con particolari esigenze. Tuttavia, rendere il sistema accessibile a una gamma più vasta di utenti è vantaggioso per l'intera comunità di utenti.

La tabella seguente mostra le risorse e la legislazione di rilievo per diverse parti del mondo:

Descrizione Sito Web

AUSTRALIA

 
Disability Discrimination Act http://www.hreoc.gov.au/disability_rights/dda_guide/dda_guide.htm
Disability Rights http://www.hreoc.gov.au/disability_rights/index.html

EUROPA

 
European Disability Forum http://www.edf.unicall.be

REGNO UNITO

 
Disability Discrimination Act http://www.hmso.gov.uk/acts/acts1995/1995050.htm
New Deal for Disabled People http://www.disability.gov.uk
Digital Access Campaign http://www.rnib.org.uk/digital/welcome.htm

NAZIONI UNITE

 
United Nations Standard Rules on the Equalization of Opportunities for Persons with Disabilities http://www.un.org/esa/socdev/enable/dissre00.htm
Social Development Information on the Internet http://www.unescap.org/esid/psis/disability/index.asp

STATI UNITI

 
Americans with Disabilities Act (ADA): US Department of Justice http://www.usdoj.gov/crt/ada/
Section 508 of the Workforce Investment Act: US Department of Justice http://www.usdoj.gov/crt/508/508home.html 
US Access Board Electronic and Information Technology Advisory Committee (EITAAC) http://www.access-board.gov 
World Wide Web Consortium Web Accessibility Campaign http://www.w3.org/wai/ 

ALTRE RISORSE

 
Disability-Related Internet Resources http://www.disabilityresources.org

 Tabella 2a, Legislazione relativa alle inabilità per paese, regione o gruppo di nazioni

A parte la legislazione, la progettazione incentrata sull'utente e dell'interfaccia utente stanno diventando sempre più il soggetto della standardizzazione, come mostrato di seguito.

Descrizione Standard/Siti Web

ANSI

www.ansi.org

ANSI

ANSI-HFES

ANSI-NSC

ANSI e Human Factors and Ergonomics Society hanno pubblicato diversi standard congiunti. ANSI dispone inoltre di un ANSI-NSC Z365 correlato al controllo e alla prevenzione dei disturbi di stress cumulativi (noti anche come RSI o (repetitive strain injury)).

ANSI sta creando delle bozze di standard relativi all'interazione computer-uomo come parte dell'IISP (Information Infrastructure Standards Panel).

ISO

www.iso.ch
ISO 9241 Una vasta serie di standard attinente principalmente con l'ergonomia delle workstation, ma che include anche una guida all'utilizzo. Inoltre, le basi per ANSI-HFES 200, in fase di sviluppo.
ISO 10075: 1991 Principi ergonomici relativi al carico di lavoro mentale
ISO 17041-1: 1995 Controllo del cursore per la modifica del testo
ISO 11581 Serie nello sviluppo per la gestione di icone e puntatori.
ISO 13407: 1999 Standard per processi di progettazione incentrati sull'utente, per i sistemi interattivi.

 Tabella 2b, interfaccia utente ISO e ANSI e standard di progettazione incentrata sull'utente

Progettazione incentrata sull'utente nel RUP

Lo sviluppo di sistemi adeguati alle esigenze dell'utente significa un impegno notevole nell'analisi dei requisiti. In una progettazione incentrata sull'utente, questo impegno è incentrato sugli utenti finali.

La disciplina Modellazione business include la modellazione dei dipendenti (per coloro che si trovano all'interno del business) e e degli attori del business (per coloro che sono all'esterno del business).

Un punto di enfasi sostanziale nella progettazione incentrata sull'utente è che si comprendono i requisiti della gente reale che assume i ruoli descritti nei prodotti di lavoro menzionati in precedenza. In particolare, occorre evitare la progettazione di persone ipotetiche per cui conviene progettare i sistemi software. I prodotti di lavoro che descrivono gli utenti devono essere scritti solo dopo un sostanziale contatto diretto con gli utenti. Nella progettazione incentrata sull'utente, il contatto diretto fa parte di un processo chiamato, a volte, richiesta contestuale. Hugh Beyer e Karen Holtzblatt (nel loro libro Contextual Design, [BEY98]) descrivono la premessa della richiesta contestuale come:

"...andare dove lavora il cliente, osservarlo mentre lavora e chiedergli informazioni sul lavoro che fa."

(Alcuni esempi concreti di tale situazione sono già stati elencati in Focalizzazione sugli utenti). Questo approccio viene utilizzato per avere non solo una migliore conoscenza dei requisiti di sistema, ma anche degli utenti stessi, delle loro attività e dei loro ambienti. Ognuno ha i propri attributi che, nel complesso, vengono indicati come contesto di utilizzo. Essi sono dettagliati nello standard ISO per la progettazione incentrata sull'utente, descritta di seguito.

Contesti di utilizzo

Human-centered design processes for interactive systems di ISO [ISO13407] identifica il primo passo nella progettazione come comprensione e specifica del contesto di utilizzo. Gli attributi suggeriti sono:

Contesto Attributi

Attività

Gli obiettivi di utilizzo del sistema, la frequenza e la durata delle prestazioni, le considerazioni sullo stato e sulla sicurezza, assegnazioni di attività, le fasi operative tra le risorse umane e tecnologiche. Le attività non dovrebbero essere descritte esclusivamente in termini delle funzioni o caratteristiche fornite da un prodotto o da un sistema.

Utenti (per ogni differente tipo o ruolo)

Conoscenze, skill, esperienza, istruzione, addestramento, attributi fisici, abitudini, preferenze, capacità.

Ambienti

Materiali hardware, software; ambienti fisici e sociali, standard pertinenti, ambiente tecnico, ambiente generico, ambiente legislativo, ambiente sociale e culturale


Tabella 3: Contesto di utilizzo dallo standard ISO per una progettazione incentrata sull'utente

E' utile suddividere il contesto dell'utente in due parti costituenti (ruolo e tipo di utente) e, quindi, considerare le relazioni tra tutti e quattro di contesti:

Diagramma descritto nel testo di accompagnamento.

Figura 2: Relazioni tra contesti

La figura 2 mostra che ogni attività viene eseguita in un ruolo eseguito da un utente all'interno di un ambiente. Tali contesti corrispondono ai prodotti di lavoro del RUP, come mostrato nella Tabella 4.

Contesto ISO 13407 Prodotti di lavoro del RUP

Ambienti

Utenti

Ruoli

  • Livello elevato:
    • Attore di business (utenti esterni), 
    • Lavoratore o sistema di business (utenti interni)
  • Dettagliata:

Attività


 Tabella 4, contesti standard di progettazione incentrata sull'utente ISO e relativi prodotti di lavoro del RUP prodotti di lavoro

Ognuno di tali contesti potrebbe avere un impatto significativo sulla progettazione di un'apposita interfaccia utente. Come risultato, ci si trova di fronte a un numero potenzialmente elevato di permutazioni. Anche per un sistema piccolo, è possibile che esistano 2 ambienti (ad esempio un sito ufficio e un sito del cliente), 3 tipi di utente (neofita delle vendite, esperto delle vendite e gestione) e 6 ruoli (assistente telefonico alle vendite, rappresentante delle vendite esterno, ecc.) . Ciò significa fino a 36 variazioni potenziali per attività, sebbene la serie di combinazioni realistiche è, generalmente, molto più limitata.

Chiaramente, occorre descrivere le attività singolarmente, ma è improbabile che una descrizione singola sia appropriata per tutte le permutazioni. Un approccio è la scomposizione dei contesti utente e ambiente nella descrizione del ruolo. Questa è la soluzione adottata da Constantine e Lockwood [CON99]. Esso comprende la fornitura di un "ruolo utente" separato per ogni permutazione di ruolo, utente e ambiente significativa, quindi la denominazione del ruolo utente risultante con una frase descrittiva, anziché con un semplice nome. Confrontare, ad esempio, il ruolo "Cliente" con i ruoli utente "Cliente casuale", "Cliente Web", "Cliente consueto" e "Cliente avanzato".

Ogni descrizione del ruolo utente include i dettagli del ruolo stesso e i relativi utenti (denominati titolari dei ruoli) e ambiente. E' possibile adottare questo approccio con il RUP, selezionando gli attori che corrispondono ai ruoli utente.

Scenari, Casi d'uso e Casi d'uso essenziali

I termini Scenari, Casi d'uso e Casi d'uso essenziali presentano un grado di sovrapposizione confusionario e vengono utilizzati in approcci di progettazione differenti per indicare concetti lievemente differenti. Ad esempio, all'interno del RUP, "scenario" indica un'istanza del caso d'uso; semplicemente un percorso specifico attraverso i possibili flussi alternativi e di base. Tuttavia, è frequente trovare metodi di progettazione dell'interfaccia utente e incentrata sull'utente che descrivono gli scenari come storie di utilizzo, contenenti sostanzialmente più dettagli rispetto al semplice flusso di eventi. Sebbene queste informazioni aggiuntive possano essere irrilevanti in fasi di progettazione successive, non fanno parte della comprensione di utenti, attività e ambienti. Di conseguenza, è possibile utilizzare gli scenari in modo estensivo (in Creazione di storyboard e Interpretazione del ruolo) nella disciplina Modellazione business, ma l'attenzione si sposta verso i Casi d'uso nella disciplina Requisiti.

La figura 3 mostra la natura di questa sovrapposizione. La scala nella parte superiore incorpora una serie di fattori differenti che tendono a variare insieme. Ad esempio, man mano che lo scopo si sposta verso i requisiti, la struttura diventa, generalmente, più formale. I casi d'uso essenziali vengono mostrati a destra dei casi d'uso generici, perché i ruoli dell'utente li rendono più specifici (consultare la sezione precedente) e hanno una struttura più formale.

Diagramma descritto nel testo di accompagnamento.

Figura 3: Sovrapposizione nei concetti tra scenari e casi d'uso nella progettazione incentrata sull'utente

Le differenze tra i casi d'uso di sistema e i casi d'uso essenziali vengono illustrate meglio tramite un esempio.   La tabella 5 mostra un caso d'uso dal Software for Use di Constantine e Lockwood [CON99]:

Azione dell'utente Risposta del sistema
inserimento della carta lettura della striscia magnetica
richiesta codice pin
immissione PIN verifica PIN
visualizzazione menu di opzioni transazione
pressione tasto visualizzazione menu del conto
pressione tasto interrogazione del conto
immissione dell'importo visualizzazione dell'importo
pressione tasto restituzione della carta
prelievo della carta distribuzione dei contanti
acquisizione dei contanti  

Tabella 5: Caso d'uso generico per il prelievo di contanti da uno sportello automatico

Questo esempio descrive in dettaglio la sequenza di eventi tra l'attore e il sistema, con la linea verticale tra le due colonne che rappresenta l'interfaccia dell'utente. Tenere presente che Constantine e Lockwood consigliano questo stile per casi d'uso essenziali e questo caso d'uso particolare non è uno essenziale. La ragione è che si basa sul dettaglio sintattico dell'interazione. Ossia, su come avviene l'interazione. Un caso d'uso essenziale è incentrato su cosa riguarda l'interazione (indicato come semantica). La tabella 6 è la versione essenziale dell'interazione.

Intenzione dell'utente Responsabilità del sistema
identificazione di se stesso verifica dell'identità
offerta di opzioni
selezione distribuzione dei contanti
acquisizione dei contanti  

Tabella 6: Caso d'uso essenziale per il prelievo di contanti da uno sportello automatico

Questo caso d'uso acquisisce l'essenza dell'interazione di acquisizione contanti. Le intestazioni Azione dell'utente e Risposta del sistema sono state sostituite da Intenzione dell'utente e Responsabilità del sistema per rispecchiare la modifica di enfasi. Una buona progettazione dell'interfaccia è incentrata sulle intenzioni e sugli obiettivi dell'utente; questi sono spesso nascosti nei casi d'uso convenzionali.  I casi d'uso essenziali sono particolarmente utili nelle seguenti situazioni:

  • esistono pochi vincoli di progettazione (ad esempio, il vincolo di progettazione implicato dell'utilizzo delle carte di credito è falso)
  • il sistema può essere migliorato per utilizzare altri mezzi di identificazione (ad esempio un tipo di accesso internet sicuro)
  • vi è la volontà di creare casi d'uso senza vincoli di progettazione, per un potenziale riutilizzo in progetti che mancano di tali vincoli

Tuttavia, i casi d'uso essenziali hanno i propri svantaggi. I casi d'uso perfettamente lineari, come quello della tabella 5, possono essere soggetti a un dibattito considerevole quando succede di estrarne l'essenza. Ad esempio, l'inserimento di una carta identifica il cliente o il conto? Nella maggior parte degli sportelli automatici esistenti, è il secondo, sebbene Constantine e Lockwood abbiano scelto di interpretare ciò come identificazione del cliente. Ciò potrebbe essere stata una decisione deliberata alla luce di una tecnologia più recente, come ad esempio l'identificazione delle impronte digitali o la scansione della retina o potrebbe essere stata una disattenzione. Le conseguenze, in questo caso, consistono in una ulteriore scelta che deve essere attuata dai clienti che posseggono più di un conto.

Un'altra difficoltà presentata dai casi d'uso essenziali è che non sono adatti per l'analisi con utenti e altri stakeholder, a causa della loro natura astratta. Una parte di questo problema deriva dalla necessità di convertire i casi d'uso essenziali in una forma completa che rappresenti le azioni dell'utente. Una volta che un modello di progettazione è disponibile, ciò può essere effettuato scrivendo scenari che descrivano l'interazione in termini concreti (simili in concetto a una realizzazione del caso d'uso, sebbene attinenti all'interazione del sistema dell'utente anziché alla collaborazione interna dell'oggetto.

Riepilogando, la creazione di casi d'uso essenziali potrebbe non essere una buona idea nelle seguenti situazioni:

  • le tecnologie dell'interfaccia utente sono intenzionalmente forzate (ad esempio, il sistema deve accettare le carte di credito)
  • il tempo necessario affinché gli utenti comprendano i casi d'uso più astratti è più importante rispetto ai vantaggi previsti.

Casi d'uso essenziali nel RUP

Il RUP non si riferisce esplicitamente ai casi d'uso essenziali, ma nell'Attività: Progettazione dell'interfaccia utente, i casi d'uso essenziali vengono utilizzati come punto di partenza, quindi sviluppati e aumentati con i requisiti di utilizzo per creare degli Storyboard, come spiegato nella Linea guida: Storyboard.  

Ciò significa la rimozione di tutti i dettagli di implementazione correnti o di progettazione, in modo che rimanga solo la semantica, il significato dell'interazione.  Quindi, dal momento che vengono esplorate varie alternative di progettazione, i dettagli sintattici, ossia la modalità con cui l'interazione ha luogo, vengono aggiunti al caso d'uso essenziale come tipo di realizzazione.  (Ogni progettazione alternativa è, in effetti, una realizzazione dello stesso caso d'uso essenziale).

E' quindi possibile utilizzare gli storyboard come input per l'Attività: Creazione di prototipi dell'interfaccia utente per sviluppare il Prototipo dell'interfaccia utente.