Progettare applicazioni utili per i clienti: Parte 2

Come vi abbiamo raccontato in uno degli articoli pubblicati qualche giorno fa, CodicePlastico ha aperto una divisione dedicata alla realizzazione della user experience, abbiamo un team di designer che si prendono cura dei clienti e progettano tramite worskhop e attività di codesign.

Come si sviuppa un progetto di UX? Il tutto inizia da una call (o da un incontro) in cui il cliente rispoonde a una serie di domande mirate e andiamo a capire lo scope del progetto, gli obiettivi ad alto livello e le necessità. L’utilità di questo primo incontro è che ci permette di definire nel dettaglio le attività che faremo nel secondo meeting e che viene erogato sotto forma di workshop. Non possiamo dire di avere un pacchetto standard che applichiamo a tutti i casi, se siamo una “sartoria” per quanto riguarda lo sviluppo software, lo vogliamo essere anche per quanto riguarda il design (cambia l’output ma non i principi) quindi il workshop viene costruito su misura per il cliente tenendo conto della dimensione, dei participanti, dell’eventuale software esistente e di altri fattori.

Ma se ogni workshop ha le sue peculiarità siamo certi che 3 step non mancheranno mai: identificazione degli utentiflusso e prototipazione.

Step 1. Identifichiamo i nostri utenti

Una delle cose che i nostri clienti faticavano a capire è che quello che dobbiamo progettare lo dobbiamo fare avendo chiaro chi saranno gli utenti del nuovo sistema. Chiediamo sempre di poter parlare con gli utenti finali, di poterli coinvolgere nei workshop che organizziamo per ascoltare le loro esigenze e capire qual è il loro modo di lavorare.

Oggi lo facciamo attraverso un gioco in cui andiamo a creare le caratteristiche dei personaggi. Insieme ai partecipanti disegnamo delle schede (simili a quelle usate per i personaggi di Dungeons&Dragons) che permettono di identificare l’utente, le sue caratteristiche, le sue propensioni all’uso di strumenti digitali, e altre informazioni che riteniamo possano essere utili per disegnare un’applicazione che sia utile.

Questa attività, fatta durante il workshop, richiede ai partecipanti di provare ad estraniarsi da se stessi e di immedesimarsi nel personaggio che stanno creando identificando le caratteristiche tipiche di chi deve svolgere quell’attività.

Ne escono schede di questo tipo:

Step 2. Il flusso

Una volta identificati i personaggi, posizioniamo i loro avatar su un lungo foglio di carta, ogni avatar occupa una riga (corsia) sulla quale andremo a posizionare gli eventi che appartengono al suo flusso.

Questo secondo step inizia con l’identificazione dell’evento che denota l’avvio del flusso, ad esempio se si tratta di un sistema di backend di un e-commerce e stiamo modellando la messa a catalogo di un nuovo prodotto, l’evento scatenante potrebbe essere la compilazione della scheda prodotto o la richiesta al fornitore del prodotto.

Gli utenti sono portati spesso a proporre macro-eventi che devono essere smontati in eventi più piccoli grazie ad una serie di domande che chi coordina il workshop deve fare per trovare le cose nascoste.

Nel caso di esempio sopra della “compilazione della scheda prodotto” viene chiesto ad esempio di spiegare chi decide che deve essere compilata, se la compilazione è un’operazione atomica o viene fatta in più passaggi, se tutte le informazioni sono disponibili, e cosi facendo si scopre che un utente si occupa solo di creare la scheda con alcuni dati segnaposto e che la compilazione vera e propria coinvolge altri utenti e che dura alcuni giorni.

Tutte queste informazioni vengono riportate sul flusso temporale, ricorrendo ai nostri amati post-it e a disegni che aggiungono contesto e collegano gli elementi del flusso.

Step 3. Prototipazione

Disegnare interfacce è compito dei designer: è una cosa che ho sempre pensato… ma cosa succede se gli utenti sono chiamati in prima persona a progettare le schermate delle proprie applicazioni?

(anche qui ero molto scettico, fino a quando…)

Dopo aver modellato il flusso e per tutti è chiaro quali sono le operazioni che vanno fatte e quando vanno fatte, gli utenti, affiancati dai nostri designer, sono invitati a disegnare le schermate che sono necessarie.

Anche questa è un’attività che facciamo in gruppo, consegnamo fogli già dimensionati (desktop, mobile, ecc..) e chiediamo di disegnare a matita la schermata.

Non è una cosa facile per un utente, ma fare questa attività in prima persona permette a tutti di rendersi conto che uno schermo ha una dimensione finita, che certe informazioni sono più importanti di altre, che certi dettagli non erano stati individuati prima e che vanno aggiunti.

Un altro side-effect che si ottiene è di tenere coinvolti i partecipanti con un’attività all’apperanza leggera (disegnare), la partecipazione attiva è fondamentale per identificare cosa ogni schermata deve contenere, discutere di eventuali differenti vedute tra utenti delle stessa applicazione (e quindi la nascita di viste diversificate per utente) e tante altre piccole informazioni che ci permettono di disegnare l’applicazione giusta.

Naturalmente ciò che viene disegnato in questa fase viene poi rivistodigitalizzato e ridisegnato dal nostro team, non ci aspettiamo che gli utenti conoscano i pattern di UX e i principi di design di un’interfaccia, ma riteniamo sia molto utile avere il loro punto di vista.

Queste sono alcune delle cose che facciamo nei nostri workshop destinati a scoprire le esigenze del cliente che vuole digitalizzare i propri processi.

Ciò che abbiamo imparato è che ai nostri clienti piace essere coinvolti direttamente in queste scelte. Abbiamo anche capito che portare tutti nella stessa stanza, anche se difficile, ha un enorme valore soprattutto per i clienti che scoprono che la realtà della loro azienda è spesso diversa da quello che credono.

Noi continueremo ad affinare i nostri workshop pensandoli sempre con l’obiettivo di creare l’applicazione giusta per i nostri clienti.