Interveniamo quando un prodotto cresciuto nel tempo deve essere ripensato durante un replatforming, oppure quando una scaleup sta progettando un nuovo prodotto o un nuovo modulo. Lavoriamo su UX/UI, design system e componenti front-end per rendere il software più chiaro da usare, più coerente da sviluppare e più forte da presentare.
Redesign UX/UI di software esistenti
Molti software B2B sono solidi e svolgono funzioni importanti, ma sono cresciuti attraverso aggiunte successive: nuovi moduli, richieste dei clienti, eccezioni, permessi, integrazioni e flussi specifici. Il risultato è spesso un prodotto valido con un’interfaccia stratificata, poco coerente e difficile da usare.
Il momento per intervenire coincide spesso con un replatforming o una migrazione del front-end. Ripensare la UX in questa fase permette di trasformare l’investimento tecnologico in un miglioramento concreto dell’esperienza, senza trasferire nel nuovo sistema i limiti accumulati in quello precedente.
L’interfaccia incide anche sul modo in cui il prodotto viene percepito. Nelle demo, nelle gare, durante l’onboarding o nelle presentazioni agli stakeholder, un software datato o confuso può comunicare meno valore di quanto ne abbia realmente.
Abbiamo raccolto questo approccio anche in Come affrontare il redesign di un software enterprise.
UX/UI per nuovi prodotti e nuovi moduli
Lavoriamo anche con scaleup tecnologiche che stanno progettando un nuovo prodotto o ampliando una piattaforma esistente. In questi casi affianchiamo founder, responsabili di prodotto e developer mentre funzionalità, priorità e direzione sono ancora in definizione.
Trasformiamo requisiti e ipotesi in flussi e prototipi concreti, così che le decisioni possano essere discusse prima che diventino codice. Il design system nasce insieme al prodotto e crea una base condivisa per le evoluzioni successive.
Come comprendiamo un software complesso
La complessità di un software B2B non dipende solo dal numero di schermate. Nasce da processi operativi, ruoli, permessi, eccezioni, dati, integrazioni e regole di business che spesso esistono da anni.
Entriamo nel dominio insieme alle persone che conoscono il prodotto e il lavoro degli utenti. Utilizziamo workshop di co-design, User Story Mapping, Jobs To Be Done e ricerca mirata per mettere ordine nelle informazioni e individuare le aree su cui intervenire.
Portiamo presto le decisioni dentro prototipi navigabili. Il prototipo non è una presentazione finale, ma uno strumento per comprendere il problema, confrontare alternative e allineare prodotto, sviluppo e direzione.
Come progettiamo il software
Partiamo dalle aree che hanno maggiore impatto sull’uso o sulla percezione del prodotto: dashboard, flussi critici, moduli usati nelle demo, operazioni ricorrenti e componenti condivisi.
Procediamo in modo verticale e incrementale. Ogni parte viene progettata ad alta fedeltà, discussa con il team e preparata per lo sviluppo. Questo permette di validare una direzione su casi reali prima di estenderla al resto del software.
Per approfondire questi pattern: come creare dashboard efficaci e come progettare tabelle di dati usabili.
Design system in Figma
Mentre progettiamo l’interfaccia, costruiamo il design system in Figma: fondamenti visivi, token, componenti, pattern e regole d’uso. Non è un documento separato dal prodotto, ma il sistema che raccoglie le decisioni prese durante il lavoro.
Il team interno può usare questa base per progettare nuove schermate, mantenere coerenza tra moduli e ridurre le decisioni ripetute. Il sistema cresce insieme al software, senza richiedere di definire tutto in anticipo.
Component library e Storybook
Quando è utile, traduciamo il design system in una component library e la documentiamo in Storybook. Realizziamo i componenti di base e le storie di esempio necessarie a mostrare il comportamento dei componenti più complessi.
Lo sviluppo dell’applicazione resta al team del cliente, che mantiene il controllo dell’architettura, del codice e del know-how. Il nostro ruolo è creare un riferimento solido tra design e implementazione, compatibile con lo stack e i vincoli già presenti.
Come lavoriamo con il team interno
Organizziamo il lavoro in sprint di due settimane. In ogni ciclo mostriamo ciò che abbiamo progettato, raccogliamo feedback e definiamo le priorità successive. Il coinvolgimento del cliente viene calibrato sulla disponibilità delle persone e sui momenti in cui il loro contributo è realmente necessario.
Il team interno porta conoscenza del dominio, dell’architettura e dei vincoli tecnici. Moze guida la ricerca, la progettazione UX/UI e la costruzione del sistema di design. In questo modo le decisioni rimangono condivise e gli output possono entrare nel processo di sviluppo senza un passaggio di consegne isolato.
Abbiamo approfondito questo tema in Designer e developer: tre principi per lavorare meglio insieme.
Marco Trombetti Co-founder & CEO, Translated
Paolo Innocenti IS Director, Serioplast
I benefici per utenti, sviluppo e vendite
- Un software più facile da usare. Flussi, gerarchie e informazioni vengono ripensati intorno alle attività reali degli utenti. La complessità necessaria rimane, ma diventa più leggibile e gestibile.
- Uno sviluppo più coerente. Regole, pattern e componenti condivisi aiutano il team a costruire nuove funzionalità senza ridefinire ogni volta le fondamenta dell’interfaccia.
- Un prodotto più efficace da presentare. L’interfaccia torna a rappresentare la qualità e la maturità del prodotto, rendendo più chiari il suo valore e la sua evoluzione durante demo, gare e presentazioni.
Progetti UX/UI per software B2B
Serioplast — Design system per una nuova suite ERP
Serioplast aveva deciso di sviluppare internamente una nuova suite ERP e aveva costituito un nuovo team dedicato. Moze ha facilitato l’avvio del progetto, co-progettato l’architettura della suite e creato un design system su misura, trasferendo al team metodo e strumenti per continuare il lavoro in autonomia.
CommerceClarity — UX/UI e design system per un nuovo prodotto AI
CommerceClarity partiva da un’idea solida e da una proof of concept funzionante. Abbiamo lavorato con i founder su strategia di prodotto, UX/UI e design system, traducendo poi il sistema in codice. Con la crescita del team tecnico interno, le fondamenta create insieme hanno reso naturale proseguire lo sviluppo e l’evoluzione del prodotto.
Voxloud — Redesign UX/UI e design system per un centralino cloud
Voxloud offre un centralino telefonico in cloud attraverso applicazioni web, desktop e mobile. Abbiamo affiancato il team nel redesign della UX/UI, nella definizione di nuove funzionalità e nella creazione del design system, lavorando in sprint e come estensione del team interno.
Leapp — UX/UI per un’app di gestione degli accessi cloud
Leapp è un’applicazione desktop open source per gestire in locale le credenziali di accesso ai principali servizi cloud. Abbiamo progettato la UX/UI dell’applicazione e l’interfaccia web con cui i manager gestiscono autorizzazioni e accessi del team.
A chi è rivolto
Questo modello funziona soprattutto quando esiste un team tecnico interno che conosce il prodotto e vuole mantenere codice e competenze all’interno dell’azienda. Possiamo lavorare sull’intero software oppure partire da un modulo, un flusso critico o un’area con particolare rilevanza commerciale.
Collaboriamo con aziende software, imprese strutturate e scaleup tecnologiche su SaaS, piattaforme enterprise, gestionali verticali e applicazioni proprietarie.
Domande frequenti
Lavorate solo su software esistenti?
No. Possiamo modernizzare un prodotto cresciuto nel tempo oppure progettare un nuovo prodotto o modulo insieme a una scaleup e al suo team tecnico.
Potete lavorare durante un replatforming?
Sì. È uno dei momenti più frequenti in cui veniamo coinvolti. Progettiamo la nuova esperienza mentre il team definisce o implementa la nuova base tecnologica.
Possiamo iniziare da una sola area del prodotto?
Sì. Possiamo partire da una dashboard, un flusso critico, un modulo usato nelle demo o un insieme limitato di funzionalità, per validare la direzione prima di estenderla.
Come collaborate con il nostro team di sviluppo?
Lavoriamo in sprint, condividiamo prototipi e decisioni e teniamo conto dello stack e dei vincoli esistenti. Il team cliente rimane coinvolto nei momenti che richiedono conoscenza del dominio o valutazioni tecniche.
Sviluppate anche il front-end dell’applicazione?
Normalmente realizziamo la component library e la documentazione in Storybook, comprese storie esemplificative per i componenti complessi. Lo sviluppo delle schermate e delle funzionalità dell’applicazione resta al team interno.
Il design system è sempre necessario?
La profondità del design system dipende dal progetto. Per prodotti destinati a crescere, composti da più moduli o sviluppati da più persone, diventa spesso una parte importante del lavoro.
Da che budget partono questi progetti?
I progetti di design per software B2B partono indicativamente da 20.000 €. Il budget cresce in base alla complessità, al numero di aree coinvolte, alla profondità del redesign e alla presenza di attività front-end o design system.
Parliamo del tuo prodotto
Se stai ripensando un software esistente oppure progettando un nuovo prodotto o modulo, possiamo partire dal problema e definire insieme un primo perimetro di lavoro.