Costruzione della UX da zero all'interno della principale piattaforma ERP australiana

Il problema: progettare la UX in una cultura engineering-first

Nessuna libreria di componenti. Nessun linguaggio visivo. Nessun processo condiviso tra design e ingegneria. La sfida non era solo progettare un'interfaccia migliore — era far contare il design all'interno di un'azienda che non ne aveva mai avuto bisogno. La realtà degli utenti era altrettanto frammentata. I responsabili delle paghe elaboravano manualmente i compensi dei dipendenti, monitoravano le variazioni dei fogli presenze su fogli di calcolo e si affidavano ai colleghi per verificare l'accuratezza dei dati. Il sistema non offriva alcuna visibilità proattiva — dovevano accedere per scoprire i problemi, anziché essere avvisati. L'onboarding avveniva tramite catene di email e moduli cartacei. Non esisteva un punto di accesso unico per i KPI — personale retribuito, totali lordi, varianze dei cicli di pagamento — e nessuna automazione dove era più necessaria. E l'architettura evolveva mentre costruivo. La transizione da un monolite a microservizi significava che le decisioni di design spesso dovevano precedere quelle ingegneristiche — non seguirle. I vincoli normativi — validazione della previdenza complementare, verifica dei conti BSB, GDPR/CCPA — aggiungevano ulteriore complessità. Ogni flusso doveva essere architetturalmente corretto prima di poter essere risolto visivamente.

Ricerca: il ritmo operativo del progetto

La ricerca non era una fase — era il ritmo operativo dell'intero progetto. Il processo è stato formalizzato in un framework DesOps che ho stabilito fin dall'inizio: Empatia → Definizione → Ideazione → Prototipazione → Test, con cicli di feedback ricorsivi tra discovery e delivery. Ogni sprint era fondato su evidenze documentate. Nessuna preferenza, nessuna assunzione.

Discovery: comprendere il sistema dall'interno

Il progetto è iniziato nel settembre 2022 con una fase di discovery strutturata. Prima che venisse disegnato un singolo wireframe, ho condotto workshop con il supporto del team UX e con il più ampio team di ingegneria per mappare l'architettura informativa esistente, ripercorrere i percorsi dei responsabili paghe e dei dipendenti, e identificare dove la struttura organizzativa del sistema legacy stava deludendo gli utenti. Queste sessioni hanno prodotto un documento Concept of Operations che articolava le caratteristiche del nuovo sistema e diventava lo strumento di allineamento tra design, prodotto e stakeholder ingegneristici. I requisiti non potevano essere scritti finché il ConOps non fosse stato validato; il ConOps non poteva essere validato finché i modelli mentali degli utenti non fossero stati compresi.

Ascoltare gli utenti

Sessioni di ricerca strutturate con i responsabili delle paghe e i team HR hanno portato alla luce una serie consistente e specifica di problemi. I responsabili delle paghe non ricevevano notifiche proattive quando qualcosa andava storto — scoprivano fogli presenze mancanti, permessi non approvati e anagrafiche dipendenti incomplete solo quando stavano già bloccando un ciclo di pagamento. Il sistema faceva affidamento su di loro per inseguire manualmente gli altri per dati che avrebbe potuto tracciare e scalare automaticamente. I loro obiettivi erano altrettanto chiari: un singolo dashboard che mostrasse stipendi, trend delle assenze, avanzamento del ciclo di pagamento e azioni HR in un'unica vista; promemoria automatici che escalassero lungo la catena di management se non risolti; e un'interfaccia per il ciclo di pagamento costruita per il monitoraggio passivo anziché per un intervento manuale costante.

Queste sessioni hanno anche prodotto un Payroll Storyboard — un documento di scenario multi-ruolo in stile swimlane che mappa l'intero ciclo di preparazione delle paghe tra HR manager, connettori, dipendenti, responsabili di linea e responsabili delle paghe. Non era un deliverable per l'ingegneria. Era una visione condivisa di come il sistema avrebbe dovuto comportarsi: proattivo, automatizzato e centrato sull'essere umano — lo standard rispetto al quale ogni successiva decisione di design sarebbe stata misurata.

Service blueprint e mappatura del percorso utente

