Otte ting, du skal vide om designsystemer

Jeg deltog i en hel masse foredrag, så du behøver ikke.

Det er på hver jobbeskrivelse. Du ser det hele over den friskeste frigørelse af designværktøj. Du har måske endda hørt din familie omtale det ved Thanksgiving. Men hvad er fakta om disse "designsystemer", som hele branchen taler om?

Bridging design og engineering har været en intens interesse for mig siden overgangen til design fra software engineering, så jeg var ivrig efter at lære alt om designsystemer, så snart jeg hørte, de var magtfulde værktøjer til designteam og deres tekniske interessenter. Heldigvis arrangerede RETHINK og SF Design Week en hel række begivenheder om emnet i løbet af den sidste måned, og jeg prøvede at gå til hver eneste en af ​​dem.

Det betyder, at jeg gik til over femten forskellige foredrag fra designere i forskellige organisationer. Hver designer bragte unikke, handlingsmæssige indsigt i designsystemer. Her er de.

Dette er en længere læst, så jeg har anvendt noget liberal fedtring, hvis du vil scanne de vigtige bits.

1. Hvorfor designsystemer er vigtige.

Kilde. Figmas designsystems.com er deres ressource til designsystemlæring.

Diana Mounter, Design Systems Manager @ GitHub, opsummerede det ret godt:

  • Designsystemer bringer orden til kaos. Alle holdes på den samme side, så hele produktet forbliver konsistent og poleret overalt.
  • Designsystemer forbedrer brugeroplevelsen gennem gentagen brug af velkendte og dokumenterede mønstre. At designe noget fra bunden giver plads til fejl, så prøv at bruge det, der allerede fungerer.
  • Designsystemer forbedrer effektiviteten af ​​arbejdsgangen. Produkthold ved nøjagtigt, hvordan komponenter af nye funktioner skal se ud, og hvordan de implementeres.

Noah Levin, chef for design @ Figma, kørte virkelig det sidste punkt hjem. Han prædikede filosofien om gentagelighed i sin tale og forklarede, at det bedste, du kan gøre, når du har brugt din tid på at gøre noget som at bygge et nyt ikon, er at automatisere denne praksis for den næste person. Dermed vil du ikke kun have bragt værdi til dit eget arbejde, men til hele organisationens arbejde. For Noah, Opførsel = Motivation * Evne * Udløser. Når nogen i dit team udløses til at gennemføre et design, kan vi gøre lidt for at ændre deres motivation, men vi kan gøre så meget gennem designsystemer for at forbedre deres evne. Slutresultatet er opførsel, der producerer et mere konsistent, bevist design så meget hurtigere.

2. Hvad et designsystem er.

Karri Saarinen, Design Systems Lead @ Airbnb, gav denne definition:

Et sæt delte, integrerede mønstre og principper, der definerer produktets overordnede design

Hvis du har ringe erfaring med designsystemer, kan en så bred definition defineres som tvetydig eller uhensigtsmæssig. Manglen på detaljer er dog nøglen. Designsystemer kræver ikke en mere specifik definition. De har brug for rummet til at være, hvad en organisation kræver for design og dens implementering for at bevæge sig hurtigt uden at ødelægge ting.

Men her er lidt mere info lige fra manden:

Blad gennem eksisterende designsystemer for bedre at forstå, hvad de er i praksis. Her er materiale design. Dette er protokol af Mozilla. Og her er iOS Human Interface Guidelines, som vi officielt ikke kalder et designsystem af en eller anden nuanceret Apple-grund, ligesom hvorfor vi ikke skulle kalde HomePod en smart højttaler. Alle disse systemer er bygget forskelligt, men forstår, hvordan de alle passer inden for grænserne for Karris definition.

