Designverktøyene går tom for spor. Slik kan vi fikse dem.

Det går sjelden en dag der jeg ikke bruker minst tid på å tenke på designverktøy. For noen år siden bygde jeg et designverktøy som ble anskaffet av Marvel. Det var over to år siden, men siden har ikke landskapet forandret seg mye, og har heller ikke min lidenskap for å forbedre det.

Nylig twitret jeg om designverktøy - noe som har vært kjent for å skje fra tid til annen.

Jeg var ikke den eneste som snakket tankene den dagen, andre chimet også inn.

28. juli 2017 var ingen god dag for designverktøy.

Det er mye flott innsikt begravd i disse Twitter-trådene, men i lang tid har jeg ønsket å ta meg tid til å dykke dypt inn i akkurat det det er som jeg synes er så grunnleggende ødelagt for den nåværende designverktøymodellen, også som et hint på retningen tror jeg vi bør gå.

Vi tegner bare bilder. Det er sinnssykt.

Nesten alle populære designverktøyer eksporteres til bilder. Dette er problematisk av flere årsaker:

  1. Du kan ikke samhandle med et bilde. Prototyping-verktøy gir oss mulighet til å legge til skjermoverganger og enkle interaksjoner i bilder. Imidlertid, ettersom produktene våre fortsetter å kreve mer avanserte skjermoverganger og mikrointeraksjoner, kan bilder ganske enkelt ikke følge med.
  2. Bilder er ikke flytende. Å kommunisere responsive designbeslutninger gjennom bilder er vanligvis en vanskelig oppgave.
  3. Bilder er ikke statlige. For å effektivt kommunisere de forskjellige statene for et brukergrensesnitt, er det ofte mange bilder som er nødvendige.
  4. Bitmappbilder er avhengig av oppløsningen. Med bruk av netthinneenheter kan bilder noen ganger gjengis dårlig.
  5. Bildefiler har en tendens til å være tunge og er ofte tungvint å lagre, administrere eller dele.

Så lenge designverktøyene fortsetter å eksportere bilder, vil de aldri kunne produsere nøyaktige representasjoner av våre produkter. Denne mangelen på nøyaktighet hindrer kommunikasjonen mellom designere og utviklere. Så lenge designere fortsetter å bruke et sørgelig utilstrekkelig medium for å formidle arbeidet sitt, vil det arbeidet alltid være åpent for feiltolkning.

Dette er et veldig viktig poeng fordi i kjernen deres nesten alle designverktøy konverterer vektorformer til bilder. Photoshop, Illustrator, Marvel, Adobe XD, Sketch og Figma er alle de samme i denne forbindelse. Likevel kan bilder bare delvis kommunisere designintensjoner. Etter hvert som produktene våre fortsetter å ta i bruk og støtte komplekse interaksjoner, taleinngang, videoinngang, augmented reality, virtual reality, temperatur sensitivity etc., vil verdien disse verktøyene gir raskt avta. Bildebasert design er en blindvei.

Designverktøyene våre skal manipulere det faktiske produktet, ikke et bilde av det.

Produktene våre er interaktive. Våre verktøy er statiske.

Jeg rørte ved dette i mitt forrige punkt, men det er superkritisk, så jeg tenkte at jeg ville utdype litt.

Tenk på mengden enkle interaksjoner som er vanlig i nesten alle produktene våre, men som ikke kan kommuniseres gjennom designverktøyene våre. Her er en kort liste over toppen av hodet:

  • Hold musepekeren
  • Fokuserer et innspill
  • Merk av for en avkrysningsrute
  • Innhold med faner
  • Bla i områder
  • Tabulasjonsindeks for fokuserte tilstander
  • Tastatursnarveier

Visst, noen av disse funksjonene kan bli etterlignet med noe habil teknikk, men man må lure på, hva i all verden er poenget? Hvorfor kan ikke designere bare designe det egentlige produktet ?! Til syvende og sist er alle mockups engangsbruk, men likevel bruker designere måneder på å finpusse dem til perfeksjon. Den tiden ville være mye bedre brukt på å finpusse selve produktet.

Jeg vil ikke gå for langt ned "bør designerkoden" kaninhullet, men jeg foreslår ikke at vi alle skriver kode. Jeg sier bare at det ikke er noen god grunn til at designverktøyene våre ikke kan støtte direkte manipulering av våre levende produkter.

