Start af et designsystem

Fra at vælge en strategi til lancering af 1.0 og videre

At starte et designsystem til at betjene en produktportefølje er ikke et typisk projekt. Selvfølgelig, indsatsen producerer genkendelige output som et visuelt sprog og UI-komponenter. At gøre det skal føles kendt, cykle gennem iterationer af design, udvikling og dokumentation.

Systemets løfte er dog ikke et leveret bibliotek. Systemets løfte er at muliggøre en ensartet oplevelse fordelt på produkter og opretholdes med en pålidelig, forudsigelig praksis. Systementusiaster skal blive iværksættere, pitching og salg af ideer, der får en muligvis modstandsdygtig organisation til at forpligte sig. Over tid opnår et system meningsfulde resultater ved at koordinere og samarbejde på tværs af organisatoriske grænser og irriterende kultur. Det er en proces.

Denne bue til at starte et system - sæt en strategi, lancere en første udgivelse og fungere regelmæssigt for at fremme adoption og community - har vist sig at være effektiv i de fem systemer, jeg har ført siden begyndelsen af ​​2016. Alle blev lavet, vedtaget og fortsætter med at fungere i dag med aktiviteter og tidsplaner beskrevet her. Måtte fremgangsmåden inspirere, når du starter en rejse mod et system, der varer.

Forpligt dig til en systemstrategi

Et designsystem starter ikke med at vælge en første farve. I stedet for skal du basere et system i en strategi, der skaber kundebehov, sætter mål, udforsker og konvergerer i en designretning, lægger en strategi og opnår en organisations engagement.

Oplev kundebehov

Som ethvert produkt, vi designer og udvikler, skal et designsystem imødekomme behovene ved at vedtage produktteam inden for det aktuelle landskab af kultur, værktøjer, eksisterende systemer og praksis.

Opdagelsesaktiviteter kan omfatte:

  • Interviews med centrale (potentielle) bidragydere, påvirkere og ledere til at vurdere perspektiv, holdninger, kultur og eksisterende praksis.
  • Kortlægning af en bredere organisation af interessenters holdninger og holdning til et system, prioriteter / behov, forhåbninger og trusler.
  • Krav indsamlet via opgaveanalyse, teknisk planlægning og konventionindstilling (ved hjælp af værktøjer som Brad Frosts Front End Questionnaire).
  • Produktture for at fordybe sig i as-is-produkter og in-flight-design, som systemet vil anvende ved at tage skærmbilleder og noter.
  • System (er) gennemgår vurderingen af ​​design-aktiver, kodebiblioteker, standarddybde og -kvalitet og styringsmodeller.

Inddrag interessenter i inkluderende workshops

Opdagelse kan føre til personlige præsentationer og arbejdssessioner for at opsummere fremskridt og indsamle flere input. Vi sammenkalder store grupper af designere, ingeniører, ledere og andre til sessioner til:

  • Præsentere fund og undersøgelser af fund og anbefalinger.
  • Definer system- og produktomfang via øvelser som Parts, Products & People og Component Cut Up-varebeholdninger af eksisterende produkter.
  • Diskuter modeller og kandidater til systemhold og ledere, samfundsdeltagelse og bidrag.
  • Saml ingeniører og teknologiledere for at bekræfte antagelser, vælge rammer (er) og identificere dev-miljø og hosting-behov.
  • Køreplan kommende systemaktivitet inklusive referencedesignkoncepter, første udgivelsescyklusproces og hvordan vi måler succes.

Konverger i en konceptuel retning

Oftest falder etablering af et designsystem sammen med at udvikle et nyt visuelt sprog fra bunden af ​​og anvende det sprog på UI-komponenter, som produktgrupper er enige om at bruge. Din succes afhænger af at få din organisation om bord med den retning, du er på vej hen.

Derfor er det kritisk at konceptuelt demonstrere din nye visuelle retning med billeder af din produktoplevelse før og efter, at et system er anvendt. Denne proces skal omfatte og endda ansætte medlemmer af dit samfund hvert skridt på vejen.

Referencedesign på tidligt stadium for den reaktive redesignperiode Marriott.com 2012–2014.