Du spekulerer måske på, hvorfor de komponenter, du kastede sammen i Sketch, blot betragtes som "mønsterbiblioteker", "stilguider" eller "UI-sæt". Mike Dick, designteknolog @ SurveyMonkey, startede faktisk med et af disse UI-sæt, da han gik omkring komponentisering af deres elementer, men han gik tilbage til tegnebrættet, da han begyndte at vise det til teknik. I stedet for at opbygge et system med komponenter til designere implementerede Mike en enkelt sandhedskilde til design til at integrere med teknik. Design, der er bygget med dette designsystem, kunne let oversættes til CSS, det sprog, der blev brugt til at definere styling, og kunne derfor hurtigt kaskade designændringer til deres front-end komponenter. Med tilstrækkelige ressourcer kan større organisationer som AirBnb implementere værktøj, der oversætter skærme, der er bygget med deres designsystem direkte til kode (dette er grunden til, at Framer X er så stor).

Når vi ser tilbage på Karris definition, ser vi en omtale af principper. Det betyder, at designsystemer indeholder regler og retningslinjer, der informerer brugerne om, hvordan de implementerer mønstre og stilarter, der er organiseret i systemet. Rich Fulcher, chef for materialedesign @ Google, forklarede, hvorfor principper var et definerende stykke af systemet: fordi et designsystem kun virkelig findes, hvis det kan bruges uden skaberen.

3. Ethvert designsystem er bedre end intet designsystem overhovedet.

Diana Mounter, GitHub

GitHubs designsystem, Primer, blev moderniseret internt og privat. Diana gjorde det delvis, fordi hendes team stod overfor Imposter Syndrome sammenligning af Primer med systemerne for modne og større organisationer som AirBnbs DLS, Shopifys Polaris og det amerikanske webdesignsystem. Primer følte sig upoleret i sammenligning. Mange komponenter blev afskrevet.

Men ved du, hvad der er værre end at vide, at en komponent udskrives? Ikke at vide, og skubbe den grusomhed til produktion.

Primer og andre systemer bruger flag til hurtigt at indikere, om komponenter er forældede eller ej.

Derfor siger Diana, at du ikke skal bekymre dig om at sammenligne dit designsystem med nogen anden organisations system, for det er ikke det, der beviser dets succes. I stedet siger Diana, skub dit designsystem ud og analyser anvendelsen for at måle dens succes. Kaos vil være en naturlig del af noget så nyt i praksis som designsystemer, så fokuser på det, der betyder noget, og drage fordel af kaoset. Bruger folk designsystemet i deres arbejdsgang og bidrager de tilbage til det for at gøre det bedre?

Der er ingen tvivl om, at systemer som Polaris, iOS HIG og Material Design er bemærkelsesværdigt grundige og endda seje at se på. Men ikke kun er disse systemer bygget af virksomheder med enorme ressourcer, de er især målrettet mod tredjeparts interessenter, der ikke arbejder under dem. Det kommer bare med territoriet.

Diana viste denne sjove bommert. Ideelt set vil komponenter ikke hindre læsbarheden af ​​den eksemplificerede kode.

Diana afsluttede sin tale med en tweet for at dele Primer med verden, mangler og alt. På denne måde giver GitHub's system interessenter: 1. Adgang til dets ressourcer og 2. Muligheder for at forbedre systemets mangler.

4. Sådan kommer du i gang med et designsystem.

Den første ting, du ser på Shopifys Polaris.

Først og fremmest har du brug for et snavset navn. Så snart du læser Polaris, ved du, at du vil blive ført til din veludformede frelse.

Bare for sjov. Faktisk blev Materialedesign ikke officielt titlet før en måned før det blev offentliggjort. Rich Fulcher sagde, at det for det meste blev kendt som 'Quantum Paper'.

Og start heller ikke med en Sketch-fil! Michael McCombie, systemdesigner @ Mozilla, begik den fejl en gang. Så snart han hentede andre interessenter, måtte han starte igen. Et designsystem er et stykke design, der løser brugerproblemer. Forstå problemet og brugerne først.

