Questo articolo è la seconda parte di La meraviglia di progettare un Design System con metodo (Parte 1), e tratta in dettaglio il metodo che abbiamo seguito nel progettare da novizi il nostro primo Design System, con il supporto dell’intramontabile Double Diamond.

Prima di iniziare…

Come già detto precedentemente lo spirito di questo articolo non è un invito ad “usare questo metodo”, ma a “fare le cose con metodo”.
Ciò che porto a casa da questa esperienza è che come team abbiamo sempre intravisto la meta finale, ma non avevamo l’idea precisa di quale fosse anche solo uno qualsiasi degli itinerari per arrivarci.

Per questo credo che usare un metodo (uno qualsiasi davvero) sia indispensabile. Avere una roadmap, risultati cadenzati, essere disciplinati, obiettivi concreti, ci ha aiutato enormemente, sopratutto nella fase iniziale di comprensione del lavoro che ci aspettava.

Seguire una metodologia non ci assicura di “trovare il tesoro”, ma perlomeno ci da la certezza di fare il viaggio in sicurezza e di “trovare la X sulla mappa”.

Quanto segue non è quindi una ricetta da seguire in maniera pedissequa, ma se può servire a generare idee, confronto, e stimoli verso chi come me era alle prime armi, allora l’articolo ha raggiunto il suo scopo.

1. DISCOVER

E’ la fase di comprensione.

Si cerca di capire il problema, andare in profondità. Occhi aperti su cosa fanno quelli più bravi di noi. Ogni Design System è costruito sull’azienda, quindi potremo prendere spunti da altri, ma tutto dovrà emergere dall’azienda stessa.

🙋‍♂️ Azioni

• Cercare “Dentro”.
  Analizzate i vostri siti e stilate una lista di criticità di superficie che balzano all’occhio, condividete gli intenti con gli altri reparti (customer-care, sviluppo, marketing) per sapere difficoltà incontrate finora, prendete consapevolezza di quali dati oggettivi siano a vostra disposizione da poter consultare in futuro (analytics, mappe di calore, etc.).
• Cercare “Fuori”.
  Createvi una cultura di quello che state facendo: libri, articoli online, partecipate a workshop, cosa che ovviamente proseguirà anche nelle fasi successive.
  Studiate e censite quelli bravi: come già detto ad esempio Atlassian, Hudl, IBM, Shopify, per citarne alcuni.
• Architettura.
  Fin dall’inizio sarà importante impostare un territorio: non solo uno spazio online (ordinato, pulito, e con le versioni dei file) dove condividere e raccogliere tutti i materiali, ma anche avere un’idea dell’architettura (un indice) del vostro Design System desiderato.

🙇‍♂️ Criticità

Perimetro d’azione. Trovare i bordi del progetto è difficile.
Il primo indice che noi avevamo stilato era 12 pagine: tutte cose bellissime (segnaletica nei luoghi di lavoro, kit di welcome on-board…), ma abbiamo un obiettivo concreto, tempistiche, e le risorse al progetto sono limitate.

Date quindi priorità (MoSCoW) agli argomenti e occupatevi inizialmente solo dei “must have”, ad aggiungerne altri ci sarà tempo. A questo proposito a mio avviso, meglio meno ma in profondità, che molti solo in superficie.

👆 Consigli

Cercate di non considerare un altro Design System come perfetto per voi e da cui pescare a piene mani. Un Design System è un progetto ad hoc per un’azienda che ha sempre necessità e richieste uniche.
Ascoltate gli altri reparti e prendete appunti: individuerete fin da subito i princìpi percepiti nei team, e vi aiuteranno ad allineare un linguaggio condiviso.

2. DEFINE

Fase di analisi profonda. Ci siamo fatti un’idea di dove siamo e di cosa vorremmo raggiungere.

Adesso dobbiamo raccogliere e mostrare dati che ci aiuteranno a ridurre le incertezze progettuali. Produciamo documentazione. Schematizzare l’analisi servirà a non perdere la bussola e mantenere il ritmo.

🙋‍♂️ Azioni

• Playground.
  Costruitevi un ambiente dove pasticciare e fare prove.
  A prescindere dallo strumento (io ad esempio ho usato Sketch) ricreatevi la situazione attuale: prendete delle pagine o dei flussi d’esempio su cui far prove dei cambiamenti che via via proporrete.
  Ad esempio tutti i mockup fatti fino a quel tempo dall’azienda erano in PSD. Per praticità avevo ricreato Home Page di prodotto, pagina comparativa, dettaglio, e carrello in Sketch usando stili e componenti ben strutturati pronti per essere modificati in maniera veloce.
