Design Systems Workshop con Alla Kholmatova
Qualche giorno fa ho avuto la fortuna di partecipare a Bologna al workshop di Alla Kholmatova basato sul libro “Design Systems”.
Visto l’argomento “caldissimo” per ogni progettista che si occupa di www, mi ero procurato il libro alla fine dello scorso anno, ma ammetto di averlo solo sfogliato superficialmente prima di questo workshop, che dico subito, ha per me superato le aspettative e invogliato a leggermi d’un fiato il libro.
Innanzitutto è d’obbligo ringraziare Ideato ed Extrategy per aver fatto accadere tutto questo. L’organizzazione, la partecipazione, e l’ambiente sono stati neanche a dirlo favolosi. Spero davvero non rimanga un evento isolato.
Eravamo tutti a nostro agio, ottima l’idea di assegnare i tavoli di lavoro in maniera preventiva, cosa che mi ha permesso di conoscere tante nuove fantastiche persone, come Giulia, Francesco, Miluska, Antonio e Beatrice che sono stati dei “colleghi per un giorno” strepitosi.
Adesso arriviamo ad Alla e al workshop…
E’ subito amore! ❤️
La disponibilità e la professionalità di Alla valeva da solo il workshop.
Alla è stata in ogni sessione di lavoro sempre presente ai tavoli, disponibile a qualsiasi richiesta, e duttile nel prendere appunti ed adattare la parte di spiegazione successiva sulla base delle domande emerse.
Se voleste approfondire potete dare un occhio alle sue presentazioni sul suo profilo di SpeakerDeck.
A cosa serve e cos’è un Design System?
Lo scopo di creare un Design System è quello di essere efficienti nella progettazione e scalabilità di interfacce, di qualità e coerenti nel loro ambiente.
La definizione di Design System ha dei bordi molto sfumati, ma al momento possiamo definirlo come: una raccolta interconnessa di PATTERN e buone PRATICHE coerentemente organizzate a raggiungere lo scopo di un prodotto digitale.
Alcuni esempi:
- Bootstrap ad esempio non è un DS, ma un framework che chiunque può utilizzare nella maniera che ritiene opportuna.
- Material Design invece è in buona parte un DS perché riporta anche delle buone pratiche da tenere nell’utilizzo di quel framework.
- Solar (il DS curato da Alla per Bulb UK) è in pieno un DS perché affronta sia pattern che buone pratiche, coordinate al raggiungimento della proposta del prodotto digitale.
Pattern e Pratiche
Pattern
Blocchi ripetibili e riusabili di un’interfaccia.
Proprio come dei mattoncini Lego possiamo usarli per costruire una soluzione ad un problema di progettazione. In genere un comportamento dell’utente, le sue azioni, scatenano l’utilizzo di un pattern.
Ad esempio: un modulo e un pulsante possono essere la soluzione all’invio di un feedback all’interno di un’interfaccia.
Pratiche
Approcci condivisi, tecniche e processi che il team applica per disegnare e costruire interfacce.
Ad esempio: qual’è la nomenclatura che all’interno del team usiamo per riferirci ai singoli elementi (“titolo”, “header”, o “scritta grande”?), oppure come decidiamo di organizzare i file di consegna, etc.
Stili
Argomento a sé è trattato nel censimento e organizzazione dello stile: l’aspetto estetico che viene percepito dall’utente che naviga una certa interfaccia. Questi “pattern estetici” riguardano colori, tipografia, animazioni, spaziature, icone, forme, layout, ma anche microcopy, e servono a trasmettere l’identità del prodotto a prescindere dalla funzionalità.
In pratica è il “feeling di prodotto” che sentiamo quando navighiamo una certa interfaccia. Quando sono in una schermata e riconosco immediatamente di essere “in casa” di quel prodotto.
All’interno del nostro Design System è bene rendere chiaro ed argomentare questo sentimento anche con esempi, in maniera che qualunque evoluzione possa comunque basarsi su quello spirito condiviso.
Durante il workshop sono stati fatti diversi esempi in cui questo feeling ha fatto la differenza a parità di funzioni.
Un esempio su tutti il prevalere di Slack su HipChat.
Princìpi
La definizione dei princìpi all’interno di un Design System è considerato come un aspetto prioritario in quanto dovrebbe essere una sorta di stella polare per tutta la stesura. La definizione dei princìpi progettuali è spesso abbinata alla creazione di un manifesto che specifichi l’indole e il carattere che anima il team per il raggiungimento degli obiettivi.
Potremmo quasi assimilarlo al concetto di “missione” del team di design.
Alcuni esempi sono quelli di:
- Trello: “Visual and Tactile”
- Citymapper: “Design for humans”
- Medium: “Direction over choice”
- GOV.uk: “This is for everyone”
Si consiglia un massimo 3-5 parole per il nostro motto che portino a renderlo:
- Genuino (che si sposi bene anche con la filosofia del nostro prodotto)
- Categorico (renderlo concreto e non troppo vago, usare quindi un pensiero pratico e non solamente filosofico o idealista)
- Indimenticabile (qualcosa che se lo chiedessi a qualsiasi membro del team non si sforzi a pensarci su, ma gli venga spontaneo tanto è memorizzabile)
Categorizzare e dare nome ai pattern
E’ una delle parti operative da fare con l’attuale interfaccia in maniera da sviscerarla e capire con cosa avremo a che fare nella formulazione del nostro Design System.
1. Trovare le azioni chiave
Raccogliere quali siano tutte le operazioni che si possano fare all’interno dell’interfaccia.
Ad esempio: all’interno di una piattaforma bibliotecaria raccogliamo azioni chiave come “scoprire libri di cui potrei essere interessato”, “trovare un libro specifico”, “gestire liste di libri”, etc…
2. Abbinare azioni ai relativi pattern
Individuare quali siano i pattern coinvolti in quelle azioni chiave.
Ad esempio: per l’azione “trovare un libro specifico” ci sarà l’input e il pulsante di ricerca, la presentazione della lista, l’oggetto libro come voce della lista, etc…
3. Censire gli elementi esistenti
Raccogliere tutti gli elementi presenti nei pattern sopra, stando attenti di raccoglierli per scopo e non estetica.
Ad esempio: raccoglierò tutti i pulsanti a prescindere che siano a forma di bottone, a forma di link, o solo icona. Hanno tutti il solito scopo di confermare ed inviare dati in elaborazione.
4. Definire e dare un nome ai pattern
Questo argomento credo debba approfondirlo meglio, ma per adesso quello che ho capito è che si debba “nomenclare” i nostri pattern con molta attenzione a renderli unici e soprattutto comprensibili anche agli altri team. Il rischio è che non vengano facilmente adottati.
Ad esempio: il pulsante principale di un’interfaccia sarà facile chiamarlo “Primary button”, ma creare un pulsante meno evidente “Secondary button”potrebbe portare ad incomprensioni. Secondario a cosa?
Ci possono essere ad esempio schermate che hanno solo pulsanti secondari, quindi non sarebbero più secondari a nessuno. O se chiamassimo “Header1” il titolo principale di una pagina, magari sarebbe perfettamente comprensibile per il front-end, ma altri reparti magari hanno sempre chiamato quella scritta come “Titolo pagina”.
Questo non significa accontentare tutti o non definire una guida al riguardo, ma sicuramente stare molto accorti nella definizione della nomenclatura.
5. Testare sull’interfaccia
Facile da capire: avere campo libero in un “playground” di interfaccia (ad esempio su Sketch, Figma, o altro tool) in maniera da testare modifiche, evoluzioni, e mantenere versioning delle prove fatte.
Costruire
Adesso abbiamo tutto quello che ci serve per partire con la costruzione vera e propria del nostro Design System.
Avere ben in testa i principi della nostra progettazione, per ogni azione prendere i pattern censiti (di cui adesso abbiamo la raccolta di dove e come è usato, e del giusta nomenclatura) provando ad evolverli, costruire blocchi di interfaccia e testare.
Avanti tutta! :)
Buone Pratiche
Non mancano consigli sulle buone pratiche da tenere durante tutto il processo da parte del team di design, in maniera da essere il più efficienti ed efficaci possibile. Ad esempio:
- Saper riconoscere e definire un pattern
La nomenclatura assegnata è importante, deve essere chiara per tutti e in caso ce ne fosse bisogno creare un glossario. - Documentare (sempre) e organizzare
Ogni pattern deve essere documentato e incasellato: come si chiama? dove è applicabile? Gerarchicamente dove sta? Un esempio? Codice? - Condividere e gestire le modifiche
Revisione e controllo continuo. Ascoltare i feedback di altri team, essere aperti, evolvere e correggere se necessario. - Incrementare l’adozione dai reparti
Ovviamente condividere e “far circolare” in altri reparti, stabilire delle metriche di adozione ed aumentare così per tutti i principi di progettazione. - Mantenere sincronizzazione tra design e codice
Se possibile legarsi a doppio filo al codice generato da quel pattern, in maniera da agevolare il reparto sviluppo, e non dare adito a modifiche o interpretazioni. - Versioning e Release
Major, Minor, Patch anche in questo contesto in maniera da essere sincronizzati su aggiornamenti.
In conclusione
Fare Design System NON significa generare un documento di Styleguide, e nemmeno realizzare una lista dei pattern usati all’interno dell’interfaccia.
Nella mia modesta opinione, per quello che ho compreso in questo workshop, si tratta di un “processo” in cui tutti i reparti all’interno dell’azienda (o di un prodotto) si sincronizzano su un linguaggio comune di progettazione.
Lo scopo del team di design è quello quindi di agevolare, grazie alla stesura (e continuo aggiornamento) di un compendio di “buone pratiche” funzionali ed estetiche, la diffusione della cultura e identità aziendale all’interno di tutti i reparti, al fine di averne un’esposizione consistente e sempre riconoscibile.
…e in pratica:
Da qualche mese all’interno di una grande azienda con la quale sto collaborando stabilmente, sto vivendo sulla mia pelle cosa significhi passare da Styleguide a Design System.
Ammetto che dopo l’eccitazione iniziale di dover portare avanti un lavoro così appagante ed esteso, le fasi immediatamente successive sono state:
- sgomento del “da dove cominciamo adesso?”
- smania nel cercare di copiare in maniera pedissequa da DS di riferimento come Carbon, Polaris (❤️), Atlassian Design, e altri.
- euforia del giungere subito a conclusioni aprendo Sketch e ridisegnare alcuni blocchi di interfaccia sulla base degli ultimi trend (mettendo gradienti ovunque).
Ecco. Se anche a voi è successa la solita cosa, è proprio in quella fase che il libro e la testimonianza di Alla farebbe bene!
Inaspettatamente quello che ho imparato da questo workshop, e dal libro di Alla, non è tanto il METODO ma le BASI e LO SCOPO che io (sbagliando) davo per scontati.
Mi spiego meglio. Mi aspettavo un workshop che pescasse molto dall’Atomic Design di Brad Frost, perché è ovvio che ci debba essere metodo in un processo di Design System, e le procedure spiegate di Alla sono utili, precise ed efficaci.
Ma quello che mi ha piacevolmente “scombussolato” è che fino a quel momento io mi concentrassi sostanzialmente sull’esecuzione (avevo fatto miriadi di benchmark, cominciato a fare ennesime styleguide, copiavo strutture da altri DS), saltando tutto quello che sta a monte:
- perché in questa azienda è nata l’esigenza di un Design System?
- quali sono i principi di progettazione dell’azienda? Sono condivisi?
- nelle interfacce attuali ho mai analizzato gli elementi per estetica e per funzionalità?
- i miei colleghi come chiamano questi elementi?
- una volta creato cosa mi aspetto che succeda?
E così via…
Insomma è un processo che guarda e indaga molto dentro il progetto digitale (e l’azienda) per cui si agisce.
Non è possibile copiare as-is o prendere troppo spunto un DS che ci convince, dato che alla base ci sono dei principi e dei pattern che saranno differenti di caso in caso, e che nascono necessariamente all’interno di quel prodotto.
Un percorso unico, che richiede tempo, che deve essere affrontato con apertura e mai da soli.
E’ ovvio dire che fare formazione sia indispensabile per chi faccia il nostro lavoro, ma non è altrettanto ovvio che meriti essere costanti nel praticarla.
Ci apre maggiormente al confronto, abbatte pregiudizi lavorativi e cattive pratiche, e soprattutto ci permette di venire in contatto con persone straordinarie.
Se avete voglia di proseguire le chiacchiere su questo argomento passate a trovarci in Officina 31. Vi aspettiamo per un caffé. 🙌
Articolo scritto da Riccardo.
