I sistemi di progettazione riguardano le relazioni

I sistemi di progettazione possono essere incredibilmente utili. Forniscono elementi e linee guida riutilizzabili per creare un "look and feel" coerente tra i prodotti. Di conseguenza, gli utenti possono prendere ciò che hanno imparato da un prodotto e applicarlo a un altro. Allo stesso modo, i team possono implementare modelli ben testati per la navigazione o le recensioni, rendendo i prodotti più affidabili. Sistemi di progettazione efficaci risolvono problemi noiosi in modo ripetibile in modo che sviluppatori e designer possano concentrarsi sulla risoluzione di problemi nuovi.

Tuttavia, quando qualcuno usa il termine "sistema di progettazione" in una riunione, non sono mai sicuro di quale reazione aspettarmi. Ho visto curiosità ed entusiasmo nel provare un nuovo modo di lavorare, ma ho anche visto frustrazione e preoccupazione per l'idea di un sistema che limita la creatività dei designer. Alcuni designer sostengono che i sistemi di progettazione indeboliscono la creatività o che siano soluzioni alla ricerca di un problema. I sistemi di progettazione possono frammentarsi nel tempo, facendo sì che i team smettano di usarli.

Tuttavia, i sistemi di progettazione non stanno scomparendo. Solo il 15% delle organizzazioni non disponeva di un sistema di progettazione nel 2018, secondo un sondaggio. Questo è in calo rispetto al 28% dell'anno precedente. Alcuni team utilizzano sistemi di progettazione di grandi dimensioni e generici come Material Design di Google, mentre altri utilizzano sistemi più piccoli e personalizzati come Cedar di REI e Protocollo di Mozilla.

I sistemi di progettazione dovrebbero potenziare i team, non limitarli. Perché ciò accada, dobbiamo iniziare a pensare in modo più olistico. Un sistema di progettazione non è solo codice, progetti o documentazione. Sono tutte queste cose, oltre alle relazioni tra le persone che creano il sistema e le persone che lo usano. Include non solo file CSS e documenti Sketch, ma anche fiducia, comunicazione e proprietà condivisa. A quanto pare, c'è un intero campo di studio dedicato all'esplorazione di sistemi come questi.

La grande immagine

Un articolo del 1960 intitolato "Sistemi socio-tecnici" ha esplorato le interazioni tra tecnologia, esseri umani e l'ambiente più ampio in cui esistono. Enid Mumford ha spiegato che i ricercatori hanno iniziato studiando come costruire relazioni migliori tra manager e dipendenti, ma negli anni '80 si sono concentrati sul rendere il lavoro più efficiente ed economico. Nel 2011, Gordon Baxter e Ian Sommerville hanno scritto che questa ricerca ha contribuito a ispirare il design incentrato sull'utente e che c'è ancora molto lavoro da fare.

Baxter e Sommerville hanno sostenuto che oggi c'è ancora una tensione tra la ricerca "umanistica", che si concentra sulla qualità della vita dei dipendenti, e la ricerca "manageriale", che si concentra sulla loro produttività. Hanno anche spiegato che è importante considerare sia la tecnologia che le interazioni umane: "le prestazioni del sistema si basano sull'ottimizzazione congiunta dei sottosistemi tecnici e sociali".

Direi che i sistemi di progettazione sono sistemi socio-tecnici. Implicano le interazioni tra le persone che creano il sistema, le persone che creano prodotti utilizzando il sistema e gli utenti finali che interagiscono con questi prodotti. Evocano anche la stessa tensione tra efficienza e umanesimo che videro Baxter e Sommerville.

I sistemi di progettazione non sono composti solo da immagini e codice; coinvolgono conversazioni tra designer, sviluppatori, product manager, CEO e persone casuali su GitHub. Queste interazioni si verificano in vari contesti - un'azienda, una comunità open source, una casa - e si verificano attraverso culture e confini organizzativi. Costruire un team può significare riunire persone provenienti da discipline come l'animazione, il sound design, la visualizzazione dei dati, l'aptica e il copywriting. La creazione di un sistema di progettazione di successo richiede parti uguali di competenza tecnica e competenze trasversali.

Eppure, sfoglia gli aggregatori di notizie di design o ingegneria e probabilmente vedrai un focus distinto su quel "sottosistema tecnico": codice e strumenti, piuttosto che persone e conversazioni. Quale strumento creativo è il migliore per tenere traccia dei token di progettazione? Quali tecnologie JavaScript dovrebbero essere utilizzate per creare componenti riutilizzabili: React, componenti Web o qualcos'altro? Quale strumento di costruzione è il migliore?