Per l'onboarding dei dipendenti, la ricerca si è tradotta direttamente in un service blueprint che mappa l'intero ciclo di vita Pre-assunzione → Primo giorno → Post-onboarding su cinque dimensioni: azioni dell'utente, esperienza frontstage, processi di sistema backstage, processi di supporto e requisiti di conformità. Accanto ad esso, ho prodotto un diagramma swimlane con quattro corsie parallele — Nuovo Dipendente, Sistema, Responsabile Paghe (Pronto Xi), Responsabile Paghe (NTS) — che mostra esattamente dove le responsabilità si trasferivano tra i ruoli, dove il sistema doveva agire autonomamente e dove le decisioni umane erano inevitabili.

Questi artefatti non erano documentazione fine a se stessa. Erano lo strumento che ho usato per definire contemporaneamente i requisiti UX e la logica di business — flussi di schermata frontstage per i dipendenti (email di invito, registrazione, completamento delle attività, profilo) e flussi backstage per i responsabili delle paghe (creazione del dipendente, assegnazione delle attività, gestione della conformità SuperAPI, monitoraggio dei progressi). Il swimlane rendeva impossibile progettare uno senza comprendere l'altro.

Analisi comparativa della concorrenza

Un'analisi comparativa strutturata ha esaminato quattro piattaforme — Workday, SAP SuccessFactors, Oracle e Odoo — valutando architettura informativa, chiarezza dell'interfaccia e completezza delle funzionalità in ambito paghe, gestione della forza lavoro e self-service per i dipendenti. Workday è emerso come benchmark: moderno, pulito, con automazione intelligente e un'esperienza incentrata sulle persone. SAP e Odoo sono stati valutati positivamente — ricchi di contenuti ma che richiedono impegno per la navigazione. Oracle non raggiungeva la fluidità attesa.

Le lacune identificate in questa analisi hanno informato direttamente la direzione di design per la navigazione, il launchpad e i flussi di onboarding di Pronto Xi. In particolare, il benchmarking ha rafforzato ciò che gli utenti avevano già detto: le piattaforme leader non costringevano gli utenti a cercare i problemi — li portavano proattivamente in superficie.

Testare i modelli di navigazione prima di scegliere

La navigazione è stata una delle decisioni ad alto rischio dell'intero progetto. Sbagliare avrebbe influenzato ogni utente, ogni giorno. Prima di proporre una direzione, ho condotto una valutazione euristica del sistema esistente rispetto a 16 principi di usabilità consolidati — che coprono coerenza, efficienza, apprendibilità, prevenzione degli errori, accessibilità, accesso basato sui ruoli e aiuto contestuale — per documentare esattamente dove l'architettura attuale falliva.

Ho poi progettato e testato cinque distinti modelli di navigazione, ciascuno rappresentante un approccio strutturale diverso. Il Modello 0 era lo stato attuale: un albero laterale verticale con rail comprimibile. I Modelli da 1 a 4 introducevano variazioni progressive — navigazione top-shell con menu a tendina, menu personalizzati specifici per il business, navigazione contestuale subshell, retrocessione con breadcrumb e combinazioni di rail LHS con dropdown modulari. Ciascuno è stato prototipato e testato con utenti reali attraverso sessioni strutturate con scenari di attività specifici e un sondaggio Microsoft Forms che raccoglieva dati sia qualitativi che quantitativi.

I test hanno rivelato qualcosa di importante: gli utenti apprezzavano costantemente una landing page pulita e ben categorizzata e un'identificazione chiara dei moduli, ma erano confusi da qualsiasi navigazione divisa in cui il punto di ingresso e la navigazione di secondo livello si trovavano in posti diversi. Il pulsante home non era identificabile nei modelli che lo nascondevano. "Panoramica" come etichetta non significava nulla senza contesto. Il modello vincente combinava una navigazione superiore consolidata, breadcrumb forti e un dropdown contestuale che ridisegnava "Panoramica" come gateway verso dashboard, bacheca di lavoro e vista manager.

Questi risultati non erano solo utili — erano decisivi. Il sistema di navigazione finale è stato costruito direttamente da ciò che gli utenti hanno rifiutato e da ciò che hanno approvato.

Sfide