Visual Breaking Change i designsystemer

Vi respekterer API-koder. Men hva med farge, type og mellomrom?

Nr. 4 av 6 i serien Releasing Design Systems:
Utgang | Kadens | Versjoner | Breaking | Avhengigheter | Prosess

Designsystemer etablerer en visuell basistil som er en essensiell avhengighet. Disse valgene - farge, typografi, rom og mer - er robust spesifisert og forventes å stabil, forutsigbart endre utgivelse ved utgivelse. Når en adopter oppgraderer, skal ikke et designsystem bryte tingene deres uventet.

Så spør deg selv ...

Kan adoptere oppgradere til en mindre utgivelse med tillit til at brukergrensesnittet ikke går i stykker på grunn av systemets visuelle endringer?

Semantic Versioning (SemVer) tilbyr klare kriterier for å kommunisere endring på tvers av utgivelser ved bruk av større, mindre og lappbetegnelser. Hvert designsystem jeg møter bruker SemVer og overvåker endring i pakkenes applikasjonsprogrammeringsgrensesnitt, eller API. Dette er kjent territorium for utviklere som koder JavaScript-rekvisitter og HTML-merking. Bryt API-en din, og din neste versjon må øke versjonen til en neste større utgave, for eksempel fra 1.4.0 til 2.0.0.

Å spesifisere et grensesnitt til komposisjonell visuell stil unngår oss. Det føles så vanskelig å definere klare, enkle regler for å overvåke stilendringer. Systemprodusenter sliter med å formulere hva eller hvorfor "Endring av denne stilen bryter brukerens brukergrensesnitt" kontra "Endring av stilen gjør det ikke." Få systemteam dokumenterer slike kriterier. Jeg spør “Hvilke spesifikke typer visuelle endringer utløser en større versjon for deg?” Deres svar: ¯ \ _ (ツ) _ / ¯.

I denne artikkelen foreslår jeg at minst farge, typografi og rom garanterer kriterier som utgjør bryteendringer. Det er andre egenskaper du bør vurdere også. Et designsystem kan definere, dokumentere og kommunisere disse kriteriene slik at adoptere kan oppgradere utgivelsen ved utgivelse med tillit.

Breaking Color

De fleste systemteam føler seg trygge når de stiller inn bakgrunnsfargen på en primær knapp. Kanskje deres motivasjon er å forbedre kontrasten mot en vanligvis hvit tekstetikett. "La oss mørkne flisen litt," sier de. "Vi forbedrer knappens tilgjengelige fargekontrast fra en AA- til AAA-rangering."

Justere bakgrunnsfargen på en primærknapp

Visstnok bør adoptere team ikke overstyre et standardfargesett for en standardknapp. Å overstyre et systemvalg skiller forbindelsen med et system. På det tidspunktet er en adopter på egen hånd. Derfor er det trygt å justere skyggen til bakgrunnsknappens bakgrunnsfarge og er ikke en ødeleggende forandring.

Å endre farger andre steder kan imidlertid sette adoptere i fare. Tenk på følgende scenarier.

Eksempel: Systemtekst på tilpassede bakgrunner

Se for deg et systemteam å finjustere interaktivt blått for å forbedre fargekontrasten. Den interaktive blå av v1.4.0 var tilgjengelig på hvit bakgrunn, men mislyktes på kullbakgrunnen.

Kontroll av fargekontrast via contrast-grid.eightshapes.com

Så for v1.5.0 justerte teamet interaktivt-blått til en lysere, mer mettet tone som fungerte på både hvitt og trekull.

Justere tekstfargen på et spøkelsesknappetikett på uforutsigbare bakgrunner

Imidlertid hadde en adopter brukt Ghost-knappen avhengig av den fargen på en lysegrå bakgrunn. Etter systemendringen er etikettens tekstfargekontrast utilgjengelig. Systemet ditt brøt produktet deres.

Eksempel: Systembakgrunner med tilpasset overlagt tekst

Tenk på samme måte at et system mørkere farge på kortkomponentens bakgrunn. Kortets innholdsområde inkluderer en "sikker" innholdscontainersone der adoptere setter inn alt innhold og markering de ønsker.

Justere bakgrunnsfargen på et kort som tillater inneholdt tilpasset innhold

I den antagelig sikre sonen la en adopter sekundær tekst som, mens den var subtile moderat grå, besto en fargekontrasttest. Etter systemendringen er fargekontrasten ikke lenger tilgjengelig. Systemet ditt brøt produktet deres.

