Пайдаланушы оқиғаларын қалай жазу керек (мысалдар мен қабылдау өлшемдерімен)

Пайдаланушы оқиғасы — функцияны пайдаланушы көзқарасынан сипаттайтын қысқа сипаттама: «Пайдаланушы ретінде [пайдаланушы түрі] ретінде мен [мақсат] жасағым келеді, сонда [себеп] болады.» Оның астында қабылдау өлшемдерін жазасыз — оқиға аяқталды деп есептелу үшін орындалуы керек бірнеше нақты шарт. Әр оқиғаны бір рет құрып, сынауға жететіндей шағын ұстаңыз, ал өлшемдерді кез келген адам тексере алатындай етіп жазыңыз.

Пайдаланушы оқиғаларын agile командалары танымал етті, бірақ AI app builder-мен жалғыз құрастырғанда да солай пайдалы. Жақсы оқиға — жақсы промпт.

Пішімі

Пайдаланушы оқиғасында үш бөлік бар:

Пайдаланушы ретінде [кім], мен [не] жасағым келеді, сонда [неге].

• Кім — нақты пайдаланушы түрі: алғаш келген қонақ, ақылы мүше, клиника қабылдаушысы, әкімші. «Пайдаланушы» емес.
• Не — олар өз сөзімен айтқан, істегісі келетін нәрсе. Экран қалай жұмыс істейтіні емес.
• Неге — олар мән беретін нәтиже. Адамдар жиі өткізіп жіберетін бөлік, ол дұрыс емес нәрсені құрудан сақтайды.

Мысал:

Пайдаланушы ретінде спорт залының мүшесі ретінде мен сабаққа брондауды телефонымнан бас тартқым келеді, сонда күту тізіміндегі біреу орнымды ала алады және мен келмегені үшін төлем алынбаймын.

«Неге» бөлігі «не» бөлігі айтпаған екі нәрсені айтады: ол телефонда жұмыс істеуі керек және күту тізімі мен төлем ережелері қатысады.

Қабылдау өлшемдері

Оқиға не қалайтынын айтады. Қабылдау өлшемдері оның қашан аяқталғанын айтады. Олар әр өлшем өтті ме деп екі адам келісе алатындай нақты болуы керек.

Оларды жазудың кең таралған жолы — Берілген / Егер / Сонда:

• Берілген бастапқы жағдай
• Егер пайдаланушы бірдеңе жасаса
• Сонда мынадай нәтиже болады

Спорт залын брондау оқиғасы үшін:

1. Берілген менде 12 сағаттан көп уақыт қалған брондау бар, егер мен Бас тарту түймесін басып, растасам, сонда брондау жойылады және мен «Брондау бас тартылды» деген хабарды көремін.
2. Берілген мен брондауымнан бас тартамын және сабақта күту тізімі бар, егер бас тарту сақталса, сонда күту тізімінің бірінші адамы орынды және электрондық хатты алады.
3. Берілген сабаққа 12 сағаттан аз уақыт қалған брондау, егер мен Бас тарту түймесін басамын, сонда растамас бұрын кеш бас тарту үшін төлем қолданылатынын көремін.
4. Берілген мен телефон ені экранында болсам, сонда Бас тарту түймесі көлденең айналдырусыз көрінеді.

Жай тізім де жұмыс істейді, әр элемент тексерілетін болса. «Бас тарту оңай» — тексерілмейді. «Бас тарту брондау тізімінен ең көбі екі рет басуды алады» — тексеріледі.

Қадам-қадам: жақсы оқиға жазу

1-қадам: нақты пайдаланушыдан және нақты мәселеден бастаңыз

Бір пайдаланушы түрін және олардың бүгін қиналатын нәрсесін таңдаңыз. Клиенттермен сұхбаттасқан болсаңыз, олардың сөздерін қолданыңыз. «Мен әрдайым бас тартуды ұмытып, ақша алынады» — «бас тарту функциясын қосу» деген жерден жақсырақ бастама.

2-қадам: бір жолдық оқиға жазыңыз

үлгіні толтырыңыз. Сенімді «сонда» бөлігін жаза алмасаңыз, функцияның қажет-қажет еместігін сұраңыз.

3-қадам: үш-алты қабылдау өлшемін қосыңыз

Алдымен негізгі сәтті жағдайды қамтыңыз, содан кейін маңызды вариацияларды: басқа рөл, бос күй, шек, қате. Алтыдан көп жазып жатсаңыз, оқиға бәлкім тым үлкен.

4-қадам: көлемнен тыс нәрсені жазыңыз

Бір жол көп кері-қайтаруды үнемдейді: «Көлемнен тыс: ақылы сабақтар үшін қайтару; әкімшілер мүшелер үшін бас тарта алмайды.» Бұл құру кезінде оқиғаның өсіп кетуіне жол бермейді.

5-қадам: INVEST бойынша тексеріңіз

INVEST — жақсы оқиғалар үшін кең таралған тексеру тізімі. Оқиға мынадай болуы керек:

Әр оқиғаны балл қоюдың қажеті жоқ. Оқиға дұрыс емес сияқты көрінгенде және неге екенін білгіңіз келгенде ең пайдалы.

Жақсы және нашар мысалдар

Тым үлкен оқиғаны қалай бөлу керек

Үлкен оқиғалар — жобалардың тоқырайтын жері. Бөлудің жиі кездесетін жолдары:

• Пайдаланушы рөлі бойынша. Мүшелер өз брондауларынан бас тартады; қызметкерлер кез келген брондаудан бас тартады.
• Ағындағы қадам бойынша. Сабақтарды қарау; сабаққа брондау; еске салғышты алу.
• Алдымен қарапайым жағдай. Ақысыз сабақтан қазір бас тарту; төлемдер мен қайтаруларды кейінгі оқиғада өңдеу.
• Деректер вариациясы бойынша. Алдымен бір орынды қолдау, кейін бірнешеуін.
• Негізгі жол, содан кейін қателер. Алдымен жұмыс істеуін құрыңыз, содан кейін сабақ толғанда, мерзімі өткен абонемент сияқты жағдайларды өңдеуді қосыңыз.

Әр бөлік әлі де пайдаланушы қолдана алатын және байқайтын нәрсе болуы керек.

Пайдаланушы оқиғаларын промпт ретінде пайдалану

Қабылдау өлшемдері бар пайдаланушы оқиғасы AI app builder-ге арналған жақсы промптқа өте жақын. Ол AI-ға кім, не, неге және аяқталғанның анықтамасын береді. Бір хабарламаға бір оқиға жіберіңіз:

Пайдаланушы ретінде мен спорт залының мүшесі ретінде сабаққа брондауды телефонымнан бас тартқым келеді, сонда күту тізіміндегі біреу орнымды ала алады. Қабылдау өлшемдері:

1. Бас тарту әр брондауда «Менің брондауларым» бөлімінде растау қадамымен болады.
2. Сабақтан 12 сағаттан көбірек уақыт бұрын бас тарту брондауды жай ғана жояды.
3. 12 сағаттан аз уақыт қалса, растамас бұрын «5 доллар кеш бас тарту төлемі қолданылады» деп көрсетіп, төлемді брондауға жазыңыз.
4. Сабақта күту тізімі болса, бірінші адам орынды және хатты алады.
5. Телефон ені экранында жұмыс істейді. Көлемнен тыс: қайтарулар, қызметкерлердің мүшелер үшін бас тартуы. Осыны құрыңыз, содан кейін алдын ала көрініс ішінде әр өлшемді тексеріп, қайсысы өтті соны айтыңыз.

Сондай-ақ AI-дан бұлыңғыр идеядан оқиғаларды жасауды сұрай аласыз, содан кейін оларды өзіңіз өңдеңіз:

Менің қолданба идеям: [екі-үш сөйлем]. Бірінші нұсқа үшін пайдаланушы оқиғаларын жазыңыз, пайдаланушы түрі бойынша топтаңыз, әр оқиғада 3-тен 5-ке дейін Берілген/Егер/Сонда қабылдау өлшемдері болсын. Іске қосу үшін қайсысы міндетті, қайсысы кейінге қалуы мүмкін екенін белгілеңіз.

Нәтижені әрдайым оқып, өзіңіз өңдеңіз. AI сіздің пайдаланушыларыңызды білмейді; сіз білесіз.

Қабылдау өлшемдері сынақ жоспарыңыз да болады. Оқиға құрылғаннан кейін әр өлшемді өзіңіз қараңыз. Қолданбаны іске қоспас бұрын сынау осыған негізделген.

Пайдаланушы оқиғалары басқа құжаттармен қалай байланысады

• Өнім талаптары құжаты бүкіл өнімді сипаттайды: мәселе, пайдаланушылар, көлем. Пайдаланушы оқиғалары — оның ішіндегі нақты бөліктер. Қараңыз: PRD-ді AI-мен қалай жазу керек.
• Қате туралы есеп құрылған оқиғаға қарсы бұзылған нәрсені сипаттайды. Қараңыз: жақсы қате туралы есепті қалай жазу керек.
• MVP — негізгі құнды жеткізетін ең аз оқиғалар жиыны. Қараңыз: MVP деген не.

Жиі кездесетін қателер

• «Пайдаланушы ретінде…» деген жалпы сөз. Тым бұлыңғыр. Пайдаланушының нақты түрін атаңыз.
• «Сонда» бөлігін өткізіп жіберу. Себепсіз сенімді шешім қабылдау мүмкін емес.
• Қажеттіліктің орнына шешімді жазу. «Маған ашылмалы тізім керек» дизайнды ешкім ойланбай тұрып бекітеді.
• Сынаңыз келмейтін өлшемдер. «Оңай», «жылдам» және «интуитивті» — тілектер, өлшемдер емес.
• Шын мәнінде эпик болып табылатын оқиғалар. «Аккаунтымды басқару» — он оқиға.
• Барлық оқиғаны алдын ала жазу. Келесі бірнешеуін толық жазыңыз; қалғандарын оларға жеткенше бір жолдық күйінде қалдырыңыз.

Mythex-те оқиғалар

Mythex-те Plan режимі идеяны оқиғаларға айналдыруға жақсы орын: агент ештеңені өңдемей тұрып тәсілді талқылайды. Оқиға дайын болғанда Build режиміне ауысып, бір хабарламаға бір оқиға қойыңыз. Әр оқиғадан кейін /test алдын ала көріністе басып, ағынды тексере алады, ал егер дұрыс жүрмесе, кез келген жауапты Осы нүктеге қайту арқылы қайтаруға болады. Құжаттардағы тиімді промпттарды және біздің AI app builder-ге промпт жазу нұсқаулығын қараңыз.

Пайдаланушы оқиғасының чек-листі

• Пайдаланушының нақты түрін атайды
• Қажеттілікті сипаттайды, дизайнды емес
• Нақты «сонда» себебі бар
• Үш-алты сыналатын қабылдау өлшемі бар
• Кем дегенде бір шеткі жағдай немесе қатені қамтиды
• Көлемнен тыс нәрсені айтады
• Бір отырыста құрып, сынауға жеткілікті шағын
• Құрылғаннан кейін өлшемдер бір-бірден тексерілді

Сұрақтар