Design Systems Sprint 1: Interface inventar

En kort introduktion: Jeg er Marcin: en tidligere UX-manager og nu medstifter og CEO hos UXPin - UXPin - den fulde stak UX-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 de grundlæggende elementer i designsystemer (hvorfor? Hvad?). Nu er det tid til at få gjort noget arbejde! Her er historien om, hvordan vi startede processen med at opbygge vores Design System med en Interface Inventory.

Hvis du undrer dig over, hvorfor eller hvordan man bygger et designsystem, skal du følge denne række stillinger. Masser af praktiske råd kommer op!

Efter vores første forskning lærte vi, at manglen på designkonsistens er et af de største problemer inden for produktudvikling. Vi bekræftede også, at vi var nødt til at løse dette problem i vores eget produkt.

Vigtigere er det, at vi bestemte, at et designsystem er den rigtige løsning til at forhindre uoverensstemmelser. Vi var nødt til fuldt ud at forpligte os til at opbygge en proces, der ville forbedre den langsigtede overlevelse af designsystemet, når det vokser til at støtte vores nyeste projekter.

Som Nathan Curtis, ekspert i designsystemer og forfatter af Modular Web Design, sagde berømt:

”Et designsystem er ikke et projekt. Det er et produkt, der serverer produkter. ”

Et designsystem er ikke en standard udskåret i sten, og det er heller ikke en engangslevering. Det er hjertet i din produktudviklingsproces, ikke en artefakt af processen.

For os designere lyder det hele godt. Et skift i processen for at eliminere uoverensstemmelser i design og gentaget arbejde? Tilmeld mig! Desværre er tingene mere komplicerede.

At sælge en radikal ændring i processen er altid meget vanskeligt. Du tvinger folk ud af deres komfortzone, peger på deres fejl og beder dem om at gøre deres job anderledes. Forvent ikke, at de byder dig velkommen med åbne arme. De vil først modstå - det er menneskets natur, og du skal være forberedt.

Så hvordan kan vi ændre andre? Det gør vi ikke.

Nogle af de vigtigste livsråd, jeg nogensinde har modtaget, er, at det er nytteløst at skifte mennesker. I stedet skal vi inspirere andre til at følge vores forspring. Så lad os starte med os selv.

Start med dig selv

Du tænker sandsynligvis, “Hej, er du ikke administrerende direktør? Kan du ikke bare bede folk om at begynde at arbejde på designsystemet? ”

Selvom det teknisk er sandt, er det ikke så simpelt i praksis.

Først og fremmest lever selv administrerende direktører i en verden fuld af begrænsninger. Jeg kan ikke bare trække folk ud af tidssensitive projekter, få dem til at arbejde sammen med mig på et designsystem og stadig holde vores VP'er ansvarlige for at levere vigtige projekter på omfang, til tiden og til strategi. Det er helt klart en urimelig forventning.

For det andet er hold nødt til fuldt ud at købe dine ideer ellers vil de aldrig vedtage dem. For at gøre det skal du lade dem opleve smerten og smage løsningen. Uanset om du er designleder eller førende designer, er det vores første ansvar at sælge designsystemet til vores organisationer.

Gå ind i Interface Inventory - et simpelt værktøj, der er det perfekte udgangspunkt for designsystemet. Et, der er lige så nyttigt til evangelisering og kickstart af rejsen.

Hvad er en grænsefladebeholdning?

Brad Frost, forfatter af Atomic Design, definerede en interfaceinventar som:

“… En omfattende samling af de bits og stykker, der udgør din interface”.

Med andre ord: Interface Inventory er en pænt organiseret kasse med alle dele af dit produkt. I et "rum" har du muligvis alle knapperne samlet fra hele produktet eller en familie af produkter. I en anden er alle farver, typografier af tekst osv.

Interfaceinventariet er et fænomenalt værktøj til at vise alle dine blanke uoverensstemmelser. Det gør problemet ubestrideligt for dit team og interessenter. I stedet for at rant, viser du dem let forbrugsstoffer, der er lettere at rette.

Du ender også med en bedre forståelse af de forskellige faser i et produkts liv. For eksempel viser en samling af alle de forskellige tabeller, hvilke der er forældede og skal refaktoriseres til den nyeste version.

Interfaceinventaret er som ringene i en træstamme. Og ligesom med træringer, kan du se, hvornår der var brand i projektet, og hvornår systemet var godt næret. Dette er en uvurderlig lektion for hele organisationen. Gode ​​og dårlige tider kommer til udtryk i produktoplevelsen. De er et vidnesbyrd om vores organisatoriske effektivitet.

Lad os komme igang!

Hvor skal man starte en grænsefladebeholdning

Brad Frost foreslår, at Interface Inventory skal starte med en simpel opgave med at tage en masse skærmbilleder af UI og kategorisere dem i bunker i en hovedpræsentation.

Selvom denne tilgang bestemt kan fungere meget godt, var den ikke passende for UXPin.

Vi havde en eksisterende kodearkitektur, som jeg ønskede at bruge som fundament for vores system. Vores UI-arkitekt (denne fyr er et rent geni og min front-end-udviklingsguru) introducerede en velstruktureret og modulær tilgang til CSS for år siden. Vi fulgte det religiøst siden. Han opdelte vores CSS (eller rettere mindre, da vi bruger en Mindre forarbejdningsvirksomhed til at opbygge og administrere vores stilark) i:

  • Elementer - de mindste individuelle stykker af grænsefladen, der fungerer som byggesten til komponenter (f.eks. Knapper, formfelter ...)
  • Komponenter - uafhængige og gentagne gange brugte stykker af grænsefladen bygget ud af elementer (f.eks. Værktøjslinjepost, sidelader)
  • Moduler - fulde funktionaliteter bygget ud af komponenter (f.eks. Værktøjslinje, søgning)
  • Layoutdefinitioner - Alle ovenstående bruger kernefiler (såsom variabler, ikonskriftsdefinitioner osv.) For at forene styling.
Modularitet af UXPin Mindre filer

Sidste år blev to tredjedele af vores produkt omskrevet til React.js, så vi begyndte også at drage fordel af Javascript-komponenter, som er tæt knyttet til en stilarkarkitektur (måske ikke så tæt, som vi gerne vil, men bestemt en solid start ).

At ignorere hele dette fundament ville gøre bygning af vores designsystem virkelig vanskelig, da det ville kræve massiv refactoring. For os ville refactoring kun give et faldende afkast, mens det koster meget tid og moral.

Med det i tankerne dannede jeg en anden slags proces til oprettelse af interfaceindholdet:

  1. Sammenligne. Sammenlign stykker af grænsefladen med deres repræsentation i kode og identificer logiske bidder.
  2. Liste. Liste over alle dele af grænsefladen i kategorier, der stammer fra kodemiljøet. Tilføj eventuelt flere forslag til kategorier.
  3. Bemærk. Noter eventuelle uoverensstemmelser mellem elementerne. Liste om klasser og filer til fremtidig reference.

Med denne enkle proces var jeg næsten klar til at gå. Jeg var nødt til at beslutte det endelige format.

Da vi sigter mod generel genanvendelighed, beslutter jeg at gøre vores interfaceinventar 100% genanvendelig. I stedet for at tage skærmbilleder, håbede jeg at indsamle mønstre direkte fra tidligere projekter - når det ikke var muligt, tegnet jeg dem igen.

I sidste ende håbede jeg at have en opgørelse, der hurtigt kunne omorganiseres til mindst et rudimentært designsystem.

Inventariet af byggesten

I mit første indlæg i denne serie delte jeg et designsystem i tre dele:

  • Byggeklodser - de mindste, mest generelle og mest genanvendelige stykker af grænsefladen, såsom farver, typografiske skalaer, gitterdefinitioner eller ikoner.
  • UI-mønstre - stykkerne i grænsefladen, der direkte bruges til at opbygge oplevelser.
  • Regler - retningslinjer for implementering og vækst af et designsystem
Grundlæggende struktur i et designsystem

Så meget som muligt skal beholdningen følge en lignende struktur.

Da du arbejder med en levende produktorganisme snarere end et velorganiseret system, er ikke alt muligvis klar til 'opfindelse' (for eksempel havde jeg problemer med gitre og regler). Jeg kan dog forsikre dig om, at nogle byggesten og alle mønstre er klar til dig.

En let byggesten, som jeg besluttede at starte med, er farve. Da vores webudviklingsteam bruger Mindre, håbede jeg, at jeg kunne finde Mindre filer fulde af farvevariabler, hvilket ville hjælpe mig med at identificere kernepaletten, der blev brugt i vores produkt. Efter en kort GIT-undersøgelse identificerede jeg 6 filer, der viser… 116 farvevariabler. Jeg var lidt overvældet, men bestemt nysgerrig efter, hvad der foregik der.

Efter at have talt med teamet og grundigt kontrolleret alle filerne, viser det sig, at nogle af de mindre kernefiler (og farver) blev forældet, og nogle farver blev duplikeret.

Ikke desto mindre eksisterede disse 116 farvedefinitioner i vores miljø og spurgte måske om lidt refactoring. Hvordan kan vi trods alt forstå vores primære palet, hvis den er skjult i 116 forskellige farver? Vi kan ikke.

For at give vores team materiale til fremtidige diskussioner og en mulig oprydning, besluttede jeg at liste alle farverne i et UXPin-projekt. Jeg begyndte også at skrive en 'Design Journal' som en ustruktureret dokumentation til opgørelsen, så teamet kunne kende mine tanker, lige fra det øjeblik, en inventarelement blev oprettet.

Sådan ser den endelige liste over farver ud:

Og dette er tidsskriftet:

Opmuntret af de indledende fremskridt og en voksende interesse hos teamet, oprettede jeg derefter en opgørelse over typografien.

I ganske lang tid har UXPin altid haft en streng typografisk standard. Inde i applikationen bruger vi eksklusivt 'Proxima Nova' og kun i de to mest læsbare vægte (regelmæssig og halvfet). Det er fantastisk og skaber bestemt en følelse af ensartet design. Jeg ville dog se den fulde skala for at forstå den semantiske struktur i produktet.

Denne opgave krævede lidt mere af et detektivarbejde. Jeg brugte inspektørværktøjet fra Chrome Developers værktøjer til at kontrollere markeringen og vælgerne af alle de specifikke tekstelementer i UI.

Her er listen over alle tekstformater i den typografiske skala:

Beholdningen af ​​ikoner

UXPin-grænsefladen er bestemt ikon-tung. Tilbage i 2015 investerede vi i vores egen ikonfamilie som en tilpasset løsning til klarhed og konsistens.

I slutningen af ​​koden fortsætter vi med at bruge ikoner som en fontfil. Det giver os en god ydelse og gør enhver ikonstyring på kodens ende en lyksalighed. Branchen er dog stærkt opdelt - der er bestemt mangler på fremgangsmåden. Jeg anbefaler disse to artikler, så du kan danne din egen mening:

  • Seriøst, skal du ikke bruge ikonskrifttyper
  • Brug alvorligt ikonskrifttyper

Ikke desto mindre var min opgave bare at opbygge en liste over vores ikoner. Jeg kunne droppe alle SVG’erne til UXPin og kalde det en dag, men så ville vi ikke have ønsket synkronisering med udvikling. I stedet gik jeg direkte til kilden og brugte ikon fontfiler til at oprette et arkiv med ikoner.

På denne måde kunne vi i de fremtidige versioner af vores system bruge nøjagtigt de samme aktiver som udviklere.

Jeg tilbragte en sjov weekend med Javascript og skabte en lille hjælpeprogram, der tager vores fontfiler og Mindre filer med ikondefinitioner og skaber en søgbar ikonliste med genererede mixin-definitioner.

Alt pakket som en Mac-app for at gøre det let tilgængeligt for både vores designere og udviklere:

Lille app, der genererer en liste over ikoner fra en ikonfont og viser mixin-erklæring fra Mindre filer

Appen var let at opbygge og viste sig at være uvurderlig i de senere faser, da jeg måtte bygge faktiske mønstre i UXPin. Alle fontikoner kan genbruges i UXPin, da vores Enterprise plan (som naturligvis vores interne team bruger) leveres med muligheden for at uploade tilpassede skrifttyper.

Ekstra fordel: Jeg havde det sjovt at arbejde på dette lille projekt.

Inventar af mønstre

Med farver, typografi og ikoner, alt sammen dokumenteret i vores lager, var det på tide at liste alle grænseflademønstre.

På samme måde som farver og typografi, var jeg nødt til at inspicere vores produktionskode for at finde de rigtige færre filer for at forstå kategoriseringen i vores arkitektur. Det tager lidt frem og tilbage mellem design, browserinspektør og github, men producerer den mest genanvendelige beholdning.

Jeg dokumenterede også alle de klasser, der blev brugt til at style et bestemt mønster. Hvis jeg nogensinde vil ændre det i fremtiden, leverer beholdningen alle de nødvendige oplysninger:

Hver gang jeg identificerede problemer, kommenterede jeg dem til teamet til at løse:

Når mønsterbeholdningen er afsluttet, er et let og tilgængeligt referencepunkt til fremtidig arbejde med designsystemet.

Beholdningen af ​​UXPin-knapperFortegnelsen over UXPin-formularfelter

Resumé

Interfaceinventariet er kilden til sandheden om status quo.

Alle elementer er dokumenteret og klar til enten at blive korrigeret, udskrevet eller inkluderet i den første kanoniske version af designsystemet. Del det med teamet og interessenter. I løbet af få minutter hjælper du dem med at indse fordelen ved at rydde op i oplevelsen med et designsystem.

Når du har dem om bord, skal du fokusere på at forene elementerne i opgørelsen med et fælles designsprog. Og det er nøjagtigt, hvad vi vil dække i det næste indlæg!

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