Designverktyg går slut. Så här kan vi fixa dem.

Det går sällan en dag där jag inte ägnar åtminstone lite tid åt att tänka på designverktyg. För några år sedan byggde jag ett designverktyg som förvärvades av Marvel. Det var för över två år sedan men sedan dess har landskapet inte förändrats mycket, och min passion för att förbättra det har inte heller ändrats.

Nyligen tweetade jag om designverktyg - en sak som har varit känd att hända då och då.

Jag var inte den enda som talade mitt sinne den dagen, andra chimade också in.

28 juli 2017 var ingen bra dag för designverktyg.

Det finns mycket bra insikt begravd i dessa Twitter-trådar men under lång tid har jag velat ta mig tid att dyka djupt in i precis vad det är som jag tror är så grundläggande trasig i den nuvarande modellen för designverktyg, liksom som antydan till riktningen tror jag att vi borde ledas.

Vi tar alla bara bilder. Det är galet.

Nästan alla populära designverktyg exporterar till bilder. Detta är problematiskt av flera skäl:

  1. Du kan inte interagera med en bild. Prototypverktyg ger oss möjlighet att lägga till skärmövergångar och enkla interaktioner till bilder. Men eftersom våra produkter fortsätter att kräva mer avancerade skärmövergångar och mikrointeraktioner, kan bilder helt enkelt inte hålla jämna steg.
  2. Bilder är inte flytande. Att kommunicera lyhörd designbeslut genom bilder är vanligtvis en svår uppgift.
  3. Bilder är inte tillåtna. För att effektivt kunna kommunicera de olika staterna för ett användargränssnitt är det ofta många bilder som behövs.
  4. Bitmappsbilder är upplösningsberoende. I samband med näthinnanordningar kan bilder ibland visas dåligt.
  5. Bilderfiler tenderar att vara tunga och är ofta besvärliga att lagra, hantera eller dela.

Så länge designverktyg fortsätter att exportera bilder kommer de aldrig att kunna producera exakta representationer av våra produkter. Denna brist på noggrannhet hindrar kommunikationen mellan designers och utvecklare. Så länge designers fortsätter att använda ett sorgligt otillräckligt medium för att kommunicera sitt arbete, kommer det arbetet alltid att vara öppet för missuppfattning.

Detta är en mycket viktig punkt eftersom i deras kärna nästan alla designverktyg konverterar vektorformer till bilder. Photoshop, Illustrator, Marvel, Adobe XD, Sketch och Figma är alla samma i detta avseende. Ändå kan bilder bara delvis kommunicera designintressen. När våra produkter fortsätter att anta och stödja komplexa interaktioner, röstinmatning, videoinmatning, augmented reality, virtual reality, temperaturkänslighet etc., kommer värdet som dessa verktyg ger att minska snabbt. Bildbaserad design är en återvändsgränd.

Våra designverktyg ska manipulera den faktiska produkten, inte en bild av den.

Våra produkter är interaktiva. Våra verktyg är statiska.

Jag berörde detta i min tidigare punkt men det är superkritiskt så jag tänkte att jag skulle utarbeta lite.

Tänk på mängden enkla interaktioner som är vanliga i nästan alla våra produkter men som ännu inte kan kommuniceras med våra designverktyg. Här är en kort lista över mitt huvud:

  • Håll muspekaren på en knapp
  • Fokusera en inmatning
  • Kontrollera en kryssruta
  • Flikinnehåll
  • Rulla områden
  • Flikindex för fokuserade tillstånd
  • Tangentbordsgenvägar

Visst, vissa av dessa funktioner kan imiteras med en del hackig teknik, men man måste undra, vad på jorden är poängen? Varför kan inte designare bara utforma själva produkten ?! I slutändan är alla mockups engångsbruk, men ändå spenderar designers månader på att justera dem till perfektion. Den tiden skulle mycket bättre spenderas på att finjustera den faktiska produkten.

Jag kommer inte att gå för långt ner i kaninhålet "ska designarkoden" men jag föreslår inte att vi alla skriver kod. Jag säger bara att det inte finns någon god anledning till att våra designverktyg inte kan stödja direkt manipulation av våra levande produkter.

