Ihmisten puolesta, ihmisille: Pidät suunnittelujärjestelmäsi ikivihreä

Tämä viesti on kolmas sarjassa HubSpot Canvasista, uudesta suunnittelukielestämme. Lue ensimmäinen täältä ja toinen täältä.

Joka tammikuussa miljoonat ihmiset päättävät, että tämä on vuosi, jonka heidän elämänsä tulee olemaan erilainen. Luet lisää kirjoja. Laitat enemmän rahaa säästöihin. Syötte vähemmän Cool Cool Ranch Doritoja ja pintteja Ben & Jerry'sistä. Ja sinä kuntosali. Joka. Päivä.

Mutta useimmiten heti, kun helmikuu kiertää, yöpöydälläsi on pino lukemattomia kirjoja. Säästösi rahoitetaan rutiininomaisesti Tacon tiistaina. Ja sohvallasi on peittävä hieno kerros Dorito-pölyä.

Miksi? Koska hyvät aikomukset eivät riitä. Ellet muuta elämäntapaa, edes parhaan mahdollisen ratkaisun ratkaisu ei vain tartu.

Sama pätee suunnittelujärjestelmiin. Kun suunnittelet tuotetta uudelleen, järjestelmät, jotka aiheuttivat tuotteen tyylioppaan stagnaation (tai johtivat ryhmääsi luomaan 6 erilaista pääpainiketta), ovat todennäköisesti edelleen olemassa. Ja ilman todellista elämäntavan muutosta päädyt todennäköisesti sinne, mihin aloitit.

Siksi uuden suunnittelujärjestelmäsi tärkein osa ei ole kaunis uusi väripaletti tai edes työkalut, jotka olet asettanut suunnittelujärjestelmän käyttämiseen vaivattomasti - se on tapa, jolla joukkueesi vuorovaikutuksessa järjestelmän kanssa jatkuvasti.

Emme halunneet uuden mallijärjestelmämme, HubSpot Canvas, seurata vanhan tyyli-oppaamme jaksoja, jotka päätyivät vanhentuneiksi ja sivuutetaan. Halusimme sen olevan kasvava, muuttuva, elävä asia. Tarvitsimme elämäntavan muutosta. Ja pääsimme sinne vain tarkistamalla suunnitteluprosessiamme.

Ihmisten toimesta - järjestelmän tulee olla kaikkien omistama

Prosessilla on joskus huono maine. Ja se on totta - prosessi prosessin vuoksi voi olla parhaimmillaan tehoton ja pahimmassa tapauksessa turhauttava.

Mutta oikea prosessi poistaa kitkan. Se nopeuttaa päätöksentekoa, tekee roolista ja vastuusta kristallinkirkas ja saa kaikki samalla sivulla. Suunnitellessamme miten hallita suunnittelukieliämme HubSpot Canvasia, halusimme luoda prosessin, jolla saavutetaan kaikki nämä asiat. Tiesimme, että jos uusi prosessimme menestyy, sen on oltava kevyt ja sitä käyttävien ihmisten yhteisomistuksessa.

Ei ole epäilystäkään siitä, että suunnittelujärjestelmän rakentaminen ja ylläpitäminen voi olla kokopäiväinen työ. Mutta olemme havainneet, että tämän työn levittäminen kiertävän suunnittelijaryhmän välillä toimii parhaiten. On itsestään selvää, että suunnittelijat, jotka työskentelevät päivittäin tuotteemme parissa, ymmärtävät käyttäjiämme ja jotka on koulutettu kuinka priorisoida työtä ja jatkaa ratkaisujen tekemistä, tekevät prosessin parhaista paimenista.

Kuuden kuukauden välein neljän suunnittelijan ryhmä vuorottelee ja ottaa erityiset roolit ja vastuut Canvas-tiimissä. Hyödyt ovat kaksi - ne eivät vain paranna järjestelmää suoraan joukkueessa ollessaan, mutta heillä on myös syvä käsitys siitä, miten voimme myötävaikuttaa siihen, kun rotaationsa on ohi. Tavoitteenamme on, että jokainen HubSpot-tuotesuunnittelija tekee lopulta kiertueen Canvas-tiimissä.

Suunnittelukielellä työskentelevät suunnittelijat tekevät niin "päivätyöhönsä" lisäksi. Olemme havainneet, että tämä toimii hyvin, koska nyt kun kaikki tärkeimmät kankaalle on luotu, suunnittelukielen ylläpitäminen on paljon vähemmän vaativa.

