Designere er fra Saturn, udviklere er fra Jupiter: eller hvorfor kommunikation betyder noget

Om 'Men det ser anderledes ud på Specs' -effekten, UI Toolkits og andre ting.

To forskellige planeter, men de er i det mindste i det samme solsystem! Og det er slutningen på analogien med planeter.

Allergirådgivning

Dette er en artikel om designsystemer, især om emnet UI Toolkits og dynamikken i kommunikationen mellem designere og udviklere.

Designere, noget siger mig, at du ved om Design Systems, og at du muligvis kan grave dem :) I tilfælde af at du vil læse mere, skrev Nathan Curtis meget om det. Jeg elsker og respekterer hans arbejde med Design Systems.

Udviklere, jeg vil vise noget kode i slutningen. Legepladsen er et React + CSS-in-JS-bibliotek (såsom følelser eller stylede komponenter) -app.

Et slags typisk scenario

Vores designer producerede en række pæne designs, herunder layoutet på vores Dokumentside:

https://www.sketchappsources.com/free-source/2576-ooto-productivity-dashboards-sketch-freebie-resource.html

Det er rent, det er afbalanceret, det er lidt behageligt for øjet. For designerne er dette kulminationen på en lang proces, en hel række opgaver, der involverer forskning, samtale, tænkning, gennemgang, genovervejelse, tavle-ing, prototype og wireframing. En uhyggelig lang og kedelig proces, som udviklere ofte ikke udsættes for.

Hvordan producerede designerne alligevel dette billede? De brugte sandsynligvis et designværktøjssæt. En meget populær er Sketch.

Desværre er den måde, denne software fungerer på, diametralt i modsætning til den måde, udviklere arbejder på. Og jeg siger, at det er kernen i vores sag.

Designere har brug for værktøjer, der giver dem mulighed for hurtigt at gentage, gennemgå og opdatere, feedback efter feedback, det ene interessentmøde efter det andet. Designere har brug for værktøjer som Sketch.

Udviklere arbejder på den anden side anderledes.

De arbejder på stadigt skiftende codebaser, der på ethvert tidspunkt skal producere en fungerende udgivelse af en applikation. Det tager en indsats for at implementere et layout som det i vores eksempel, designe, abstrahere, implementere, refactoring, test, gennemgang, refactoring, bug fixing, refactoring. Udviklere er nødt til at sikre sig, at de ikke bryder noget andet eller forurener kodebasen med dårlig, dupliceret kode.

For mig er det at være designer mere som at springe frem og tilbage, mens udviklere arbejder i en kontinuerlig loop af udvikling.

Den Visual Spec-fil

Nu er det tid for designere at kommunikere med udviklere og aflevere stafetten.

Der er layouts, mellemrum og farver (og så videre), der skal dokumenteres. Sketch eller noget andet værktøj ved ikke meget om din nuværende kodebase, din filstruktur eller din abstraktion, så hvad kan Sketch gøre? Mål ting. Og det er hvad der vil blive produceret:

Et par dage går ...

Stuff er klar, og designerne ser det første:

Frustrerede designere, frustrerede udviklere.

Det er det øjeblik, hvor fortryllelsen virkelig brydes. Spec-filen. Små problemer med farve, afstand, typografi, layout, fejlagtige detaljer, manglende opførsel.

Udviklere bliver nødt til at tolke og tilpasse specifikationerne til deres eget system i kodebasen på farten, når de bare skulle bekymre sig om implementering af forretningslogikken for den nye funktion. Designere er dog ikke skylden - de ved ganske enkelt ikke om et sådant system.

Min bedstefar plejede at sige:

Når designere og udviklere ikke kommunikerer godt, skal du få et designsystem med et godt delt og kommunikeret sæt værktøjer, abstraktioner og begrænsninger.

Du har brug for en god UI Toolkit

Det er gennem et delt system, at designere og udviklere virkelig kan kommunikere effektivt uden stress. En UI Toolkit sigter mod at styrke de principper, der er dokumenteret i et Design System. Det styres af et meget delt og dokumenteret sæt konventioner, UI-mønstre, adfærd, og det er designet, testet og aftalt af alle. Det er her designere og udviklere indsats mødes.

