Varför mockup-versioner sällan visar alla interaktiva tillstånd
När en kund godkänner en design brukar det finnas tre till fem skärmar som visar hur sidan ska se ut. Men så fort webbplatsen går live upptäcker användarna knappar som ändrar färg, formulär som visar felmeddelanden och menyer som vecklar ut sig på sätt som aldrig syntes i skisserna.
Gapet mellan det som godkändes och det som byggs beror sällan på slarvigt arbete. Det handlar oftare om att varje interaktivt element kan befinna sig i ett dussintal tillstånd, och att visa dem alla i en statisk mockup blir snabbt ohanterligt.
En knapp har minst sex tillstånd
En enda primärknapp kan se annorlunda ut beroende på om den är inaktiv, hover, aktiv, fokuserad via tangentbord, laddande eller disabled. Designern måste välja vilket tillstånd som ska visas i mockupen.
Oftast väljs det inaktiva läget, eftersom det är enklast att fotografera. Men då försvinner information om hur knappen ska bete sig när användaren håller muspekaren över den eller försöker klicka innan ett formulär är ifyllt.
Resultatet blir att utvecklaren måste gissa färg och effekt för de andra fem tillstånden, eller att en snabb rundmail skickas mitt i bygget för att stämma av detaljer som borde ha beslutats från början.
Formulär multiplicerar antalet varianter
Ett kontaktformulär med fyra fält kan generera minst tjugo olika skärmvarianter om varje fält ska visas i tomt läge, ifyllt korrekt, ifyllt felaktigt, fokuserat och disabled.
Ovanpå det tillkommer tillstånd för hela formuläret: inget ifyllt, delvis ifyllt, alla fält korrekta, minst ett fel, inskickat och väntar på svar, bekräftelse mottagen. Ingen mockup-presentation hinner visa allt.
Istället förlitar sig designteamet på att utvecklaren känner till konventioner för hur fel markeras. Men om projektet har en ovanlig färgpalett eller vill undvika röd text av tillgänglighetsskäl måste det dokumenteras separat.
Navigation som ser annorlunda ut beroende på var du är
En meny som fungerar bra på startsidan kan bli för bred när användaren befinner sig tre nivåer ned i en undersektion. Breadcrumbs, aktiv länk och mobilmeny kräver alla egna varianter.
Om mockupen bara visar navigationen från startsidan riskerar teamet att missa hur den ska se ut när en undermeny är utfälld, när sökrutan är aktiv eller när användaren scrollat förbi hero-sektionen och menyn ska fästas högst upp.
Vissa byråer skapar separata artboards för varje variant. Men det leder till att Figma-filen växer till hundratals sidor, och kunden tappar överblicken över vad som faktiskt ska godkännas.
Designsystem löser en del men inte allt
Ett internt designsystem kan dokumentera hur en komponent ska bete sig i alla lägen. Men det kräver att varje tillstånd först har definierats, testats och godkänts av både designer och utvecklare.
Mindre projekt har sällan tid att bygga den infrastrukturen. Istället skapas en mockup som visar huvudflödet, och resten fylls i under bygget.
Det fungerar så länge teamet sitter nära varandra och kan lösa oklarheter direkt. Men när kund, designer och utvecklare befinner sig i olika tidszoner blir varje obesvarad fråga en flaskhals.
Responsivitet fördubblar arbetet
Varje tillstånd måste också fungera på mobil, surfplatta och desktop. En knapp som ser bra ut i desktop-läge kan bli för liten för tummen på mobil, eller för bred i en tvåkolumnslayout på surfplatta.
Att visa alla tillstånd i alla skärmstorlekar skulle kräva tre gånger så många mockups. De flesta projekt nöjer sig med att visa desktop-varianten fullt ut och mobilversionen för huvudflödet.
Utvecklaren får sedan anpassa alla mellanliggande tillstånd efter bästa förmåga, vilket ofta innebär att färgkontrast, avstånd och typsnitt justeras utan att designern ser resultatet förrän i staging-miljön.
Animationer och övergångar saknas nästan alltid
En mockup är per definition statisk. Den kan visa före och efter, men inte hur övergången mellan tillstånden ska se ut.
Ska en meny glida in från sidan, fada in ovanifrån eller växa ut …