For mere om forberedelse og præsentation af koncepter, skal du læse Referencedesign til systemer: Sidekoncepter, der sammenligner før og efter, med en systemvridning.

Lav en strategi med et klart forslag

I sidste ende er en strategi intet, hvis de mennesker, der betyder noget - både ledere med penge og samfund af produkter, der adopterer - ikke køber ind i den. Så du skal slå en strategi. Og det betyder, at du opretter et præsentationsdæk.

Et prøvesystem tonehøjde fra senere 2016

Vores typiske strategi pitch-præsentation dækker emner som:

  • Definition af hvad et designsystem er, og hvorfor det er vigtigt.
  • Historier, der udtrykker værdi, såsom at parre de universelle og du troede knapper var nemme med andre udfordringer, der er relevante for en organisation.
  • Foreslået rækkevidde, timing, produkter og processer inkluderet i 1.0 frigivelse, efterfølgende produktoptagelse og support og systemudvikling og vedligeholdelse der følger (hvordan og hvornår).
  • Anbefalet sammensætning af tværfaglige systemteams, og hvordan de engagerer bidragydere og beslutningstagere (hvem der).

Få en forpligtelse til formål og team

Vær ikke genert. Du beder om at lancere et nyt produkt i din organisation, så du bliver nødt til at spørge. Hvad beder du om?

  1. Personalets kapacitet til at fremstille og vedligeholde et system nu og efter lanceringen.
  2. Produkter - ofte mange mange produkter - for at foregribe ansvaret for at foretage væsentlige ændringer engang i fremtiden.
  3. Et samfund og en organisation, der udvikler, hvordan de fungerer, deler arbejde, træffer beslutninger og mere. Organisatoriske forandringer er svære.

Vi forlader ofte en tonehøjde med direkte eller stiltiende godkendelse for at komme videre med det. Jeg er bøjet endnu mere, når en administrerende direktør går hen til mine interne jævnaldrende, og jeg hyler bagefter og siger:

Hvad du delte er meget overbevisende og værdifuld. Godt arbejde. Lad mig vide, hvad du har brug for for at få dette til.

Alligevel betyder mundtlige godkendelser ikke at starte i morgen. Nogle gange stopper tingene op.

Mange faktorer kan bremse fart. Måske udløste din første tonehøjde en opfølgende tonehøjde til operationer og HR for at skifte personale. Måske er du nødt til at vente til næste runde i en virksomheds kvartalsvise driftsbudgetproces. Eller der er simpelthen en overgangsperiode, da systemteamet skifter fra produktteamforpligtelser. Bliv kurset! Bliv vedholdende! Du kommer derhen.

På et tidspunkt begynder du officielt at oprette et system med godkendelse.

Start en 1.0-udgivelse

Du har sikret dig et organisatorisk mandat og en gruppe designere, ingeniører, ledere og andre. Omfanget er klart. Det er tid til at designe, bygge og dokumentere en systemsprint efter sprint for at komme til en første udgivelse.

Når essentielle dele dukker op, giver en alpha 0,1 tidlige adoptører en sneak peek. Efterhånden som komponentbiblioteket vokser, kan tidlig adoption begynde at bruge beta-udgivelser som 0.3 og derover.

Selvom sprints kan give trinvise udgivelser for at størkne din proces, er dit øje på prisen for frigivelsen, hvorefter alle hold vedtager. Enklere biblioteker kan tage 2-3 måneder, mens robuste komponentkataloger - fleksibel tema, sofistikeret værktøj, robust dokumentation - kan tage et par måneder længere. Ved slutningen af ​​cyklussen repræsenterer 1.0 den “store lancering”, som du offentliggør, er generelt tilgængelig for produktgrupper klar.

Leverer rækkevidde trinvis

En første udgivelsescyklus leverer noget, hvor der ikke var noget. Efterhånden som et system skrider frem, skal dets kunder, sponsorer og endda holdet selv have en idé om, hvad der vil ske ved, såvel som komfort i den upræcise tidspunkt for efterbehandling af hvert stykke.

