Avviare la UX dentro il principale ERP australiano

Il progetto

Settore

ERP, SaaS

Durata

4 anni

Team

1 design lead, 1 scrum master, 5 sviluppatori, 1 product manager

Il mio ruolo

Strategia e guida UX, Architettura del design system, Requisiti di prodotto, Ricerca e test con gli utenti, Service design e blueprint, Lavoro tra prodotto e ingegneria

Utenti

Dipendenti, Manager, Addetti paghe, Amministratori, Utenti esterni a Pronto

Strumenti

Figma, Confluence, Jira

Lavorare con Carmelo è stato fantastico. È entrato nel nostro mondo UX con sicurezza e chiarezza, e ha aiutato a dare forma ad alcune esperienze davvero critiche.

Panoramica

Pronto Software è il principale produttore australiano di ERP. Quando ha iniziato a portare Pronto Xi da un sistema 4GL a microservizi in cloud, la New Technology Stack (NTS), non aveva designer.

Sono entrato come UX Designer Lead per avviare la disciplina: definire come lavora il design, costruire il design system e dare forma al prodotto in tutto Pronto Xi, in un’azienda che rilasciava software da decenni senza un designer nella stanza.

Il lavoro copre sei prodotti: l’Employee Portal su desktop e mobile, l’onboarding dei dipendenti, un assistente AI, navigazione e ricerca globali, un UI builder no-code e la comunicazione con i clienti.

Il problema

Non c’erano una libreria di componenti, un linguaggio di design o un processo comune tra design e ingegneria. Prima di progettare un’interfaccia migliore, dovevo dimostrare a cosa serve il design in un’azienda che non ne aveva mai avuto bisogno.

Anche gli utenti avevano i loro problemi. Gli addetti paghe calcolavano a mano le indennità, seguivano le differenze nei timesheet su fogli di calcolo e chiedevano ai colleghi di ricontrollare i dati. Il sistema non li avvisava mai: entravano e scoprivano i problemi. L’onboarding passava da catene di email e moduli cartacei. Non c’era un posto unico per vedere dipendenti pagati, totali lordi o scostamenti delle buste paga, e mancava l’automazione proprio dove serviva di più.

Intanto l’architettura cambiava. Passare da un monolite ai microservizi voleva dire che spesso le decisioni di design dovevano arrivare prima di quelle tecniche. Verifica della previdenza (superannuation), controlli BSB e GDPR/CCPA aggiungevano altre regole. Ogni flusso doveva essere corretto nella struttura prima di poterlo disegnare.

Ricerca

La ricerca non è stata una fase iniziale. Ha accompagnato tutto il progetto, dentro un framework DesignOps che ho impostato subito: empatizzare, definire, ideare, prototipare, testare, con ritorni dalla consegna alla discovery. Ogni sprint partiva da dati scritti, non da opinioni.

Discovery

Abbiamo iniziato a settembre 2022. Prima di qualsiasi wireframe ho organizzato workshop con il team di supporto UX e con l’ingegneria per mappare l’architettura dell’informazione, ripercorrere i percorsi di addetti paghe e dipendenti e capire dove la vecchia struttura deludeva gli utenti.

Ne è uscito un Concept of Operations: un documento che descrive come deve comportarsi il nuovo sistema, condiviso da prodotto, design e ingegneria. I requisiti aspettavano il ConOps, e il ConOps aspettava di capire come gli utenti pensano il proprio lavoro.

Ascoltare gli addetti paghe

Le sessioni con addetti paghe e HR facevano emergere sempre gli stessi problemi. Nessuno li avvisava quando qualcosa non andava. Scoprivano timesheet mancanti, ferie non approvate e anagrafiche incomplete solo quando bloccavano già l’elaborazione delle paghe, e poi dovevano inseguire i colleghi per dati che il sistema avrebbe potuto seguire da solo.

Anche quello che volevano era chiaro: una dashboard unica per stipendi, andamento delle ferie, avanzamento delle paghe e azioni HR; promemoria che salgono lungo la catena dei responsabili se ignorati; e una schermata delle paghe da tenere d’occhio, non da spingere di continuo.

Ne abbiamo fatto un Payroll Storyboard, uno scenario a corsie dell’intero ciclo paghe tra responsabili HR, connettori, dipendenti, capi diretti e addetti paghe. Non era una specifica per l’ingegneria. Era l’immagine di come il sistema doveva comportarsi, proattivo e automatico, e ogni decisione successiva è stata verificata su quella.

Service blueprint e percorsi

Per l’onboarding, la ricerca è diventata un service blueprint che copre prima dell’assunzione, primo giorno e dopo, su cinque livelli: cosa fa l’utente, cosa vede, cosa fa il sistema dietro le quinte, processi di supporto e conformità.

