Visuele brekende verandering in ontwerpsystemen

We respecteren code-API's. Maar hoe zit het met kleur, type en ruimte?

# 4 van 6 van de serie Releasing Design Systems:
Uitgangen | Cadans | Versies | Breken | Afhankelijkheden | Werkwijze

Ontwerpsystemen zorgen voor een visuele basislijn die een essentiële afhankelijkheid is. Deze keuzes - kleur, typografie, ruimte en meer - zijn robuust gespecificeerd en zullen naar verwachting stabiel, voorspelbaar van release tot release veranderen. Wanneer een adoptant een upgrade uitvoert, mag een ontwerpsysteem zijn spullen niet onverwacht breken.

Stel jezelf dus de vraag ...

Kunnen adopters upgraden naar een kleine release in het vertrouwen dat hun UI niet zal breken vanwege de visuele veranderingen van een systeem?

Semantic Versioning (SemVer) biedt duidelijke criteria voor het communiceren van veranderingen tussen releases met behulp van major-, minor- en patch-aanduidingen. Elk ontwerpsysteem dat ik tegenkom, gebruikt SemVer en controleert veranderingen in de applicatie-programmeerinterface of API van hun pakket. Dit is bekend terrein voor ontwikkelaars die JavaScript-props en HTML-markeringen coderen. Breek uw API, en uw volgende versie moet de versie ophogen naar een volgende belangrijke release, zoals van 1.4.0 tot 2.0.0.

Het specificeren van een interface naar visuele compositorische stijl ontgaat ons. Het is zo moeilijk om duidelijke, eenvoudige regels te definiëren om stijlwijzigingen te volgen. Systeemmakers worstelen om te articuleren wat of waarom "Het veranderen van deze stijl breekt de gebruikersinterface van een gebruiker" versus "Het veranderen van die stijl niet." Weinig systeemteams documenteren dergelijke criteria. Ik vraag "Welke specifieke soorten visuele veranderingen leiden tot een belangrijke versie voor u?" Hun antwoord: ¯ \ _ (ツ) _ / ¯.

In dit artikel stel ik voor dat ten minste Kleur, Typografie en Ruimte criteria rechtvaardigen die een brekende verandering vormen. Er zijn ook andere eigenschappen om te overwegen. Een ontwerpsysteem kan deze criteria definiëren, documenteren en communiceren, zodat adoptanten release voor release met vertrouwen kunnen upgraden.

Brekende kleur

De meeste systeemteams voelen zich veilig bij het afstemmen van de achtergrondkleur van een primaire knop. Misschien is hun motivatie om het contrast te verbeteren tegen een meestal wit tekstlabel. "Laten we de wintertaling een beetje verduisteren", zeggen ze. "We zullen het toegankelijke kleurcontrast van de knop verbeteren van AA tot AAA."

Achtergrondkleur van een primaire knop aanpassen

Zeker, het adopteren van teams mag de kleurenset van een standaard primaire knop niet overschrijven. Het negeren van een systeemkeuze verbreekt de verbinding met een systeem. Op dat moment staat een adoptant alleen. Daarom is het aanpassen van de tint van de achtergrondkleur van de primaire knop veilig en geen blijvende verandering.

Het veranderen van kleuren elders kan echter adopters in gevaar brengen. Overweeg de volgende scenario's.

Voorbeeld: systeemtekst op aangepaste achtergronden

Stel je voor dat een systeemteam interactief blauw fijnafstemt om het kleurcontrast te verbeteren. Het interactieve blauw van v1.4.0 was toegankelijk op een witte achtergrond, maar mislukte op de houtskoolachtergrond.

Kleurcontrastcontrole via contrast-grid.eightshapes.com

Voor v1.5.0 heeft het team dus interactief blauw aangepast naar een lichtere, meer verzadigde toon die zowel op wit als op houtskool werkte.

Tekstkleur van een spookknoplabel aanpassen op onvoorspelbare achtergronden

Een adoptant had echter de Ghost-knop afhankelijk van die kleur op een lichtgrijze achtergrond gebruikt. Nadat het systeem is gewijzigd, is het tekstkleurcontrast van het label niet toegankelijk. Uw systeem heeft hun product kapot gemaakt.

Voorbeeld: systeemachtergronden met aangepaste overlappende tekst

Stel je ook voor dat een systeem de achtergrondkleur van de kaartcomponent donkerder maakt. Het inhoudsgebied van de kaart bevat een "veilige" inhoudscontainerzone waar gebruikers de gewenste inhoud en markeringen kunnen invoegen.

De achtergrondkleur van een kaart aanpassen die inhoud op maat mogelijk maakt

In die vermoedelijk veilige zone heeft een adoptant secundaire tekst toegevoegd die, hoewel subtiel matig grijs, een kleurcontrasttest heeft doorstaan. Nadat het systeem is gewijzigd, is het kleurcontrast niet langer toegankelijk. Uw systeem heeft hun product kapot gemaakt.

