Colmare il divario tra design e codice

"Design & Code" è una serie di esperimenti, processi e apprendimenti di progettazione e ingegneria offerti dal team di AirSwap.

In AirSwap abbiamo un approccio asincrono e iterativo allo sviluppo del prodotto. Tuttavia, una delle prime sfide che abbiamo incontrato è stata quella di mantenere un'identità coerente del prodotto attraverso iterazioni di funzionalità, attraverso più proprietari di prodotti. Lavorando sulle prime versioni di AirSwap Token Trader e AirSwap Widget, abbiamo rapidamente accumulato una manciata di file Sketch: ogni file conteneva un sacco di simboli e stili che rappresentavano lo stato della nostra identità di prodotto in quel momento. Anche se all'inizio ha funzionato, la nostra mancanza di una consolidata fonte di verità è cresciuta rapidamente in un caos di stili obsoleti su più fonti.

Con più file e simboli sparsi su tutti, è diventata una seccatura gestire un'identità coerente.

Ogni esperienza di frontend su AirSwap è scritta in React. All'inizio avevamo una directory di componenti condivisi, una libreria di componenti preliminari, se lo desideri, con gli stili appropriati che corrispondevano all'identità del prodotto. Tuttavia, mentre ripetevamo, la nostra identità di prodotto è cambiata. Fare riferimento alle composizioni di progettazione per le nuove funzionalità ha reso più difficile identificare se un particolare componente esisteva già o doveva essere implementato. Abbiamo preso una decisione iniziale di utilizzare componenti con stile, che ci ha permesso di iterare e creare rapidamente funzionalità. La facilità d'uso fornita con i componenti di stile è stata una grande vittoria, ma ci ha anche permesso involontariamente di prendere alcune decisioni sbagliate in termini di estensione degli stili. Senza regole rigide su come creare o estendere i componenti, la nostra base di codice è diventata rapidamente sede di molti codici duplicati con solo lievi differenze. Ciò non solo ha ridotto la velocità degli sviluppatori e ha aumentato il debito tecnologico, ma ha anche introdotto un'incoerenza nella nostra identità di prodotto.

A causa dell'assenza di un sistema ben definito nelle composizioni di progettazione, molti file nella nostra base di codice introdurrebbero nuovi componenti simili a quelli esistenti o apporterebbero piccole modifiche ai componenti esistenti.

Nella nostra ricerca di una soluzione a questi problemi, abbiamo recentemente iniziato a sperimentare come colmare il divario tra design e codice.

Disegno tecnologico

L'idea della tecnologia del design non è una novità. Esistono strumenti come Craft e Invision per aiutare i designer a consolidare i propri stili e collegare tali informazioni agli sviluppatori. Ciò consente a più parti interessate di lavorare su diverse funzionalità mantenendo un insieme consolidato di componenti di base o una libreria di componenti condivisa. Tuttavia, ciò di cui avevamo bisogno era un modo non solo di mantenere la parità tra i progetti, ma anche di mantenere la parità tra i componenti che costituiscono un progetto e ciò che esiste nel codice.

Circa un anno fa, il team della tecnologia di progettazione di Airbnb ha rilasciato un progetto open source chiamato reazioni-sketchapp, che ha permesso ai componenti di React di essere trasformati in Sketch. La comunità React ha risposto favorevolmente, e ben presto, i componenti in stile hanno rilasciato un'estensione della loro libreria, in stile componenti / primitivi, con supporto per il rendering multi-target (incluso il rendering in Sketch). Questi progetti sono diventati soluzioni tecniche di base ai problemi di incoerenza che stavamo affrontando.

Libreria dei componenti AirSwap

Dopo un controllo approfondito del widget AirSwap, abbiamo identificato e ricreato in Sketch l'insieme di componenti che dovevano essere utilizzati in tutte le funzionalità presenti e future. Abbiamo quindi dedicato del tempo a ricreare l'intera libreria di componenti in React, utilizzando come base le componenti / primitive in stile. I nostri componenti sono stati resi come simboli attraverso reagire-sketchapp, creando un'unica fonte di verità per i nostri progetti.

Reagisci componenti resi a Sketch