Se for at systemets mindre utgivelse inkluderte disse justeringene. Bakoverkompatibel, sa du? Ingen risiko i å oppgradere, stolte de på? Nei! Systemet ditt brøt produktet deres!

Evaluer derfor endrede fargeegenskaper for å finne ut om et system endret seg, for eksempel:

  • Tekstfarge som kan vises over en adopteres bakgrunnsfarge, bilde eller annen tekstur.
  • bakgrunnsfarge som en adopsers tekstfarge er lagt på.
  • bakgrunnsfarge, kantfarge, tekstfarge, boksskygge eller annen egenskap sammensatt ved siden av, over eller under en annen komponents kant eller innhold for å redusere kontrasten mellom elementene.

Tilgjengeligheten drev disse eksemplene. Det er også estetisk risiko ved at velmenende systemendringer kan forstyrre den fargerike harmonien oppnådd av en produktdesigner. Fargeinteraksjoner florerer i hele brukergrensesnittet som en systemdesigner ikke kontrollerer eller har synlighet til.

Takeaway: Begynn å bryte endre samtale med fargekriterier. Det er lettere å formidle risiko, det er objektivt målbart, og det er knyttet til tilgjengeligheten som vekker lidenskaper. Bevæpnet med noen få kriterier, kan du gå videre til andre bekymringer.

Breaking Typography (By Wrapping)

Typografi er en kjernefasett i enhver visuell stil. Lag ønsker å få det helt riktig. Og det er så mange numre å stille inn: fontfamilie, skriftvekt, skriftstørrelse, teksttransformasjon, linjehøyde, bokstavavstand og mer.

Ikke alle opplever risiko for å bryte hvis et system justerer typografi. For innholdstunge opplevelser kan hvert elements innhold være uforutsigbart, av varierende lengde, og designet for å pakke inn og svare på endringer i visningsbredden.

For tettere grensesnitt må typografi være presis. Designere sliper i timevis med finjustering av typografi og ordner etiketter for å passe på kompakte områder. Hvis du justerer systemtypografi, kan elementene deres pakke eller beskjære på uventede måter.

Eksempel: Innpakningstapper er forferdelig

Se for deg at systemet justerer labelfont-vekt fra normal til fet skrift.

Etter en mindre versjon oppgradering, svarer ikke-svarende faner. Ikke bra.

En adopter oppgraderinger. Deres eksisterende ikke-svarende faner overskrider tildelt plass, slik at de pakker seg inn. Uhyggelig! Systemet ditt brøt produktet deres.

Eksempel: Letter Spacing Mayhem

Retningslinjer for merkevarer utvikler seg, og gir nytt overskriftshierarki og stil. Dermed tilpasser systemet ditt ved å øke bokstavavstanden for hver overskrift.

En adopter oppgraderer sin tette, en-siders radiologi-app som er oversatt til 14 språk, sammensatt av mange kontrollpaneler, hver chock full av formelementer og overskrifter. De oppgraderer, og brukergrensesnittet er full av overskrifter som er uforutsigbart beskåret. De kaller et krisemøte. De inviterer back-end dataingeniører, for godhet skyld! Systemet ditt brøt produktet deres!

Å justere systemtypografi kan være farlig. For deg er det en forfriskende typografisk evolusjon som brukes enkelt på tvers av et bibliotek. For dem begynner tekst å oppføre seg ikke. De klandrer deg. Kanskje de flammer deg i # system-design Slack-kanalen. Det er det ingen som trenger.

Takeaway: Før 1.0.0, arbeide nøye for å eksperimentere, avgrense og ferdigstille typestiler som passer kundens utvalg. Når 1.0.0 har passert, oppretthold en stabil base og vurder å endre forsiktig. Vurder å reservere farlige skift til neste større utgivelse. Inntil da, trinnvis legge til inneholdte funksjoner, for eksempel en Long Form Text-komponent for styling bare artikkelskopi.

Breaking Space og størrelse

I det minste kan du se farge og typografi. Plass og størrelse? Disse er vanskeligere å definere som konkret gjenbrukbare, enn si overvåke for å bryte endringer.

Når du endrer egenskapene til en komponent i boksens modellegenskaper - polstring, margin, bredde, høyde, skjerm, størrelse på boks, plassering, venstre, høyre, topp, bunn - risikerer du å påvirke layoutkomposisjonen som ordner den komponenten med andre sideelementer.

Eksempel 1: Fjerne vertikalt avstand

Systemteamet ditt bestemmer seg for å fjerne kontroller for vertikal avstand brukt skjema i form av margin-bottom. Dette påvirker ,