Progettazione UX per gestionali: imparare a conoscere l’utente

by Andrea Maioli on 28 maggio 2019

Nel mio articolo precedente Progettazione UX per gestionali: la soluzione in due mosse ho cercato di motivare chi ha sviluppato software gestionali a rivedere le proprie applicazioni in una modalità User Centrica, fornendo una semplice ricetta in due passi per riuscirci.

Il primo è quello di conoscere l’utente. Può sembrare una cosa scontata, in pratica non lo è visto che, solitamente, chi progetta e sviluppa i gestionali non è anche utente dei propri prodotti.

Che tipo di conoscenza è richiesta per ottenere una buona progettazione? In sintesi, occorre una capacità di immedesimazione che arriva a comprendere le condizioni in cui viene utilizzato il software, i livelli di preparazione e di comprensione del processo, le ragioni per cui l’utente può trovare piacevole o fastidioso utilizzare i nostri prodotti.

Questo lavoro non sostituisce la parte più tecnica in cui si analizza il processo, i dati coinvolti e l’architettura applicativa, piuttosto è complementare ad essa. E siccome è determinante per il successo dell’impresa, è conveniente completarlo prima di tutto il resto.

Come si può ottenere questo livello di conoscenza ed immedesimazione? La cosa migliore è quella di mettersi al posto dei propri utenti, anche fisicamente, passando del tempo con loro per capire quali sono in pratica i loro problemi. Più si osserva meglio è: fare delle ipotesi potrebbe essere fuorviante, perché saremmo inevitabilmente condizionati dalle nostre idee preconcette.

Occorre, a questo punto, formalizzare il risultato di questa osservazione. Le tecniche di progettazione UX prevedono diverse modalità di formalizzazione; nella mia esperienza ho riscontrato che possono essere sufficienti tre tipi di documenti: gli User Profile, le User Stories e il Business Model. Che cosa contengono?

Nel documento User Profile occorre descrivere le varie tipologie di utenti dell’applicazione. Per ogni tipo di utente bisogna descrivere:

  1. Le caratteristiche personali rilevanti, come ad esempio i titoli di studio, la capacità di comprensione del processo, l’affinità con gli strumenti informatici;
  2. Le condizioni di utilizzo: quando viene usato il sistema, dove, per quanto tempo, da quanti utenti e in quali condizioni ambientali. Non è la stessa cosa usare un sistema tramite smartphone alla fermata del metrò o con un PC desktop sulla scrivania del proprio ufficio;
  3. I problemi che gli utenti hanno (pain) e come il nostro sistema dovrebbe aiutare a superarli (gain).

Con una ricerca sul web potrete trovare tanti esempi di User Profile. Ne trovate uno anche in un  articolo precedente di questo blog.

Il documento User Stories è quello, a mio parere, più importante da scrivere – e a dirla tutta anche il più divertente. Consiste nel descrivere le situazioni di utilizzo tipiche del sistema, meglio se osservate in casi reali. Tale descrizione avviene tramite vere e proprie storie in cui si raccontano il contesto, la problematica da risolvere e come l’applicazione aiuta – o aiuterà – l’utente, fino al successo dell’operazione.

Per ogni tipo di utente va inserita almeno una storia per ogni funzione specifica dell’applicazione che lo riguarda. Questo documento risulta quindi più corposo del precedente, ma è anche quello fondamentale per verificare che il prototipo (mockup) dell’applicazione sia poi adeguato allo scopo.

Anche sul documento User Stories ci sono tonnellate di esempi nel web, fra i quali un altro articolo di questo blog in tema con quello degli User Profile.

Infine, è bene inserire anche una descrizione del Business Model. Perché il modello di vendita influenza la progettazione? La risposta è semplice: oggi possiamo utilizzare una moltitudine di modelli di business di un software, basti pensare al modello SaaS o a quello freemium, fino a quelli completamente gratuiti basati su pubblicità o su schemi di cross selling. Ognuno di questi modelli influenza le caratteristiche UX dell’applicazione, nel senso che ne determina sia le funzionalità che come vengono presentate. In alcuni casi è necessario che l’applicazione si venda da sola. È quindi importante verificare che tali caratteristiche siano tenute in debita considerazione fino dalla progettazione del prototipo.

Se volete un esempio, potete leggere questo articolo su questo blog in linea con gli articoli precedenti.

È solo a questo punto, dopo aver lavorato attentamente a questi tre documenti, che possiamo fare il passo successivo e vedere come utilizzare gli standard UX per giungere ad una soluzione adeguata alle nostre applicazioni di tipo gestionale.

Il passo numero due? Lo trovate nel prossimo articolo!

{ 1 trackback }

Progettazione UX per gestionali: le soluzioni UX standard
4 giugno 2019 alle 12:08

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: