De vigtigste lektioner lærte jeg at oprette et populært designsystem

Illustration af den super talentfulde Maya Ealey

I 2012 startede jeg et lille sideprojekt til standardisering af designmønstre og brugeroplevelse af 12 softwareprodukter hos Atlassian. I løbet af de næste 3 år blev dette lille sideprojekt til et meget stort projekt, der blev mit fuldtidsjob, der involverede oprettelse og forsendelse af flere versioner af Atlassian Design System og etablerede teamet Design Platform (som stadig findes i dag, men med mange flere mennesker) til at vedligeholde og udnytte systemer, der arbejder på tværs af Atlassian-produktpakken.

Med uptick i diskussioner om designsystemer i de sidste par år, bliver jeg lejlighedsvis bedt om tip eller indsigt fra min erfaring med at bygge designsystemet hos Atlassian. Hvis du har overvejet at oprette et til dit produkt eller din virksomhed, er i færd med at fremstille et eller har prøvet og opgivet, forhåbentlig vil disse indsigter hjælpe dig med at skabe et bedre designsystem til din virksomhed.

Hos Asana er vi i starten af ​​vores rejse for at opbygge et holistisk designsystem. Jeg har fundet, at det at reflektere over disse lektioner har hjulpet os med at sætte teamet og virksomheden op til succes, så vi leverer den sande værdi af et designsystem.

1. Start med at gøre ting, der ikke skaleres

Den allerførste version af Atlassian Design System var omkring 20 statiske HTML-filer, som jeg var vært på en Mac Pro under mit skrivebord. Der var ingen templatering i disse filer, ingen versionskontrol, jeg havde importeret CSS fra vores produkter, og jeg skrev markeringen selv for hver komponent. Denne version var grim at opdatere og var ikke skalerbar, men nok mennesker fandt værdi i den, at jeg blev inspireret til at investere mere tid og kræfter, der satte os på vejen til oprettelse af Atlassian Design System.

Uden at gøre noget, der ikke blev skaleret, havde vi måske taget meget længere tid for at komme i gang. Når du arbejder på dit system, skal du prøve ikke at blive for besat af overkonstruktion af en sømløs, perfekt arbejdsgang, men i stedet kigge efter skramle måder at starte på og bare fortsætte med at gøre fremskridt, hvis det fungerer.

2. Må ikke våben dine retningslinjer

Hvis du opretter et designsystem, så andre ikke begår fejl, som du (og kun dig!) Bliver nødt til at rette op senere, kan du muligvis ikke nærme dig dette med det rigtige tankesæt.

Målet med et designsystem er at skalere dig selv (og dit designteam) for at opbygge et produkt hurtigere og give alle mulighed for at træffe bedre designbeslutninger.

Et designsystem er et værktøj til empowerment, ikke et våben til at kontrollere design.

Det er virkelig vigtigt at ikke kaste regelbogen på folk og politihandle den ihjel. Prøv i stedet for at nærme dig systemet med filosofien om, at et designsystem er et værktøj til at demokratisere design på tværs af din virksomhed. Denne tilgang åbner virkelig dørene, så folk vil bidrage og være en del af det. Husk, et designsystem er et værktøj til empowerment, ikke et våben til at kontrollere design.

3. "Lad os bare redesigne det hele"

Modstå trangen til at tage dette som en mulighed for at redesigne dit produkt. Oprettelse af et system og redesign af din app på samme tid vil bremse dig markant. Det er meget lettere at dokumentere, hvad du har i dag, både de gode og de dårlige mønstre, og derefter rette de dårlige mønstre med en redesign af det visuelle sprog bagefter.

Der var mange forsøg på Atlassian med at redesigne produktsuiten, før grundlæggelsen af ​​at dokumentere vores systemkomponenter var tilfredsstillende. Det tog lang tid at opbygge arkitekturen i systemet, men det gjorde det lettere (og hurtigere) for Atlassian at opdatere det visuelle sprog senere, fordi fundamenterne var solide.

4. Få tværfunktionel support til dit designsystem

