Design System Sprint 2: Én farvepalet, der styrer dem alle

En kort introduktion: Jeg er Marcin: en tidligere UX-manager og nu medstifter og CEO hos UXPin - UXPin's fulde stak-designplatform. I denne serie med indlæg rapporterer jeg om UXPins rejse med at skabe vores eget designsystem. I det første indlæg diskuterede jeg grundlæggende elementer i designsystemer (hvorfor? Hvad?). Det andet indlæg var fokuseret på oprettelse af grænsefladebeholdningen. I dag skal vi diskutere den første rigtige kamp, ​​som vores nyligt organiserede Design Operations-team var nødt til at gennemgå. Slaget om et samlet farvemønster.

Så her er alle trinene op til dette punkt:

  1. Vi ved, at vi lider af designinkonsekvens (måske det største problem inden for produktudvikling).
  2. Vi ved, at vi er nødt til at oprette et designsystem for at løse problemet.
  3. Oprettelse af en grænsefladebeholdning påpegede ikke kun flere uoverensstemmelser, som vi kan løse relativt hurtigt, men beviste også, at det er umagen værd at opbygge et designsystem.
  4. Kort efter at have afsluttet grænsefladebeholdningen, dannede vi et lille Design Operations-team (bestående af mig, vores Head of Design, en senior designer og en senior UI-arkitekt) til at opbygge vores designsystem i ugentlige sprints.

Nu skal vi klare problemet med vores farvepalet.

Farver Materiale

Hvorfor?

Først og fremmest var vores problemer med farvepaletten meget let at se. Når alt kommer til alt så virkede 116 variabler i definitionerne af farver, der blev brugt i UXPin UI, bare lidt usædvanligt.

At opbygge et konsistent farvesystem, reducere antallet af anvendte variabler og fjerne unødvendige duplikater virkede som en hurtig gevinst. Og så dedikerede vi vores første sprint til at fikse det en gang for alle.

Resultatet af vores Interface Inventory sprint - liste over 116 farvevariabler

For det andet har farver en enorm effekt på den samlede opfattelse af et digitalt produkt.

Undersøgelsen The Impact of Color on Marketing (citeret efter Jonathan Z. White, 'Designing in Colour') viser, at op til 90% af beslutninger om snapkøb udelukkende er baseret på opfattelsen af ​​farver. Mens købsbeslutninger ikke kan udlignes med brugeroplevelsen, viser undersøgelsen betydningen af ​​farve for vores overordnede kognition. Derudover kan interne relationer mellem farver gøre eller bryde oplevelsen. Så hvis der ikke er tilstrækkelig kontrast mellem teksten og baggrunden, vil brugerne have svært ved at bruge et produkt. Endelig er der en kulturel betydning, der kan føre til uventede konsekvenser (f.eks. Farven hvid betyder renhed i vestlige lande men død og sorg i Kina og Japan).

Det er dog ikke alt.

Farver er en af ​​tre mest gennemgribende byggesten til enhver grænseflade (ved siden af ​​typografi og plads). De findes i alle UI-mønstre på en eller anden måde. Det betyder, at definition af en farvepalet kan gøre designere og udviklere liv meget lettere.

En farvepalet skal være:

  • Tilstrækkelig præcis - definerer et lille antal godkendte primærfarver og et tilstrækkeligt antal accentfarver.
  • Tydeligt navngivet - udviklere og designere skal nemt kunne henvise til bestemte farver defineret i systemet. Farvenavne er let forståelige, mindeværdige og fremkalder meningsfulde samtaler mellem designere og udviklere (skyggerændringer, kontrastkorrektioner osv.).
  • Tilgængelig - både med hensyn til ekstern tilgængelighed (hvor let alle brugere opfatter farvekombinationer) og intern tilgængelighed (hvor let designere og udviklere finder og bruger paletten).

Vi så selvfølgelig ikke, hvad der kom…

Uforudsete farveudfordringer

I starten af ​​sprinten identificerede vi de største problemer, vi har brug for at løse:

  • 116 variabler defineret i vores mindre filer skal reduceres
  • Navne skal forenes i et let forståeligt format for designere og udviklere
  • Primærfarver skal være adskilt fra accenter
  • Vi skal danne en palet med et tilstrækkeligt antal gråtoner

Og det er vi nødt til at gøre uden at bryde UXPin-grænsefladen. Lyder let ikke? Ikke rigtig.