La risposta a queste domande è, ovviamente, "dipende!" Chi progetterà, costruirà e utilizzerà il sistema? Quali sono i loro bisogni? Con quali vincoli operano? Con quali strumenti e tecnologie si sentono a proprio agio? Cosa vogliono imparare?

Per rispondere a questo tipo di domande, Baxter e Sommerville consigliano due tipi di attività:

• Attività di sensibilizzazione e sensibilizzazione
  Conoscere le varie persone che creeranno e parteciperanno al sistema e condivideranno tali informazioni in lungo e in largo.
• Impegno costruttivo
  Comunicare tra ruoli, costruire prototipi e considerare sia le parti tecniche che sociali del sistema.

Scavare

All'inizio del 2019, facevo parte di un team - chiamiamolo "team blue" - che stava costruendo un sistema di progettazione per una grande organizzazione. Ho facilitato le chat informali con questo team e il "team green", che utilizzava il sistema di progettazione per creare un'applicazione web. Ogni due settimane riunivamo tutti gli sviluppatori e i designer attorno a un tavolo e parlavamo di ciò che stavamo costruendo e di quali problemi stavamo cercando di risolvere. Queste chat erano le nostre "attività di sensibilizzazione e sensibilizzazione".

Non avevamo il permesso di rendere pubblico il nostro sistema di progettazione, quindi abbiamo fatto la cosa migliore successiva: l'abbiamo trattato come un piccolo progetto open source all'interno dell'organizzazione. Abbiamo inserito il codice in un repository a cui entrambi i team potrebbero accedere e abbiamo chiesto contributi. Il Team Blue era responsabile della revisione e dell'approvazione di questi contributi, ma chiunque in una delle due squadre poteva contribuire. Il Team Blue stava anche costruendo una propria applicazione, quindi in un certo senso erano sia utenti che custodi del sistema di progettazione.

Queste interazioni hanno aiutato i team a creare prodotti migliori, ma altrettanto importante hanno stabilito la fiducia tra i team. Il Team Blue ha appreso che le persone stavano usando il sistema in modo ponderato e ci stavano costruendo nuove idee intelligenti. Il Team Green ha appreso che il sistema era davvero su misura per le loro esigenze, quindi potevano lavorare con esso invece che contro di esso. Baxter e Sommerville potrebbero chiamare questo lavoro "impegno costruttivo".

Abbiamo scoperto che entrambi i team erano sotto pressione per apprendere nuove tecnologie e fornire rapidamente un prodotto completo. In altre parole, stavano già operando con un carico cognitivo piuttosto considerevole. Di conseguenza, i due team hanno deciso di concentrarsi sul rendere il sistema facile da usare. Ciò significava eludere l'intero dibattito sui componenti web, concentrandosi principalmente sui CSS e assicurando che la nostra documentazione fosse chiara e amichevole.

Mettere tutto insieme

Le organizzazioni di tutte le dimensioni creano elementi di design riutilizzabili per aiutare i team a creare applicazioni più coerenti ed eleganti. Le diverse esigenze e dinamiche delle organizzazioni sono espresse nei loro sistemi di progettazione. Ecco solo alcuni esempi:

• Il Material Design di Google ha diverse implementazioni in diversi framework e linguaggi. È utilizzato da una varietà di persone all'interno e all'esterno di Google, quindi ha una documentazione completa e una varietà di toolkit per le app di progettazione.
• Il Fluent Design System di Microsoft si rivolge a quattro piattaforme molto diverse. Come Material, include toolkit per UX designer e documentazione completa.
• Il protocollo di Mozilla è implementato in JavaScript Sass e vanilla. Ha una forte attenzione all'internazionalizzazione. Alex Gibson afferma che questo sistema aiuta Mozilla a "creare pagine Web on-brand a un ritmo più rapido con un lavoro manuale meno ripetitivo".
• Cedar di REI è costruito con componenti Vue.js e non può essere utilizzato con altri framework JavaScript. Il cedro è utilizzato principalmente dagli sviluppatori interni di REI ed è strettamente legato al marchio dell'azienda. Il codice del sistema di progettazione è open source, ma i suoi caratteri non lo sono.
• Lightning Design System di Salesforce è un framework CSS indipendente da JavaScript. Può essere opzionalmente utilizzato insieme a Lightning Component Framework, che include due implementazioni JavaScript: una che utilizza componenti Web e un'altra che utilizza il framework Aura proprietario di Salesforce.
• PatternFly di Red Hat è stato creato per fornire un'esperienza utente coerente tra i prodotti della piattaforma cloud dell'azienda, quindi ha una densità di informazioni relativamente elevata e include una varietà di componenti di visualizzazione dei dati. Il team di PatternFly è recentemente passato da Angular a React dopo alcune sperimentazioni con componenti web. PatternFly include anche un'implementazione indipendente da JavaScript utilizzando HTML e CSS. (Divulgazione completa: sono un ex Cappellaio Rosso.)
• Il Carbon Design System di IBM offre implementazioni in JavaScript React, Vue, Angular e vanilla, nonché un toolkit di progettazione per Sketch. Il team di Carbon sta sperimentando componenti web. (Consiglio di cappello a Jonathan Speek per aver rintracciato quel repository.)

Sistemi come questi sono coerenti e affidabili perché persone di diversi team e ruoli hanno lavorato insieme per costruirli. Questi sistemi risolvono problemi reali. Non sono il risultato di sviluppatori che cercano di imporre la loro volontà ai designer o viceversa.

Josh Mateo e Brendon Manwaring spiegano che i designer di Spotify "vedono il loro ruolo di contributori principali e coautori di un sistema condiviso , di cui hanno la proprietà". Mina Markham si descrive come "la traduttrice tra ingegneria e design" sul sistema di design dei tailleur. Jina Anne approfondisce le dinamiche del team e la ricerca degli utenti dietro i sistemi di progettazione: “Allarme spoiler! Avrai bisogno di qualcosa di più di semplici designer".

Costruiamo un po' di roba!

Ora che abbiamo esaminato la ricerca e alcuni esempi, parliamo di come costruire un nuovo sistema di progettazione. Inizia parlando con le persone. Scopri chi utilizzerà e contribuirà al tuo sistema di progettazione. Queste persone probabilmente abbracciano una varietà di discipline: design, sviluppo, gestione del prodotto, affari e simili. Scopri i bisogni e gli obiettivi delle persone e chiedi loro di condividere ciò su cui stanno lavorando. Prendi in considerazione la pianificazione di un incontro informale con snack, caffè o tè per creare un'atmosfera accogliente. Stabilisci una comunicazione regolare con queste persone. Ciò potrebbe significare entrare in una chat room condivisa o pianificare riunioni regolari. Mantieni il tono informale e amichevole e concentrati sull'ascolto.

Mentre parli di ciò su cui stai lavorando, cerca problemi e obiettivi comuni. Potresti scoprire che i team devono visualizzare grandi quantità di dati, quindi stanno esaminando strumenti per visualizzare tabelle e generare report. Dai priorità alle soluzioni per questi problemi.

Cerca anche schemi ripetuti e variazioni su temi simili. Potresti scoprire che i pulsanti e i moduli di accesso hanno un aspetto leggermente diverso tra i team. Qual è il significato di queste variazioni? Quali variazioni sono intenzionali, ad esempio un pulsante principale rispetto a un pulsante secondario, e quali variazioni sono avvenute per caso? Il tuo sistema di progettazione può nominare e catalogare i modelli e le variazioni intenzionali e può eliminare le variazioni "accidentali".

L'obiettivo qui è stabilire un rapido ciclo di feedback con le persone che utilizzano il sistema di progettazione. Un feedback più rapido e iterazioni più piccole possono aiutare a evitare di andare troppo lontano nella direzione sbagliata e di dover cambiare radicalmente rotta. PJ Onori chiama questi grandi cambiamenti improvvisi "thrash". Dice che un po' di thrash è buono – è un segno che stai imparando e reagendo al cambiamento – ma che troppo può essere dirompente. “Non dovresti temere il thrash”, dice, “ma devi sapere quando è utile e come mitigare i suoi aspetti negativi. Uno dei modi migliori per mitigare gli aspetti negativi del thrash è iniziare in piccolo, con tutto .

Considera di iniziare in piccolo impostando alcuni elementi di base:

• Un sistema di controllo della versione per memorizzare il codice. GitHub, GitLab e Bitbucket sono tutte ottime opzioni qui. Assicurati che tutti coloro che utilizzano il sistema possano accedere al codice e proporre modifiche. Se possibile, considera di rendere il codice open source per raggiungere il pubblico più ampio possibile.
• Codice CSS per implementare il sistema. Usa le variabili Sass o le proprietà personalizzate CSS per memorizzare i "design token", valori comuni come larghezze e colori.
• Un file package.json che definisce come le applicazioni possono creare e installare il sistema di progettazione.
• Documentazione HTML che dimostra come utilizzare il sistema di progettazione, idealmente utilizzando il CSS del sistema.