• COSA analizzare.
  Nel nostro caso gli argomenti da affrontare con certezza erano:
  a. Colori: brand, interfacce, aree.
  b. Tipografia: caratteri, contesto, armonie, regole.
  c. Icone: proprietarie di prodotto, set generico a supporto.
  d. Moduli (Form): stilizzazione, modalità, validazioni, flussi.
  e. Errori e Avvisi: prevenzione, segnalazione, correzione.
  f. Editing: modifiche inline, pop-up, dati tabellari.
  g. Navigazione: disposizione menù, processi, trovabilità.
  h. Layout: framework, spazi, linee, ritmi di contenuti.
• COME analizzare.
  In ognuno dei capitoli sopra avevamo prodotto documenti affrontando:
  1. Situazione attuale: cosa fa la nostra azienda al riguardo?
  2. Problemi noti: cosa sappiamo non funzionare e cosa ci dicono i reparti?
  3. Benchmark: cosa fanno gli altri? (nel paragrafo dopo CHI analizzare)
  4. Ipotesi e proposte: come potremmo evolvere?
  5. Testing: valutiamo usabilità e accessibilità della proposta fatta.
  6. Montaggio: disegniamo la proposta sul nostro playground.
  7. Conclusioni: linee guida decise sull’argomento.
  X. Riferimenti: link interessanti, risorse, materiali utili.
• CHI analizzare.
  Sul punto 3 “Benchmark” abbiamo analizzato:
  - 5 Competitor principali.
  - 4 “Big” per buone pratiche (Amazon, Facebook, Google, eBay).
  - 6 Riferimenti che reputavamo virtuosi su vari fronti, per avanguardia e processi (Airbnb, Paypal, Stripe, HiOscar, Medium, Techcrunch).
  Ovviamente a questi aggiungevamo nell’analisi ciò che di buono avevamo trovato nei Design System visti nella fase precedente, o altri riferimenti nati dalla condivisione.
• Struttura.
  Vista la mole di dati da prendere siate strutturati e ordinati.
  Ci possono essere mille modi per collezionare dati. Io ho usato:
  - struttura a cartelle.
  - un buon editor di testo a fianco del browser.
  - screen di porzioni di schermo quando serve.
  - LiceCap: un tool per registrare da schermo in gif animate in modo da poterle inserire in qualunque documento senza plugin o conversioni video.

Un ordine temporale: tutta questa ricerca ha assorbito circa 20 giornate lavoro (3 mesi in tutto), a fronte di oltre 400 pagine di documentazione, e un Design Brief (con solo le conclusioni) di 50 pagine circa.

Ricordate la fase di “Shu” della via dell’apprendimento?

E’ tanta tecnica. Questo lavoro vi porterà inevitabilmente ad una visione e consapevolezza più ampia, ci prepara una forma mentis per le fasi successive in cui dovremo mettere in pratica i nostri insegnamenti, osare, sperimentare, e dare forma.

🙇‍♂️ Criticità

La routine. Facendo attività in maniera schematica ed impostata, il rischio che subentri la noia è alto. Non cedete, veder evolvere pian piano il vostro playground vi ripagherà. State facendo “tanta palestra in vista della gara”. Fatevi trovare al meglio.

👆 Consigli

Lasciate parlare i dati che state raccogliendo. Non lavorate per cercare conferme alle vostre teorie.
Potrei farvi innumerevoli esempi di ipotesi che ci eravamo fatti precedentemente all’analisi, e smontate dai dati raccolti. La voglia di usare Material è stata al momento accantonata in quanto non ci risultava così efficace sulle nostre tipologie di moduli desktop. Alla stessa maniera appena partiti non ci sarebbe mai passato per la testa di usare un “semplice” font di sistema per i contenuti testuali, analizzando i dati ci siamo ricreduti.

3. DEVELOP

E’ il momento di produrre potenziali soluzioni.

Si affina il nostro playground, si completano le pagine d’esempio, si validano le nuove linee guida su altri blocchi di contenuti, e si provano le interfacce con i breakpoint (mobile, tablet, desktop, etc).

🙋‍♂️ Azioni

• Pagine e Breakpoint.
  Dopo le costanti evoluzioni fatte nel vostro playground arriverete alla consegna di alcune delle pagine d’esempio ridisegnate e finalizzate.
  Risolvete possibili incongruenze e curate, per quanto possibile, le visualizzazioni sui diversi device.
  Per le mie pagine d’esempio avevo preparato le visualizzazioni su tutti i possibili breakpoint indicati da Bootstrap 4.
• Campionamento blocchi
  Ricordate il buon Content Inventory? Censite su tutte le pagine delle vostre interfacce i blocchi simili, categorizzate e campionate per il loro scopo. Ad esempio:

• Re-design dei singoli blocchi.
  Ovviamente le pagine d’esempio non copriranno le casistiche più particolari. A noi è tornato utile ridisegnare alcuni dei blocchi non coperti dalle pagine usate nel playground, per valutare se effettivamente le nostre nuove linee guida si adattavano come sperato.

