La tentazione, quando si progetta un gestionale verticale, è partire dall'elenco delle funzionalità: anagrafiche, calendario, documenti, notifiche, app, dashboard. Tutto utile. Ma una lista di funzioni non è ancora un prodotto.
L'ho capito lavorando al progetto di un software dedicato ai professionisti della nutrizione. Il problema non era costruire l'ennesima schermata per compilare un piano alimentare. Era capire come quel piano nasce, cambia e arriva alla persona che dovrà seguirlo.
Un gestionale verticale deve parlare la lingua del lavoro
Un software generico organizza record. Un buon gestionale verticale organizza decisioni e processi di una professione.
Per un nutrizionista non basta archiviare un documento: ci sono visite, rilevazioni, obiettivi, ricette, sostituzioni, revisioni del piano e comunicazioni con il paziente.
Ogni funzione va progettata chiedendosi dove entra nella giornata reale dell'utente. Se aggiunge più passaggi di quanti ne elimini, probabilmente non è ancora quella giusta.
Il nodo delle versioni
Uno dei problemi di progettazione più interessanti riguarda una distinzione apparentemente banale: una bozza non è un piano pubblicato.
Immagina che un professionista stia modificando il piano di un paziente. Nel frattempo il paziente apre l'app. Che cosa deve vedere?
Non i cambiamenti incompleti. Deve continuare a vedere la versione valida finché il professionista non decide di pubblicarne una nuova.
Da qui discendono regole precise:
- una bozza modificabile dal professionista;
- una versione pubblicata e identificabile;
- uno storico utile a ricostruire i cambiamenti;
- un'operazione di pubblicazione coerente, che non lasci contenuti a metà.
Questo non è un dettaglio tecnico secondario. È la differenza tra un'interfaccia che sembra funzionare e un sistema prevedibile per chi lo usa.
I permessi vanno progettati insieme alle schermate
Se un'applicazione contiene dati dei pazienti, non si può rimandare il tema degli accessi alla fine.
Occorre chiarire chi può leggere o modificare ogni informazione, come sono separati gli account e che cosa accade quando cambia il rapporto tra professionista e paziente.
Le regole di autorizzazione devono essere applicate dal sistema, non affidate soltanto al fatto che un pulsante non sia visibile nell'interfaccia. Inoltre privacy e trattamento dei dati sanitari richiedono valutazioni e misure specifiche prima di un eventuale utilizzo reale.
La UX deve ridurre il lavoro mentale
Durante la progettazione ho cercato un'interfaccia meno simile a un foglio di calcolo e più vicina al modo in cui un professionista costruisce un piano.
Per esempio, ragionare sui pasti come elementi composti, rendere leggibili i valori nutrizionali mentre si lavora e distinguere chiaramente la modifica dalla pubblicazione.
La semplicità non sta nel nascondere tutto. Sta nel mostrare la cosa giusta nel momento giusto, senza obbligare l'utente a ricordare continuamente dove si trova.
Il metodo prima dell'interfaccia
Prima definisco il percorso completo: creazione, revisione, pubblicazione, consultazione, aggiornamento. Poi individuo i dati indispensabili e i casi limite. Solo dopo ha senso disegnare componenti e schermate.
Questo modo di lavorare è utile anche fuori dalla nutrizione: vale per software destinati a studi professionali, laboratori, servizi e piccole aziende.
La domanda chiave è sempre la stessa: qual è l'operazione che l'utente deve poter completare senza ambiguità?
Non serve costruire tutto subito
Un prodotto verticale rischia facilmente di diventare enorme. La strada che preferisco è concentrarmi sul suo flusso principale, renderlo affidabile e poi aggiungere ciò che ha davvero una relazione con quel flusso.
È lo stesso criterio che uso quando valuto quale processo automatizzare per primo: prima il valore operativo, poi la quantità di funzioni.
Domande frequenti
Che differenza c'è tra gestionale generico e verticale?
Il primo copre attività comuni a settori diversi. Il secondo rispecchia regole, terminologia e flussi specifici di una professione.
Perché servono le versioni dei documenti?
Per distinguere le modifiche in corso da ciò che è già stato approvato o reso disponibile, riducendo errori e ambiguità.
Si può partire da un prototipo?
Sì, purché sia chiaro che un prototipo non equivale a un prodotto pronto per gestire dati reali o sensibili. Permessi, privacy, robustezza e verifiche restano necessari.
Se stai immaginando un software per una professione o un processo molto specifico, raccontami come si lavora oggi. È da lì che comincerei.
