Questo è il primo articolo di una serie dedicata al redesign di software enterprise. Per ricevere i prossimi, iscriviti alla nostra newsletter.
In questi anni abbiamo lavorato con aziende di servizi che sviluppano e mantengono software proprietari, piattaforme SaaS B2B e prodotti digitali complessi. Prodotti solidi, spesso costruiti in anni di lavoro, che continuano a generare valore ma iniziano a mostrare un problema diverso: non comunicano più la qualità reale della soluzione.
In questo articolo proviamo a mettere ordine in ciò che abbiamo imparato: perché il redesign diventa necessario, dove si rischia di rallentare il progetto e quali strumenti aiutano a costruire più rapidamente una direzione condivisa.
Il momento in cui il redesign diventa necessario
Il primo segnale che un software enterprise ha bisogno di essere ripensato arriva molto spesso dal team commerciale. Arriva quando durante una demo qualcuno evita sistematicamente certe schermate, quando la conversazione si sposta troppo spesso su ciò che il prodotto farà in futuro invece che su ciò che è in grado di fare oggi, oppure quando un prospect osserva che il software sembra semplicemente datato.
È una situazione che vediamo spesso. Nessuno perde una gara perché un bottone è brutto o perché una tabella utilizza un font poco contemporaneo. Le opportunità iniziano però a sfumare quando il prodotto comunica complessità, lentezza e rigidità mentre il mercato si aspetta semplicità. In quel momento il problema non è più estetico, è competitivo.
Curiosamente, il redesign raramente nasce come un’iniziativa autonoma. Nella maggior parte dei casi arriva come conseguenza di qualcosa di molto più concreto: un replatforming, una migrazione tecnologica o la necessità di modernizzare un software che negli anni è diventato sempre più difficile da mantenere ed evolvere. A quel punto emerge una domanda inevitabile: se stiamo investendo mesi di lavoro per ricostruire la piattaforma, ha davvero senso ricostruire anche gli stessi problemi?
Il contesto cambia più velocemente del software
Molti software enterprise sono il risultato di anni, se non decenni, di evoluzione. Ogni nuova funzionalità, integrazione o richiesta commerciale ha lasciato una traccia nel prodotto. Nella maggior parte dei casi queste decisioni erano corrette nel momento in cui sono state prese. Il problema è che il software continua ad accumulare storia mentre il mondo attorno a lui cambia.
Negli ultimi anni abbiamo assistito a una trasformazione significativa delle aspettative degli utenti. Le persone utilizzano ogni giorno prodotti digitali che alzano continuamente l’asticella in termini di semplicità, chiarezza e velocità. Non importa che si tratti di software consumer, strumenti di produttività o nuove piattaforme SaaS. Quando un prodotto dimostra che l'esperienza può essere più intuitiva, quella aspettativa si trasferisce immediatamente anche altrove.
È un fenomeno evidente in molti settori. Negli ultimi anni sono emersi nuovi prodotti capaci di ridefinire le aspettative degli utenti; non necessariamente perché offrono funzionalità rivoluzionarie, ma perché riescono a presentare processi complessi in modo più semplice e accessibile. Quando questo accade, gli utenti iniziano inconsciamente a confrontare tutte le altre esperienze con quel nuovo standard.
L’intelligenza artificiale sta accelerando ulteriormente questo processo. Per anni abbiamo chiesto alle persone di adattarsi al software. Oggi iniziamo a vedere software che cercano di adattarsi alle persone, suggerendo azioni, riducendo attività ripetitive e semplificando l’accesso alle informazioni. Non siamo ancora alla completa trasformazione del paradigma, ma la direzione è chiara.
Per questo motivo un software enterprise non compete più soltanto con i propri concorrenti diretti. Compete con le aspettative generate da qualsiasi esperienza digitale moderna. E non sorprende che UX e usabilità siano sempre più presenti nei processi di selezione, nei documenti di gara e nelle valutazioni comparative tra prodotti.
La ricerca infinita non riduce il rischio
Quando un’azienda decide di affrontare un redesign, la prima reazione è quasi sempre la stessa: ridurre il rischio. Si organizzano workshop, interviste, sessioni di allineamento, attività di analisi e raccolta requisiti. Sono attività utili e spesso indispensabili. Sarebbe ingenuo sostenere il contrario.
Il problema nasce quando si sviluppa una convinzione molto diffusa nei progetti enterprise: l’idea che prima o poi arriverà un momento in cui tutto sarà sufficientemente chiaro da permettere al progetto di partire senza incertezze.
Quel momento, semplicemente, non arriva.
I software enterprise sono organismi complessi. Esistono processi che nessuno ha documentato, eccezioni che emergono solo in situazioni particolari, regole di business stratificate negli anni e dipendenze tecnologiche che diventano evidenti soltanto quando si entra nel dettaglio delle singole funzionalità. Pensare di comprendere ogni aspetto del sistema prima di iniziare a progettare significa spesso inseguire un obiettivo irraggiungibile.
Abbiamo visto organizzazioni trascorrere mesi nel tentativo di eliminare ogni possibile area di incertezza. La conseguenza è che il progetto continua ad accumulare documentazione mentre le decisioni vengono rimandate. Dopo un certo punto ogni nuovo workshop genera un valore marginale sempre più ridotto. Detto in modo meno elegante: dopo il decimo workshop non stai più riducendo l’incertezza, stai producendo una documentazione sempre più accurata del fatto che il progetto non è ancora partito.
Questo non significa che la comprensione sia meno importante, significa che il suo obiettivo dovrebbe essere diverso. Non comprendere tutto, comprendere abbastanza per prendere una direzione.
Continuare a lavorare come nel 2020 è un lusso costoso
In questo scenario l’intelligenza artificiale sta cambiando radicalmente il modo in cui affrontiamo le fasi iniziali di un progetto. Non perché sostituisca la ricerca, il design o le decisioni strategiche, ma perché riduce drasticamente il costo della comprensione.
Fino a pochi anni fa era normale trascorrere giornate intere a riascoltare workshop, organizzare appunti, sintetizzare insight e costruire documentazione. Oggi possiamo registrare una sessione, trascriverla automaticamente e utilizzare strumenti AI per individuare pattern ricorrenti, criticità condivise, punti di disaccordo e temi emergenti. Possiamo trasformare ore di conversazioni in conoscenza navigabile e interrogabile in tempi estremamente ridotti.
Lo stesso vale per la documentazione esistente. Specifiche funzionali, manuali, schermate, registrazioni video e processi operativi possono essere analizzati molto più rapidamente rispetto al passato. Possiamo approfondire domini specialistici, esplorare alternative progettuali e lavorare sul microcopy con una velocità che fino a qualche anno fa sarebbe stata difficile da immaginare.
L’aspetto più interessante però è un altro. L’AI non elimina la necessità di comprendere il problema. Elimina una parte significativa dell’attrito necessario per comprenderlo. Questo permette ai team di dedicare meno tempo alla raccolta delle informazioni e più tempo alle decisioni che hanno un impatto reale sul prodotto.
Trovare rapidamente una direzione condivisa
Se accettiamo l’idea che la comprensione completa sia impossibile e che la tecnologia ci permetta di accelerare molte attività preliminari, cambia anche il modo in cui possiamo affrontare un redesign.
Nel nostro caso preferiamo partire da workshop concentrati e molto pragmatici, generalmente di una o due giornate. L’obiettivo non è raccogliere ogni possibile dettaglio sul sistema. È identificare rapidamente problemi, obiettivi, opportunità e vincoli sufficienti per costruire una prima visione condivisa.
Da qui passiamo velocemente alla costruzione di un concept ad alta fedeltà. Questa è probabilmente una delle differenze più evidenti rispetto ad approcci più tradizionali. Molte organizzazioni sono abituate a pensare che il design inizi soltanto dopo una lunga fase di analisi. Noi tendiamo a considerare il prototipo come uno strumento di comprensione.
Quando le persone vedono qualcosa di concreto, la qualità delle conversazioni cambia radicalmente. Emergono dettagli che non sarebbero mai comparsi in una riunione, vincoli che nessuno aveva considerato e opportunità che fino a quel momento erano rimaste invisibili. Molte delle osservazioni più utili che raccogliamo durante un progetto arrivano proprio davanti a un prototipo.
È lì che qualcuno dice che il processo funziona in modo diverso da quanto immaginato. È lì che emerge una regola di business dimenticata. È lì che si scopre che il problema percepito inizialmente non era il problema reale.
Per questo motivo consideriamo il concept non solo come uno strumento di presentazione, ma come uno strumento di scoperta. Una volta condivisa la direzione generale, il lavoro può essere suddiviso in flussi, aree funzionali e iniziative più circoscritte, approfondendo progressivamente ciò che conta davvero.
Perché il design system accelera il lavoro
Un altro elemento che contribuisce ad accelerare il processo è la presenza di un design system. Spesso viene percepito come un tema legato esclusivamente alla governance o alla coerenza visiva, ma nella pratica il suo impatto è molto più ampio.
Quando esiste un sistema condiviso di componenti, pattern e regole, il team può concentrarsi sui problemi da risolvere invece di ridiscutere continuamente gli stessi elementi dell’interfaccia. Molte decisioni vengono prese una sola volta e poi riutilizzate in modo coerente all’interno del prodotto.
Senza un sistema condiviso, ogni schermata rischia di diventare una discussione nuova. Ogni componente viene reinterpretato, ogni flusso sviluppa eccezioni e ogni decisione deve essere rivalutata. Con un design system ben costruito, molte di queste scelte vengono prese una sola volta. Questo libera tempo ed energia per affrontare ciò che conta davvero: i problemi degli utenti e gli obiettivi del business.
Questo rende la progettazione più fluida, più sistematica e più veloce. In alcuni casi permette persino di ridurre il ricorso ai wireframe tradizionali, lavorando direttamente su soluzioni ad alta fedeltà e accelerando il confronto con stakeholder e utenti.
Il design system non è quindi un’attività che rallenta il progetto. È uno degli strumenti che permettono al progetto di muoversi più rapidamente.
Gli utenti hanno (quasi) sempre ragione
Tutto questo non significa ignorare gli utenti finali. Al contrario, quando il contesto lo permette, il coinvolgimento diretto delle persone che utilizzano il prodotto rappresenta uno dei maggiori moltiplicatori di qualità disponibili.
Nella nostra esperienza esiste quasi sempre una distanza tra ciò che gli stakeholder credono di sapere e ciò che gli utenti stanno realmente cercando di ottenere. Non perché manchi competenza o conoscenza del dominio, ma perché molto spesso le aziende osservano i sintomi mentre gli utenti vivono il problema.
È una differenza sottile ma importante. Le organizzazioni tendono a chiedere una nuova interfaccia, una navigazione diversa o una funzionalità aggiuntiva. Gli utenti, invece, stanno cercando di completare un’attività, evitare un errore, ridurre il tempo necessario per svolgere un processo o semplicemente lavorare con meno attrito.
Per questo attività come il Jobs To Be Done possono essere estremamente utili nelle fasi iniziali. Aiutano a comprendere obiettivi, priorità e bisogni reali prima di discutere delle possibili soluzioni. Successivamente, concept e prototipi possono essere validati direttamente con gli utenti finali, trasformando la ricerca in uno strumento continuo di apprendimento e non in una fase isolata all’inizio del progetto.
Non sempre tempi e budget permettono di fare tutto ciò che vorremmo. Quando però riusciamo a inserire gli utenti all’interno del processo, la qualità delle decisioni migliora sensibilmente.
Comprendere progettando
Nei software enterprise contemporanei il redesign non è più soltanto un esercizio estetico. E non è nemmeno un lungo percorso di analisi preliminare. È un processo progressivo che combina competenze di business, tecnologia, ricerca, design e strumenti AI per costruire rapidamente una direzione condivisa e migliorarla nel tempo.
I progetti più efficaci non cercano di eliminare completamente l’incertezza prima di partire. Costruiscono la comprensione mentre il prodotto prende forma. Utilizzano prototipi per prendere decisioni, sistemi per accelerare il lavoro e ricerca per verificare che la direzione sia corretta.
Trovare una direzione, però, è solo il primo passo. Una volta definita una visione condivisa, la sfida successiva diventa renderla coerente, scalabile e sostenibile nel tempo. È qui che entrano in gioco design language, design system e collaborazione tra design e sviluppo.
Ne parleremo nel prossimo articolo.
Perché modernizzare un software non significa ricostruire il passato con una tecnologia nuova. Significa usare ogni intervento per ridurre complessità, aumentare chiarezza e costruire un prodotto capace di evolvere più velocemente del contesto in cui opera.
Questo è il primo articolo di una serie dedicata al redesign di software enterprise. Per ricevere il prossimo, iscriviti alla nostra newsletter.