Kahdeksan asiaa, jotka sinun on tiedettävä suunnittelujärjestelmistä

Olen osallistunut moniin keskusteluihin, joten sinun ei tarvitse tehdä sitä.

Se on jokaisessa työkuvauksessa. Näet sen kaikkialla tuoreimmassa suunnittelutyökalun julkaisussa. Olet ehkä kuullut perheesi mainitsevan sen kiitospäivänä. Mutta mitkä ovat tosiasiat näistä ”suunnittelujärjestelmistä”, joista koko teollisuus puhuu?

Suunnittelun ja suunnittelun yhdistäminen on herättänyt suurta mielenkiintoa siirryttäessä suunnittelulle ohjelmistosuunnittelusta, joten olin innokas oppimaan kaiken suunnittelujärjestelmistä heti, kun kuulin niiden olevan tehokkaita työkaluja suunnittelutiimille ja heidän suunnitteluryhmilleen. Onneksi RETHINK ja SF Design Week järjestivät viime kuussa paljon aiheita koskevia tapahtumia ja yritin käydä jokaisessa heissä.

Se tarkoittaa, että kävin yli viidessätoista erilaisessa keskustelussa suunnittelijoiden kanssa eri organisaatioissa. Jokainen suunnittelija toi ainutlaatuisen, käytännöllisen näkemyksen suunnittelujärjestelmiin. Täällä he ovat.

Tämä on pidempi lukema, joten olen käyttänyt hieman lihavointia, jos haluat skannata tärkeät bitit.

1. Miksi suunnittelujärjestelmät ovat tärkeitä?

Lähde. Figman designsystems.com on heidän resurssi suunnittelujärjestelmien oppimiseen.

Diana Mounter, Design Systems Manager @ GitHub, tiivisti sen melko hyvin:

  • Suunnittelujärjestelmät tuovat järjestyksen kaaokseen. Kaikkia pidetään samalla sivulla, joten koko tuote pysyy yhtenäisenä ja kiillotettuna kaikkialla.
  • Suunnittelujärjestelmät parantavat käyttökokemusta käyttämällä toistuvasti tuttuja ja todistettuja malleja. Jos suunnittelet jotain tyhjästä, jätetään tilaa virheille, joten yritä käyttää sitä, mikä jo toimii.
  • Suunnittelujärjestelmät parantavat työnkulun tehokkuutta. Tuoteryhmät tietävät tarkalleen, kuinka uusien ominaisuuksien komponenttien tulisi näyttää ja miten ne toteutetaan.

Suunnittelija @ Figma -johtaja Noah Levin ajoi todella viimeisen pisteen kotiin. Hän saarnasi puheessaan toistettavuusfilosofiaa, selittäen, että paras tapa, jonka voit tehdä vietettyäsi aikaa tekemällä jotain esimerkiksi uuden kuvakkeen rakentamisen, on automatisoida tämä käytäntö seuraavalle henkilölle. Näin toimiessasi et ole vain tuonut arvoa omaan, vaan koko organisaation työhön. Noalle, käyttäytyminen = motivaatio * kyky * laukaista. Kun joku ryhmäsi laukaistaan ​​suorittamaan suunnittelun, voimme tehdä vain vähän heidän motivaationsa muuttamiseksi, mutta voimme tehdä niin paljon suunnittelujärjestelmien avulla heidän kykynsä parantamiseksi. Lopputuloksena on käyttäytyminen, joka tuottaa johdonmukaisemman ja todistetun suunnittelun paljon nopeammin.

2. Mikä on suunnittelujärjestelmä.

Karri Saarinen, Design Systems Lead @ Airbnb, antoi tämän määritelmän:

Joukko jaettuja, integroituja malleja ja periaatteita, jotka määrittelevät tuotteen yleisen suunnittelun

Jos sinulla on vähän kokemusta suunnittelujärjestelmistä, niin laaja määritelmä voidaan ymmärtää epäselväksi tai hyödyttömäksi. Yksityiskohtien puute on kuitenkin avainasemassa. Suunnittelujärjestelmät eivät vaadi tarkempaa määritelmää. He tarvitsevat huoneen olevan mikä tahansa, jota organisaatio vaatii suunnittelusta ja sen toteuttamisesta liikkua nopeasti rikkomatta asioita.