• Documentazione per il reparto Sviluppo.
  Immagino che questa attività cambi proprio di azienda in azienda, lo scopo sarebbe quella di cominciare a preparare documentazione ad hoc per lo sviluppo.
  Ovviamente consultatevi e chiedete quali materiali agevolino il montaggio con il framework in uso.
  Noi abbiamo fornito wireframe a bassa fedeltà dei blocchi censiti, raccontando per ognuno i contenuti che ospiteranno. Ad esempio:
  Blocco contenuto prodotto:
  1. (icona + titolo + bollino)
  2. (video + lista con icone)
  3. (CTA + prezzo + offerta)

Si prova la fase “Ha” della via dell’apprendimento.
Abbiamo finalmente contestualizzato un ambiente e sappiamo come muoverci al suo interno. Possiamo sperimentare con cognizione di causa, riusciamo finalmente a vedere una visione d’insieme.

🙇‍♂️ Criticità

La troppa sicurezza. Saremo inebriati dal piacere di ridisegnare tutto “a modo nostro” in base alle conoscenze acquisite. Non perdiamo il confronto e testiamo più oggettivamente possibile le sperimentazioni.

👆 Consigli

Occhi nuovi. Siamo scesi in profondità indagando su ogni argomento, con ogni probabilità avremo tirato fuori ottime soluzioni (il giusto font pairing, una leggibilità certificata WCAG 2.0 dei testi, una navigazione consistente), e vederle funzionare insieme nella solita interfaccia in maniera olistica assicureranno un risultato.
Ecco. E’ il momento perfetto per fare pasticci nel tentativo di migliorare facendo di testa nostra. Dalla mia poca esperienza l’unica prevenzione, veloce e non dispendiosa, è stata quella di cercare un feedback (anche il collega alla scrivania accanto) su ogni possibile modifica evolutiva. Ovviamente non ci schermerà 100% dal fare cose inadeguate, ma sicuramente ci fa vedere la cosa con un’altra prospettiva e ci fa essere anche solo un pizzico più obiettivi.

4. DELIVER

Fase di riordino e consegna.

Tiriamo le somme e convogliamo tutto il nostro lavoro in una piattaforma che ospiti il nostro Design System, con le funzionalità e l’accesso più funzionale per l’azienda. Controlliamo e ordiniamo i materiali prima di consegnare.

🙋‍♂️ Azioni

• Guardiamo indietro.
  Ricontrolliamo che tutto sia in ordine nelle cartelle, che non manchi niente, che il playground si sia trasformato in file ufficiali, che tutti i materiali siano accessibili e nel posto giusto.
• Materiali di consegna “parlanti”.
  Premuratevi che il vostro lavoro possa essere portato avanti da qualsiasi altro designer senza impazzire.
  Ad esempio per me lavorando in Sketch questo passa ovviamente da simboli, simboli nidificati, e stili in ordine, nomi di layer comprensibili, gruppi che abbiano senso, immagini correttamente incluse, ed export nei giusti asset per Avocode e compagnia.
• Scegliere la Piattaforma.
  Questa scelta è in maniera inderogabile in funzione di chi e quanti utilizzeranno la piattaforma. Alcune domande che potete farvi sono:
  - Quali sono i reparti interessati?
  - Chi e quanti la aggiorneranno?
  - Sarà accessibile a tutti o protetta?
  - Dovrà ospitare file sorgenti (ad esempio i .sketch)?
  - Sarà repository anche per file più corposi (.psd, .ai, .zip)?
  - Ospiterà anche la parte codice dei componenti?
• Nel nostro caso, inizialmente invogliati dagli altri big, avevamo in mente di ampliare la nostra piattaforma proprietaria interna, perché scettici verso quelle già pronte. Provarne più in profondità alcune però ci ha fatto pienamente ricredere, e (grazie al consiglio di una bravissima docente — Gaia Zuccaro — ad un corso a cui partecipavamo) ne abbiamo trovata una che sembrasse fare proprio al caso nostro: Zeroheight.
• Linguaggio.
  Non mi dilungo sull’importanza dell’essere comprensibili, semplici, ed efficaci nelle pagine della nostra piattaforma. Abbiamo sempre parlato di linguaggio comune, preparate la piattaforma scrivendo al meglio… ma poi fatevi sempre validare il lavoro dai reparti che fanno progettazione contenuti di mestiere.

🙇‍♂️ Criticità

Pretendere di forzare la piattaforma. Usando delle soluzioni già pronte per ospitare i vostri materiali alcune cose vi sembreranno una limitazione (“la visualizzazione dei colori l’avevo pensata come su Polaris”, “non mi piace come visualizza gli stili tipografici”, e così via).
Andate oltre, e fate tutto come desidera la piattaforma stessa (aiutatevi con gli esempi che vi propongono).
“Siate acqua” e adattate voi i materiali come vengono richiesti, vi accorgerete dell’ordine e l’armonia che regnerà, e di piacevoli funzionalità a cui non avevate pensato (plugin per sincronizzare direttamente da Sketch, visualizzazione componenti come su Zeplin, comportamenti live via CSS, etc).

