Design System Tiers

Tid til at modne systemer til understøttelse af arbejdsniveauer

Vores designsystem, sandhedskilden. Enkelt, centralt, perfekt. Det ene sted, hvor du finder alle svarene. Er systemer bestemt til kun at have et sæt kun de bedste ting? Jeg er ikke overbevist.

Hvorfor begrænse designsystemer til kun ting af højeste kvalitet, der er relevante for alle? Er der plads mellem et designsystemets kerne og adopterere, der giver mindre perfekte funktioner at leve på? Et sted at dele arbejdsideer, køre eksperimenter og stabilisere kvalitet over tid?

Jeg foreslår, at designsystemer giver mulighed for en taksonomi af fleksible lag under en kerne af højeste kvalitet. Ved hjælp af lag kan systemer trinvis forbedre kapaciteter og kvalitet af meningsfulde funktionssæt og fremme ideer fra et team eller en gruppe opad gennem en arkitektur, som alle deler.

Et system kan understøtte lag

Ideer boble op. De starter muligvis med en idé i en enkelt persons sind. Denne idé er nyttig for en samarbejdspartner i nærheden. Andre indser gradvist, at de deler behovet. Til sidst kan en idé - eller måske ikke - være relevant for alle. Vi kan arkitekten designe systemer, der afspejler sådanne niveauer.

Arkitekturer starter - men behøver ikke stoppe - med to lag af et system, og det vedtager produkter. Et hierarki på to niveauer er enkelt og let at forstå.

Alligevel er ikke alle komponenter og andre funktioner lige så værdifulde, hærdet til samme niveau af kvalitet eller relevante for så mange mennesker. Jo højere niveauet er, jo bredere deles noget.

Takeaway: Antag, at når et system vokser, kan det drage fordel af yderligere lag for at oprette og dele designaktiver, kode og dokumentation. Nedre niveauer kan være mellemrum til funktioner, der ikke behøver at høre til et systems kerne, der er synlig for alle.

Øverst er en "kerne" relevant for alle

Når et system afslører funktioner af varierende kvalitet og relevans, skal en kerne adskilles som den højeste kvalitet og mest relevant for alle.

På dette tidspunkt er et designsystems kerne forudsigelig: en visuel stils farve, typografi, ikonografi og plads anvendt på komponenter som overskrifter, knap, ikon, afkrydsningsfelt, input og andre, som alle tydeligvis har brug for. Indtil du har kerne ret, kan du ikke udforme de sofistikerede ting med selvtillid.

Kernen styres og dokumenteres centralt af en kernegruppe eller udpeget designsystemteam (er). Samfund med design og teknik har stor indflydelse, men de har også brug for et team, der peger mod det, der er ansvarlig og ansvarlig for en kernes vedvarende succes.

Afhentning: Når først nye systemdele begynder at dukke op, skal du udpege en "kerne" -niveau, der er nyttig for alle adoptører og vedligeholdes af en identificerbar kernegruppe. Kald det, hvad du vil — kerne, base, fundament, hvad som helst - for klart at betegne disse mest væsentlige funktioner øverst.

Start med lag til INNE forretningsenheder ...

Funktionssæt dannes naturligt inden for organisatoriske grænser, såsom grupper A, B, C og D afbildet nedenfor.

Tier 2-delsystemer, der understøtter forskellige forretningsområder (A, B, C, D)

Mine observationer på tværs af designsystemer antyder, at dette allerede sker, men på ad hoc-måde, der ikke er overvåget af et systemteam. Et systemteam tilbød Core kit med Sketch-aktiver og komponentkode. I naturen lavede platformdesignere i gruppe A & B tydelige skitsekitudvidelser, og en ingeniør havde lavet et "C Kit" af komponentkode til deres gruppe. I sådanne tilfælde kunne et systemprogram modellere og levere værktøjer til sådanne udvidelser af design og kode.

... Og også styrke Tiers ACROSS-enheder

Et system behøver ikke at begrænse et funktionssæt til organisatoriske grænser. Lagene kan også gøre det muligt for et samfund at dele på tværs af grænser. Jeg vil minde systemteamene om, at deres synlighed på tværs af produkter ikke kun er en styrke, men et ansvar. At opdage muligheder og udløse forbindelser er en del af jobbet, selvom ud over hvad der er i deres systemkerne.

Overvej et økosystemets flere berøringspunkter, der integrerer en rich-text editor. Det er ikke kun et redigeringsvindue med afsnit, overskrifter, lister og andet indhold. Der er værktøjslinjer til formatering. Dialoger til upload. Fuld skærm skifter for at komponere fordybende. Redaktører er ikke billige. Når et hold i gruppe A tager det videre, hører gruppe B om det, og en delt investering tager form.

I det samme økosystem kan andre fælles investeringer opstå, såsom eksperimenter med komponenter til navigation, sociale og andre funktioner under kernen.

Takeaway: Vær en matchmaker, der forbinder indsatser på tværs af hold. Tilby værktøjer - repo- og komponentstilladser, skitskabeloner, doc-udfyld-blanke emner - for at starte samtaler, så deres første date vokser til et frugtbart forhold.

