Definition af designsystemer

At komme til rodet af, hvad dit system virkelig er

Det er en skræmmende udfordring at definere designsystemer. Det er ikke som om vores samfund ikke har gjort mange, mange, mange, mange, mange, mange, mange, mange, mange, mange, mange, mange, mange forsøg. For nylig skrev Sarah Federman om at destillere det til dets væsen og advarer os om at undgå at blive fanget i at definere ting og være dogmatiske over, hvad det er og ikke er.

Designsystemer er et voksende felt dannet af levende, samarbejdsfulde stemmer. Det er vigtigt at udpege, hvad et system er, og hvordan det passer, eller vi risikerer at underminere dets værdi på grund af usammenhængende forståelse. Vi bør ikke lide udfordringer, og der er fælles grund til at vinde. Mit levebrød afhænger af det, og sælger ~ 15–25 designsystemer, der er forpligtelser om året til kunder, der forstår resultaterne og output (tip: ikke kun UI-sæt, kode og doc), og hvorfor de betyder noget.

“Hvad er et designsystem?”

Hvis jeg har ~ 30 sekunder i en elevator eller over animerede dias, fører jeg med:

Næsten altid tilbyder et designsystem et bibliotek med visuel stil og komponenter, der er dokumenteret og frigivet som genanvendelig kode for udviklere og / eller værktøj (er) for designere. Et system kan også tilbyde vejledning om tilgængelighed, sidelayout og redaktionel og mindre ofte branding, data viz, UX mønstre og andre værktøjer.
Et designsystem er vedtaget af og understøttet for andre teams, der gør erfaringer. Disse hold bruger det til at udvikle og sende funktioner mere effektivt til at danne en mere sammenhængende kunderejse.
Et designsystem er lavet af et individ, team og / eller samfund. Mens nogle opstår mindre formelt, dedikerer organisationer nu små til store grupper (r) til at udvikle og frigive systemversioner og processer over tid.

Hvis det kun er 10 sekunder, siger jeg:

Et designsystem tilbyder et bibliotek med visuel stil, komponenter og andre problemer, der er dokumenteret og frigivet af et individ, team eller samfund som kode- og designværktøjer, så at vedtage produkter kan være mere effektive og sammenhængende.

Hvis det kun er en tweet, så er der dette:

Formelt er et system et sæt af sammenkoblede dele, der danner en samlet helhed. I tilfælde af designsystemer henviser denne definition faktisk ikke til ét men tre sammenhængende systemer, som du skal løse for at få succes:

  1. et sæt genanvendelige, sammenkoblede dele,
  2. et sæt sammenhængende, sammenkoblede produkter og
  3. et samfund af samarbejdsvillige, sammenkoblede mennesker.

# 1. Et sæt genanvendelige, sammenkoblede dele

For sine primære kunder er systemet et sæt konkrete outputs, som de møder dagligt. Jeg starter helt klart med:

Næsten altid tilbyder et designsystem et bibliotek med visuel stil og komponenter, der er dokumenteret og frigivet som genanvendelig kode for udviklere og / eller værktøj (er) for designere.

I disse dage forbinder et system med dele en kodificeret visuel stil (f.eks. Farve, plads, typografi) til komposible UI-komponenter (knapper, formularer, overskrifter, så meget mere), der bruges til at designe og oprette grænseflader.

Dette udgangspunkt pakker et stykke af intentioner og afslører overbevisning: Et system betjener udviklere og designere i den rækkefølge. Et system skal være veldokumenteret. Et system skal tilbyde stil- og UI-komponenter. Alligevel er ethvert system forskelligt, så jeg udvider et systems rækkevidde til også at omfatte:

Et system kan også tilbyde vejledning om tilgængelighed, sidelayout og redaktionel og mindre ofte branding, data viz, UX mønstre og andre værktøjer.

Denne variation varierer nyttige samtaler, der trækker grænser for, hvad en organisation ønsker og har brug for. Nogle bekymringer (altid stil og komponenter) realiseres langt oftere end andre (redaktionel vejledning og datavisualisering).

# 2. Et sæt sammenhængende, sammenkoblede produkter

Ord som "tilbud" og "frigivet" er forsætlige, og støber designsystemet som et produkt, der tilfredsstiller kundernes behov (først og fremmest udviklere og designere, der fremstiller deres egne produkter) gennem konkrete output, de bruger.

Påkaldelse af produktkoncepter udløser en kaskade af koncepter, der er nyttige for dem, der er bekendt med produktstyring, der også er gældende for et system: køreplan, efterslæb, frigivelser, programforøgelser, sprints, afhængigheder. At fokusere kun på udvikling af dele risikerer dog at mangle, hvad der får systemer til at fungere. Især systemets kunder!

Et designsystem er vedtaget af og understøttet for andre teams, der gør erfaringer. Disse hold bruger det til at udvikle og sende funktioner mere effektivt til at danne en mere sammenhængende kunderejse.

Designsystemer investerer i markedsføring til produktteams til at forbruge kittet med dele for at danne en samlet og sammenhængende holistisk oplevelse. Fremme af vedtagelse kræver klar besked for at sælge andre til at vedtage system og forbedre sig selv (individuelt og samlet) ved at realisere fordelene over tid som en afhængighed.