Accanto ho disegnato un flusso a corsie con quattro linee: nuovo dipendente, sistema, addetto paghe in Pronto Xi, addetto paghe in NTS. Mostrava dove il lavoro passava da un ruolo all’altro, dove il sistema doveva agire da solo e dove serviva una decisione umana. Con questi due documenti ho scritto insieme requisiti UX e logica di business: le schermate del dipendente (invito, registrazione, attività, profilo) e quelle dell’addetto paghe (creare il dipendente, assegnare attività, conformità SuperAPI, avanzamento). Non si poteva progettare un lato senza capire l’altro.

Concorrenti

Ho confrontato Workday, SAP SuccessFactors, Oracle e Odoo su architettura dell’informazione, chiarezza della UI e funzioni, tra paghe, gestione del personale e self-service. Workday era il riferimento: pulito, con automazioni intelligenti e attento alle persone. SAP e Odoo erano buoni ma pesanti da navigare; Oracle il meno coeso.

Le lacune emerse sono finite direttamente in navigazione, launchpad e onboarding. Il confronto ha confermato anche quello che dicevano gli utenti: le piattaforme migliori portano i problemi da te invece di farteli cercare.

Provare la navigazione prima di sceglierla

La navigazione riguarda ogni utente ogni giorno, quindi era una delle decisioni più rischiose. Prima ho valutato il sistema esistente su 16 principi di usabilità, tra cui coerenza, efficienza, facilità di apprendimento, prevenzione degli errori, accessibilità, accesso per ruolo e aiuto contestuale, per capire esattamente dove falliva.

Poi ho progettato e testato cinque modelli di navigazione. Il modello 0 era l’albero laterale attuale con barra richiudibile. I modelli da 1 a 4 provavano una barra in alto con menu a tendina, menu specifici per il business, sotto-navigazione contestuale, breadcrumb, e una barra a sinistra con menu dei moduli. Ognuno è stato prototipato e provato con gli utenti su attività definite, con un questionario Microsoft Forms per raccogliere punteggi e commenti.

Gli utenti apprezzavano una pagina iniziale pulita e ben raggruppata e moduli con nomi chiari. Qualunque navigazione divisa, con l’ingresso in un punto e il secondo livello altrove, li confondeva. Non trovavano il pulsante home quando era nascosto, e “Overview” da solo non diceva nulla. Ha vinto un modello con una sola navigazione in alto, breadcrumb evidenti e un menu che trasforma “Overview” in un accesso a dashboard, bacheca di lavoro e vista manager. Il sistema finale è nato direttamente da ciò che gli utenti hanno scartato e da ciò che hanno tenuto.

Design

Il design è cresciuto sulla ricerca a piccoli passi, fianco a fianco con l’ingegneria, e ogni decisione si può ricondurre a un bisogno documentato.

Il design system

Il design system è ciò su cui gira tutto il prodotto. Si basa su IBM Carbon v11 con aggiunte specifiche per Pronto: 44 componenti documentati in 56 pagine, con token per colori, spaziature ed effetti. Dove Carbon non copriva le esigenze di un ERP, ho costruito i componenti da zero. Ognuno passa da Labs a Preview a Stable, così l’ingegneria sa sempre cosa è pronto da sviluppare.

Ho inserito tre componenti AI (etichetta AI, livello AI e un popover che spiega le risposte) prima che l’assistente esistesse. Quando il prodotto è stato pronto per l’AI, il sistema lo era già, senza sprint di recupero.

Token e componenti sono collegati al codice tramite Code Connect: design e ingegneria lavorano dalla stessa fonte e il passaggio di consegne smette di essere una fase a sé.

Navigazione e struttura

Dalla ricerca è nato un modello hub, spoke e object: un launchpad come centro, viste spoke per gli elenchi, pagine object per il singolo record. Ogni programma è al massimo a tre livelli dal launchpad, quindi nessuno si perde in menu profondi.

Cinque template spoke (pagina object, overview, analitica, inserimento rapido o wizard, report a elenco) danno a ogni schermata una forma prevedibile: si sa sempre dove si è e come tornare indietro. Le attività si completano il 40% più in fretta, risultato confermato in più cicli di test documentati.

Pronto AI

Pronto AI è l’assistente dentro Pronto Xi. Prima di progettarlo ho usato un modello di contesto per l’AI, guardando a persone (esperti del dominio), business (esigenze operative), macchina (cosa sa fare il machine learning) e mondo (dati e norme esterne), per capire dove l’AI aiuta davvero e dove aggiunge solo rumore.