Hvorfor du virkelig har brug for en god UI Toolkit

  • Bliv din app stadig mere kompleks?
  • Taler designere en hel del om uoverensstemmelser i appen?
  • CI / CD? Gå hurtigt hurtigt hurtigt?
  • Fjernhold?
  • Bliv lidt rodet med disse CSS-filer?
  • Begynder du at bekymre dig om størrelsen på appen?
  • Er brugeroplevelsen kernen i din forretningsmodel?

Du behøver ikke at markere alle disse - selv en kan være nok :)

Hvorfor du har brug for dit eget UI Toolkit

Et designsystem handler om sproget. Visuelt sprog, UI-designsprog osv. Det kræver en stor indsats at definere dit eget: Produkt, design, engineering, alle disse afdelinger vil være stærkt involveret.

Mange gange er det bare ikke en levedygtig mulighed. Der er fantastiske rammer derude, semantisk-ui, ant-design, Bootstrap, Material-UI. De leveres alle med en slags foruddannet sprog og en kamptestet UI-værktøjskasse, klar til brug.

Fangsten? Efter min ærlige mening passer de snart ikke længere til dig. Du vil undgå dem. Desuden er UI værktøjssæt sandsynligvis så konstrueret til at være svære at kontrollere. Husk, at disse rammer er lavet til at passere utallige sager, måske mere end hvad du har brug for. Desuden betales denne ekstra kompleksitet også i kb.

Stjæl som kunstner

Anvend ikke et UI Toolkit. Kopier fra andre i stedet, og med det mener jeg at tage de bits, der passer dig bedst, og implementere dem fra bunden. Det er nu almindeligt, at meget brugercentriske virksomheder har deres eget designsystem, og mange af dem er åbne!

Se på denne liste over designsystemer: https://adele.uxpin.com:

  • BBC: Gel
  • Trello: Nachos
  • Salesforce: Lyn

og snesevis mere. Og til sidst handler det om at designe og levere dette sammen. Det handler om at opbygge noget specifikt til dit domæne, også unikt og repræsentativt for dit brand. Det er givende, og du får også et pænt navn til det :)

Lad os lave en

Jeg vil vise dig, hvor let det er at startestrap dit eget designsystem.

Jeg kalder det Larry.

Lad os tage en lille del af vores layout og prøv at opbygge det fra bunden:

Slutresultat først

Følgende CodeSandbox er den eneste app i verden, der implementerer Larry:

Du kan finde Larry på GitHub: https://github.com/albinotonnina/larry

Dokumentationen

Denne bit er den vigtigste. Hvem har ansvaret for dette, måske Designere? Godt typisk ja, men tro mig på dette: I skulle begge være lige involveret i at dokumentere dit sprog. I skulle begge være enige om bogstaveligt talt alt her.

Lad os begynde at definere nogle virkelig basale konventioner:

farver

Lad os generere en palet til vores layout.

Jeg foreslår, at du definerer en række semantiske navne fra disse farver, sådan:

headerText = JapaneseIndigo
paragraphText = JapaneseIndigo
elementBackgroundDefault = Sne
elementBackgroundHover = BrilliantAzure
elementButton = LightGray - alpha 60%

Dette er de navne, som du begge vil bruge, når du specificerer (som er et ord).

Mellemrum

Vær ekstra opmærksom på afstand. Uden en klar strategi for afstand kan ting gå virkelig galt.

Definer og enige om et afstandssystem, for eksempel:

En spec-fil ser sådan ud:

Typografi

Sørg for, at fontstørrelser, fontvægte, linjehøjder, marginer, farver i dine overskrifter, dine afsnit og så videre bare matcher. Ring til dem med navne, du kan lide, f.eks. HeaderHuge, HeaderLarge, HeaderTiny eller brug semantiske tags (h1, h2, h3) korrekt. Bare sørg for, at du er på linje med dette.

Mønstre

Hvad rimer med UI Toolkit? Mønsterbibliotek! Du skal begynde at udfylde dit bibliotek med mønstre. Det, du ønsker, er at have de komponenter, du har brug for, opføre sig som du aftalt, så du kan komponere dem, som du vil, når som helst du ønsker.

Start fra partiklerne og primitiverne, sådan en boksekomponent, for når du skal indstille mellemrum og grænser rundt om noget andet.