Mutta tässä on vähän lisätietoja suoraan mieheltä:

Selaa olemassa olevia suunnittelujärjestelmiä ymmärtääksesi paremmin, mitä ne ovat käytännössä. Tässä on materiaalisuunnittelu. Tämä on Mozillan pöytäkirja. Ja tässä on iOS-käyttöliittymän ohjeet, joita emme virallisesti kutsu nimeksi suunnittelujärjestelmäksi jokaisesta vivahteellisesta Apple-syystä, kuten miksi meidän ei pitäisi kutsua HomePodia älykkääksi puhujaksi. Kaikki nämä järjestelmät on rakennettu eri tavalla, mutta ymmärrä, kuinka ne kaikki mahtuvat Karrin määritelmän rajoihin.

Saatat ihmetellä, miksi luonnokseen yhdessä heittämiäsi komponentteja pidetään pelkästään ”kuvakirjastot”, “tyylioppaat” tai “käyttöliittymäpaketit”. Suunnitteluteknologi @ SurveyMonkey, Mike Dick, aloitti tosiasiallisesti yhdellä näistä käyttöliittymäpaketeista, kun hän ryhtyi komponentoimaan niiden elementtejä, mutta hän palasi piirustuslautaan, kun hän aloitti sen osoittamisen suunnittelulle. Sen sijaan, että rakentaisi komponenttijärjestelmää suunnittelijoille, Mike otti käyttöön yhden totuuden lähteen suunnittelulle integroitavaksi suunnitteluun. Tällä suunnittelujärjestelmällä rakennetut mallit voitaisiin helposti kääntää CSS: ään, kielellä, jota käytetään muotoilun määrittelemiseen, ja ne voisivat näin ollen nopeasti kaskadisoida muutoksia niiden etuosaan. Riittävien resurssien avulla suuret organisaatiot, kuten AirBnb, voivat toteuttaa työkaluja, jotka kääntävät suunnittelujärjestelmänsä kanssa rakennetut näytöt suoraan koodiksi (siksi Framer X on niin iso juttu).

Kun tarkastellaan Karrin määritelmää, näemme periaatteiden maininnan. Toisin sanoen suunnittelujärjestelmiin sisältyy sääntöjä ja ohjeita, jotka antavat käyttäjille tietoa järjestelmän sisällä organisoitujen kuvioiden ja tyylien toteuttamisesta. Materiaalisuunnittelun @ Googlen johtaja Rich Fulcher selitti miksi periaatteet olivat määrittelevä osa järjestelmää: koska suunnittelujärjestelmä on todella olemassa vain, jos sitä voidaan käyttää ilman luojaa.

3. Mikä tahansa suunnittelujärjestelmä on parempi kuin ei mitään suunnittelujärjestelmää.

Diana Mounter, GitHub

GitHubin suunnittelujärjestelmää Primerä uudistettiin sisäisesti ja yksityisesti. Diana totesi, että niin tekeminen johtui osittain siitä, että hänen tiiminsä kohtasi Imposterin oireyhtymää vertaamalla Primeria kypsyneiden ja suurempien organisaatioiden järjestelmiin, kuten AirBnb's DLS, Shopify's Polaris ja Yhdysvaltain Web Design System. Pohjustus tuntui kiillottamattomalta verrattuna. Monet komponentit olivat vanhentuneita.

Mutta tiedätkö mikä on pahempaa kuin tietäisi, että komponentti on vanhentunut? Et tiedä, ja ajaa tuon julmuuden tuotantoon.

Primer ja muut järjestelmät käyttävät lippuja nopeasti osoittaakseen, ovatko komponentit vanhentuneet vai eivät.

Siksi Diana sanoo, että sinun ei pitäisi huolehtia vertaamalla suunnittelujärjestelmääsi minkään muun organisaation järjestelmään, koska se ei ole mikä todistaa sen menestystä. Sen sijaan, Diana sanoo, työnnä suunnittelujärjestelmäsi ulos ja analysoi hyödyntämistä mittaamaan sen menestystä. Kaaos on luonnollinen osa jotain niin uutta käytännössä kuin suunnittelujärjestelmiä, joten keskity siihen, mikä on tärkeää, ja käytä kaaosta. Käytävätkö ihmiset suunnittelujärjestelmää työnkulussaan ja auttavatko sitä parantamaan sitä?

