Kasu:
- Võimalus toota tehisintellektiga kiireid prototüüpide skelette, näidissisu ja mikrointeraktsiooni ideid
- Võimalus luua prototüübi jaoks realistlikku kohatäite teksti ja andmeid ning testida disaini reaalses kasutuses
- Võimalus säilitada järjepidevust ja komponentide loogikat AI väljundi teisaldamisel disainitööriistale (Figma jne)
Prototüüp on klõpsatav, navigeeritav disaini imitatsioon; See on simulatsioon, mida kasutaja saab kogeda nagu päris tootes. Kõrge täpsusega disain on seevastu disain, mis on värvide, tüpograafia, reaalse sisu ja mikrointeraktsiooni abil muutunud lõpptootele lähedasemaks. Selles etapis on eesmärk muuta idee testitavaks "nagu see oleks tõeline". AI on siin tugev kolmel viisil: luustiku ja variatsioonide kiire loomine, realistliku kohatäite sisu ja andmete pakkumine ning mikrointeraktsiooni ideede soovitamine. Kuid järjepidevuse ja komponentide loogika säilitamine väljundi teisaldamisel disainitööriistadesse – st süsteemi sobitamine süsteemi ilma seda segamata – on inimese töö.
Prototüübi eesmärk: testida soodsalt õiget küsimust
Prototüüpimisel on üks eesmärk: testida eeldust odavalt, ilma koodi kirjutamata. "Kas kasutaja saab sellest voost aru?", "Kas see paigutus kiirendab tema ülesannet?" Seetõttu ei pea prototüüp olema nii täiuslik kui päris toode; see peab lihtsalt olema piisavalt reaalne, et testitavat küsimust veenvalt kujutada.
Tehisintellekt kiirendab seda usaldusväärsust. Kuid on oht: kõrge eraldusvõime tundub "tehtud". Kui sidusrühmad näevad poleeritud prototüüpi, võivad nad seda ekslikult pidada lõplikuks otsuseks; Siiski on see endiselt hüpotees. Öelge alati selgelt, mida prototüüp testib ja mis on veel lahtine.
Ettevaatust: poleeritud prototüüp liialdab küpsusega. Kui te seda huvirühmale näidates ei raamista "see on testtööriist, mitte lõplik kujundus; me testime seda küsimust", tekib vale ootus.
Realistlik sisu: prototüübi päästmine valest
Prototüübi suurim vale on täiuslikud kohatäited, nagu "Lorem ipsum" ja "Eesnimi Perekonnanimi". Reaalses maailmas on nimed pikad, loendid on mõnikord tühjad, numbrid on mõnikord negatiivsed, kuupäevad on mõnikord aegunud. Kui prototüüp on täidetud ideaalse sisuga, peidab see tõelisi probleeme.
Siin on tehisintellekt väärtuslik: see toodab realistlikku kohatäite sisu ja erineva pikkusega, erineva olekuga andmeid. Prototüüpi saate reaalsele kasutamisele lähemale tuua selliste taotlustega nagu "Andke mulle 20 realistlikku tootenime, mõned neist väga pikad", "Kirjutage 5 erinevat tühja juhtumi stsenaariumit", "Tootke näidiskonto andmeid, sealhulgas negatiivset saldot". Seega testib test tegelikkust, mitte ideaali.
Sisu tüüp
võlts (eksitav)
Realistlik (tehisintellektiga)
Nimi
"nimi perekonnanimi"
Näited lühikeste, pikkade, üksikute nimede, erimärkidega
Nimekiri
alati täis
Tühi, 1-elemendiline, 100-elemendiline variatsioon
Number
alati positiivne
Null, negatiivne, väga suured väärtused
tekst
ideaalne pikkus
Ülevoolav pealkiri, väga lühike kirjeldus
kuupäeva
täna
Minevik, tulevik, "just praegu", "3 aastat tagasi"
Mikrointeraktsioonid: väikesed, kuid otsustavad
Mikrointeraktsioonid on väikesed, ainsad interaktsioonihetked, nagu tagasiside nupu vajutamisel, väli muutub täitmisel roheliseks, laadimisanimatsioon jne. Need tekitavad kasutajas tunde, et "süsteem kuulis mind". AI on hea ajurünnak partner mikrointeraktsiooniideede genereerimiseks (millal, milline tagasiside, milline olekumuutus). Kuid iga mikrointeraktsiooni tuleb kaaluda jõudluse, ligipääsetavuse ja tähelepanu hajutamise seisukohalt; uhke, kuid tarbetu animatsioon aeglustab kogemust.
kolm minikarpi
Juhtum 1 – tellimus langeb tegelike andmetega. Meeskond täitis prototüübi 30 realistliku (mõned väga pika) tootenimega, mille AI genereeris. Kaks kaardipaigutust ajasid üle; Probleem tabati ja parandati enne testimist. Õppetund: realistlik sisu paljastab varjatud vead varakult.
Juhtum 2 – poleeritud prototüüp tekitas valed ootused. Disainer valmistas ette kõrge eraldusvõimega prototüübi „ainult voo testimiseks”, kuid näitas seda sidusrühmadele ilma raamimata. Sidusrühm ütles "tore, avaldame"; samas kui juurdepääsetavus ja sisu ei olnud veel olemas. Õppetund: öelge selgelt, mida prototüüp testib.
Juhtum 3 – komponentide konsistents on katki. Tehisintellekti ekraanivisand sisaldas teistsugust nupustiili kui kujundussüsteemi nupp. Selle Figmasse teisaldamisel unustas disainer selle süsteemikomponendiga siduda; Tootel on kaks erinevat nuppu. Õppetund: väljundi tööriistasse teisaldamisel on selle ühendamine olemasolevate komponentidega kohustuslik.
Kopeeritavad juhised
Looge selle ekraani jaoks realistlik kohahoidja sisu:- 20 <<elemendi tüüp>> nime: mõned liiga lühikesed, mõned liiga pikad, üks erimärgiga.- 4 tühja stsenaariumi.- 3 äärmuslikku andmenäidet (null, negatiivne, liiga suur). Eesmärk: testida prototüüpi tegeliku, mitte ideaalse kasutusega. Kontekst: <<ekraan/toode>>
Pakkuge selle voo jaoks välja prototüübi skelett (ekraaniloend + põhielemendid igal ekraanil): Ülesanne: "<<ülesanne>>". Küsimus, mida tahan testida, on: "<<hüpotees>>". Soovitage selle küsimuse testimiseks piisavalt ekraane; ära lisa rohkem.
Soovitage selle suhtluse jaoks 4 mikrointeraktsiooni ideed (nupu vajutamine, välja kinnitamine, laadimine, õnnestumine). Igaühe jaoks: päästik, tagasiside, kestuse soovitus ja juurdepääsetavuse märkus (liikumistundlikkus, ekraanilugeja teadaanne). Kontekst: <<interaktsioon>>
Kontrollige selle ekraani visandi ühilduvust minu kujundussüsteemiga: kas nupp, tüpograafia, vahed ja värv vastavad minu olemasolevatele komponentide reeglitele ("<<kokkuvõte>>"). Loetlege kõik mitteühilduvad üksused ja millise süsteemikomponendiga see peaks olema ühendatud. Mustand: <<tekst>>
Nõrk viip / Tugev viip
Nõrk: "Andke selle prototüübi jaoks näidissisu."
Tulemus: ideaalne pikkus, ühtlane, võltsitud sisu, mis varjab tõelisi probleeme.
Tugev: "Looge 20 tootenime; mõned liiga pikad, üks erimärgiga; lisage 4 tühja ümbrist ja 3 servaandmete näidet; proovige prototüüpi reaalse kasutamisega testida."
Tulemus: sisu, mis tõesti muudab paigutuse paremaks, avab vead varakult.
Erinevus: tugev viip nõuab mitmekesisust + äärmuslik ümbris + eesmärk.
Levinud vead
- Ideaalse sisuga testimine. Suurepärased kohahoidjad peidavad tõelisi probleeme.
- Lihvitud prototüübi eksimine lõplikuks otsuseks. Kui raamimist ei tehta, tekivad valed ootused.
- Mittevajaliku ekraani lisamine. Prototüüp peaks olema hüpoteesi kontrollimiseks piisav; liiga palju on aja raiskamine.
- Komponentide loogika purunemine. Kui unustate süsteemikomponente sõidukisse transportimisel ühendada, tekib ebakõla.
- Väljamõeldud, kuid tarbetu mikrointeraktsioon. Animatsiooni lisamine jõudlust ja juurdepääsetavust arvestamata.
Kokkuvõttes
Prototüüpimine on viis hüpoteesi odavalt testimiseks ilma koodi kirjutamata; Kõrge eraldusvõime muudab selle usutavaks, kuid loob ka illusiooni "valmis". AI annab sellele etapile jõudu kiire luustiku, realistliku kohatäite sisu ja mikrointeraktsiooni ideedega. Selle kõige väärtuslikum panus on mitmekesised ja äärmuslikud andmed, mis võimaldavad prototüüpi testida reaalses, mitte ideaalses kontekstis. Inimese kohustus on selgelt raamida, mida prototüüp testib, säilitades komponentide ja stiilide järjepidevuse väljundi teisaldamisel disainitööriista.
Rakenduse ülesanne
- Kirjutage üks hüpoteesilause, mida soovite voo suhtes kontrollida.
- Teise viipaga looge selle hüpoteesi kontrollimiseks piisav skeleti prototüüp.
- Esimese viipaga looge realistlik, äärmuslik kohatäite sisu ja täitke prototüüp.
- Kolmanda viipaga genereerige 2–3 mikrointeraktsiooni ideed ja hinnake juurdepääsetavuse märkmeid.
- Neljanda viipaga kontrollige ja parandage kavandi süsteemi järjepidevust.
kontrollnimekiri
- [ ] Kirjutasin selgelt hüpoteesi, mida prototüüp testib.
- [ ] Testisin realistliku ja äärmusliku sisuga.
- [ ] Raamisin prototüübi sidusrühma jaoks "testimisvahendiks".
- [ ] Hoidsin hüpoteesi kontrollimiseks piisavalt ekraane.
- [ ] Kaalusin mikrointeraktsioone juurdepääsetavuse ja toimivuse suhtes.
- [ ] Säilitasin järjepidevuse, sidudes väljundi süsteemikomponentidega.