Scopri il Design Foundation Sprint

No. Lavoriamo su una parte rappresentativa del prodotto, abbastanza ampia da definire una nuova direzione che possa poi essere applicata progressivamente al resto.

Dipende dal prodotto e dai problemi da risolvere. Possiamo lavorare trasversalmente su struttura, navigazione e componenti condivisi oppure approfondire un workflow significativo dall’inizio alla fine. La scelta viene fatta insieme al team all’inizio dello Sprint.

Non lavoriamo con un numero prestabilito di schermate. Definiamo un perimetro compatibile con le sei settimane e abbastanza ampio da permetterci di prendere le decisioni necessarie.

Non subito, ed è una scelta voluta. Un design system completo copre tutto il prodotto, con ogni componente, variante e stato, ed è pensato per crescere e mantenersi nel tempo: non nasce in sei settimane. Con lo Sprint ne costruiamo le fondamenta, cioè design token, componenti principali e pattern ricavati dalla parte di prodotto che ridisegniamo. È una base che il team usa da subito e su cui il design system cresce, in autonomia o insieme a noi.

Significa rendere esplicite informazioni che spesso rimangono implicite: come utilizzare i componenti, quali pattern preferire, quali vincoli rispettare e come estendere il sistema senza perdere coerenza. Queste regole possono essere utilizzate dal team e fornite come contesto agli agenti AI, per esempio in un DESIGN.md o in formati equivalenti.

Perché senza regole l’AI produce AI slop, e i problemi sono due. Il primo è che i prodotti finiscono per somigliarsi tutti: per un software B2B è un problema commerciale, perché diventa più difficile farsi scegliere. Il secondo è che i pattern vengono applicati senza capire quando servono, e l’interfaccia perde chiarezza proprio dove l’utente ne ha più bisogno. Un team di design guarda il prodotto in un altro modo: lavora su gerarchie, semplificazioni e flussi reali, e cambia quello che poi viene dato agli agenti AI. Con un design system solido e regole esplicite, gli agenti AI lavorano dentro un linguaggio già definito e il team sviluppa più in fretta, senza perdere coerenza.

Sì. Il prototipo, la libreria Figma e la documentazione servono proprio a dare al team una base da utilizzare ed estendere in autonomia.

Sì. Possiamo approfondire il redesign con nuovi Agile Design Sprint, implementare componenti e pattern con la Code Foundation oppure rivedere periodicamente il lavoro prodotto internamente. Il Design Foundation Sprint rimane comunque un progetto completo anche senza attività successive.

Sì. Con la Code Foundation possiamo implementare design token, componenti e pattern direttamente nello stack del prodotto, adattandoci a React, Angular o alle tecnologie già utilizzate dal team.

È il contesto in cui questo approccio trova più naturalmente applicazione, soprattutto per SaaS, software enterprise e prodotti con flussi, ruoli e funzionalità articolate. Può funzionare anche per altri prodotti digitali che abbiano già raggiunto una certa complessità.