Opbygning af et visuelt sprog: Bag kulisserne i vores Airbnb-designsystem

Arbejder med softwareudvikling og design er vi ofte forpligtet til at sende engangsløsninger. Nogle gange arbejder vi inden for tidsbegrænsninger, og nogle gange er vi endnu ikke enige om en vej fremad. Disse engangsløsninger er ikke i sig selv dårlige, men hvis de ikke bygger på et solidt fundament, finder vi os til sidst nødt til at betale tilbage påløbne tekniske og designgæld.

Visuelt sprog er som ethvert andet sprog. Misforståelser opstår, hvis sproget ikke deles og forstås af alle, der bruger det. Når et produkt eller et team vokser, udbydes udfordringerne inden for disse modaliteter.

Design har altid stort set handlet om systemer, og hvordan man opretter produkter på en skalerbar og gentagelig måde. Fra Pantone-farver til Philips-skruer gør disse systemer i stand til at styre kaoset og skabe bedre produkter. Digitale produkter er måske den mest frugtbare grund til implementering af disse systemer, og alligevel betragtes de ikke ofte som en prioritet.

Et samlet designsystem er vigtigt for at bygge bedre og hurtigere; bedre, fordi en sammenhængende oplevelse lettere forstås af vores brugere, og hurtigere, fordi den giver os et fælles sprog at arbejde med.

Hvorfor vi har brug for designsystemer

Airbnb har oplevet en masse vækst gennem årene. I øjeblikket består vores designafdeling af næsten et dusin funktioner og resultathold. Det blev klart, at vi havde brug for mere systematiske måder at vejlede og udnytte vores kollektive indsats. Mens vi anerkendte disse udfordringer i virksomheden, tror jeg, de er symptomer på større softwarebranche-problemer.

For få begrænsninger
Software design har få fysiske begrænsninger sammenlignet med mange andre designdiscipliner. Dette giver mulighed for en række løsninger til enhver given udfordring, men åbner det også for usammenhængende brugeroplevelser. Som produkt ejere og designere er vi nødt til at oprette og følge vores egne begrænsninger.

Flere designere og interessenter
Software er ofte bygget af teams - nogle gange utroligt store teams - af mennesker. Udfordringen med at skabe sammenhængende oplevelser multipliceres eksponentielt, efterhånden som flere mennesker tilføjes mix. Ligeledes over tid, uanset hvor konsistent eller lille et team er, vil forskellige mennesker bidrage med nye løsninger og stilarter, hvilket får oplevelser til at afvige.

Mængde af platforme
Vi er nødt til at sende vores produkt på en række platforme og enheder. At holde funktioner og design synkroniseret kræver betydelig indsats, hvilket ofte kræver, at det samme arbejde gentages på tværs af alle disse platforme.

Software som et kontinuum
En anden unik ting ved software er, at selvom det kan betragtes som et produkt, slides det ikke rigtigt og bliver erstattet som traditionelle forbrugerprodukter. Kode og design oprettet for mange år siden findes stadig mange steder, selv efter at et virksomheds landskab og dets produkt er ændret markant. Dette kræver konstant vedligeholdelse og opgradering.

At komme på arbejde

For at arbejde gennem disse udfordringer og holde vores beslutningsproces hurtig, samlede vi en lille gruppe designere og ingeniører [2]. Vi ryddet vores kalendere, reserverede et eksternt studiested lige uden for Airbnb HQ og dedikerede os til at designe og opbygge Design Language System (DLS).

Målet, vi satte os for DLS, var at skabe et mere smukt og tilgængeligt designsprog. Vores design skal være forenede platforme, der driver større effektivitet gennem veldefinerede og genanvendelige komponenter. For at fokusere vores indsats reducerede vi det oprindelige omfang til at oprette systemet først på native platforme (iOS & Android).

Vi startede med at revidere og udskrive mange af vores design, både gamle og nye. Ved at lægge strømme side om side på et bræt, kunne vi se, hvor og hvordan oplevelserne blev brudt, og hvor vi var nødt til at begynde at foretage ændringer. Vi regnede med, at den bedste måde at begynde på var ved at tackle problemer i spidsen. Hver af os fokuserede på en skærm eller et produktområde til redesign, og vi etablerede et par principper for at guide os med disse individuelle design:

Unified: Hvert stykke er en del af en større helhed og skal bidrage positivt til systemet i skala. Der skal ikke være isolerede funktioner eller udligere.

