Bygg en fungerande app-prototyp med AI och låt riktiga människor testa den

Varför en fungerande prototyp säger mer än en skiss

Statiska skärmar testar om folk gillar hur något ser ut. De testar sällan om folk kan använda det, eftersom testpersonen måste föreställa sig vad som händer efter varje tryck, och den som leder testet slutar med att berätta om produkten. En klickbar prototyp som verkligen svarar tar bort den berättelsen. Testpersonen skriver i ett riktigt fält, ser en riktig summa ändras och möter ett riktigt tomt läge när sista posten raderas. Förvirringen handlar då om din design, inte om luckor i prototypen.

Det ändrar också vilka frågor du kan ställa. Med en skiss frågar du ”skulle du använda det här?”, och det besvarar folk artigt. Med något som fungerar kan du ge en uppgift (”lägg till nästa tisdags pass och se vad det gör med dina timmar för veckan”) och se var de tvekar.

Bestäm vad prototypen ska bevisa

Innan du beskriver något, skriv ner den eller de två frågor testet ska besvara. Det håller bygget litet och testerna fokuserade. Vanliga frågor:

• Förståelse: vet folk vad huvudskärmen är till för inom några sekunder?
• Kärnuppgiften: klarar de det enda jobb produkten finns till för, utan hjälp?
• Det knepiga läget: vad händer vid gränsfallet du är osäker på: en tom lista, ett misstag som ska ångras, ett långt namn som radbryts?
• Viljan: efter att ha använt den, skulle de byta ut sitt nuvarande kalkylark, anteckningsblock eller sin nuvarande app?

Allt som inte tjänar de frågorna kan lämnas bort eller fejkas. En inställningssida som ingen öppnar under ett tjugo minuter långt test är bortkastad möda, hur lätt den än är att generera.

Hur du beskriver den för Anticode

Beskriv personen, uppgiften och skärmarna i några meningar, och säg hur exempeldatan ska se ut. Till exempel: ”En prototyp av en app för att byta pass i ett kaféteam. Skärmar: veckans schema, en förfrågan om att byta pass och en lista över öppna bytesförfrågningar. Använd åtta exempelanställda och en realistisk vecka. Märk allt som demodata.” Architect svarar med en kort plan (namn, skärmar, utseende, funktioner) och kan ställa upp till tre frågor där svaret ändrar bygget, var och en med föreslagna svar du kan trycka på.

När du väljer Build it skriver modellen hela appen som ett HTML-dokument, och du kan se koden strömma in. Nya appbyggen kan också öppnas i en webbläsare utan gränssnitt i mobil- och laptopbredd, fotograferas med skärmdumpar och klickas igenom, med fel som skickas tillbaka för att åtgärdas, när den granskningstjänsten är tillgänglig.

Var ärlig med det som är fejkat

Anticode-appar körs i en sandlåda utan nätverk, så allt som normalt skulle behöva en server simuleras i sidan: andra användare är exempelpersoner, ”skickade” meddelanden hamnar i en lokal lista och en inloggningsskärm accepterar vad som helst. Appen märker detta som demodata där det spelar roll. Låt märkningen synas under testerna. Testpersoner som tror att de använder ett skarpt system gör andra, mer riskfyllda val än testpersoner som vet att det är en modell, och i det här skedet vill du ha den andra sortens återkoppling.

Det som däremot sparas är allt appen lagrar i testpersonens egen webbläsare. Om någon lägger till tre poster, stänger fliken och kommer tillbaka i morgon finns posterna kvar på den enheten. Det räcker för en dagboksstudie under en vecka, så länge varje testperson håller sig till en mobil eller laptop.

Köra testerna och ändra bygget

1. Publicera prototypen på dess anticode.dev-adress och skicka länken till testpersonerna. Inget att installera.
2. Till intressenter skickar du i stället en granskningslänk för kunder: de kan öppna den aktuella förhandsvisningen utan konto och lämna kommentarer kopplade till en sektion. Länkarna slutar gälla efter 14 dagar som standard och du kan återkalla dem.
3. Efter varje omgång ber du om ändringar med vanliga ord (”flytta bytesknappen till varje passkort”). De senaste sparningarna finns i versionshistoriken (upp till ett antal som beror på ditt abonnemang), så du kan visa omgång ett och omgång tre sida vid sida eller gå tillbaka.

Vad en prototyp i en enda webbläsare inte kan testa

Var tydlig för dig själv med var gränsen går. En prototyp i sandlåda körs på en enhet i taget, så den kan inte testa:

• Något som sker mellan människor: riktiga aviseringar, delade listor, två testpersoner som ser varandras ändringar.
• Riktig inloggning, behörigheter eller kontoåterställning.
• Skarp data utifrån, betalningar eller AI-funktioner i appen (de kan bara imiteras med fasta exempelsvar).
• Prestanda med verkliga datamängder eller långsamma nätverk.

När idén klarar testerna är Next.js-exporten steget mot en riktig produkt. Den gäller appbyggen och ger dig ett vanligt App Router-projekt i TypeScript med Postgres via Prisma, inloggning med e-post, roller för kunder och personal och ett administrationsgränssnitt. Det är en utgångspunkt som en utvecklare bygger vidare på, inte en färdig app för många användare, och du kan pusha den till ett GitHub-repo du väljer. Guiden om export till Next.js visar vad som ingår. Om du behöver funktioner för många användare i produktion utan att skriva kod kan ett no-code-verktyg med egen backend passa dig bättre än båda.

Vanliga frågor

Är det här ett AI-verktyg för app-prototyper eller ett designverktyg?

Det bygger fungerande kod, inte ramar på en arbetsyta. Du får en riktig app i webbläsaren, vilket passar för användartester; om du behöver pixelexakta designfiler till ett designteam, använd ett designverktyg vid sidan av.

Kan testpersonerna använda den i mobilen?

Ja. Den publicerade appen är en webbsida som fungerar i mobilens webbläsare, och allt den sparar stannar på den mobilen.

Kan jag se vad testpersonerna har skrivit in?

Inte det de har sparat i appen, det stannar på deras enhet. Om du lägger till ett formulär för återkoppling eller kontakt når de svaren dig via e-post och i instrumentpanelen.

Blir prototypen den riktiga appen?

Den kan bli utgångspunkten. Next.js-exporten gör om den till ett projekt med databas och inloggning som en utvecklare kan bygga vidare på.