Bridging the Gap Between Design & Code

‘Design & kode’ er en serie om design- og ingeniøreksperimenter, processer og indlæring, bragt til dig af AirSwap-teamet.

Hos AirSwap har vi en asynkron og iterativ tilgang til produktudvikling. En af de tidligste udfordringer, vi stød på, var imidlertid at opretholde en konsistent produktidentitet gennem iterationer af funktionsarbejde på tværs af flere produktejere. Når vi arbejdede med de tidlige versioner af AirSwap Token Trader og AirSwap Widget, samlede vi hurtigt en håndfuld Sketch-filer - hver fil indeholdt en grabpose med symboler og stilarter, der repræsenterede status for vores produktidentitet på det tidspunkt. Selvom dette virkede i begyndelsen, voksede vores mangel på en samlet kilde til sandhed hurtigt til et rod af forældede stilarter på tværs af flere kilder.

Med flere filer og symboler spredt over dem alle, blev det en besvær, der styrede en ensartet identitet.

Hver frontend-oplevelse på AirSwap er skrevet i React. I begyndelsen havde vi et bibliotek med delte komponenter, et foreløbigt komponentbibliotek, hvis du vil, med de rette stilarter, der matchede produktidentiteten. Efterhånden som vi itererede, ændrede vores produktidentitet sig. Henvisning til designkomponenter til nyere funktioner gjorde det sværere at identificere, om en bestemt komponent allerede eksisterede eller skulle implementeres. Vi tog en tidlig beslutning om at bruge stylede komponenter, som gjorde det muligt for os hurtigt at iterere og opbygge funktioner. Brugervenligheden, der fulgte med stylede komponenter, var en kæmpe gevinst, men det gjorde os også utilsigtet tilladt at tage nogle dårlige beslutninger i udvidelse af stilarter. Uden strenge regler for, hvordan man opretter eller udvider komponenter, blev vores kodebase hurtigt hjemsted for en masse duplikeret kode med kun mindre forskelle. Dette reducerede ikke kun udviklerhastigheden og øgede teknisk gæld, men indførte også inkonsekvens i vores produktidentitet.

På grund af fraværet af et veldefineret system på designkomponenterne, ville mange filer i vores kodebase introducere nye komponenter, der ligner de eksisterende, eller foretage mindre ændringer af de eksisterende komponenter.

I vores søgning efter en løsning på disse problemer er vi for nylig begyndt at eksperimentere med, hvordan man brobro mellem design og kode.

Design teknologi

Ideen om designteknologi er ikke noget nyt. Der findes værktøjer som Craft og Invision for at hjælpe designere med at konsolidere deres stilarter og bygge bro over denne information til udviklere. Dette gør det muligt for flere interessenter at arbejde på forskellige funktioner, mens de opretholder et konsolideret sæt basekomponenter eller et delt komponentbibliotek. Men hvad vi havde brug for var en måde at ikke kun opretholde paritet mellem design, men også opretholde paritet mellem hvilke komponenter, der udgør et design, og hvad der findes i koden.

For cirka et år siden frigav designteknologiteamet på Airbnb et open source-projekt kaldet react-sketchapp, som gjorde det muligt for React-komponenter at gengive til Sketch. React-gruppen reagerede positivt, og hurtigt nok frigav stylede komponenter en udvidelse af deres bibliotek, stylede komponenter / primitiver, med støtte til gengivelse af flere mål (inklusive gengivelse til Sketch). Disse projekter blev grundlæggende tekniske løsninger på de uoverensstemmelsesproblemer, vi stod overfor.

AirSwap-komponentbibliotek

Efter en udtømmende revision af AirSwap-widgeten identificerede og genskabte vi i Sketch det sæt af komponenter, der skulle bruges på tværs af alle nuværende og fremtidige funktioner. Derefter tog vi os tid til at genskabe hele dette komponentbibliotek i React ved hjælp af stylede komponenter / primitiver som vores fundament. Vores komponenter blev gengivet som symboler gennem react-sketchapp, hvilket skabte en enkelt kilde til sandhed til vores designs.

Reager komponenter gengivet til Sketch