Vi gjorde med vilje UXPin-grænsefladen meget minimalistisk for at hjælpe brugerne med at fokusere mere på deres kreationer. Eventuelle levende farver vil sandsynligvis distrahere designere og udviklere fra deres arbejde.

Fordi brugere undertiden arbejder om natten i vores platform, har vores interface også en lys og mørk tilstand. Det betyder, at farvepaletten har brug for mange grå nuancer for at give tilstrækkelig kontrast i begge indstillinger.

UXPin i lystilstandUXPin i mørk tilstand

For at løse dette problem var vi nødt til at:

  • Generer en skala med internt konsistente gråtoner
  • Navngiv dem, så vores designere og udviklere kan henvise til dem uden forvirring.

Men først var vi nødt til at lære mere om det dyr, vi har at gøre med.

Farveundersøgelse

Den første del af forskningen blev afsluttet i grænsefladebeholdningsfasen.

Jeg listede alle de farver, der er defineret i mindre filer, der gemmer variabler og kategoriserede dem i henhold til vores strukturer i Mindre filer. Selvom denne metode viste os hele spektret af vores palet (som defineret i kode), gav det os ikke nok af konteksten til at forstå de næste trin. Vi vidste bare ikke, hvilke af disse grå nuancer der var mest vigtige for vores UI.

Og derfor besluttede vores modige Senior UI-arkitekt at kontrollere antallet af gange, hver farve faktisk bruges i kode. Vi antog, at nogle af de grå nuancer vil være meget gennemgribende, mens andre sandsynligvis er fejl.

For at gøre hans resultater let forbrugte, efterlod han simpelthen kommentarer til vores interface-opgørelse:

Statistik over farveforbrug på tværs af UXPin UI