La creazione della libreria dei componenti è diventata la base del nostro processo preliminare di progettazione end-to-end in AirSwap. I progetti per i componenti sono arrivati ​​per primi, seguiti dall'implementazione. Dato che stavamo usando componenti con stile e reazioni-sketchapp, potremmo riportare il codice implementato in Sketch per la revisione. Dopo l'approvazione, i componenti renderizzati diventerebbero i nuovi progetti, pronti per la revisione futura, se necessario.

Versioni multiple della libreria dei componenti, renderizzate in Sketch e caricate in Figma

Inserisci Figma

Questo ciclo elimina la disparità tra codice e design. Tuttavia, abbiamo rapidamente scoperto i vantaggi aggiuntivi di questa soluzione quando abbiamo iniziato a svolgere la maggior parte del nostro lavoro di progettazione su Figma. Poiché i nostri strumenti di progettazione ci consentono di creare documenti Sketch dalla nostra libreria di componenti, carichiamo ogni nuova revisione su Figma. Commenti e richieste di modifiche possono essere fatti in modo interattivo sull'ultima revisione, che fornisce le specifiche per la revisione successiva, da caricare solo quando vengono indirizzati tutti i commenti precedenti. Questo non è perfettamente fluido (ancora), ma crea un processo di revisione dell'interfaccia utente che è informativamente simile alle richieste pull di GitHub.

Utilizzando la nostra nuova libreria di componenti per creare simulazioni per il nuovo trading OTC conversazionale di AirSwap

Inoltre, utilizzando le funzionalità di libreria condivisa di Figma, possiamo quindi fornire accesso a questi componenti attraverso tutti i nostri componenti di progettazione. Come ingegneri, possiamo, in tempo reale, visualizzare e modificare in modo collaborativo queste composizioni, il che fornisce una chiara indicazione su quale componente viene utilizzato. Questo elimina completamente qualsiasi ipotesi sull'esistenza o meno di un componente, poiché il nome del componente viene visualizzato su Figma.

Il nome del componente viene visualizzato in Figma, che fornisce immediatamente informazioni agli sviluppatori che visualizzano le simulazioni

Qual'è il prossimo

Andando avanti, intendiamo migliorare e modificare questo processo per adattarlo più facilmente al nostro lavoro di sviluppo del prodotto. Sono ancora necessari diversi passaggi manuali e inefficienti.

Per uno, Figma non fornisce attualmente un'API in grado di scrivere per i documenti, che richiede di caricare manualmente i file di Sketch generati. Con un adeguato supporto API, possiamo facilmente integrare questo processo end-to-end nella nostra pipeline di integrazione continua. Immaginiamo un futuro in cui una pipeline CI esegua il rendering di un file di schizzo da un tag o ramo in un repository (o meglio, renderizza oggetti Figma nativi anziché passare attraverso Sketch), carica quel file su Figma e collega il documento risultante a un pull richiesta. I commenti di Figma possono essere inviati su GitHub, fornendo comunicazioni e feedback senza soluzione di continuità tra design e codice.

Inoltre, anche se abbiamo creato le basi tecniche per la libreria dei componenti, dobbiamo ancora stabilire regole praticabili su come e quando estendere i componenti e / o crearne di nuovi. Quali proprietà di quali componenti possono essere modificate caso per caso e quando un gran numero di modifiche indica la necessità di creare un nuovo componente? Dobbiamo identificare le risposte naturali a questi problemi, idealmente trovare modi automatizzati per far applicare tali decisioni.

Con questa nuova libreria di componenti, abbiamo notato un aumento della produttività e dell'efficienza con i nostri handoff design-to-code. Sebbene lungi dall'essere perfette, le capacità complete end-to-end di questo nuovo processo ci hanno permesso di aumentare la velocità con cui iteriamo sul lavoro, mantenendo un alto livello di integrità nell'identità del prodotto. La conversazione sulla progettazione e la tecnologia di progettazione si sta sviluppando rapidamente in molti team di prodotti in tutto il mondo. Il design è qualcosa di cui ci preoccupiamo profondamente in AirSwap e la tecnologia di progettazione è diventata un'interessante intersezione dello sviluppo del prodotto che possiamo sfruttare per aiutarci a spedire prodotti fantastici.

  • Iscriviti al blog di AirSwap
  • Unisciti al nostro canale ufficiale su Telegram
  • Seguici su Twitter
  • Trovaci su Facebook
  • Iscriviti al nostro subreddit