Ei ole epäilystäkään siitä, että Polarisin, iOS HIG: n ja materiaalisuunnittelun kaltaiset järjestelmät ovat uskomattoman perusteellisia ja jopa hienoja tarkastella. Näiden järjestelmien lisäksi, että yritykset ovat rakentaneet valtavia resursseja, ne on suunnattu erityisesti kolmansien osapuolien sidosryhmille, jotka eivät toimi niiden alla. Se tulee vain alueen kanssa.

Diana osoitti tämän hauskan vian. Ihannetapauksessa komponentit eivät estä esimerkillisen koodin luettavuutta.

Diana lopetti keskustelunsa twiitillä jakaaksesi Primeria maailman, puutteiden ja kaikkien kanssa. Tällä tavoin GitHubin järjestelmä antaa sidosryhmille: 1. Pääsyn resursseihinsa ja 2. Mahdollisuuksiin parantaa järjestelmän puutteita.

4. Kuinka aloittaa suunnittelujärjestelmä.

Ensimmäinen asia, jonka näet Shopify's Polarisissa.

Ensinnäkin, tarvitset pirteän nimen. Heti kun luet Polarisia, tiedät, että sinut johdattaan hyvin suunniteltuun pelastukseesi.

Kiusoittelen vain. Itse asiassa Materiaalisuunnittelu nimettiin virallisesti vasta kuukautta ennen julkaisemista. Rich Fulcher sanoi, että se tunnetaan sisäisesti nimellä "kvanttipaperi" suurimman osan ajasta.

Ja älä aloita myös Sketch-tiedostolla! Michael McCombie, järjestelmien suunnittelija @ Mozilla, teki virheen kerran. Heti kun hän sai mukaan muita sidosryhmiä, hänen piti aloittaa uudestaan. Suunnittelujärjestelmä on pala, joka ratkaisee käyttäjän ongelmat. Ymmärrä ensin ongelma ja käyttäjät.

Kun käyttäjäkokemuksen @ Glassdoor johtaja Jordan Girman päätti tehdä Glassoorsin ensimmäisen suunnittelujärjestelmän, hän sai ryhmän aloittamaan seuraavilla kysymyksillä:

  1. Mikä on tämän järjestelmän tarve?
  2. Kuinka suunnittelu toteutetaan nyt?
  3. Kuinka se tulisi panna täytäntöön?

Sieltä he asettavat suunnittelujärjestelmälleen tavoitteet ja vaatimukset, jotka ovat yhdenmukaisia ​​muun organisaation kanssa. Tämä suuntaus, kuten Mike Dick selitti, perustuu suhteeseen. Ilman suhdetta sidosryhmiisi, sinulla on edessään muutama haaste:

  • Kukaan ei puhu samaa kieltä. ”Tyyliopas” tarkoittaa insinööreille ja suunnittelijoille kahta eri asiaa. Kuinka tiedät, ymmärtävätkö kaikki terminologiat ja asiakirjat?
  • Kaikkien saavuttaminen suunnittelujärjestelmääsi on paljon vaikeampaa. Kansasi eivät ymmärrä sen arvon arvoa, jota he eivät auttaneet luomaan.
  • Kukaan ei tiedä, mikä totuuden lähde on. Suudella johdonmukaisuutta hyvästi.
Mitä insinööri ajattelee, kun sanot ”tyyliopas”

Erityisesti Mike suosittelee etsimään vastinetta, joka täydentää taitojasi yhteisellä intohimolla suunnittelusta ja suunnittelusta johtuvien aukkojen kuromiseksi. Jos et ole suuri koodaaja, hanki ystäviä jonkun kanssa, joka on loistava koodaaja ja jolla on syvällinen käsitys tekniikan pinoista. Tämä antoi Mikelle ymmärtää, että CSS: n dokumentointi sen sijaan, että järjestelmäkomponentit redlinkisoitaisiin, oli avainasemassa suunnittelussa järjestelmän parhaan hyödyntämisen kannalta.

Suosittelen, että etsit Mediumista resursseja siitä, mitä työkaluja käytetään ja kuinka käyttää niitä suunnittelujärjestelmäsi rakentamiseen. Et halua kuulla sitä minulta, koska aion vain sanoa jotain Figmasta.