Framer gjør en bedre jobb enn de fleste på denne avdelingen, og støtter avanserte og detaljerte interaksjoner. Resten av pakken er veldig langt bak.

Våre verktøy skal støtte nettets layoutparadigme

Inntil for omtrent et år siden, var den eneste måten å bygge oppsett på nettet ved å bruke skjermen: tabell og vertikaljustere CSS-egenskaper. Nå har vi Flexbox og snart vil vi ha CSS-nett. Disse tre layoutmotorene fungerer ganske likt og bruker strømmen til DOM. Nesten alle nettsteder er bygget ved hjelp av et av disse tre layoutsystemene.

Så det er fornuftig at designverktøyene våre støtter den samme layoutmodellen. Ikke sant?

Vel, nesten alle designverktøy ignorerer disse layoutsystemene, og velger i stedet å plassere hvert lag absolutt innenfor tavlen. Dette åpner en kløft mellom hvordan nettet fungerer og hvordan designverktøyene våre fungerer, og introduserer mange problemer:

  • Responsiv design blir veldig vanskelig fordi hvert lag må omorganiseres manuelt for hvert bruddpunkt. Alternativt kan det innføres et begrensningsbasert layoutsystem, men som tilfører kompleksitet, styrker læringskurver og til slutt forhindrer utviklere fra å overføre layout direkte til nettet.
  • Siden hvert lag er utenfor strømmen av dokumentet, blir manipulering av innhold vanskelig. Hvis du for eksempel vil legge til et element i en liste, må du manuelt flytte de andre elementene i listen. Selvfølgelig kan repeterende funksjoner og andre fancy funksjoner introduseres for å lette smertene, men igjen, dette introduserer ekstra kompleksitet og kompliserer noe som DOM gir oss gratis.
  • Absolutt plassering fører naturlig til faste pikselkoordinater og dimensjoner. Dette avler ufleksibilitet og er igjen en enorm avgang fra hvordan nettet fungerer. Internett er bygget på væskeenheter som em, rem, vh, vw og%. Våre verktøy skal støtte disse enhetene som standard.

Designverktøy skal ikke trenge å ligne eller reflektere nettet og nyansene - de skal bare være nettet.

Et monolitisk verktøy er ikke veien

God design skjer i trinn. Et godt strukturert designsystem har noen få forskjellige lag:

  1. Stilpalett En samling farger, skygger, avstand, kantradier, skrifttyper, skriftstørrelser, animasjoner og andre stiler som danner merkevareidentiteten din. For tiden støtter de fleste designverktøy bare fargepaletter. Inntil de støtter de andre stilegenskapene, vil det være ekstremt arbeidskrevende å designe systematisk.
  2. Eiendeler Dette inkluderer elementer som ikoner, illustrasjoner og bilder. Det er noen fenomenale billedredigerere der ute, og Figmas vektorverktøy er utmerket, men når det kommer til SVG-støtte, forlater designverktøyene våre mye å være ønsket.
  3. Komponentbibliotek En komponent er en samling av stiler og eiendeler som gjengir data til et enkelt element i en rekke varianter. Eksempler inkluderer knapper, innganger, merker osv. Som jeg nevnte, har Figma og Sketch nylig abstraktert denne prosessen vekk fra hovedtegningstrømmen - det er synd at de bare er bilder av komponenter og ikke faktiske komponenter.
  4. Moduler En modul / komposisjon er en samling av komponenter som gjengir data til et innkapslet stykke UI i en rekke stater. Eksempler kan være topplinjer, tabulatormenyer, påloggingsformer, tabeller osv. Siden moduler bare er komplekse komponenter, antar jeg at Figma og Sketch kan håndtere disse også. Skjønt det kan være en viss fortjeneste å skille de to.
  5. Skjermbilder En skjerm er en samling av moduler, komponenter og data for å danne et komplett brukergrensesnitt som brukeren kan samhandle med.

De fleste designverktøy gir funksjoner som i hvert fall i noen grad støtter hvert av disse designtrinnene. Problemet er at alle trinnene er konfliktfylt. Nesten alle designverktøyene tilbyr bare én modus - tegningsmodus. Du lager et sett med tavler og bare begynne å tegne bilder. Bare ganske nylig har verktøy som Sketch og Figma abstrakte komponenter / symboler vekk fra hovedtegningsmodusen - noe som er rart fordi komponenter i front-end har blitt abstrahert i mange år.

