Per aziende con un prodotto digitale
Figma dice una cosa, la produzione ne dice un'altra.
Non è un problema di disciplina del team: è che manca un sistema che renda impossibile sbagliare. Costruiamo librerie di componenti che il vostro team usa davvero, e le teniamo allineate a quello che disegnate.
In parole semplici
Se non lavorate nel software, ecco cosa facciamo e perché vi conviene.
Il ricettario dell'interfaccia
Colori, bottoni, messaggi: tutte le regole in un posto solo.
Si decide una volta
Niente più ore spese a rifare le stesse scelte.
Lo costruiamo con voi
Regole scritte, pezzi pronti nel vostro codice, team formato.
Le parole che usiamo
Le trovate in questa pagina. Ecco cosa vogliono dire.
Token
I valori di base del sistema, ognuno col suo nome: il blu principale, lo spazio standard fra due elementi, la dimensione del testo. Si cambia il valore in un punto e cambia ovunque.
Componente
Un pezzo d'interfaccia pronto all'uso, come un bottone o un campo da compilare, costruito una volta con le regole del sistema.
Libreria di componenti
L'insieme dei componenti, nel codice e in Figma, con lo stesso nome da entrambe le parti.
Figma
Il programma in cui si disegnano le schermate prima di programmarle.
Framework (React, Angular, Vue)
Gli strumenti con cui i vostri sviluppatori costruiscono il prodotto. Lavoriamo in quello che usate già.
Audit
L'analisi di quello che c'è oggi: un documento che dice cosa non va e in che ordine sistemarlo.
Riconoscete qualcuno di questi?
Se ne riconoscete tre su cinque, il problema non è estetico ed è già costoso.
Lo stesso bottone esiste in sei versioni
Nessuna è sbagliata, nessuna è uguale all'altra, e nessuno sa quale sia quella buona.
Ogni sviluppatore decide a modo suo
Nessuno ha stabilito come deve essere l'interfaccia, quindi ognuno sceglie da sé. E i vostri clienti se ne accorgono.
Quello che approvate non è quello che va online
Il designer vi mostra una cosa, gli sviluppatori ne consegnano un'altra, e ogni revisione si mangia mezza giornata a capire quale delle due è giusta.
Ogni piccola modifica grafica costa più del previsto
Chiedete di cambiare un colore o un carattere e vi rispondono «qualche giorno». Non stanno esagerando.
Chi l'ha costruito non c'è più
Funziona, ma nessuno sa perché è fatto così, e quindi nessuno osa toccarlo.
Il costo non si vede in bilancio, ma è misurabile: sono le ore che ogni release spende a rifare decisioni già prese.
Cos'è un design system
Un insieme di decisioni prese una volta: colori, misure, testi, componenti. Ogni schermata nuova le riusa invece di rifarle, e cambiarne una le aggiorna tutte. Questo è il nostro: esploratelo, e provate a cambiare il colore principale.
Trascinate per muovervi, Ctrl + rotellina per lo zoom.Trascinate per muovervi, due dita per lo zoom. Con la tastiera: frecce per muovervi, + e − per lo zoom, 0 per vedere tutto.
Il percorso di un colore
Una decisione presa in Figma arriva online così com'è.
Quanto fa risparmiare
Due esperimenti, uno sui designer e uno sugli sviluppatori. Sono piccoli e li presentiamo per quello che sono: misurano lo stesso effetto da due lati.
Lo stesso modulo, in meno della metà del tempo
| Come | Ore (mediana) |
|---|---|
| Da zero | 4,2 ore |
| Con il design system | 2 ore |
Tempo mediano di 8 sviluppatori per costruire lo stesso modulo di contatto, prima da zero e poi con un design system esistente (Carbon di IBM), apprendimento compreso. Un esperimento su un campione piccolo, non una statistica di settore.
Fonte: Sparkbox, «Yes, Design Systems Do Improve Developer Efficiency and Design Consistency»
I designer finiscono un terzo prima
| Come | Tempo (senza = 100) |
|---|---|
| Senza design system | 100 |
| Con il design system | 66 (−34%) |
Tempo per lo stesso tipo di compito, fatto 100 quello senza design system. Ogni designer ha lavorato con e senza, su due compiti equivalenti. Esperimento interno di Figma, 2019: gli autori lo considerano il risparmio massimo, con un sistema perfettamente adatto al compito.
Come lavoriamo
Quattro fasi. Per ognuna sapete in anticipo cosa entra, cosa esce e quanto dura — anche se decidete di fermarvi dopo la prima.
1–2 settimane
Inventario
Guardiamo cosa avete davvero, non cosa dovreste avere: quante varianti dello stesso componente esistono, quanti valori sono scritti a mano, dove Figma e codice hanno smesso di parlarsi. Esce un documento con le duplicazioni, le priorità in ordine di costo e beneficio, e una stima delle ore che il team perde oggi.
2–3 settimane
Fondamenta
Token: colori, misure, tipografia. Non scelti a occhio ma calcolati, con i contrasti risolti e verificati sia in chiaro sia in scuro. È la parte che nessuno vede e che regge tutto il resto — e se sbagliata qui, ogni componente eredita l'errore.
4–8 settimane
Componenti
La libreria vera, in Figma e nel framework del vostro prodotto — React, Angular, Vue o quello che usate — con gli stessi nomi da entrambe le parti. Ogni componente con i suoi stati, la sua accessibilità e la sua documentazione. E soprattutto: il modo per aggiungerne uno nuovo senza rompere quelli che ci sono.
continuativa
Adozione
Un sistema che nessuno usa è un costo, non un investimento. Questa fase è formazione, revisioni, e i controlli automatici che impediscono di tornare indietro: se qualcuno scrive un colore a mano o rompe una soglia di contrasto, la build fallisce prima di andare online.
In tre modi
Tre porte d'ingresso diverse, a seconda di dove siete adesso.
2 settimane
Audit dell'interfaccia
- Per chi
- Sapete che qualcosa non va ma non sapete quanto costa, e vi serve un numero da portare in riunione.
- Cosa ricevete
- Un documento con gli screen delle schermate, le criticità riscontrate e le priorità di risoluzione — ordinate per impatto e per costo di intervento. È anche il modo più economico di vederci lavorare prima di decidere qualcosa di più grande.
6–12 settimane
La vostra libreria di componenti
- Per chi
- Avete un team di sviluppo e volete smettere di ridiscutere le stesse decisioni a ogni schermata.
- Cosa ricevete
- Una libreria che il vostro team usa da subito: componenti nel framework che avete già scelto, la loro controparte in Figma con gli stessi nomi, i token che li tengono insieme, e la documentazione che spiega perché — non solo come.
Due strade
Riordino
Avete già dei componenti. Non li buttiamo: li mettiamo in ordine, togliamo i duplicati, estraiamo i valori scritti a mano, e ci scriviamo sopra la documentazione che oggi non c'è. È la strada più rapida e quasi sempre la più conveniente.
Da zero
Non c'è niente, o quello che c'è non è recuperabile. Si parte dalle fondamenta e si costruisce nell'ordine giusto — token, poi primitive, poi composizioni.
continuativo, a giornate
Affiancamento
- Per chi
- Il sistema c'è e volete che resti vivo, invece di degradare release dopo release.
- Cosa ricevete
- Componenti nuovi, revisioni, formazione, e il presidio perché Figma e produzione non tornino a divergere. Si compra a giornate e si interrompe quando volete.
Quello che ci chiedete prima di dire di sì
«E chi lo mantiene, dopo?»
Il vostro team, ed è il punto. La fase di adozione serve esattamente a questo: se alla fine il sistema dipende da noi, abbiamo fallito. Vi lasciamo la documentazione, i controlli automatici e le persone formate.
«E se poi il team non lo usa?»
Succede quando il sistema è stato costruito lontano da chi lo deve usare. Per questo lavoriamo dentro il vostro flusso, non accanto: i vostri sviluppatori partecipano, e quello che non li convince lo cambiamo prima che diventi legge.
«Non è troppo per noi?»
Probabilmente sì, se siete in tre. Un sistema sovradimensionato è uno dei modi più comuni di sprecare soldi in questo campo. Ve lo diciamo nell'inventario, e se la risposta è che vi basta molto meno, la risposta è quella.
«Noi usiamo Angular, non React»
Lavoriamo nel framework che avete, non in quello che preferiamo noi. I token sono indipendenti dal framework — variabili CSS e file di dati — e i componenti si scrivono nel vostro, con le vostre convenzioni. Il metodo è lo stesso, cambia solo la sintassi.
«Come evitate che Figma e codice divergano di nuovo?»
Non ci si affida alla buona volontà. I token hanno una fonte unica da cui si generano entrambe le parti, i nomi sono identici, e i controlli automatici bloccano quello che esce dal sistema. La divergenza non si previene con la disciplina: si rende difficile.
Tre domande, e vi diciamo se vi serviamo
Scriveteci o chiamateci: vi facciamo tre domande sul vostro prodotto e sul vostro team. Se la conclusione è che non vi serviamo, ve lo diciamo.