Oprettelse af komponentbibliotek blev grundlaget for vores foreløbige designproces fra ende til ende på AirSwap. Designerne til komponenterne kom først efterfulgt af implementering. Da vi brugte stylede komponenter og reaktionsskitsapp, kunne vi returnere den implementerede kode til Sketch til gennemgang. Efter godkendelse vil de gengivne komponenter blive de nye design, klar om nødvendigt i fremtiden.

Flere versioner af komponentbiblioteket, gengivet til Sketch og uploadet til Figma

Indtast Figma

Denne cyklus eliminerer forskellen mellem kode og design. Vi opdagede imidlertid hurtigt de ekstra fordele ved denne løsning, da vi begyndte at udføre størstedelen af ​​vores designarbejde på Figma. Da vores designværktøjer tillader os at oprette sketch-dokumenter fra vores komponentbibliotek, uploader vi hver nye revision til Figma. Kommentarer og anmodninger om ændringer kan fremsættes interaktivt ved den seneste revision, der indeholder specifikationer for den næste revision, der kun kan uploades, når alle tidligere kommentarer er adresseret. Dette er ikke helt sømløst (endnu), men det skaber en UI-gennemgangsproces, der informativt ligner GitHub-pull-anmodninger.

Brug af vores nye komponentbibliotek til at bygge mock til den nye AirSwap Conversational OTC Trading

Ved hjælp af Figmas delte biblioteksfunktioner kan vi desuden give adgang til disse komponenter på tværs af alle vores designkomponenter. Som ingeniører kan vi i realtid samarbejde se og redigere disse comps, som giver en klar indikation af, hvilken komponent der bruges. Dette fjerner fuldstændig gætte om, hvorvidt en komponent allerede findes, eller ej, da navnet på komponenten vises på Figma.

Komponentnavnet vises i Figma, som straks giver information til udviklere, der ser på spottene

Hvad er det næste

Når vi går videre, har vi til hensigt at forbedre og finpusse denne proces for at passe mere problemfrit i vores produktudviklingsarbejde. Der kræves stadig flere manuelle og ineffektive trin.

For det første leverer Figma ikke i øjeblikket et API, der kan skrives, til dokumenter, hvilket kræver, at vi manuelt uploader de genererede Sketch-filer. Med ordentlig API-support kan vi let integrere denne ende til ende-proces i vores kontinuerlige integrationspipeline. Vi ser for os en fremtid, hvor en CI-rørledning gengiver en Sketch-fil fra et tag eller gren i en repo (eller endnu bedre, gengiv indfødte Figma-objekter i stedet for at gå gennem Sketch), uploade denne fil til Figma og knytte det resulterende dokument til et træk anmodning. Kommentarer fra Figma kan krydses til GitHub, hvilket giver problemfri kommunikation og feedback mellem design og kode.

Derudover har vi endnu ikke oprettet praktiske regler for, hvordan og hvornår vi skal udvide komponenter og / eller oprette nye, selvom vi har oprettet det tekniske fundament for komponentbiblioteket. Hvilke egenskaber for hvilke komponenter kan finjusteres fra sag til sag, og hvornår angiver et stort antal ændringer et behov for at oprette en ny komponent? Vi er nødt til at identificere naturlige svar på disse problemer og ideelt set komme med automatiserede måder at håndhæve disse beslutninger på.

Med dette nye komponentbibliotek har vi bemærket en stigning i produktivitet og effektivitet med vores overførsler til design-til-kode. Skønt langt fra perfekt, har de fulde ende-til-ende-egenskaber ved denne nye proces gjort det muligt for os at øge hastigheden, hvorpå vi gentager arbejdet, samtidig med at vi opretholder en høj grad af integritet i produktidentitet. Samtalen omkring design og designteknologi udvikler sig hurtigt i mange produktteam over hele verden. Design er noget, vi interesserer os dybt med på AirSwap, og designteknologi er blevet et spændende skæringspunkt mellem produktudvikling, som vi kan udnytte til at hjælpe os med at sende fantastiske produkter.

  • Abonner på AirSwap-bloggen
  • Deltag i vores officielle kanal på Telegram
  • Følg os på Twitter
  • Find os på Facebook
  • Abonner på vores subreddit