Byg MVP'en: flowet virker fra start til slut

Byggeteknikken kommer fra vibe coding-kurset (Lovable/Replit, iterations, rollbacks). Her dækker vi, hvad der adskiller et produkt fra et hobbyprojekt: den rækkefølge, du bygger i, og to lag, som begyndere altid glemmer.

Skelet før skønhed

Mål ét: hele flowet kører fra start til slut, uanset hvor klodset – tilmeld dig → gør tingen → få resultatet. Først derefter polerer du individuelle trin. Hvorfor den rækkefølge: de mest skræmmende problemer er overgangene («trin 3 er umuligt uden data fra trin 5»), og de viser sig kun, når flowet kører hele vejen igennem. Bedre at fange dem på dag ét end at opdage, efter en uge med polering af landingssiden, at produktet slet ikke kan færdiggøres.

Denne regel er ældre end webudvikling. Da Pixar lavede den første Toy Story, klippede de en grov version af hele filmen ud af skitser – de såkaldte «reels» – og først da de var sikre på, at historien holdt fra start til slut, brugte de måneder på at rendere frames. Hele tingen groft først, detaljer smukke bagefter. Software fungerer på samme måde.

En sokratisk pause

Du har åbnet produktet for første gang. Hvad er der på den første skærm? Ikke en fuld opgaveliste, ikke et udfyldt feed – tomhed. Og det er der, det afgøres, om du bliver eller lukker fanen. Tænk: hvad skal der være på den tomme skærm, for at du ved, hvad du skal gøre?

Lag 1: tomme tilstande

En ny bruger har nul data: tom liste, tom historik. Et hobbyprojekt viser bar tomhed; et produkt guider dig: «Intet her endnu. Upload din første – her er knappen.» Hvad du skal bede AI'en om: «For hver liste og skærm, byg en tom tilstand: hvad dette er, hvad det er til, og en knap til den første handling». Førstehåndsindtryk lever præcis her – på den skærm, hobbyprojekter lader stå tom.

Lag 2: brugervenlige fejlmeddelelser

Forkert fil, wi-fi'et blinkede, betalingen mislykkedes. Et hobbyprojekt siger intet, eller skræmmer folk med «Error 0x80070057». Et produkt forklarer og tilbyder en vej ud: «Denne fil er over 100 MB – komprimer den eller del den op.» Formlen for en god besked: hvad der skete + hvad du skal gøre. Anmodningen: «Hver fejl i almindeligt sprog: hvad der skete, og hvad du skal gøre. Og vis mig en liste over alle fejlmeddelelserne» – den sidste del lader dig redigere hver tekst på én gang, med én stemme.

Myter for begyndere

• «Fejl er undtagelser, jeg skriver dem senere.» Én ud af tre personer støder på en fejl ved deres allerførste besøg: forkert format, musen gled, ustabilt netværk. Det er ikke undtagelsen, det er midten af oplevelsen.
• «Det er klart for mig, så det er klart for alle.» Du kender produktet indefra – du er en blind tester. Det skal være klart for en, der ser skærmen for første gang.
• «Jeg gør det pænt, og så tjekker jeg logikken.» Den anden vej rundt: fungerende flow først, skønhed bagefter. Et smukt, men ødelagt produkt er et dyrt billede.

«Andres hænder»-testen

Du kender dette trick fra tidligere kurser – nu er det et påkrævet accepttrin. En fra din målgruppe gennemgår flowet foran dig, i stilhed, og du antyder ikke og forklarer ikke – du ser bare, hvor de snubler. I «Don't Make Me Think» viste Steve Krug, at 3–5 rigtige mennesker er nok til at finde de fleste problemer; du behøver ikke et dyrt laboratorium. Tre snubler = tre opgaver til i morgen. Bliv ved med at polere flowet, indtil en ny person kommer igennem det uden et eneste spørgsmål – det er, hvad MVP-klar betyder.

Hvor det går galt: du polerer det forkerte

Den klassiske MVP-byggefejl ser sådan ud: grundlæggeren bruger en uge på at perfektionere en knapanimation og en gradient på landingssiden, og testbrugeren snubler ved hoveddøren – de ved ikke, hvor de skal klikke efter tilmelding. Skind poleret, skelet brudt. Rækkefølgereglen eksisterer præcis for dette: indtil en ny person kan gennemgå flowet fra start til slut, er polering af en enkelt skærm for tidligt. Først «virker fra start til slut», derefter «smukt ved hvert trin». Den omvendte rækkefølge er den dyreste måde at bruge en uge på.

Hvordan dette hænger sammen med andre kurser

Iteration, tilbagerulning til en fungerende version og arbejde med en AI-assistent er teknik fra vibe coding-kurset. Og de tomme tilstande og brugervenlige fejlmeddelelser, du bygger her, driver direkte konvertering til første værdi – en metrik fra dette kursus' analyselektion. Det hele hænger sammen: hvad du bygger nu, er hvad du måler senere.

Gør dette nu (5 minutter)

Åbn din produktskabelon og find en ny brugers første skærm. Leder den tomme tilstand dem til en første handling, eller er den bare tom? Hvis den bare er tom, så skriv AI-anmodningen for tomme tilstande lige nu, før du glemmer det.