Rakenna toimiva sovelluksen prototyyppi tekoälyllä ja vie se ihmisten testattavaksi
Prototyyppi kannattaa rakentaa, kun se vastaa kysymykseen, johon mallikuva ei pysty: ymmärtääkö ihminen oikeasti kulun, kun hänen täytyy käyttää sitä itse? Anticode kirjoittaa kuvauksesi pohjalta toimivan sovelluksen, joka on täytetty esimerkkidatalla ja merkitty sellaiseksi, ja testaaja voi avata sen omalla puhelimellaan. Tällä sivulla käydään läpi, mitä kannattaa prototypoida, miten se kuvaillaan ja missä yhden selaimen prototyypin rajat tulevat vastaan.
Miksi toimiva prototyyppi kertoo enemmän kuin mallikuva
Staattisilla näkymillä testataan, pitävätkö ihmiset siitä, miltä jokin näyttää. Harvoin niillä testataan, osaavatko ihmiset käyttää sitä, koska testaajan pitää kuvitella, mitä jokaisen napautuksen jälkeen tapahtuu, ja testin vetäjä päätyy selostamaan tuotetta. Klikattava prototyyppi, joka oikeasti reagoi, poistaa selostamisen tarpeen. Testaaja kirjoittaa oikeaan kenttään, näkee oikean summan muuttuvan ja saa oikean tyhjän näkymän, kun poistaa viimeisen kohteen. Hänen hämmennyksensä koskee suunnitteluasi, ei prototyypin aukkoja.
Se muuttaa myös kysymyksiä, joita voit esittää. Mallikuvan kanssa kysyt ”käyttäisitkö tätä?”, ja siihen ihmiset vastaavat kohteliaasti. Toimivan version kanssa voit antaa tehtävän (”lisää ensi tiistain vuoro ja katso, mitä se tekee viikkotunneillesi”) ja seurata, missä kohtaa testaaja epäröi.
Päätä, mitä prototyypin pitää todistaa
Kirjoita ennen kuvailua ylös ne yksi tai kaksi kysymystä, joihin testin pitää vastata. Silloin versio pysyy pienenä ja testit keskittyneinä. Tyypillisiä ovat:
- Ymmärrettävyys: tietävätkö ihmiset muutamassa sekunnissa, mihin päänäkymä on tarkoitettu?
- Ydintehtävä: pystyvätkö he suorittamaan sen yhden tehtävän, jota varten tuote on olemassa, ilman apua?
- Hankala hetki: mitä tapahtuu reunatapauksessa, josta olet epävarma: tyhjä lista, peruttava virhe, pitkä nimi, joka rivittyy?
- Halukkuus: vaihtaisivatko he käytön jälkeen nykyisen taulukkonsa, muistikirjansa tai sovelluksensa tähän?
Kaiken, mikä ei palvele näitä kysymyksiä, voi jättää pois tai lavastaa. Asetussivu, jota kukaan ei avaa kahdenkymmenen minuutin testissä, on hukkaan heitettyä vaivaa, vaikka sen tuottaminen olisi kuinka helppoa.
Näin kuvailet sen Anticodelle
Kuvaile henkilö, tehtävä ja näkymät muutamalla lauseella ja kerro, miltä esimerkkidatan pitää näyttää. Esimerkiksi: ”Prototyyppi kahvilan tiimin vuoronvaihtosovelluksesta. Näkymät: tämän viikon työvuorolista, pyyntö vaihtaa vuoro ja lista avoimista vaihtopyynnöistä. Käytä kahdeksaa esimerkkityöntekijää ja realistista viikkoa. Merkitse kaikki esimerkkidataksi.” Architect vastaa lyhyellä suunnitelmalla (nimi, näkymät, ilme, ominaisuudet) ja voi kysyä enintään kolme kysymystä kohdista, joissa vastaus muuttaa lopputulosta, ja jokaiseen on ehdotettuja vastauksia, joita voit napauttaa.
Kun valitset Build it, malli kirjoittaa koko sovelluksen yhdeksi HTML-dokumentiksi, ja voit seurata, kun koodi virtaa sisään. Uudet sovellusversiot voidaan myös avata selaimessa ilman käyttöliittymää puhelimen ja kannettavan levyisinä, kuvata ja klikata läpi, ja virheet palautetaan korjattaviksi, kun tämä tarkistuspalvelu on käytettävissä.
Tee lavastetuista osista rehellisiä
Anticode-sovellukset toimivat hiekkalaatikossa ilman verkkoyhteyttä, joten kaikki, mikä normaalisti vaatisi palvelimen, simuloidaan sivun sisällä: muut käyttäjät ovat esimerkkihenkilöitä, ”lähetetyt” viestit päätyvät paikalliseen listaan ja kirjautumisnäkymä hyväksyy mitä tahansa. Sovellus merkitsee nämä esimerkkidataksi siellä, missä sillä on merkitystä. Pidä merkinnät näkyvillä testauksen ajan. Testaajat, jotka luulevat käyttävänsä oikeaa järjestelmää, tekevät erilaisia ja riskialttiimpia valintoja kuin ne, jotka tietävät käyttävänsä mallia, ja tässä vaiheessa haluat jälkimmäisten palautetta.
Pysyvää on se, minkä sovellus tallentaa testaajan omaan selaimeen. Jos joku lisää kolme kohdetta, sulkee välilehden ja palaa huomenna, kohteet ovat yhä siinä laitteessa. Se riittää viikon mittaiseen päiväkirjatutkimukseen, kunhan jokainen testaaja pysyy yhdessä puhelimessa tai kannettavassa.
Testien pitäminen ja version muuttaminen
- Julkaise prototyyppi sen anticode.dev-osoitteeseen ja lähetä linkki testaajille. Mitään ei tarvitse asentaa.
- Lähetä sidosryhmille sen sijaan asiakkaan tarkistuslinkki: he voivat avata nykyisen esikatselun ilman tiliä ja jättää kommentteja, jotka liittyvät tiettyyn osioon. Linkit vanhenevat oletuksena 14 päivän kuluttua, ja voit perua ne.
- Pyydä jokaisen kierroksen jälkeen muutoksia tavallisin sanoin (”siirrä vaihtopainike jokaiseen vuorokorttiin”). Viimeisimmät tallennukset säilyvät versiohistoriassa (tilauksesi määräämään määrään asti), joten voit näyttää ensimmäisen ja kolmannen kierroksen rinnakkain tai palata taaksepäin.
Mitä yhden selaimen prototyypillä ei voi testata
Ole itsellesi selvä rajasta. Hiekkalaatikossa toimiva prototyyppi toimii yhdellä laitteella kerrallaan, joten sillä ei voi testata:
- Mitään ihmisten välistä: oikeita ilmoituksia, jaettuja listoja tai sitä, että kaksi testaajaa näkee toistensa muutokset.
- Oikeaa kirjautumista, käyttöoikeuksia tai tilin palautusta.
- Reaaliaikaista ulkoista dataa, maksuja tai sovelluksen sisäisiä tekoälyominaisuuksia (niitä voi vain jäljitellä kiinteillä esimerkkivastauksilla).
- Suorituskykyä oikeilla datamäärillä tai hitailla yhteyksillä.
Kun idea kestää testauksen, Next.js-vienti on askel kohti oikeaa tuotetta. Se kattaa sovellusversiot ja antaa sinulle tavallisen App Router -projektin TypeScriptillä, Postgres-tietokannan Prisman kautta, sähköpostikirjautumisen, asiakas- ja henkilöstöroolit sekä ylläpitonäkymän. Se on lähtökohta, jota kehittäjä laajentaa, ei valmis monen käyttäjän sovellus, ja voit viedä sen valitsemaasi GitHub-repositorioon. Opas Next.js-vientiin kertoo, mitä siinä on. Jos tarvitset tuotantovalmiita monen käyttäjän ominaisuuksia koodaamatta, taustajärjestelmällä varustettu no-code-työkalu voi sopia paremmin kuin kumpikaan.
Usein kysyttyä
Onko tämä tekoälyllä toimiva prototyyppityökalu vai suunnittelutyökalu?
Se rakentaa toimivaa koodia, ei kehyksiä piirtoalustalle. Saat oikean sovelluksen selaimeen, mikä sopii käytettävyystestaukseen; jos tarvitset pikselintarkkoja suunnittelutiedostoja suunnittelutiimille, käytä suunnittelutyökalua tämän rinnalla.
Voivatko testaajat käyttää sitä puhelimellaan?
Voivat. Julkaistu sovellus on verkkosivu, joka toimii puhelimen selaimessa, ja kaikki, mitä se tallentaa, pysyy siinä puhelimessa.
Näenkö, mitä testaajat syöttivät?
Et sitä, mitä he tallensivat sovelluksen sisällä, koska se pysyy heidän laitteessaan. Jos lisäät palaute- tai yhteydenottolomakkeen, lomakkeen viestit tulevat sinulle sähköpostiin ja hallintapaneeliin.
Tuleeko prototyypistä oikea sovellus?
Siitä voi tulla lähtökohta. Next.js-vienti tekee siitä projektin, jossa on tietokanta ja kirjautuminen ja jonka päälle kehittäjä voi rakentaa.