UX UI design per software gestionali usati tutto il giorno
Il design UX/UI di un software gestionale decide quanti clic servono per chiudere un ordine e quanti errori si fanno a fine turno. Lo facciamo osservando chi userà le schermate e facendogli provare un prototipo prima di scrivere il codice.
Come si riconosce un gestionale disegnato male
Si riconosce dai fogli Excel che gli crescono intorno. La maschera dell’ordine ha quaranta campi, l’impiegata ne compila sei e salta gli altri con il tasto Tab. Lo stato di una commessa si ricostruisce aprendo tre schede, così il commerciale telefona in magazzino invece di guardare. Ogni scorciatoia è un errore possibile e un pezzo di lavoro che il software non registra.
Il design di un gestionale è fatto di decisioni piccole: quali campi servono in quale momento, cosa compare per primo in una lista di duemila righe, cosa succede quando l’operatore sbaglia un codice articolo. Si prendono guardando le persone lavorare, e su un prototipo costano molto meno che sul codice.
Per chi è
- Aziende con un gestionale su misura che funziona ma è usato a metà, con dati ricopiati altrove.
- Chi sta per far sviluppare un nuovo software e vuole le schermate approvate da chi le userà prima di firmare il preventivo di sviluppo.
- Reparti IT e software house che hanno sviluppatori ma nessun designer.
- Aziende con più applicativi, ognuno con la sua grafica e la sua logica, che vogliono regole comuni.
Cosa include
Osservazione sul posto
Un designer segue un ciclo di lavoro completo accanto a chi usa il software: all’ufficio acquisti, al banco del magazzino, in auto con il commerciale. Annota dove si ferma, cosa ricopia, cosa chiede ai colleghi.
Flussi e mappa delle schermate
Cosa si fa in quale schermata, con i passaggi inutili tolti. È il documento su cui gli sviluppatori stimano il lavoro.
Prototipo con dati realistici
Le schermate in Figma, cliccabili, con nomi di clienti e codici articolo verosimili e liste lunghe come in produzione. Un prototipo con tre righe di esempio nasconde proprio i problemi che contano.
Clic e tempi, prima e dopo
Per i compiti più frequenti, come inserire un ordine o trovare una fattura di marzo, contiamo clic e tempo sul software di oggi e sul prototipo. Il confronto va nel documento finale, accanto alle schermate.
Design system
Componenti, regole per tabelle e moduli, messaggi di errore, documentati e allineati al codice. Per Eternoo gli stessi componenti tengono insieme l’app dei commerciali, il portale interno e l’area clienti.
Come si svolge
Nel team Webion ci sono due designer UI/UX, che lavorano nello stesso gruppo degli sviluppatori.
Ruoli e compiti
Con voi scegliamo chi userà il software e, per ogni ruolo, i compiti da cui passa la sua giornata. Osservazione, prototipo e prove si concentrano su quelli.
Osservazione e prima serie di schermate
Il designer passa in reparto e in ufficio, poi torna con le schermate cliccabili, una serie per ruolo.
Giri di prova
Due o tre persone per ruolo eseguono i compiti sul prototipo senza aiuto, in sessioni registrate con il loro consenso. Dopo ogni giro arriva una versione corretta, finché nessuno si blocca più.
Passaggio allo sviluppo
Il prototipo validato diventa la base del preventivo di sviluppo. Il designer resta nel progetto e controlla le schermate a ogni rilascio in collaudo.
Con cosa si collega
Il design si collega al codice attraverso il design system: i componenti disegnati in Figma esistono identici nella libreria del frontend, quindi una tabella o un campo data si comportano allo stesso modo in ogni schermata. Quando il designer cambia un componente, lo sviluppatore sa quali schermate toccare.
Si collega anche ai dati che arrivano da altri sistemi. Se il codice articolo viene dall’ERP, il campo non si digita ma si cerca. Se in magazzino si lavora con il lettore di codici a barre, la schermata parte dalla scansione e deve funzionare anche senza rete, come nel modulo magazzino di Etenet.
Progetti in cui il design ha guidato lo sviluppo
Tempi e costi
La fase di design si può fare prima di decidere chi svilupperà: alla fine avete flussi, prototipo validato e regole dei componenti.
Durata e costo dipendono da quanti ruoli usano il software e da quanti giri di prova servono. Ogni ruolo in più aggiunge osservazione, una serie di schermate e le sue sessioni di prova: un gestionale per il solo ufficio acquisti si chiude in molto meno tempo di uno usato anche da magazzino, commerciali e clienti. Ridisegnare due o tre maschere di un gestionale esistente costa una parte di un progetto che parte da zero.
Domande frequenti
Parliamone in 30 minuti
Raccontateci il processo e cosa non funziona: vi diciamo se e come lo risolveremmo, con tempi e costi indicativi.