Tämän joukkueen suunnittelijoiden on silti:

  • Mestari HubSpot Canvas -muotoilukieltä
  • Ole perehtynyt nykyisiin asiakirjoihin ja päätöksiin, jotta he voivat helposti vastata kysymyksiin ja tunnistaa epäjohdonmukaisuudet
  • Tunnista edelleen tapoja parantaa prosessia ja dokumentaatiota
  • Päivitä Sketch UI Kit viikoittain ja lähetä sähköpostiviesti yksityiskohtaisesti päivitykset suunnittelijoille ja käyttöliittymäkehittäjille
  • Triage saapuvat kysymykset ja helpottaa keskustelua ja päätöksiä viikoittaisissa tarkistuskokouksissamme
  • Ota proaktiivisesti yhteyttä koko ryhmän suunnittelijoihin auttaaksesi dokumentoimaan tapauksia, variantteja ja malleja
  • Tee yhteistyötä Frontend-as-a-Service-tiimimme kanssa vastataksesi kysymyksiin ja auttaaksemme varmistamaan, että komponentit vaihdetaan tai rakennetaan oikein.

Kuinka laskusta tulee lakia

Suunnittelujärjestelmän ikivihreä pitäminen vaatii suunnittelijoiden ja kehittäjien tiivistä yhteistyötä. Joten tehokkaan yhteistyön helpottamiseksi päätimme rakentaa prosessimme sinne, missä suunnittelujärjestelmäämme koskevat keskustelut ja päätökset olivat jo tapahtumassa - Githubiin.

Tämä tekee Githubista ainoan totuuden lähteen kankaalle. Niin…

  • Jos insinöörin on tiedettävä, onko suunnittelutiimi hyväksynyt osan? Se on Githubissa.
  • Jos suunnittelijan on tiedettävä, onko komponentti vielä rakennettu? Se on Githubissa.
  • Jos ryhmän on keskusteltava siitä, pitäisikö komponenttia olla olemassa? Arvasit sen - teemme sen Githubissa.

Vaihe 1: Tarvitsemme uuden komponentin tai muokkauksen olemassa olevaan komponenttiin.

Kuka tahansa voi lähettää käyttöliittymäkirjastoomme Github-lehden tiimille tarkistettavaksi. Nämä asiat kertovat, kuinka suunnittelija saa pallon liikkumaan Canvas-joukkueen kanssa.

Pyydämme useita yksityiskohtia alkuperäisessä Github-numerossa. Olemme oppineet ajan myötä (ja kommunikoineet laajasti), että asiat sujuvat sujuvammin, kun lähettäjä on pohtinut yksityiskohtia ja käyttänyt komponentin tapauksia perusteellisesti. Tämä ei ole paikka yleisille ideoille tai tuleville parannuksille (nämä keskustelut tapahtuvat usein Slackin kautta tai offline-tilassa suunnittelijoiden välillä) - kyse on komponentista, joka on valmis tarkistamaan ja rakentamaan.

Sitten se lisätään jonoon:

Vaihe 2: Canvas-joukkue koettelee asiat.

Tämä prosessi on kehittynyt ajan myötä, mutta tavoitteemme on pysynyt samana. Varmistaaksemme, että mikään ei liuku halkeamien läpi, huomasimme, että jokainen kysymys tarvitsee jonkun, joka vastaa sen paimentamisesta tämän prosessin kautta.

Sen sijaan, että suunnittelimme hienostuneen mallin työn jakamiseksi tai jakamiseksi tasaisesti, päädyimme joka viikko yksinkertaiseen vapaaehtoistyöhön. Sovitimme asiaan parista syystä. Ensinnäkin, joillakin ihmisillä on vain enemmän kiinnostusta tai asiantuntemusta tietyistä aiheista. Ja toiseksi, työmäärät tämän ryhmän ulkopuolella vaihtelevat - joskus tietyt ryhmän ihmiset ovat kiireisiä, toisinaan eivät. Tällä tavalla joukkue voi reagoida työskentelyyn joustavasti, luottamalla toisiinsa tarttumaan löysyyteen. Se ei ole täydellinen; Joskus meidän on määritettävä asiat uudelleen tai tehtävä pieniä muutoksia. Mutta se sopii yleiseen työskentelytyyliimme HubSpotissa, eikä se ole vielä epäonnistanut meitä.

Vaihe 3: Asiat tarkistetaan.

Korkealla tasolla tarkistusprosessi heijastaa yleistä suunnitteluprosessiamme (mutta pienemmässä mittakaavassa):

  1. Ymmärrä ongelma
  2. Selvitä, ketkä ongelmaan vaikuttavat
  3. Keskustele ja tee yhteistyötä tiimien kanssa, joita asia koskee
  4. Valmistele, muokkaa ja hio komponenttisuunnittelua
  5. Katsaus Canvas-tiimin kanssa

Pyrimme siihen, että tämä prosessi kestää viikon, mutta jotkut asiat vievät minuutteja ja toiset voivat kestää viikkoja komponentin laajuudesta ja sen riippuvuuksista riippuen.

