Visuaalisen kielen rakentaminen: Airbnb-suunnittelujärjestelmämme kulissien takana

Ohjelmistokehityksen ja suunnittelun parissa meitä vaaditaan usein toimittamaan kertaluonteisia ratkaisuja. Toisinaan työskentelemme aikarajoissa, ja joskus emme vain ole vielä sopineet etenemissuunnasta. Nämä kertaluonteiset ratkaisut eivät ole luonnostaan ​​huonoja, mutta jos niitä ei rakenneta vankalle pohjalle, joudumme lopulta maksamaan takaisin kertyneet tekniset ja suunnitteluvelat.

Visuaalinen kieli on kuin mikä tahansa muu kieli. Väärinkäsityksiä syntyy, jos kieltä ei jaeta ja ymmärretä kaikilla sitä käyttävillä. Tuotteen tai tiimin kasvaessa näiden tapojen haasteet yhdistyvät.

Suunnittelussa on aina ollut pääosin kyse järjestelmistä ja siitä, kuinka luoda tuotteita skaalautuvalla ja toistettavalla tavalla. Pantone-väreistä Philips-ruuveihin näiden järjestelmien avulla voimme hallita kaaosta ja luoda parempia tuotteita. Digitaaliset tuotteet ovat ehkä heikoin maaperä näiden järjestelmien toteuttamiselle, mutta sitä ei kuitenkaan pidetä usein prioriteettina.

Yhtenäinen suunnittelujärjestelmä on välttämätöntä paremman ja nopeamman rakentamisen kannalta; parempaa, koska yhtenäinen kokemus ymmärretään helpommin käyttäjillemme ja nopeampi, koska se antaa meille yhteisen kielen työskennellä.

Miksi tarvitsemme suunnittelujärjestelmiä

Airbnb on kokenut paljon kasvua vuosien varrella. Suunnitteluosastomme koostuu tällä hetkellä lähes kymmenestä toiminnasta ja tulosryhmästä. Kävi selväksi, että tarvitsimme systemaattisempia tapoja ohjata ja hyödyntää kollektiivista työtämme. Vaikka tunnistimme nämä haasteet yrityksessä, uskon, että ne ovat oireita suuremmista ohjelmistoteollisuusongelmista.

Liian vähän rajoituksia
Ohjelmistosuunnittelulla on vähän fyysisiä rajoituksia verrattuna moniin muihin suunnittelun aloihin. Tämä antaa mahdollisuuden tarjota erilaisia ​​ratkaisuja mihin tahansa haasteeseen, mutta avaa sen myös hajaantuneille käyttäjäkokemuksille. Tuotteiden omistajina ja suunnittelijoina meidän on luotava ja noudatettava omia rajoituksiamme.

Useita suunnittelijoita ja sidosryhmiä
Ohjelmistot rakentavat usein ihmisten joukkueet - joskus uskomattoman suuret joukkueet. Haaste luoda yhtenäisiä kokemuksia moninkertaistuu eksponentiaalisesti, kun joukkoon lisätään enemmän ihmisiä. Ajan myötä, riippumatta siitä, kuinka johdonmukainen tai pieni joukkue on, erilaiset ihmiset lisäävät uusia ratkaisuja ja tyylejä aiheuttaen kokemusten eroon.

Lukuisat alustat
Meidän on lähetettävä tuotteemme monilla alustoilla ja laitteilla. Ominaisuuksien ja mallien synkronointi vaatii huomattavia ponnistuksia, edellyttäen usein saman työn toistamista kaikilla näillä alustoilla.

Ohjelmisto jatkumona
Toinen ohjelmiston ainutlaatuinen asia on se, että vaikka sitä voidaan pitää tuotteena, se ei todellakaan kulu eikä korvaa kuin perinteiset kuluttajatuotteet. Vuotta sitten luodut koodit ja mallit ovat edelleen olemassa monissa paikoissa, jopa sen jälkeen, kun yrityksen ja sen tuotteen maisema on muuttunut huomattavasti. Tämä vaatii jatkuvaa huoltoa ja päivittämistä.

Päästä töihin

