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 från knappen? Hur länge ska animationen pågå, och ska den accelerera eller bromsa in i slutet?
Vissa designer levererar separata prototyper i Figma eller Principle som visar rörelserna. Men de flesta projekt hoppar direkt till kod, och då blir timing och easing upp till utvecklaren att bestämma.
- Definiera komponentens alla tillstånd — lista hover, focus, error, loading och disabled innan mockupen börjar.
- Skapa varianter för kritiska flöden — visa minst felläge och laddning för formulär och knappar som är affärskritiska.
- Dokumentera resten i text — en kort specifikation kan ersätta tiotals skärmbilder om den är tydlig nog.
- Testa i staging tidigt — låt designern se tillstånden i verklig kod innan allt är klart.
Färdiga bibliotek täcker basen men inte varumärket
Material Design och Bootstrap har färdiga definitioner för hur en knapp ska se ut i alla lägen. Men de följer Googles respektive Twitters visuella identitet, inte kundens.
Att anpassa ett färdigt bibliotek innebär att varje tillstånd måste ritas om. Då är fördelen med biblioteket nästan borta, och teamet står ändå kvar med uppgiften att dokumentera alla varianter.
Vissa projekt väljer att behålla standardutseendet för interaktiva tillstånd och bara anpassa färger och typsnitt. Det går snabbt men gör att webbplatsen ser ut som tusentals andra.
När kunden upptäcker skillnaderna efter lansering
Det är vanligt att en kund reagerar veckor efter go-live och pekar på att en undermeny ser annorlunda ut än vad som godkändes. Då måste byrån förklara att det aldrig fanns en mockup för just det tillståndet.
Ibland leder det till en extradebitering för designjustering. Ibland ändras det gratis för att bevara relationen. Men båda utfallen kostar tid och skapar friktion.
Bättre är att redan i offerten tydliggöra vilka tillstånd som ska visas i mockup och vilka som ska lösas direkt i kod. Då vet kunden vad de godkänner och vad som kommer att definieras senare.
Så hanterar byråer problemet i praktiken
Rawdesigns och andra webbbyråer som arbetar med interaktionstunga gränssnitt brukar skapa en blandning av statiska mockups och levande prototyper. De visar huvudflödet i Figma och låter resten definieras i en styleguide som byggs parallellt med siten.
Det kräver att kunden är villig att godkäння designen i två steg: först konceptet, sedan detaljerna när de syns i webbläsaren. Fungerar den modellen blir resultatet både snabbare och mer konsekvent.
För projekt med stram budget kan en enklare väg vara att använda färdiga komponentbibliotek som Chakra UI eller Tailwind UI, som redan har definierat alla tillstånd. Då försvinner en del av varumärkesuttrycket, men risken för missförstånd minskar.
Framtida verktyg kan automatisera en del
Nya designverktyg som Framer och Webflow låter designern bygga interaktiva prototyper som kan exporteras direkt till kod. Då försvinner gapet mellan mockup och färdig sajt, eftersom det designern ser också är det som användaren får.
Men de kräver att designern lär sig tänka som en utvecklare, vilket inte alla är intresserade av. Och för komplexa applikationer räcker inte verktygen till, så traditionell front end-utveckling behövs ändå.
På sikt kan AI-assistenter generera alla varianter av en komponent automatiskt utifrån ett enda exempel. Men så länge kräver det mänsklig omdöme att avgöra vilka tillstånd som är viktiga nog att visa och vilka som kan lösas ad hoc.