Vaihe 4+: Se riippuu.

Komponenttikatsauksessa voi esiintyä muutama skenaario:

  • Suunnittelu komponenteille, joita käytetään laajasti. Frontend-palveluna -tiimillemme on järkevin rakentaa ja toteuttaa nämä komponentit, koska niitä käytetään koko tuotteessa.
  • Suunnittelu komponenteille, joiden käyttö on kapeampaa. Usein, jos yksi ryhmä tarvitsee eniten komponenttia, he rakentavat sen uudelleenkäytettävällä tavalla ja lisäävät sen sitten käyttöliittymäkirjastoomme.
  • Suunnittelu komponenteille, joiden ei tarvitse olla uudelleenkäytettäviä. Joskus komponentit ovat niin kapea-alaisia, että ei ole syytä, että toisen joukkueen olisi käytettävä sitä. Tässä tapauksessa komponentti tarkistetaan sen varmistamiseksi, että se sopii muuhun järjestelmään, ja sitten joukkue rakentaa sen sovellukseensa. Jos siitä tulee tulevaisuudessa uudelleenkäytettävää komponenttia, ryhmät voivat sitten lisätä sen käyttöliittymäkirjastoon.

Jos nämä ongelmat johtavat siihen, että jotain on tarpeen muuttaa tai lisätä Sketch UI Kit -sivustomme, se saa erityisen tunnisteen tulevan julkaisun nimellä. Tämän avulla UI-pakettia kuratoivien suunnittelijoiden on helppo nähdä kaikki, joihin on puututtava.

On myös muutamia syitä, miksi joukkue voi hylätä komponenttipyynnön:

  • Suunnittelu komponenteille, joita pidämme tarpeettomina. Tiimiin tulee aina sisällyttämään harkittu syy siihen, miksi komponentista ei pitäisi tulla standardia tai miksi se ei sovi ohjeisiin. Tarvittaessa tarjotaan muita ratkaisuja tai huomioita.
  • Suunnittelu komponenteille, jotka tarvitsevat lisätietoja. Joskus suunnittelijoiden on palattava piirtotaululle selvittääksesi lisätietoja ennen kuin komponentti on valmis ennätysaikaan.

Ihmisille - järjestelmän pitäisi auttaa sinua

Halusimme, että kangas olisi niin helppo käyttää, että suunnittelijamme eivät koskaan uneksisi käyttämästä jotain muuta. Joten esimerkiksi sen sijaan, että käyttäisimme vain numeroita UI Kit -versioiden merkitsemiseen, aloimme nimetä jokaisen version aakkosjärjestyksessä kuuluisten räppärien jälkeen. Paitsi, että saimme hauskoja tosiasioita ja upeita soittolistoja, se myös teki eri versioiden muistamisen ja niistä puhumisen paljon helpommaksi (yllättävää, että Jam Master Jay ja Kris Kross on paljon helpompi muistaa kuin v1, v22 tai v100). Kun olemme tehneet sen aakkosten kautta, aloimme työskennellä As Seen -sovelluksen kautta TV-tuotteissa.

Paljon kiitoksia Hot Stamps -yritykselle, joka opetti meille, että kaikki mitä tarvitset vakuuttamaan ystäväsi on hiukan kimalteleva.

Haluamme paljon jatkuvaa arviointia ja parantamista prosessiamme helpottaaksesi kaikkien suunnittelutiimin jäsenten elämää. Muutamia esimerkkejä haasteista, jotka olemme ratkaisseet ajan myötä, ovat:

Näkyvyys siihen, mikä muuttuu.

Alkuaikoina ryhmän suunnittelijoilla oli vaikeuksia tietää, mikä muuttui, elleivät he olleet kankaalle-joukkueessa. Joten aloimme sähköpostin lähettämisen aina, kun julkaisemme uuden Sketch UI -sarjan. Nämä sähköpostit auttavat meitä päivittämään tiimin selvästi ja johdonmukaisesti jokaisessa versiossa uutta ja erilaista, ja tarjoavat suunnittelijoille helpon paikan ladata uusi pakkaus. Jokainen käyttöliittymäpaketti sisältää myös muutoslokin Sketch-tiedoston ensimmäisellä sivulla.

Vastaava koodi käyttöliittymän kirjastossa Sketch-käyttöliittymäpaketin omaisuuden suunnitteluun.

Alussa meillä oli paljain luomalla luonnospaketti, joka luetteloi tarvitsemme eri komponentit, ja käyttöliittymäkomponenttikirjasto, jota kehittäjät voivat käyttää ja käyttää, mutta ne eivät aina vastanneet toisiaan. Tämä jako johti sopimattomaan kieleen suunnittelijoiden ja kehittäjien välillä. Joten suunnittelijoiden ja kehittäjien yhteisomistuksen viljelyä varten aloitimme suuren projektin, joka vastaa käyttöliittymäkirjaston ja Sketch UI Kit -sovelluksen navigointi- ja nimeämiskäytäntöjä.