Jotta voimme selvittää nämä haasteet ja pitää päätöksentekoprosessimme nopeana, kokomme pienen ryhmän suunnittelijoita ja insinöörejä [2]. Tyhjensimme kalenterimme, varasimme ulkoisen studiopaikan aivan Airbnb HQ: n ulkopuolelle ja omistauduimme suunnittelukielen järjestelmän (DLS) suunnitteluun ja rakentamiseen.

DLS: lle asettamme tavoitteena oli luoda kauniimpi ja helposti saavutettavissa oleva suunnittelukieli. Suunnittelumme tulisi olla yhtenäiset alustat, jotka lisäävät tehokkuutta selkeästi määriteltyjen ja uudelleen käytettävien komponenttien avulla. Keskittääksemme ponnistelumme pienensimme alkuperäistä laajuutta luoda järjestelmä ensin natiiviin alustoihin (iOS ja Android).

Aloitimme tarkastamalla ja tulostamalla monia mallejamme, sekä vanhoja että uusia. Asettamalla virtaukset vierekkäin taululle, näimme missä ja miten kokemukset rikkoivat ja missä meidän piti aloittaa muutokset. Kuvittelimme, että paras tapa aloittaa oli käsitellä asioita eteenpäin. Jokainen meistä keskittyi näytön tai tuotealueen suunnitteluun, ja me perustimme muutamia periaatteita opastaa meitä näiden yksittäisten mallien:

Yhtenäinen: Jokainen pala on osa suurempaa kokonaisuutta ja sen tulisi vaikuttaa positiivisesti järjestelmään mittakaavassa. Ei pitäisi olla erillisiä ominaisuuksia tai poikkeavia.

Universal: Airbnb: tä käyttää ympäri maailmaa laaja globaali yhteisö. Tuotteidemme ja visuaalisen kielemme tulisi olla vieraanvaraisia ​​ja saatavissa.

Ikoninen: Olemme keskittyneitä sekä suunnitteluun että toiminnallisuuteen. Työmme pitäisi puhua rohkeasti ja selvästi tähän painopisteeseen.

Keskusteleva: Liikkeemme käyttö hengittää elämää tuotteihimme ja antaa meille mahdollisuuden kommunikoida käyttäjien kanssa helposti ymmärrettävällä tavalla.

Perustan luominen

Ennen tämän suunnitteluprinterin aloittamista olimme jo luoneet tyylioppaan, jonka kutsumme säätiöksi. Tämä säätiö määritteli löysästi typografian, värit, kuvakkeet, etäisyyden ja tietoarkkitehtuurimme. Säätiö osoittautui välttämättömäksi ohjata työtämme yhtenäiseen suuntaan antaen samalla meille tilaa tutkia yksilöllisesti luovia suunnitteluratkaisuja.

Tällä tavalla tunsimme työskentelevämme yhdessä saman idean eteen. Tarkastelemalla kollektiivista työtämme jokaisen päivän lopussa, havaittiin, että malleja syntyy. Suoritimme kurssin tarvittaessa ja aloimme määritellä standardisoidut komponentit.

Komponenttien luominen

Perinteisesti monet tyylioppaat määrittelevät komponentit atomikomponenteiksi, joita sitten käytetään rakentamaan monimutkaisempia molekyylejä. Teoriassa tämä toimii hyvin johdonmukaisten ja joustavien järjestelmien luomiseksi. Käytännössä kuitenkin usein tapahtuu, että näitä uudelleen käytettäviä atomeja käytetään monin eri tavoin, mikä mahdollistaa kaikenlaisten molekyylien luomisen. Tämä avaa oven kaikenlaisille hajaantuneille kokemuksille ja vaikeuttaa järjestelmän ylläpitoa.

Yksittäisiin atomiin luottamisen sijasta aloimme harkita komponenttejamme elävän organismin osina. Heillä on toiminto ja persoonallisuus, ne on määritelty ominaisuuksien joukolla, ne voivat esiintyä rinnakkain muiden kanssa ja voivat kehittyä itsenäisesti. Yhtenäisen suunnittelukielen ei tulisi olla vain joukko staattisia sääntöjä ja yksittäisiä atomeja, vaan myös kehittyvä ekosysteemi.

