UX/UI

Progettazione UX per gestionali: imparare a conoscere l’utente

| 28 Maggio 2019 | Andrea Maioli
progettazione ux per gestionali imparare a conoscere utente Instant Developer

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.

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.

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.

È 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!

Andrea Maioli
CEO & Co-Founder
Mi occupo di Instant Developer, dalla mattina presto a notte inoltrata. Mi interesso di ingegneria del software, di natural language processing e di tutti i modi per sfruttare al meglio le nuove tecnologie.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.


Potrebbe Interessarti

Instant Developer Foundation 22.5 e Fluid: il futuro comincia da qui

La versione 22.5 di Instant Developer Foundation rappresenta un passo tangibile verso il futuro di Instant Developer. Il nuovo motore grafico Fluid è infatti il...

Leggi Tutto

Webinar: Le novità di Instant Developer Cloud 22.5

Nel webinar sulle novità della release 22.5 di Instant Developer Cloud , Giuseppe Lanzi, responsabile dei reparti Customer Care e Systems e Paolo Giannelli, responsabile...

Leggi Tutto

Instant Developer Cloud 22.5: esperienze migliori per te e il tuo software

Instant Developer Cloud 22.5 è una versione progettata per una migliore esperienza di utilizzo da parte degli sviluppatori e di fruizione delle applicazioni per gli...

Leggi Tutto

Rimani Aggiornato

Iscriviti alla nostra newsletter per ricevere aggiornamenti su novità, eventi, release, webinar e tante altre notizie sui prodotti Instant Developer.