Da Jordan Girman, sr. Direktør for brugeroplevelse @ Glassdoor, begyndte at fremstille Glassdoors første designsystem, startede han teamet med disse spørgsmål:

  1. Hvad er behovet for dette system?
  2. Hvordan implementeres design nu?
  3. Hvordan skal det implementeres?

Derfra sætter de mål og krav til deres designsystem, der stemmer overens med resten af ​​organisationen. Denne tilpasning, som forklaret af Mike Dick, er afhængig af et forhold. Uden et forhold til dine interessenter vil du støde på nogle få udfordringer:

  • Ingen taler det samme sprog. "Style guide" betyder to forskellige ting for ingeniører og designere. Hvordan ved du, om din terminologi og dokumentation vil blive forstået af alle?
  • Det bliver meget sværere at få alle ombord med dit designsystem. Dine folk forstår ikke værdien af ​​noget, de ikke hjalp med at skabe.
  • Ingen vil vide, hvad kilden til sandheden er. Kysse din konsistens farvel.
Hvad en ingeniør tænker, når du siger

Mike anbefaler især at finde et modstykke, der komplementerer dine evner med en fælles lidenskab for at bygge bro mellem design og teknik. Hvis du ikke er en god koder, skal du blive venner med en, der er en god koder med en dyb forståelse af ingeniørstakken. Det gjorde det muligt for Mike at forstå, at det at dokumentere CSS snarere end at omdirigere systemkomponenter var nøglen til konstruktion for at udnytte systemet bedst muligt.

Jeg anbefaler, at du søger på Medium efter ressourcer om, hvilke værktøjer du skal bruge, og hvordan du bruger dem til at opbygge dit designsystem. Du vil ikke høre det fra mig, for jeg vil bare sige noget om Figma.

5. Designsystemer dokumenterer alt.

Microsofts flydende dokumentation om radioknapper.

Når du har fastlagt dine systems mål og krav sammen med interessenter, er du et godt sted at starte med at negle dine overordnede, styrende designprincipper. Gode ​​designprincipper giver dig mulighed for at opbygge dit system med en konsistens, der er på linje med dine mål, og de kan være en genvej til din brugers flyt af hele systemet. Igen anbefaler jeg, at du kigger på eksisterende, robuste designsystemer som Polaris for at finde de bedste eksempler på principper i praksis. Når du begynder at oprette deres egne, Rich Fulcher og Selene Hinkley, Content Strategist @ Shopify, havde et par ting at huske på:

  • Mange ønsker ikke engang at læse principper; hvis de læser, kan de scanne. Hvis de scanner, forstår de muligvis ikke. Hvis de ikke forstår det, gælder de bestemt ikke. Så forstå dit publikum, når du opretter din kopi og indhold!
  • Vær vejledende, ikke receptpligtig. Giv plads til kreativitet ved at give et spektrum af hvad der er acceptabelt. Principper skal være en guide til beslutningstagning.
  • Begræns antallet af principper. Shopify startede med 13, men de har nu det kogt ned til 4. De fjernede “top down” og “mellemstyring” -principper, der ikke gjorde meget for dem, der designede og implementerede design første hånd i dag til dag arbejde. Græsrødprincipper er guld.
  • Genspejle dine principper i det, du opretter. For den type bruger, der refererer til designsystemet i kontekst og lærer gennem et eksempel, vil dette gøre meget for at gribe ind i dine principper og forblive konsistente.
  • De kan ikke begrænse dit brand eller produktprincipper. Designsystemer skal være delsystemer i din organisation, så sørg for, at de passer ind i helheden.
  • Fortsæt med at udvikle dine principper. Anvend brugercentreret design til oprettelsen af ​​dine principper, så de afspejler dit system og virkelighed nøjagtigt. Ellers vil konsistensen nedbrydes, når andre brugere anvender dine principper.

