Hvordan Kiwi.com håndterer projektstruktur, versionering og komponenter i Figma

En tidligere Figma-skeptiker ændrer sin melodi

Billed oprettet til Figma af Peter Barnaba

Figma-redaktørens note: Med denne historie gentrykker vi fremragende arbejde fra Kiwi.com-designer Denis Rojcyk, som oprindeligt dukkede op på hans personlige websted. Vi lavede nogle justeringer til grammatik, formatering og forståelse, men vi sponsorerede ikke dette indlæg. Er du interesseret i at skrive om design eller din Figma-proces til vores blog? Meddelelse content@figma.com.

Det mobile designteam på rejsebestillingsstedet Kiwi.com er lille, vi er kun to. Men der er omkring tyve mennesker, der bidrager til vores design på en eller anden måde, uanset om de kommenterer vores seneste iterationer, fikserer kopi eller designer krydsplatformfunktioner. I øjeblikket er vores frontend designet i Sketch, ligesom Orbit, vores designsystem. Men da den mobile del af Orbit er visuelt anderledes, besluttede vi at prøve at designe den i Figma og se, hvordan det fungerer for os.

Dette indlæg dækker:

1. Hvorfor vi byggede vores mobile designsystem i Figma
2. Hvordan den seneste opdatering ændrede vores måde at arbejde på
3. Hvordan vi har organiseret vores designsystem (med eksempler)

Spring videre til det tredje afsnit ("Vores designbibliotekskomponentprincipper"), hvis du allerede er en Figma-konvertering og bare vil have inspiration til at organisere komponenter, håndtere versionhistorik og anden husholdning.

Gå til "Komponentprincipper", hvis du allerede er en Figma-konvertering og bare ønsker filorganisation / strukturering af ideer

Hvorfor Figma?

En sketchorienteret arbejdsgang er afhængig af værktøjer som Zeplin til håndtering af overleveringer, Abstract til at dække versionskontrol og Marvel til at designe statiske prototyper. Men fra tid til anden kommer tingene ud af synkronisering. Prototyper sidder fast på de seneste testede iterationer, folk glemmer at skubbe forpligtelser til Abstract, måske Zeplin ikke er blevet opdateret med de seneste godkendte grafik, eller PNG'erne, der er integreret i Dropbox Paper, er 3 uger gamle. Disse værktøjer er ved design bundet til at komme ud af synkronisering .

Før jeg kom til Kiwi.com, spillede jeg med ideen om at prøve Figma, men det var svært for mig at komme til det. Jeg så ikke så meget værdi ved at bruge det, og jeg havde ikke brug for at holde alle mine værktøjer synkroniserede.

Jeg blev også frataget af browseren / sky-tilgangen til det. Jeg kunne godt lide, at jeg kunne affyre Sketch, når jeg ville, og det er en indbygget Mac-app. Og så ramte det mig, der er ingen vej omkring det - du har enten alt i skyen, og det er synkroniseret 100% af tiden, eller så har du ting offline i desynkroniserede arbejdsgange. Så jeg prøvede at arbejde med Figma, bare lidt i starten, og jeg kunne godt lide det meget.

Så blev jeg medlem af Kiwi.com i november sidste år. Vojta var den eneste, der arbejdede der på mobilen på det tidspunkt. Han dækkede alle platforme og alle enheder af sig selv . Mens han gjorde et fantastisk stykke arbejde, manglede hans arbejde et konsekvent system bag det.

Vi ville prøve det, men at satse på Figma uden hele holdet og designe Orbit i det virkede som et dårligt opkald. Det var ikke meget klart, hvilken retning Figma-teamet ville gå i, og hvad de ville fokusere på. Derudover var nogle af funktionerne bare ikke helt klar. Og alligevel besluttede vi at prøve det alligevel, men kun med mobil. Vores frontend og Orbit er stadig designet og vedligeholdt i Sketch.

Så ramte det mig: Du har enten alt synkroniseret 100% i skyen, eller så har du ting offline i desynkroniserede arbejdsgange.

Figma 3.0

Indtil for nylig var det en smerte at styre komponenter. Figma manglede funktionerne for at gøre designsystemet skalerbart. Hvis du ønskede at arbejde med en DS effektivt, var du begrænset til en enkelt fil.

Heldigvis introducerede Figma en enorm 3.0-opdatering. Jeg vil ikke gå meget i detaljer her (bare følge linket), men dybest set opdateringen:

1. Det er let at aktivere, deaktivere og styre opdateringer
2. Aktiverede brugere til at dele komponenter med tilsidesættelser på tværs af filer
3. Aktiverede brugere til at dele forskellige stilarter for lag (hvilket gør det mere atomisk end Sketch, da det giver dig mulighed for at kombinere tekstformater med farver og effekter)