Jeg mener, at det ikke er en akademisk øvelse at oprette et designsystem. Hvis ingen bruger systemet, eller det ikke hjalp dit team at bevæge sig hurtigere og træffe bedre beslutninger, spilder du muligvis din tid.

Ved at få andre til at følge, hvad du laver, og bidrage til at forbedre mønstre og retningslinjer, får du det buy-in og support, du har brug for for virkelig at gøre en forskel og opbygge fantastiske produkter. Jeg kan ikke understrege for meget, hvor kritisk dette er for dine systems succes.

Tilbage i 2013 var forholdet mellem designer og ingeniør noget i området fra 1 designer til hver 15-20 ingeniører. Mens jeg ryster over tanken om dette nummer i dag, prøvede jeg dengang at bruge denne ubalance til min fordel. Noget, der hjalp mig med at få ingeniørorganet på min side hos Atlassian var at skabe en tale til nye startere i løbet af deres første uge med ombord på firmaet. Cirka 15 mennesker ville være der hver uge, og jeg kunne få dem til at forstå, hvad vi forsøgte at gøre fra dag 1. For eksempel ville jeg gennemgå en historie om, hvordan vi plejede at have 44 forskellige dropdown menuer (ikke en overdrivelse), men vi har en nu og her er, hvordan du skal bruge det.

I løbet af 2013, og med Atlassian fordobling i størrelse næsten hvert år, havde jeg dybest set omkring 500 mennesker ombord på vigtigheden af ​​vores designsystem, og hvordan de kan bruge det. Jeg fandt, at dette var en virkelig effektiv måde at ændre virksomhedskulturen med hensyn til design.

5. Gå videre end en stilguide

Et designsystem (eller retningslinje) er forskellig fra en stilguide. At have alle komponenterne i en Sketch-fil er relativt let at gøre - alle de primære knapper er i samme farve, eller du bruger et 8px gitter. Men hvornår bruger jeg en primær knap i stedet for en sekundær knap? Hvilken type etiketter skal knapperne have? Når en primær og en sekundær knap er sammen, hvilken er der til venstre?

Disse spørgsmål er den slags ting et designsystem skal løse for ikke kun at dokumentere pixelværdierne for dine komponenter. Mange designteam går glip af dette aspekt, når de opretter deres system og i sidste ende går glip af en stærk bivirkning af systemarbejdet.

Som nævnt ovenfor var det Atlassiske designteam i begyndelsen af ​​2013 relativt lille (~ 13 personer) sammenlignet med ingeniørteamet (~ 300 personer). En af fordelene ved at inkludere skriftlige retningslinjer var, at ingeniører kunne gøre en enorm mængde fremskridt uden en designer der. Det betød, at vi kunne stoppe med at designe skærme i Sketch og i stedet springe på en tavle og brainstorme en strøm eller begynde at arbejde på meget større produktproblemer, der eksisterede opstrøms.

6. Få nogen tilsyn med systemet, men sørg for, at alle bidrager

Vi brugte en centraliseret model, som gjorde det muligt for enhver designer i virksomheden at bidrage. Vi havde også et ~ 3 måneders rotationsprogram, hvor designere og ingeniører blev taget fra deres respektive produkter og ville arbejde på Design Platform-teamet for at skubbe systemet fremad. De ville bidrage stærkt, mens de var på vores team, og derefter vende tilbage til deres originale produktteams som ægte fortalere for systemet.

At have nogen overvåget systemet er meget, meget vigtigt. Denne person (mig hos Atlassian) er sandsynligvis en designer måneskin som produktchef. De skal beskytte systemet, men være meget omhyggelige med ikke at skabe et miljø, hvor folk afviser det og bliver useriøse. Glem ikke, formålet med systemet er at gøre alle i virksomheden til en bedre designer.

Er du interesseret i at finde ud af mere om Asana? Vi har et pænt site op på https://asana.design med lidt om, hvem vi er, og hvad vi gør. Vi ansætter også designledere og produktdesignere på vores kontor i San Francisco, et af de bedste arbejdspladser i 2018 i USA! (Vi kan flytte dig, hvis du ikke er hjemme i Bugtområdet).

Hvis du nød dette indlæg, kan du måske følge vores publikation for flere historier fra Asana Design