La meraviglia di progettare un Design System con metodo (Parte 1)

Guida pratica allo sviluppo di un Design System cercando di dormire sereni la notte

Riccardo Ghignoni
May 22 · 7 min read
Illustrazione di Diego Pavan

La faccio breve.

Era ottobre 2017, ho avuto la fortuna di avere un manager illuminato che di sua iniziativa mi ha inviato una mail, chiedendomi di rivedere le linee guida stilistiche dei prodotti digitali che avevamo redatto insieme 3 anni prima.

Un sogno. ✨

Così, come sempre “da cosa nasce cosa”, e la richiesta di revisione styleguide si è trasformata nel mio primo incarico di progettazione di un Design System.

Dal World Wide Web.

Online per fortuna troviamo moltissima documentazione su Design Systems (articoli Medium, libri strepitosi, aziende illuminate che condividono), esempi virtuosi (Atlassian, Carbon, Polaris, Uniform tra i miei preferiti), semilavorati pronti da essere personalizzati (Cabana, Symbol, etc.), tutto ovviamente condito con l’omnipresente Atomic Design raccontato dal Brad Frost.

Cosa vogliamo di più? Facile no?
Non proprio.


Cos’è un Design System?

La sua definizione ha contorni ancora labili, ma possiamo definirlo come: una raccolta interconnessa di PATTERN e buone PRATICHE coerentemente organizzate per raggiungere lo scopo di un prodotto digitale.

Il suo scopo è quello di portare a sistema la progettazione, generando efficienza e scalabilità nel disegno delle interfacce, qualità e coerenza nel loro ambiente.

Mia personale rappresentazione di un Design System, che come abbiamo detto è una definizione molto soggettiva. :)

Cosa troviamo dentro un Design System?

  1. PATTERN FUNZIONALI
    Componenti, blocchi ripetibili e riutilizzabili di un’interfaccia.
    Come con le Lego possiamo usare dei componenti per costruire una soluzione ad un problema di progettazione. In genere un comportamento dell’utente, scatena l’utilizzo di un pattern.
    Ad esempio: per inviare un feedback all’interno di una pagina potremo utilizzare come soluzione un componente “form” (fatto dei singoli input text, checkbox, textarea, etc.) e un componente “pulsante”.
  2. PATTERN PERCETTIVI
    Styleguide, l’aspetto estetico che viene percepito dall’utente navigando una certa interfaccia.
    Colori, tipografia, animazioni, spaziature, icone, forme, layout, ma anche microcopy, tutto ciò che serve a trasmettere l’identità del prodotto a prescindere dalla funzionalità.
    In pratica è il feeling di prodotto” che percepiamo quando navighiamo una certa interfaccia. Quando sono in una schermata e riconosco immediatamente di essere “in casa” di quel prodotto.
  3. BUONE PRATICHE
    Approcci condivisi, tecniche e processi che il team applica per disegnare e costruire interfacce.
    Qual è la nomenclatura interna al team che usiamo per riferirci ai singoli elementi? “titolo”, “header”, o “scritta grande”? Oppure come decidiamo di organizzare le esportazioni e i file di consegna, etc.
  4. PRINCÌPI
    Lo spirito alla base degli obiettivi progettuali del team.
    Una sorta di “motto” che sincronizzi in breve tutti sulla stessa lunghezza d’onda, per l’elaborazione delle nostre interfacce.
    E’ importante che non ci sia imposizione dal team di design, ma che il tutto emerga dalle persone dell’azienda stessa. Può essere d’aiuto anche un vero e proprio manifesto, che specifichi l’indole che anima il team per il raggiungimento degli obiettivi progettuali.
  5. IDENTITÀ (può non essere inclusa nella documentazione del Design System)
    In alcuni casi potremmo decidere di inglobare nel Design System anche ciò che riguarda l’identità aziendale, non solo per ciò che è demandato al digitale. Ad esempio i requisiti e regole di applicabilità del logo, la parte di composizione fotografica applicabile ai materiali cartacei, il tono di voce usato dall’azienda, o estendere a tutta la parte di mission aziendale.

Quale valore porta un Design System?

Il solo processo di strutturazione di un Design System fa in modo che tutti i reparti all’interno dell’azienda si sincronizzino su un linguaggio comune di progettazione.

Il nostro scopo come team di design è quello quindi di agevolare l’emergere di buone pratiche, documentarle, renderle coerenti con il resto, favorire la diffusione della cultura e identità aziendale all’interno di tutti i reparti, al fine di produrre interfacce consistenti e sempre riconoscibili.

Inoltre la consultazione e l’applicazione di un Design System non richiede competenze specifiche. I pattern e le pratiche saranno comprensibili ed applicabili non solo dai designer ma da tutti i reparti: dal marketing per creare delle landing-page, magari in concomitanza con chi si occupa di copywriting che potrà valutare ingombri e spazi, o dal team di sviluppo per avere codice front-end ad hoc per i componenti.


Portare a casa il risultato.

Ho imparato sulla mia pelle quanto possa esser lungo un progetto di questo tipo, e quanto l’orientamento al risultato debba essere sempre la priorità. Perdere la strada maestra è più facile di quel che si pensi.