Yhtenäinen suunnittelukieli ei saisi olla vain joukko staattisia sääntöjä ja yksittäisiä atomeja; sen pitäisi olla kehittyvä ekosysteemi.

Esimerkiksi käyttäjän avatar-elementti voidaan määritellä alun perin tyylioppaan avulla, mutta sen loppukäyttö alustalla voi viedä satoja permutaatioita, mikä vaikeuttaa avatarelementin päivittämistä onnistuneesti tiellä. ”Jos haluamme muuttaa jompaakumpaa näistä asioista, voimme olla varmoja, että emme riko muita näyttöjä.

Jokainen komponentti määritellään sen vaadittavien elementtien (kuten otsikko, teksti, kuvake ja kuva) avulla, ja se voi joskus sisältää valinnaisia ​​elementtejä. Nämä elementit on määritelty sekä Sketch-asiakirjassa että koodissa. Sen sijaan, että sallimme itse jakajaviivat, vaadimme, että jokaisella komponentilla on jakaja, joka on sitten näkyvissä tai piilotettu näkymälogiikan perusteella.

Kirjaston kokoaminen

Luodessamme näitä komponentteja keräämme ne päätiedostoon nimeltä kirjasto, johon viittasimme koko suunnitteluprosessin ajan. Viikon tai kahden kuluttua aloimme nähdä valtavia tuottavuuden harppauksia käyttämällä kirjastoa iteroimalla malleja. Yhtenä päivänä, kun kootimme viime hetken prototyypin, tiimimme pystyi luomaan lähes 50 näyttöä vain muutamassa tunnissa kirjaston tarjoamien puitteiden avulla.

Kun kirjasto kasvoi, aloimme järjestää yksittäisiä komponentteja tauluihin, jotka sisältävät samanlaisia ​​esineitä. Nämä taulut jaettiin sitten yleisen luokan mukaan: navigointi, telttat, sisältö, kuva ja erikoisuus.

Loimme yhden sarjan näistä komponenteista puhelimille (iOS ja Android) ja mukautimme ne tablet-kokoon sieltä. Tablettikomponentit ovat pitkälti samat kuin mobiililaitteissa, ja teknisellä tasolla koodin on oltava olemassa vain kerran kahdessa eri tyylissä. Tämän järjestelmän avulla komponentit voivat vaihdella ulkonäöltään ja sijoittelustaan, samalla tavalla kuin reagoiva suunnittelu toimii webissä. Suunnittelijat voivat sitten suunnitella näytön kerran käyttämällä yleisiä komponentteja, ja se voidaan helposti mukauttaa eri näytön kokoihin sekä iOS: iin ja Androidiin.

Tablettilaitteille loimme pari yksinkertaista asettelukonseptia, kuten Focus Views, joka keskittää sivun sisällön, modaalit sekä 2-sarake- ja ruudukkoasettelut.

Kaikki komponentit ja näkymät on rakennettu omalla teknisellä näkymäkehyksellämme, joka käsittelee näitä tyylejä, tiloja ja mukautuvuutta. [2]

Opittua

Tiesimme, että tämä oli haastava projekti. Se tarkoitti suurimman osan sovelluksessamme olevien näkymien suunnittelusta ja uudelleenrakentamisesta. Onnistuimme saavuttamaan tavoitteemme luoda järjestelmä ja julkaista uudet sovellukset 17. huhtikuuta. Kuten minkä tahansa projektin kohdalla, on asioita, joita toivomme, että olisimme tehneet toisin.

Kaikkia komponentteja ei luoda tasavertaisia. Useimmissa sovelluksissa on joukko komponentteja, jotka toistuvat usein. Meille nämä komponentit ovat rivejä (tai taulukkosoluja). Toivon taaksepäin, että toivomme, että meillä olisi ollut enemmän aikaa miettiä rivejä ja keksiä vahvempi malli- ja komponenttijoukko. Loppujen lopuksi meillä on monia erilaisia ​​epäjohdonmukaisuuksia.