Framer gör ett bättre jobb än de flesta på denna avdelning och stöder avancerade och detaljerade interaktioner. Resten av förpackningen är väldigt långt efter.

Våra verktyg bör stödja webbs layoutparadigm

Fram till för ungefär ett år sedan var det enda sättet att bygga layouter på webben att använda displayen: tabell och CSS-egenskaper vertikalt anpassade. Nu har vi Flexbox och snart kommer vi att ha CSS-nät. Dessa tre layoutmotorer fungerar ganska på samma sätt och använder flödet av DOM. Nästan alla webbplatser är byggda med ett av dessa tre layoutsystem.

Så det är meningsfullt att våra designverktyg stöder samma layoutmodell. Rätt?

Tja, nästan alla designverktyg ignorerar dessa layout-system, istället väljer du att placera varje lager absolut på sitt tavla. Detta öppnar en klöv mellan webben fungerar och hur våra designverktyg fungerar och introducerar många problem:

  • Responsiv design blir mycket svårt eftersom varje lager måste ordnas om manuellt för varje brytpunkt. Alternativt kan ett begränsningsbaserat layoutsystem införas, men det lägger till komplexitet, ökar inlärningskurvorna och slutligen hindrar utvecklare från att överföra layouten direkt till webben.
  • Eftersom varje lager ligger utanför dokumentets flöde blir manipulering av innehåll svårt. Om du till exempel vill lägga till ett objekt i en lista måste du manuellt flytta de andra artiklarna i den listan. Naturligtvis kan upprepade funktioner och andra snygga funktioner introduceras för att underlätta smärtan men återigen, detta introducerar extra komplexitet och komplicerar något som DOM ger oss gratis.
  • Absolut positionering leder naturligt till fasta pixelkoordinater och dimensioner. Detta avlar flexibilitet och, återigen, är en enorm avvikelse från hur webben fungerar. Webben är byggd på vätskeenheter som em, rem, vh, vw och%. Våra verktyg bör stödja dessa enheter som standard.

Designverktyg ska inte behöva likna eller reflektera webben och dess nyanser - de bör bara vara webben.

Ett monolitiskt verktyg är inte vägen

Bra design händer i steg. Ett välstrukturerat designsystem har några olika lager:

  1. Stilpalett En samling färger, skuggor, avstånd, kantradie, typsnitt, typstorlekar, animationer och andra stilar som bildar din varumärkesidentitet. För närvarande stöder de flesta designverktyg bara färgpaletter. Tills de stöder de andra stilegenskaperna kommer det att vara extremt besvärligt att designa systematiskt.
  2. Tillgångar Detta inkluderar element som ikoner, illustrationer och bilder. Det finns några fenomenala bildredigerare där och Figmas vektorverktyg är utmärkt men när det gäller SVG-support lämnar våra designverktyg mycket att önska.
  3. Komponentbibliotek En komponent är en samling stilar och tillgångar som ger data till ett enda element i en mängd olika variationer. Exempel inkluderar knappar, ingångar, märken etc. Som jag nämnde har Figma och Sketch nyligen abstraktat denna process bort från huvudritningsflödet - det är synd att de bara är bilder av komponenter och inte faktiska komponenter.
  4. Moduler En modul / komposition är en samling av komponenter som ger data till en inkapslad bit av UI i en mängd olika tillstånd. Exempel kan inkludera rubrikfält, flikmenyer, inloggningsformulär, tabeller etc. Eftersom moduler bara är komplexa komponenter antar jag att Figma och Sketch kan hantera dessa också. Även om det kan vara viss fördel att separera de två.
  5. Skärmar En skärm är en samling av moduler, komponenter och data för att bilda ett komplett användargränssnitt som användaren kan interagera med.

De flesta designverktyg ger funktioner som stöder vart och ett av dessa konstruktionsstadier åtminstone till viss del. Problemet är att alla etapper är konflikterade. Nästan alla designverktyg erbjuder bara ett läge - ritningsläget. Du skapar en uppsättning av tavlor och börjar bara rita bilder. Bara nyligen har verktyg som Sketch och Figma abstraherade komponenter / symboler bort från huvudritningsläget - vilket är konstigt eftersom komponenter i front-end har abstraherats i många år.