Ha due modalità. Quella assistiva risponde dentro la schermata in uso, senza far perdere il filo. Quella immersiva è una chat a schermo intero con cronologia, rinomina, archivio e input vocale.

Il proof of concept è stato presentato alla conferenza commerciale di Pronto prima del design completo. Visto che i componenti erano già nel sistema, costruire Pronto AI non ha richiesto modifiche strutturali.

Onboarding dei dipendenti

L’onboarding è stata la prima area rilasciata sulla nuova piattaforma, e ha avuto una ricerca proporzionata alla sua complessità: flusso a corsie, service blueprint e analisi dei processi XOnboard e SuperAPI sono confluiti nel design.

Ho progettato quattro flussi, per il nuovo dipendente, l’addetto paghe, il datore di lavoro e il lancio dell’app paghe, tutti oggi in V1 Stable con documentazione versionata. Il flusso del dipendente copre invito con token, verifica dell’identità, dati personali e contatti, codice fiscale australiano (TFN), conto bancario, scelta del fondo pensione tramite SuperAPI e verifica dei dati del datore di lavoro. Quello dell’addetto paghe copre creazione del dipendente, gestione delle sessioni di onboarding, conformità SuperAPI, assegnazione delle attività e avanzamento dalla dashboard NTS.

Il lavoro andava ben oltre le schermate: email, autenticazione a due fattori, il service blueprint completo e la conformità ATO tramite SuperAPI erano tutti nel perimetro. Prima di tutto era un problema di service design.

Employee Portal

Il portale è dove le persone lavorano ogni giorno: dati personali, rapporto di lavoro, ferie, timesheet, viste manager, cambio azienda e impostazioni, su desktop e mobile. I soli dati del rapporto di lavoro sono passati da tre revisioni formali, ognuna corretta con l’ingegneria e provata con gli utenti, prima di arrivare all’MVP attuale. I manager hanno un livello a parte, con responsabilità diverse ma lo stesso linguaggio di design.

Pronto UI Studio

Il design system doveva funzionare anche per gli sviluppatori che ci costruiscono sopra. Pronto UI Studio è un builder no-code dove si compongono schermate trascinando componenti in griglie responsive. La prima versione era difficile: non era chiaro dove mettere un componente, come si legavano righe e colonne, né quali componenti andassero in quali aree.

Ho trattato gli sviluppatori come qualsiasi altro utente. Servivano aree di rilascio chiare, colori per distinguere le zone del layout, un riscontro immediato quando un rilascio non era permesso e testi di aiuto per non dover aprire la documentazione. Ho guardato IBM Carbon UI Builder, SAP Business Technology Platform e Bubble.io per i pattern che funzionano a questa scala. La nuova versione ha un pannello componenti raggruppato a sinistra, etichette e colori sulla tela e un pannello proprietà a destra.

Requisiti

La UX ha guidato anche la definizione del prodotto. Ho scritto i requisiti di sette aree funzionali, con user story, stime per sprint e piani di rilascio, in Confluence. Ingegneria, prodotto e referenti lavoravano da lì, quindi il design alimentava direttamente il backlog.

Le sfide

• Guadagnarsi un posto. In un’azienda guidata dagli ingegneri, il design si è conquistato voce in capitolo sprint dopo sprint, aiutando nelle scelte di architettura oltre che consegnando schermate.
• Un’architettura in movimento. Spesso i requisiti dovevano esistere prima dei servizi. ConOps e flussi a corsie hanno tenuto allineati design e ingegneria.
• Conformità. Previdenza, controlli BSB, GDPR e CCPA hanno condizionato le scelte di interazione dall’inizio alla fine.
• L’AI prima dell’AI. Mettere i componenti AI nel sistema in anticipo era una scommessa su dove andava il prodotto. Ha pagato: nessuna rilavorazione al lancio.
• Cinque ruoli, sei prodotti. Li ha tenuti coerenti il design system, perché è stato costruito come infrastruttura.

Impatto

• 90%dei casi d’uso MVP superati nei test
• 40%più veloci le attività di navigazione
• 30%di UX in più rispetto ai concorrenti

• Rispetto ai concorrenti. Posizionamento UX migliorato del 30%, misurato in un confronto strutturato con Workday, SAP SuccessFactors, Oracle e Odoo.
• Navigazione. Attività completate il 40% più in fretta, provate su 88 frame di navigazione e più cicli di feedback documentati.
• MVP. Il 90% dei casi d’uso ha superato i test, su 576 frame pronti per la produzione che coprono cinque ruoli e sei prodotti.

Se devi far crescere la UX su più prodotti, portare il design in un’azienda guidata dall’ingegneria o costruire un design system su cui gira tutto il prodotto, un ruolo lungo e integrato come questo è dove lavoro meglio.