Udvid brugen af ​​systemværktøjer til lagret arbejde

Så hvordan ville du rulle lag inden for en organisation? En tilgang ville være at pilotere en første fase for et par sæt på tværs af teams - redaktør, navigation, social. Dette vil give dig muligheden for at prøve adgangsrettigheder, onboarding, workflow og endda potentiel promovering. Efterhånden som disse piloter lykkes, uddyber du værktøjet i en anden fase for at understøtte mere autonom og omfattende anvendelse på et tredje niveau inden for teams.

Et system, der understøtter cirka 25 teams, bevidst instaluerede deres core-ui-arkitektur i et søskende salgs-ui-lager afhængigt af core-uis komponenter og stil. Salg-ui-kataloget ekspanderede hurtigt i forhold til den langsommere udvikling. Kontrollerne var løse. Leveringsfrister blev overholdt. Nogle så et rod.

Eksempel: Salgsorganisation, der bygger et udvidet komponentbibliotek

Alligevel så systemteamet mulighed. Der var klare kandidater til at promovere fra salgs-ui til core-ui. Værktøjer til forbedring af kvalitet (fnugning, visuel regressionstest) greb fat i en tidligere ragtag-gruppe. Frem for alt integrerede salgsteam core-ui-funktioner i alt, hvad de gjorde uden en anden tanke. Uden at vide, var de nu et andet niveau i det designsystem.

Takeaway: Forretningsenheder og produktlinjer er motiverede til at arbejde hurtigt, opfylde mål og genbruge med deres tilstødende pladser. Systemværktøjer kan stillads op med hurtig, systematisk design og udviklingspraksis for at anspore grupper til at bevæge sig fremad uden nødvendigvis at komplicere systemets kerne.

Modeltilladelser til synlighed og kontrol

Når et designsystemteam understøtter en kerne, er det klart, at de er ansvarlige for at udføre meget af design, kodning og dokumentation af denne kerne. Som et resultat vil de se foreslåede bidrag, der ændrer denne kerne meget omhyggeligt. For ethvert niveau under kernen har flere mennesker imidlertid brug for mere åbne tilladelser til at bidrage, udvide og vedligeholde aktiver.

Hold kan bruge applikationer som Abstract og Lingo App til at distribuere Sketch-bibliotekets aktiver til deres system. Sættet (r) giver en kerneknap, afkrydsningsfelt og mange andre komponenter til hele samfundet, skønt kun kerneteammedlemmer (og nøglepartnere) har adgang til redigering.

Yderligere kits (såsom Produkter, Konto, Gave og Checkout) kunne organisere et andet lag undergrupper efter erfaring. Disse undergrupper kan udvide komponenter som kort og formularer og inkluderer også aktiver (som billeder) og komponenter (som Account Header) kun relevante for deres team. Mens hvert kit er synligt for hele designfællesskabet, er hvert kit's redigeringsrettigheder begrænset til designere i den forretningsenhed plus kerneteamet.

Afhentning: Model tilladelser til maksimal synlighed og minimer risikoen. Jo flere designere og udviklere kan se arbejde, der udføres i andre grupper, de kan danne forbindelser, reducere redundans og deltage i et eksperiment.

Opret navneområdet centralt

Når et system tilskynder til bidrag fra forskellige grupper, kan det blive det vilde vilde vest. Du er nødt til at holde øje med prisen: et bibliotek, der deler en arkitektur uden konflikt og kollisioner. Ingen har brug for afkrydsnings-knap, handling-knap og boks-med-afkrydsningsfelt-i-det-knap rullende rundt.

Det kræver, at navneområdet styres for at sikre, at nye funktioner:

  • overlap ikke med andre funktionsfunktioner
  • kolliderer ikke med andre funktionsnavne, når det bruges eller promoveres
  • minimerer navneændringer, så tidlige adoptører ikke behøver at refaktorere senere

At navngive er hårdt. Det får vi alle sammen. Men at omdøbe senere kan virkelig skjule værkerne. Et system opretter et delt rum, der kræver et ordforråd på tværs af udviklere og designere. Når et system spreder funktioner på tværs af sæt, skal du derfor normalisere, hvad hver ting er navngivet, og hvordan den er grupperet.

Takeaway: Sammenlæg forsigtigt navnene på sæt og funktioner, især komponenter. Vær klar over, hvem der kuraterer navngivning og gennemgår de foreslåede navne, når de dukker op. Dette kan endda være en bestemt person eller en lille gruppe, der virkelig er talentfulde og / eller brænder for det.

Udsæt lag i dokumentation

