Kā rakstīt uzvednes MI lietotņu veidotājiem (ar pirms un pēc piemēriem)
Laba uzvedne MI lietotņu veidotājam apraksta produktu, nevis kodu: kas to lieto, ko viņi dara soli pa solim, kādus datus tas glabā un kam ir atļauts ko redzēt. Kad pirmā versija ir gatava, katrā ziņojumā lūdziet vienu konkrētu izmaiņu, pasakiet, kas jāpaliek nemainīgs, un problēmas aprakstiet kā „es izdarīju X, sagaidīju Y, dabūju Z”. Šie trīs ieradumi novērš lielāko daļu vilšanos radošu rezultātu.
Pārējā šī rokasgrāmata detalizēti parāda modeļus ar pirms un pēc piemēriem, ko varat pielāgot.
Kāpēc uzvednes rakstīšana lietotņu veidotājam atšķiras no sarunas ar MI
Ja jautājat tērzēšanas asistentam, neskaidra uzvedne dod neskaidru atbildi, un jūs ejat tālāk. Kad uzvedināt MI lietotņu veidotāju, atbilde ir darbojoša programma. Katrs apraksta robs tiek aizpildīts ar minējumu, un šie minējumi kļūst par kodu, datubāzes tabulām un ekrāniem, ar kuriem tad jums jāsadzīvo vai tie jāatceļ.
Tāpēc uzvednes mērķis nav izklausīties gudram. Tas ir atstāt mazāk svarīgu lēmumu nejaušībai. Tam nav vajadzīga tehniska terminoloģija. Vajag būt konkrētiem par lietām, ko zināt tikai jūs: par lietotājiem, darba plūsmu un noteikumiem.
Ko iekļaut pirmajā uzvednē
Pirms ko rakstāt, atbildiet uz šiem jautājumiem. Katrs no tiem aizver robu, par ko MI citādi minētu.
| Iekļaujiet | Kāpēc tas svarīgi | Piemērs |
|---|---|---|
| Produktu vienā teikumā | Nosaka rāmi visiem vēlākajiem lēmumiem | „Rezervāciju vietne divkrēslu frizētavai” |
| Kas to lieto | Nosaka ekrānus un toni | „Klienti bez pieraksta telefonos un īpašnieks klēpjdatorā” |
| Galveno plūsmu soli pa solim | Tas, kam pirmām kārtām jādarbojas | „Izvēlies pakalpojumu, izvēlies laiku, ievadi vārdu un tālruni, saņem apstiprinājumu” |
| Datus, ko tas glabā | Kļūst par datubāzes dizainu | „Pakalpojumi, rezervācijas, klienti” |
| Kas var ko redzēt vai mainīt | Nosaka pieteikšanos un atļaujas | „Tikai īpašnieks redz visas rezervācijas” |
| Izskatu un noskaņu, īsi | Izvairās no vispārīga noklusējuma stila | „Tumšs, vienkāršs, lielas pogas” |
| Ko pagaidām atstāt ārpusē | Tur pirmo versiju mazu | „Vēl bez maksājumiem un atsauksmēm” |
Pēdējā rinda ir novērtēta par zemu. Pateikt, ko negribat, neļauj MI pievienot emuāru, cenu lapu un jaunumu abonēšanu, par ko neesat lūdzis.
Pirms un pēc: pirmā uzvedne
Pirms:
Izveido man lietotni manai sporta zālei.
Veidotājam jāuzmin viss: vai lietotāji ir dalībnieki vai darbinieki? Nodarbības vai individuālie treniņi? Maksājumi? Iegūsiet kaut ko, kas izskatās pēc sporta zāles vietnes, bet nedara to, kas jums vajadzīgs.
Pēc:
Izveido nodarbību rezervēšanas lietotni nelielai jogas studijai. Dalībnieki redz šīs nedēļas nodarbības (nosaukums, pasniedzējs, laiks, brīvās vietas) un rezervē vietu, un var atcelt līdz pusotru stundu pirms sākuma. Dalībnieki reģistrējas ar e-pastu un paroli. Studijas īpašnieks pieslēdzas, lai pievienotu nodarbības, redzētu, kas ir pierakstījies, un atzīmētu apmeklējumu. Glabā nodarbības, dalībniekus un rezervācijas datubāzē. Mierīgs, viegls dizains, kas labi darbojas telefonos. Maksājumu vēl nav.
Otrā versija joprojām ir īsa. Tā vienkārši atbild uz jautājumiem no iepriekšējās tabulas.
Aprakstiet uzvedību, nevis realizāciju
Bieži labākus rezultātus dod tas, ka aprakstāt, kas notikt, nevis kā to veidot.
Pirms:
Pievieno useEffect, kas ielādē rezervācijas, un modālo komponentu rediģēšanai.
Pēc:
Kad īpašnieks noklikšķina uz rezervācijas, atver paneli, kurā var mainīt laiku vai to atcelt. Izmaiņām jāparādās sarakstā uzreiz.
Pirmā uzvedne piespiež MI izmantot konkrētu paņēmienu, kas var neatbilst tam, kā lietotne ir uzbūvēta. Otrā pasaka rezultātu un ļauj izvēlēties pareizo pieeju kodam, kas jau ir uzrakstīts. Ja esat izstrādātājs un tiešām jums ir spēcīga preference, pasakiet to, bet kopā ar rezultātu.
Esiet konkrēti par noteikumiem
Biznesa noteikumi ir vieta, kur MI veidotās lietotnes visbiežāk kļūdās, jo jums tie ir acīmredzami, bet MI — neredzami. Uzrakstiet tos skaidri.
- Ierobežojumi: „Dalībnieks var turēt ne vairāk kā trīs nākotnes rezervācijas.”
- Laiks: „Atcelšana beidzas divas stundas pirms nodarbības sākuma.”
- Malas gadījumi: „Ja nodarbībā nav vietu, rādiet pogu Pierakstīties rindā, nevis Rezervēt.”
- Atļaujas: „Pasniedzēji redz savu nodarbību apmeklējumu, bet ne citu pasniedzēju.”
Katrs no tiem ir viens teikums. Ja kādu no tiem izlaižat, lietotne vai nu neievēros noteikumu, vai izdomās savu versiju.
Pēc pirmās versijas: viena izmaiņa katrā ziņojumā
Kad kaut kas darbojas priekšskatījumā, pārejiet no visa produkta apraksta uz mazu, pārbaudāmu izmaiņu pieprasīšanu.
Pirms:
Dizains ir nepareizs, rezervēšana nedarbojas kā vajag, un gribu kalendāra skatu un e-pastus.
Pēc (kā četri atsevišķi ziņojumi):
- Kad rezervēju pēdējo vietu nodarbībā, nodarbība joprojām rāda „Atlicis 1 vieta”. Tai jārāda „Pilna” un jāslēpj poga Rezervēt.
- Pievieno nedēļas skata kalendāru grafika lapā, vienu kolonnu katrai dienai. Saglabā pašreizējo saraksta skatu kā opciju.
- Padari nodarbību kartītes kompaktākas telefonos: mazāks iekšējais atstarpums, pasniedzēja vārds vienā rindā ar laiku.
- Nosūti dalībniekam apstiprinājuma e-pastu, kad viņš rezervē.
Kāpēc tas darbojas:
- Katra izmaiņa ir pietiekami maza, lai MI to izdarītu pareizi vienā piegājienā.
- Varat pārbaudīt katru, pirms ejat tālāk.
- Ja kaut kas noiet greizi, varat atgriezt tikai šo soli, nezaudējot pārējos.
Pasakiet, ko saglabāt
Kad lūdzat izmaiņu kaut kam, kas jau darbojas, pasakiet MI, kas nedrīkst mainīties. Tas ir vienkāršākais veids, kā apturēt regresijas (lietas, kas agrāk strādāja, pēc labojuma pārtrūkst).
Pārveido sākumlapas virsrakstu ar lielāku virsrakstu un fotogrāfiju labajā pusē. Saglabā navigāciju, krāsas un visu zem virsraksta tieši tā, kā tas ir.
Tas pats attiecas uz datiem: „Pievieno dalībniekiem tālruņa numura lauku. Neizdzēs un nepārdēvē nevienu esošo lauku.”
Izmantojiet ekrānuzņēmumus un precīzu tekstu
Vārdi „tā lieta augšā” ir neskaidri. Vairums MI lietotņu veidotāju pieņem attēlus, un ekrānuzņēmums ar īsu piezīmi ir ātrāks par rindkopu aprakstu.
- Pievienojiet ekrānuzņēmumu un uzrakstiet „poga, kas apvilkta sarkanā krāsā, telefonos pārklājas ar izvēlni”.
- Ielīmējiet jebkura kļūdas paziņojuma precīzu tekstu, nevis to pārstāstiet.
- Citējiet ekrānā redzamās etiķetes precīzi: „poga Saglabāt izmaiņas lapā Iestatījumi”.
Kļūdām konkrēti izmantojiet šādu formu:
Lapā Rezervācijas noklikšķināju uz Atcelt rezervācijai rītdienai. Sagaidīju, ka tā pazudīs no manā saraksta. Tā vietā nekas nenotika, un pēc lapas pārlādēšanas rezervācija joprojām ir. Izlabo to un pārbaudi, vai atcelšana darbojas.
Mūsu rokasgrāmata par to, kā atkļūdot MI veidotu lietotni, šo aplūko sīkāk.
Vispirms plāns lielām izmaiņām
Jebkam, kas skar daudzas lietotnes daļas — lietotāju kontu pievienošanai lietotnei, kurai tādu nebija, maksājumu pievienošanai, datu struktūras maiņai —, pirms kods mainās, pieprasiet plānu.
Pirms kaut ko mainīt, paskaidro, kā pievienotu komandu kontus: kādas jaunas tabulas, kuras lapas mainās un kas notiek ar esošajiem lietotājiem. Vēl nemaini kodu.
Izlasiet plānu. Ja tas kaut ko pārprot, viena rindkopas labošana ir daudz lētāka nekā gatavas funkcijas labošana. Daudziem veidotājiem ir īpašs režīms šim nolūkam; Mythex tas ir režīms Plāns, blakus režīmiem Veidot un Jautāt.
Ko nedarīt
| Nedariet | Kāpēc | Tā vietā |
|---|---|---|
| „Padari labāku” / „Padari pamanāmāku” | Nav mērķa, tāpēc MI nejauši maina lietas | Nosauciet izmaiņu: „vairāk atstarpes starp sadaļām, lielākas virsrakstu” |
| Vienu milzīgu uzvedni ar desmit funkcijām | Kļūdas uzkrājas; grūti pārbaudīt | Viena funkcija vienā ziņojumā |
| API atslēgu ielīmēšana tērzēšanā | Atslēgas paliek tērzēšanas vēsturē | Izmantojiet veidotāja noslēpumus vai vides iestatījumus |
| Strīdēties ar bojātu rezultātu | Katrs labojums uzliek kļūdai virsū | Atgriezieties un pārformulējiet |
| Norādīt kodu, ko nesaprotat | Nostiprina sliktu piemērotību | Aprakstiet vēlamo uzvedību |
| Prasīt „uzņēmuma līmeņa drošību” | Nenozīmē neko konkrētu | Uzskaitiet reālos noteikumus: kas ko var redzēt |
Par API atslēgām: ja jums vajag maksājumu vai e-pasta pakalpojumu, ielieciet tā atslēgas projekta noslēpumos, nevis uzvednē. Ja tas ir jauns, skatiet kas ir vides mainīgie un noslēpumi.
Atkārtoti izmantojamas uzvedņu sagataves
Pielāgojiet tās, aizstājot iekavās ievietotās daļas.
Jauna lietotne:
Izveido [lietotnes veidu] [kam]. Viņi [galvenā plūsma, soli pa solim]. [Otrais lietotāju tips] pieslēdzas, lai [ko dara]. Glabā [datus] datubāzē. [Izskats un noskaņa]. Atstāj ārpusē [lietas vēlākai versijai].
Jauna funkcija:
Pievieno [funkciju] lapai [lapa]. Kad [lietotājs] veic [darbību], jānotiek [kas notiek]. Tikai [kam] drīkst [to darīt]. Saglabā [esošās lietas] tādas, kādas tās ir.
Dizaina izmaiņa:
Lapā [lapa] nomaini [konkrēto elementu] uz [konkrētu izmaiņu]. Saglabā [ko saglabāt]. Pārbaudi, vai tas izskatās pareizi telefona platumā.
Kļūda:
Lapā [lapa] es [soļi]. Sagaidīju [sagaidāmais]. Tā vietā [faktiskais, kā arī precīzs kļūdas teksts]. Izlabo to un pārbaudi, vai plūsma darbojas.
Jautājums bez izmaiņām:
Nemaini nevienu kodu. Izskaidro, kā darbojas [lietotnes daļa] un kur tiek glabāti [dati].
Garākas specifikācijas rakstīšana
Lielākiem projektiem var palīdzēt uzrakstīt vienas lappuses īsu aprakstu un ielīmēt to kā sākuma uzvedni: lietotāji, galvenās plūsmas, dati, noteikumi un tas, kas ir ārpus darbības apjoma. To pat var sastādīt ar MI palīdzību — mūsu rokasgrāmata par produkta prasību dokumenta rakstīšanu ar MI parāda, kā. Tikai turiet pirmo būvēšanas pieprasījumu pie galvenās plūsmas un pārējo pievienojiet soli pa solim.
Uzvedināšana Mythex
Visi iepriekš minētie principi darbojas Mythex. Dažas konkrētas lietas, kas palīdz:
- Režīmi Veidot, Plāns un Jautāt. Izmantojiet Plānu lielām vai riskantām izmaiņām un Jautāt, ja vēlaties skaidrojumu bez rediģēšanas.
- Kontrolpunkti. Pēc katras veiksmīgas izmaiņas Mythex saglabā kontrolpunktu, un Atgriezties šajā punktā atbildē atjauno projektu. Varat arī rediģēt iepriekšēju ziņojumu un nosūtīt to atkārtoti, lai no šī punkta izmēģinātu citu uzvedni.
- Noslēpumu kartīte. Kad aģentam vajag API atslēgu, tas jautā caur kartīti tērzēšanā, lai vērtība tiktu saglabāta kā projekta noslēpums, nevis ierakstīta jūsu ziņojumā.
- Attēli. Pievienojiet ekrānuzņēmumus vai maketus, un aģents tos apskatīs.
Dokumentācijā ir īsa lapa par efektīvām uzvednēm un lapa par iterēšanu bez pārbūves. Ja sākat no nulles, kā veidot lietotni ar MI izskaidro visu projektu, un kā veidot labi izskatītu lietotni ar MI aplūko uzvednes vizuālajam pulējumam.
Jautājumi
Cik garai jābūt uzvednei MI lietotņu veidotājam?
Pirmajai versijai parasti pietiek ar īsu rindkopu no četriem līdz astoņiem teikumiem: kas lieto lietotni, galvenā plūsma, dati, ko tā glabā, un kas drīkst ko redzēt. Pēc tam īsākas uzvednes, kas prasa vienu izmaiņu vienlaikus, darbojas labāk nekā garas.
Vai man vajadzētu pateikt MI, kuru ietvaru vai valodu izmantot?
Tikai tad, ja ir iemesls, piemēram, izstrādātājs, kurš pārņems kodu, vai pakalpojums, kas darbojas tikai ar vienu steku. Citādi aprakstiet produktu un ļaujiet veidotājam izvēlēties saprātīgus noklusējumus.
Kāpēc MI turpina mainīt lietas, ko neesmu lūdzis mainīt?
Parasti tāpēc, ka uzvedne bija plaša („padari labāku”) vai nepateica, ko saglabāt. Nosauciet tieši to, ko mainīt, pasakiet, kas jāpaliek nemainīgs, un katrā ziņojumā lūdziet vienu izmaiņu.
Vai labāk ir labot slikta rezultāta ar vēl vienām uzvednēm vai sākt no jauna?
Ja pēdējā izmaiņa padarīja lietas sliktākas, atgriezieties versijā pirms tās un pārformulējiet, nevis uzliekat labojumus viens uz otra. Jaunu projektu sāciet tikai tad, ja pati ideja ir mainījusies.