Visual Breaking Change i designsystemer

Vi respekterer kode-API'er. Men hvad med farve, type og plads?

# 4 af 6 i serien Releasing Design Systems:
Output | Kadens | Versioner | Breaking | Afhængigheder | Behandle

Designsystemer etablerer en visuel basistil, som er en væsentlig afhængighed. Disse valg - farve, typografi, plads og mere - er robust specificeret og forventes stabilt, forudsigeligt at ændre frigivelse ved frigivelse. Når en adopter opgraderer, bør et designsystem ikke ødelægge deres ting uventet.

Så spørg dig selv ...

Kan adoptører opgradere til en mindre udgivelse med tillid til, at deres UI ikke går i stykker på grund af et systems visuelle ændringer?

Semantic Versioning (SemVer) tilbyder klare kriterier for at kommunikere ændringer på tværs af udgivelser ved hjælp af større, mindre og patch-betegnelser. Hvert designsystem, jeg støder på, bruger SemVer og overvåger ændringer i deres pakkes applikationsprogrammeringsgrænseflade eller API. Dette er velkendt område for udviklere, der koder JavaScript-rekvisitter og HTML-markup. Bryd din API, og din næste version skal øge versionen til en næste større udgave, f.eks. Fra 1.4.0 til 2.0.0.

Specificering af en grænseflade til kompositionel visuel stil undgår os. Det føles så svært at definere klare, enkle regler for at overvåge stilændringer. Systemproducenter kæmper for at formulere, hvad eller hvorfor "Ændring af denne stil bryder en adopteres UI" versus "Ændring af denne stil gør ikke." Få systemteam dokumenterer sådanne kriterier. Jeg spørger “Hvilke specifikke typer af visuelle ændringer udløser en større version for dig?” Deres svar: ¯ \ _ (ツ) _ / ¯.

I denne artikel foreslår jeg, at kriterier for farve, typografi og rum i det mindste garanterer kriterier, der udgør brudændring. Der er også andre egenskaber, der skal overvejes. Et designsystem kan definere, dokumentere og kommunikere disse kriterier, så adoptører kan opgradere frigivelse ved frigivelse med tillid.

Breaking Colour

De fleste systemhold føler sig trygge ved at indstille en primærknapps baggrundsfarve. Måske er deres motivation for at forbedre kontrasten mod en normalt hvid tekstetiket. ”Lad os mørkne floden lidt,” siger de. "Vi forbedrer knappens tilgængelige farvekontrast fra en AA til AAA vurdering."

Justering af baggrundsfarve på en primær knap

Det er bestemt, at vedtagelse af teams ikke bør tilsidesætte et standardknappes farvesæt. At tilsidesætte et systemvalg adskiller forbindelsen med et system. På det tidspunkt er en adopter alene. Derfor er det sikkert at justere skyggen af ​​den primære knaps baggrundsfarve og er ikke en ødelæggende ændring.

Ændring af farver andetsteds kan dog sætte adoptører i fare. Overvej følgende scenarier.

Eksempel: Systemtekst på brugerdefinerede baggrunde

Forestil dig et systemteam, der finjusterer interaktivt blåt for at forbedre farvekontrasten. Den interaktive blå af v1.4.0 var tilgængelig på en hvid baggrund, men mislykkedes på kulbaggrunden.

Farvekontrastkontrol via contrast-grid.eightshapes.com

Så for v1.5.0 justerede teamet interaktivt-blåt til en lysere, mere mættet tone, der arbejdede på både hvidt og kul.

Justering af tekstfarve på et spøgelsesknappemærkat på uforudsigelige baggrunde

Imidlertid havde en adopter brugt Ghost-knappen afhængig af denne farve på en lysegrå baggrund. Efter systemændringen er etiketens tekstfarvekontrast utilgængelig. Dit system brød deres produkt.

Eksempel: Systembaggrunde med tilpasset overlagt tekst

Forestil dig på samme måde, at et system mørkere kortkomponentens baggrundsfarve. Kortets indholdsområde inkluderer en "sikker" indholdscontainerzone, hvor adoptører indsætter det indhold og den markering, de ønsker.

Justering af baggrundsfarve på et kort, der tillader indeholdt tilpasset indhold

I den formodentlig sikre zone tilføjede en adopter sekundær tekst, der, selv om den var let moderat grå, bestod en farvekontrasttest. Efter systemændringen er farvekontrasten ikke længere tilgængelig. Dit system brød deres produkt.

