Udvikling af et designmiljø

Hvad er et designmiljø, og hvordan kan det gøre et designsystem lettere at bruge?

Siden jeg flyttede til San Francisco, har jeg gjort min store del af jobhopping. Jeg har været kommunikationsdesigner, produktdesigner og front-end-udvikler. Hver gang min rolle skiftede, var jeg altid travlt med at lære nye færdigheder, men følte mig aldrig som om jeg arbejdede med problemer, som jeg faktisk var god til at løse. Heldigvis viste det sig at være en god træning for det job, jeg har nu, som bygger ud Thread, Credit Karmas interne designsystem.

Skitsymboler til tråd, Credit Karmas interne designsystem.

Den bedste del ved at springe rundt var dog muligheden for at studere, hvordan forskellige typer organisationer nærmer sig at få gjort arbejde. Jeg blev især fascineret af ingeniørteams, for inden for ingeniørarbejde er samarbejde stort set ikke-valgfri. Hvis du har 400 ingeniører, der skriver kode, skal hver persons bidrag til at samarbejde, og ingeniørorganisationer strækker sig meget for at sikre, at der er så få snags, når du kombinerer kode som muligt.

Faktisk bruger du i de fleste ingeniørorganisationer hele din første dag på at opsætte dit udviklingsmiljø, så du faktisk kan sende kode. Det er generelt temmelig kedeligt, og ingen kan lide at gøre det, men det er denne ting, du gør for at bidrage med meningsfuldt arbejde til produktionen. Hvilket fik mig til at tænke, hvordan ville det se ud for at gøre det lettere for designere at designe til produktion?

Med henblik på dette indlæg definerer jeg et udviklingsmiljø som "Sættet af processer og programmeringsværktøjer, der bruges til at oprette programmet eller softwareproduktet."

Udviklingsmiljø: sæt processer og programmeringsværktøjer, der bruges til at oprette programmet eller softwareproduktet.

I modsætning hertil ville et designmiljø være "Sættet med processer og designværktøjer, der bruges til at designe programmet eller softwareproduktet."

Designmiljø: sæt processer og designværktøjer, der bruges til at designe programmet eller softwareproduktet.

Tråd, vores designsystem, er en succes, hvis den nemmeste måde at designe eller bygge UI også er af højeste kvalitet. En stor del af denne succes er at lukke kløften mellem, hvad en designer har adgang til i Sketch, og hvad en ingeniør har adgang til i kode. Kunne formalisering af listen over designværktøj og proceskrav hjælpe med at reducere kløften? For at finde ud af det, startede jeg med en liste.

For at designe ordentligt til produktion, har en Credit Karma-designer brug for:

  1. Trådsymboler, der opfører sig så tæt på deres React-komponent-modstykker som muligt (afstand, typografi osv.)
  2. Adgang til en farvepalet, der matcher vores CSS-variabler
  3. Adgang til tekstformater, der matcher vores CSS-klasser
  4. Adgang til lagformater, der matcher vores CSS-klasser
  5. Adgang til det ajourførte Thread Sketch-bibliotek
  6. En måde at teste, om den rigtige virksomheds skrifttype er installeret, og adgang til den rigtige version, hvis den gamle findes

Derfra var det let at begynde at identificere mulige løsninger, og jeg sammensatte et par muligheder, som jeg troede ville hjælpe.

  1. Dynamisk knap og Anima Auto Layout for at justere symbolafstand og polstring med React-komponentafstand og polstring
  2. Skittspaletter til import af farver
  3. Sketch Style-biblioteker for at trække tekstformater fra Thread Sketch-biblioteket
  4. Skitse-biblioteker til at trække kant- og baggrundsformater fra Thread Sketch-biblioteket
  5. Abstract til biblioteksdistribution og versionskontrol
  6. En skissefil til test af fontversionen og adgang til den rigtige skrifttype på Google Drev

Dette sidste problem var det vanskeligste. Den originale skrifttype, vi købte, havde nogle problemer med linjehøjde, hvilket fik knapper og badges til at se lodret ud fra midten. Vi arbejdede med font maker for at løse problemet, men det var svært for folk let at fortælle, om skrifttypen faktisk var blevet opdateret eller ej. Jeg valgte de mest indlysende elementer, der ville se forkert ud, hvis skrifttypen var forkert, og tog skærmbilleder af forskellen, og satte dem derefter på en " Fontcheck" -side i biblioteket Thread Sketch-bibliotek.

Jeg bemærkede også nogle nice-to-haves, som at indstille Sketch's Shift + Arrow nudging til 8px i stedet for 10px standard for at matche vores 8px polstring klasse skala og installere SketchRunner for at fremskynde symbolstyring.

Da jeg var færdig med forslaget om henstillinger, lagde jeg alle de løse ressourcer i en enkelt mappe på Google Drev og forberedte en præsentation om, hvordan designmiljøopsætningen skulle fungere.

Trådressourcemappen

Bemærk: Ligesom med udviklingsmiljøer, vil problemerne, som et designmiljø sigter mod at løse, og de løsninger, det giver, varierer meget fra virksomhed til virksomhed.

Test af processen

Det næste trin var at samle en gruppe designere sammen for at give forslaget et trin-for-trin testkørsel, som vi gjorde i sidste februar.

Det startede med en gruppe på 6 frivillige, som voksede til 10, da mødet rullede rundt. Jeg gik alle gennem præsentationen, designmiljømålene og mappen Trådressourcen på Google Drev og holdt pause efter hvert trin for at sikre, at alles konfiguration fungerede.