Universal: Airbnb bruges over hele verden af ​​et bredt globalt samfund. Vores produkter og det visuelle sprog skal være imødekommende og tilgængelige.

Ikonisk: Vi er fokuserede når det kommer til både design og funktionalitet. Vores arbejde skal tale modigt og tydeligt med dette fokus.

Samtale: Vores brug af bevægelse giver vores produkter liv og giver os mulighed for at kommunikere med brugerne på let forståelige måder.

Lægning af fundamentet

Før vi startede denne designsprint, havde vi allerede oprettet en grundlæggende stilguide, som vi kaldte fundamentet. Dette fundament definerede løst vores typografi, farver, ikoner, afstand og informationsarkitektur. Fundamentet viste sig at være vigtigt for at lede vores arbejde i en samlet retning og samtidig give plads til os til individuelt at udforske kreative designløsninger.

På denne måde følte vi, at vi alle arbejdede sammen, mod den samme idé. Når vi gennemgik vores kollektive arbejde i slutningen af ​​hver dag, begyndte vi at se mønstre opstå. Vi kursuskorrigerede, når det var nødvendigt, og begyndte at definere vores standardiserede komponenter.

Oprettelse af komponenter

Traditionelt definerer mange stilguider komponenter som atomkomponenter, som derefter bruges til at opbygge mere komplekse molekyler. I teorien fungerer dette godt for at skabe sammenhængende og fleksible systemer. I praksis er det, der ofte sker, at disse genanvendelige atomer bruges på mange forskellige måder, hvilket gør det muligt at oprette alle slags molekyler. Igen åbner dette døren for alle slags usammenhængende oplevelser og gør systemet sværere at vedligeholde.

I stedet for at stole på individuelle atomer, begyndte vi at betragte vores komponenter som elementer i en levende organisme. De har en funktion og personlighed, defineres af et sæt egenskaber, kan eksistere sammen med andre og kan udvikle sig uafhængigt. Et samlet designsprog bør ikke kun være et sæt statiske regler og individuelle atomer, men et økosystem, der udvikler sig.

Et samlet designsprog bør ikke kun være et sæt statiske regler og individuelle atomer; det bør være et økosystem, der udvikler sig.

For eksempel er vores brugeravatarelement muligvis oprindeligt defineret af en stilguide, men dets slutbrug i platformen kan påtage sig hundredevis af permutationer, hvilket gør det vanskeligt at opdatere avatarelementet nede ad vejen. ”Hvis vi ønsker at ændre enten af disse ting, kan vi være sikre på, at vi ikke bryder andre skærme.

Hver komponent er defineret af dets krævede elementer (såsom titel, tekst, ikon og billede) og kan undertiden indeholde valgfri elementer. Disse elementer er begge defineret i sketch-dokumentet såvel som i kode. I stedet for at tillade skilelinjer selv, kræver vi, at hver komponent har en skillelinje, som derefter er synlig eller skjult baseret på visningslogikken.

Kompilering af biblioteket

Mens vi oprettede disse komponenter, indsamlede vi dem i en masterfil kaldet biblioteket, som vi nævnte under hele designprocessen. Efter en uge eller to begyndte vi at se enorme produktionsspring ved at bruge biblioteket, når det gentager design. En dag, mens vi sammensatte en prototype i sidste øjeblik, var vores team i stand til at skabe næsten 50 skærme inden for få timer ved at bruge de rammer, som vores bibliotek leverede.

Mens biblioteket voksede, begyndte vi at organisere individuelle komponenter i tegnebræt indeholdende lignende genstande. Disse tegnebræt blev derefter organiseret efter generel kategori i: Navigation, markeringer, indhold, billede og specialitet.

Vi oprettede et sæt af disse komponenter til telefoner (iOS og Android) og tilpassede dem til tabletstørrelser derfra. Tabletkomponenter er stort set de samme som for mobil, og på teknisk plan behøver koden kun at eksistere en gang i to forskellige stilarter. Med dette system kan komponenter variere i udseende og placering, svarende til den måde, hvorpå responsivt design fungerer til web. Designere kan derefter designe en skærm en gang ved hjælp af fælles komponenter, og den kan let tilpasses til forskellige skærmstørrelser såvel som iOS og Android.

Til tablet skabte vi et par enkle layoutkoncepter, såsom Fokusvisninger, der fokuserer indholdet på siden, modaler og 2-søjle- og gitterlayouter.