Ajattelu perinteisten komponenttien ulkopuolelle.

Kuvitukset, sivuasettelut, tyhjät tilat, virhetilat - nimeät sen. Jos objektin uudelleenkäyttö luo vipuvaikutusta, on syytä tehdä siitä komponentti tai lisäosa. Frontend-as-a-service-tiimimme on myös tehnyt erittäin helpoksi tuoteryhmien insinöörien toimittaa komponentit tai lisäosat itse järjestelmään. Olemme myös alkaneet dokumentoida UX-malleja (ei vain "mitä komponenttia minun pitäisi käyttää?", Vaan "kuinka minun pitäisi käyttää sitä?").

Mutta emme todellakaan ole vahvistaneet kaikkea. Joitakin haasteita, joita yritämme edelleen ratkaista ja joita olemme iteraineet, ovat muun muassa:

Prioriteetin asettaminen ja näyttäminen tehokkaasti.

Kun aloimme siirtää prosessiamme Githubiin, toimitimme tunnisteet, joiden avulla käyttäjät voivat valita pyyntönsä prioriteetin asteikolla P1 - P3 (P1 tarkoitti "meidän on tehtävä tämä eilen" ja P3 tarkoittaa "päästämme tähän jonain päivänä"). Mutta koska joukkueemme liikkuu niin nopeasti, melkein kaikki päätyi P1-luokkaan.

Mutta emme myöskään voi tehdä kaikkea - meidän on tasapainotettava yli 40-joukkueiden prioriteetit, ja meillä on ollut joitain ongelmia halkeamien läpi. Harkitsemme, kuinka priorisoimme asiat tänään, jotta voimme ratkaista sekä komponentteja rakentavan joukkueen että niitä odottavien ryhmien kanssa.

Ei omaa suunnitteluresurssia.

Haluamme kaikkien ryhmän suunnittelijoiden tekevän vuorottelun, mutta heidän päävastuunsa ovat edelleen heidän tuotetiiminsä. Tämä tarkoittaa, että meidän on oltava raaputtavia ja kekseliäitä, kun on kyse työn saamisesta ajoissa. Saatamme harkita rotaatiotiimin täydentämistä suunnittelijalla, joka keskittyy tulevaisuudessa kokoaikaiseen järjestelmään.

Luotamme järjestelmäämme

Meillä on kultainen sääntö täällä HubSpotissa osana kulttuurikoodiamme: Käytä hyvää harkintaa. Se johtuu luottamuksen ja vastuun muista kulttuureista. Rakensimme periaatteemme, ohjeemme ja prosessimme luottamuksen kallioperälle varmistaaksemme, että suunnittelujärjestelmämme kestää, koska järjestelmä toimii vain, jos ihmiset luottavat siihen.

Loimme luottamuksen tekemällä helpoksi ymmärtää miten päätöksiä tehdään ja miten vaikuttaa, jos joku haluaa auttaa tai on eri mieltä päätöksestä. Keräämme palautetta määräajoin ja suunnittelemme parannuksia. Löydämme tapoja ihmisille, jotka välittävät siitä tai käyttävät sitä paljon osallistuakseen. Ja dokumentoimme niin paljon kuin pystymme siitä, miksi päätöksiä tehtiin, jotta kuka tahansa voi nähdä ne ja palata niihin.

Päivän lopussa suunnittelukielen ylläpitämisen helppous ei ollut vain hyvä suunnittelijoille ja kehittäjille - se oli hyvä käyttäjillemme. Tuotteemme uudelleensuunnittelu Canvasilla oli iso muutos, mutta tavoitteemme oli rakentaa järjestelmä ja prosessi niin vahva, että meidän ei koskaan tarvitsisi suunnitella tuotteemme uudelleen.

Koko tällä järjestelmällä luodun perustan avulla voimme tehdä pienempiä muutoksia tuotteeseemme ajan myötä. Uusi pääväri? Tehty. Pyöristetyt kulmat eivät ole enää viileitä? Mennyt. Käyttäjillä on vaikeuksia selvittää, kuinka edetä ohjatun toiminnon yhteydessä? Tutkimme ja korjaamme sen ilman sovelluksen koko UI-tarkastusta.

Luomalla vahvan suunnittelujärjestelmän ja vahvan prosessin sen tukemiseksi, voimme tukea harkittuja tuotekehitysprosesseja - ilman tukkuvallankumouksen taakkaa. Se on järjestelmä, joka toimii.

Laajuus:
Kuvia Sue Yee.

Alun perin julkaistu HubSpot-tuoteblogissa.