I løbet af denne tid vil et nyoprettet team akklimatisere sig til en udviklingsproces til levering af hver del, her afbildet som design / build i orange og dokumentere / udgive i mørkegrå.

For planlægning på højt niveau er detaljerede arbejdsgange per vare ikke vigtige. Det er heller ikke rækkefølgen eller navnene på specifikke komponenter i eksemplet ovenfor (skønt det ærligt er et ret almindeligt omfang og leveringsordre). I stedet fokuserer jeg på, hvordan vores team er:

  • Leverer dele gradvist over sprints.
  • Leverer flere dele pr. Sprint senere, efterhånden som produktiviteten øges.

Hvad skal alle have tillid til? At systemteamet skal levere et indledende bibliotek - tør jeg sige “MVP?” - der kan vedtages på et forudsigeligt tidspunkt. Derfor vil jeg gentagne gange forstærke, at vi er på vej til at lancere en 1.0, der leverer et stærkt visuelt fundament og 12 til 16 UI-komponenter.

Betjen ud over 1.0-udgivelsen

Fra starten af ​​at forfølge et designsystem, selv så tidligt som dine interviews og workshops under Discovery, er det vigtigt at kommunikere, at et designsystem ikke er et projekt, det er et produkt. Det øves, leveres og vedligeholdes over tid, der ikke ender med 1.0.

Som et resultat vil jeg arbejde med lederskab for at arrangere kapacitet og processer til det, der er næste, da teamet er midt i en intens første udgivelsescyklus.

Den anden udviklingscyklus afregnes også i en regelmæssig kadence af planlægning og levering, såsom kvart på seks eller syv sprints. Målet er ikke at lancere et uventet 2.0, som ville være for tidligt og tumult. I stedet for i modsætning til et intenst skub til 1.0, skal teamet begynde at udføre med disciplin og blive opfattet som "forretning som sædvanlig."

Skift fra formation til operationer

Dette igangværende program kræver en drejning fra en formativ til operationel tankegang. Ikke længere begrænset til at levere kernefunktioner, diversificere aktiviteter til:

  • Udvidelse, optimering og rettelse af fejl for at bevare, hvad der er der.
  • Levering af nye funktioner, der er vigtige for virksomheden.
  • Koordinering og støtte af produktadoption med træning, parret integration, hjælp, overvågning og rapportering.
  • Dyrkning af samfund af indflydelse og bidrag på tværs af designere og ingeniører.
Fremhævelse af en adoptionsplan bringer fokus på forholdet mellem et system og produkter, det tjener

Især kræver bevidst, fokuseret og krævet samarbejde at hjælpe en produktorganisation med at indføre et designsystem. Vær udstyret med et kort præsentationsdæk og demo, og klar til at præsentere det igen og igen og igen. Fremhævelse af vedtagelse i en plan på højt niveau skaber et nyttigt fokus på dine vigtigste forhold: et system og alle dets vedtagende produkter.

Invester programmet i regelmæssige tidsintervaller

Disse perioder opretholder et voksende bibliotek, men skal også fortsætte med at levere påviselig forretningsværdi. Ligesom et systems egne mønstre bygger planlægning og levering af programmet over trin et mønster af nyværdigt fremskridt, synkronisering med produkter og køreplan.

For hvert kvartal kunne du levere epos som:

  • I 3. kvartal er navigationskomponenter, mønstre og lydhør layout.
  • I Q4 varierede advarende komponenter med redaktionel vejledning plus bevægelse!
  • I første kvartal næste år datavisualisering, diagrammer og robuste illustrationer.
  • I 2. kvartal næste år en bred underkatalog over helte- og indholdskomponenter.

Forlængelse af tidsskalaen endnu mere, vokser modne systemprogrammer til at etablere mål eller temaer, der genovervejes årligt og spores ligesom ethvert andet produkt, portefølje og program på tværs af en virksomhed.

Dette kan virke langt væk eller endda skræmmende, når du får et system fra jorden. Men selv når du leverer det væsentlige først, kan du bruge koncepter med regelmæssig planlægning af kadence, epos og temaer til at illustrere, hvor din systemrejse kan gå.

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!