Vores principper for designbibliotekskomponenter

Hver gang vi designer en ny bibliotekskomponent eller enhver anden tilføjelse til designsystemet, prøver vi at følge et par UX-principper for at sikre, at biblioteket forbliver konsistent, effektivt og let at arbejde med.

Højeste to niveauer dyb komponent

At arbejde med komponenter og hekke dem føles temmelig kraftigt i starten. Ved at bygge komponenter ud på atomniveau (som ikoner) og samle dem til større komponenter (som statusbjælker), giver du dig selv fleksibiliteten til at ændre et lille stykke af dit system og se det afspejle sig i alle dele af dit design. For dem, der ikke kender praksis, her er et blogindlæg og en tutorialvideo, der går nærmere ind på.

At gå 2 niveauer dybt inde i komponent-reden, giver den bedste balance mellem brugervenlighed og mulighed.

Men så snart du går mere end et par lag dybt - for eksempel, lad os sige, at du hekker en ikonkomponent i en statuslinjekomponent, som i sig selv er indlejret i en hjemmeskærmkomponent - din proces kan blive virkelig forvirrende. Med stor kraft kommer stort ansvar, og jeg har fundet ud af, at det at gå omkring 2 niveauer dybt inde i komponenthekker giver den bedste balance mellem brugervenlighed og mulighed. Det er en afgørende retningslinje, der holder vores designsystem håndterbart.

Indlejrede komponenter i aktion

Gør det lettere at vælge lag (især med tekst)

For at designe hurtigt har du brug for teknikker til at manipulere lag og komponenter. De har ofte usynlige afgrænsningsbokse omkring dem, der kan være vanskelige at sømme (meget som 'hitbox'-målene i FPS-spil). Lad os sige, at du opretter en standardkomponent med kun en tekstetiket. Når du opretter et tekstlag i Figma, er håndtagene (stiplede linjer), der omgiver det, små som indpakning af teksten næsten 1: 1.

På Kiwi.com har vi fået en vane med automatisk at strække disse håndtag til komponentens grænser. Derefter kan vi dobbeltklikke næsten overalt i komponenten for at redigere etiketten.

Du skal tage en lidt anden takt, når du har to etiketter i en komponent. Hvis du strækker begge disse etiketter til kanterne, overlapper de hinanden (og den praktiske 'stræk til klik-teknik' fungerer ikke længere). I dette tilfælde skal du gøre en af ​​etiketterne lidt mindre (jeg gør den normalt halvdelen af ​​størrelsen) og skub den til toppen af ​​laglisten i venstre panel. Derefter har du en bekvem måde at dobbeltklikke på og redigere begge lag, enten ved at klikke på det store på selve lærredet eller ved at klikke på et mindre i lagpanelet.

(Øverst)

Komponent tilsidesætter logik

Forslag til tilsidesættelse af komponenter er baseret på komponentens størrelse. Så når du ønsker at erstatte en komponent med noget andet, og du vil vælge det i forslagsvinduet, skal det være af samme størrelse.

GroupIt ProTip ™

Vi pakker alle vores komponenter i grupper. På den måde rodede de ikke på sidebjælken i filkomponentbiblioteket. Dette gør arbejdet med sider med masser af komponenter langt lettere. Det er noget, jeg savner i Sketch ganske meget.

Optimer bitmap-aktiver

Når vi arbejder med fotos eller andre bitmaps i vores design, arbejder vi med dem, som vi ville gøre, hvis de ville være webaktiver.

  • Vi optimerer billederne: med værktøjer som ImageOptim, Optimage, tinyPNG og sådan. Jeg er ikke sikker på, om Figma gør nogen optimering, men vi gør det alligevel.
  • Vi optimerer filformatet: PNG'er til enkle illustrationer og JPEG til fotos.
  • Vi ændrer størrelsen på aktiverne: Vi har normalt ikke brug for fotos af billboardstørrelse i vores modeller.

Efter denne praksis forbedrer downloadtiden for vores filer og bibliotekskomponenter. Det gør også genåbning af filer mindre besværligt.

Komponenter og projektstruktur

Ud over vores retningslinjer for bygningskomponenter har vi også oprettet organisationsstruktur til projekter, versioner og filer. Jeg har gendannet de følgende eksempler, så du nemt kan bruge dem selv. Bare kopier dem, og føl dig fri til at tilpasse dem til din arbejdsgang.

Projektdækning

Det kan virke som en lille ting, men at navigere gennem Figma kan være smertefuldt, når du har masser af filer og projekter. Filtitler fungerer, men det er svært at scanne dem hurtigt. Derfor bruger vi omslagsbilleder.