Produktstyring fremkalder også, hvordan designsystemer passer ind i produktdrift, såsom DevOps-levering ("Hvordan frigiver vi det? Hvordan er det automatiseret?"), Integration ("Hvordan versionerer vi? Hvad er en banebrydende ændring? Hvordan, hvor ofte, og hvornår opgraderer vi? ”) og infrastruktur (“ Hvor er vores repo? Hvor er vores doc vært? Er det offentligt? ”).

Let at gå glip af i definitionen ovenfor understøttes til, indramning af kundes support og service. Effektiv dokumentation er vigtig. Derudover skal der være veje til og tid til at yde hjælp, svare på anmodninger, lappe defekter og konsultere alt i et miljø, der er åbent og lydhør.

At cast et designsystem (og den krævede indsats for at få det til at fungere godt), da netop udviklet stil, komponenter og aktiver - til undtagelse af markedsføring, service, integration og operationer, som succes afhænger af - er for snævert.

# 3. Et samfund af sammenkoblede samarbejdspartnere

For at hjælpe interessenter med at forstå konsekvenserne af et system dirigerer jeg også samtalen gennem de mennesker og aktiviteter, der kræves for at betjene et system.

Et designsystem er lavet af et individ, team og / eller samfund. Mens nogle opstår mindre formelt, dedikerer organisationer nu små til store grupper (r) til at udvikle og frigive systemversioner og processer over tid.

At karakterisere et systemteam som en produktgruppe sætter valget med hensyn til kendte produkt- og marketingfolk: er dette vigtigt nok til at lægge et team bag det? Dette team kan vedtage ritualer, fremvise arbejde og udvikle en køreplan for at blive en del af stoffet i, hvordan virksomheder fremstiller produkter.

I de tilfælde, jeg har observeret, er dette team ansvarligt for arbejdsgange, forbindelser og samfundsengagement på tværs af en virksomhed for at beslutte, hvordan et system anvendes og udvikles. Historisk omtalt som "regeringsførelse" vil jeg undgå dette udtryk for at favorisere en tone i samarbejde om kontrol.

Udefra fornemmer en designer, ingeniør eller en anden i et samfund muligvis ikke niveauet for udførelsen bag sådanne aktiviteter. Det betyder ikke, at de ikke udvikles, betjenes, understøttes og bruges med vilje i måneder eller år. Denne udførelse af interaktioner i samfundet er et anstrengende, men alligevel immaterielt produkt, der gør et system vellykket.

Komponering af en High Definition System Definition

Selvom det ikke var min hensigt, vendte denne skrivelse mig tilbage til rammen af ​​et workshop om dele, produkter og folk, jeg har kørt i årevis. Denne aktivitet trækker deltagerne gennem en ordineret protokol for at specificere, hvilke dele deres system har brug for, hvilke produkter det vil gælde for, og hvem der udfører arbejdet.

Aktivitetsark for dele, produkter og mennesker

Det er dog rimeligt at gå foran eller erstatte denne omhyggelige aktivitet med en slankere, udfyld-blanke skabelon til jordforståelse:

Vores designsystem tilbyder
_______ [sæt omfang] _______
frigivet som
_______ [kitudgange] _____
og dokumenteret kl
_______ [kit doc site] _____
produceret af
_______[mennesker]_________
for at tjene
_______[Produkter]_______
produkter og oplevelser.

I årevis med at bidrage til designsystemer ville denne erklæring give lignende, men altid unikke svar. Et system, jeg arbejder på nu, ville udfylde disse emner som:

Vores designsystem tilbyder
visuel stil, tilgængelige UI-komponenter, diagrammer, redaktionel vejledning, UX-mønstre og branding
frigivet som en
HTML & CSS-rammer via npm, Sketch og andre PDF- og AI-skabeloner
og dokumenteret kl
designsystem.companyname.com
produceret af
et systemteam bestående af 1 designdirektør, 1 produktchef, 2 designere, 3 ingeniører og et samfund på ~ 15 samfundsbidragydere
for at tjene
~ 50 webapps, et par native app og begrænset branding
produkter og oplevelser.

Et system, jeg starter nu, udviser en anden sammensætning, der kræver en anden tilgang til, hvordan det er fremstillet og forbrugt:

Vores designsystem tilbyder
visuel stil, UI-komponenter og tilgængelighedsprocedurer
frigivet som en
Reager komponentbiblioteket og skitse aktiver via Lingo
og dokumenteret kl
designsystems.companyname.com
produceret af
et systemteam med 1 systemleder, 1 produktchef, 1 designer og 2 frontend-udviklere, der samarbejder med et React-baseret engineering team
for at tjene
~ 10 webbaseret og 2 indbygget app
produkter og oplevelser.

Det, der flommer vores samfund, er variationen i systemsammensætning. Det konsekvente mål - at vedtage produkter, der producerer en sammenhængende oplevelse mere effektivt - nås på mange mulige måder ved at involvere forskellige slags grupper med forskellige fokusområder.

Der er ingen de-facto-formler, ingen vindende metodik (men vi bliver bedre). I stedet kræver systemsucces at tilpasse, hvordan du definerer det til betingelser og begrænsninger for den virksomhed, den tjener.

Om at gå i gang med et designsystem eller har brug for at dykke dybere for at diskutere produkter og spillere? EightShapes afholder systemplanlægningsworkshops og coacher klienter i designsystemer. Lad os tale!