Hvordan og hvorfor jeg designet en farvevariant og tilgængelighedsværktøj

Som udvikler har det altid været en af ​​de sværere opgaver at vælge farver til mine designs. For at hjælpe har jeg en tendens til at bruge værktøjer som Coolors, SASS Color Generator og denne farvekontrastkontrol.

Min proces plejede at se sådan ud:

  1. Generer en palette ved hjælp af Coolors
  2. Vælg varianter for hver farve ved hjælp af SASS Color Generator
  3. Par varianter sammen i baggrunds- / forgrundskombinationer.
  4. Kontroller, at parene er tilgængelige ved hjælp af farvekontrastkontrollen.
  5. Føj mine valgte farver til mit valgte designværktøj (Figma).
  6. Tilpas farver og gentag fra trin 2.

Så hvad var problemet?

Min gamle proces involverede en masse frem og tilbage mellem forskellige applikationer. Jeg kunne ikke tilpasse mine farver og se indvirkningen på tilgængelighed i realtid. I stedet måtte jeg kopiere / indsætte HEX-koder fra en app til en anden. Så da jeg var klar til at starte udviklingen, måtte jeg manuelt oprette variablerne i SASS / CSS og kopiere værdierne igen.

Og løsningen?

Opret et værktøj, hvor jeg kunne gøre (næsten) alt på ét sted. Mit mål var at bevæge sig mod en proces som denne:

  1. Generer en palette ved hjælp af Coolors
  2. Vælg varianter, par farver og lav tweaks ved hjælp af en enkelt app.
  3. Føj de resulterende farver til mit valgte designværktøj.

Jeg ville også have, at appen kunne eksportere mine farver til kode, så jeg ville have et godt udgangspunkt for udvikling.

Det første bevis på konceptet

Jeg ønskede at få noget i gang så hurtigt som muligt, så jeg kunne begynde at teste det. Til dette formål begyndte jeg at oprette en prototype.

Brug sager

Det første skridt i at få sammensat en prototype var at definere de anvendelsessager, der skulle drive den.

  1. Som bruger vil jeg generere varianter til mine basisfarver.

Jeg ville være i stand til at åbne appen, tilføje mine basisfarver, vælge varianterne og derefter eksportere dem tilbage til mit designværktøj igen. Simpelt?

2. Som bruger vil jeg kontrollere, om et baggrunds- / forgrundsfarvepar er tilgængeligt.

Fra de indtastede basisfarver eller deres varianter ville jeg være i stand til at kontrollere, om to farver var tilgængelige, når de blev parret sammen.

3. Som bruger skal jeg være i stand til at se den indvirkning, som ændring af en grundfarve har på tilgængeligheden.

Jeg ville være i stand til at få feedback i realtid om de farvepar, jeg havde valgt, hver gang jeg lavede justeringer til mine basisfarver.

En (meget grov) arbejdsversion

Med de definerede brugssager begyndte jeg derefter at designe prototypen. Jeg kom med en farvepalet, designede et begrænset sæt komponenter og kom til sidst frem til en løsning, der havde tre “tilstande” eller sider, hvor brugeren skulle skifte mellem dem for at udføre deres opgaver.

I stedet for at beskrive det yderligere, lad os tage et kig.

Som du kan se på billedet ovenfor, opnåede prototypen alt, hvad jeg ønskede, baseret på de oprindelige brugssager ... Sort af.

Klik her, hvis du gerne vil prøve prototypen selv takket være magien ved Netlify-implementeringseksempler.

Det gode og dårlige ved det originale design

Jeg havde aldrig til hensigt, at den første prototype skulle være andet end en springbræt, og du kan selv se, at den var ret ru og mangelfuld.

Til den næste version startede jeg med at se på, hvad jeg kunne lide ved prototypen.

Variant-tilstand

Jeg var ret tilfreds med, hvordan den variant, der genererede en del af prototypen, blev. Det var ret simpelt at vælge en farve og få din liste over varianter. Den fanebaserede tilgang fungerede også ret godt til at tilføje flere basisfarver.

At kunne se ændringer i tilgængelighed efter at have skiftet en farve

Som du kan se i den korte demo ovenfor, var der ikke behov for at kopiere / indsætte HEX-koder mellem applikationer. Jeg kunne nu ændre en af ​​mine farver og se, hvordan det påvirkede tilgængeligheden af ​​farver virkelig hurtigt.

