In DataCamp la nostra missione è democratizzare l’educazione alla data science per tutti e, con oltre 2 milioni di studenti nel mondo, stiamo facendo progressi rapidi. Operare a questo ritmo di crescita richiede uno sforzo importante da parte di tutti in azienda e introduce tante sfide nuove ed entusiasmanti.
Per il team di design significa passare da una progettazione pagina per pagina a un modo di progettare più scalabile. Il riuso di componenti esistenti, la riduzione dei tempi di sviluppo, il miglioramento dell’usabilità e l’aumento dell’accessibilità stanno diventando sempre più importanti.
Questo articolo spiega come stiamo iniziando a dare un senso a un design system.
Che cos’è un design system?
Un design system riunisce tutti i componenti necessari per distribuire e riprodurre una soluzione di design. Non è qualcosa di nuovo o esclusivo del design di prodotti digitali — nella storia si trovano moltissimi esempi.
Per esempio, il primo impero cinese aveva il problema che gli arcieri non potevano usare le frecce dei compagni. Ogni freccia era progettata specificamente per un certo arco, quindi le altre semplicemente non andavano bene. Il primo imperatore cinese, Ying Zheng, standardizzò il modo in cui venivano progettate le frecce e questo ebbe un enorme impatto sulle loro conquiste militari.
Negli anni ’50, ogni stazione della metropolitana di New York aveva la propria segnaletica. Ciò causava molta confusione perché ogni singola stazione aveva un proprio modo di orientare le persone. Di conseguenza, molti erano restii a usare il sistema di trasporto perché non capivano come funzionasse. Massimo Vignelli e Bob Noorda crearono il NYC Transit Authority — Graphics Standards Manual, che documentava come realizzare i cartelli e dove posizionarli all’interno delle stazioni. Nel tempo questo sistema è rimasto più o meno invariato e viene ancora usato attivamente oggi.
Perché dovremmo avere un design system?
Quando ogni pagina è progettata in isolamento, molti componenti hanno duplicati o alternative simili. Questo rende un prodotto digitale difficile da capire per gli utenti e difficile da mantenere per l’ingegneria. In DataCamp abbiamo scoperto oltre 20 tipi diversi di pulsanti all’interno del nostro prodotto, ognuno con le proprie particolarità (stati hover differenti, stati disabilitati incoerenti, ecc.). È difficile tenere traccia di tutti questi componenti quando un prodotto cresce rapidamente e diventa quasi impossibile mantenerli. È qui che entra in gioco un design system.
Per un prodotto digitale, un design system descrive i componenti dell’interfaccia utente che possono essere usati per creare un’interfaccia che risolve un problema e che offrirà un’esperienza coerente all’utente.
Quando un design system è implementato bene produce un effetto a cascata che …
- Riduce le incomprensioni
- Riduce i tempi di implementazione
- Riduce il lavoro di manutenzione
- Riduce i bug
- Riduce i ticket di supporto
- Aumenta la qualità
- Aumenta l’efficienza
- Aumenta la longevità
- Aumenta la facilità di apprendimento
- Aumenta l’usabilità
- Aumenta l’accessibilità
- Aumenta l’innovazione
- Aumenta la concentrazione
- Aumenta le vendite
Non è facile …
Creare, mantenere e far rispettare un design system richiede molta disciplina e un impegno continuo da parte di chiunque prenda parte al processo di creazione. Non è solo design; anche ingegneria e product management sono stakeholder importanti. Tutti dovrebbero essere in grado di porre domande difficili come: “Perché stiamo costruendo questo?”, “Possiamo riutilizzare questo componente altrove?”, “Abbiamo già qualcosa di simile?”, “Questo componente personalizzato porta benefici sufficienti rispetto allo sforzo richiesto?”.
Design System 101 in DataCamp
1. Crea un inventario dei componenti
Obiettivo: assicurarsi che tutti conoscano l’esistenza e lo stato di un componente.
Quando ho iniziato in DataCamp c’era un file Sketch che conteneva colori, icone, font e alcuni componenti di base. Era ben lontano dall’essere completo, ma era un buon punto di partenza. Anche il front-end aveva una raccolta di componenti usati nei vari progetti.
Insieme abbiamo creato un inventario in Airtable basato sui componenti usati in produzione. Questo ha dato al team di design un’idea di ciò che esisteva già e ci ha evitato di creare nuovi componenti senza saperlo. Ci ha anche dato un’idea di quanti componenti simili avevamo e di quanto fosse grave la situazione.
2. Usa convenzioni di naming
Obiettivo: evitare incomprensioni tra Design e Ingegneria.
Confrontando i componenti abbiamo notato che Design e Ingegneria non parlavano la stessa lingua. Ad esempio, il “colore primario” definito dal design era il “colore secondario” nel codice. Cose del genere possono generare fraintendimenti quando i team iniziano a crescere e causano confusione e frustrazione. Ci siamo assicurati che la stessa terminologia venisse usata in tutti i team.
3. Ottimizzare il workflow di design
Obiettivo: evitare di perdere lavoro e avere un flusso trasparente.
Lavorare insieme come team di design comporta sfide specifiche. Conservavamo i design su Dropbox ma, quando il team ha iniziato a crescere, i rischi di perdere lavoro e la fatica di tenere traccia delle modifiche sono aumentati drasticamente.
Il nostro team di design era molto aperto a cambiare workflow e abbiamo iniziato a usare Abstract. Ci ha permesso di versionare correttamente i design, avere un flusso di lavoro trasparente e progettare con maggiore sicurezza.
4. Migliore documentazione + onboarding
Obiettivo: accelerare l’onboarding e ridurre l’overhead comunicativo.
Abbiamo iniziato a documentare il nostro processo e il design system usando Slite. Se dobbiamo spiegare qualcosa più di una volta, allora va documentato e condiviso con il team. Questo evita molto overhead di comunicazione e impedisce che le informazioni vadano perse.
5. Design review
Obiettivo: allineare le aspettative tra Design e Ingegneria.
È importante che le design review avvengano in entrambi i sensi. I designer dovrebbero poter rivedere il front-end, ma anche il front-end dovrebbe poter rivedere il design. I designer hanno questa voglia di creare qualcosa di nuovo e accattivante. Gli ingegneri devono poter fare domande difficili come: “Perché stiamo costruendo qualcosa di custom?”, “Non possiamo riutilizzare questo componente?”, “Possiamo migliorare questo componente?”, “Questo componente vale lo sforzo di sviluppo extra?”. Si tratta di giustificare le decisioni e allineare le aspettative di tutti i coinvolti.
Conclusione
Abbiamo appena iniziato a mettere insieme il nostro design system e stiamo ancora cercando di dare un senso a tutti i componenti duplicati che abbiamo trovato nel nostro prodotto. La strada è ancora lunga, ma con ogni componente su cui mettiamo mano stiamo creando un prodotto migliore, più coerente e più facile da imparare per i nostri clienti.
Siamo curiosi di sapere come altre organizzazioni diano un senso a un design system. Mandami una email se vuoi condividere la tua esperienza.
In DataCamp cerchiamo sempre persone di talento da inserire nel team. Ti interessa? Scopri le posizioni aperte.
