Bygga MVP:n: flödet fungerar från början till slut

Byggtekniken kommer från vibe coding-kursen (Lovable/Replit, iterationer, rollbacks). Här går vi igenom vad som skiljer en produkt från ett hobbyprojekt: ordningen du bygger i, och två lager som nybörjare alltid glömmer.

Skelett före skönhet

Mål ett: hela flödet fungerar från början till slut, hur klumpigt det än är – registrera dig → gör grejen → få resultatet. Först då putsar du individuella steg. Varför den ordningen: de läskigaste problemen är skarvarna (”steg 3 är omöjligt utan data från steg 5”), och de dyker bara upp när flödet körs hela vägen igenom. Bättre att upptäcka dem dag ett än att efter en vecka med att putsa landningssidan upptäcka att produkten inte kan slutföras alls.

Denna regel är äldre än webbutveckling. När de gjorde den första Toy Story klippte Pixar ihop en grov version av hela filmen från skisser – ”reels” – och först när de var säkra på att berättelsen höll från början till slut lade de månader på att rendera bildrutor. Hela grejen grov först, detaljerna vackra sedan. Mjukvara fungerar på samma sätt.

En sokratisk paus

Du har öppnat produkten för första gången. Vad finns på den första skärmen? Inte en fullständig uppgiftslista, inte ett fyllt flöde – tomhet. Och det är där det avgörs om du stannar eller stänger fliken. Tänk: vad behöver finnas på den tomma skärmen för att du ska veta vad du ska göra?

Lager 1: empty states

En ny användare har ingen data: tom lista, tom historik. Ett hobbyprojekt visar bara tomhet; en produkt vägleder: ”Inget här än. Ladda upp din första – här är knappen.” Vad du ska be AI:n om: ”För varje lista och skärm, bygg en empty state: vad detta är, vad det är till för, och en knapp för den första åtgärden”. Första intrycken lever precis här – på skärmen som hobbyprojekt lämnar tom.

Lager 2: mänskliga felmeddelanden

Fel fil, wifi blinkade till, betalningen misslyckades. Ett hobbyprojekt säger inget, eller skrämmer folk med ”Error 0x80070057”. En produkt förklarar och erbjuder en väg ut: ”Denna fil är över 100 MB – komprimera den eller dela upp den.” Formeln för ett bra meddelande: vad som hände + vad du ska göra. Uppmaningen: ”Varje felmeddelande i klarspråk: vad som hände och vad du ska göra. Och visa mig en lista över alla felmeddelanden” – den sista delen låter dig redigera all text på en gång, med en enhetlig ton.

Nybörjarmytar

• ”Fel är undantagsfall, jag skriver dem senare.” En av tre personer stöter på ett fel vid sitt allra första besök: fel format, musen slank, ostadigt nätverk. Det är inte undantaget, det är mitt i upplevelsen.
• ”Det är tydligt för mig, så det är tydligt för alla.” Du känner produkten inifrån – du är en blindtestare. Det måste vara tydligt för någon som ser skärmen för första gången.
• ”Jag gör det snyggt, sedan kollar jag logiken.” Tvärtom: fungerande flöde först, skönhet sedan. En vacker trasig produkt är en dyr bild.

Testet ”någon annans händer”

Du känner till detta knep från tidigare kurser – nu är det ett obligatoriskt acceptanssteg. Någon från din målgrupp går igenom flödet framför dig, i tystnad, och du varken tipsar eller förklarar – du bara observerar var de snubblar. I ”Don't Make Me Think” visade Steve Krug att 3–5 riktiga personer räcker för att hitta de flesta problem; du behöver inget dyrt labb. Tre snubblingar = tre uppgifter för imorgon. Fortsätt putsa flödet tills en ny person tar sig igenom det utan en enda fråga – det är vad MVP-redo betyder.

Där det går fel: att putsa fel sak

Det klassiska MVP-byggfelet ser ut så här: grundaren lägger en vecka på att perfekta en knappanimation och en landningssidesgradient, och testanvändaren snubblar vid ytterdörren – de vet inte var de ska klicka efter att ha registrerat sig. Ytan putsad, skelettet trasigt. Ordningregeln finns just för detta: tills en ny person kan gå igenom flödet från början till slut, är det för tidigt att putsa någon enskild skärm. Först ”fungerar från början till slut”, sedan ”vackert i varje steg”. Den omvända ordningen är det dyraste sättet att spendera en vecka.

Hur detta kopplar till andra kurser

Att iterera, rulla tillbaka till en fungerande version och arbeta med en AI-assistent är teknik från vibe coding-kursen. Och de empty states och mänskliga felmeddelanden du bygger här driver direkt konvertering till första värde – en metrik från denna kursens analyslektion. Allt hänger ihop: det du bygger nu är det du mäter senare.

Gör detta nu (5 minuter)

Öppna ditt produktutkast och hitta en ny användares första skärm. Vägleder empty staten dem till en första åtgärd, eller är den bara tom? Om den bara är tom, skriv AI-uppmaningen för empty states nu, innan du glömmer.