Da det viste sig, var 10 personer alt for store af en gruppe, og øvelsens pisel natur gjorde det let for deltagerne at blive distraherede og miste fokus. På trods af ujævnhederne tog jeg notater om alle de steder, hvor folk fik problemer og gjorde præsentationen til en guide på vores dokumentationswebsted.

I guiden sørgede jeg for at ramme processen som en investering, designet til at spare tid, når jeg samarbejdede med engineering. Jeg tilføjede også en anslået "tid til at afslutte" for at stille forventninger om, at hele processen kun skulle tage ca. 30 minutter fra start til slut.

Da guiden blev offentliggjort, satte jeg op en videochat med Pedro, en designer på vores LA-kontor, og tog yderligere notater, da han gik gennem guiden. Igen fandt jeg en masse ting at forbedre og afklare, derefter gentages det på nogle af instruktionerne.

kompromiser

Selvom projektet har set nogen tidlig succes (en af ​​mine kolleger fortalte mig, at det at oprette en ny Sketch-fil nu er "en billig spænding"), er det stadig et arbejde, der er i gang, og som altid er der kompromis at overveje.

Nedsat arbejdsgangs autonomi

En af de største ændringer for vores team var at tage en gruppe holdning til filhåndtering ved hjælp af Abstract til at spore Sketch-filændringer. At beslutte at bruge Abstract betød at bede alle om at ændre den måde, de organiserede deres arbejde på, hvilket tog noget overbevisende. Men vi kæmpede for effektivt at spore og dele arbejde, når teamet voksede, så den kontekst, som versionskontrol giver, var virkelig tiltalende. Selvom det koste os en smule autonomi for arbejdsgange, har det været meget nyttigt for samarbejde, især når man overleverer design til engineering.

Yderligere afhængigheder og softwarekonflikter

Når der tilføjes nye afhængigheder til en værktøjskæde, øges naturligvis risikoen for softwarekonflikt. Det har ikke været et væsentligt spørgsmål endnu, men opgradering til større versioner af nøglesoftware som Sketch kan forståeligt nok føre til nogle frustrationer. Derudover er det mindre sandsynligt, at ny software er stabil end moden software, både i fejl og levetid. Når du vælger at inkorporere et open source-projekt eller et startværktøj, skal du være opmærksom på, at der er en chance for, at projektet ikke opretholdes, eller at opstart vil blive foldet.

Psykisk overhead

Den sidste ting man skal passe på er mental overhead. Med hvert nyt værktøj og plugin er der genveje og opførsel, som brugere af designmiljøet skal huske. Selvom jeg vil reducere afstanden mellem hvad en designer ser i Sketch og det, de ser i produktionen så meget som muligt, ville for mange trin og plugins besejre formålet med at skabe en mere strømlinet workflow. Da der altid vil være uoverensstemmelser mellem Sketch's gengivelse og browser gengivelse, skal Sketch alligevel behandles som en tæt tilnærmelse.

Evalueringsværktøjer

I digital produktdesign har antallet af værktøjer, du vælger, aldrig været højere, så hvordan finder du ud af, om det er en god ide at introducere et nyt værktøj? Hvis du beslutter at udskifte et gammelt værktøj med et nyt, hvordan overbeviser du alle andre på dit hold?

De tre vigtigste spørgsmål, der skal overvejes, er:

  1. Hvilke problemer forsøger du at løse med dette nye værktøj?
  2. Hvilke nye problemer kan dette værktøj introducere?
  3. Hvad gør denne bytte værd?

Intet værktøj er perfekt, og de har alle en omkostning. Hvis du beder en gruppe mennesker om at ændre den måde, de fungerer væsentligt på, er det rart at være opmærksom på fordele og ulemper ved den ændring, du foreslår at vise, at du har foretaget din due diligence.

Imidlertid er det dejlige ved designværktøjer, der samles sammen, at alle værktøjer individuelt bliver bedre. Da Figma fik prototype, fulgte Sketch efter. Da Abstract introducerede versionskontrol til Sketch, frigav Figma versionshistorik med kommentarer. Selv prototype-værktøjer som Framer og InVision har øget deres investering i designsiden af ​​værktøj. Nogle virksomheder, som Airbnb og Facebook, bygger brugerdefinerede værktøjer oven på disse platforme eller bygger helt nye værktøjer helt.

Det fine ved designværktøjer, der samlet samles, er, at alle værktøjer individuelt bliver bedre.

Den bedste ting at gøre er at overveje din proces holistisk og vælge værktøjer, der bøjer sig til den måde, du vil arbejde, og ikke omvendt.

Ser frem til

Dette designmiljøprojekt er bare begyndelsen. Hvilke andre bedste fremgangsmåder kan vi tilpasse fra beslægtede discipliner, der har løst problemer, som designorganisationer traditionelt kæmper med? Kan nogen af ​​disse fremgangsmåder gøre designsystemer lettere at bruge?

Andre virksomheder er allerede begyndt at gøre dette. Airbnb har oprettet et designforende eksperiment med Figma API. Abstrakt baner vejen for design-pull-anmodninger, der kunne gøre det at opretholde konsistensen på systemniveau til et delt ansvar. Og der er masser at lære ud over teknik: Shopifys Polaris designsystem indstiller søjlen for tværfunktionel læring ved at sætte indholdsstrategi på komponentniveau i deres dokumentation.

Uanset hvilke værktøjer, vi alle bruger i de næste fem år, ser jeg frem til at se, hvordan vores tilgang til at få gjort arbejde udvikler sig over tid.