5. Suunnittelujärjestelmät dokumentoivat kaiken.

Microsoftin sujuva dokumentointi radiopainikkeista.

Kun olet määrittänyt järjestelmäsi tavoitteet ja vaatimukset sidosryhmien kanssa, kattavan suunnittelun periaatteiden naulaaminen on hyvä tapa aloittaa. Suuret suunnitteluperiaatteet antavat sinun rakentaa järjestelmäsi johdonmukaisella tavalla, joka vastaa tavoitteitasi, ja ne voivat olla oikotie käyttäjän koko järjestelmän sujuvuuteen. Suosittelen jälleen tutustumaan Polariksen kaltaisiin olemassa oleviin, vankkoihin suunnittelujärjestelmiin löytääksesi parhaat esimerkit periaatteista käytännössä. Kun aloitat oman luomisen, Rich Fulcherilla ja sisästrategistolla @ Shopifellä Selene Hinkleyllä oli seuraavat asiat mielessä:

  • Monet eivät edes halua lukea periaatteita; Jos he lukevat, he voivat skannata. Jos he skannaavat, he eivät ehkä ymmärrä. Jos he eivät ymmärrä, he eivät varmasti ota yhteyttä. Joten ymmärrä yleisösi, kun luot kopioita ja sisältöä!
  • Ole opastava, ei määräävä. Jätä tilaa luovuudelle antamalla spektri siitä, mikä on hyväksyttävää. Periaatteiden tulisi olla opas päätöksenteossa.
  • Rajoita periaatteiden määrää. Shopify aloitti 13: lla, mutta heillä on nyt se kiehuvaksi 4. He poistivat ylhäältä alas- ja keskijohdon periaatteet, jotka eivät tehneet paljoa niille, jotka suunnittelivat ja toteuttivat mallin päivittäin. työ. Ruohonjuuritason periaatteet ovat kultaa.
  • Heijasta periaatteita luomassasi. Sellaiselle käyttäjätyypille, joka viittaa suunnittelujärjestelmään kontekstissa ja oppii esimerkin kautta, tämä tekee paljon syventääksesi periaatteesi ja pysyä johdonmukaisena.
  • He eivät voi rajoittaa tuotemerkkiäsi tai tuoteperiaatteitasi. Suunnittelujärjestelmien tulisi olla organisaatiosi alajärjestelmiä, joten varmista, että ne sopivat kokonaisuuteen.
  • Jatka periaatteiden kehittämistä. Käytä käyttäjäkeskeistä suunnittelua periaatteidesi luomiseen, jotta ne heijastavat järjestelmääsi ja todellisuuttasi tarkasti. Muutoin johdonmukaisuus hajoaa, kun muut käyttäjät soveltavat periaatteitasi.

Lisää sitten sieltä suunnittelujärjestelmän komponentit ja dokumentoi niiden erityiset periaatteet. Asiat etenevät paljon nopeammin, avuttomat joukkuetoverit eivät tee sinulle virhettä, ja nimesi ei kirota, kun et ole ympäri. Selene: n on sanottava seuraava suunnittelujärjestelmäsi dokumentoinnista:

  • Jakaa kappaleet luetteloiksi ja luetteloiksi.
  • Käytä visuaalisia esimerkkejä aina kun mahdollista.
  • Pidä lauseet lyhyinä ja toimivina.
  • Käytä dos / älä.
  • Tee älä niin selväksi. Malline heitä realististen virheiden jälkeen, jotka voivat johtua vääristä tulkinnoista
Lähde: material.io

6. Suunnittelujärjestelmien on integroitava saavutettavuus.

Tutustu tähän työkaluun tarkistaaksesi käytettävissä olevat kontrastisuhteet WebAIMissa.

John Cassidy, vanhempi suunnittelija @ Google, aloitti keskustelunsa rasvalla tilalla:

Joka seitsemäs henkilö on vammainen. Se on yli miljardi ihmistä.

Johnilla oli silti enemmän sanottavaa. Käyttäjä poistetaan käytöstä heti, kun heidän kätensä ovat täynnä päivittäistavaroita. Jos he matkustavat vieraassa maassa, jolla ei ole paikallista kielitaitoa, he ovat vammaisia. Jos asut tarpeeksi kauan, joudut todennäköisesti pysyvästi poistumaan yhdestä päivästä.