Tilføj mere specialiserede nye partikler, f.eks. En tekstkomponent eller en flexkomponent, som du kunne forestille dig som en boksekomponent + nogle flexværktøjer.

Se dem som partikler, der lever isoleret, ikke opmærksomme på den kontekst, i hvilken de vil blive brugt, og af det rum, der skal eksistere omkring dem.

Fortsæt med mere komplekse brugergrænsefladekomponenter, sammensætninger af andre mindste komponenter osv.

Det, der er vigtigt her, er ikke teknologien eller hvilke slags abstraktioner der findes i din dokumentation. Det, der er vigtigt, er, at du gør dette sammen.

Eksempel på en mere kompleks UI-komponent

Får du kerne?

Du har defineret konstanter, og du har nogle partikler at bygge.

Du gentager over disse partikler og udvider biblioteket temmelig hurtigt, så omfavne og forbered dig på elasticitet. Udviklere, du vil ikke have, at designere skal være færdige med at dokumentere hele systemet, før de begynder at implementere koden. Du skal gøre denne ting sammen, ellers går det ikke bare af.

Så designere og udviklere, lav lige efter artiklen, lav din egen Larry, hvis du ikke har en!

Kode

Du har en kopi af Larry, du kan klone og lege med den. Din Larry kan være anderledes, eller du bruger muligvis forskellige rammer, så jeg vil gennemgå nøglepunkterne i denne tilgang.

Tema, definer konstanterne

Det er et objekt med vores temakonstanter, så mellemrumsdefinitioner, farver, skrifttyper, typografi, breakpoints, hvad som helst. Her er Larrys tema, og her er en eksempelversion af det:

Der er ingen grænse for den kompleksitet / fuldstændighed, du kan opnå her, når alt kommer til alt er det et spørgsmål om at generere et JavaScript-objekt, bare forestil dig, hvad du kunne gøre!

Dette er en kernefil. Hver farve, margin eller polstring, fontstørrelse eller fontvægt eller brudpoint skal komme herfra og kun herfra.

CSS-in_JS-biblioteker er fantastiske værktøjer, og stylet system gør dem endnu bedre. Det er et sæt værktøjer til designsystemer og består af funktioner, der tager rekvisitter som et argument og returnerer stilobjekter, mens det gør det enklere at bruge værdier fra et tema og anvende stilarter responsivt på tværs af breakpoints.

Denne tilgang drager fordel af disse værktøjer, så føl dig fri til at evaluere den.

Sæt temaet i din app

Angiv disse konstanter til din app: hver komponent i appen har adgang til vores temakonstanter.

Opret grundlæggende brugergrænsefladekomponenter

en primitiv Box UI-komponent

Mere specialiserede UI-komponenter

Her er en Flex-komponent.

Implementere UI-komponenter i dine funktionsfiler

Tid til at gengive noget

Det er her du implementerer din UI-komponent og din forretningslogik.

Filstrukturen

Dette er Larrys filstruktur. Jeg har ikke stærke meninger om filstrukturer, faktisk tror jeg på noget andet: Flyt dine filer rundt, indtil du har det godt med dem.

Larry er alt sammen i en "design-system" -mappe. Det er her du kan finde dens konstanter og generiske og genanvendelige UI-komponenter.

Bemærk også UI-mappen i mappen Dokumentlayout - det er her jeg definerer og eksporterer de UI-komponenter, der er specifikke for vores funktion.

Konklusion

Med store og komplekse apps er det aldrig nemt at holde UI'en konsistent og sammenhængende. Hjælp til designsystemer. Tilpassede designsystemer og skræddersyede UI-værktøjssæt hjælper virkelig.

Designere og udviklere kan have meget forskellige tilgange til det samme problem, men det betyder ikke, at de ikke kan kommunikere effektivt.

https://dribbble.com/shots/2712522-Designer-vs-Developer

Tak fordi du læste

Har du positive oplevelser at dele? Gør det venligst i kommentarerne.

Hej, jeg hedder Albino Tonnina, jeg er en softwareingeniør, der arbejder i London, du kan finde mig på Twitter eller Github eller Instagram eller rundt i byen.

Mine seneste artikler

Sådan mister du et it-job inden for 10 minutter
Apropos weblayouts… introduktion af Magic Hat-teknikken

Følg mig på Twitter!