Lag en fungerende app-prototype med KI og vis den til ekte brukere

Hvorfor en fungerende prototype sier mer enn en skisse

Statiske skjermbilder tester om folk liker hvordan noe ser ut. De tester sjelden om folk klarer å bruke det, fordi testpersonen må forestille seg hva som skjer etter hvert trykk, og den som leder testen ender opp med å fortelle om produktet. En klikkbar app-prototype som faktisk reagerer, fjerner den fortellingen. Testpersonen skriver i et ekte felt, ser en ekte sum endre seg og får en ekte tom-tilstand når hun sletter det siste elementet. Forvirringen handler da om designet ditt, ikke om hullene i prototypen.

Det endrer også hvilke spørsmål du kan stille. Med en skisse spør du «ville du brukt dette?», og det svarer folk høflig på. Med noe som fungerer kan du gi en oppgave («legg inn vakten neste tirsdag og se hva det gjør med timene dine denne uken») og se hvor de nøler.

Bestem hva prototypen skal bevise

Før du beskriver noe, skriv ned det ene eller de to spørsmålene testen skal svare på. Da holdes prototypen liten og testene fokuserte. Typiske spørsmål:

• Forståelse: skjønner folk hva hovedskjermen er til for i løpet av noen sekunder?
• Kjerneoppgaven: klarer de den ene jobben produktet finnes for, uten hjelp?
• Det vanskelige øyeblikket: hva skjer i ytterkanten du er usikker på: en tom liste, en feil som må angres, et langt navn som brytes over linjen?
• Vilje: etter å ha brukt den, ville de byttet ut regnearket, notatboken eller appen de bruker i dag?

Alt som ikke tjener disse spørsmålene, kan utelates eller etterlignes. En innstillingsside ingen åpner i løpet av en test på tjue minutter, er bortkastet arbeid, uansett hvor lett den er å generere.

Slik beskriver du den for Anticode

Beskriv personen, oppgaven og skjermene i noen få setninger, og si hvordan eksempeldataene skal se ut. For eksempel: «En prototype av en app for vaktbytte for et kafé-team. Skjermer: denne ukens vaktliste, en forespørsel om å bytte vakt og en liste over åpne byttforespørsler. Bruk åtte eksempelansatte og en realistisk uke. Merk alt som demodata.» Architect svarer med en kort plan (navn, skjermer, uttrykk, funksjoner) og kan stille opptil tre spørsmål der svaret endrer resultatet, hvert med foreslåtte svar du kan trykke på.

Når du velger Build it, skriver modellen hele appen som ett HTML-dokument, og du kan se koden strømme inn. Nye app-versjoner kan også åpnes i en hodeløs nettleser i mobil- og laptopbredde, fotograferes og klikkes gjennom, og feil sendes tilbake for retting, når den gjennomgangstjenesten er tilgjengelig.

Vær ærlig om det som er falskt

Anticode-apper kjører i en sandkasse uten nettverk, så alt som normalt ville trengt en server, simuleres inne på siden: andre brukere er eksempelpersoner, «sendte» meldinger havner i en lokal liste, og en innloggingsskjerm godtar hva som helst. Appen merker dette som demodata der det betyr noe. La merkingen være synlig under testingen. Testpersoner som tror de bruker et ekte system, tar andre og mer risikable valg enn testpersoner som vet at det er en modell, og det er den siste typen tilbakemelding du vil ha på dette stadiet.

Det som blir lagret, er alt appen lagrer i testpersonens egen nettleser. Hvis noen legger inn tre elementer, lukker fanen og kommer tilbake i morgen, ligger elementene der fortsatt på den enheten. Det holder for en dagbokstudie over en uke, så lenge hver testperson holder seg til én mobil eller laptop.

Gjennomfør testene og endre prototypen

1. Publiser prototypen på anticode.dev-adressen dens og send lenken til testpersonene. Ingenting å installere.
2. Til interessenter sender du heller en lenke for kundegjennomgang: de kan åpne den gjeldende forhåndsvisningen uten konto og legge igjen kommentarer knyttet til en seksjon. Lenkene utløper som standard etter 14 dager, og du kan trekke dem tilbake.
3. Etter hver runde ber du om endringer med vanlige ord («flytt bytteknappen inn på hvert vaktkort»). De siste lagringene tas vare på i versjonshistorikken (opptil et antall som avhenger av abonnementet ditt), så du kan vise runde én og runde tre ved siden av hverandre, eller gå tilbake.

Det en prototype i én nettleser ikke kan teste

Vær tydelig overfor deg selv om grensen. En prototype i sandkasse kjører på én enhet om gangen, så den kan ikke teste:

• Noe som foregår mellom mennesker: ekte varsler, delte lister, to testpersoner som ser hverandres endringer.
• Ekte innlogging, tilganger eller gjenoppretting av konto.
• Levende eksterne data, betalinger eller KI-funksjoner inne i appen (de kan bare etterlignes med faste eksempelsvar).
• Ytelse med reelle datamengder eller trege nettverk.

Når ideen overlever testingen, er Next.js-eksporten steget mot et ekte produkt. Den gjelder app-versjoner og gir deg et standard App Router-prosjekt i TypeScript med Postgres via Prisma, innlogging med e-post, roller for kunder og ansatte og et administrasjonsområde. Det er et utgangspunkt en utvikler bygger videre på, ikke en ferdig app for mange brukere, og du kan sende det til et GitHub-repository du velger. Guiden om eksport til Next.js viser hva som er med. Trenger du funksjoner for mange brukere i produksjon uten å skrive kode, kan et no-code-verktøy med backend passe bedre enn begge deler.

Vanlige spørsmål

Lager dette app-prototyper med KI, eller er det et designverktøy?

Det lager fungerende kode, ikke rammer på et lerret. Du får en ekte app i nettleseren, som passer til brukertesting; trenger du designfiler på pikselnivå til et designteam, bruker du et designverktøy ved siden av.

Kan testpersonene bruke den på mobilen?

Ja. Den publiserte appen er en nettside som fungerer i mobilnettleseren, og alt den lagrer, blir liggende på den mobilen.

Kan jeg se hva testpersonene skrev inn?

Ikke det de lagret inne i appen, som blir liggende på enheten deres. Hvis du legger til et skjema for tilbakemelding eller kontakt, når de innsendingene deg på e-post og i dashbordet.

Blir prototypen til den ekte appen?

Den kan bli utgangspunktet. Next.js-eksporten gjør den om til et prosjekt med database og innlogging som en utvikler kan bygge videre på.