Vi begyndte at bemærke nogle af farverne (f.eks. # 666666) bruges mange forskellige steder, mens andre kun bruges én gang (og er meget tæt på andre grå nuancer, der allerede er defineret i systemet).

Denne indsigt viste os endelig, hvordan vi organiserer vores palet!

Primære farver

Bevæbnet med dataene identificerede vi hurtigt alle vores primærfarver:

  • # 006CFF Blå (hovedfarvefarve)
  • # 666666 Grå
  • # FF003C Rød (fejl og farvefarve)
  • # 63ad0e Grøn (succesfarve)
  • # ffc000 Orange (advarselsfarve)
  • # 7800ff Violet
  • # ff56b1 Pink
  • # 00ffde Mint

Alle disse farver bruges flere steder i UI og spiller typisk en vigtig rolle.

Mens vi yderligere kunne opdele dem i for eksempel mærkefarver, meddelelsesfarver, marketingfarver - kæmpede vi for at skabe en fælles nomenklatur. Ethvert forsøg på underkategorier resulterede bare i forvirring.

For at forenkle tingene besluttede vi at opbevare vores farver i en spand og henvise til dem som vores primære farver. Ikke ideelt, men det er et pragmatisk trin, da mange flere farver stadig har brug for at komme til den endelige version af vores palet.

Efter at have defineret den første version af primærfarver flyttede vi derefter til opgaven at vælge accenter (sekundærfarver) og håndtere vores sult efter mange gråtoner.

Accenter bygget med funktioner

Opgaven med at definere sekundærfarver, selvom de er komplekse, kan benyttes på to måder:

  • Vilkårlige beslutninger - hvor designeren bestemmer, hvilke farver og nuancer der skal gå i paletten baseret på personlig smag.
  • Beregnede beslutninger - hvor designeren beregner, hvilke farver der går i paletten baseret på farveteori og manipulation af basale egenskaber (farvetone, mætning, lysstyrke ...).

I betragtning af kompleksiteten i alle gråtoner var vilkårlige beslutninger umulige. Vi ender med en forvirrende palet uden nok farver. Designere og udviklere ville bare vende tilbage til deres gamle rodede måder.

Så vi tog den beregnede sti i stedet.

Heldigvis har CSS-forarbejdere en meget nem måde at ændre farver på. Funktionerne i Mindre Sass kan generere en anden farve (med en given procentdel) baseret på den medfølgende farve. Hvis du f.eks. Vil gøre den blå farve, siger # 006CFF, 10% mørkere, kan du bare bruge funktionen Mindre mørkere (eller analog Sass mørkere funktion), som denne:

mørkere (# 006CFF, 10%) // Returnerer # 0056cc

Denne funktion returnerer således en lidt mørkere nuance af blå (# 0056cc).

CSS-forarbejdere er geniale til at generere farver konsekvent og tydeligt. I stedet for at komme med forskellige gråtoner, kan vi bare generere alt, hvad vi har brug for med enkle funktioner! I betragtning af deres hurtighed og lethed sluttede vi med at bruge Less-funktioner til at generere vores grå skala.

Men der var kun et problem: selvom denne tilgang fungerer godt i kode, er den ikke rigtig tilgængelig for designere. Af en eller anden grund gør både Sketch og Photoshop det ekstremt svært at arbejde med enkle farvemanipulationer:

  • Sass and Less bruger HSL-farveformat til at manipulere, siger, lysstyrke, af farver
  • Sketch og PS er afhængige af HSB-format

Dette skaber en inkonsekvens mellem design og udviklingsmiljøer.

Vores designsystem vil overvinde denne udfordring ved at definere farvepaletten og gemme den i farveprøver i Sketch, Photoshop og UXPin. Men inden vi kom der, havde vi brug for en simpel lommeregner, som designere kunne arbejde dynamisk med Sass og Less-funktioner.

For at hjælpe teamet havde jeg noget sjov i weekenden og kodede en lille farve-app (lige nu bruges internt, men til sidst frigives den for offentligheden):

Vores interne farveregner - Electron App-simulering af Sass og mindre-funktioner

Appen giver dig mulighed for at give enhver definition af en farve og beregner lysere, mørkere, mættede og desaturerede versioner af farven med et givet interval. Det giver nøjagtigt de samme resultater som Sass og Less-funktioner!

Et ekstremt enkelt værktøj, der viste sig at være uundværlig for processen.

Definition af accenter uden at bryde ting

Når vi engang havde et nemt værktøj til beregning af paletten på vores sekundære farver, begyndte vi at arbejde på en liste over farver til enten at matche ofte anvendte farver eller tilstrækkelige farver.

Jeg oprettede et regneark med de nye farver og deres nye funktioner og variabler:

Regneark, der viser alle de nye og gamle farvevariabler

Nu kunne vi se, om vi dækkede alle vores baser. Herfra kunne vi begynde at beslutte hele paletten.

Navnekonventioner

Vi var tættere på at få en hel palet defineret og klar til implementering. Vi havde bare brug for en navnekonvention.

Vores aktuelle farvevariabler var skyldige i alle synder ved variabel navngivning:

  • Ulæselige kamelhus
  • Forvirrende graduering af adjektiver (lightGray, mediumGray, darkGray, darkerGray)
  • Obskure funktionelle navne (f.eks. @ColorGraySeparatorBorder).

Populære løsninger, der ikke fungerede

Efter lidt research slog vi et par muligheder fra vores liste.

1. Naturlige farvenavne eller abstrakte farvenavne

Der var mange virksomheder i vores rum med naturlige farvenavne eller abstrakte farvenavne.

Men med størrelsen og kompleksiteten af ​​vores palet, ville ingen af ​​løsningen fungere. Navnene på grå nuancer som: beton, galleri, alt, adel - indikerer ikke rigtig forskel i skygge og blev derfor svære at forstå og kommunikere.

2. Funktionelle navne

Naturligvis prøvede andre rent funktionelle navne, der beskriver farven efter stedet i UI.

Denne tilgang synes at fungere godt for Salesforce Lightning. Men vi var bekymrede over mulige duplikater af farver og vanskeligheden med at styre en sådan palet i tide (hvad hvis en bestemt del af UI'en fjernes fra grænsefladen?). Vores udvikling er ekstremt hurtig, og farvepaletten skal sejre uanset.

Vi havde brug for en mere universel navnekonvention.

Salesforce Lynfarver navngivningsmønster

3. Talbaserede navne

Endelig fjerner nogle virksomheder navnekonventionen fra farvepaletten og vælger numre i stedet. Mens en fristende tilgang, ville vores antal af accenter gøre det til en effektivitetsmorder. Det er umuligt at kommunikere med abstrakte navne.

IBM Carbon farve navngivningsmønster

Den tilpassede løsning, der fungerede

Da intet passer til vores behov, skabte vi vores egen navnekonvention.

Først og fremmest blev vi enige om at gå videre med et meget simpelt præfiks til primærfarver - 'base-'. Vi kan godt lide det, fordi det er let at forstå, let at sige og let at huske (hvilket er vigtigt under kodning).

Vores primærfarver blev:

  • @ basisblå: # 006CFF
  • @ basisgrå: # 666666
  • @ base-rød: # FF003C
  • @ base-grøn: # 63ad0e
  • @ base-orange: # ffc000
  • @ base-violet: # 7800ff
  • @ base-pink: # ff56b1
  • @ base-mint: # 00ffde

For accenter har vi besluttet at bruge navnene på primærfarver, navnene på funktioner, der genererer farven og et interval for ændringer. For eksempel: en farve, der er 25% lysere end vores basisgrå, blev @ grå-lysere-25. En farve, der er 15% mørkere end vores basisblå, blev @ blå-mørkere-15.

Fordi navnekonventionen fungerede godt, formaliserede vi den med et diagram:

UXPin-farvepalet

På dette tidspunkt troede vi, at vi var klar til at gå ind i test og regler for tilgængelighed.

Vi kunne ikke have taget mere forkert.

The Epic Battle of the Shades of Grey

Stolt af vores arbejde besluttede vi at diskutere det med vores senior grafiske designpersonale. Vi forventede ros af ord, masser af smil og positiv energi.

Vores palet blev helt ødelagt.

Årsagen var meget enkel - de var uenige i vores primært farve (# 666666). De mente, at det var for let, selvom det ofte blev brugt i UI.

De planlagde at udrydde denne grå nuance. I stedet ville de udlede det grå enten fra # 444444 eller # f3f3f3 (selvom begge næppe blev brugt i noget aktuelt arbejde).

Vi var skuffede, men det hele er en del af processen.

Efter at have prøvet og fejlet med to andre farver, endte vi med at definere to nuancer af grå i vores primære farver - mørke - # 444444 (i vores palet kaldet @ base-grå) og lys - # f3f3f3 (kaldet @ base-sølv). Det grafiske designteam elskede det.

For at validere beslutningen viste vi paletten til designere uden for vores firma. Jina Bolton (jina anne) fra Salesforce påpegede en inkonsekvens i navngivning mellem primærfarver og accenter (tak Jina!) Og foreslog at bruge suffikser i stedet for præfikser til navnene på primærfarver. Det var en ren åbenbaring. Vi skiftede base-blå, til blue-base, og det begyndte endelig at passe godt sammen med vores accentfarver navne, f.eks. blå-lysne-15.

Her er det endelige resultat:

Den endelige version af UXPin Palette

Test vores palet

En defineret palet skal testes omhyggeligt inden for den aktuelle grænseflade. I nogle tilfælde kan ændring af eksisterende farver næppe ses, i andre kan du muligvis ødelægge brugergrænsefladen.

Vi overvejede visuel regressionstekst (f.eks. PhantomCSS), men indså i sidste ende, at kun manuelle tests kan give tilstrækkelig kontekst til en beslutning. Mens jeg skriver disse ord, gennemgår vi stadig grænsefladen med ændrede farver og markerer steder, der skal tilpasses.

Tilgængelighed

Det sidste trin i vores rejse gennem oprettelsen af ​​en farvepalet er at skabe retningslinjer for tilgængelighed. Designere skal vide, hvilke farver parrer sig godt, og hvilke der giver dårlig kontrast.

For at hjælpe med at sprede denne viden oprettede jeg 'kontrastpar', som tydeligt viser, hvilke par der klarer WCAG-test:

Oprettelse af denne form for dokumentation er rent manuelt arbejde (jeg brugte https://heiswayi.nrird.com/color-contrast-checker/#fg=FFF5F3,bg=BB0B2E) og tager meget tid.

Det er stadig det værd, da tilgængelighed er et krav.

Det endelige ord

Vi havde brug for en hel sprint for at skabe en samlet farvepalet - det var uden tvivl en vanskelig rejse.

Men det har fungeret som en stresstest for vores designdriftsteam. Vi er klar til mere!

Leder du efter alle artiklerne i denne serie? Her er de:

  • Design Systems Sprint 0: Silver Bullet of Product Development.
  • Design Systems Sprint 1: Interface inventar
  • Design System Sprint 2: Én farvepalet, der styrer dem alle
  • Design System Sprint 3: Administration af det grundlæggende
  • Design System Sprint 4: Design Principles
  • Design System Sprint 5: Administration af typografi
  • Design System Sprint 6: De hurtigste ikoner på jorden

Og du går ind i mere dybtgående tanker om designsystemer:

  • Det minimale levedygtige designsystem
  • Designsystemer er et sprog. Og det ændrer softwareudvikling for evigt
Tilmeld dig nu: https://www.uxpin.com/design-systems-early-access