ഉപയോക്തൃ കഥകൾ എങ്ങനെ എഴുതാം (ഉദാഹരണങ്ങളും സ്വീകാര്യതാ മാനദണ്ഡങ്ങളും സഹിതം)
ഉപയോക്താവിന്റെ കാഴ്ചപ്പാടിൽ നിന്നുള്ള ഒരു ഫീച്ചറിന്റെ ചെറിയ വിവരണമാണ് ഉപയോക്തൃ കഥ: "ഒരു [ഉപയോക്താവിന്റെ തരം] ആയി, എനിക്ക് [ലക്ഷ്യം] വേണം, അങ്ങനെ [കാരണം]." അതിന് താഴെ സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ എഴുതുന്നു: കഥ പൂർത്തിയായി എന്ന് കണക്കാക്കാൻ ശരിയായിരിക്കേണ്ട കുറച്ച് വ്യക്തമായ വ്യവസ്ഥകൾ. ഓരോ കഥയും ഒറ്റയടിക്ക് നിർമ്മിച്ച് പരിശോധിക്കാവുന്നത്ര ചെറുതാക്കുക, മാനദണ്ഡങ്ങൾ ആർക്കും പരിശോധിക്കാവുന്ന രീതിയിൽ എഴുതുക.
ഉപയോക്തൃ കഥകൾ പ്രചാരത്തിലായത് ചടുലമായ (agile) സോഫ്റ്റ്‌വെയർ ടീമുകളിലൂടെയാണ്. എന്നാൽ ഒരു AI ആപ്പ് ബിൽഡർ ഉപയോഗിച്ച് സ്വന്തമായി നിർമ്മിക്കുമ്പോഴും ഇവ അതേ പ്രയോജനകരമാണ്. ഒരു നല്ല കഥ ഒരു നല്ല പ്രോംപ്റ്റ് തന്നെയാണ്.
ഫോർമാറ്റ്
ഒരു ഉപയോക്തൃ കഥയ്ക്ക് മൂന്ന് ഭാഗങ്ങളുണ്ട്:
As a [ആര്], I want [എന്ത്] so that [എന്തുകൊണ്ട്].
- ആര് എന്നത് ഒരു പ്രത്യേക തരം ഉപയോക്താവാണ്: ആദ്യമായി വരുന്ന സന്ദർശകൻ, പണമടയ്ക്കുന്ന അംഗം, ഒരു ക്ലിനിക്കിലെ റിസപ്ഷനിസ്റ്റ്, ഒരു അഡ്മിൻ. "ഉപയോക്താവ്" എന്നല്ല.
- എന്ത് എന്നത് അവർ ചെയ്യാനാഗ്രഹിക്കുന്ന കാര്യമാണ്, അവരുടെ സ്വന്തം വാക്കുകളിൽ. സ്ക്രീൻ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നല്ല.
- എന്തുകൊണ്ട് എന്നത് അവർ ശ്രദ്ധിക്കുന്ന ഫലമാണ്. ഇതാണ് പലരും ഒഴിവാക്കുന്ന ഭാഗം, പക്ഷേ തെറ്റായ കാര്യം നിർമ്മിക്കുന്നത് തടയുന്നതും ഇതാണ്.
ഉദാഹരണം:
ഒരു ജിം അംഗം ആയി, എനിക്ക് എന്റെ ഫോണിൽ നിന്ന് ഒരു ക്ലാസ് ബുക്കിംഗ് റദ്ദാക്കണം അങ്ങനെ വെയ്റ്റ്‌ലിസ്റ്റിലുള്ള ആർക്കെങ്കിലും എന്റെ സ്ഥാനം എടുക്കാം, എനിക്ക് നോ-ഷോ ഫീസ് ഈടാക്കില്ല.
"എന്തുകൊണ്ട്" എന്ന ഭാഗം "എന്ത്" പറയാത്ത രണ്ട് കാര്യങ്ങൾ പറയുന്നു: ഇത് ഫോണിൽ പ്രവർത്തിക്കണം, വെയ്റ്റ്‌ലിസ്റ്റും ഫീസ് നിയമങ്ങളും ഇതിൽ ഉൾപ്പെടുന്നു.
സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ
കഥ പറയുന്നത് എന്താണ് വേണ്ടത് എന്നാണ്. സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ പറയുന്നത് എപ്പോൾ അത് പൂർത്തിയായി എന്നാണ്. ഓരോ മാനദണ്ഡവും രണ്ടുപേർക്ക് വിജയിച്ചോ ഇല്ലയോ എന്ന് തീരുമാനിക്കാൻ കഴിയുന്നത്ര വ്യക്തമായിരിക്കണം.
ഇത് എഴുതാനുള്ള സാധാരണ രീതി Given / When / Then ആണ്:
- Given ഒരു തുടക്ക സാഹചര്യം
- When ഉപയോക്താവ് ഒരു കാര്യം ചെയ്യുമ്പോൾ
- Then ഇതാണ് ഫലം
ജിം ബുക്കിംഗ് കഥയ്ക്ക്:
- Given എനിക്ക് 12 മണിക്കൂറിലധികം അകലെയുള്ള ഒരു ബുക്കിംഗ് ഉണ്ട്, when ഞാൻ Cancel ടാപ്പ് ചെയ്ത് സ്ഥിരീകരിക്കുന്നു, then ബുക്കിംഗ് നീക്കം ചെയ്യപ്പെടും, "Booking cancelled" എന്ന് കാണിക്കും.
- Given ഞാൻ ഒരു ബുക്കിംഗ് റദ്ദാക്കുകയും ക്ലാസിന് വെയ്റ്റ്‌ലിസ്റ്റ് ഉണ്ടാകുകയും ചെയ്യുന്നു, when റദ്ദാക്കൽ സേവ് ആകുന്നു, then വെയ്റ്റ്‌ലിസ്റ്റിലെ ആദ്യയാൾക്ക് സ്ഥാനവും ഇമെയിലും ലഭിക്കുന്നു.
- Given 12 മണിക്കൂറിനുള്ളിലുള്ള ഒരു ബുക്കിംഗ്, when ഞാൻ Cancel ടാപ്പ് ചെയ്യുന്നു, then സ്ഥിരീകരിക്കുന്നതിന് മുമ്പ് ലേറ്റ്-കാൻസലേഷൻ ഫീസ് ബാധകമാണെന്ന് ഞാൻ കാണുന്നു.
- Given ഞാൻ ഫോൺ-വീതിയുള്ള സ്ക്രീനിലാണ്, then Cancel ബട്ടൺ വശത്തേക്ക് സ്ക്രോൾ ചെയ്യാതെ കാണാം.
ലളിതമായ ചെക്ക്‌ലിസ്റ്റും പ്രവർത്തിക്കും, ഓരോ ഇനവും പരിശോധിക്കാവുന്നതാണെങ്കിൽ. "റദ്ദാക്കൽ എളുപ്പമാണ്" എന്നത് പരിശോധിക്കാനാവില്ല. "ബുക്കിംഗ് ലിസ്റ്റിൽ നിന്ന് റദ്ദാക്കാൻ പരമാവധി രണ്ട് ടാപ്പ് മതി" എന്നത് പരിശോധിക്കാവുന്നതാണ്.
ഘട്ടം ഘട്ടമായി: നല്ല കഥ എഴുതുന്ന വിധം
ഘട്ടം 1: യഥാർത്ഥ ഉപയോക്താവിൽ നിന്നും യഥാർത്ഥ പ്രശ്നത്തിൽ നിന്നും തുടങ്ങുക
ഒരു തരം ഉപയോക്താവിനെയും അവർ ഇന്ന് നേരിടുന്ന ഒരു പ്രശ്നവും തിരഞ്ഞെടുക്കുക. ഉപയോക്തൃ അഭിമുഖങ്ങൾ നടത്തിയിട്ടുണ്ടെങ്കിൽ അവരുടെ വാക്കുകൾ ഉപയോഗിക്കുക. "ഞാൻ എപ്പോഴും റദ്ദാക്കാൻ മറന്നുപോകും, പിന്നെ പണം ഈടാക്കപ്പെടും" എന്നത് "റദ്ദാക്കൽ ഫീച്ചർ ചേർക്കുക" എന്നതിനേക്കാൾ നല്ല തുടക്കമാണ്.
ഘട്ടം 2: ഒരു വരി കഥ എഴുതുക
ടെംപ്ലേറ്റ് പൂരിപ്പിക്കുക. ബോധ്യപ്പെടുത്തുന്ന "അങ്ങനെ" എന്ന ഭാഗം എഴുതാൻ കഴിയുന്നില്ലെങ്കിൽ, ഈ ഫീച്ചർ ആവശ്യമാണോ എന്ന് ചോദിക്കുക.
ഘട്ടം 3: മൂന്ന് മുതൽ ആറ് വരെ സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ ചേർക്കുക
പ്രധാന വിജയ സാഹചര്യം ആദ്യം ഉൾപ്പെടുത്തുക, പിന്നെ പ്രധാനപ്പെട്ട വ്യതിയാനങ്ങൾ: വ്യത്യസ്ത റോൾ, ശൂന്യമായ അവസ്ഥ, ഒരു പരിധി, ഒരു പിശക്. ആറിൽ കൂടുതൽ എഴുതുന്നുണ്ടെങ്കിൽ കഥ ഒരുപക്ഷേ വളരെ വലുതാണ്.
ഘട്ടം 4: എന്താണ് പരിധിക്ക് പുറത്തെന്ന് കുറിക്കുക
ഒരു വരി ധാരാളം തിരിച്ചും മുന്നോട്ടും പോകുന്നത് തടയും: "പരിധിക്ക് പുറത്ത്: പണമടച്ച ക്ലാസുകളുടെ റീഫണ്ട്; അഡ്മിൻ അംഗങ്ങൾക്ക് വേണ്ടി റദ്ദാക്കുന്നത്." നിർമ്മാണ സമയത്ത് കഥ വളരുന്നത് ഇത് തടയുന്നു.
ഘട്ടം 5: INVEST ഉപയോഗിച്ച് പരിശോധിക്കുക
നല്ല കഥയ്ക്കുള്ള ഒരു സാധാരണ ചെക്ക്‌ലിസ്റ്റാണ് INVEST. ഒരു കഥ ഇവയായിരിക്കണം:
| അക്ഷരം | അർത്ഥം | ദ്രുത പരിശോധന |
|---|---|---|
| I | സ്വതന്ത്രം (Independent) | മറ്റൊരു കഥയ്ക്കായി കാത്തിരിക്കാതെ നിർമ്മിക്കാനാകുമോ |
| N | ചർച്ചയ്ക്ക് തുറന്നത് (Negotiable) | ആവശ്യം വിവരിക്കുന്നു, ഉറപ്പിച്ച ഡിസൈൻ അല്ല |
| V | മൂല്യമുള്ളത് (Valuable) | ഇത് പുറത്തിറങ്ങിയാൽ ഉപയോക്താവ് ശ്രദ്ധിക്കും |
| E | കണക്കാക്കാവുന്നത് (Estimable) | ഏകദേശം എത്ര വലുതാണെന്ന് ഊഹിക്കാനാകും |
| S | ചെറുത് (Small) | ഒരു ഇരിപ്പിൽ നിർമ്മിച്ച് പരിശോധിക്കാം |
| T | പരിശോധിക്കാവുന്നത് (Testable) | ഓരോ സ്വീകാര്യതാ മാനദണ്ഡവും പരിശോധിക്കാം |
ഓരോ കഥയ്ക്കും സ്കോർ നൽകേണ്ടതില്ല. ഒരു കഥ ശരിയല്ലെന്ന് തോന്നുമ്പോൾ എന്തുകൊണ്ടെന്ന് അറിയാനാണ് ഇത് ഏറ്റവും ഉപയോഗപ്രദം.
നല്ലതും ചീത്തയുമായ ഉദാഹരണങ്ങൾ
| ദുർബലമായ കഥ | പ്രശ്നം | മെച്ചപ്പെട്ട കഥ |
|---|---|---|
| ഒരു ഉപയോക്താവ് എന്ന നിലയിൽ, എനിക്ക് ഒരു ഡാഷ്‌ബോർഡ് വേണം. | നിർദ്ദിഷ്ട ഉപയോക്താവില്ല, കാരണമില്ല, പരിശോധിക്കാനാവില്ല | ഒരു ഷോപ്പ് ഉടമ എന്ന നിലയിൽ, ഇന്നത്തെ ഓർഡറുകളും വരുമാനവും ഒരൊറ്റ സ്ക്രീനിൽ കാണണം, അങ്ങനെ ദിവസം നന്നായി പോകുന്നുണ്ടോ എന്ന് ഒറ്റനോട്ടത്തിൽ അറിയാം. |
| ഒരു അഡ്മിൻ എന്ന നിലയിൽ, ഡാറ്റാബേസിൽ ഒരു status കോളം വേണം. | നടപ്പിലാക്കലിനെ വിവരിക്കുന്നു, ആവശ്യത്തെയല്ല | ഒരു അഡ്മിൻ എന്ന നിലയിൽ, ഓർഡറുകൾ അയച്ചതായി അടയാളപ്പെടുത്താൻ വേണം, അങ്ങനെ എവിടെയെന്ന് ചോദിച്ച് ഉപഭോക്താക്കൾ ഇമെയിൽ അയക്കുന്നത് നിൽക്കും. |
| ഒരു ഉപഭോക്താവ് എന്ന നിലയിൽ, എന്റെ അക്കൗണ്ട് നിയന്ത്രിക്കണം. | വളരെ വലുത്: പല ഫീച്ചറുകൾ ഉൾപ്പെടുന്നു | ഒരു ഉപഭോക്താവ് എന്ന നിലയിൽ, എന്റെ ഇമെയിൽ വിലാസം മാറ്റണം, അങ്ങനെ രസീതുകൾ പുതിയ ഇൻബോക്സിലെത്തും. |
| ഒരു സന്ദർശകൻ എന്ന നിലയിൽ, സൈറ്റ് വേഗമുള്ളതാകണം. | ഇതൊരു കഥയല്ല; എല്ലാവർക്കും വേണ്ട ഒരു ഗുണമാണ് | ഓരോ കഥയിലും ഒരു മാനദണ്ഡമായോ, അല്ലെങ്കിൽ പ്രത്യേക പ്രകടന ലക്ഷ്യമായോ എഴുതുക. |
വലിയ കഥ വിഭജിക്കുന്ന വിധം
വലിയ കഥകളിലാണ് പ്രോജക്റ്റുകൾ മുടങ്ങുന്നത്. സാധാരണ വിഭജന രീതികൾ:
- ഉപയോക്തൃ റോൾ അനുസരിച്ച്. അംഗങ്ങൾ സ്വന്തം ബുക്കിംഗുകൾ റദ്ദാക്കുന്നു; സ്റ്റാഫ് ആരുടെയും റദ്ദാക്കുന്നു.
- ഫ്ലോയിലെ ഘട്ടം അനുസരിച്ച്. ക്ലാസുകൾ ബ്രൗസ് ചെയ്യുക; ക്ലാസ് ബുക്ക് ചെയ്യുക; ഓർമ്മപ്പെടുത്തൽ ലഭിക്കുക.
- ലളിതമായ കേസ് ആദ്യം. സൗജന്യ ക്ലാസ് ഇപ്പോൾ റദ്ദാക്കുക; ഫീസും റീഫണ്ടും പിന്നീടുള്ള കഥയിൽ.
- ഡാറ്റാ വ്യതിയാനം അനുസരിച്ച്. ആദ്യം ഒരു ലൊക്കേഷൻ മാത്രം; പിന്നീട് പലത്.
- സാധാരണ വഴി ആദ്യം, പിശകുകൾ പിന്നീട്. ആദ്യം പ്രവർത്തിപ്പിക്കുക, പിന്നെ ക്ലാസ് നിറഞ്ഞിരിക്കുക, കാലഹരണപ്പെട്ട പാസ് തുടങ്ങിയവയ്ക്കുള്ള കൈകാര്യം ചേർക്കുക.
ഓരോ ഭാഗവും ഇപ്പോഴും ഒരു ഉപയോക്താവിന് ഉപയോഗിക്കാനും ശ്രദ്ധിക്കാനും കഴിയുന്നതായിരിക്കണം.
ഉപയോക്തൃ കഥകൾ പ്രോംപ്റ്റുകളായി ഉപയോഗിക്കുന്ന വിധം
സ്വീകാര്യതാ മാനദണ്ഡങ്ങളുള്ള ഒരു ഉപയോക്തൃ കഥ AI ആപ്പ് ബിൽഡറിനുള്ള നല്ല പ്രോംപ്റ്റിനോട് വളരെ അടുത്താണ്. അത് AI-ക്ക് ആരാണ്, എന്ത്, എന്തുകൊണ്ട്, പൂർത്തിയായ നിർവചനം എന്നിവ നൽകുന്നു. ഒരു സന്ദേശത്തിൽ ഒരു കഥ വീതം അയയ്ക്കുക:
ഒരു ജിം അംഗം എന്ന നിലയിൽ, എനിക്ക് എന്റെ ഫോണിൽ നിന്ന് ക്ലാസ് ബുക്കിംഗ് റദ്ദാക്കണം, അങ്ങനെ വെയ്റ്റ്‌ലിസ്റ്റിലുള്ള ആർക്കെങ്കിലും എന്റെ സ്ഥാനം എടുക്കാം. സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ:
- My Bookings-ലെ ഓരോ ബുക്കിംഗിലും Cancel ഉണ്ടാകണം, സ്ഥിരീകരണ ഘട്ടത്തോടെ.
- ക്ലാസിന് 12 മണിക്കൂറിലധികം മുമ്പ് റദ്ദാക്കിയാൽ ബുക്കിംഗ് നീക്കം ചെയ്താൽ മതി.
- 12 മണിക്കൂറിൽ താഴെയാണെങ്കിൽ, സ്ഥിരീകരിക്കുന്നതിന് മുമ്പ് "A late-cancellation fee of $5 applies" എന്ന് കാണിക്കുക, ബുക്കിംഗിൽ ഫീസ് രേഖപ്പെടുത്തുക.
- ക്ലാസിന് വെയ്റ്റ്‌ലിസ്റ്റ് ഉണ്ടെങ്കിൽ, ആദ്യയാൾക്ക് സ്ഥാനവും ഇമെയിലും ലഭിക്കണം.
- ഫോൺ-വീതിയുള്ള സ്ക്രീനിൽ പ്രവർത്തിക്കണം. പരിധിക്ക് പുറത്ത്: റീഫണ്ടുകൾ, അംഗങ്ങൾക്ക് വേണ്ടി സ്റ്റാഫ് റദ്ദാക്കുന്നത്. ഇത് നിർമ്മിക്കുക, പിന്നെ പ്രിവ്യൂവിൽ ഓരോ മാനദണ്ഡവും പരിശോധിച്ച് ഏതൊക്കെ വിജയിച്ചു എന്ന് പറയുക.
ഒരു പരുക്കൻ ആശയത്തിൽ നിന്ന് കഥകൾ തയ്യാറാക്കാനും AI-യോട് ആവശ്യപ്പെടാം, പിന്നെ നിങ്ങൾ തന്നെ എഡിറ്റ് ചെയ്യുക:
എന്റെ ആപ്പ് ആശയം ഇതാണ്: [രണ്ടോ മൂന്നോ വാക്യങ്ങൾ]. ആദ്യ പതിപ്പിനുള്ള ഉപയോക്തൃ കഥകൾ എഴുതുക, ഉപയോക്തൃ തരം അനുസരിച്ച് ഗ്രൂപ്പ് ചെയ്ത്, ഓരോന്നിനും 3 മുതൽ 5 വരെ Given/When/Then സ്വീകാര്യതാ മാനദണ്ഡങ്ങളോടെ. ലോഞ്ചിന് അത്യാവശ്യമുള്ളവയും പിന്നീടാകാവുന്നവയും അടയാളപ്പെടുത്തുക.
എപ്പോഴും ഫലം വായിച്ച് എഡിറ്റ് ചെയ്യുക. AI-ക്ക് നിങ്ങളുടെ ഉപയോക്താക്കളെ അറിയില്ല; നിങ്ങൾക്കറിയാം.
സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ തന്നെയാണ് നിങ്ങളുടെ ടെസ്റ്റ് പ്ലാനും. കഥ നിർമ്മിച്ചു കഴിഞ്ഞാൽ ഓരോ മാനദണ്ഡവും സ്വയം പരിശോധിക്കുക. ലോഞ്ചിന് മുമ്പ് നിങ്ങളുടെ ആപ്പ് ടെസ്റ്റ് ചെയ്യുന്ന വിധം എന്ന ഞങ്ങളുടെ ഗൈഡ് ഇതിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.
ഉപയോക്തൃ കഥകൾ മറ്റ് രേഖകളുമായി ചേരുന്ന വിധം
- പ്രോഡക്റ്റ് റിക്വയർമെന്റ്സ് ഡോക്യുമെന്റ് മുഴുവൻ പ്രോഡക്റ്റും വിവരിക്കുന്നു: പ്രശ്നം, ഉപയോക്താക്കൾ, വ്യാപ്തി. ഉപയോക്തൃ കഥകൾ അതിനകത്തെ വിശദമായ ഭാഗങ്ങളാണ്. AI ഉപയോഗിച്ച് PRD എഴുതുന്ന വിധം കാണുക.
- ബഗ് റിപ്പോർട്ട് ഇതിനകം നിർമ്മിച്ച ഒരു കഥയുമായി താരതമ്യം ചെയ്ത് എന്തോ തകർന്നു എന്ന് വിവരിക്കുന്നു. നല്ല ബഗ് റിപ്പോർട്ട് എഴുതുന്ന വിധം കാണുക.
- MVP എന്നത് പ്രധാന മൂല്യം നൽകുന്ന ഏറ്റവും ചെറിയ കഥകളുടെ കൂട്ടമാണ്. എന്താണ് MVP കാണുക.
സാധാരണ തെറ്റുകൾ
- "ഒരു ഉപയോക്താവ് എന്ന നിലയിൽ…" വളരെ അവ്യക്തം. ഏത് തരം ഉപയോക്താവ് എന്ന് പേര് നൽകുക.
- "അങ്ങനെ" ഒഴിവാക്കുന്നത്. കാരണമില്ലെങ്കിൽ ശരിയായ വിട്ടുവീഴ്ചകൾ എടുക്കാനാകില്ല.
- ആവശ്യത്തിന് പകരം പരിഹാരം എഴുതുന്നത്. "എനിക്ക് ഒരു ഡ്രോപ്പ്ഡൗൺ വേണം" എന്നത് ആരും ചിന്തിക്കുന്നതിന് മുമ്പേ ഒരു ഡിസൈൻ ഉറപ്പിക്കുന്നു.
- പരിശോധിക്കാനാവാത്ത മാനദണ്ഡങ്ങൾ. "എളുപ്പം", "വേഗത", "അവബോധജന്യം" എന്നിവ ആഗ്രഹങ്ങളാണ്, മാനദണ്ഡങ്ങളല്ല.
- യഥാർത്ഥത്തിൽ എപ്പിക്കുകളായ കഥകൾ. "എന്റെ അക്കൗണ്ട് നിയന്ത്രിക്കുക" പത്ത് കഥകളാണ്.
- എല്ലാ കഥകളും മുൻകൂട്ടി വിശദമായി എഴുതുന്നത്. അടുത്ത കുറച്ചെണ്ണം വിശദമായി എഴുതുക; ബാക്കി എത്തുന്നതുവരെ ഒരു വരിയായി സൂക്ഷിക്കുക.
Mythex-ലെ കഥകൾ
Mythex-ൽ ഒരു ആശയം കഥകളാക്കാൻ Plan മോഡ് നല്ല സ്ഥലമാണ്: ഏതെങ്കിലും മാറ്റം വരുത്തുന്നതിന് മുമ്പ് ഏജന്റ് സമീപനം ചർച്ച ചെയ്യുന്നു. ഒരു കഥ തയ്യാറായാൽ Build മോഡിലേക്ക് മാറി ഒട്ടിക്കുക, ഒരു സന്ദേശത്തിൽ ഒരു കഥ വീതം. ഓരോന്നിനും ശേഷം /test പ്രിവ്യൂയിൽ ഫ്ലോ ക്ലിക്ക് ചെയ്ത് പരിശോധിക്കും; തെറ്റായ വഴിയിലായാൽ ഏതെങ്കിലും മറുപടി Revert to this point ഉപയോഗിച്ച് തിരികെയെടുക്കാം. ഫലപ്രദമായ പ്രോംപ്റ്റുകൾ ഡോക്സിൽ കാണുക, കൂടാതെ AI ആപ്പ് ബിൽഡറുകൾക്ക് പ്രോംപ്റ്റ് എഴുതുന്ന വിധം എന്ന ഞങ്ങളുടെ ഗൈഡും.
ഉപയോക്തൃ കഥ ചെക്ക്‌ലിസ്റ്റ്
- ഒരു നിർദ്ദിഷ്ട തരം ഉപയോക്താവിനെ പേരെടുത്ത് പറയുന്നു
- ഒരു ആവശ്യം വിവരിക്കുന്നു, ഡിസൈൻ അല്ല
- യഥാർത്ഥ "അങ്ങനെ" കാരണം ഉൾപ്പെടുത്തിയിരിക്കുന്നു
- മൂന്ന് മുതൽ ആറ് വരെ പരിശോധിക്കാവുന്ന സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ
- കുറഞ്ഞത് ഒരു അപവാദ കേസോ പിശകോ ഉൾപ്പെടുന്നു
- പരിധിക്ക് പുറത്തുള്ളത് പറഞ്ഞിരിക്കുന്നു
- ഒറ്റയടിക്ക് നിർമ്മിച്ച് പരിശോധിക്കാവുന്നത്ര ചെറുതാണ്
- നിർമ്മിച്ച ശേഷം മാനദണ്ഡങ്ങൾ ഓരോന്നായി പരിശോധിച്ചു
ചോദ്യങ്ങൾ
ഉപയോക്തൃ കഥയുടെ ഫോർമാറ്റ് എന്താണ്?
സാധാരണ ടെംപ്ലേറ്റ്: ഒരു [ഉപയോക്താവിന്റെ തരം] ആയി, എനിക്ക് [ഒരു ലക്ഷ്യം] വേണം, അങ്ങനെ [ഒരു കാരണം]. അതിന് പിന്നാലെ സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ വരും; കഥ പൂർത്തിയായി എന്ന് കണക്കാക്കാൻ ശരിയായിരിക്കേണ്ട വ്യവസ്ഥകളുടെ ചെറിയ പട്ടികയാണിത്.
സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ എന്താണ്?
ഒരു ഉപയോക്തൃ കഥ പൂർത്തിയായി എന്ന് നിർവചിക്കുന്ന, വ്യക്തവും പരിശോധിക്കാവുന്നതുമായ വ്യവസ്ഥകളാണ് സ്വീകാര്യതാ മാനദണ്ഡങ്ങൾ. പലപ്പോഴും Given / When / Then രൂപത്തിലാണ് എഴുതുന്നത്: ഒരു തുടക്ക സാഹചര്യം നൽകിയാൽ, ഉപയോക്താവ് ഒരു കാര്യം ചെയ്യുമ്പോൾ, ഒരു പ്രത്യേക ഫലം ഉണ്ടാകുന്നു.
ഒരു ഉപയോക്തൃ കഥ എത്ര വലുതാകണം?
ഒറ്റ ഇരിപ്പിൽ നിർമ്മിച്ച് പരിശോധിക്കാവുന്നത്ര ചെറുതും, അതിന് തന്നെ മൂല്യമുള്ളതും ആയിരിക്കണം. കഥയിൽ അഞ്ചോ ആറോ സ്വീകാര്യതാ മാനദണ്ഡങ്ങളിൽ കൂടുതലുണ്ടെങ്കിലോ, ഒന്നിലധികം സ്ക്രീനുകൾ ഉൾപ്പെടുന്നെങ്കിലോ, ഉപയോക്തൃ റോൾ, ഫ്ലോയിലെ ഘട്ടം, അല്ലെങ്കിൽ ആദ്യം ലളിതമായ കേസ്, പിന്നീട് അപവാദ കേസുകൾ എന്ന രീതിയിൽ വിഭജിക്കുക.
AI ഉപയോഗിച്ച് നിർമ്മിക്കുമ്പോൾ ഉപയോക്തൃ കഥകൾ ഉപയോഗപ്രദമാണോ?
അതെ. സ്വീകാര്യതാ മാനദണ്ഡങ്ങളുള്ള ഒരു ഉപയോക്തൃ കഥ ഏറെക്കുറെ ആദർശപരമായ പ്രോംപ്റ്റാണ്: ഫീച്ചർ ആർക്കുവേണ്ടിയാണ്, അവർക്ക് എന്ത് വേണം, അത് ശരിയായി പ്രവർത്തിക്കുന്നു എന്ന് എങ്ങനെ പരിശോധിക്കാം എന്നിവ അതിൽ പറയുന്നു. ഒരു സന്ദേശത്തിൽ ഒരു കഥ വീതം അയയ്ക്കുന്നത് AI മാറ്റങ്ങൾ ചെറുതാക്കി പരിശോധിക്കാൻ എളുപ്പമാക്കും.