När jag utformar en stilpalett behöver jag inte se tavlor eller vektorverktyg. Jag vill se verktyg för att välja harmoniska färger. Jag vill ha förinställningar för saker som en 8dp avståndskala eller ett urval av typskalor.

Att designa en ikon kräver ett helt annat tänkande för att designa ett användarflöde. En enkel SVG-redaktör som tillät mig att rita ursprungliga SVG-rektanglar, cirklar, linjer och banor och sedan exportera optimerad SVG-kod skulle vara idealisk.

När jag utformar en komponent bör jag inte längre tänka på enskilda stilar - jag skulle helt enkelt välja stilar från min fördefinierade stilpalett. Jag kan inte bara börja finjustera stilar för en komponent eftersom det skulle innebära inkonsekvens och utspäda effektiviteten i mitt designsystem. När en stilpalett är på plats bör den bara kunna redigeras vid källan.

På samma sätt bör jag bara utsättas för mitt fördefinierade komponentbibliotek när jag komponerar en modul. Det bör inte finnas några stilegenskaper i en sidofält. Inga vektorverktyg. Bara ett bibliotek med återanvändbara komponenter som jag kan dra och släppa för att komponera moduler.

Detsamma gäller för att komponera skärmar. Just nu använder vi bara komponenter och moduler för att bygga ett användargränssnitt. Vi funderar inte på stilar eller former eller andra kreativa ansträngningar. Vi fokuserar främst på att utforma innehållet och användarflödena.

Var och en av dessa konstruktionssteg kan ske i separata verktyg helt eller bara i olika lägen inom samma verktyg. Jag tror inte att det betyder mycket. En sak är dock säker, de flesta aktuella designverktyg misslyckas inte ens med att erkänna processen.

Våra verktyg bör uppmuntra till god design

Formgivare har den sällsynta lyxen att kunna lägga till ett oändligt antal unika stilar till ett projekt utan några märkbara följder. Behöver du något större typsnitt? Stoppa bara upp det. Ingen biggie. Behöver du en något ljusare färg? Justjustera det. Det är lugnt. Du kan till och med skapa flera tavlor i samma projekt, var och en med lite olika värden för liknande stilar och det skulle förmodligen gå obemärkt.

Ditt designverktyg kommer aldrig att säga att du inte kan göra något. Det kommer aldrig att dra dig upp för att använda en färg utanför märket. Det kommer aldrig att hindra dig från att använda ett vitrumsavstånd som inte hör till din avståndskala. Det kommer aldrig att varna dig för att 20% av befolkningen bokstavligen inte kan se den ljusgrå text du just har designat.

Och varför inte…? Eftersom designverktyg inte bryr sig.

Designverktyg är så riktigt förtrollade med en vision för obegränsad kreativitet att de har förlorat synen på vad det innebär att utforma på ett förnuftigt sätt, att designa inkluderande, att designa systematiskt.

Enkelt uttryckt, designverktyg tillåter oss att göra vad fan vi vill. I viss utsträckning är denna nivå av gränslös kreativitet användbar, särskilt i ideationsfaserna. Som UI-designers kräver dock majoriteten av vårt arbetsflöde inte mycket kreativitet. Snarare kräver vårt arbetsflöde återanvändning, upprepning, kännedom och standardisering; behov som våra verktyg gör lite för att tillfredsställa.

Denna obegränsade frihet är i strid med verkligheten i webbutveckling. Eftersom utvecklare arbetar med själva produkten måste de alla arbeta med samma kod. Utvecklare kan inte helt enkelt lägga till isolerade teckensnittstorlekar eller slumpmässiga färgvärden till kodbasen. För det första skulle en linter (ett varningsmeddelande som varnar om dåligt skriven kod) troligen börja skrika omedelbart. Om inte, skulle deras dåliga hantverk förmodligen gripas under en kodgranskning. Om det på något sätt lyckades glida genom sprickorna skulle en märkbar prestandapåverkan slutligen ljuda larmet.

Ett av de mest störande problemen jag ser i produktgrupper är kopplingen mellan design- och utvecklingsgrupper. Utvecklare har arbetat med strikta riktlinjer och begränsningar i flera år. Om inte våra designverktyg använder samma begränsningar, kommer luckan aldrig att minska.

