En snygg startsida i Figma visar sällan hur webbplatsen fungerar när innehållet blir långt, data saknas eller ett formulär ger fel. Med rätt granskningspunkter kan ni upptäcka luckorna innan de blir dyra ändringar i kod.
Startsidan ser färdig ut i Figma, men så snart utvecklaren frågar hur formuläret beter sig vid fel, hur mobilmenyn fungerar eller vad besökaren ser medan innehåll laddas uppstår luckorna. Då visar det sig ofta att ni har godkänt en stillbild snarare än en genomarbetad Figma-prototyp. Skillnaden blir kostsam när obesvarade frågor måste lösas efter att komponenter, integrationer och innehållsmodeller redan har börjat byggas. Den här artikeln hjälper SME-ägare att granska webbdesign och godkänna designförslag utifrån verkliga användarsituationer, inte bara välpolerade standardsidor.
Vad ni egentligen godkänner i en Figma-prototyp
En designfil kan innehålla färdiga färger, typsnitt, bilder och sidmallar utan att för den skull beskriva hur webbplatsen fungerar. En Figma-prototyp går längre genom att koppla samman vyer och visa vad som händer när användaren öppnar en meny, skickar ett formulär, filtrerar en lista eller stöter på ett problem. Den ska inte ersätta den färdiga webbplatsen, men den ska göra centrala beslut synliga innan utvecklingen börjar.
Föreställ er en tjänstesida med en knapp som öppnar ett bokningsflöde från ett externt system. I den snygga standardvyn ser besökaren tjänsten och knappen, men utvecklaren behöver betydligt fler besked. Ska flödet öppnas på sidan eller i ett separat fönster? Vad visas om integrationen svarar långsamt, om inga tider finns eller om ett steg misslyckas? Ska användaren kunna gå tillbaka utan att förlora sina val? Om svaren saknas flyttas designarbetet i praktiken in i utvecklingsfasen.
Det är där omtag uppstår. Ett beslut som verkar litet kan påverka komponentens uppbyggnad, datan som hämtas, hur fel hanteras och vad som behöver testas. Om ett formulär först byggs för ett enkelt lyckat resultat och senare ska kompletteras med flera feltyper, sparade värden och tydlig fokusförflyttning kan ändringen beröra både gränssnitt och bakomliggande logik. Kostnaden ligger alltså inte bara i att rita om en ruta, utan i att redan fattade tekniska beslut måste öppnas igen.
Under 2026 är den här granskningen särskilt relevant eftersom många webbplatser kombinerar innehåll från ett CMS med sökfunktioner, externa tjänster och komponenter som förändras efter besökarens val. En sida i WordPress kan exempelvis innehålla både redaktionella block och information från en integration. Ett React-baserat gränssnitt kan byta tillstånd utan att hela sidan laddas om. Ju mer dynamisk lösningen är, desto mindre säger en statisk desktopvy om den färdiga upplevelsen.
Så här hade vi angripit granskningen: börja med det användaren försöker göra och följ uppgiften från början till slut. Färgjusteringar och exakta mellanrum kan fortfarande behöva bedömas, men de bör inte skymma frågor som påverkar affären. Om en potentiell kund inte förstår att ett formulär skickas, inte hittar tillbaka i mobilmenyn eller tolkar ett tomt sökresultat som ett tekniskt fel kan det leda till avbrutna förfrågningar. Prototypens främsta värde är därför att göra sådana risker diskuterbara när de fortfarande är billiga att lösa.
Granska Figma-prototypens flöden och tillstånd – inte bara standardsidorna
Det första vi tittar på är om byrån kan visa hela förloppet för webbplatsens viktigaste funktioner. Varje flöde har ett läge före interaktion, ofta ett vänteläge och ett resultat. Resultatet kan dessutom vara lyckat, tomt, avbrutet eller misslyckat. När bara det lyckade utfallet är designat måste utvecklaren själv tolka resten, och den tolkningen kanske inte stämmer med verksamhetens behov eller tonalitet.
Ta ett kontaktformulär som konkret exempel. Den första vyn visar tomma fält och en knapp. Om användaren skriver en felaktig e-postadress behövs en vy där felet visas vid rätt fält, men det räcker inte att rita en röd text. Prototypen eller dess kommentarer bör beskriva om fältet markeras, om fokus flyttas till det första felet och om redan ifyllda uppgifter bevaras. För en företagare är affärskonsekvensen enkel: besökaren ska kunna rätta sitt misstag utan att börja om eller undra vad som hände.
När formuläret skickas behövs nästa beslut. En inaktiverad knapp med texten ”Skickar” kan fungera bra eftersom den visar att klicket har registrerats och motverkar upprepade försök. En större innehållslista behöver ofta en annan lösning, exempelvis platshållare som liknar den kommande layouten. Syftet är inte att fylla sidan med animationer, utan att förklara väntan och hålla gränssnittet stabilt medan systemet arbetar.
Efter skickandet bör prototypen skilja mellan en bekräftelse och ett tekniskt fel. Bekräftelsen behöver svara på vad som har hänt och vad användaren kan förvänta sig härnäst. Ett tekniskt fel behöver i stället erbjuda en rimlig väg vidare: prova igen, kontrollera uppgifterna, använda en annan kontaktväg eller återkomma senare. Formuleringen bör vara begriplig även om den bakomliggande orsaken är ett API-fel eller ett avbrott i nätverket; tekniska felkoder hjälper sällan den person som försöker bli kund.
Tomma lägen kräver samma noggrannhet. ”Det finns inget innehåll publicerat ännu” betyder något annat än ”din sökning gav inga träffar”, och båda skiljer sig från ”innehållet kunde inte hämtas”. I det första fallet kan sidan förklara vad som kommer att visas där. I det andra kan användaren få hjälp att ändra sökord eller rensa filter. I det tredje behöver gränssnittet markera att problemet ligger i hämtningen, så att besökaren inte tror att utbudet faktiskt är tomt.
Be därför byrån demonstrera prioriterade flöden även när något går fel. Prototypen behöver inte simulera en riktig nätverksanslutning, men den ska visa de beslutade tillstånden och hur användaren tar sig mellan dem. Det gör också överlämningen till utvecklaren tydligare: designen beskriver inte bara hur varje ruta ser ut, utan varför den visas och vad nästa möjliga handling är.
Mobilvyn måste visa verkliga beslut, inte bara en smalare startsida
Fallgropen vi ser oftast i en mobilgranskning är att startsidan har ritats i en smal ram medan de svåra funktionerna fortfarande bara finns i desktopformat. Resultatet ser responsivt ut på presentationen, men säger inget om tabeller, filter, formulär, modaler eller långa sidfötter. Det är just i dessa delar som utrymmesbristen tvingar fram prioriteringar.
En mobilvy är inte en desktopvy där kolumner automatiskt staplas på varandra. Om en sida har en introduktion, en faktaruta, ett formulär och relaterat innehåll behöver någon besluta i vilken ordning delarna ska visas. Kanske ska formuläret komma tidigare på mobilen eftersom det är sidans huvudsakliga handling. Kanske ska kompletterande fakta fällas ihop, medan kontaktuppgifter alltid ska ligga synliga. Sådana val påverkar hur snabbt kunden når sitt mål och bör därför ägas av designen och verksamheten, inte lämnas åt en standardregel i koden.
Mobilmenyn är ett tydligt test på prototypens mognad. En ensam menyikon visar bara hur navigationen öppnas. Byrån bör också visa menyn i öppet läge, hur en undermeny ser ut, vilken sida som är aktiv och hur användaren går tillbaka till föregående nivå. Om en tydlig kontaktknapp finns i desktophuvudet behöver ni dessutom se var den hamnar på mobil och om den fortfarande är lätt att hitta när menyn är stängd.
Tabeller kräver andra beslut. En enkel tabell kan ibland få horisontell rullning, medan en jämförelsetabell kan behöva prioritera vissa kolumner eller omformas till kort. Det finns ingen universallösning eftersom rätt val beror på vad läsaren ska jämföra. Prototypen bör därför visa det verkliga innehållet och förklara vad som händer med mindre prioriterad information, snarare än att bara göra texten mindre.
Formulär behöver granskas med skärmtangentbordet i åtanke. När tangentbordet öppnas minskar den synliga ytan, felmeddelanden kan göra formuläret högre och knappar kan hamna utanför vyn. Tänk er ett formulär där flera fält samtidigt innehåller fel och den nedersta knappen är fixerad mot skärmens kant. Utan en genomtänkt lösning kan knappen täcka innehåll eller ge intrycket att användaren inte kan fortsätta.
Samma sak gäller modaler, alltså dialogrutor som läggs ovanpå sidan. På en stor skärm kan de ligga centrerade med gott om luft. På en telefon behöver ni veta om de fyller nästan hela vyn, hur innehållet rullas och var stängningsknappen ligger. Prototypen bör också kommentera sådant som inte alltid syns i en bild, exempelvis om dialogen kan stängas med Escape-tangenten och vart fokus återvänder efter stängning. Det ger en mer förutsägbar upplevelse för både tangentbordsanvändare och andra besökare.
Ni behöver inte kräva en unik ritning för varje telefonmodell. Ett bättre angreppssätt är att välja representativa bredder, granska de mest komplexa uppgifterna där och komplettera med regler för vad som händer mellan vyerna. Öppna sedan den delade prototyplänken på en fysisk telefon. Där märks snabbt om tryckytor ligger för nära varandra, om viktiga texter hamnar långt ned eller om en meny känns betydligt krångligare än den gjorde på datorskärmen.
Testa prototypen med besvärligt men trovärdigt innehåll
Figma-webbdesign presenteras ofta med jämnlånga rubriker, välbeskurna bilder och korta texter som passar exakt i komponenterna. Det skapar en tilltalande helhet, men döljer hur webbplatsen fungerar när redaktörer börjar publicera verkligt material. En robust design ska inte förutsätta att varje rubrik har samma längd eller att varje bild levereras i perfekt proportion.
Föreställ er tre artikelkort bredvid varandra. Det första har rubriken ”Om oss”, det andra en lång och beskrivande projektrubrik och det tredje saknar ingress. Ska korten få olika höjd, ska rubriken kapas eller ska knapparna ändå ligga i linje? Inget av svaren är automatiskt rätt. Det avgörande är att valet görs medvetet och att redaktören förstår vilka begränsningar komponenten har.
Figma-funktioner som komponentvarianter och Auto Layout kan hjälpa designern att visa hur en komponent växer och anpassas. De löser däremot inte innehållsfrågan av sig själva. Om ingen har bestämt hur många rader en rubrik får uppta eller vad som händer när en valfri etikett saknas kan en tekniskt flexibel komponent ändå ge en ojämn och svåröverblickad sida.
Bildkomponenter behöver också utsättas för variation. En bred miljöbild kan fungera med automatisk beskärning, medan samma beskärning kan kapa ansiktet i ett porträtt eller viktig text i en illustration. Be byrån visa både liggande och stående bilder, motiv där huvudpersonen ligger nära kanten samt ett läge där bild saknas. Lösningen kan vara en neutral reservbild, en yta utan bild eller en regel för brännpunkt, men den måste passa webbplatsens innehåll och inte bara demonstrationsmaterialet.
I ett CMS som WordPress behöver designen dessutom motsvara de fält som redaktören faktiskt hanterar. Om ett artikelkort består av bild, rubrik, ingress, datum, etikett och länk bör det framgå vilka fält som är obligatoriska och vad komponenten gör när valfria fält saknas. Annars kan den färdiga administrationen tvinga redaktören att fylla i innehåll enbart för att layouten inte ska gå sönder. Det skapar onödigt arbete över tid och ökar risken för utfyllnadstexter som inte hjälper läsaren.
Dynamiskt innehåll från integrationer förtjänar samma behandling. Produktnamn, filnamn, orter eller kategorier kan bli längre än den manuellt skrivna exempeltexten. Listor kan innehålla ovanligt många poster, endast en post eller inga alls. Genom att prova mycket, lite och ofullständigt innehåll i prototypen går det att avgöra om filter, sidindelning, sortering och tomma lägen behövs innan utvecklaren har byggt komponenten.
Den här typen av belastningstest handlar inte om att hitta osannolika extrema situationer. Målet är att använda sådant innehåll som en redaktör eller integration rimligen kan skapa. Så här hade vi gjort: kopiera några typiska rubrikstrukturer från det befintliga materialet, komplettera med längre och kortare varianter och prova varje central komponent utan sina valfria fält. Då blir granskningen nära verksamhetens vardag utan att utge sig för att vara en mätning eller ett kundcase.
Gör godkännandet till en spårbar leveranskontroll
När ni ska godkänna designförslag räcker det inte att skriva ”ser bra ut” i en övergripande kommentar. Formuleringen kan senare tolkas som att både utseende, mobilbeteende och alla funktionella tillstånd är beslutade, trots att diskussionen bara gällde startsidans desktopvy. Ett användbart godkännande beskriver därför vad som har granskats och vilka frågor som fortfarande är öppna.
Figma Comments passar bra för konkret återkoppling vid en viss komponent eller skärm. Problemet uppstår när viktiga beslut ligger utspridda bland frågor, småjusteringar och lösta kommentarstrådar. Skapa därför en separat vyförteckning som kopplar varje sidtyp och central komponent till desktop, mobil och relevanta tillstånd. Då kan även en beställare utan djup Figma-kunskap se om exempelvis sökfelet, den öppna mobilmenyn eller formulärets bekräftelse saknas.
Skilj också mellan visuell design och funktionellt beteende. En modal kan se färdig ut utan att prototypen visar hur den stängs. En filterknapp kan vara välformgiven utan att någon har beslutat om valen används direkt eller först när besökaren trycker på ”Visa resultat”. Beteendet kan dokumenteras med klickbara övergångar, komponentvarianter eller kommentarer, men det måste vara tillräckligt tydligt för att utvecklare och testare ska dra samma slutsats.
Nedan visas en illustrativ granskningsmatris, inte data från ett verkligt projekt. Den gör luckorna synliga och ger ett gemensamt språk för beställare, designer, utvecklare och innehållsansvariga. Anpassa cellerna efter projektet, men behåll kopplingen mellan vy, tillstånd, ansvar och status.
| Sidtyp eller funktion | Desktop | Mobil | Laddning | Tomt läge | Fel | Varierande innehåll | Ansvarig | Status |
|---|---|---|---|---|---|---|---|---|
| Startsida | Huvudsektion och innehållsblock visade | Ordning och mobil navigation behöver justeras | Platshållare för integrerad nyhetsyta visad | Nyhetsytan döljs när innehåll saknas | Meddelande vid misslyckad hämtning saknas | Lång huvudrubrik och saknad bild testade | Designansvarig | Ändringsbegärd |
| Artikel | Artikel, metadata och relaterat innehåll visade | Delningsfunktion och bildtext granskade | Sidmall visas medan relaterat innehåll hämtas | Relaterad yta utelämnas när poster saknas | Reservläge för relaterat innehåll dokumenterat | Lång rubrik, stående bild och saknad ingress testade | Innehållsansvarig | Godkänd |
| Sök | Resultatlista och filter visade | Filter öppet, stängt och tillämpat visade | Laddningsplatshållare motsvarar resultatkorten | Noll träffar har förslag på nästa steg | Hämtningsfel skiljs från noll träffar | Långa titlar och omfattande resultatlista testade | UX-ansvarig | Öppen fråga |
| Kontaktformulär | Standard, skickar och bekräftelse visade | Skärmtangentbord och flera fältfel granskade | Knappen visar pågående skickning | Inte relevant för funktionen | Fältfel och tekniskt fel visas separat | Långa etiketter och valfria fält testade | Projektledare | Godkänd med undantag |
| Mobilmeny | Desktopnavigation dokumenterad som separat komponent | Öppen meny, undermeny, aktiv sida och väg tillbaka visade | Inte relevant för funktionen | Läge utan undermenyalternativ dokumenterat | Reservbeteende för saknade länkar återstår | Många menyval och långa sidnamn testade | Designansvarig | Ändringsbegärd |
Ett godkännande kan sedan formuleras precist, exempelvis ”godkänd med kvarstående beslut om sökfel och mobilfilter”. Det gör inte projektet tyngre; det minskar risken för att parterna minns samma genomgång på olika sätt. När en öppen fråga har en ansvarig person och ett definierat nästa steg kan utvecklingen planeras runt den i stället för att stoppas oväntat.
Versionen behöver också gå att identifiera. Länka granskningsprotokollet till rätt Figma-version och notera när granskningen genomfördes, eftersom en generell länk till en levande arbetsfil kan visa något annat senare. Godkänn gärna per sidtyp eller funktion i stället för att vänta på ett enda slutligt ja till hela webbplatsen. Då blir omfattningen hanterbar samtidigt som beroenden mellan exempelvis sök, filter och resultatkort förblir synliga.
Fyra kriterier som minskar risken för dyra omtag
Bedöm inte prototypen enbart efter hur genomarbetade standardsidorna ser ut. Använd kriterierna nedan för att kontrollera om den fångar beslut, undantag och realistiskt innehåll som annars riskerar att bli sena ändringar. Ett bra underlag behöver inte innehålla varje tänkbar detalj, men det ska täcka de flöden som påverkar affären och de osäkerheter som kan förändra utvecklingens omfattning. När ni kan förklara vad användaren ser före, under och efter en handling har prototypen börjat fungera som ett verkligt beslutsunderlag.
Kräv kompletta flöden och relevanta tillstånd
Prototypen ska visa hur användaren tar sig från start till slutförd uppgift, inklusive fel, tomma lägen, laddning, bekräftelser och avbrutna steg. Det gör att verksamhetslogik och saknade beslut kan upptäckas innan de byggs in i lösningen. Prioritera kontakt, köp, bokning, sök eller andra flöden som direkt stödjer webbplatsens mål; dekorativa övergångar är mindre värdefulla om det centrala formuläret fortfarande saknar felhantering.
Signal: Kontrollera att varje viktigt flöde går att klicka igenom även när något saknas, blir fel eller kräver ett nytt försök. Om presentationen måste avbrytas för att designern muntligt ska förklara en saknad vy bör den frågan dokumenteras innan godkännandet.
Granska mobilvyn som en egen beslutad upplevelse
Mobilvyn bör tydliggöra vad som prioriteras, flyttas, förenklas eller tas bort när utrymmet minskar. En smalare version av startsidan säger lite om hur navigering, formulär, tabeller och viktiga åtgärder faktiskt fungerar på en mindre skärm. Granska därför de uppgifter som kräver flest beslut, inte bara de sidor som är enklast att göra visuellt tilltalande.
Signal: Varna om mobilprototypen bara omfattar några standardsidor eller saknar de mest komplexa användaruppgifterna. En öppnad meny, ett formulär med flera fel och ett aktivt filterläge säger mer om lösningen än ännu en statisk innehållssida.
Belasta designen med besvärligt men trovärdigt innehåll
Testa långa rubriker, varierande bildformat, tomma resultat, omfattande listor, felmeddelanden och innehåll som saknar perfekta metadata. Realistiska ytterfall visar om layouten håller eller om lösningen bygger på att redaktörer alltid levererar idealiskt material. Granskningen bör också klargöra vilka begränsningar som är avsiktliga, exempelvis om en rubrik kapas eller om ett block döljs när ett valfritt fält saknas.
Signal: En bra leverantör visar hur prototypen hanterar både ovanligt mycket, ovanligt lite och ofullständigt innehåll. Om alla kort har lika långa texter och identiska bildformat är underlaget ännu inte tillräckligt belastat.
Gör godkännandet spårbart och verifierbart
Definiera vilka flöden, vyer, tillstånd och skärmstorlekar som ingår i godkännandet samt vilka frågor som fortfarande är öppna. Dokumenterade beslut och tydliga acceptanskriterier minskar risken att ett visuellt godkännande senare tolkas som att all funktionalitet redan var beslutad. Spårbarheten hjälper också projektledaren att skilja blockerande frågor från sådant som rimligen kan hanteras i en senare iteration.
Signal: Kontrollera att leveransen innehåller en daterad granskningslista där varje punkt är godkänd, ändringsbegärd eller uttryckligen lämnad för senare beslut. Varje öppen punkt bör ha en ansvarig person och ett nästa steg, annars är den bara en dold försening.
Börja här – godkänn prototypen innan utvecklingen startar
-
Definiera vad prototypen ska bevisa
Skriv de viktigaste användarflödena i FigJam, exempelvis att hitta en tjänst, förstå erbjudandet och skicka en förfrågan. Beskriv målet ur användarens perspektiv och koppla det sedan till verksamheten: en förfrågan ska nå rätt mottagare, en tjänst ska gå att jämföra och ett nästa steg ska vara tydligt. Be webbyrån knyta varje prioriterat flöde till ett affärsmål, så att granskningen handlar om funktion och kundnytta snarare än enbart färg och form. Om gruppen inte kan enas om vad prototypen ska bevisa blir det också svårt att avgöra när den är redo att godkännas.
-
Kräv en klickbar Figma-prototyp för prioriterade flöden
Be byrån bygga sammanhängande flöden i prototypläget i Figma med realistiska texter, knappar, formulär och felmeddelanden. Klicka från den sida där användaren sannolikt börjar och fortsätt tills uppgiften är avslutad eller ett definierat fel uppstår. Resultatet behöver inte efterlikna varje teknisk detalj i den färdiga webbplatsen, men det ska kännas tillräckligt sammanhängande för att avslöja oklara steg. Komplettera klickvägarna med kommentarer när ett beteende inte kan demonstreras trovärdigt i Figma, exempelvis exakt hur data sparas eller när en extern integration gör ett nytt försök.
-
Granska mobilvyn före desktopdetaljerna
Öppna prototypen i Figma Mobile App eller via en delad prototyplänk på din egen telefon och genomför de viktigaste uppgifterna. Testa navigationen, skriv i formulären och prova vyer med långa rubriker eller flera felmeddelanden. Börjar ni här blir prioriteringsproblemen synliga innan mycket tid läggs på små visuella desktopjusteringar. Dokumentera hinder direkt med Figma Comments och beskriv vad du försökte göra, vad du förväntade dig och var du fastnade; det ger byrån ett betydligt bättre ändringsunderlag än en allmän kommentar om att mobilen känns trång.
-
Testa prototypen med personer utanför projektet
Dela prototyplänken med några personer som liknar målgruppen men som inte har deltagit i designmötena. Ge dem konkreta uppgifter utan att förklara gränssnittet, exempelvis att hitta rätt tjänst och skicka en fråga. Observera var de tvekar, går tillbaka eller tolkar en knapp på ett annat sätt än projektgruppen hade tänkt. Samla observationerna i FigJam och sortera dem som blockerar, försvårar eller förbättring. Ett enskilt önskemål behöver inte styra om designen, men återkommande hinder i ett centralt flöde bör lösas innan prototypen godkänns.
-
Lås beslut och öppna frågor i ett godkännandeprotokoll
Skapa en sida i Notion, Confluence eller Google Docs med beslut om sidstruktur, innehåll, komponenter, mobilbeteende och viktiga interaktioner. Länka till rätt Figma-version och använd granskningsmatrisen för att markera vad som är godkänt, ändringsbegärt eller kvar för senare beslut. Godkänn först när blockerande kommentarer är stängda och återstående avvikelser har en ansvarig person, ett nästa steg och ett överenskommet beslutstillfälle. Protokollet ska inte ersätta dialogen med byrån; det ska bevara resultatet av dialogen så att designer, utvecklare och beställare bygger vidare på samma beslut.
En Figma-prototyp förebygger dyra omtag när den används som ett beslutsunderlag, inte som en snygg förhandsbild. När flöden, mobilbeteende, fel, väntelägen och varierande innehåll är prövade och dokumenterade får både ni och webbyrån en tydligare grund för utvecklingen. Ett erfaret team som FLAR AB skulle angripa uppgiften genom att först synliggöra de affärskritiska användarresorna och därefter göra öppna designbeslut spårbara innan någon börjar bygga.