Derefter begyndte jeg at vælge ting, som jeg ikke kunne lide og skulle forbedres .

Interaktioner var ikke indlysende

Baseret på ankomsten til hjemmesiden var det ikke umiddelbart indlysende, hvordan du vælger varianter og kontrollerer for tilgængelighed. Du kunne sandsynligvis finde ud af, at du til sidst skulle klikke på fliserne, men det var virkelig klodset.

Tilstande var forvirrende

I de oprindelige designs kunne du kun tilføje par fra paletvisningen, og du kunne kun tilføje / fjerne varianter fra variantvisningen. Det hele involverede en masse skift mellem skærme, og jeg blev frustreret over, hvor meget arbejde appen fik mig til at gøre. Dette fører mig til mit næste punkt.

For meget klik var nødvendigt

Du skal klikke for at tilføje en variant. Derefter skal du klikke for at flytte til paletvisningen. Derefter skal du klikke flere gange for at oprette et par. Derefter skal du klikke lidt mere for at se det par, du lige har tilføjet. Som jeg nævnte ovenfor var det hele ret klodset, og dette var sandsynligvis den værste del af prototypen og noget, jeg vidste, at jeg havde brug for at ændre.

Der var ikke nok information på skærmen på én gang

Jo mere jeg brugte det, jo mere begyndte jeg ikke at kunne lide det “modes” -koncept, jeg oprettede. Jeg tror, ​​jeg blev påvirket af den oprindelige proces, der inspirerede applikationen, og jeg designede skærmene i siloer snarere end at designe en samlet oplevelse. Efter at have brugt prototypen besluttede jeg, at jeg skulle migrere væk fra "modes" -konceptet til noget, der ideelt set alle kunne gøres på en enkelt side.

Et andet forsøg

Jeg tog de lektioner, jeg havde lært af prototypen, og begyndte at skabe en bedre version af appen.

For at reducere antallet af krævede interaktioner , reducere tvetydigheden i interaktionerne og for at øge mængden af ​​information, der er tilgængelig for brugeren på én gang, besluttede jeg at flytte til et træk-og-slip-baseret brugergrænseflade, hvor brugeren kunne trække fliser rundt for at føje til deres palet eller oprette tilgængelighedskontrol.

Trækmålet vises altid, og dette undgår behovet for at skifte mellem skærme.

Lad os se på, hvad jeg kom på.

Du kan få adgang til den aktuelle version af applikationen her.

Næste skridt

Ansøgningen er stadig meget i sin barndom, og selvom den anden version er meget tættere på den idé, jeg havde i tankerne, er der stadig forbedringer, der kan foretages.

Import fra kode

Ud over at eksportere paletten har jeg planer om at tilføje muligheden for at læse de indledende basisfarver fra kode indeholdende variabler (SASS- og CSS-variabler til at begynde med)

Eksporter til flere formater

I øjeblikket kan du kun eksportere SASS. Jeg planlægger at tilføje support til CSS-variabler og andre formater i fremtiden.

Integrer med designværktøjer

Eksport til kode er fantastisk, men det ville være endnu bedre, hvis jeg kunne eksportere paletten og derefter importere den som et lag eller delt stil i et designværktøj som Figma eller Sketch.

Forbedre brugergrænsefladen

Lad os se det i øjnene, er det ikke den bedste leder ansøgning i verden. Jeg planlægger at finjustere UI-komponenterne for at forbedre appen visuelt.

Feedback og fejlrapportering

Denne taler for sig selv. Jeg kan kun forbedre appen med input fra dem, der bruger den. For at gøre det planlægger jeg at tilføje en feedbackformular i fremtiden.

Feedback

Apropos feedback ... Jeg skrev denne artikel af to grunde. Den første var at lede dig gennem processen, jeg gik igennem for at nå frem til det aktuelle design i håb om, at du kan lære af det.

Den anden grund er, at jeg ønskede at fremvise værktøjet til udviklings- og designfællesskabet, da jeg tror, ​​det kan være nyttigt for mange mennesker og også at samle feedback om det i dets nuværende tilstand.

Så hvis du har nogle tanker om designet, funktionaliteten, den proces, jeg har gennemgået for at oprette værktøjet eller noget andet, vil jeg meget gerne høre det!

Links

Prototype

Nuværende version

Komponentbibliotek