Vi borde designa med livedata

Live-data har till viss del införlivats av många verktyg, vilket är bra att se. Adobe XD har några riktigt snygga funktioner för att generera falska data som liknar typiska livedata. Invision Craft tillhandahåller också några coola livedatafunktioner för Sketch.

Live data bör dock inte sluta med text. Andra element som bilder och video kan ha en stor inverkan på användarupplevelsen genom att öka belastningstiderna avsevärt. Om du arbetar på webben gör det möjligt för webbläsarens dev-verktyg att stryka anslutningen för att likna olika internethastigheter. Sedan kan du först se hur ett nytt innehåll kan påverka användarupplevelsen.

Har våra designverktyg oss den här lyxen?

Med ett ord: nej.

Ju närmare vi kommer att utforma själva produkten, desto mer användbart och påverkande kan vårt designarbete vara.

Webben är öppen. Våra verktyg borde också vara det.

En av de verkligt vackra sakerna med webben är dess öppna tillgänglighet. En webbplats kan ses i valfri webbläsare på nästan vilken enhet som helst.

Hur jämför det med designverktyg? Nåväl, för några dagar sedan bad min bror David mig om en designgranskning av en app han bygger. Han skickade mig en skissfil. När jag öppnade det hände detta ...

De flesta designverktyg är muromgärdade trädgårdar. Om en kollega arbetar i Photoshop kan en annan kollega inte öppna projektet i Sketch. Det räcker inte ens med att hela teamet använder samma verktyg - de måste också använda samma version av det verktyget.

Marvel och Figma gör ett bra jobb här och erbjuder gratis planer och innovativa samarbetsfunktioner.

Så vad är framtiden för designverktyg?

Innovation inom designverktyg är oerhört värdefullt och det har skett mycket av det nyligen. På Airbnb designverktyg har Jon Gold och Benjamin Wilkins arbetat med React-Sketchapp som tar React-komponenter och gör dem inuti Sketch. Jon och Ben har också arbetat med ett sinnesblåsande nytt verktyg som tar servetskisser och på något sätt förvandlar dem till React-komponenter.

Adam Morse, Brent Jackson och John Otander arbetar på en svit med verktyg hos Compositor som i princip löser alla problemen i den här artikeln och kanske världen.

Jag arbetar med Modulz, ett nytt designverktyg och open-source designsystem som också syftar till att lösa problemen jag nämnde i den här artikeln. Om du är intresserad, följ med på Twitter för uppdateringar.

Även om innovation i verktyg är viktig, är den verkliga utmaningen utbildning. Designgemenskapen är helt enkelt inte redo för ett systematiskt designverktyg. Många designers har lite till inget intresse för att bygga system. För vissa är JPG slutmålet - Dribblan gillar.

Vi måste på något sätt inspirera till en ansvarighetskultur. Utvecklare har haft en kultur av ansvarighet i flera år. De har verktyg för att hålla koden i kontroll. Om en utvecklare upprepade gånger avviker från sina strikta riktlinjer för kod kan du vara säker på att problemet kommer att åtgärdas.

Samtidigt samlar designers ofta berg av lager i full oordning med liten hänsyn till lagarnamnering, gruppering och beställning. Det är väldigt var och en för sig. Eftersom utgången (rasterbilden) inte påverkas av ingången (vektorslager), finns det ingen verklig börda för designers att organiseras. Formgivare ursäkta ofta denna brist på organisation genom att romantisera konsten att designa, måla sig själva som trollkarlar som behöver överlåtas till sina egna apparater för att uppträda.

Vi måste också inspirera en kultur för inkludering. Vi bör aktivt avskräcka malpractice som ultralätt textfärger som gör text svår att läsa för många, eller superhögkvalitativa typsnitt som gör webbsidor långsamma att ladda, eller mönsterlösa UI-element som gör saker svåra att förstå för färgblinda människor. För närvarande applåderas denna typ av felbehandling bland designgemenskapen. Om vi ​​välkomnar ett smart designverktyg måste vi invertera denna kultur.

Om ett systematiskt designverktyg ska vinna våra hjärtan, måste det först utbildas.