Luonnos. Yritimme alun perin luoda nämä komponentit symboleiksi Sketchissä, mikä johti sotkuun. Vielä nytkin Sketch-tiedostojemme ylläpitäminen on joskus haastavaa. Toivomme löytävänsä parempia tapoja ylläpitää ja luoda uusia komponentteja. [3]

Dokumentointi. Tämä projekti vaati meitä toimimaan tiukassa aikataulussa, mikä sai meidät unohtaa osan dokumentointiprosessista. Perusteellisen dokumentoinnin puute aiheutti sekaannusta, jonka olisi voinut välttää. Aivan kuten koodauksessa, järjestelmien dokumentointi niiden luomisessa on ensiarvoisen tärkeää prosessille. Se on tehtävä ennemmin tai myöhemmin, ja koko luomisprosessin dokumentointi mahdollistaa sujuvamman päätöksenteon.

johtopäätös

Koska suunnittelukieli ja koodi ovat usein yhteisiä, voimme nyt rakentaa ja vapauttaa ominaisuuksia kaikille alkuperäisille alustoille suunnilleen samaan aikaan. Kehitys on yleensä nopeampaa, koska tuotesuunnittelijat voivat keskittyä enemmän piirteiden logiikan kuin näkymäkoodin kirjoittamiseen. Lisäksi insinöörit ja suunnittelijat jakavat nyt yhteisen kielen.

Suunnittelijat olivat myös innoissaan järjestelmästä. Sen avulla tuotearvioinnissa voidaan keskittyä suunnittelun todellisiin konsepteihin ja kokemuksiin sijaan pehmusteisiin, väreihin ja tyyppivalintoihin. DLS tarjoaa meille yhteisen käsityksen visuaalisesta tyylistämme ja virtaviivaistaa panoksia yhteen järjestelmään. Tämä järjestelmä antaa meille kaikille myös prototyypin ja kokeilla ideoita erittäin uskollisesti nopeammin ja edullisemmin.

Uskon, että näiden järjestelmien avulla voimme keskittyä enemmän todellisiin käyttökokemuksiin ja konsepteihin, joita haluamme luoda tulevaisuudessa.

Vastasin myös joihinkin kysymyksiin aiheesta Designer News AMA.

Päivitys: Jos haluat lisätietoja ja suunnittelujärjestelmäämme koskevaa viimeaikaista kehitystä, katso puheeni Design Systems 2018 -konferenssissa Helsingissä.

alaviitteet:

[1]: Monet hienot projektit koskevat joukkueita ja ihmisiä on aina liian paljon kiittääkseen, mutta halusin tuoda esiin muutamia ihmisiä, jotka tekivät tämän projektin tapahtumaan:

Bek Stone, Adam Michela, Amber Cartwright, Alex Schleifer, Michael Bachand, Paul Kompfner, Sean Abraham, Salih Abdul-Karim, Michael Sui + monet muut suunnittelutiimien jäsenistä. Kiitos Josh Leong, Sola Biu, Catherine Waite lukemasta tämän luonnoksia.

[2]: Jätän yhden suunnittelijamme tehtäväksi kirjoittaa lisää DLS: n teknisestä puolelta.

[3]: Tässä tapauksessa haluamme, että ihmiset voivat muuttaa symbolikokoja (esim. Sinun on majoitettava enemmän sisältöä otsikkoon). Jos joudut muuttamaan jonkin kokoa tai muuttamaan sitä vahingossa, Sketch (2.5) muuttaa automaattisesti jokaisen symbolin esiintymän. Se tappaisi luonnoksesi hetkeksi ja todennäköisesti sekaisi tiedostosi pysyvästi (joskus kumoaminen ei toiminut). Saavutimme komponentit kerrosryhmiin ja annimme ihmisille kopioida ja liittää ne.

Käytämme git / github-tiedostoa myös tiedostojen päivitysprosessin helpottamiseksi. Luomme ja lisäämme uusia komponentteja manuaalisesti kirjastokokoelmatiedostoomme ja lähetämme vetopyynnöt muutoslokiin ja luomme png-viennin, joka dokumentoi muutokset. Sen jälkeen Sketch-tiedosto päätyy jaettuun Box-kansioon, joka on linkitetty Sketch-malleihin, joten kaikilla on pääsy uusiin komponentteihin heti.