Forestil dig, at dit systems mindre udgave inkluderede disse justeringer. Bagudkompatibel, sagde du? Ingen risiko ved opgradering, stolede de på? Nix! Dit system brød deres produkt!

Evaluer derfor ændrede farveegenskaber for at bestemme, om et system har ændret sig, såsom:

  • Tekstfarve, der kunne vises over en adopteres baggrundsfarve, billede eller anden tekstur.
  • baggrundsfarve, som en adopteres tekstfarve er lagt på.
  • baggrundsfarve, kantfarve, tekstfarve, kasseskygge eller anden egenskab sammensat ved siden af, over eller under en anden komponents kant eller indhold for at mindske kontrasten mellem elementerne.

Tilgængeligheden førte til disse eksempler. Der er også æstetisk risiko, idet velmenende systemændringer kan forstyrre den farverige harmoni opnået af en produktdesigner. Farveinteraktioner bugner i hele UI, som en systemdesigner ikke kontrollerer eller har synlighed til.

Takeaway: Begynd at bryde ændre samtale med farvekriterier. Det er lettere at overføre risiko, det er objektivt målbart, og det er bundet til tilgængelighed, der bringer lidenskaber. Bevæbnet med et par kriterier, kan du gå videre til andre bekymringer.

Breaking Typography (Af indpakning)

Typografi er en kerne facet af enhver visuel stil. Hold ønsker at få det helt rigtigt. Og der er så mange opkald til at indstille: font-familie, font-vægt, font-størrelse, tekst-transformation, liniehøjde, letter-afstand og mere.

Ikke alle oplever risiko for brud, hvis et system justerer typografi. Ved indholdstunge oplevelser kan hvert elements indhold være uforudsigeligt, af forskellig længde og designet til at indpakke og reagere på ændringer i visningsbredden.

For tættere grænseflader skal typografi være nøjagtig. Designere slibes i timevis med finjustering af typografi og arrangerer etiketter, der passer til kompakte områder. Hvis du justerer systemtypografi, kan elementerne indpakkes eller beskæres på uventede måder.

Eksempel: Indpakning af faner er forfærdelige

Forestil dig, at dit system justerer fanen labelfont-vægt fra normal til fed.

Efter en mindre version af opgraderingen indpakkes ikke-svarende faner. Ikke godt.

En adopter opgraderinger. Deres eksisterende ikke-svarende faner overskrider allokeret plads, så de indpakkes. Skrækkelige! Dit system brød deres produkt.

Eksempel: Letter Spacing Mayhem

Brand-retningslinjer udvikler sig, hvilket giver nyt overskriftshierarki og stil. Således tilpasser dit system sig ved at øge hvert overskrifts bogstavafstand.

En adopter opgraderer deres tætte radiologi-app på én side, der er oversat til 14 sprog, sammensat af utallige kontrolpaneler, hver chock fuld af formelementer og overskrifter. De opgraderer, og UI'en er overvældet med overskrifter, der er uforudsigeligt beskåret. De kalder et krisemøde. De inviterer back-end dataingeniører, for godheds skyld! Dit system brød deres produkt!

Justering af systemtypografi kan være farligt. For dig er det en forfriskende typografisk udvikling, der nemt implementeres på tværs af et bibliotek. For dem begynder tekst ikke at opføre sig. De beskylder dig. Måske flammer de dig i # system-design Slack-kanalen. Ingen har brug for det.

Takeaway: Før 1.0.0 skal du arbejde hårdt for at eksperimentere, forfine og færdiggøre typestilarter, der passer til kundens sort. Når 1.0.0 er gået, skal du opretholde en stabil base og overveje at ændre forsigtigt. Overvej at reservere farlige skift til den næste større udgivelse. Indtil da tilføjes trinvis indbefattede funktioner, f.eks. En lang formtekstkomponent til styling, bare artikelkopi.

Breaking Space og størrelse

I det mindste kan du se farve og typografi. Plads og størrelse? Disse er sværere at definere som konkret genanvendelige, så meget mindre monitor for at bryde ændringer.

Når du ændrer en komponents boksmodelleegenskaber - polstring, margin, bredde, højde, display, boksstørrelse, placering, venstre, højre, øverste, nederste - risikerer du at påvirke layoutkomposition, der arrangerer denne komponent med andre sideelementer.

Eksempel 1: Fjernelse af lodret afstand

Dit systemteam beslutter at fjerne de anvendte formkontroller for lodret afstand i form af margin-bottom. Dette påvirker ,