Död till processmaskiner!

Hitta din perfekta designprocess genom att hålla dig till några enkla principer istället för ett styvt skript.

Du hör massor av olika råd om rätt och fel sätt att utforma en app eller webbplats.

"Du bör använda Sketch."
"Design Systems eller GTFO."
"Real Designers designar 100% i kod."
"Trådramar är slöseri med tid."
"Om du inte gör prototyper gör du det inte rätt."
"Du måste börja på papper."

Du tror att det inte finns någon överenskommelse om det rätta sättet att designa, men det finns en punkt som till stor del är fri från kontroverser - att din process ska vara linjär.

Den klassiska linjära strategin ser ut så här:
forskning → skiss → wireframe → static comps → prototyp → code

Det är som de Rube Goldberg-esque tillverkningsmaskiner som de använder för att göra Doritos och Ding-Dongs. Släpp en idé i processmaskinen, och efter att den har mossats och gjutits i form när den lindar genom trapporna dyker en färdig produkt ut på andra sidan! Förutsägbar! Effektiv!

Ungefär.

Processmaskiner fungerar, men bara när de arbetar. De anpassar sig inte, och det gör dem ömtåliga. Allt som krävs är en liten Sabot för att slipa din processmaskin till ett stopp.

Hank, a.k. ”Sabot”

Jag har tittat på Finding Dory med mitt barn på sistone, och en del av "att göra" -filmerna fortsätter att hoppa ut mot mig.

I filmen finns det denna bläckfisk som heter Hank:

Disney / Pixar

Septopus, tekniskt. Hans karaktärsmodell var så besvärlig att arbeta med, de slog av ett tentakel för att göra animering av honom genomförbar. Fortfarande, med 4000 separata kontroller var han oerhört utmanande att arbeta med.

Vid denna punkt i processen har de gått förbi skisser och återgivningar och animatik - de lägre fidelity-stadierna som hjälper dig att veta ett gäng idéer snabbt och billigt. De fick redan riktigt. Karaktärriggen byggdes, tekniska detaljer utarbetade, grundläggande frågor besvarade.

De är i det sista animationssteget - 3D-modeller i 3D-miljöer. De kunde ha soldat vidare på bekostnad av produktionsschemat och budgeten. Istället gjorde de något riktigt intressant - de gick tillbaka till att skissa.

Disney / Pixar

Genom att skissa ut den komplexa rörelsen av Hanks tentakler på papper kunde de spika ner den perfekta, flytande animationen de letade efter i en bråkdel av tiden. När de var nöjda med sekvensen skulle de animeras i 3D för att matcha. De fick en bättre produkt på kortare tid eftersom de valde att värdera processprinciper istället för ett processrecept.

Läkemedlet för en receptbelagd process

Finding Dory-teamet gjorde en bättre produkt snabbare genom att fatta beslut som prioriterade hastighet och kvalitet istället för att hålla sig till en rote-process.

Du kanske väljer andra saker att värdesätta, men om du arbetar i en kommersiell miljö bör fokusering på den söta platsen mellan hastighet och kvalitet vara högst upp på din lista. Att snurra runt bra arbete är trots allt en stor uppgift för professionella designers och konstnärer.

Att definiera principerna som driver din process är bara början. Så här kan du tillämpa dem i praktiken.

Börja med de stora frågorna

Om du värdesätter hastighet kan du starta ett projekt genom att ta reda på vad de största, mest grundläggande frågorna är. I Getting Real kallas detta "epicenter design":

