Af folket, for folket: Hold dit designsystem stedsegrøn

Dette indlæg er det tredje i en serie om HubSpot Canvas, vores nye designsprog. Læs det første her og det andet her.

Hver januar beslutter millioner af mennesker, at dette er året, deres liv vil være anderledes. Du læser flere bøger. Du lægger flere penge i besparelser. Du spiser færre Cool Ranch Doritos og pints af Ben & Jerry's. Og du vil træne. Hver. Dag.

Men oftere end ikke, så snart februar ruller rundt, er der en stak ulæste bøger på dit natbord. Dine besparelser vil rutinemæssigt finansiere din Taco tirsdag vane. Og der er et fint lag af Dorito-støv, der dækker din sofa.

Hvorfor? Fordi gode intentioner ikke er nok. Medmindre du foretager en livsstilsændring, vil selv den bedst hensigtsmæssige opløsning bare ikke holde sig.

Det samme er tilfældet med designsystemer. Når du redesigner dit produkt, er de systemer, der fik dit produkts stilguide til at stagnere (eller førte til, at dit team oprettede 6 forskellige primære knapper) stadig omkring. Og uden en ægte livsstilsændring vil du sandsynligvis ende lige, hvor du startede.

Derfor er den vigtigste del af dit nye designsystem ikke din smukke nye farvepalet eller endda de værktøjer, du sætter på plads til at gøre brug af dit designsystem ubesværet - det er den måde dit team interagerer med systemet løbende.

Vi ønskede ikke, at vores nye designsystem, HubSpot Canvas, skulle følge i vores gamle stilguider, som endte uaktuelle og ignorerede. Vi ønskede, at det skulle være en voksende, skiftende, levende ting. Vi havde brug for en livsstilsændring. Og vi kom kun dertil ved at gennemgå vores designproces.

Af befolkningen - dit system skal ejes af alle

Process får undertiden et dårligt ry. Og det er sandt - proces for processens skyld kan være ineffektiv i bedste fald og frustrerende i værste fald.

Men den rigtige proces fjerner friktion. Det fremskynder beslutningstagningen, gør roller og ansvar krystalklar og får alle på samme side. Ved at finde ud af, hvordan vi styrer HubSpot Canvas, vores designsprog, ønskede vi at skabe en proces, der opnår alle disse ting. Vi vidste, at hvis vores nye proces ville få succes, ville den være let og medejet af de mennesker, der brugte den hver dag.

Der er ingen tvivl om, at opbygning og vedligeholdelse af et designsystem kan være et fuldtidsjob. Men vi har fundet ud af, at det at arbejde med at sprede dette job over en roterende gruppe designere fungerer bedst. Det er grunden til, at de designere, der arbejder med vores produkt hver dag, som forstår vores brugere, og som er trænet i, hvordan man prioriterer arbejde og itererer med løsninger, gør de bedste hyrder til denne proces.

Hver 6. måned roterer en gruppe på fire designere ind og påtager sig specifikke roller og ansvar på Canvas-teamet. Fordelene er todelt - ikke kun vil de direkte forbedre systemet, mens de er på teamet, men de vil have en dyb forståelse af, hvordan de kan bidrage til det, når deres rotation er forbi. Vores mål er at have enhver produktdesigner hos HubSpot til sidst på en turné på pligt på Canvas-teamet.

Designerne, der arbejder på vores designsprog, gør det ud over deres “dagjob”. Vi har fundet, at dette fungerer godt, for nu som alle de store stykker lærred er blevet oprettet, er opgaven med at bevare designsproget meget mindre krævende.

Stadig skal designere på dette team:

  • Champion HubSpot Canvas designsprog
  • Vær velbevandret i den hidtidige dokumentation og beslutninger, så de let kan besvare spørgsmål og identificere uoverensstemmelser
  • Fortsæt med at identificere måder at forbedre processen og dokumentationen på
  • Opdater Sketch UI Kit ugentligt, og send en e-mail med detaljer om opdateringerne til designere og front-end-udviklere
  • Triage indgående spørgsmål og lette diskussion og beslutninger i vores ugentlige gennemgangsmøder
  • Nå ud til designere i hele teamet for at hjælpe med at dokumentere brug af sager, varianter og mønstre
  • Arbejd med vores Frontend-as-a-Service-team for at besvare spørgsmål og hjælpe med at sikre, at komponenter ændres eller bygges korrekt.

Hvordan et lovforslag bliver en lov

At holde et designsystem stedsegrønt kræver et tæt samarbejde mellem designere og udviklere. Så for at lette effektivt samarbejde besluttede vi at opbygge vores proces, hvor samtalerne og beslutningerne om vores designsystem allerede foregik - i Github.

Dette gør Github til vores eneste sandhedskilde for lærred. Så…

  • Hvis en ingeniør har brug for at vide, om en komponent er godkendt af designteamet? Det er i Github.
  • Hvis en designer har brug for at vide, om en komponent endnu er bygget? Det er i Github.
  • Hvis holdet har brug for at diskutere, om en komponent overhovedet skal eksistere? Du gættede det - vi gør det i Github.

