Questo è il secondo articolo di una serie dedicata al redesign di software enterprise. Per ricevere i prossimi, iscriviti alla nostra newsletter.
Nel primo articolo di questa serie abbiamo raccontato come affrontiamo il redesign di un software enterprise: comprendere i problemi, mettere ordine nella complessità, individuare una direzione e portarla abbastanza avanti da poterla verificare.
Quando lavoriamo al redesign di un software enterprise, sappiamo che molte decisioni arriveranno dopo la consegna. Nuove funzionalità, dati imprevisti e vincoli tecnici metteranno alla prova ciò che abbiamo progettato. A prendere quelle decisioni sarà soprattutto il team del cliente, sempre più spesso con il supporto di agenti AI.
Per questo non basta consegnare una soluzione convincente per i casi che conosciamo oggi. Dobbiamo lasciare un sistema di principi, componenti e regole che il team possa usare ed estendere mentre il prodotto cambia.
Il vero test arriva quando il prodotto cambia
Una delle illusioni più pericolose in un redesign è pensare che, aumentando abbastanza il livello di dettaglio, sia possibile eliminare l’incertezza. Possiamo approfondire i flussi principali, lavorare sui casi limite e confrontarci con chi conosce bene il dominio. È necessario farlo, ma prima o poi qualcosa sfuggirà.
Basta iniziare a costruire per accorgersene. Un campo che nei casi studiati conteneva poche parole deve gestire descrizioni molto più lunghe. Una tabella incontra combinazioni di dati impreviste. Uno stato considerato marginale diventa frequente. Una regola di business emerge soltanto quando il team tecnico entra nel dettaglio dell’implementazione.
E poi c’è tutto ciò che ancora non esiste. Tra sei mesi qualcuno aggiungerà una funzionalità che oggi non possiamo conoscere. Tra un anno potrebbe esserci un nuovo modulo. Un altro team potrebbe iniziare a lavorare sul prodotto senza avere partecipato al redesign.
Se ogni nuovo problema viene affrontato tornando alle soluzioni già progettate e cercando quella che gli assomiglia di più, la coerenza dipende soprattutto dalla capacità delle singole persone di interpretare correttamente ciò che era stato deciso. È una base fragile per un prodotto che deve durare.
Il punto è fare in modo che ciò che non abbiamo previsto possa essere affrontato senza ricominciare ogni volta daccapo.
Il prodotto ha bisogno di una memoria
Durante un redesign prendiamo continuamente decisioni che hanno un valore più ampio del caso specifico su cui stiamo lavorando. Definiamo il modo in cui il prodotto crea gerarchie, comunica gli stati, gestisce la densità delle informazioni e rende riconoscibili le azioni. Alcune scelte sono visive, altre riguardano il comportamento o il modo in cui le diverse parti dell’interfaccia funzionano insieme.
Se rimangono implicite nelle soluzioni progettate, sono difficili da trasferire. Chi ha partecipato al lavoro riesce a riconoscerne la logica perché ricorda le discussioni che l’hanno prodotta. Chi arriva dopo vede soprattutto il risultato.
Il design language rende esplicita questa logica: definisce i principi e le regole che danno al prodotto un linguaggio riconoscibile e coerente. Il design system porta quel linguaggio nella pratica, traducendolo in componenti, token, pattern e documentazione che il team può usare mentre progetta e sviluppa.
In questo modo una parte delle decisioni smette di dipendere dalla memoria di chi era presente e diventa patrimonio del prodotto. Una nuova funzionalità può partire da scelte già fatte; quando serve qualcosa di nuovo, esiste un riferimento con cui confrontarsi per capire come farlo entrare nel sistema.
Un buon design system permette così di distribuire le decisioni senza perdere coerenza. È qui che smette di essere una questione principalmente per designer e developer e diventa un tema di prodotto.
Quando il design arriva al codice
Rendere esplicite le regole è un primo passo. In molti progetti vale la pena portare il design system fino a componenti realmente utilizzabili dal team tecnico, raccolti e documentati in una component library come Storybook.
In Moze consideriamo anche questo parte del lavoro di design. Implementare un componente costringe infatti a prendere decisioni che durante la progettazione possono rimanere più aperte: come si comporta con contenuti reali, quali varianti deve supportare, quali combinazioni hanno senso e dove invece è utile porre dei limiti. È uno dei punti in cui design e tecnologia si avvicinano di più. Il sistema smette di descrivere soltanto come dovrebbe funzionare il prodotto e comincia a esistere nella stessa materia con cui verrà costruito.
Per il team che lo eredita la differenza è concreta. Una parte delle decisioni progettuali è già incorporata nei componenti che userà nello sviluppo, riducendo la distanza tra ciò che è stato progettato e ciò che finirà davvero nel prodotto.
L’autonomia fa parte del risultato
Questo aspetto per noi è diventato ancora più importante negli ultimi anni, perché è cambiato il modo in cui lavoriamo con i team tecnici dei clienti.
In passato era frequente progettare un prodotto e svilupparne direttamente buona parte del front-end. Oggi l’implementazione applicativa viene molto più spesso gestita internamente. Le aziende software hanno team tecnici maturi e vogliono mantenere al proprio interno architettura, codice e conoscenza del prodotto. L’intelligenza artificiale sta accelerando ulteriormente questo passaggio, rendendo una parte crescente dell’esecuzione più accessibile.
Costruire un sistema è una forma di trasferimento. Il team riceve una direzione abbastanza solida da poter essere estesa senza chiedere continuamente a chi l’ha progettata come risolvere il caso successivo.
Per chi guida un prodotto, questo significa soprattutto ridurre una forma di dipendenza. Un nuovo designer può entrare nel progetto e capire più rapidamente le convenzioni esistenti. Un developer può costruire un flusso nuovo senza introdurre inconsapevolmente un secondo modo per risolvere lo stesso problema. Il team può discutere le eccezioni partendo da una base comune invece di affidarsi ogni volta all’interpretazione personale.
C’è anche un beneficio meno misurabile ma molto concreto: la serenità di sapere che il redesign non è una parentesi destinata a deteriorarsi appena ricomincia lo sviluppo ordinario. L’obiettivo non dovrebbe essere rendere il cliente dipendente dalle persone che hanno fatto il redesign ma lasciarlo nella condizione di continuare bene anche senza di loro.
Gli agenti AI rendono il sistema ancora più importante
Lo sviluppo agentico rende tutto questo più evidente. In un progetto recente abbiamo realizzato un design system completo e lo abbiamo portato fino a Storybook. Il team del cliente lo sta usando oggi come base per sviluppare gran parte del software con Claude Code, con una velocità che fino a poco tempo fa sarebbe stata difficile da immaginare.
La velocità, però, racconta solo una parte della storia. La cosa più interessante è che l’agente lavora dentro un ambiente in cui molte decisioni sono già state prese. Esistono componenti utilizzabili, convenzioni condivise e documentazione. Quando deve costruire qualcosa di nuovo non deve dedurre ogni volta quale sia il linguaggio del prodotto.
Questo cambia radicalmente il valore del sistema: un agente è molto efficace quando ha un obiettivo chiaro e un contesto affidabile. Se quel contesto è debole, l’aumento di velocità non risolve il problema: permette semplicemente di produrre più rapidamente decisioni incoerenti.
La relazione è abbastanza semplice: più l’esecuzione diventa economica, più aumenta il valore delle regole che la guidano.
Questo vale naturalmente ben oltre il design system. Nello sviluppo agentico contano la qualità delle specifiche, l’organizzazione della codebase e la capacità di verificare il risultato. Ma il principio è lo stesso: una macchina può lavorare con grande autonomia quando il contesto in cui opera è stato preparato bene.
Il design system diventa una parte di quel contesto. Non documenta soltanto l’aspetto del prodotto, ma offre all’agente una serie di decisioni già disponibili che può applicare mentre costruisce.
È una conseguenza interessante perché modifica anche il modo in cui possiamo valutare il lavoro fatto durante un redesign. Un sistema ben definito non serve più soltanto ad allineare le persone che lavorano sul prodotto oggi. Può diventare il linguaggio condiviso tra il team e gli agenti AI che lo affiancano nello sviluppo.
Progettare la capacità di cambiare
Un design system non è un modo per congelare le decisioni prese durante il redesign. Sarebbe inutile, perché il prodotto continuerà comunque a cambiare.
Anche il sistema dovrà evolvere. Alcuni componenti verranno modificati, nuove esigenze introdurranno nuovi pattern e certe regole si dimostreranno inadatte a problemi che oggi non conosciamo. La differenza è che questi cambiamenti possono avvenire in modo consapevole, dentro una struttura che rende visibile ciò che esiste già.
È questo il valore che cerchiamo di lasciare dopo un redesign. Una direzione abbastanza chiara da sopravvivere al progetto e abbastanza flessibile da non diventare un vincolo. Un sistema che permetta al team di continuare a prendere decisioni quando cambiano i requisiti, le persone e persino il modo in cui il software viene costruito.
Il lavoro fatto a monte serve a evitare che ogni aumento di velocità si trasformi semplicemente in un aumento dell’entropia. Per questo il redesign, almeno per come lo intendiamo oggi, non finisce quando abbiamo trovato una buona soluzione per il prodotto che abbiamo davanti. Finisce quando abbiamo lasciato al team gli strumenti per continuare a farlo evolvere senza perdere quella direzione.
È lì che il redesign diventa un sistema.