Non vedere la vetta perché ci sono le nuvole è la normalità, perdere fiducia sul progetto da parte di tutti è frustrante, declassare il progetto al “mettiamolo un attimo in stand-by” è sempre dietro l’angolo.

E’ passato un anno e mezzo.

C’è voluto tempo, cultura, sudore, contaminazione, confronto, ma è andata bene. Oltre le aspettative.

Oggi quell’azienda ha iniziato l’evoluzione di quelle che un tempo erano linee guida stilistiche; ha una sua piattaforma fatta di componenti, buone pratiche e tutto ciò che serve a diffondere internamente un linguaggio comune da trasformare ed esporre in maniera coordinata e consistente.
E’ stato già parzialmente applicato in un progetto pilota e pian piano arriverà anche a tutte le interfacce che il cliente gestisce.

Merito nostro?
No, di un metodo.

Disclaimer:

Nonostante la mia esperienza sia stata positiva, applicare unicamente un metodo di lavoro e una roadmap, non garantisce certamente il successo del progetto.
Nessun metodo da solo è infallibile, ognuno potrà trovarsi meglio con alcune parti piuttosto che con altre. La cosa certa è che l’utilizzo di metodo, una timeline di progetto, e tenere ritmo sia essenziale.

Proverò a raccontarvi come ho agito, e come questo mi abbia permesso di arrivare ad una consegna che soddisfacesse le aspettative promesse.

Vorrei solo condividere l’aspetto virtuoso di applicare un metodo, scandire bene le fasi di lavoro, agire con consapevolezza, senza lasciare troppo all’improvvisazione e ai pareri personali.


Imparare ad imparare.

Shu Ha Ri

Porto nel cuore un breve articolo che aveva scritto una persona che stimo, e che mi ha introdotto al concetto dello Shu Ha Ri come via dell’apprendimento.

Sono le fasi che conducono alla padronanza di una tecnica, seguendo principalmente 3 passi:

  1. “Shu” — Segui la regola: si applica la regola in maniera pedissequa, senza farsi troppe domande. Dobbiamo imparare i fondamenti e la tecnica. Seguiamo il consiglio di chi ha già esperienza. Partiamo da lì.
  2. “Ha” — Vìola la regola: si comincia a discostarsi dalla regola, si sperimenta, ci si rende consapevoli di ciò che funziona e cosa no, si apprende dagli altri, cerchiamo il confronto.
  3. “Ri” — Sii la regola: si trascende. Non si pensa più alle regole, ma si comincia ad applicare la regola su tutto, in maniera naturale ed implicita. Il nostro stesso agire “è” la regola.

Uso questo parallelismo NON per dirvi che alla fine del percorso saremo dei “Master of Design Systems”, ma per aiutare a comprendere che ci sono momenti precisi e dedicati per fare cose diverse: alcuni in cui sperimentare, ed altri in cui tenere duro, ascoltare, e fare tanta ricerca.

Double Diamond

“Old but gold”. Siamo tutti consapevoli che ci sono decine di metodi efficaci di progettazione, molte evoluzioni, e spesso personalizzarsi il proprio porta virtuosismi. Ma ho optato per il metodo base, quello che mi ha aiutato un sacco di volte: l’intramontabile Double Diamond di Design Council.

Che bellezza.

Prima di partire.

La strada è lunga in un territorio nuovo (almeno per me lo era).
Sarà importantissimo essere chiari e coordinati con tutto il team su:

  • Cosa consegnare: Siate chiari sulle aspettative di consegna. Non state consegnando un re-design, state creando una piattaforma di approvvigionamento componenti e pratiche in funzione dell’azienda.
    Nel nostro caso ci eravamo detti di chiudere una Fase 1 con un (Design Brief) documento di analisi che portasse già valore come “stato dell’opera”, sviluppasse una proposta, da applicare poi nella Fase 2, con la consegna di una piattaforma di Design System nuova di zecca.
  • Apporto al progetto: Stabilite e cadenzate il vostro apporto.
    Ad esempio dedicavo almeno 1,5 giornate lavoro / settimana sul progetto.
  • Tempi di consegna: Quando l’azienda avrà in mano quanto pattuito.
    Noi avevamo definito la chiusura della Fase 1 entro i primi sei mesi, e ipotizzato altri sei mesi per la Fase 2.
  • Cerimonie: Impostate un appuntamento fisso (per noi era settimanale), si discuteva ciò che era stato fatto nella settimana precedente, e cosa avremmo dovuto fare nella seguente.

Tutto è pronto per passare a raccontarvi in concreto come ho affrontato il progetto, pezzo per pezzo con la SECONDA PARTE dell’articolo:


Storie di design, esseri umani e interazioni.

Sharing is caring:

L’articolo era interessante? Lasciaci qualche applauso 👏👏👏👏 e condividilo con qualcuno!

UX Tales è una pubblicazione aperta: ✍️ proponi qui il tuo articolo, oppure scrivici su Twitter o su Facebook

UX Tales

Storie di design, esseri umani e interazioni.

Riccardo Ghignoni

Written by

I love learning, understanding, asking, knowing, touching, and making stuff. I’m curious. Designer @Officina31.

UX Tales

UX Tales

Storie di design, esseri umani e interazioni.