Når jeg designer en stilpalett, trenger jeg ikke å se tegnebrett eller vektorverktøy. Jeg vil se verktøy for å velge harmoniske farger. Jeg vil ha forhåndsinnstillinger for ting som en 8dp avstandsskala eller et utvalg av typeskalaer.

Å designe et ikon krever en helt annen tenkemåte for å designe en brukerflyt. En enkel SVG-editor som tillot meg å tegne innfødte SVG-rektangler, sirkler, linjer og stier og deretter eksportert optimalisert SVG-kode ville være ideelt.

Når jeg designer en komponent, skulle jeg ikke lenger tenke på individuelle stiler - jeg burde ganske enkelt velge stiler fra den forhåndsdefinerte stilpaletten. Jeg kan ikke bare begynne å finpusse stiler for en komponent fordi det ville introdusere inkonsekvens og fortynne effektiviteten til designsystemet mitt. Når en stilpalett er på plass, bør den bare redigeres ved kilden.

På samme måte, mens jeg komponerer en modul, skulle jeg bare bli utsatt for mitt forhåndsdefinerte komponentbibliotek. Det skal ikke være noen stilegenskaper i en sidefelt. Ingen vektorverktøy. Bare et bibliotek med gjenbrukbare komponenter som jeg kan dra og slippe for å komponere moduler.

Det samme gjelder for å komponere skjermer. På dette tidspunktet bruker vi bare komponenter og moduler for å bygge et brukergrensesnitt. Vi tenker ikke på stiler eller former eller andre kreative bestrebelser. Vi fokuserer først og fremst på å utforme innholdet og brukerstrømmene.

Hvert av disse designtrinnene kan foregå i separate verktøy helt eller bare i forskjellige modus i det samme verktøyet. Jeg tror ikke det betyr noe særlig. En ting er imidlertid sikkert, de fleste aktuelle designverktøy klarer ikke engang å anerkjenne prosessen.

Våre verktøy skal oppmuntre til god design

Designere har den sjeldne luksusen å kunne legge til et uendelig antall unike stiler til et prosjekt uten merkbare konsekvenser. Trenger du en litt større skriftstørrelse? Bare støt det opp. Ikke tenk på det. Trenger du en litt lysere farge? Bare finpusse det. Det er kult. Du kan til og med lage flere tegnebrett i samme prosjekt, der hver bruker litt forskjellige verdier for lignende stiler, og det vil sannsynligvis gå upåaktet hen.

Designverktøyet ditt kommer aldri til å fortelle deg at du ikke kan gjøre noe. Det kommer aldri til å trekke deg opp for å bruke en farge utenfor merkevaren. Det kommer aldri til å hindre deg i å bruke en hvit mellomrom-verdi som ikke hører hjemme i din avstandsskala. Det vil aldri advare deg om at 20% av befolkningen bokstavelig talt ikke kan se den lysegrå teksten du nettopp har designet.

Og hvorfor ikke…? Fordi designverktøy ikke bryr seg.

Designverktøy er såpass fortrolig med en visjon for ubegrenset kreativitet at de har mistet synet av hva det vil si å utforme fornuftig, å designe inkluderende, å designe systematisk.

Enkelt sagt, designverktøy lar oss gjøre hva faen vi vil. Til en viss grad er dette nivået av grenseløs kreativitet nyttig, spesielt i forestillingsfasene. Som UI-designere krever imidlertid ikke flertallet av arbeidsflyten mye kreativitet. Snarere krever arbeidsflyten vår gjenbruk, repetisjon, kjent og standardisering; behov som verktøyene våre gjør lite for å tilfredsstille.

Denne ubegrensede friheten er i strid med virkeligheten av nettutvikling. Siden utviklere jobber med det faktiske produktet, må de alle jobbe med samme kode. Utviklere kan ikke bare legge isolerte skriftstørrelser eller tilfeldige fargeverdier til kodebasen. For det første vil en lint (en advarsel om advarsel om dårlig skrevet kode) sannsynligvis begynne å skrike umiddelbart. Hvis ikke, vil sannsynligvis deres beskjedne håndverk bli arrestert under en kodevurdering. Hvis det på en eller annen måte klarte å skli gjennom sprekkene, vil en merkbar ytelseseffekt til slutt gi alarm.

Et av de mest forstyrrende problemene jeg ser på produktgrupper er koblingen mellom design- og utviklingsteam. Utviklere har jobbet med strenge retningslinjer og begrensninger i mange år. Med mindre designverktøyene våre bruker de samme begrensningene, vil gapet aldri bli mindre.

