Készíts működő alkalmazás prototípust MI-vel, és tedd emberek elé
Egy prototípust akkor érdemes megépíteni, ha olyan kérdésre ad választ, amelyre egy makett nem: megérti-e valaki a folyamatot, amikor tényleg használnia kell? Az Anticode a leírásodból működő alkalmazást ír, demóként jelölt mintaadatokkal feltöltve, amelyet a tesztelő a saját telefonján megnyithat. Ez az oldal arról szól, mit érdemes prototipizálni, hogyan írd le, és hol ér véget egy egyetlen böngészőben futó prototípus.
Miért mond többet egy működő prototípus, mint egy makett
A statikus képernyők azt tesztelik, tetszik-e az embereknek, ahogy valami kinéz. Azt ritkán, hogy tudják-e használni, mert a tesztelőnek el kell képzelnie, mi történik minden koppintás után, és a tesztet vezető ember végül elmeséli a terméket. Egy kattintható alkalmazás prototípus, amely tényleg reagál, ezt a mesélést megszünteti. A tesztelő valódi mezőbe gépel, valódi végösszeget lát változni, valódi üres állapotot kap, amikor törli az utolsó elemet. A zavara a dizájnodra vonatkozik, nem a prototípus hiányosságaira.
Azt is megváltoztatja, milyen kérdéseket tehetsz fel. Egy makettnél azt kérdezed: „használnád ezt?”, amire az emberek udvariasan válaszolnak. Valaminél, ami működik, feladatot adhatsz („vedd fel a jövő keddi műszakot, és nézd meg, hogyan változik a heti óraszámod”), és figyelheted, hol akadnak el.
Döntsd el, mit kell bizonyítania a prototípusnak
Mielőtt bármit leírnál, írd le azt az egy-két kérdést, amelyre a tesztnek válaszolnia kell. Így a build kicsi marad, a tesztalkalmak pedig fókuszáltak. Tipikus kérdések:
- Megértés: tudják-e az emberek néhány másodpercen belül, mire való a fő képernyő?
- A fő feladat: el tudják-e végezni segítség nélkül azt az egy dolgot, amiért a termék létezik?
- A kényes pillanat: mi történik annál a határesetnél, amelyben bizonytalan vagy: egy üres lista, egy visszavonandó hiba, egy több sorba törő hosszú név?
- Hajlandóság: használat után lecserélnék-e rá a mostani táblázatukat, jegyzetfüzetüket vagy alkalmazásukat?
Ami nem szolgálja ezeket a kérdéseket, kihagyható vagy imitálható. Egy beállítások oldal, amelyet egy húszperces teszt alatt senki sem nyit meg, elvesztegetett munka, akármilyen könnyű is legenerálni.
Hogyan írd le az Anticode-nak
Írd le néhány mondatban a felhasználót, a feladatot és a képernyőket, és azt, hogyan nézzenek ki a mintaadatok. Például: „Egy kávézói csapat műszakcserélő alkalmazásának prototípusa. Képernyők: a heti beosztás, egy műszakcsere-kérés és a nyitott cserekérések listája. Használj nyolc minta-munkatársat és egy valószerű hetet. Mindent jelölj demóadatként.” Az Architect egy rövid tervvel válaszol (név, képernyők, megjelenés, funkciók), és legfeljebb három kérdést tehet fel ott, ahol a válasz megváltoztatja a buildet, mindegyikhez javasolt válaszokkal, amelyekre rákoppinthatsz.
Amikor a Build it gombot választod, a modell az egész alkalmazást egyetlen HTML-dokumentumként írja meg, és nézheted, ahogy a kód beérkezik. Az új alkalmazásbuildek egy fej nélküli böngészőben is megnyithatók telefonos és laptopos szélességben, ahol képernyőképek készülnek róluk, végigkattintják őket, és a hibák visszakerülnek javításra, amikor ez az ellenőrző szolgáltatás elérhető.
Legyenek őszinték az imitált részek
Az Anticode-alkalmazások hálózat nélküli homokozóban futnak, így mindaz, amihez általában szerver kellene, az oldalon belül szimulált: a többi felhasználó mintaszemély, az „elküldött” üzenetek egy helyi listába kerülnek, a bejelentkezési képernyő pedig bármit elfogad. Az alkalmazás ott, ahol számít, demóadatként jelöli ezeket. Ez a jelölés a tesztelés alatt is maradjon látható. Azok a tesztelők, akik azt hiszik, élő rendszert használnak, másként és kockázatosabban döntenek, mint azok, akik tudják, hogy modellről van szó, és ebben a szakaszban a második fajta visszajelzésre van szükséged.
Ami megmarad, az mindaz, amit az alkalmazás a tesztelő saját böngészőjébe ment. Ha valaki felvesz három elemet, bezárja a lapot, és másnap visszatér, az elemek azon az eszközön még ott vannak. Ez elég egy hetes naplós vizsgálathoz, amíg minden tesztelő egyetlen telefonnál vagy laptopnál marad.
A tesztek lebonyolítása és a build módosítása
- Tedd közzé a prototípust az anticode.dev címén, és küldd el a linket a tesztelőknek. Nincs mit telepíteni.
- Az érintetteknek küldj inkább ügyfél-véleményezési linket: fiók nélkül megnyithatják az aktuális előnézetet, és egy-egy szakaszhoz kötött megjegyzéseket hagyhatnak. A linkek alapértelmezésként 14 nap után lejárnak, és visszavonhatod őket.
- Minden kör után kérd a változtatásokat egyszerű szavakkal („tedd a csere gombot minden műszakkártyára”). A legutóbbi mentések a verzióelőzményekben megmaradnak (a csomagodtól függő számban), így egymás mellett mutathatod az első és a harmadik kört, vagy visszaléphetsz.
Amit egy egyetlen böngészőben futó prototípus nem tud tesztelni
Légy tisztában a határral. Egy homokozóban futó prototípus egyszerre egy eszközön fut, így nem tudja tesztelni:
- Semmit, ami emberek között zajlik: valódi értesítéseket, megosztott listákat, két tesztelőt, akik látják egymás változtatásait.
- Valódi bejelentkezést, jogosultságokat vagy fiók-helyreállítást.
- Élő külső adatokat, fizetést vagy MI-funkciókat az alkalmazáson belül (ezeket csak rögzített mintaválaszokkal lehet imitálni).
- A teljesítményt valódi adatmennyiséggel vagy lassú hálózaton.
Ha az ötlet túléli a tesztelést, a Next.js-export a lépés egy valódi termék felé. Az alkalmazásbuildekre vonatkozik, és egy szabványos, TypeScriptben írt App Router-projektet ad Postgresszel a Prismán keresztül, e-mailes bejelentkezéssel, ügyfél- és munkatársi szerepkörökkel és adminfelülettel. Ez egy kiindulópont, amelyet egy fejlesztő továbbépít, nem kész többfelhasználós alkalmazás, és egy általad választott GitHub-tárolóba küldheted. A Next.js-be exportálásról szóló útmutató leírja, mi van benne. Ha kódírás nélkül van szükséged éles, többfelhasználós funkciókra, egy háttérrendszerre épülő no-code eszköz jobban illhet hozzád mindkettőnél.
Gyakori kérdések
MI-alapú prototípusgenerátor ez, vagy dizájneszköz?
Működő kódot épít, nem kereteket egy vásznon. Valódi alkalmazást kapsz a böngészőben, ami a használhatósági teszteléshez illik; ha egy dizájncsapatnak pixelpontos tervfájlokra van szüksége, használj mellette dizájneszközt.
Használhatják a tesztelők a telefonjukon?
Igen. A közzétett alkalmazás egy weboldal, amely telefonos böngészőben is működik, és amit ment, az azon a telefonon marad.
Látom, mit vittek be a tesztelők?
Azt nem, amit az alkalmazáson belül mentettek, mert az az eszközükön marad. Ha hozzáadsz egy visszajelzési vagy kapcsolatfelvételi űrlapot, azok a beküldések e-mailben és az irányítópulton eljutnak hozzád.
A prototípusból lesz a valódi alkalmazás?
Kiindulópont lehet belőle. A Next.js-export adatbázissal és bejelentkezéssel rendelkező projektté alakítja, amelyre egy fejlesztő építhet.