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

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

Riccardo Ghignoni
May 29, 2019 · 12 min read
Image for post
Image for post
Illustrazione di Diego Pavan

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.

Image for post
Image for post

1. DISCOVER

E’ la fase di comprensione.

🙋‍♂️ 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.

Image for post
Image for post
12 pagine di indice… un pò lunghetto.

👆 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.

Image for post
Image for post

2. DEFINE

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

🙋‍♂️ 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.
Image for post
Image for post
Struttura dei materiali di analisi.
Image for post
Image for post
“Shu” — Segui la regola

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.

Image for post
Image for post

3. DEVELOP

E’ il momento di produrre potenziali soluzioni.

🙋‍♂️ 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:
Image for post
Image for post
Attuale Blocco di contenuti generici
Image for post
Image for post
Attuale Blocco di griglia
Image for post
Image for post
Attuale Blocco di Azione
Image for post
Image for post
Categorizzazione dei blocchi fatta
Image for post
Image for post
Esempio di re-design dei blocchi precedenti.
Image for post
Image for post
Esempio di wireframe per “blocco di vetrina prodotti” con censimento elementi.
Image for post
Image for post
“Ha” — Vìola la regola

🙇‍♂️ 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.

Image for post
Image for post

4. DELIVER

Fase di riordino e consegna.

🙋‍♂️ 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).

“…be water my friend!”

👆 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.

Image for post
Image for post

5. DIFFUSE… & EVOLVE

Adesso è il momento di diffondere quanto fatto.

🙋‍♂️ 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.
Image for post
Image for post
“Ri” — Sii la regola

🙇‍♂️ 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.

Approfondimenti

Image for post
Image for post
Storie di design, esseri umani e interazioni.

Sharing is caring:

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

UX Tales

Storie di design, esseri umani e interazioni.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store