Vi bør designe med live data

Live-data har blitt integrert til en viss grad av mange verktøy, noe som er flott å se. Adobe XD har noen veldig pene funksjoner for å generere falske data som ligner typiske livedata. Invision Craft tilbyr også noen kule live data-funksjoner for Sketch.

Live-data skal ikke slutte med tekst. Andre elementer som bilder og video kan ha stor innvirkning på brukeropplevelsen ved å øke belastningstiden betydelig. Hvis du jobber på nettet, gir nettleserens dev verktøy deg muligheten til å strupe forbindelsen for å ligne en rekke internetthastigheter. Deretter kan du se førstehånds hvordan et nytt innhold kan påvirke brukeropplevelsen.

Har våre designverktøy råd til oss denne luksusen?

Med et ord: nei.

Jo nærmere vi kommer til å designe det egentlige produktet, jo mer nyttig og effektfullt kan designarbeidet vårt være.

Internett er åpent. Våre verktøy bør også være.

Noe av det virkelig vakre ved nettet er dens åpne tilgjengelighet. Et nettsted kan sees i hvilken som helst nettleser på omtrent hvilken som helst enhet.

Hvordan kan det sammenlignes med designverktøy? For noen dager siden ba broren min David meg om en designgjennomgang av en app han bygger. Han sendte meg en skissefil. Da jeg åpnet den, skjedde dette ...

De fleste designverktøy er inngjerdede hager. Hvis en kollega jobber i Photoshop, kan ikke en annen kollega åpne det prosjektet i Sketch. Det er ikke engang å ha hele teamet ditt til å bruke det samme verktøyet - de må også bruke den samme versjonen av det verktøyet.

Marvel og Figma gjør en god jobb her, og tilbyr gratis planer og innovative samarbeidsfunksjoner.

Så hva er fremtiden for designverktøy?

Innovasjon innen designverktøy er ekstremt verdifullt og det har skjedd mye i det siste. På Airbnb designverktøy har Jon Gold og Benjamin Wilkins jobbet med React-Sketchapp som tar React-komponenter og gjengir dem i Sketch. Jon og Ben har også jobbet med et forbløffende nytt verktøy som tar serviettskisser og på en eller annen måte gjør dem til React-komponenter.

Adam Morse, Brent Jackson og John Otander jobber med en pakke med verktøy hos Compositor som i utgangspunktet løser alle problemene i denne artikkelen og kanskje verden.

Jeg jobber med Modulz, et nytt designverktøy og open-source designsystem som også har som mål å løse problemene jeg nevnte i denne artikkelen. Hvis du er interessert, følg med på Twitter for oppdateringer.

Selv om innovasjon i verktøy er viktig, er den virkelige utfordringen utdanning. Designfellesskapet er rett og slett ikke klart for et systematisk designverktøy. Mange designere har liten eller ingen interesse for å bygge systemer. For noen er JPG sluttmålet - Dribblingen liker.

Vi må på en eller annen måte inspirere til en kultur for ansvarlighet. Utviklere har hatt en ansvarlighetskultur i mange år. De har verktøy for å holde koden i sjakk. Hvis en utvikler gjentatte ganger avviker fra sine strenge retningslinjer for kode, kan du være sikker på at problemet blir løst.

I mellomtiden samler designere ofte fjell av lag i fullstendig uenighet med liten hensyn til lagnavn, gruppering og bestilling. Det er veldig mye hver for seg. Siden utdataene (rasterbildet) ikke påvirkes av inngangen (vektorsjikt), er det ingen reell belastning for designere å organisere. Designere unnskylder ofte denne mangelen på organisering ved å romantisere designkunsten, male seg selv som tryllekunstnere som må overlates til sine egne enheter for å opptre.

Vi må også inspirere en kultur for inkludering. Vi bør aktivt avskrekke malpractice som ultralette tekstfarger som gjør tekst vanskelig å lese for mange mennesker, eller super høykvalitets skrifttyper som gjør at nettsider blir treg å laste, eller mønsterløse brukergrensesnittelementer som gjør ting vanskelig å forstå for fargeblinde. For øyeblikket applauderes denne typen feilbehandling blant designfellesskapet. Hvis vi ønsker velkommen til et smart designverktøy, må vi snu denne kulturen.

Hvis et systematisk designverktøy skal vinne hjertene våre, må det først utdanne seg.