👆 Consigli

Ordine. Non abbiate paura di spendere un giorno in più a preparare perfettamente i materiali sorgenti. Questo tempo vi tornerà indietro amplificato ogni qualvolta non vi perderete a cercare un file, o potrete cambiare un solo simbolo per tutti i pulsanti dell’interfaccia, o ancor più passare materiali ad altri designer senza necessità di chiamate o introduzioni.

5. DIFFUSE… & EVOLVE

Adesso è il momento di diffondere quanto fatto.

Il lavoro non è ovviamente terminato con la consegna. Aggiungo questa quinta “D” perché lo scopo finale è ovviamente quello di un’adozione delle pratiche e dei nuovi componenti. Il lavoro di divulgazione (che era già partito nelle fasi precedenti) è quindi adesso strategico e imprescindibile.

🙋‍♂️ Azioni

• Raccontare.
  Argomentare e saper esporre magnificamente i benefici che porta l’utilizzo di un sistema di questo tipo risulterà essenziale per l’adozione del Design System. Siate pronti e scaltri.
  Non fornite agli altri reparti solamente l’accesso alla piattaforma, ma introduceteli con una piccola presentazione ad hoc che possa dargli una visione. Va da sé, meglio se dal vivo.
• Far toccare con mano.
  Reparto per reparto affiancate, in progetti reali, per far toccare con mano i vantaggi di utilizzare la piattaforma. Ascoltate e agevolate gli altri designer durante la prima volta di utilizzo, stimolateli nell’inviarvi feedback preziosi in qualunque momento, mostrate agli sviluppatori cosa possono trovare e chiedete come migliorare ancora per preparargli flussi di lavoro al meglio.
  Può sembrar banale, ma io penso sempre a qualche anno fa la meraviglia di sviluppatori abituati a ricevere dei file .PSD da aprire, campionare colori, caratteri e spaziature, nel mostrargli Zeplin con accesso veloce a informazioni css, asset pronti per essere scaricati in tutti i formati richiesti, spaziature tra gli elmenti, etc.
  Mi piace pensare che questo dovrebbe essere il benchmark di meraviglia quando presentiamo e facciamo toccare il nuovo Design System.

Siamo finalmente arrivati alla fase “Ri” della via dell’apprendimento.
Vi renderete conto che tutto quello che racconterete e disegnerete sarà in maniera spontanea e naturale sulla base del Design System stesso.
C’è da realizzare un nuovo componente? Verrà spontaneo e veloce. Sicuri della vostra tecnica, ma sempre critici dove e quanto serve.
E’ vostro dovere divulgare e diffondere quanto appreso nell’azienda.

🙇‍♂️ Criticità

Assenza di monitoraggio. Questo argomento meriterebbe un approfondimento a sé. Alla Kholmatova nel suo libro Design System traccia dei parametri su come valutare i criteri di adozione all’interno dell’azienda.
Non basatevi su criteri soggettivi, valutate se in concreto sono state adottate le buone pratiche nel fare un nuovo progetto. Come sempre, meglio che siano stata applicate in maniera errata (dato che possiamo correggere o analizzare incomprensioni), che non applicate affatto per sfiducia, pigrizia, o altri motivi.
Al riguardo segnalo un interessantissimo articolo di Cristiano Rastelli proprio su questo argomento.

👆 Consigli

Evolvere. Nulla di quello che è stato fatto è inciso sulla pietra. E’ un processo continuo. Noi stessi non dobbiamo perdere lo spirito critico verso il Design System realizzato. Fatevi domande, siate curiosi e aperti verso l’esterno, meravigliatevi delle novità e cercate come riportarle in maniera armoniosa nel vostro sistema progettuale.

Ogni reparto, ogni designer, può contribuire e suggerire un’evoluzione del System stesso. Quando questo accadrà in maniera migliorativa credo sarà proprio il segno di un adozione avvenuta con successo. 🙌

Approfondimenti

• Design Systems Book di Alla Kholmatova: il primo passo per cominciare a muoversi nell’elaborazione di un proprio Design System.
• Design Systems Handbook di InVision: approfondimento sul tema, sui metodi da seguire, e scenari di progettazione.
• Atomic Design di Brad Frost: probabilmente il capofila del cambiamento di mentalità sul progettare in maniera sistemica.
• Adele di UxPin: un buon repository di Design Systems dal mondo.
• Slack Design Systems: una fucina di idee e contaminazioni. Scambiare opinioni direttamente con chi ha fatto altri DS è un valore enorme.

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