Trin 1: Vi har brug for en ny komponent eller en redigering af en eksisterende komponent.

Fra vores UI-bibliotek kan enhver indsende et Github-spørgsmål til teamet til gennemgang. Disse problemer er, hvordan en designer får bolden til at rulle med Canvas-teamet.

Vi beder om en række detaljer i den indledende Github-udgave. Vi har lært over tid (og kommunikeret bredt), at ting bevæger sig mere glat, når indsenderen har overvejet detaljerne og bruger sager til en komponent grundigt. Dette er ikke stedet for generelle ideer eller fremtidige forbedringer (disse samtaler sker ofte over Slack eller offline mellem designere) - det er for en komponent, der er klar til at blive revideret og bygget.

Derefter tilføjes det til vores kø:

Trin 2: Problemerne bliver triagtet af Canvas-teamet.

Denne proces har udviklet sig over tid, men vores mål er forblevet den samme. For at sikre, at intet glider gennem revnerne, indså vi, at hvert emne har brug for nogen, der er ansvarlig for at hyrde det igennem denne proces.

I stedet for at udtænke en sofistikeret model til, hvordan man opdeler eller fordeler arbejdet jævnt, endte vi med et simpelt frivilligt triagesystem hver uge. Vi afgjorde dette af et par grunde. For det første har nogle mennesker bare mere interesse eller ekspertise inden for bestemte emner. Og for det andet svækker arbejdsmængder uden for dette team - nogle gange er visse mennesker på holdet travlt, og nogle gange er de ikke det. På denne måde kan teamet reagere på at arbejde på en elastisk måde og stole på hinanden for at afhente slakken. Det er ikke perfekt; undertiden er vi nødt til at overdrage problemer eller foretage små ændringer. Men det passer til vores generelle arbejdsstil hos HubSpot, og det har endnu ikke svigtet os.

Trin 3: Problemerne gennemgås.

På et højt niveau afspejler gennemgangsprocessen vores overordnede designproces (men i mindre skala):

  1. Forstå problemet
  2. Bestem, hvem der er berørt af problemet
  3. Chat og samarbejd med hold, der er berørt
  4. Udform, rediger og finpudse komponentdesignet
  5. Gennemgå med Canvas-teamet

Vi sigter mod, at denne proces tager en uge, men nogle problemer tager minutter, og nogle kan tage uger afhængigt af omfanget af komponenten og dens afhængigheder.

Trin 4+: Det afhænger.

Der er et par scenarier, der kan komme ud af komponentgennemgangen:

  • Design til komponenter med bred anvendelse. Det giver mest mening for vores Frontend-as-a-Service-team at bygge og implementere disse komponenter, da de vil blive brugt på tværs af produktet.
  • Design til komponenter med mere snæver brug. Hvis det ofte er et enkelt team, der har brug for en komponent mest, bygger de det på en genanvendelig måde, og tilføj det derefter til vores UI-bibliotek.
  • Design til komponenter, der ikke behøver at kunne genbruges. Nogle gange er komponenter så smalle i omfang, at der ikke er nogen grund til, at et andet team skal bruge det. I dette tilfælde gennemgås komponenten for at sikre, at den passer til resten af ​​systemet, og derefter bygger teamet det ind i deres app. Hvis det på et tidspunkt i fremtiden skal blive en genanvendelig komponent, kan hold derefter føje det til UI-biblioteket.

Hvis disse problemer resulterer i, at noget skal ændres eller tilføjes i vores Sketch UI Kit, modtager det et specielt tag med navnet på den kommende udgivelse. Dette gør det lettere for designerne, der sammenlægger UI Kit, at se alt, hvad der skal løses.

Der er også et par grunde til, at teamet muligvis afviser en anmodning om komponent:

  • Design til komponenter, som vi finder unødvendige. Holdet vil altid indeholde en tankevækkende grund til, hvorfor en komponent ikke bør blive en standard, eller hvorfor den ikke passer til vores retningslinjer. Hvis det er relevant, tilbydes andre løsninger eller overvejelser.
  • Design til komponenter, der har brug for mere information. Nogle gange skal designere gå tilbage til tegnebrættet for at finde ud af yderligere detaljer, før en komponent er klar til prime time.

For folkene - dit system skal hjælpe dig

Vi ønskede, at Canvas skulle være så let at bruge, at vores designere aldrig ville drømme om at bruge noget andet. Så for eksempel i stedet for kun at bruge tal til at mærke vores UI Kit-versioner, begyndte vi at navngive hver version alfabetisk efter berømte rappere. Ikke kun fik vi sjove fakta og gode afspilningslister, men det gjorde det også meget lettere at huske og tale om de forskellige versioner (overraskende nok er Jam Master Jay og Kris Kross meget lettere at huske end v1, v22 eller v100). Når vi kom igennem alfabetet, begyndte vi at arbejde igennem Som set på tv-produkter.

Mange tak til Hot Stamps-reklamen for at have lært os, at alt hvad du behøver for at imponere dine venner er noget glitter.