Stel je voor dat de kleine release van je systeem die aanpassingen bevatte. Achterwaarts compatibel, zei je? Geen risico bij upgraden, vertrouwden ze? Nee! Uw systeem heeft hun product kapot gemaakt!

Evalueer daarom de eigenschappen van gewijzigde kleuren om te bepalen of een systeem is gewijzigd, zoals:

  • Tekstkleur die boven de achtergrondkleur, afbeelding of andere textuur van een gebruiker kan verschijnen.
  • achtergrondkleur waarop de tekstkleur van een adoptant wordt gelegd.
  • achtergrondkleur, randkleur, tekstkleur, vakschaduw of andere eigenschap die naast, boven of onder de rand of inhoud van een ander onderdeel is gecomponeerd om het contrast tussen elementen te verminderen.

Toegankelijkheid reed deze voorbeelden. Er is ook een esthetisch risico, omdat goedbedoelde systeemveranderingen de kleurrijke harmonie van een productontwerper kunnen verstoren. Kleurinteracties in overvloed in de gebruikersinterface waar een systeemontwerper geen controle over heeft of geen zicht op heeft.

Afhaalmaaltijden: begin het veranderingsgesprek te onderbreken met kleurcriteria. Het is gemakkelijker om risico's over te brengen, het is objectief meetbaar en het is gekoppeld aan toegankelijkheid die passies oproept. Gewapend met een paar criteria, kunt u verder gaan met andere zorgen.

Brekende typografie (door verpakking)

Typografie is een kernfacet van elke visuele stijl. Teams willen het precies goed krijgen. En er zijn zoveel te kiezen knoppen: lettertypefamilie, lettergewicht, lettergrootte, teksttransformatie, regelhoogte, letterafstand en meer.

Niet alle ervaringen lopen het risico te breken als een systeem de typografie aanpast. Voor content-zware ervaringen, kan de inhoud van elk element onvoorspelbaar zijn, van verschillende lengte en ontworpen om te wikkelen en te reageren op veranderingen in de breedte van de viewport.

Voor dichtere interfaces moet typografie nauwkeurig zijn. Ontwerpers schuren urenlang fijnafstemmende typografie en rangschikken labels om in compacte gebieden te passen. Als u systeemtypografie aanpast, kunnen hun elementen op onverwachte manieren worden omgeslagen of bijgesneden.

Voorbeeld: verpakkingstabs zijn verschrikkelijk

Stel je voor dat je systeem het labelfont-gewicht aanpast van normaal naar vet.

Na een upgrade van de secundaire versie worden de tabbladen niet meer geactiveerd. Niet goed.

Een adoptant voert een upgrade uit. Hun bestaande niet-reagerende tabbladen overschrijden de toegewezen ruimte, dus ze lopen in. Gruwelijke! Uw systeem heeft hun product kapot gemaakt.

Voorbeeld: Letter Spacing Mayhem

Merkrichtlijnen evolueren, wat een nieuwe kophiërarchie en stijl oplevert. Uw systeem past zich dus aan door de letterafstand van elke kop te vergroten.

Een adoptant upgradet zijn dichte, enkele pagina radiologie-app die is vertaald in 14 talen, samengesteld uit talloze bedieningspanelen, elk boordevol formulierelementen en koppen. Ze upgraden en de gebruikersinterface is overspoeld met koppen die onvoorspelbaar zijn bijgesneden. Ze roepen een crisisbijeenkomst op. Ze nodigen de back-end data-ingenieurs uit, in godsnaam! Uw systeem heeft hun product kapot gemaakt!

Systeemtypografie aanpassen kan gevaarlijk zijn. Voor jou is het een verfrissende typografische evolutie die moeiteloos in een bibliotheek wordt toegepast. Voor hen begint tekst zich te misdragen. Ze geven jou de schuld. Misschien vlammen ze je in het # systeemontwerp Slack-kanaal. Niemand heeft dat nodig.

Afhaalmaaltijden: werk vóór 1.0.0 hard aan het experimenteren, verfijnen en afwerken van typestijlen die geschikt zijn voor de variëteit van de klant. Zodra 1.0.0 voorbij is, handhaaf een stabiele basis en overweeg verandering voorzichtig. Overweeg gevaarlijke shifts te reserveren voor de volgende grote release. Voeg tot die tijd incrementeel functies toe, zoals een lange tekstcomponent voor het stylen van alleen artikelkopieën.

Ruimte en grootte breken

Je ziet tenminste kleur en typografie. Ruimte en grootte? Die zijn moeilijker te definiëren als concreet herbruikbaar, laat staan ​​te controleren op het doorbreken van verandering.

Wanneer u in HTML de eigenschappen van een doosmodel van een component wijzigt - opvulling, marge, breedte, hoogte, weergave, vakgrootte, positie, links, rechts, boven, onder - loopt u het risico de lay-outsamenstelling te beïnvloeden die die component met andere pagina-elementen rangschikt.

Voorbeeld 1: verticale afstand verwijderen

Uw systeemteam besluit om toegepaste formulierbesturingselementen met verticale tussenruimte te verwijderen in de vorm van marge onderaan. Dit heeft invloed op ,