Greator
Progettare il sistema che rende possibile il design
Non tutti i progetti richiedono nuove interfacce. Alcuni richiedono nuove condizioni. In Greator il lavoro non è stato quello di ridisegnare il prodotto, ma di intervenire sul modo in cui il design funzionava all’interno dell’organizzazione. Il focus non era l’estetica, ma la struttura. Non la velocità di produzione, ma la sostenibilità delle decisioni.
Greator
Progettare il sistema che rende possibile il design
Non tutti i progetti richiedono nuove interfacce. Alcuni richiedono nuove condizioni. In Greator il lavoro non è stato quello di ridisegnare il prodotto, ma di intervenire sul modo in cui il design funzionava all’interno dell’organizzazione. Il focus non era l’estetica, ma la struttura. Non la velocità di produzione, ma la sostenibilità delle decisioni.
Greator
Progettare il sistema che rende possibile il design
Non tutti i progetti richiedono nuove interfacce. Alcuni richiedono nuove condizioni. In Greator il lavoro non è stato quello di ridisegnare il prodotto, ma di intervenire sul modo in cui il design funzionava all’interno dell’organizzazione. Il focus non era l’estetica, ma la struttura. Non la velocità di produzione, ma la sostenibilità delle decisioni.
Panoramica del progetto
Greator è una piattaforma digitale in crescita, attiva tra prodotto, marketing e mobile app. Le interfacce funzionavano, le feature venivano rilasciate, il team era operativo. Il problema non era visibile. Ma sotto la superficie, il sistema non era solido. I file Figma erano cresciuti in modo organico. Il design system esisteva, ma senza una governance chiara. L’allineamento con sviluppo dipendeva più dalle persone che dalla struttura. I principi di brand erano definiti, ma non sempre tradotti in regole operative di interfaccia. Nulla era rotto. Ma nulla era davvero sostenibile.
Il problema
Il problema non era l’incoerenza visiva. Era l’entropia decisionale.
Con l’espansione del team, le ambiguità si moltiplicavano. Non era sempre chiaro cosa facesse parte del sistema e cosa no. Le responsabilità non erano formalizzate. Il concetto di “done” variava a seconda delle persone. Il design system veniva percepito come libreria, non come infrastruttura.
Il rischio non era un fallimento immediato. Era una crescita fragile, dipendente dalla memoria e dalle relazioni informali.
Quando le decisioni non sono esplicite, la qualità dipende dagli individui.
Il mio ruolo
Sono entrato come Senior UI/UX Designer, ma il mio contributo si è rapidamente spostato dalla produzione all’organizzazione del design.
Ho lavorato sulla definizione di una roadmap UI strutturata per Q1–Q2, introducendo rilasci incrementali del sistema invece di puntare a una soluzione perfetta fin dall’inizio. Ho facilitato momenti di allineamento attraverso workshop e survey, per far emergere attriti, aspettative e timori latenti intorno al design system.
Ho riorganizzato l’architettura dei file Figma, separando chiaramente foundations, moduli app, moduli marketing e documentazione di governance. L’obiettivo non era pulire i file, ma rendere le decisioni navigabili.
Ho formalizzato le fasi del workflow, definendo criteri condivisi di completamento e migliorando l’allineamento con sviluppo. Parallelamente, ho supportato la crescita dei designer più junior, favorendo maggiore autonomia e chiarezza operativa.
Non si trattava di ridisegnare il prodotto. Si trattava di ridisegnare le condizioni in cui il design accadeva.
Panoramica del progetto
Greator è una piattaforma digitale in crescita, attiva tra prodotto, marketing e mobile app. Le interfacce funzionavano, le feature venivano rilasciate, il team era operativo. Il problema non era visibile. Ma sotto la superficie, il sistema non era solido. I file Figma erano cresciuti in modo organico. Il design system esisteva, ma senza una governance chiara. L’allineamento con sviluppo dipendeva più dalle persone che dalla struttura. I principi di brand erano definiti, ma non sempre tradotti in regole operative di interfaccia. Nulla era rotto. Ma nulla era davvero sostenibile.
Il problema
Il problema non era l’incoerenza visiva. Era l’entropia decisionale.
Con l’espansione del team, le ambiguità si moltiplicavano. Non era sempre chiaro cosa facesse parte del sistema e cosa no. Le responsabilità non erano formalizzate. Il concetto di “done” variava a seconda delle persone. Il design system veniva percepito come libreria, non come infrastruttura.
Il rischio non era un fallimento immediato. Era una crescita fragile, dipendente dalla memoria e dalle relazioni informali.
Quando le decisioni non sono esplicite, la qualità dipende dagli individui.
Il mio ruolo
Sono entrato come Senior UI/UX Designer, ma il mio contributo si è rapidamente spostato dalla produzione all’organizzazione del design.
Ho lavorato sulla definizione di una roadmap UI strutturata per Q1–Q2, introducendo rilasci incrementali del sistema invece di puntare a una soluzione perfetta fin dall’inizio. Ho facilitato momenti di allineamento attraverso workshop e survey, per far emergere attriti, aspettative e timori latenti intorno al design system.
Ho riorganizzato l’architettura dei file Figma, separando chiaramente foundations, moduli app, moduli marketing e documentazione di governance. L’obiettivo non era pulire i file, ma rendere le decisioni navigabili.
Ho formalizzato le fasi del workflow, definendo criteri condivisi di completamento e migliorando l’allineamento con sviluppo. Parallelamente, ho supportato la crescita dei designer più junior, favorendo maggiore autonomia e chiarezza operativa.
Non si trattava di ridisegnare il prodotto. Si trattava di ridisegnare le condizioni in cui il design accadeva.
Panoramica del progetto
Greator è una piattaforma digitale in crescita, attiva tra prodotto, marketing e mobile app. Le interfacce funzionavano, le feature venivano rilasciate, il team era operativo. Il problema non era visibile. Ma sotto la superficie, il sistema non era solido. I file Figma erano cresciuti in modo organico. Il design system esisteva, ma senza una governance chiara. L’allineamento con sviluppo dipendeva più dalle persone che dalla struttura. I principi di brand erano definiti, ma non sempre tradotti in regole operative di interfaccia. Nulla era rotto. Ma nulla era davvero sostenibile.
Il problema
Il problema non era l’incoerenza visiva. Era l’entropia decisionale.
Con l’espansione del team, le ambiguità si moltiplicavano. Non era sempre chiaro cosa facesse parte del sistema e cosa no. Le responsabilità non erano formalizzate. Il concetto di “done” variava a seconda delle persone. Il design system veniva percepito come libreria, non come infrastruttura.
Il rischio non era un fallimento immediato. Era una crescita fragile, dipendente dalla memoria e dalle relazioni informali.
Quando le decisioni non sono esplicite, la qualità dipende dagli individui.
Il mio ruolo
Sono entrato come Senior UI/UX Designer, ma il mio contributo si è rapidamente spostato dalla produzione all’organizzazione del design.
Ho lavorato sulla definizione di una roadmap UI strutturata per Q1–Q2, introducendo rilasci incrementali del sistema invece di puntare a una soluzione perfetta fin dall’inizio. Ho facilitato momenti di allineamento attraverso workshop e survey, per far emergere attriti, aspettative e timori latenti intorno al design system.
Ho riorganizzato l’architettura dei file Figma, separando chiaramente foundations, moduli app, moduli marketing e documentazione di governance. L’obiettivo non era pulire i file, ma rendere le decisioni navigabili.
Ho formalizzato le fasi del workflow, definendo criteri condivisi di completamento e migliorando l’allineamento con sviluppo. Parallelamente, ho supportato la crescita dei designer più junior, favorendo maggiore autonomia e chiarezza operativa.
Non si trattava di ridisegnare il prodotto. Si trattava di ridisegnare le condizioni in cui il design accadeva.
Gestire i conflitti attraverso decisioni condivise
Invece di proporre una trasformazione radicale, abbiamo introdotto piccoli interventi strutturati. Il design system è passato da documentazione statica a evoluzione pianificata. Le decisioni visive sono state validate con esperimenti leggeri, riducendo la soggettività. I valori di brand sono stati tradotti in regole applicabili, non lasciati a livello dichiarativo.
Figma è diventato un sistema navigabile, non un archivio. Il workflow è diventato esplicito, non implicito. Il team ha iniziato a lavorare con maggiore prevedibilità. Il design è diventato meno reattivo e più intenzionale.
Toolkit UI e librerie di pattern
Il passo successivo è stato creare il toolkit UI e le librerie di pattern. Questi componenti includevano elementi fondamentali come la tipografia, i pulsanti e i colori, che erano standardizzati tra i progetti. Questo toolkit ha aiutato a garantire coerenza riducendo la ridondanza delle decisioni di design tra i team. Le librerie di pattern sono state integrate in Figma, consentendo ai designer di accedere a componenti riutilizzabili e di evitare di ricominciare da zero per ogni nuova funzionalità.
Toolkit UI e librerie di pattern
Il passo successivo è stato creare il toolkit UI e le librerie di pattern. Questi componenti includevano elementi fondamentali come la tipografia, i pulsanti e i colori, che erano standardizzati tra i progetti. Questo toolkit ha aiutato a garantire coerenza riducendo la ridondanza delle decisioni di design tra i team. Le librerie di pattern sono state integrate in Figma, consentendo ai designer di accedere a componenti riutilizzabili e di evitare di ricominciare da zero per ogni nuova funzionalità.
Toolkit UI e librerie di pattern
Il passo successivo è stato creare il toolkit UI e le librerie di pattern. Questi componenti includevano elementi fondamentali come la tipografia, i pulsanti e i colori, che erano standardizzati tra i progetti. Questo toolkit ha aiutato a garantire coerenza riducendo la ridondanza delle decisioni di design tra i team. Le librerie di pattern sono state integrate in Figma, consentendo ai designer di accedere a componenti riutilizzabili e di evitare di ricominciare da zero per ogni nuova funzionalità.
Documentazione e Scalabilità del Sistema
Ho predisposto una chiara documentazione per ogni componente all'interno del sistema di design. Questo ha comportato l'utilizzo di Figma e Confluence come risorse centralizzate per tracciare le decisioni di design, le linee guida per l'uso e le migliori pratiche. Il sistema è stato strutturato per essere facilmente scalabile, consentendo ai futuri designer di integrarsi senza problemi e contribuire in modo efficace.
Documentazione e Scalabilità del Sistema
Ho predisposto una chiara documentazione per ogni componente all'interno del sistema di design. Questo ha comportato l'utilizzo di Figma e Confluence come risorse centralizzate per tracciare le decisioni di design, le linee guida per l'uso e le migliori pratiche. Il sistema è stato strutturato per essere facilmente scalabile, consentendo ai futuri designer di integrarsi senza problemi e contribuire in modo efficace.
Documentazione e Scalabilità del Sistema
Ho predisposto una chiara documentazione per ogni componente all'interno del sistema di design. Questo ha comportato l'utilizzo di Figma e Confluence come risorse centralizzate per tracciare le decisioni di design, le linee guida per l'uso e le migliori pratiche. Il sistema è stato strutturato per essere facilmente scalabile, consentendo ai futuri designer di integrarsi senza problemi e contribuire in modo efficace.
Riflessione
L’ambiguità tra design e sviluppo si è ridotta. Le responsabilità sono diventate più chiare. Il design system ha acquisito valore operativo. I designer hanno lavorato con maggiore autonomia. Il team ha iniziato a evolvere in modo strutturato, non casuale. Il risultato più importante non è stato un’interfaccia. È stato un modo più maturo di lavorare.
Riflessione
L’ambiguità tra design e sviluppo si è ridotta. Le responsabilità sono diventate più chiare. Il design system ha acquisito valore operativo. I designer hanno lavorato con maggiore autonomia. Il team ha iniziato a evolvere in modo strutturato, non casuale. Il risultato più importante non è stato un’interfaccia. È stato un modo più maturo di lavorare.
Riflessione
L’ambiguità tra design e sviluppo si è ridotta. Le responsabilità sono diventate più chiare. Il design system ha acquisito valore operativo. I designer hanno lavorato con maggiore autonomia. Il team ha iniziato a evolvere in modo strutturato, non casuale. Il risultato più importante non è stato un’interfaccia. È stato un modo più maturo di lavorare.
Risultato
In soli sei mesi, ho posato con successo le basi per un sistema di design scalabile per Greator. Concentrandomi su flussi di lavoro, collaborazione e documentazione, ho garantito che il sistema non solo affrontasse le sfide di design immediate, ma anche preparasse il terreno per una crescita futura. Il sistema di design pilota ha dimostrato il valore di processi chiari e collaborazione interfunzionale, creando un prodotto più forte e coeso sia per il team che per gli utenti.
Risultato
In soli sei mesi, ho posato con successo le basi per un sistema di design scalabile per Greator. Concentrandomi su flussi di lavoro, collaborazione e documentazione, ho garantito che il sistema non solo affrontasse le sfide di design immediate, ma anche preparasse il terreno per una crescita futura. Il sistema di design pilota ha dimostrato il valore di processi chiari e collaborazione interfunzionale, creando un prodotto più forte e coeso sia per il team che per gli utenti.
Risultato
In soli sei mesi, ho posato con successo le basi per un sistema di design scalabile per Greator. Concentrandomi su flussi di lavoro, collaborazione e documentazione, ho garantito che il sistema non solo affrontasse le sfide di design immediate, ma anche preparasse il terreno per una crescita futura. Il sistema di design pilota ha dimostrato il valore di processi chiari e collaborazione interfunzionale, creando un prodotto più forte e coeso sia per il team che per gli utenti.
E.
Disponibile per progetti di design system su prodotti digitali complessi.
Se questo approccio ti interessa, confrontiamoci.
© Edoardo Sportelli - 2026. Living in Italy, in Fiastra, nestled in the Sibillini Mountains. Like Tuscany, but better. Policy Privacy and Data Protection. No reuse or redistribution without permission.
E.
Disponibile per progetti di design system su prodotti digitali complessi.
Se questo approccio ti interessa, confrontiamoci.
© Edoardo Sportelli - 2026. Living in Italy, in Fiastra, nestled in the Sibillini Mountains. Like Tuscany, but better. Policy Privacy and Data Protection. No reuse or redistribution without permission.
Disponibile per progetti di design system su prodotti digitali complessi.
Se questo approccio ti interessa, confrontiamoci.
© Edoardo Sportelli - 2024
Living in Italy, in Fiastra, nestled in the Sibillini Mountains. Like Tuscany, but better.
Policy Privacy and Data Protection.
No reuse or redistribution without permission.
E.