ਯੂਜ਼ਰ ਸਟੋਰੀਆਂ ਕਿਵੇਂ ਲਿਖੀਏ (ਉਦਾਹਰਨਾਂ ਅਤੇ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡਾਂ ਨਾਲ)
ਯੂਜ਼ਰ ਸਟੋਰੀ ਇੱਕ ਫ਼ੀਚਰ ਦਾ ਛੋਟਾ ਵਰਣਨ ਹੈ ਯੂਜ਼ਰ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ: "As a [ਕਿਸਮ ਦਾ ਯੂਜ਼ਰ], I want [ਟੀਚਾ] so that [ਕਾਰਨ]।" ਇਸਦੇ ਹੇਠਾਂ ਤੁਸੀਂ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਲਿਖਦੇ ਹੋ, ਕੁਝ ਖਾਸ ਸ਼ਰਤਾਂ ਜੋ ਸੱਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਸਟੋਰੀ ਪੂਰੀ ਮੰਨੀ ਜਾਵੇ। ਹਰ ਸਟੋਰੀ ਇੰਨੀ ਛੋਟੀ ਰੱਖੋ ਕਿ ਇੱਕ ਵਾਰ ਵਿੱਚ ਬਣਾਈ ਅਤੇ ਟੈਸਟ ਕੀਤੀ ਜਾ ਸਕੇ, ਅਤੇ ਮਾਪਦੰਡ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ ਕਿ ਕੋਈ ਵੀ ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕੇ।
ਯੂਜ਼ਰ ਸਟੋਰੀਆਂ ਐਜਾਈਲ ਸਾਫ਼ਟਵੇਅਰ ਟੀਮਾਂ ਵਿੱਚ ਮਸ਼ਹੂਰ ਹੋਈਆਂ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਇਕੱਲੇ 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: ਇੱਕ ਲਾਈਨ ਦੀ ਸਟੋਰੀ ਲਿਖੋ
ਟੈਮਪਲੇਟ ਭਰੋ। ਜੇ ਤੁਸੀਂ ਯਕੀਨਨ "so that" ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਪੁੱਛੋ ਕਿ ਕੀ ਫ਼ੀਚਰ ਦੀ ਲੋੜ ਹੈ ਵੀ ਸਹੀ।
ਕਦਮ 3: ਤਿੰਨ ਤੋਂ ਛੇ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਜੋੜੋ
ਪਹਿਲਾਂ ਮੁੱਖ ਸਫ਼ਲ ਕੇਸ, ਫਿਰ ਮਹੱਤਵਪੂਰਨ ਭਿੰਨਤਾਵਾਂ: ਵੱਖਰੀ ਭੂਮਿਕਾ, ਖਾਲੀ ਹਾਲਤ, ਕੋਈ ਹੱਦ, ਕੋਈ ਗਲਤੀ। ਜੇ ਛੇ ਤੋਂ ਵੱਧ ਲਿਖ ਰਹੇ ਹੋ, ਤਾਂ ਸਟੋਰੀ ਸ਼ਾਇਦ ਬਹੁਤ ਵੱਡੀ ਹੈ।
ਕਦਮ 4: ਲਿਖੋ ਕਿ ਕੀ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ
ਇੱਕ ਲਾਈਨ ਬਹੁਤ ਸਾਰੀ ਆਵਾਜਾਈ ਬਚਾਉਂਦੀ ਹੈ: "ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ: ਕਲਾਸ ਦੀਆਂ ਭੁਗਤਾਨ ਵਾਲੀਆਂ ਬੁਕਿੰਗਾਂ ਲਈ ਰਿਫ਼ੰਡ; ਐਡਮਿਨ ਵੱਲੋਂ ਮੈਂਬਰਾਂ ਦੀ ਤਰਫ਼ੋਂ ਰੱਦ ਕਰਨਾ।" ਇਹ ਬਣਾਉਂਦੇ ਸਮੇਂ ਸਟੋਰੀ ਨੂੰ ਵਧਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਕਦਮ 5: INVEST ਨਾਲ ਜਾਂਚੋ
INVEST ਚੰਗੀਆਂ ਸਟੋਰੀਆਂ ਲਈ ਆਮ ਚੈੱਕਲਿਸਟ ਹੈ। ਸਟੋਰੀ ਇਹ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
| ਅੱਖਰ | ਮਤਲਬ | ਛੇਤੀ ਟੈਸਟ |
|---|---|---|
| I | ਸੁਤੰਤਰ | ਕਿਸੇ ਹੋਰ ਸਟੋਰੀ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਬਣ ਸਕਦੀ ਹੈ |
| N | ਗੱਲਬਾਤ ਯੋਗ | ਲੋੜ ਦੱਸਦੀ ਹੈ, ਪੱਕਾ ਡਿਜ਼ਾਈਨ ਨਹੀਂ |
| V | ਮੁੱਲਵਾਨ | ਜੇ ਰਿਲੀਜ਼ ਹੋਵੇ ਤਾਂ ਯੂਜ਼ਰ ਧਿਆਨ ਦੇਵੇ |
| E | ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਯੋਗ | ਤੁਸੀਂ ਮੋਟਾ ਅੰਦਾਜ਼ਾ ਲਾ ਸਕਦੇ ਹੋ ਕਿ ਕਿੰਨੀ ਵੱਡੀ ਹੈ |
| S | ਛੋਟੀ | ਇੱਕ ਬੈਠਕ ਵਿੱਚ ਬਣੀ ਅਤੇ ਟੈਸਟ ਹੋਈ |
| T | ਜਾਂਚਣਯੋਗ | ਹਰ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਦੀ ਜਾਂਚ ਹੋ ਸਕਦੀ ਹੈ |
ਤੁਹਾਨੂੰ ਹਰ ਸਟੋਰੀ ਨੂੰ ਅੰਕ ਦੇਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹ ਉਦੋਂ ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਕੋਈ ਸਟੋਰੀ ਗਲਤ ਲੱਗੇ ਅਤੇ ਤੁਸੀਂ ਕਾਰਨ ਜਾਣਨਾ ਚਾਹੋ।
ਚੰਗੀਆਂ ਅਤੇ ਮਾੜੀਆਂ ਉਦਾਹਰਨਾਂ
| ਕਮਜ਼ੋਰ ਸਟੋਰੀ | ਸਮੱਸਿਆ | ਬਿਹਤਰ ਸਟੋਰੀ |
|---|---|---|
| As a user, I want a dashboard. | ਕੋਈ ਖਾਸ ਯੂਜ਼ਰ ਨਹੀਂ, ਕੋਈ ਕਾਰਨ ਨਹੀਂ, ਜਾਂਚਣਯੋਗ ਨਹੀਂ | As a shop owner, I want to see today's orders and revenue on one screen so that I know at a glance if the day is going well. |
| As an admin, I want the database to have a status column. | ਲਾਗੂਕਰਨ ਦਾ ਵਰਣਨ, ਲੋੜ ਦਾ ਨਹੀਂ | As an admin, I want to mark orders as shipped so that customers stop emailing to ask where they are. |
| As a customer, I want to manage my account. | ਬਹੁਤ ਵੱਡੀ: ਕਈ ਫ਼ੀਚਰ ਕਵਰ ਕਰਦੀ ਹੈ | As a customer, I want to change my email address so that receipts go to my new inbox. |
| As a visitor, I want the site to be fast. | ਸਟੋਰੀ ਨਹੀਂ; ਹਰ ਕਿਸੇ ਨੂੰ ਚਾਹੀਦੀ ਗੁਣਵੱਤਾ ਹੈ | ਇਸਨੂੰ ਹਰ ਸਟੋਰੀ 'ਤੇ ਇੱਕ ਮਾਪਦੰਡ ਵਜੋਂ ਲਿਖੋ, ਜਾਂ ਵੱਖਰੇ ਪ੍ਰਦਰਸ਼ਨ ਟੀਚੇ ਵਜੋਂ। |
ਵੱਡੀ ਸਟੋਰੀ ਨੂੰ ਕਿਵੇਂ ਵੰਡੀਏ
ਵੱਡੀਆਂ ਸਟੋਰੀਆਂ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਪ੍ਰੋਜੈਕਟ ਰੁਕ ਜਾਂਦੇ ਹਨ। ਆਮ ਵੰਡਣ ਦੇ ਤਰੀਕੇ:
- ਯੂਜ਼ਰ ਭੂਮਿਕਾ ਅਨੁਸਾਰ। ਮੈਂਬਰ ਆਪਣੀਆਂ ਬੁਕਿੰਗਾਂ ਰੱਦ ਕਰਦੇ ਹਨ; ਸਟਾਫ਼ ਕਿਸੇ ਦੀ ਵੀ।
- ਪ੍ਰਵਾਹ ਦੇ ਕਦਮ ਅਨੁਸਾਰ। ਕਲਾਸਾਂ ਬ੍ਰਾਊਜ਼ ਕਰੋ; ਕਲਾਸ ਬੁੱਕ ਕਰੋ; ਯਾਦ ਦਿਵਾਉਣਾ ਲਓ।
- ਸਾਦਾ ਕੇਸ ਪਹਿਲਾਂ। ਮੁਫ਼ਤ ਕਲਾਸ ਹੁਣੇ ਰੱਦ ਕਰੋ; ਫ਼ੀਸਾਂ ਅਤੇ ਰਿਫ਼ੰਡ ਬਾਅਦ ਦੀ ਸਟੋਰੀ ਵਿੱਚ।
- ਡਾਟਾ ਭਿੰਨਤਾ ਅਨੁਸਾਰ। ਪਹਿਲਾਂ ਇੱਕ ਟਿਕਾਣਾ ਸਹਿਯੋਗ ਦਿਓ, ਬਾਅਦ ਵਿੱਚ ਕਈ।
- ਸਫ਼ਲ ਰਸਤਾ ਪਹਿਲਾਂ, ਗਲਤੀਆਂ ਬਾਅਦ। ਪਹਿਲਾਂ ਕੰਮ ਕਰਦਾ ਬਣਾਓ, ਫਿਰ ਭਰੀਆਂ ਕਲਾਸਾਂ, ਖਤਮ ਹੋਏ ਪਾਸ ਆਦਿ ਲਈ ਹੱਲ ਜੋੜੋ।
ਹਰ ਟੁਕੜਾ ਫਿਰ ਵੀ ਕੁਝ ਅਜਿਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਵਰਤ ਸਕੇ ਅਤੇ ਧਿਆਨ ਦੇ ਸਕੇ।
ਯੂਜ਼ਰ ਸਟੋਰੀਆਂ ਨੂੰ ਪ੍ਰੋਂਪਟ ਵਜੋਂ ਵਰਤਣਾ
ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡਾਂ ਵਾਲੀ ਯੂਜ਼ਰ ਸਟੋਰੀ AI ਐਪ ਬਿਲਡਰ ਲਈ ਚੰਗੇ ਪ੍ਰੋਂਪਟ ਦੇ ਬਹੁਤ ਨੇੜੇ ਹੈ। ਇਹ AI ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕੌਣ, ਕੀ, ਕਿਉਂ ਅਤੇ "ਪੂਰਾ" ਦਾ ਅਰਥ ਕੀ ਹੈ। ਹਰ ਸੁਨੇਹੇ ਵਿੱਚ ਇੱਕ ਸਟੋਰੀ ਭੇਜੋ:
As a gym member, I want to cancel a class booking from my phone so that someone on the waitlist can take my spot. ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ:
- ਮੇਰੀਆਂ ਬੁਕਿੰਗਾਂ ਵਿੱਚ ਹਰ ਬੁਕਿੰਗ 'ਤੇ Cancel ਹੈ, ਪੁਸ਼ਟੀ ਕਦਮ ਨਾਲ।
- 12 ਘੰਟੇ ਤੋਂ ਵੱਧ ਪਹਿਲਾਂ ਰੱਦ ਕਰਨ 'ਤੇ ਬੁਕਿੰਗ ਸਿਰਫ਼ ਹਟ ਜਾਂਦੀ ਹੈ।
- 12 ਘੰਟਿਆਂ ਤੋਂ ਘੱਟ ਪਹਿਲਾਂ ਹੋਵੇ ਤਾਂ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ "A late-cancellation fee of $5 applies" ਦਿਖਾਓ, ਅਤੇ ਫ਼ੀਸ ਬੁਕਿੰਗ 'ਤੇ ਦਰਜ ਕਰੋ।
- ਜੇ ਕਲਾਸ ਦੀ ਵੇਟਲਿਸਟ ਹੈ, ਤਾਂ ਪਹਿਲੇ ਵਿਅਕਤੀ ਨੂੰ ਥਾਂ ਅਤੇ ਈਮੇਲ ਮਿਲੇ।
- ਫ਼ੋਨ ਚੌੜਾਈ ਵਾਲੀ ਸਕਰੀਨ 'ਤੇ ਕੰਮ ਕਰੇ। ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ: ਰਿਫ਼ੰਡ, ਸਟਾਫ਼ ਵੱਲੋਂ ਮੈਂਬਰਾਂ ਲਈ ਰੱਦ ਕਰਨਾ। ਇਸਨੂੰ ਬਣਾਓ, ਫਿਰ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਹਰ ਮਾਪਦੰਡ ਜਾਂਚੋ ਅਤੇ ਦੱਸੋ ਕਿ ਕਿਹੜੇ ਪਾਸ ਹੁੰਦੇ ਹਨ।
ਤੁਸੀਂ AI ਨੂੰ ਇੱਕ ਮੋਟੇ ਵਿਚਾਰ ਤੋਂ ਸਟੋਰੀਆਂ ਦਾ ਖਰੜਾ ਬਣਾਉਣ ਲਈ ਵੀ ਕਹਿ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਆਪ ਸੋਧ ਸਕਦੇ ਹੋ:
ਮੇਰੀ ਐਪ ਦਾ ਵਿਚਾਰ ਇਹ ਹੈ: [ਦੋ ਜਾਂ ਤਿੰਨ ਵਾਕ]। ਪਹਿਲੇ ਵਰਜ਼ਨ ਲਈ ਯੂਜ਼ਰ ਕਿਸਮ ਅਨੁਸਾਰ ਸਮੂਹ ਕਰਕੇ ਯੂਜ਼ਰ ਸਟੋਰੀਆਂ ਲਿਖੋ, ਹਰ ਇੱਕ ਨਾਲ 3 ਤੋਂ 5 Given/When/Then ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ। ਦੱਸੋ ਕਿ ਕਿਹੜੀਆਂ ਲਾਂਚ ਲਈ ਜ਼ਰੂਰੀ ਹਨ ਅਤੇ ਕਿਹੜੀਆਂ ਉਡੀਕ ਸਕਦੀਆਂ ਹਨ।
ਹਮੇਸ਼ਾ ਨਤੀਜਾ ਪੜ੍ਹੋ ਅਤੇ ਆਪ ਸੋਧੋ। AI ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਨਹੀਂ ਜਾਣਦਾ; ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ।
ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਤੁਹਾਡੀ ਟੈਸਟ ਯੋਜਨਾ ਵੀ ਹਨ। ਜਦੋਂ ਸਟੋਰੀ ਬਣ ਜਾਵੇ, ਤਾਂ ਹਰ ਮਾਪਦੰਡ ਆਪ ਚੈੱਕ ਕਰੋ। ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਐਪ ਨੂੰ ਟੈਸਟ ਕਿਵੇਂ ਕਰੀਏ ਇਸੇ 'ਤੇ ਬਣਦੀ ਹੈ।
ਯੂਜ਼ਰ ਸਟੋਰੀਆਂ ਹੋਰ ਦਸਤਾਵੇਜ਼ਾਂ ਨਾਲ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦੀਆਂ ਹਨ
- ਪ੍ਰੋਡਕਟ ਰਿਕਵਾਇਰਮੈਂਟਸ ਡੌਕੂਮੈਂਟ ਪੂਰੇ ਪ੍ਰੋਡਕਟ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ: ਸਮੱਸਿਆ, ਯੂਜ਼ਰ, ਦਾਇਰਾ। ਯੂਜ਼ਰ ਸਟੋਰੀਆਂ ਉਸਦੇ ਅੰਦਰ ਵਿਸਥਾਰ ਵਾਲੇ ਟੁਕੜੇ ਹਨ। ਵੇਖੋ AI ਨਾਲ PRD ਕਿਵੇਂ ਲਿਖੀਏ।
- ਬੱਗ ਰਿਪੋਰਟ ਉਸ ਚੀਜ਼ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ ਜੋ ਪਹਿਲਾਂ ਬਣੀ ਸੀ ਅਤੇ ਹੁਣ ਟੁੱਟੀ ਹੈ। ਵੇਖੋ ਚੰਗੀ ਬੱਗ ਰਿਪੋਰਟ ਕਿਵੇਂ ਲਿਖੀਏ।
- MVP ਸਭ ਤੋਂ ਛੋਟਾ ਸਟੋਰੀਆਂ ਦਾ ਸਮੂਹ ਹੈ ਜੋ ਮੁੱਖ ਮੁੱਲ ਦਿੰਦਾ ਹੈ। ਵੇਖੋ MVP ਕੀ ਹੁੰਦਾ ਹੈ।
ਆਮ ਗਲਤੀਆਂ
- "As a user…" ਬਹੁਤ ਧੁੰਦਲਾ ਹੈ। ਯੂਜ਼ਰ ਦੀ ਖਾਸ ਕਿਸਮ ਦਾ ਨਾਮ ਲਓ।
- "so that" ਛੱਡਣਾ। ਕਾਰਨ ਤੋਂ ਬਿਨਾਂ ਸਮਝਦਾਰ ਸਮਝੌਤੇ ਨਹੀਂ ਹੋ ਸਕਦੇ।
- ਲੋੜ ਦੀ ਥਾਂ ਹੱਲ ਲਿਖਣਾ। "ਮੈਨੂੰ ਡ੍ਰੌਪਡਾਊਨ ਚਾਹੀਦਾ ਹੈ" ਕਿਸੇ ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਸੋਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਉਸਨੂੰ ਪੱਕਾ ਕਰ ਦਿੰਦਾ ਹੈ।
- ਜਾਂਚਣਯੋਗ ਨਾ ਹੋਣ ਵਾਲੇ ਮਾਪਦੰਡ। "ਆਸਾਨ", "ਤੇਜ਼" ਅਤੇ "ਅਨੁਭਵੀ" ਇੱਛਾਵਾਂ ਹਨ, ਮਾਪਦੰਡ ਨਹੀਂ।
- ਜੋ ਅਸਲ ਵਿੱਚ ਐਪਿਕ ਹਨ ਉਹਨਾਂ ਨੂੰ ਸਟੋਰੀ ਕਹਿਣਾ। "ਮੇਰਾ ਅਕਾਊਂਟ ਸੰਭਾਲੋ" ਦਸ ਸਟੋਰੀਆਂ ਹਨ।
- ਸਾਰੀਆਂ ਸਟੋਰੀਆਂ ਪਹਿਲਾਂ ਹੀ ਲਿਖਣਾ। ਅਗਲੀਆਂ ਕੁਝ ਵਿਸਥਾਰ ਵਿੱਚ ਲਿਖੋ; ਬਾਕੀ ਇੱਕ ਲਾਈਨ ਦੇ ਵਿਚਾਰ ਵਜੋਂ ਰੱਖੋ ਜਦ ਤੱਕ ਉਹਨਾਂ ਤੱਕ ਨਾ ਪਹੁੰਚੋ।
Mythex ਵਿੱਚ ਸਟੋਰੀਆਂ
Mythex ਵਿੱਚ Plan ਮੋਡ ਵਿਚਾਰ ਨੂੰ ਸਟੋਰੀਆਂ ਵਿੱਚ ਬਦਲਣ ਲਈ ਚੰਗੀ ਥਾਂ ਹੈ: ਏਜੰਟ ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਸਟੋਰੀ ਤਿਆਰ ਹੋਵੇ, ਤਾਂ Build 'ਤੇ ਜਾਓ ਅਤੇ ਉਸਨੂੰ ਪੇਸਟ ਕਰੋ, ਇੱਕ ਸੁਨੇਹੇ ਵਿੱਚ ਇੱਕ ਸਟੋਰੀ। ਹਰ ਇੱਕ ਤੋਂ ਬਾਅਦ /test ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਕਲਿੱਕ ਕਰਕੇ ਪ੍ਰਵਾਹ ਜਾਂਚ ਸਕਦਾ ਹੈ, ਅਤੇ ਜੇ ਕੋਈ ਗਲਤ ਰਸਤੇ ਜਾਵੇ ਤਾਂ ਕਿਸੇ ਵੀ ਜਵਾਬ 'ਤੇ Revert to this point ਨਾਲ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਡੌਕਸ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰੋਂਪਟ ਵੇਖੋ, ਅਤੇ ਸਾਡੀ ਗਾਈਡ AI ਐਪ ਬਿਲਡਰਾਂ ਲਈ ਪ੍ਰੋਂਪਟ ਕਿਵੇਂ ਲਿਖੀਏ।
ਯੂਜ਼ਰ ਸਟੋਰੀ ਚੈੱਕਲਿਸਟ
- ਕਿਸੇ ਖਾਸ ਕਿਸਮ ਦੇ ਯੂਜ਼ਰ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ
- ਇੱਕ ਲੋੜ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, ਡਿਜ਼ਾਈਨ ਦਾ ਨਹੀਂ
- ਅਸਲ "so that" ਕਾਰਨ ਸ਼ਾਮਲ ਹੈ
- ਤਿੰਨ ਤੋਂ ਛੇ ਜਾਂਚਣਯੋਗ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਹਨ
- ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕਿਨਾਰੇ ਵਾਲਾ ਕੇਸ ਜਾਂ ਗਲਤੀ ਕਵਰ ਕਰਦੀ ਹੈ
- ਦੱਸਦੀ ਹੈ ਕਿ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਕੀ ਹੈ
- ਇੰਨੀ ਛੋਟੀ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਵਿੱਚ ਬਣਾਈ ਅਤੇ ਟੈਸਟ ਕੀਤੀ ਜਾ ਸਕੇ
- ਬਣਨ ਤੋਂ ਬਾਅਦ ਮਾਪਦੰਡ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਜਾਂਚੇ ਗਏ
ਸਵਾਲ
ਯੂਜ਼ਰ ਸਟੋਰੀ ਦਾ ਫ਼ਾਰਮੈਟ ਕੀ ਹੈ?
ਆਮ ਟੈਮਪਲੇਟ ਇਹ ਹੈ: As a [ਕਿਸਮ ਦਾ ਯੂਜ਼ਰ], I want [ਕੋਈ ਟੀਚਾ] so that [ਕੋਈ ਕਾਰਨ]। ਇਸਦੇ ਬਾਅਦ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਆਉਂਦੇ ਹਨ, ਯਾਨੀ ਸ਼ਰਤਾਂ ਦੀ ਛੋਟੀ ਸੂਚੀ ਜੋ ਸੱਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਸਟੋਰੀ ਪੂਰੀ ਮੰਨੀ ਜਾਵੇ।
ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਕੀ ਹੁੰਦੇ ਹਨ?
ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਖਾਸ, ਜਾਂਚਣਯੋਗ ਸ਼ਰਤਾਂ ਹਨ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਯੂਜ਼ਰ ਸਟੋਰੀ ਕਦੋਂ ਪੂਰੀ ਹੈ। ਇਹ ਅਕਸਰ Given / When / Then ਵਿੱਚ ਲਿਖੇ ਜਾਂਦੇ ਹਨ: ਦਿੱਤੀ ਗਈ ਸ਼ੁਰੂਆਤੀ ਹਾਲਤ, ਜਦੋਂ ਯੂਜ਼ਰ ਕੁਝ ਕਰੇ, ਤਾਂ ਕੋਈ ਖਾਸ ਨਤੀਜਾ ਹੋਵੇ।
ਯੂਜ਼ਰ ਸਟੋਰੀ ਕਿੰਨੀ ਵੱਡੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?
ਇੰਨੀ ਛੋਟੀ ਕਿ ਇੱਕ ਬੈਠਕ ਵਿੱਚ ਬਣਾਈ ਅਤੇ ਟੈਸਟ ਕੀਤੀ ਜਾ ਸਕੇ, ਅਤੇ ਫਿਰ ਵੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੋਵੇ। ਜੇ ਕਿਸੇ ਸਟੋਰੀ ਵਿੱਚ ਪੰਜ ਜਾਂ ਛੇ ਤੋਂ ਵੱਧ ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡ ਹਨ ਜਾਂ ਕਈ ਸਕਰੀਨਾਂ ਕਵਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਯੂਜ਼ਰ ਭੂਮਿਕਾ, ਪ੍ਰਵਾਹ ਦੇ ਕਦਮ, ਜਾਂ ਸਾਦੇ ਕੇਸ ਪਹਿਲਾਂ ਅਤੇ ਕਿਨਾਰੇ ਵਾਲੇ ਕੇਸ ਬਾਅਦ ਵਿੱਚ ਦੇ ਹਿਸਾਬ ਨਾਲ ਵੰਡੋ।
ਕੀ ਯੂਜ਼ਰ ਸਟੋਰੀਆਂ AI ਨਾਲ ਬਣਾਉਣ ਵੇਲੇ ਕੰਮ ਦੀਆਂ ਹਨ?
ਹਾਂ। ਸਵੀਕ੍ਰਿਤੀ ਮਾਪਦੰਡਾਂ ਵਾਲੀ ਯੂਜ਼ਰ ਸਟੋਰੀ ਲਗਭਗ ਇੱਕ ਆਦਰਸ਼ ਪ੍ਰੋਂਪਟ ਹੈ: ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਫ਼ੀਚਰ ਕਿਸ ਲਈ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਾਂਚ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਹਰ ਸੁਨੇਹੇ ਵਿੱਚ ਇੱਕ ਸਟੋਰੀ ਭੇਜਣ ਨਾਲ AI ਦੇ ਬਦਲਾਅ ਛੋਟੇ ਅਤੇ ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਰਹਿੰਦੇ ਹਨ।