Per le persone, per le persone: mantenere il tuo sistema di progettazione sempreverde

Questo post è il terzo di una serie su HubSpot Canvas, il nostro nuovo linguaggio di progettazione. Leggi il primo qui e il secondo qui.

Ogni gennaio, milioni di persone decidono che questo è l'anno in cui le loro vite saranno diverse. Leggerai altri libri. Investirai di più in risparmi. Mangerete meno Doritos Cool Ranch e pinte di Ben & Jerry. E tu in palestra. Ogni. Giorno.

Ma il più delle volte, non appena febbraio arriva, c'è una pila di libri non letti sul tuo comodino. I tuoi risparmi finiranno abitualmente per finanziare l'abitudine di Taco Tuesday. E c'è un sottile strato di polvere di Dorito che copre il tuo divano.

Perché? Perché le buone intenzioni non sono sufficienti. A meno che tu non modifichi uno stile di vita, anche la risoluzione più voluta non si attaccherà.

Lo stesso vale per i sistemi di progettazione. Quando riprogetti il ​​tuo prodotto, i sistemi che hanno causato il ristagno della guida di stile del tuo prodotto (o che hanno portato il tuo team a creare 6 diversi pulsanti primari) sono probabilmente ancora disponibili. E senza un vero cambiamento nello stile di vita, probabilmente finirai proprio dove hai iniziato.

Ecco perché la parte più importante del tuo nuovo sistema di progettazione non è la tua bellissima nuova tavolozza di colori, o anche gli strumenti che hai messo in atto per rendere semplice l'utilizzo del tuo sistema di progettazione: è il modo in cui il tuo team interagisce con il sistema su base continuativa.

Non volevamo che il nostro nuovo sistema di progettazione, HubSpot Canvas, seguisse le orme delle nostre vecchie guide di stile, che finivano per diventare vecchie e ignorate. Volevamo che fosse una cosa in crescita, in cambiamento, vivente. Avevamo bisogno di un cambiamento nello stile di vita. E ci saremmo riusciti solo revisionando il nostro processo di progettazione.

Dalle persone: il tuo sistema dovrebbe essere di proprietà di tutti

Il processo a volte ottiene una cattiva reputazione. Ed è vero - il processo per il bene del processo può essere nella migliore delle ipotesi inefficiente e frustrante nella peggiore.

Ma il giusto processo rimuove l'attrito. Accelera il processo decisionale, chiarisce ruoli e responsabilità e porta tutti sulla stessa pagina. Nel capire come governare HubSpot Canvas, il nostro linguaggio di progettazione, abbiamo voluto creare un processo che raggiunga tutte queste cose. Sapevamo che se il nostro nuovo processo avrebbe avuto successo, avrebbe dovuto essere leggero e condiviso dalle persone che lo usavano ogni giorno.

Non c'è dubbio che costruire e mantenere un sistema di progettazione possa essere un lavoro a tempo pieno. Ma abbiamo scoperto che la diffusione di quel lavoro su un gruppo di designer in rotazione funziona meglio. È ovvio che i progettisti che lavorano ogni giorno sul nostro prodotto, che comprendono i nostri utenti e che sono addestrati su come dare priorità al lavoro e iterare sulle soluzioni, rendono i migliori pastori di questo processo.

Ogni 6 mesi, un gruppo di quattro designer ruota e assume ruoli e responsabilità specifici nel team di Canvas. I vantaggi sono duplici: non solo miglioreranno direttamente il sistema mentre fanno parte del team, ma avranno una profonda conoscenza di come contribuire al termine della rotazione. Il nostro obiettivo è fare in modo che ogni progettista di prodotti presso HubSpot faccia un giro di lavoro nel team di Canvas.

I designer che lavorano sul nostro linguaggio di design lo fanno in aggiunta ai loro "lavori diurni". Abbiamo trovato che funziona bene, perché ora che tutti i principali pezzi di Canvas sono stati creati, il compito di mantenere il linguaggio di design è molto meno esigente.

Tuttavia, i progettisti di questo team devono:

  • Promuovi il linguaggio di design della tela HubSpot
  • Sii esperto nella documentazione e nelle decisioni esistenti in modo da poter rispondere facilmente alle domande e identificare incoerenze
  • Continuare a identificare i modi per migliorare il processo e la documentazione
  • Aggiorna settimanalmente il kit dell'interfaccia utente di Sketch e invia un'email con i dettagli degli aggiornamenti a designer e sviluppatori front-end
  • Triage i problemi in arrivo e facilita la discussione e le decisioni nelle nostre riunioni settimanali di revisione
  • Contatta in modo proattivo i progettisti di tutto il team per aiutare a documentare casi d'uso, varianti e schemi
  • Collabora con il nostro team di Frontend-as-a-Service per rispondere alle domande e contribuire a garantire che i componenti vengano modificati o creati correttamente.

Come un disegno di legge diventa una legge

Mantenere un sistema di progettazione sempreverde richiede una stretta collaborazione tra designer e sviluppatori. Quindi, al fine di facilitare una collaborazione efficace, abbiamo deciso di costruire il nostro processo dove già stavano avvenendo le conversazioni e le decisioni sul nostro sistema di progettazione - in Github.

Questo rende Github la nostra unica fonte di verità per Canvas. Così…

  • Se un ingegnere deve sapere se un componente è stato approvato dal team di progettazione? È a Github.
  • Se un designer deve sapere se è stato ancora creato un componente? È a Github.
  • Se il team ha bisogno di discutere se un componente dovrebbe esistere affatto? Hai indovinato, lo facciamo a Github.

Passaggio 1: è necessario un nuovo componente o una modifica a un componente esistente.

Dalla nostra libreria UI, chiunque può inviare un problema Github al team per la revisione. Questi problemi riguardano il modo in cui un designer fa rotolare la palla con il team di Canvas.

Chiediamo una serie di dettagli nel numero iniziale di Github. Nel corso del tempo abbiamo appreso (e comunicato ampiamente) che le cose si muovono più agevolmente quando il mittente ha preso in considerazione i dettagli e ha utilizzato i casi per un componente in modo completo. Questo non è il posto per idee generali o miglioramenti futuri (quelle conversazioni spesso avvengono su Slack o offline tra designer) - è per un componente che è pronto per essere rivisto e costruito.

Viene quindi aggiunto alla nostra coda:

Passaggio 2: i problemi vengono risolti dal team di Canvas.

Questo processo si è evoluto nel tempo, ma il nostro obiettivo è rimasto lo stesso. Al fine di assicurarci che nulla scivoli attraverso le crepe, ci siamo resi conto che ogni problema ha bisogno di qualcuno responsabile per guidarlo attraverso questo processo.

Invece di escogitare un modello sofisticato su come dividere o distribuire uniformemente il lavoro, alla fine ci siamo ritrovati con un semplice sistema di triage volontario ogni settimana. Ci siamo accordati su questo per un paio di ragioni. Innanzitutto, alcune persone hanno solo più interesse o competenza in determinati argomenti. E in secondo luogo, i carichi di lavoro al di fuori di questa squadra fluttuano - a volte alcune persone della squadra sono occupate e altre volte no. In questo modo, il team può reagire al lavoro in modo elastico, fidandosi l'uno dell'altro per rimediare al gioco. Non è perfetto; a volte dobbiamo riassegnare i problemi o apportare piccole modifiche. Ma si adatta al nostro stile generale di lavoro su HubSpot e non ci ha ancora deluso.

Passaggio 3: i problemi passano attraverso la revisione.

Ad un livello elevato, il processo di revisione rispecchia il nostro processo di progettazione generale (ma su scala minore):

  1. Comprendi il problema
  2. Determina chi è interessato dal problema
  3. Chatta e collabora con i team interessati
  4. Crea, modifica e perfeziona il design del componente
  5. Esamina con il team di Canvas

Miriamo a che questo processo richieda una settimana, ma alcuni problemi richiedono alcuni minuti e alcuni possono richiedere settimane a seconda dell'ambito del componente e delle sue dipendenze.

Passaggio 4+: dipende.

Esistono un paio di scenari che possono venire fuori dalla revisione del componente:

  • Design per componenti con ampio utilizzo. È più sensato per il nostro team di Frontend-as-a-Service costruire e implementare questi componenti, poiché verranno utilizzati in tutto il prodotto.
  • Design per componenti con un uso più ristretto. Spesso, se è un singolo team che ha maggiormente bisogno di un componente, lo costruiranno in modo riutilizzabile, quindi lo aggiungeranno alla nostra Libreria UI.
  • Progettare per componenti che non devono essere riutilizzabili. A volte, i componenti hanno una portata così ristretta che non c'è motivo per cui un altro team avrebbe bisogno di usarli. In questo caso, il componente viene rivisto per assicurarsi che si adatti al resto del sistema, quindi il team lo costruirà nella propria app. Se in futuro dovrà diventare un componente riutilizzabile, i team potranno quindi aggiungerlo alla Libreria UI.

Se questi problemi comportano la necessità di modificare o aggiungere qualcosa nel nostro kit dell'interfaccia utente di Sketch, riceve un tag speciale con il nome della prossima versione. Questo rende più facile per i progettisti che curano il kit UI vedere tutto ciò che deve essere affrontato.

Esistono anche alcuni motivi per cui il team potrebbe rifiutare una richiesta di un componente:

  • Progettare per componenti che riteniamo non necessari. Il team includerà sempre un motivo ponderato per cui un componente non dovrebbe diventare uno standard o perché non si adatta alle nostre linee guida. Se applicabile, vengono offerte altre soluzioni o considerazioni.
  • Progettare per componenti che richiedono maggiori informazioni. A volte, i progettisti devono tornare al tavolo da disegno per capire ulteriori dettagli prima che un componente sia pronto per la prima serata.

Per le persone: il tuo sistema dovrebbe aiutarti

Volevamo che Canvas fosse così facile da usare che i nostri designer non avrebbero mai sognato di usare nient'altro. Quindi, ad esempio, invece di usare solo numeri per etichettare le versioni del nostro kit UI, abbiamo iniziato a nominare ciascuna versione in ordine alfabetico dopo rapper famosi. Non solo abbiamo ottenuto fatti divertenti e fantastiche playlist, ma ha anche reso molto più facile ricordare e parlare delle diverse versioni (non sorprende che Jam Master Jay e Kris Kross siano molto più facili da ricordare rispetto a v1, v22 o v100). Dopo aver superato l'alfabeto, abbiamo iniziato a lavorare su As Seen in TV.

Mille grazie allo spot di Hot Stamp per averci insegnato che tutto ciò che serve per stupire i tuoi amici è un po 'di glitter.

Teniamo molto alla valutazione e al miglioramento continui del nostro processo per rendere la vita più semplice a tutti i membri del team di progettazione. Alcuni esempi delle sfide che abbiamo risolto nel tempo sono:

Visibilità in ciò che sta cambiando.

All'inizio, i progettisti del team avevano difficoltà a sapere cosa stava cambiando a meno che non facessero parte del team Canvas. Quindi abbiamo iniziato a inviare e-mail ogni volta che rilasciamo un nuovo kit dell'interfaccia utente di Sketch. Queste e-mail ci aiutano ad aggiornare il team in modo chiaro e coerente su ciò che è nuovo e diverso in ogni versione e forniscono ai progettisti un luogo semplice per scaricare il nuovo kit. Ogni kit di interfaccia utente include anche un registro delle modifiche nella prima pagina del file di Sketch.

Codice corrispondente nella libreria UI per progettare risorse nel kit dell'interfaccia utente di Sketch.

All'inizio, avevamo un kit di sketch semplice che catalogava i diversi componenti di cui potremmo avere bisogno e una libreria di componenti front-end che gli sviluppatori potevano fare riferimento e utilizzare, ma non sempre si combaciavano. Questa divisione ha portato a un linguaggio discordante tra designer e sviluppatori. Quindi, al fine di coltivare la comproprietà tra designer e sviluppatori, abbiamo intrapreso un grande progetto per abbinare le convenzioni di navigazione e denominazione nella nostra Libreria UI e nel nostro Kit UI Sketch.

Pensare oltre i componenti tradizionali.

Illustrazioni, layout di pagina, stati vuoti, stati di errore: il nome. Se il riutilizzo di un oggetto crea leva, vale la pena trasformarlo in un componente o in un componente aggiuntivo. Il nostro team di Frontend-as-a-Service ha inoltre reso estremamente semplice per gli ingegneri dei team di prodotto inviare componenti o componenti aggiuntivi al sistema stesso. Abbiamo anche iniziato a documentare i pattern UX (non solo "quale componente dovrei usare?" Ma "come dovrei usarlo?").

Ma di certo non abbiamo risolto tutto. Alcune sfide che stiamo ancora cercando di risolvere e su cui stiamo iterando includono:

Assegnare e visualizzare efficacemente la priorità.

Quando abbiamo iniziato a spostare il nostro processo in Github, abbiamo fornito tag che permettevano agli utenti di scegliere la priorità della loro richiesta su una scala da P1 a P3 (un P1 significava "dobbiamo farlo ieri" e un P3 significa "arriveremo a questo un giorno”). Ma poiché il nostro team si muove così velocemente, quasi tutto è finito per essere un P1.

Inoltre, non possiamo fare tutto: dobbiamo bilanciare le priorità di oltre 40 squadre e abbiamo riscontrato alcuni problemi. Stiamo ripensando al modo in cui oggi diamo priorità ai problemi in modo da poter risolvere sia il team che costruisce i nostri componenti sia i team che li stanno aspettando.

Non avere una risorsa di progettazione dedicata.

Mentre vorremmo che tutti i designer del team facessero una rotazione, le loro responsabilità principali sono ancora dei team dei prodotti. Ciò significa che dobbiamo essere scadenti e intraprendenti quando si tratta di portare a termine il lavoro in modo tempestivo. Potremmo considerare di integrare il team di rotazione con un progettista che si concentra sul sistema a tempo pieno in futuro.

Abbiamo fiducia nel nostro sistema

Abbiamo una regola d'oro qui su HubSpot come parte del nostro Codice Cultura: usa il buon senso. Deriva da una cultura di fiducia e responsabilità verso gli altri. Abbiamo costruito i nostri principi, linee guida e processi su una base di fiducia per garantire che il nostro sistema di progettazione duri, perché un sistema funziona solo se le persone si fidano di esso.

Abbiamo creato quella fiducia rendendo facile capire come vengono prese le decisioni e come contribuire se qualcuno vuole aiutare o non è d'accordo con una decisione. Raccogliamo periodicamente feedback e pianifichiamo di affrontare i miglioramenti. Troviamo modi per le persone che ci tengono o lo usano molto per essere coinvolti. E documentiamo il più possibile sul perché sono state prese le decisioni in modo che chiunque possa vederle e fare riferimento a esse.

Alla fine, rendere il mantenimento del nostro linguaggio di progettazione un gioco da ragazzi non era solo un bene per i nostri progettisti e sviluppatori, ma anche per i nostri utenti. La riprogettazione del nostro prodotto con Canvas è stata un grande cambiamento, ma il nostro obiettivo era quello di costruire un sistema e un processo così forti da non dover più riprogettare il nostro prodotto.

Con le basi che abbiamo creato con questo intero sistema, abbiamo la possibilità di apportare piccole modifiche nel tempo al nostro prodotto. Nuovo colore primario? Fatto. Gli angoli arrotondati non sono più belli? Andato. Gli utenti hanno difficoltà a capire come procedere in un flusso di procedura guidata? Cercheremo e ripareremo senza un intero controllo dell'interfaccia utente in tutta l'app.

Creando un forte sistema di progettazione e un forte processo per supportarlo, possiamo sostenere un processo ponderato di evoluzione del prodotto, senza l'onere della rivoluzione all'ingrosso. È un sistema che funziona.

Crediti:
Illustrazioni di Sue Yee.

Originariamente pubblicato sul blog del prodotto HubSpot.