Byg en fungerende app-prototype med AI, og sæt den foran rigtige mennesker

Hvorfor en fungerende prototype fortæller mere end en mockup

Statiske skærmbilleder tester, om folk kan lide, hvordan noget ser ud. De tester sjældent, om folk kan bruge det, for testpersonen må forestille sig, hvad der sker efter hvert tryk, og den, der leder testen, ender med at fortælle produktet. En klikbar prototype, der virkelig reagerer, fjerner den fortælling. Testpersonen skriver i et rigtigt felt, ser en rigtig total ændre sig og får en rigtig tom tilstand, når det sidste element slettes. Forvirringen handler om dit design, ikke om prototypens huller.

Det ændrer også, hvilke spørgsmål du kan stille. Med en mockup spørger du »ville du bruge det her?«, og det svarer folk høfligt på. Med noget, der virker, kan du give en opgave (»tilføj næste tirsdags vagt, og se, hvad det gør ved dine timer for ugen«) og se, hvor de tøver.

Beslut, hvad prototypen skal bevise

Før du beskriver noget, så skriv de ét eller to spørgsmål ned, testen skal besvare. Det holder byggeriet lille og sessionerne fokuserede. Typiske spørgsmål:

• Forståelse: ved folk inden for få sekunder, hvad hovedskærmen er til?
• Kerneopgaven: kan de løse den ene opgave, produktet findes for, uden hjælp?
• Det akavede øjeblik: hvad sker der i det hjørne, du er usikker på: en tom liste, en fejl der skal fortrydes, et langt navn der ombrydes?
• Villighed: efter at have brugt den, ville de så skifte deres nuværende regneark, notesbog eller app ud med den?

Alt, der ikke tjener de spørgsmål, kan udelades eller fakes. En indstillingsside, ingen åbner i en session på tyve minutter, er spildt arbejde, uanset hvor nem den er at generere.

Sådan beskriver du den til Anticode

Beskriv personen, opgaven og skærmene i få sætninger, og sig, hvordan eksempeldataene skal se ud. For eksempel: »En prototype af en app til vagtbytte for personalet på en café. Skærme: denne uges vagtplan, en anmodning om at bytte en vagt og en liste over åbne bytteanmodninger. Brug otte eksempelmedarbejdere og en realistisk uge. Markér alt som demodata.« Architect svarer med en kort plan (navn, skærme, udtryk, funktioner) og stiller måske op til tre spørgsmål, hvor svaret ændrer byggeriet, hvert med foreslåede svar, du kan trykke på.

Når du vælger Build it, skriver modellen hele appen som ét HTML-dokument, og du kan se koden strømme ind. Nye app-byggerier kan også åbnes i en headless browser i telefon- og laptopbredde, hvor der tages skærmbilleder og klikkes igennem, og fejl sendes tilbage til rettelse, når den kontroltjeneste er tilgængelig.

Gør de falske dele ærlige

Anticode-apps kører i en sandkasse uden netværk, så alt, der normalt ville kræve en server, simuleres inde i siden: andre brugere er eksempelpersoner, »sendte« beskeder lander i en lokal liste, og en loginskærm accepterer hvad som helst. Appen markerer det som demodata, hvor det betyder noget. Hold den markering synlig under testen. Testpersoner, der tror, de bruger et rigtigt system, træffer andre og mere risikable valg end testpersoner, der ved, det er en model, og det er den sidste slags feedback, du vil have på dette stadie.

Det, der bliver gemt, er alt, hvad appen gemmer i testpersonens egen browser. Hvis nogen tilføjer tre elementer, lukker fanen og kommer tilbage i morgen, er elementerne der stadig på den enhed. Det er nok til et dagbogsstudie over en uge, så længe hver testperson holder sig til én telefon eller laptop.

Kør sessionerne og ret byggeriet

1. Udgiv prototypen på dens anticode.dev-adresse, og send linket til testpersonerne. Intet skal installeres.
2. Til interessenter sender du i stedet et link til kundegennemgang: de kan åbne den aktuelle forhåndsvisning uden konto og skrive kommentarer knyttet til en sektion. Links udløber som standard efter 14 dage, og du kan trække dem tilbage.
3. Efter hver runde beder du om ændringer med almindelige ord (»flyt byt-knappen ind på hvert vagtkort«). De seneste versioner gemmes i versionshistorikken (op til et antal, der afhænger af dit abonnement), så du kan vise runde ét og runde tre side om side eller gå tilbage.

Det kan en prototype i én browser ikke teste

Vær klar over grænsen. En prototype i en sandkasse kører på én enhed ad gangen, så den kan ikke teste:

• Noget mellem mennesker: rigtige notifikationer, delte lister, to testpersoner der ser hinandens ændringer.
• Rigtigt login, rettigheder eller gendannelse af konto.
• Levende data udefra, betalinger eller AI-funktioner inde i appen (de kan kun efterlignes med faste eksempelsvar).
• Ydeevne med rigtige datamængder eller langsomme netværk.

Når idéen overlever testen, er Next.js-eksporten skridtet mod et rigtigt produkt. Den dækker app-byggerier og giver dig et standard App Router-projekt i TypeScript med Postgres via Prisma, login med e-mail, roller for kunder og personale og et administrationsområde. Det er et udgangspunkt, en udvikler bygger videre på, ikke en færdig app til mange brugere, og du kan skubbe det til et GitHub-repository, du vælger. Guiden til eksport til Next.js gennemgår, hvad der er med. Hvis du har brug for funktioner til mange brugere i produktion uden at skrive kode, passer et no-code-værktøj med backend måske bedre end begge dele.

Ofte stillede spørgsmål

Er det en generator til app-prototyper med AI eller et designværktøj?

Den bygger fungerende kode, ikke rammer på et lærred. Du får en rigtig app i browseren, som egner sig til brugertest; hvis du har brug for designfiler på pixelniveau til et designteam, så brug et designværktøj ved siden af.

Kan testpersonerne bruge den på deres telefoner?

Ja. Den udgivne app er en webside, der virker i en mobilbrowser, og alt, hvad den gemmer, bliver på den telefon.

Kan jeg se, hvad testpersonerne har indtastet?

Ikke det, de har gemt inde i appen, for det bliver på deres enhed. Hvis du tilføjer en feedback- eller kontaktformular, når de henvendelser frem til dig på e-mail og i dashboardet.

Bliver prototypen til den rigtige app?

Den kan blive udgangspunktet. Next.js-eksporten gør den til et projekt med database og login, som en udvikler kan bygge videre på.