Börja från kärnan på sidan och bygg utåt
Epicentresdesign fokuserar på den verkliga essensen på sidan - episentret - och bygger sedan utåt. Detta innebär att du i början ignorerar extremiteterna: navigering / flikar, sidfot, färger, sidofält, logotyp, etc. Istället börjar du vid episoden och designar det viktigaste innehållet först.
Oavsett vad sidan absolut inte kan leva utan är epicentern. Om du till exempel utformar en sida som visar ett blogginlägg, är bloggposten själv episoden. Inte kategorierna i sidofältet, inte rubriken överst, inte kommentarformuläret längst ner, men själva blogginläggsenheten. Utan blogginläggsenheten är sidan inte ett blogginlägg.
Först när enheten är klar börjar du tänka på det näst mest kritiska elementet på sidan. Sedan, efter det näst mest kritiska elementet, skulle du gå vidare till det tredje och så vidare. Det är epicentresignen.
Epicenter-design undviker den traditionella modellen "låt bygga ramen och släpp innehållet i" -modellen. I den processen byggs sidformen, sedan nav ingår, sedan marknadsföring "grejer"
 läggs in, och slutligen hälls kärnfunktionaliteten, sidans verkliga syfte, in i vilket utrymme som finns kvar. Det är en bakåtprocess som tar det som borde vara högsta prioritet och sparar det för slutet.

Här är ett exempel på varför detta är avgörande. Jag arbetade på en liten sidoprojekt iOS-app som använde ett unikt, eventuellt obearbetbart ljudgränssnitt. Om jag inte värdesatte hastighet kunde jag ha ägnat otaliga timmar på att utforma de otaliga detaljerna som vilade på grunden för denna en udda idé. Design kommer trots allt i den klassiska linjära processen.

Istället började jag med kod för att ta reda på om denna idé var livskraftig eller inte. Det var det inte! Så jag justerade mina planer och sparat mig en enorm mängd tid och energi.

Fråga bara, WMGMTCATMQITLAOT?

När du först vet de frågor som behöver svar, fråga dig själv:
"Vilket medium ger mig det tydligaste svaret på mina frågor på minsta tid?"

När det gäller mitt sidoprojekt var svaret kod. För en sida på Basecamp.com är svaret ofta text eller en skiss. För dig kan det vara något helt annat.

Att veta när man ska byta växlar

Det ger dig en plats att börja, men hur vet du när det är dags att byta till ett annat medium? När du träffar motstånd.

Tänk på att köra bil. Du kryssar längs motorvägen - motorn går bort som en nöjd kattunge. Men sedan börjar du köra uppför en kulle. Det redskap du befinner dig i var utmärkt för kryssning, men inte för bergsklättring. För att behålla din hastighet växlar du till en ny växel.

Samma sak här. Men till skillnad från bilar finns det ingen bunnsäker indikator på att du har träffat för mycket motstånd i ditt val av medium. Lyckligtvis har de flesta designers och konstnärer ett fast handtag när du behöver byta till ett medium som erbjuder mer trohet. Detta är den del som överensstämmer med den klassiska linjära processen för låg trohet → hög trohet. Du vet att du är redo att gå vidare från att skissa när skisser slutar ge dig användbar insikt.

När du har nått den här punkten kan du ta reda på nästa viktigaste uppsättning frågor och ställa dig själv igen: "vilket medium ger mig det tydligaste svaret på mina frågor på minsta tid?"

Det andra fallet - som går tillbaka till en lägre trohet - är tuffare. Både för att folk är mindre öva på det, och också för att det är knepigt. Ta arbete med kod. Du arbetar med 100% trohet, så det finns ingen gräns för mediets förmåga att svara på frågor. Men det finns en gräns för dess förmåga att svara snabbt på frågor.

När du känner att du inte följer banor eftersom det känns som för mycket arbete, är det ett riktigt bra tecken på att du måste backa ut. När saker känner att de bara inte klickar som de borde, är det dags att ompröva. Var uppmärksam och du börjar utveckla en känsla för det.

Använd ett medium till din fördel

Det finns ett tredje fall för att byta till - eller hålla fast vid - ett medium. Den här bryr sig inte om motstånd, den bryr sig bara om en grundläggande sanning; process påverkar resultatet. Precis som att rita något med en penna kommer att se annorlunda ut än att rita det med en markör, att designa i webbläsaren kommer att ge ett annat resultat än att designa i Sketch.

