3.2. Dai bisogni degli utenti alle user stories¶
Queste linee guida sono superate
- I riferimenti attuali sono:
le Linee guida di design per i siti e i servizi digitali della PA emesse a norma CAD ex. Art 71 e riferimento normativo in vigore;
il Manuale operativo di design e le altre risorse messe a disposizione come strumento a supporto della Pubblica Amministrazione e dei suoi fornitori dal progetto Designers Italia.
In particolare, i punti di partenza da cui avviare l’attività di progettazione possono essere sintetizzati in alcuni strumenti operativi che abbiamo affrontato nel capitolo delle Linee Guida dedicato al service design:
personas, ossia profili verosimili di utenti del servizio delineati in base ai risultati della ricerca, rappresentativi di un gruppo di utenti;
user journey, ossia la rappresentazione del percorso compiuto dall’utente interagendo con i touchpoint fisici o digitali del servizio, elaborata a partire dai personas e dalle loro esperienze d’uso del servizio in questione.
In questo capitolo faremo un passo in avanti, introducendo strumenti come le user stories e gli scenari d’uso. Questi elementi ci aiutano a concentrarci sulle persone che useranno il servizio, ad assumere il loro punto di vista e avere una lista chiara dei loro bisogni, evidenziando priorità e possibili criticità. Sulla base di user stories e scenari, procederemo poi alla fase di prototipazione vera e propria.
Storyboard e scenari d’uso, attraverso una sintesi dei dati di ricerca, permettono di definire soluzioni progettuali che tengono al centro le personas: descrivono in modo realistico la sequenza di azioni che queste compiono all’interno del servizio, identificando e mettendo in ordine di priorità le caratteristiche più importanti dal loro punto di vista. Si tratta di una narrazione macroscopica, non troppo dettagliata: una sorta di sceneggiatura all’interno della quale, con un approccio più analitico, si possono generare le user stories. All’interno di uno scenario possono esistere più user stories, che specificano con maggior dettaglio un preciso caso d’uso del servizio.
Scuola - Esempi di scenari d’uso del servizio |
|
---|---|
Iscrizione all’asilo nido |
|
Scelta dell’istituto scolastico |
|
Pagamento servizi scolastici |
|
Comuni - Esempi di scenari d’uso |
|
Archivio documenti personali (contravvenzioni) |
|
Rinnovo documenti |
|
Pagamento tributi |
|
Le user stories sono una descrizione informale delle funzioni di un servizio, espressa dal punto di vista dell’utente secondo una struttura che definisce il ruolo di chi la esprime, l’azione che vuole o deve compiere e l’obiettivo che muove all’azione:
Io come [personas] vorrei [funzione] per [bisogno].
Le user stories facilitano la comprensione delle caratteristiche richieste al servizio per tutti i membri del team al lavoro sul progetto. Per non perdere di vista il quadro generale possono essere organizzate per scenari d’uso (vedi sopra) o story map, ovvero mappe in cui raggruppare le user stories in base al tema o al tipo di attività, ordinandole per priorità.
I bisogni e le funzioni individuati grazie ai risultati della ricerca sugli utenti sono un’ottima base per definire le user stories.
Il kit per gli scenari e le user stories
Ecco una lista di esempi di alcune risposte (funzioni) ai bisogni degli utenti del sito di una scuola o di un comune, espressi in termini di user stories.
Scuola |
|||
---|---|---|---|
Personas |
Bisogni |
Funzioni |
User stories |
Genitore |
Iscrivere mio figlio all’asilo nido |
Compilare online il modulo on line per l’iscrizione |
Io come genitore vorrei compilare on line il modulo per iscrivere mio figlio al nido |
Scegliere la scuola migliore per mio figlio |
Confrontare on line i diversi istituti scolastici |
Io come genitore vorrei confrontare online le scuole secondo parametri oggettivi, in modo da scegliere la scuola migliore per mio figlio |
|
Assicurare pasto e merenda ai propri figli mentre sono a scuola |
Attivare e pagare online del servizio mensa in modo rapido e sicuro |
Io come genitore vorrei poter attivare e pagare online l’iscrizione al servizio mensa, in modo da assicurare pasti a mio figlio quando è a scuola |
|
Comune |
|||
Personas |
Bisogni |
Funzioni |
User stories |
Cittadino |
Controllare le contravvenzioni ricevute |
Visualizzare l’elenco delle multe in una pagina personale |
Io come cittadino vorrei accedere a una pagina web riservata dove controllare le contravvenzioni che ho ricevuto |
Rinnovare la carta di identità |
Prenotare on line l’appuntamento per il rinnovo nel Comune di residenza |
Io come cittadino vorrei prenotare online l’appuntamento all’ufficio comunale, in modo da rinnovare la mia carta d’identità |
|
Essere in regola con il pagamento della tassa sui rifiuti (TARI) |
Effettuare il pagamento on line della TARI in modo facile e sicuro. |
Io come cittadino vorrei poter pagare i servizi pubblici online in modo facile e sicuro, inclusa la TARI, in modo da essere in regola con i pagamenti |
Un metodo simile al precedente prevede la mappatura delle funzioni del sistema concentrandosi sui due profili di utilizzatore - l’utente finale e il gestore del servizio - corrispondenti al front-end e al back-end del sistema. Questo approccio favorisce la creazione di una relazione chiara tra la progettazione dell’interfaccia utente e quella delle funzioni che permettono di abilitare il servizio.
BISOGNI |
FUNZIONI PER GLI UTENTI DI FRONTEND |
FUNZIONI PER GLI UTENTI DI BACKEND |
---|---|---|
Cambiare residenza |
Mostrare all’utente i contatti e gli orari di apertura dell’ufficio anagrafe del comune in cui l’utente si è trasferito e il sistema per prenotare un appuntamento |
Permette di gestire il numero di prenotazioni disponibili per ciascuna fascia oraria |
Dopo aver definito in modo chiaro bisogni e funzioni di un servizio, siamo in grado di avviare il processo di prototipazione.