Derefter skal du tilføje komponenterne i dit designsystem, mens du sørger for at dokumentere deres specifikke principper. Ting bevæger sig så meget hurtigere, clueless holdkammerater buger dig ikke, og dit navn bliver ikke forbandet, når du ikke er i nærheden. Her var hvad Selene havde at sige om at dokumentere dit designsystem:

  • Opdel stykker i punkter og lister.
  • Brug visuelle eksempler, hvor det er muligt.
  • Hold sætninger korte og handlingsbare.
  • Brug dos / don'ts.
  • Gør dine ikke mindre tydelige. Model dem efter realistiske fejl, der kan være resultatet af fejlagtig fortolkning
Kilde: material.io

6. Designsystemer skal integreres tilgængelighed.

Tjek dette værktøj til at kontrollere tilgængelige kontrastforhold hos WebAIM.

John Cassidy, Senior Designer @ Google, begyndte sin tale med en fed stat:

1 ud af 7 personer er handicappede. Det er over en milliard mennesker.

Stadig havde John mere at sige. En bruger er deaktiveret, så snart deres hænder er fyldt med dagligvarer. Hvis de finder sig selv på rejse i et fremmed land uden lokale sprogfærdigheder, er de deaktiverede. Hvis du lever længe nok, ender du sandsynligvis permanent ud en dag.

Hvis du er overbevist endnu, har John dette råd til at bringe tilgængelighed til dit designsystem.

  • Anvend tilgængelighedsindstillede designbegrænsninger. Sørg for, at dine komponenter tager højde for scenarier, der har behov for tilgængelighed, som f.eks. Ændret størrelse til fjernsyn og alt-tekst for skærmlæsere. Glem ikke midlertidig handicap; hvad nu hvis dit produkt bruges af drivere i skarpt dagslys?
  • Lær om tilgængelighedsteknologien, der er tilgængelig for dine brugere. OS-teknologi som iOS Magnifier og Windows Narrator er mest tilgængelige, men tilføjelsesprodukter som Xbox Adaptive Controller findes også. Og noget teknologi er ikke begrænset til brug af handicappede brugere, især stemmeassistenter.
  • Test dine komponenter med de tilgængelighedsteknologier, der er tændt. Temmelig enkel. Tænd for teknologier som iOS VoiceOver, og sørg for, at de fungerer med dine systemkomponenter på en nyttig måde.
  • Test dit produkt med brugere med varierende handicap. Naturligvis skal du bringe dit produkt foran brugere, der befinder sig i et spektrum af forskellige mentale, fysiske og situationelle handicap.
Microsofts Xbox Adaptive Controller er en af ​​de nyeste tilgængelighedsteknologier for brugerne.

7. Farve og illustration kan og bør være systematisk.

Shopifys Polaris farvepalet

Din organisation har muligvis allerede mærkefarver, der ville være nyttige til udfyldning af dit brugergrænseflade, men ikke så hurtigt. Vælg ikke dine UI-farver ved at kopiere og indsætte dine mærkefarver. Mærkefarver tager ikke højde for anvendeligheden, selvom at aflede dine basefarver fra dit branding sandsynligvis er det bedste sted at starte. Linda Dong, Design Manager @ Lyft, anbefaler, at du opretter spektrum af mærkefarver med overlagt tekst for at slå sig ned på UI-farver, der tilfredsstiller tilgængelige farveforhold. Test selvfølgelig alt dette i de situationer, dit produkt vil blive brugt i. Lyft har brug for at arbejde for chauffører om aftenen og på de lyseste dage.

Når du vælger dine farver, skal du ikke henvise til disse farver i dit designsystem med deres hex-kode eller deres “officielle” navn. Linda påpegede dette med en sjov quiz til farvenavn. Det viser sig, at duen er en medium-grå. Kald mig usofistisk, men jeg tror, ​​at pidgeon er det, du leder efter.

I stedet skal du definere dit farveskema gennem farvestykker. Michael McCombie og protokollsystemet bruger grundlæggende farvenavne som $ farverød, mens Linda og Lyft bruger et $ ColorName-Value-format på grund af deres farvespektrum. Medbring naturligvis alle dine interessenter, når du bygger dit farvesystem - og annoncer det, når det er klart - for at sikre vedtagelse.