Ju mer du förstår hur ett medium påverkar ditt arbete - vilken typ av verktyg som markerar det - desto mer kan du använda det till din fördel. Vill din design vara uttrycksfull? Förmodligen bättre att arbeta med ett visuellt verktyg som Sketch, Illustrator, eller till och med * kippa * Photoshop. Vill du ha en minimal, lätt design? Håll dig fast vid designen i kod.

Ett praktiskt exempel

Nu när jag har pratat om förskrivningsprocessens faror vill jag dela med dig ... min process. Inte för dig att följa steg för steg! Bara för att ge dig ett verkligt exempel på hur du kan använda principer för att vägleda din process.

Vi lanserar ett nytt sätt att arbeta med kunder i Basecamp, och mitt jobb var att skapa en ny sida på Basecamp.com för att marknadsföra den. Så här spelade det ut:

Fastställa stora frågor, välja ett medium

Det här är inte en ny webbplats eller en helt ny layout. Först behövde jag ta reda på syftet med denna sida, vad den försöker säga och den övergripande strukturen.

"Vilket medium ger mig det tydligaste svaret på mina frågor på minsta tid?"

Comps och skisser är ute. Detta delas in i en befintlig design och en befintlig mall. Jag kunde hoppa rakt till koden, men markeringen är buller vid denna punkt. Text är helt rätt.

Ett gäng halvbakt exemplar

Ökad trohet

Jag stickade inte med text tillräckligt länge för att avsluta all kopia för sidan. När jag hade en översikt och en känsla av hur jag ville prata om funktionen skiftade jag växlar till kod.

Varför?

Ett textdokument kunde inte berätta någonting om en rad skulle lämna en änka, om ett stycke "kändes" länge, hur bilderna skulle flöda osv. Jag behövde mer trohet. Vissa av de nya frågorna kunde ha besvarats av en statisk komp, men det skulle inte ha besvarat frågor om kopieringsanpassning såvida jag inte slösat bort tiden som matchade komponenten exakt till koden. Nej tack.

Arbetar genom kopieringsredigeringar i kod

Selektivt minskande trohet

Efter ytterligare några omgångar med kopieringsrevisioner började sidan ta form. Visuellt var det mekaniskt och överväldigande. Jag ville att det skulle vara mer uttrycksfullt, så jag övergick till Sketch för att få lite idéer.

Jag kunde ha stannat kvar i kod för det mesta, men med Sketch kunde jag avfyra ett gäng idéer mycket snabbare än jag kunde koda dem. Det låter mig också direkt jämföra dessa idéer mot varandra och skulle inte lämna ett CSS-råttbo från hela kärnan. Win-win-win.

Ett gäng halvbakade skisskomponenter

Lägg märke till hur ingen av dem är helt bakade? Det beror på att de inte spelar någon roll! Dessa är inte avsedda för en klientpresentation eller för överlåtelse av utvecklare. De är där för att hjälpa mig ta reda på något, sedan är de skräp. Att investera tid för att polera dem skulle ha varit ett totalt slöseri med ansträngningar.

Slutför

När jag en gång hade en känsla av riktningen kodade det resten av vägen. Polering av kopia, spikning av skärmdumpar och alltid utvärdering mot den sista nyckelfrågan: "Är detta redo att levereras?". Du kan ta en titt på de direkta klienterna i Basecamp-sidan här.

Det är inte så som varje projekt spelar ut. Ibland skissar jag något i Procreate, ibland börjar jag med en snabb och smutsig visuell komp, ibland skriver jag kopia i Sketch, ibland kommer jag att arbeta 100% med kod. Det beror på projektet.

Förhoppningsvis ger det dig lite inblick i hur du kan använda principer för att vägleda din process från fall till fall utan att känna att du ständigt återuppfinner hjulet.

Tänk på din process och vilken typ av arbete du gör. Definiera principerna som är viktiga för dig, fokusera först på de stora sakerna och fortsätt ifrågasätta om mediet du arbetar i är det rätta för tillfället. Ditt arbete blir bättre för det.