Alle komponenter og visninger er bygget med vores egne tekniske synsrammer, der håndterer disse stilarter, tilstande og tilpasningsevne. [2]

Erfaringer

Vi vidste, at dette var et udfordrende projekt. Det betød at omdesigne og genopbygge størstedelen af ​​synspunkterne i vores app. Det lykkedes os at gøre vores mål om at skabe systemet og frigive de nye apps den 17. april. Som med ethvert projekt er der ting, vi ønsker, at vi ville have gjort anderledes.

Ikke alle komponenter er oprettet lige. I de fleste apps er der et sæt komponenter, der gentages ofte. For os er disse komponenter rækker (eller tabelceller). Når jeg ser tilbage, ville jeg ønske, at vi havde taget mere tid til at tænke på rækkerne og komme med et stærkere sæt mønstre og komponenter. I sidste ende afvikles vi med mange forskellige slags med nogle uoverensstemmelser.

Skitse. Vi forsøgte oprindeligt at oprette disse komponenter som symboler i Sketch, hvilket resulterede i et rod. Selv nu er vores Sketch-filer undertiden udfordrende at vedligeholde. Fremadrettet håber vi at finde bedre måder at vedligeholde og oprette nye komponenter på. [3]

Dokumentation. Dette projekt krævede, at vi skulle arbejde inden for en stram tidslinje, hvilket fik os til at overse noget af dokumentationsprocessen. Manglende grundig dokumentation skabte en vis forvirring, der kunne have været undgået. Ligesom med kodning er dokumentationssystemer, som de er oprettet, vigtigst for processen. Det skal gøres før eller senere, og dokumentation i hele oprettelsesprocessen muliggør en mere jævn beslutningstagning.

Konklusion

Da designsprog og kode ofte deles, kan vi nu opbygge og frigive funktioner på alle oprindelige platforme på omtrent samme tid. Udviklingen er generelt hurtigere, da produktingeniører kan fokusere mere på at skrive funktionslogikken snarere end visningskoden. Derudover deler ingeniører og designere nu et fælles sprog.

Designere var også begejstrede for systemet. Det giver produktanmeldelser mulighed for at fokusere på de faktiske koncepter og oplevelser af et design snarere end polstring, farver og typevalg. DLS giver os en delt forståelse af vores visuelle stil og strømline bidrag til et enkelt system. Dette system gør det også muligt for os alle at prototype og eksperimentere med ideer i høj kvalitet hurtigere og til en lavere pris.

Jeg tror, ​​at vi med disse systemer kan fokusere mere på faktiske brugeroplevelser og koncepter, som vi ønsker at skabe i fremtiden.

Jeg besvarede også nogle spørgsmål om Designer News AMA.

Opdatering: For yderligere detaljer og nyere udviklinger omkring vores designsystem, se min tale på Design Systems 2018-konferencen Helsinki, Finland.

Fodnoter:

[1]: Mange gode projekter handler om teams, og der er altid for mange mennesker til at takke for, men jeg ønskede at fremhæve få mennesker, der fik dette projekt til at ske:

Bek Stone, Adam Michela, Amber Cartwright, Alex Schleifer, Michael Bachand, Paul Kompfner, Sean Abraham, Salih Abdul-Karim, Michael Sui + mange andre i design- og ingeniørteams. Tak Josh Leong, Sola Biu, Catherine Waite for at have læst udkastene til dette.

[2]: Jeg overlader det til en af ​​vores ingeniører at skrive mere om den tekniske side af DLS.

[3]: I vores tilfælde ønsker vi, at folk skal være i stand til at ændre symbolstørrelserne (f.eks. Du skal bruge mere indhold i en header). Hvis du har brug for at ændre størrelsen på eller ved at ændre størrelsen på noget, vil Sketch (2.5) automatisk ændre størrelsen på hver forekomst af dette symbol. Det ville dræbe din skitse i få øjeblikke og sandsynligvis ødelægge din fil permanent (undertiden fortryd fungerede ikke). Vi endte med at placere komponenterne i laggrupper og lade folk kopiere og indsætte dem.

Vi bruger også git / github til at lette filopdateringsprocessen. Vi opretter og tilføjer nye komponenter manuelt til vores hovedbibliotek Sketch-fil, og indsender pull-anmodninger med en ændringslog og genereret png-eksport, der dokumenterer ændringerne. Derefter ender Sketch-filen ind i en delt mappe, der er knyttet til Sketch-skabeloner, så alle har øjeblikkelig adgang til de nye komponenter.