Figma-prototype eller kodet MVP?

Både prototypen og MVP’en kaldes “at teste idéen”, men de beviser vidt forskellige ting. Det er dyrt at vælge det forkerte værktøj, uanset hvilken vej fejlen går: En MVP bygget for at besvare et spørgsmål som en prototype kunne have klaret, koster ca. 270.000 DKK til ingen nytte, og en prototype hvor der var brug for en MVP, giver falsk tryghed. Her er hvad hvert værktøj faktisk kan bevise.

Hvad en Figma-prototype kan bevise

En klikbar Figma-prototype ser ud og føles som et rigtigt produkt, men er en række sammenkoblede skærmbilleder. Den koster 53.000–160.000 DKK, tager et par uger at lave og kan tegnes om mellem to interviews.

Den beviser det der kan ses og opleves: Forstår brugerne hvad tjenesten gør? Kan de finde vej gennem flowet? Reagerer de på prissiden med interesse eller tøven? I interviews giver den stærke signaler om oplevelse, forståelighed og udtalt betalingsvilje. Det den ikke kan bevise, er adfærd over tid: Ingen “bruger” en prototype for alvor, og ingen betaler rigtige penge i den.

Hvad en kodet MVP kan bevise

En MVP er et rigtigt produkt i drift, afgrænset til ét kerneflow. Den koster fra cirka 320.000 DKK og opefter og tager otte uger eller mere at bygge.

Den beviser det som prototypen ikke kan nå: reel adfærd. Kommer brugerne tilbage i næste uge uden at nogen interviewer dem? Gennemfører de flowet når ingen kigger? Betaler de med deres eget kort? Virker teknikken med rigtige data? Det er forskellen på hvad folk siger og hvad de gør, og når der skal træffes forretningsbeslutninger, er det kun det sidste der tæller.

Sammenligningen i korte træk

Beslutningsreglen: Hvor ligger din største usikkerhed?

Spørg dig selv hvilken usikkerhed der ville vælte satsningen hvis den faldt ud til den forkerte side. Er det design, forretning eller teknik?

• Design og forståelighed. “Vil brugerne forstå det her og have lyst til det?” Start med prototypen. Den besvarer spørgsmålet for en tiendedel af prisen og kan itereres indtil svaret er tydeligt.
• Forretningen. “Vil folk betale og komme igen?” Prototypen giver et første signal via interviews, men beviset kræver en MVP: Tilbagevendende brug og rigtige betalinger kan ikke simuleres.
• Teknikken. “Kan det bygges, og kan vi håndtere dataene, ydeevnen og integrationen?” Her hjælper ingen Figma i verden; det kræver kode. Et teknisk proof of concept eller en MVP er det rigtige værktøj.

For de fleste nye tjenester er rækkefølgen derfor: først en prototype for at ramme rigtigt i oplevelsen til en lav pris, derefter en MVP på det validerede flow for at teste forretningen for alvor.

Regneeksempel: to veje til samme svar

En stifter vil lancere en abonnementstjeneste. Vej A: at bygge en MVP med det samme for 530.000 DKK. Efter lanceringen viser det sig at onboardingen bliver misforstået, og det udløser en ombygning for 160.000 DKK og to måneders tabt tid. I alt 690.000 DKK. Vej B: en prototype for 110.000 DKK, ti interviews og to omtegninger hvor onboardingproblemet bliver opdaget og løst, og derefter en MVP på det validerede flow for 480.000 DKK. I alt ca. 590.000 DKK, hurtigere frem til et fungerende produkt og med betydeligt lavere risiko undervejs.

Prototypen “kostede” altså ikke 110.000 DKK. Den sparede tværtimod omtrent et lige så stort beløb og to måneder. Sådan ser kalkulen ud i de fleste tilfælde hvor usikkerheden i designet er stor.

Fælden i begge retninger

Prototyper kan blive en flugtvej: En tjeneste der bliver demonstreret i det uendelige, men aldrig møder virkeligheden, tester i sidste ende ingenting. Og MVP’er der bygges for tidligt, tester de forkerte ting til en høj pris. Værktøjerne er trin på samme trappe. Hos Weapp bruger vi normalt begge i rækkefølge som en del af vores ydelser, med en tydelig beslutning imellem. Usikker på hvor din idé står? Kontakt os, så hjælper vi dig med at finde den største usikkerhed først.