Tusen takk for tilbakemeldingen, Mahamed! Jeg kjenner ikke konteksten godt nok, men skal prøve på et svar likevel:

Jeg er sikker på at det finnes en primærmålgruppe for appen det er snakk om. Målgruppen opplever et problem/uforløst behov som appen er ment å adressere og løse.

I appen skal sannsynligvis målgruppen utføre noen oppgaver for å nå et bestemt mål. Det kan for eksempel være noe så enkelt som kjøp av en vare eller tjeneste.

Den "billige" prototypen jeg snakker om her vil kun gi deg svar på om målgruppen klarer å utføre disse oppgavene i løsningen/appen som foreslås. For å finne utav dette trenger du stort sett fem personer fra målgruppen som kommer inn i en brukertest-setting der de får prøve en billig prototype. Papirskisser fungerer her og kan lages på 10 minutter. Men det vil gi en mer virkelighetstro setting med prototype i Figma eller tilsvarende.

Merk at løsningen ikke kan anses som en suksess selv om det gikk bra i brukertestingen. Det er ekte bruk av et ekte produkt som kan hjelpe deg å høste data om hvordan den faktisk brukes.

Du nevner at det er viktig å gi et godt førsteinntrykk, og der er jeg helt enig. Derfor er det viktig at et ekte og brukbart produkt (sett at brukertestingen var en suksess) ikke leveres ut til hele målgruppen på en gang. Releasen kan gjøres til en begrenset gruppe som bruker appen på ordentlig og som du kan høste data fra.

Ettersom du ikke kan vite om løsningen din er en suksess (les: målgruppen bruker den og genererer salg, eller hva som er målet), så gir det mening å ikke legge for mye arbeid i å perfeksjonere produktet. Koden behøver ikke å være perfekt, brukergrensesnittet trenger ikke å være pixel perfect, skalerbarheten trenger ikke å være til stede og den kan være konsentrert om kjernefunksjonaliteten.

Men pass på at lover og regler om f.eks personvern overholdes.

Hvis responsen er god fra de første som tar det i bruk, så er det på tide å lage et robust produkt med kvalitetskode og pixel pushing ;)

Jeg nevner hypotesekortene i samme artikkel. Bruk disse for å tilnærme deg hva den endelige løsningen skal være.

Alt som ikke er validert bør du være klar for å forkaste.

Håper dette ga noen svar!

Vennlig hilsen Håkon