Jos olet vielä vakuuttunut, Johnilla on nämä neuvoja esteettömyyden lisäämiseksi suunnittelujärjestelmään.

  • Käytä esteettömiä suunnittelurajoituksia. Varmista, että komponentit vastaavat pääsyä tarvitsevia tilanteita, kuten kaukonäköisyyden koon mukaista tyyppiä ja näytönlukijalle alt-tekstiä. Älä unohda väliaikaista vammaisuutta; entä jos kuljettajat käyttävät tuotteitasi kirkkaassa päivänvalossa?
  • Tutustu käyttäjien käytettävissä olevaan esteettömystekniikkaan. OS-tekniikka, kuten iOS Magnifier ja Windows Narrator, ovat eniten saatavissa, mutta myös lisätuotteita, kuten Xbox Adaptive Controller, on olemassa. Ja jotkut tekniikat eivät ole rajoitettuja käyttämään vammaisia ​​käyttäjiä, etenkin ääni-avustajia.
  • Testaa komponenttejasi päällä olevilla esteettömyystekniikoilla. Aika yksinkertainen. Ota käyttöön tekniikat, kuten iOS VoiceOver, ja varmista, että ne toimivat järjestelmäkomponenttien kanssa hyödyllisellä tavalla.
  • Testaa tuotteitasi vammaisten käyttäjien kanssa. Tietenkin, sinun täytyy tuoda tuotteesi käyttäjien eteen, joilla on erilaisia ​​psyykkisiä, fyysisiä ja tilannehäiriöitä.
Microsoftin Xbox Adaptive Controller on yksi uusimmista käyttäjien tavoitettavuustekniikoista.

7. Väri ja piirrokset voivat olla ja niiden tulee olla systemaattisia.

Shopifen Polaris-värivalikoima

Organisaatiollasi voi olla jo brändivärit, jotka olisivat käteviä käyttöliittymän täyttämisessä, mutta eivät niin nopeasti. Älä valitse käyttöliittymävärejä kopioimalla liittämällä tuotemerkkisi värit. Brändivärit eivät ota huomioon käytettävyyttä, vaikka perusvärien johtaminen tuotemerkistäsi on todennäköisesti paras tapa aloittaa. Suunnittelupäällikkö @ Lyft, Linda Dong, suosittelee luomaan brändivärien spektriä päällekkäisellä tekstillä asettumaan käyttöliittymävärille, joka tyydyttää saavutettavissa olevat värisuhteet. Tietysti testaa tämä kaikki tilanteissa, joissa tuotteesi käytetään. Lyftin täytyy työskennellä kuljettajien kanssa kuollut yöllä ja kirkkaimpana päivänä.

Kun asetat väreihisi, älä viitata suunnittelujärjestelmässäsi oleviin väreihin heidän heksadestaan ​​tai "viralliseen" nimeensä. Linda huomautti tämän hauskasti värien nimeämiskilpailulla. Osoittautuu, että kyyhky on keskiharmaa. Soita minulle hienostumattomana, mutta mielestäni pidgeon on mitä etsit.

Määritä sen sijaan värimaailma värimerkkeillä. Michael McCombie ja Protocol -järjestelmä käyttävät perusvärinimiä, kuten $ väri-punainen, kun taas Linda ja Lyft käyttävät $ ColorName-Value -muotoa värispektriensä vuoksi. Ota tietysti mukaan kaikki sidosryhmät, kun rakennat värijärjestelmääsi - ja mainosta sitä, kun se on valmis - varmistaaksesi käyttöönoton.

Jennifer Hom, Illustration @ Airbnb: n kokemussuunnittelupäällikkö, tuli laivalle uudistamaan kuvajärjestelmäänsä. Aikaisemmin Airbnb oli jakanut kokoja eri kokoille tai eri kokoja eri kuville. Jennifer muutti kuvituksia systemaattisesti lisääntyneiksi vektoreiden painoiksi ja yksityiskohdiksi vientikokojen kasvaessa (1x, 2x, 3x), mikä mahdollisti johdonmukaisen, mutta alustalle sopivan suunnittelun laitteiden välillä.