Jennifer Hom, oplevelsesdesignchef for Illustration @ Airbnb, kom ombord for at gendanne deres illustrationssystem. Før havde Airbnb illustrationer delt på tværs af størrelser eller forskellige illustrationer mellem størrelser. Jennifer ændrede illustrationer til systematisk forøgede vektorvægte og detaljer, da eksportstørrelser steg op (1x, 2x, 3x), hvilket muliggjorde et konsistent, men platform-passende design mellem enheder.

Jennifer havde også disse principper til at overveje til dit illustrationssystem:

  • Sørg for, at dine illustrationer er jordet. Illustrationer skal give de fleste, hvis ikke alle, mulighed for at forholde sig til dit produkt og uden at tænke på detaljer.
  • Lad ikke dine illustrationer tage fokus. De skal øge glæden uden at distrahere brugeren fra deres mål.
  • Brug tilgængelige farver. Tjek dine farveforhold!
  • Vær mangfoldig, men realistisk. Airbnb's illustrationer er baseret på virkelige mennesker, så de "viser" Donald Glover og Jennifer's tilfældige Facebook-venner. Airbnb talte også med organisationer og myndigheder om handicap, der gav dem ideen om at bruge en subtil kø som hovedtelefoner.
  • Test dine illustrationer. Åh mand, kan du tro det? Dette designstykke skal også testes. At vise de Kina-specifikke illustrationer til Beijing-kontoret gjorde det muligt for Jennifer at finde ud af, at stor-kiste kinesiske mænd ikke ville være den mest relatable.

8. Sådan skaleres et designsystem.

Karri Saarinen: Hvordan et designsystem vil udvikle sig med skala.

Hvad er det? Din virksomhed har netop annonceret en serie C! Inden for 3 måneder forventes det, at du har en komplet pakke med apps på alle platforme og et team af ikke-Yous, der administrerer hver enkelt.

Frygt ej. Andre har nået den anden side. Sådan synes Karri, at du kan skalere dit designsystem:

  • Brug definerede primitiver. Definer farveskemaer, tekstformater, gitre osv., Der vil være byggestenene for hver tilføjelse til dit designsystem. Alle Airbnb's kernekomponenter og teamspecifikke biblioteker er bygget med det samme sæt primitiver.
  • Byg dine komponenter ved hjælp af disse primitiver, og opbyg dine mønstre med disse komponenter. Dette vil sikre konsistens, samtidig med at det giver mulighed for en vis fleksibilitet og formbarhed.
  • Forbliv fleksibel. Du har brug for fleksibilitet for at give mulighed for afstand, tekstbeskæring, forskellige tekststørrelser for tilgængelighed og internationalisering, forskellige farvevalg, brugerdefinerede komponenter og god kreativitet.
  • Lav dine designspecifikationer platform-agnostisk. DLS definerer deres komponenter i JSON, en allestedsnærværende datanorm, der giver mulighed for automatisk oversættelse til platformspecifikke stilarter som CSS.
  • Tilføj teamspecifikke biblioteker, men hold dem under kontrol. Airbnb begrænser deres teambiblioteker til eksperimentelle og specifikke komponenter. Så teambiblioteker overvåges, og komponenter sendes op i kæden, hvis de er egnede kernekomponenter. 70 komponenter udgør 60% af Airbnb's front-end på tværs af alle platforme!

Stor tak til de utrolige højttalere: Diana Mounter, Noah Levin, Karri Saarinen, Rich Fulcher, Michael McCombie, Linda Dong, John Cassidy, Jennifer Hom, Selene Hinkley og Jordan Girman. Og tak til Julie Stanescu (sammen med sit team på Rethink) og SF Design Week for at arrangere deres fantastiske foredrag!

Til sidst tak til Jasmine Rosen og Jodee Cherney for redigering og resten af ​​Tradecraft for deres fortsatte støtte, og Tyler Heucke for at være min ”engineering-modpart”.