BykiDu ber en AI bygga en enkel bokningsapp. Första skärmen blir fin. Den andra ser ut som en annan app. Knapparna är blå på ett ställe och gröna på ett annat, och ingen har tänkt på vad som händer när användaren skriver fel i ett fält.
Det är inte konstigt. AI:n fick veta vad den skulle bygga, men inte för vem, i vilken ordning eller hur det skulle se ut. Så den gissade, skärm för skärm.
Ett sätt att slippa det är att skriva ner ramarna innan AI:n börjar. Förslaget som sprids är fem korta dokument, som AI:n läser innan den skriver en enda rad kod.
1. En brief om användaren
Det första dokumentet svarar på tre frågor: vem är appen till för, vilket problem har de, och vad behöver de få gjort?
Det låter självklart, men det är det som oftast saknas. En app för hantverkare som bokar jobb från telefonen i en bil ser helt annorlunda ut än en för en ekonomiavdelning som sitter vid stora skärmar. Skriv det kort, men skriv det.
2. Användarflödet
Nästa dokument beskriver vägen användaren tar, från att hon registrerar sig till att uppgiften är klar. Vilka steg finns, i vilken ordning, och vad händer om hon avbryter halvvägs?
Ett flöde på papper avslöjar ofta onödiga steg innan de har byggts. Det är billigare att stryka en ruta i en skiss än en skärm i en färdig app.
3. Designsystemet
Det tredje dokumentet bestämmer färger, typsnitt och avstånd. Det är det som får alla skärmar att kännas som samma app.
Har ni redan en grafisk profil, utgå från den. Har ni ingen räcker det långt att bestämma några få färger, ett eller två typsnitt och en fast skala för avstånd. Poängen är att AI:n inte ska behöva hitta på något nytt för varje skärm.
4. Komponenterna
Det fjärde dokumentet gör om designsystemet till byggstenar som återanvänds: knappar, formulär, kort och liknande. Det viktiga här är att också beskriva hur de ser ut när något går fel. Hur ser ett fält ut när det är felifyllt? Vad visar en knapp medan något laddar?
Det är i felen och väntan som många AI-byggda appar känns ofärdiga, för ingen bad om dem.
5. Skärmspecarna
Det femte dokumentet samlar allt per skärm: hur skärmen är uppbyggd, vilken som är huvudhandlingen, hur den ser ut på mobilen och vad som visas medan något laddar.
Här möts de fyra första. Briefen säger vem som använder skärmen, flödet säger var i resan den ligger, designsystemet och komponenterna säger hur den ska se ut.
Är fem rätt antal?
Tanken är att man inte ska vibe-koda utan just dessa fem. Det är ett upplägg, inte en standard. Ett litet verktyg kan klara sig med en sida som täcker alla fem, och ett stort projekt behöver mer. Poängen är viktigare än antalet: skriv ner ramarna innan AI:n börjar.
Att AI:n håller sig till dokumenten genom hela bygget är inte heller givet. Den kan glida, särskilt i långa arbetspass. Låt den därför läsa dokumenten på nytt när den börjar på något nytt, och jämför resultatet med specarna innan du godkänner det.
Vi arbetar själva på ett liknande sätt. Varje projekt får en grund med krav, teknikval, flöde, design, datamodell och plan, och varje uppgift ska kunna pekas tillbaka till den. Det är mer att skriva i början, men det gör att AI:n slutar gissa.
Checklista innan bygget
- Vem är det till för, och vad ska de få gjort?
- Vilka steg tar användaren, i vilken ordning?
- Vilka färger, typsnitt och avstånd gäller?
- Hur ser knappar och formulär ut när något går fel eller laddar?
- Vad är huvudhandlingen på varje skärm, och hur ser den ut på mobilen?
Ska ni bygga något med AI och vill ha hjälp att skriva grunden först kan du boka ett kostnadsfritt samtal på 30 minuter med oss.