Anticode Szerkesztő megnyitása

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.

Frissítve · Az Anticode csapata

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

  1. 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.
  2. 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.
  3. 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.