Ligesom holdene begynder at lave forskellige funktionssæt, vil andre gerne bruge de funktionssæt, de er interesseret i. De vil heller ikke se funktionssæt, de ikke er interesseret i. Dette påvirker, hvordan funktioner præsenteres i dokumentation og værktøjer, såsom:

  • Klassificering af dokumentationssidens navigation, katalogstatus og detaljsider
  • Emballagekode og designaktiver, såsom skitsesymboler
  • Prioritering af kerne og bredt relevante sætter mere end dem, der er mindre relevante
  • Tilpasning, så brugerne kan konfigurere, hvad de gør og ikke kan se
  • Integration af dokumentation centralt i en ejendom på et sted eller - gisp! - overvejer flere dokumentsider?

Takeaway: Tilføjelse af sæt ud over en kerne er en udfordring til informationsarkitektur for værktøjer og dokumentation. Det tvinger spørgsmål om klassificering, organisering og prioritering. Forestil dig en måltilstand, og bygg derefter værktøjer gradvist mod den, en funktion ad gangen.

Jo højere niveau, jo højere kvalitet

En kernes funktioner skal være af højeste kvalitet. Når lagene kommer frem, vil kvaliteten under kernen variere. Atlassians Atlaskit-kodepakker antyder et andet lag med funktionsgrupper til både forretningsenheder (bitbucket) og funktioner på tværs af grupper (editor, hjem, søgning og navigation), hvor kvaliteten af ​​nogle kan være lavere end hvad der følger med kernen. IBM Carbon's webstedsdokumentation antager to niveauer: en implicit kerne og en "eksperimentel" anden lag:

”Eksperimentelle komponenter, design og andre ressourcer præsenteres til test og feedback. De er ikke beregnet til produktionsbrug. ”- IBM Carbon

Funktionskvalitet bør forbedres, jo højere en funktion stiger. Som et resultat skal et system tydeliggøre for producenterne, hvor godt hver funktion skal laves, og for brugerne, hvor godt hver funktion er lavet. Det er op til et system med to eller flere lag at differentiere og tydeligt kommunikere kvalitet på hvert niveau.

Funktionskvalitetskriterier efter niveau

En model strammer kvalitetskontrol baseret på, hvor udbredt funktionen vil blive brugt på tværs af forretningsenheder:

  • "Inden for gruppe" -delingsfunktioner skal passere browserkontrol og kodning af fodring, adressere udfordringer til tilgængelighed, der er relevante for dem, der fremstiller det, og være stylet på en måde, der er i overensstemmelse med det centrale designsprog.
  • "På tværs af grupper" -fladefunktioner skal også være lydhøre, bruge BEM CSS-metodologi, semantisk version, logændringer, indkapsling af stil afhængig af designtokener, opsætningsenhed og visuel regressionstest og være godkendt af det komplette design- og / eller udviklingssamfund.
  • Top-kernetrin-funktionsniveauer skal også bestå en omfattende tilgængelighedsgennemgang, aktivere størrelse (S, M, & L), arbejde på tværs af baggrunde (hvid, lys, mørk, sort og brand) og aktivere tilpassede tema-, analyser- og internationaliseringsfunktioner som f.eks. højre mod venstre.

At køre et system i dag og næppe imødekomme niveau "inden for gruppe" -kvalitet? Jeg dømmer dig ikke. Dine adoptører kan dog være det. Så overvej hvilken kvalitet der er nødvendig, og kortlægge en sti for at komme dertil.

Afhentning: Identificer klare og opnåelige kriterier for at placere funktioner. For dem, der løber hurtigt og løst, skal du etablere minimumsforventninger til ikke at bremse dem. Når brugen af ​​en funktion øges (og tilliden stiger), skal du klarlægge, hvilke skridt der er næste til at hærde den til forfremmelse. For andre, der kigger ind og er interesserede i ikke-kernefunktioner, skal du sikre dig, at de ved, hvad de får fat på.

Brug lag i samtaler om bidrag

Tiers giver en krog til at tale om, hvordan funktioner fremmes fra smalle eksperimenter til udbredt anvendelse ved hjælp af klare kriterier. Denne funktion bliver nødt til at gå et sted, og lagene giver beskyttelsesrammer i samtaler som:

  • Lad os organisere redigeringsfunktioner som et sæt ... ("Hvad?")
  • ... bygget i niveau 2 ... ("Hvor?" Og "Hvor godt?")
  • ... at vi har brug for 3 sprints ("Hvor meget koster det?") ...
  • ... at servere produktgrupper A og C, men ikke B, D eller E ("Hvem?").

Hvorfor? Fordi systemer tilbyder en arkitektur til at designe mere konsekvent, bygge mere effektivt og opnå højere kvalitet. Der er ingen grund til at begrænse den værdi af at gøre tingene godt til kun systemteamet.

Takeaway: Du kan kortlægge “bidrag” muligheder som forfremmelse gennem niveauer af et system. Disse bidragydere har brug for et systems arkitektur til at bygge sammen med og systemteammedlemmer for at identificere muligheder og hyrde processen.

Tiers vil lykkes, når et samfund vedtager et sprog og en arkitektur til deling. Værktøjet vil udvides for at byde flere deltagere velkommen, og aktiviteten vil være synlig inden for og på tværs af forretningsenheder. Vi holder øje med.