La documentazione node-sass per il framework CSS Bulma descrive questi passaggi in modo un po' più dettagliato. Puoi saltare l'installazione e l'importazione di Bulma se desideri iniziare da zero, oppure puoi includerlo se desideri iniziare con alcune delle basi in atto.

Potresti aver notato che non ho menzionato nulla su JavaScript qui. Potresti voler aggiungere questo elemento alla fine, ma non ne hai bisogno per iniziare. È facile andare in una tana del coniglio alla ricerca degli strumenti JavaScript migliori e più recenti e perdersi in questa ricerca può rendere più difficile iniziare. Ad esempio, "5 motivi per cui i componenti Web sono perfetti per i sistemi di progettazione" e "Perché non uso i componenti Web" sono entrambi punti validi, ma solo tu puoi decidere quali strumenti sono adatti al tuo sistema. Iniziare con solo CSS e HTML ti consente di raccogliere feedback dal mondo reale che ti aiuteranno a prendere questa decisione quando sarà il momento.

Quando rilasci nuove versioni del sistema, aggiorna il numero di versione del tuo sistema per indicare cosa è cambiato. Usa il controllo delle versioni semantico per indicare cosa è cambiato con un numero come "1.4.0". Incrementa l'ultimo numero per le correzioni di bug, il numero medio per le nuove funzionalità e il primo numero per modifiche grandi e dirompenti. Continua a comunicare con le persone che utilizzano il sistema di progettazione, invita feedback e contributi e apporta piccoli miglioramenti man mano che procedi. Questo modo di lavorare collaborativo e iterativo può aiutare a ridurre al minimo il "thrash" e stabilire un senso di proprietà condivisa.

Infine, considera la pubblicazione del tuo sistema di progettazione come pacchetto su npm in modo che gli sviluppatori possano usarlo eseguendo il comando npm install your-design-system . Per impostazione predefinita, i pacchetti npm sono pubblici, ma puoi anche pubblicare un pacchetto privato, pubblicare il pacchetto in un registro privato o chiedere agli sviluppatori di installare il pacchetto direttamente da un sistema di controllo della versione. L'utilizzo di un repository di pacchetti renderà più semplice rilevare e installare gli aggiornamenti, ma l'installazione diretta dal controllo della versione può essere una soluzione semplice a breve termine per aiutare i team a iniziare.

Se sei interessato a saperne di più sul lato ingegneristico delle cose, Building Your Design System di Katie Sylor-Miller offre un fantastico approfondimento. (Divulgazione completa: ho lavorato con Katie.)

Avvolgendo

I sistemi di progettazione sono costituiti da codice, progetti e documentazione, nonché da relazioni, comunicazione e fiducia reciproca. In altre parole, sono sistemi socio-tecnici. Per costruire un sistema di progettazione, non iniziare scrivendo codice e scegliendo strumenti; inizia parlando con le persone che utilizzeranno il sistema. Scopri i loro bisogni e vincoli e aiutali a risolvere i problemi. Quando prendi decisioni tecniche, di design o strategiche, considera le esigenze di queste persone rispetto al modo teoricamente "migliore" di fare le cose. Inizia in piccolo, itera e comunica mentre procedi. Mantieni il tuo sistema il più semplice possibile per ridurre al minimo il thrash e invita feedback e contributi per stabilire un senso di proprietà condivisa.

Dando uguale peso alle considerazioni ingegneristiche e interpersonali, possiamo ottenere i vantaggi dei sistemi di progettazione evitando le insidie. Possiamo lavorare in modo efficiente e umano; non dobbiamo scegliere uno sull'altro. Possiamo potenziare i team piuttosto che limitarli. I team potenziati alla fine ci aiutano a servire meglio i nostri utenti, che, dopo tutto, è il motivo per cui siamo qui in primo luogo.

Ulteriori letture su SmashingMag:

• Suggerimenti per la gestione dei sistemi di progettazione
• Includere l'animazione nel tuo sistema di progettazione
• Oltre gli strumenti: come costruire un sistema di progettazione può migliorare il tuo modo di lavorare
• Costruire un sistema di progettazione su larga scala per il governo degli Stati Uniti (caso di studio)