Vi er meget interesserede i løbende at evaluere og forbedre vores proces for at gøre livet lettere for alle i designteamet. Nogle eksempler på de udfordringer, vi har løst over tid, er:

Synlighed for, hvad der ændrer sig.

I de tidlige dage havde designere på teamet problemer med at vide, hvad der skiftede, medmindre de var på Canvas-teamet. Så vi begyndte at sende e-mail hver gang vi frigiver et nyt Sketch UI Kit. Disse e-mails hjælper os med at opdatere teamet tydeligt og konsekvent om, hvad der er nyt og anderledes i hver version, og giver et nemt sted for designere at downloade det nye kit. Hvert UI-kit inkluderer også en ændringslog på den første side i Sketch-filen.

Matchingskode i UI-biblioteket til design af aktiver i Sketch UI Kit.

I begyndelsen havde vi et bare-ben-sketchesæt, der katalogiserede de forskellige komponenter, vi muligvis har brug for, og et front-end-komponentbibliotek for udviklere til reference og brug, men de stemte ikke altid overens. Denne kløft førte til uoverensstemmende sprog mellem designere og udviklere. Så for at dyrke medejerskab mellem designere og udviklere, påtog vi os et stort projekt, der matcher navigations- og navnekonventionerne i vores UI-bibliotek og vores Sketch UI-kit.

Tænker ud over traditionelle komponenter.

Illustrationer, sidelayout, tomme tilstande, fejltilstande - du navngive det. Hvis genbrug af et objekt skaber gearing, er det værd at gøre det til en komponent eller en tilføjelse. Vores Frontend-as-a-Service-team har også gjort det ekstremt let for ingeniører i produktteam at indsende komponenter eller tilføjelser til selve systemet. Vi er også begyndt at dokumentere UX-mønstre (ikke kun "hvilken komponent skal jeg bruge?", Men "hvordan skal jeg bruge det?").

Men vi har bestemt ikke rettet alt. Nogle udfordringer, som vi stadig prøver at løse og har gentaget os, inkluderer:

Effektiv tildeling og visning af prioritet.

Da vi begyndte at flytte vores proces til Github, leverede vi tags, der lader brugere vælge prioriteten af ​​deres anmodning på en skala fra P1 til P3 (en P1 betød “vi har brug for dette i går” og en P3 betød ”vi kommer til dette en skønne dag"). Men fordi vores hold bevæger sig så hurtigt, endte næsten alt med at blive en P1.

Men vi kan heller ikke gøre alt - vi er nødt til at afbalancere prioriteterne for 40+ hold, og vi har haft nogle problemer, der glider gennem revnerne. Vi overvejer, hvordan vi prioriterer spørgsmål i dag, så vi både kan løse for det team, der bygger vores komponenter, og for de hold, der venter på dem.

Har ikke en dedikeret designressource.

Selvom vi ønsker, at alle designere på teamet skal lave en rotation, ligger deres hovedansvar stadig hos deres produktteam. Det betyder, at vi er nødt til at være skrøbelige og ressourcefulde, når det gælder at få arbejdet udført rettidigt. Vi overvejer muligvis at supplere det roterende team med en designer, der er fokuseret på systemet på heltid i fremtiden.

I vores system stoler vi på

Vi har en gylden regel her på HubSpot som en del af vores kulturkode: Brug god dømmekraft. Det stammer fra en kultur med tillid og ansvarlighed over for andre. Vi byggede vores principper, retningslinjer og processer på et grundlag af tillid for at sikre, at vores designsystem varer, fordi et system kun fungerer, hvis folk har tillid til det.

Vi skabte denne tillid ved at gøre det let at forstå, hvordan beslutninger tages, og hvordan man kan bidrage, hvis nogen vil hjælpe eller er uenig i en beslutning. Vi samler regelmæssigt feedback og laver planer om at tackle forbedringer. Vi finder måder for folk, der er interesserede i eller bruger det meget til at blive involveret. Og vi dokumenterer så meget som vi kan om, hvorfor beslutninger blev truffet, så enhver kan se og henvise tilbage til dem.

I slutningen af ​​dagen var det ikke bare godt for vores designere og udviklere at gøre vedligeholdelsen af ​​vores designsprog til en leg - det var godt for vores brugere. Omdesign af vores produkt med Canvas var en stor ændring, men vores mål var at opbygge et system og en proces, der er så stærk, at vi aldrig skulle behøve at redesigne vores produkt igen.

Med det fundament, vi har oprettet med hele dette system, har vi evnen til at foretage mindre ændringer på tværs af vores produkt over tid. Ny primærfarve? Færdig. Rundede hjørner er ikke cool længere? Væk. Brugere har problemer med at finde ud af, hvordan de går videre i en guide til guiden? Vi vil undersøge og rette det uden en hel UI-revision på tværs af appen.

Ved at skabe et stærkt designsystem og en stærk proces til at understøtte det, kan vi støtte en tankevækkende proces med produktudvikling - uden byrden ved engrossalg. Det er et system, der fungerer.

credits:
Illustrationer af Sue Yee.

Oprindeligt offentliggjort på HubSpot produktblog.