Jenniferillä oli myös nämä periaatteet huomioitava piirustusjärjestelmässäsi:

  • Varmista, että kuvasi ovat maadoitettuja. Kuvien tulisi antaa useimpien, ellei kaikkien, mahdollisuus suhtautua tuotteeseesi ja ajattelematta pienimuotoista.
  • Älä anna kuvasi ottaa huomion. Niiden tulisi lisätä iloa kiinnittämättä käyttäjää häiritsemään tavoitetta.
  • Käytä saatavilla olevia värejä. Tarkista värisuhteesi!
  • Ole monipuolinen, mutta realistinen. Airbnb: n piirustukset perustuvat todellisiin ihmisiin, joten he “esittelevät” Donald Gloverin ja Jenniferin satunnaisia ​​Facebook-ystäviä. Airbnb puhui myös vammaisten organisaatioiden ja viranomaisten kanssa, mikä antoi heille ajatuksen käyttää hienovaraista vihjettä, kuten kuulokkeita.
  • Testaa kuviasi. Voi mies, voitko uskoa siihen? Tämä malli on myös testattava. Kiinakohtaisten kuvien näyttäminen Pekingin toimistolle antoi Jenniferille selville, etteivät suuret rinnassa olevat kiinalaiset urokset ole kovin luotettavat.

8. Kuinka suunnitella mittakaava.

Karri Saarinen: Kuinka suunnittelujärjestelmä kehittyy mittakaavassa.

Mikä tuo on? Yrityksesi ilmoitti juuri sarjan C! Kolmen kuukauden kuluessa sinulta odotetaan olevan täydellinen sovelluskokoelma jokaisella alustalla ja Not-Yous-tiimi joka hallinnoi kaikkia.

Älä pelkää. Toiset ovat päässeet toiselle puolelle. Näin Karri luulee voit skaalata suunnittelujärjestelmääsi:

  • Käytä määriteltyjä alukkeita. Määritä värimaailmat, tekstityylit, ruudukot jne., Jotka ovat rakennuspalikoita jokaiselle suunnittelujärjestelmän lisäykselle. Kaikki Airbnb: n ydinkomponentit ja ryhmäkohtaiset kirjastot on rakennettu samoilla alukkeilla.
  • Rakenna komponentit noiden primitiivien avulla ja rakenna mallisi näiden komponenttien kanssa. Tämä varmistaa johdonmukaisuuden samalla kun sallitaan tietty joustavuus ja muokattavuus.
  • Pysy joustavana. Tarvitset joustavuutta etäisyyksien, tekstin leikkaamisen, eri tekstikokojen saavutettavuuden ja kansainvälistymisen mahdollistamiseksi, eri värivalintojen, mukautettujen komponenttien ja hyvän olosuhteiden luovuuden.
  • Tee suunnittelustiedot alusta-agnostisiksi. DLS määrittelee niiden komponentit JSON: ssä, joka on yleinen tietostandardi, joka mahdollistaa automaattisen kääntämisen alustakohtaisiin tyyleihin, kuten CSS.
  • Lisää joukkuekohtaiset kirjastot, mutta pidä ne hallinnassa. Airbnb rajoittaa joukkuekirjastonsa kokeellisiin ja erityisiin komponentteihin. Joten ryhmäkirjastoja seurataan ja komponentit lähetetään ketjuun, jos ne ovat sopivia ydinkomponentteja. 70 komponenttia on 60% Airbnb: n käyttöliittymästä kaikilla alustoilla!

Suuri kiitos uskomattomille puhujille: Diana Mounter, Noah Levin, Karri Saarinen, Rich Fulcher, Michael McCombie, Linda Dong, John Cassidy, Jennifer Hom, Selene Hinkley ja Jordan Girman. Ja kiitos Julie Stanesculle (yhdessä hänen ryhmänsä kanssa Rethinkissä) ja SF Design Weekille heidän mahtavista keskusteluistaan!

Viimeiseksi kiitos Jasmine Rosenille ja Jodee Cherneylle editoinnista ja muille Tradecraft-yrityksille jatkuvasta tuestaan ​​ja Tyler Heuckelle siitä, että olen ”suunnittelukumppanini”.