Projektfilstruktur

Vi holder fast ved en fil pr. Projekt eller flow (vi har filer til ting som stedvælger, datavælger, søgning og lignende). Vi valgte denne løsning, fordi vi fandt ud af, at det at have mange brugerstrømme i en fil gør det langsomt at indlæse.

En ulempe - Du kan ikke forbinde to filer og oprette en prototype fra dem i Figma. Så med strømme, der er adskilt mellem filer, kan vi ikke teste visse brugeradfærd (som at gå fra bookingflowet til deres profiloplysninger).

Projektversionering

Vi bruger sider som forskellige versioner af projektet med en standard XY-navnekonvention. X repræsenterer enorme versionopdateringer, mens Y mindre iterationer med den nyeste iteration øverst. Komponentsiden er vært for komponentkandidater, som vi overvejer at flytte til det primære UI-bibliotek.

Hjælper bibliotek

https://www.figma.com/embed?embed_host=share&url=https://www.figma.com/file/Mutou0a3WLf4bZrApWVRU9Kz/Helpers?node-id=0%3A1

Ud over almindelige projektfiler og tokenfiler oprettede vi en separat fil kaldet Hjælpere. Det indeholder elementer, vi bruger til at organisere andre designfiler, f.eks. Et mærkningssystem. Vi sætter udtryk som "side" og "kategori" ud for designrammer for at skelne mellem disse komponenter og give lærredet en fornemmelse af struktur.

Derefter kan enhver, der gennemgår denne designfil, analysere oplysningerne hurtigt og forstå, hvad de ser på. F.eks. Indeholder Helpers-filen en klistret note til kommentarer, og vi trækker denne komponent ind i eventuelle nye designfiler, så folk kan efterlade noter. Selvom Figma har sin egen kommentarefunktion, er denne funktionalitet ikke altid åbenlyst for mennesker uden designbaggrund.

Tokens

Denne fil røres sjældent. Det indeholder de mest atomære komponenter i hele designsystemet. Filen har tre sider: farver, typografi og skygger. Grundlæggende alt, hvad du kan definere i Figma Biblioteker, undtagen for komponenter.

Tokens - farver

Tokens - typografi

Typografi er den samme som farver. Vi har allerede defineret alt, hvad vi har brug for i vores designsystem (det mangler nogle definitioner af FE-skrifttypestil), og det berøres sjældent sjældent. Typografien defineret ovenfor virker temmelig enkel, men når den kombineres med andre delte stilarter, er det alt, hvad vi har brug for på mobilen.

Tokens - skygger

Skygger er noget, vi stadig eksperimenterer med, men indtil videre har vi defineret 4 højdeniveauer, og det ser ud til at fungere godt for os.

Ikoner

Ikoner har deres egen side, de er alle opdelt i forskellige sektioner og placeres i 24x24 rammer. Næsten alle ikoner er standardmaterialedesignikoner.

Illustrationer

Illustrationer ligner meget ikoner. Det er bare et kæmpe lærred fuld af vores produktillustrationer. De har alle samme størrelse. Men på grund af nogle importbegrænsninger af SVG til Figma, er vi nødt til at arbejde med bitmaps i øjeblikket.

Orbit Mobile

Oprindeligt havde vi to forskellige mobilbiblioteker til iOS og Android. Men da de overlapper meget, har vi besluttet at kombinere dem. Det er lettere for os at vedligeholde det på denne måde. Men der er stadig forskelle i præsentationen af ​​nogle af UI-elementerne, f.eks. Switches og sådan. Dette er stadig et igangværende arbejde, og vi er nødt til at indhente Android lidt .

Naysayeren spiser sine ord

Figma manglede funktioner før 3.0-udgivelsen, men nu har de tilføjet de fleste af mine must-haves, og det er blevet en seriøs konkurrent til andre værktøjer. At opbygge et designsystem med det viste sig at være relativt let. Faktisk har jeg lyst til at styre det i Figma er langt lettere end det andre værktøjer. Det er på ingen måde perfekt, men det passer bedst til min smag.

Den måde, vi strukturerer vores filer på og splitter designsystemlogikken på, udvikler sig konstant med hver opdatering, men de ting, der er nævnt i dette indlæg, har sidst fast hos os den længste og bevist effektive.

I fremtidige stillinger vil jeg gerne dække, hvordan man rent faktisk opbygger et designsystem i Figma, nogle af gotchaserne bag arbejdet med indlejrede komponenter og nogle andre tip. Hvis dette er noget lige op i din gyde, er den sikreste måde at vide om den, når den først er ude, at følge mig på Twitter .