17 ਮਈ 2025·8 ਮਿੰਟ
ਪਹਿਲਾਂ ਲਾਭਦਾਇਕ ਬਣਾਓ: ਸਕੇਲ ਜਾਂ ਪਾਲਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪ੍ਰਯੋਗੀ ਗਾਈਡ
ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਪਹਿਲਾਂ ਸੱਚਮੁੱਚ ਲਾਭਦਾਇਕ ਬਣਾਉ: ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਚੁਣੋ, ਚੋਟੀਲਾ ਹੱਲ ਭੇਜੋ, ਤੇਜ਼ ਫੀਡਬੈਕ ਲਵੋ, ਅਤੇ ਸਕੇਲ/ਪਾਲਿਸ਼ ਨੂੰ ਉਸ ਵੇਲੇ ਤੱਕ ਟਾਲੋ ਜਦੋਂ ਇਹ ਪ੍ਰਵਾਨਿਤ ਹੋਵੇ।
ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਹੀਂ — ਉਪਯੋਗੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ
ਕਈ ਉਤਪਾਦਕਾਰੀ ਕੰਮ ਇਹ ਸੋਚ ਕੇ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਕਿ ਡੈਮੋ ਵਿੱਚ ਕੀ ਚਮਕਦਾ ਹੋਵੇ: ਇੱਕ ਸਲੀਕ UI, ਚਮਕੀਲੇ ਐਨੀਮੇਸ਼ਨ, ਲੰਬੀ ਫੀਚਰ ਲਿਸਟ। ਮੁਸ਼ਕਲ ਇਹ ਹੈ ਕਿ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪੰਜ ਮਿੰਟ ਲਈ ਨਕਲੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ—ਪਰ ਉਪਯੋਗਤਾ ਨੂੰ ਸੋਮਵਾਰ ਸਵੇਰੇ ਵੀ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਕਿਸੇ ਕੰਮ ਨੂੰ ਨਿਪਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੋਵੇ।
“ਉਪਯੋਗੀ” ਦਾ ਅਸਲੀ ਮਤਲਬ
ਇਸ ਗਾਈਡ ਲਈ, ਉਪਯੋਗੀ ਦਾ ਮਤਲਬ ਹੈ:
- ਇਹ ਇੱਕ ਅਸਲੀ, ਵਿਸ਼ੇਸ਼ ਸਮੱਸਿਆ ਹਲ ਕਰਦਾ ਹੈ (ਨਾ ਕਿ ਇੱਕ ਧੁੰਦਲਾ “ਲੋਕਾਂ ਨੂੰ ਸ਼ਾਇਦ ਇਹ ਚਾਹੀਦਾ ਹੋਵੇ”)।
- ਇਹ ਐਨਾ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਇਸਤੇਮਾਲ ਲਈ ਉਪਭਰੋਸਾ ਕਰੇ।
- ਇਹ ਇੱਕ ਸਪਸ਼ਟ ਕਿਸੇ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ—ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਪ੍ਰਕਾਰ ਦੇ ਉਪਭੋਗਤਾ ਅਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸਥਿਤੀ ਵਿੱਚ।
ਜੇ ਤੁਸੀਂ ਉਹ ਵਿਅਕਤੀ ਅਤੇ ਉਹ ਪਲ ਦੱਸ ਨਹੀਂ ਸਕਦੇ ਜਦੋਂ ਉਹਨੂੰ ਤੁਹਾਡੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਉਪਯੋਗਤਾ ਨਹੀਂ ਬਣਾ ਰਹੇ—ਤੁਸੀਂ ਸੰਭਾਵਨਾਵਾਂ ਬਣਾ ਰਹੇ ਹੋ।
ਕਿਉਂ ਪਾਲਿਸ਼ ਅਤੇ ਸਕੇਲ ਆਮ ਤੌਰ ਤੇ ਇੰਤਜ਼ਾਰ ਕਰ ਸਕਦੇ ਹਨ
ਪਾਲਿਸ਼ ਅਤੇ ਸਕੇਲ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ। ਇਹ ਡਿਜ਼ਾਈਨ, ਇੰਜੀਨੀਅਰਿੰਗ, QA, ਸਹਾਇਤਾ ਅਤੇ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਵਿੱਚ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਗੁਣਾ ਕਰ ਦਿੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕੋਰ ਮੁੱਲ साबित ਕੀਤੇ ਬਿਨਾਂ ਇਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਕਰੋਗੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਗਲਤ ਹੱਲ ਨੂੰ ਸੁਧਾਰਨ ਦਾ ਖਤਰਾ ਹੈ।
ਕੁਝ ਮੁਕਤ ਅਪਵਾਦ ਹਨ। ਆਪਣੇ ਵਿਸ਼ਵਾਸ ਦੇ ਮੂਲ ਤੱਤਾਂ ਨੂੰ ਟਾਲ ਨਹੀਂ ਸਕਦੇ: ਪ੍ਰਾਈਵੇਸੀ, ਸੁਰੱਖਿਆ, ਡੇਟਾ ਲਾਸ ਰੋਕਥਾਮ, ਅਤੇ "ਕੀ ਇਹ ਟੁੱਟਦਾ ਹੈ?" ਵਾਲੇ ਮਸਲੇ। ਜੇ ਨਾਕਾਮੀ ਨਾਲ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ, ਨੀਤੀ ਲੰਘ ਸਕਦੀ ਹੈ, ਜਾਂ ਭਰੋਸਾ ਖਰਾਬ ਹੋ ਸਕਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਹੱਲ ਕਰੋ।
ਇਹ ਗਾਈਡ ਕਿਸ ਲਈ ਹੈ—ਅਤੇ ਅਗਲੇ ਕਦਮ
ਇਹ ਸ਼ੁਰੂਆਤੀ-ਚਰਣ ਦੇ ਉਤਪਾਦਾਂ ਅਤੇ ਨਵੀਂ ਫੀਚਰਾਂ ਲਈ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਅਜੇ ਵੀ ਮੁੱਲ ਪਰਖ ਰਹੇ ਹੋ ਅਤੇ ਬਿਨਾਂ ਓਵਰਬਿਲਡਿੰਗ ਦੇ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ।
ਬਾਕੀ ਪੋਸਟ ਵਿੱਚ ਤੁਸੀਂ ਇਹ workflow ਫਾਲੋ ਕਰੋਗੇ:
- ਇੱਕ ਅਸਲੀ ਉਪਭੋਗਤਾ ਅਤੇ ਇੱਕ ਦਰਦਨਾਕ ਸਮੱਸਿਆ ਚੁਣੋ।
- ਸਮੱਸਿਆ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਟਾਰਗਟ ਵਿੱਚ ਬਦਲੋ।
- ਇੱਕ ਛੋਟਾ ਮੁੱਲ ਦਾ ਵਾਅਦਾ 定義 ਕਰੋ (ਤੁਹਾਡਾ MVP)।
- ਇੱਕ ਪਤਲਾ ਐਂਡ-ਟੂ-ਐਂਡ ਸਲਾਇਸ ਬਣਾਓ।
- UX ਸਧਾਰਨ ਰੱਖੋ, ਬੁਨਿਆਦੀ ਮਾਪ ਕਰੋ, ਅਸਲ ਲੋਕਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਫਿਰ ਦੁਹਰਾਓ।
ਮਕਸਦ ਵੱਡੀ ਚੀਜ਼ ਭੇਜਣਾ ਨਹੀਂ—ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਕੁਝ ਉਪਯੋਗੀ ਭੇਜਿਆ ਜਾਵੇ—ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਿਆ ਜਾਵੇ।
ਇੱਕ ਅਸਲੀ ਉਪਭੋਗਤਾ ਅਤੇ ਇੱਕ ਦਰਦਨਾਕ ਸਮੱਸਿਆ ਚੁਣੋ
ਜੇ ਤੁਸੀਂ “ਸਭ ਲਈ” ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ, ਤਾਂ ਅੰਦਰੋਂ ਅਨੁਮਾਨੀਂ ਰਹਿਣਾ ਪਵੇਗਾ। ਇਸ ਦੀ ਬਜਾਏ, ਇੱਕ ਸੰਕਰੀ ਦਰਸ਼ਕ ਚੁਣੋ ਜਿਸ ਤੱਕ ਤੁਸੀਂ ਇਸ ਮਹੀਨੇ ਪਹੁੰਚ ਸਕਦੇ ਹੋ—ਉਹ ਲੋਕ ਜੋ ਤੁਸੀਂ ਈਮੇਲ ਕਰ ਸਕਦੇ ਹੋ, ਫੋਨ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਉਤਪਾਦ ਵਰਤਦੇ ਦੇਖ ਸਕਦੇ ਹੋ।
ਉਹ ਦਰਸ਼ਕ ਚੁਣੋ ਜੋ ਪਹੁੰਚਯੋਗ ਹੋਵੇ
ਇੱਕ ਚੰਗੀ ਸ਼ੁਰੂਆਤੀ ਦਰਸ਼ਕ ਛੋਟਾ, ਵਿਸ਼ੇਸ਼ ਅਤੇ ਪਹੁੰਚਯੋਗ ਹੁੰਦਾ ਹੈ:
- ਮੌਜੂਦਾ ਗ੍ਰਾਹਕ (ਭਾਵੇਂ ਸਿਰਫ 5–20 ਲੋਕ ਹੋਣ)\
- ਤੁਹਾਡਾ ਨਿੱਜੀ ਨੈਟਵਰਕ (ਇਕ ਹੀ ਭੂਮਿਕਾ ਦੇ ਸਹਿ-ਕਾਰ)\
- ਇੱਕ ਆਨਲਾਈਨ ਕਮਿਊਨਿਟੀ ਜਿੱਥੇ ਤੁਸੀਂ ਭਾਗ ਲੈ ਸਕਦੇ ਹੋ (ਕੇਵਲ ਪ੍ਰੋਮੋਟ ਨਾ ਕਰੋ)\
- ਇੱਕ ਕੰਮ ਦੀ ਸੰਦਰਭ (ਉਦਾਹਰਣ: “ਮੁਫ਼ਤਲ ਡਿਜ਼ਾਇਨਰ ਜੋ ਮਹੀਨਾਵਾਰ ਇਨਵੌਇਸ ਕਰਦੇ ਹਨ”)
ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਇਹ ਲੋਕ ਕਿੱਥੇ ਹੁੰਦੇ ਹਨ ਜਾਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰੋਂਗੇ, ਤਾਂ ਦਰਸ਼ਕ ਅਜੇ ਵੀ ਬਹੁਤ ਵਿਆਪਕ ਹੈ।
ਦਰਦਨਾਕ ਸਮੱਸਿਆਵਾਂ ਲੱਭੋ (ਤੇਜ਼, ਸਧਾਰਨ ਸਰੋਤ)
ਤੁਹਾਨੂੰ ਵੱਡੇ ਰਿਸਰਚ ਪ੍ਰੋਜੈਕਟ ਦੀ ਲੋੜ ਨਹੀਂ। ਜਿੱਥੇ ਦਰਦ ਪਹਿਲਾਂ ਤੋਂ ਦਿੱਤਾ ਨਜ਼ਰ ਆ ਰਿਹਾ ਹੈ, ਉੱਥੇ ਸ਼ੁਰੂ ਕਰੋ:
- ਤੁਹਾਡਾ ਸਪੋਰਟ ਇਨਬਾਕਸ: ਦੁਹਰਾਈ ਗਈ ਸਵਾਲ, ਗੁੰਝਲ, “ਵਰਕਅਰਾਊਂਡ”, ਕੈਂਸਲੇਸ਼ਨ\
- ਸੇਲਜ਼ ਕਾਲਾਂ ਅਤੇ ਡੈਮੋ: ਅਵਰੋਧ ਅਤੇ “ਸਾਨੂੰ X ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਹੀ ਅਸੀਂ ਇਸਨੂੰ ਵਰਤਾਂਗੇ”\
- ਫੋਰਮ/ਕਮਿਊਨਿਟੀਜ਼: ਦੁਹਰਾਉਂਦੇ ਸ਼ਿਕਾਇਤਾਂ\
- 5–10 ਛੋਟੀ ਇੰਟਰਵਿਊ: “ਹਰ ਹਫ਼ਤੇ X ਕਰਨ ਵਿੱਚ ਸਭ ਤੋਂ ਔਖਾ ਹਿੱਸਾ ਕੀ ਹੈ?”\
- ਮੁਕਾਬਲੇ ਦੀਆਂ ਸਮੀਖਿਆਵਾਂ: ਲੋਕ ਕੀ ਤਾਰੀਫ਼/ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ (ਅਤੇ ਕਿਉਂ)
ਦੁਹਰਾਵ + ਨਤੀਜੇ ਦੇਖੋ
ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਬਾਰ-ਬਾਰ ਹੋ ਰਹੀਆਂ ਹਨ ਅਤੇ ਜਿਨ੍ਹਾਂ ਦੇ ਸਪਸ਼ਟ ਨਤੀਜੇ ਹਨ: ਸਮਾਂ ਬਰਬਾਦ ਹੋਣਾ, ਪੈਸਾ ਖੋਣਾ, ਡੈਡਲਾਈਨ ਮਿਸ ਹੋਣਾ, ਗ੍ਰਾਹਕ ਸ਼ਿਕਾਇਤਾਂ, ਪਾਲਨਾ-ਜ਼ਿੰਮੇਵਾਰੀ ਜੋਗੀ ਜੋਖਮ, ਜਾਂ ਅਸਲ ਤਨਾਅ। “ਬੇਚੈਨ” ਅਕਸਰ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ—ਖੋਜੋ “ਇਹ ਮੈਨੂੰ ਰੋਕਦਾ ਹੈ।”
ਸਮੱਸਿਆ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ (ਕੋਈ ਹੱਲ ਨਹੀਂ)
ਇੱਕ ਵਾਕ ਲਿਖ ਕੇ ਸਪਸ਼ਟਤਾ ਲਈ ਮਜ਼ਬੂਰ ਕਰੋ ਜਿਸ ਵਿੱਚ ਦਰਦ ਬਿਨਾਂ ਤੁਹਾਡੇ ਵਿਚਾਰ ਦੇ ਵਰਣਨ ਕੀਤਾ ਜਾਵੇ।
ਉਦਾਹਰਣ ਫਾਰਮੈਟ:
“[ਵਿਸ਼ੇਸ਼ ਉਪਭੋਗਤਾ] ਨੂੰ [ਕਿਰਿਆ] ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ [ਬੰਧਨ], ਜਿਸ ਨਾਲ [ਨੁਕਸਾਨ] ਹੁੰਦਾ ਹੈ।”
ਜੇ ਤੁਸੀਂ ਸਾਫ਼-ਸੁਥਰੇ ਤੌਰ 'ਤੇ ਉਹ ਵਾਕ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਤਿਆਰ ਨਹੀਂ ਹੋ—ਤੁਸੀਂ ਅਜੇ ਵੀ ਸਮੱਸਿਆ ਲੱਭ ਰਹੇ ਹੋ।
ਸਮੱਸਿਆ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਟਾਰਗਟ ਵਿੱਚ ਬਦਲੋ
ਇੱਕ ਉਪਯੋਗੀ ਉਤਪਾਦ ਉਸ ਸਮੱਸਿਆ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਲਕੜੀ ਮਾਰ ਸਕਦੇ ਹੋ। ਜੇ ਸਮੱਸਿਆ ਧੁੰਦਲੀ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ MVP ਵੀ ਧੁੰਦਲਾ ਹੋਵੇਗਾ—ਅਤੇ ਫੀਡਬੈਕ ਨਹੀਂ ਦੱਸੇਗਾ ਕਿ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ।
“ਚੰਗੀ” ਸਮੱਸਿਆ ਲਈ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ
ਕੋਈ ਸਮੱਸਿਆ ਉਸ ਵੇਲੇ ਬਣਾਉਣ ਯੋਗ ਹੈ ਜਦੋਂ ਇਹ:
- ਤਤਕਾਲੀ/ਅਜੀਕਤ: ਲੋਕ ਇਸਨੂੰ ਅਕਸਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਤਰਕੀਬ ਅਜਮਾਉਂਦੇ ਹਨ (ਭਲੇ ਹੀ ਔਖੇ ਤਰੀਕੇ)\
- ਵਿਸ਼ੇਸ਼: ਤੁਸੀਂ ਇਕ ਪਲ, ਵਰਕਫਲੋ, ਅਤੇ ਨਤੀਜੇ ਦੀ ਨੁਕਤਾ ਦੱਸ ਸਕਦੇ ਹੋ\
- ਟੈਸਟ ਕਰਨ ਯੋਗ: ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ ਪ੍ਰਯੋਗ ਚਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ “ਬਿਹਤਰ” ਕਿਉਂ ਹੈ
ਜੇ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਕੌਣ ਇਸਨੂੰ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਕਦੋਂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਦਾ ਉਹਨਾਂ ਲਈ ਕੀ ਖ਼ਰਚ ਹੈ, ਤਾਂ ਇਹ ਅਜੇ ਟਾਰਗਟ ਨਹੀਂ ਹੈ।
ਧੁੰਦਲਾ ਬਨਾਮ ਸਪਸ਼ਟ ਸਮੱਸਿਆ ਬਿਆਨ
ਧੁੰਦਲਾ: “ਉਪਭੋਗਤਾ ਇੱਕ ਬਿਹਤਰ ਡੈਸ਼ਬੋਰਡ ਚਾਹੁੰਦੇ ਹਨ।”
ਸਪਸ਼ਟ: “ਟੀਮ ਲੀਡ ਹਰ ਸੋਮਵਾਰ 30–45 ਮਿੰਟ ਤਿੰਨ ਟੂਲਜ਼ ਤੋਂ ਨੰਬਰ ਖਿੱਚ ਕੇ ਸਪਤਾਹਿਕ ਪ੍ਰਗਤੀ ਰਿਪੋਰਟ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਫਿਰ ਵੀ ਓਵਰਡਿਊ ਕੰਮ ਨਿਰਧਾਰਤ ਕਰਨਾ ਭੁੱਲ ਜਾਂਦਾ ਹੈ।”
ਧੁੰਦਲਾ: “ਓਨਬੋਰਡਿੰਗ ਗੁੰਝਲਦਾਰ ਹੈ।”
ਸਪਸ਼ਟ: “ਨਵੇਂ ਗਾਹਕ ਆਪਣਾ ਡੇਟਾ ਸੋర్స్ ਖੁਦ ਜੋੜ ਨਹੀਂ ਪਾ ਰਹੇ; 6 ਵਿੱਚੋਂ 10 ਪਹਿਲੇ 15 ਮਿੰਟ ਵਿੱਚ ਸਪੋਰਟ ਚੈਟ ਖੋਲ੍ਹਦੇ ਹਨ।”
ਇੱਕ ਸਪਸ਼ਟ ਬਿਆਨ ਵਿੱਚ ਉਪਭੋਗਤਾ, ਪਲ, ਟਕਰਾਅ, ਅਤੇ ਅਸਰ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ।
"ਮੁਕੰਮਲ" ਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
ਆਪਣੇ ਅੰਦਰੂਨੀ ਮੀਲਪੱਥਰਾਂ (ਜਿਵੇਂ “ਫੀਚਰ ਭੇਜਿਆ”) ਨੂੰ ਛੱਡ ਦਿਓ। "ਮੁਕੰਮਲ" ਨੂੰ ਉਪਭੋਗਤਾ ਨਤੀਜੇ ਦੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
- “ਇੱਕ ਟੀਮ ਲੀਡ 5 ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਸਪਤਾਹਿਕ ਰਿਪੋਰਟ ਤਿਆਰ ਕਰ ਸਕੇ ਬਿਨਾਂ ਟੂਲ ਬਦਲਣ ਦੇ।”\
- “ਨਵਾਂ ਗਾਹਕ ਆਪਣਾ ਡੇਟਾ ਸੋర్స్ ਇੱਕ ਸੈਸ਼ਨ ਵਿੱਚ ਜੋੜ ਸਕੇ, ਸਹਾਇਤਾ ਨਾਲ ਸੰਪਰਕ ਕੀਤੇ ਬਿਨਾਂ।”
ਤੁਸੀਂ ਕੀ ਮਾਪੋਗੇ (ਸਧਾਰਨ ਪਰ ਅਰਥਪੂਰਨ)
ਇੱਕ ਗੁਣਾਤਮਕ ਸੰਗਤਿ ਅਤੇ ਕੁਝ ਹਲਕੇ ਮੈਟਰਿਕ ਵਰਤੋ:
- ਗੁਣਾਤਮਕ: “ਕੀ ਇਹ ਮਦਦਗਾਰ ਸੀ?” + “ਕਿਹੜਾ ਹਿੱਸਾ ਮੁਸ਼ਕਲ ਲੱਗਾ?” (ਇਨ-ਐਪ ਪ੍ਰਾਂਪਟ ਜਾਂ 10 ਮਿੰਟ ਦੀਆਂ ਕਾਲਾਂ)\
- ਮੈਟਰਿਕਸ: ਪਹਿਲੀ ਕਾਮਯਾਬੀ ਤੱਕ ਸਮਾਂ, % ਜੋ ਨਿਰਧਾਰਿਤ ਨਤੀਜੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਬੁਨਿਆਦੀ ਫੇਲ ਸਿਗਨਲ (ਕਦਮ X 'ਤੇ ਡਰੌਪ-ਆਫ, ਉਸ ਫਲੋ ਲਈ ਸਪੋਰਟ ਟਿਕਟ)
ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਟਾਰਗਟ ਹੈ ਜਿਸ ਵੱਲ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣ ਸਕਦੇ ਹੋ ਅਤੇ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਛੋਟਾ ਮੁੱਲ ਵਾਅਦਾ ਤਿਆਰ ਕਰੋ (ਤੁਹਾਡਾ MVP)
MVP "ਛੋਟਾ ਉਤਪਾਦ" ਨਹੀਂ—ਇਹ ਇੱਕ ਛੋਟਾ ਵਾਅਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿਚ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਸਧਾਰਨ ਫਰਮੇਟ:
“X ਮਿੰਟਾਂ ਵਿੱਚ, ਤੁਸੀਂ Y ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ Z ਦੇ।”
ਉਦਾਹਰਣ: “10 ਮਿੰਟ ਵਿੱਚ, ਤੁਸੀਂ ਪਹਿਲੀ ਕਲਾਇਂਟ ਕਾਲ ਸ਼ਡਿਊਲ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਬੈਕ-ਅਟ-ਫੋਰਥ ਈਮੇਲਾਂ ਦੇ।” ਮਕਸਦ ਫੀਚਰਾਂ ਨੂੰ ਵੇਰਵਾ ਕਰਨਾ ਨਹੀਂ—ਨਤੀਜੇ ਅਤੇ ਤੁਸੀਂ ਕਿਹੜੀ ਰਗੜ ਹਟਾ ਰਹੇ ਹੋ ਇਹ ਦੱਸਣਾ ਹੈ।
ਸਭ ਤੋਂ ਛੋਟਾ ਐਂਡ-ਟੂ-ਐਂਡ ਵਰਕਫਲੋ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
ਤੁਹਾਡੇ MVP ਵਿੱਚ "ਮੈਂ ਆਇਆ" ਤੋਂ "ਮੈਨੂੰ ਨਤੀਜਾ ਮਿਲਿਆ" ਤੱਕ ਪੂਰਾ ਰਸਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਹਰ ਕਦਮ ਸਧਾਰਨ ਹੋਵੇ।
ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ: ਘੱਟੋ-ਘੱਟ ਐਂਡ-ਟੂ-ਐਂਡ ਵਰਕਫਲੋ ਜੋ ਮੁੱਲ ਵਾਅਦੇ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਕੀ ਹੈ?
- ਐਂਟਰੀ: ਉਪਭੋਗਤਾ ਕਿਵੇਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ?\
- ਐਕਸ਼ਨ: ਉਹ ਕੀ ਕਰਦੇ ਹਨ (ਵੋ ਇੱਕ ਮੁੱਖ ਕਰਤੱਬ)?\
- ਆਊਟਪੁਟ: ਉਹ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜੋ ਸਫਲਤਾ ਦੀ ਪੁਰਸਟੀ ਕਰਦਾ ਹੈ?\
- ਫਾਲੋ-ਅੱਪ: ਕੀ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਮੁੱਲ ਟਿਕੇ ਰਹੇ?
ਜੇ ਕਿਸੇ ਵੀ ਕਦਮ ਦੀ ਘਾਟ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਲੂਪ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ—ਅਤੇ ਤੁਸੀਂ ਨਹੀਂ ਸਿੱਖ ਸਕਦੇ ਕਿ ਕੀ ਟੁੱਟਿਆ।
ਕੋਰ ਵਰਕਫਲੋ ਬਨਾਮ ਨਾਇਸ-ਟੂ-ਹੈਵ
ਬਹੁਤ ਸਖਤੀ ਨਾਲ ਕੋਰ ਚੀਜ਼ਾਂ ਦੀ ਪਛਾਣ ਕਰੋ:
- ਕੋਰ ਵਰਕਫਲੋ: ਉਹ ਕਦਮ ਜੋ ਵਾਅਦੇ ਨੂੰ ਪਹਿਲੀ ਵਾਰੀ ਪੂਰਾ ਕਰਨ ਲਈ ਲਾਜ਼ਮੀ ਹਨ।\
- ਨਾਇਸ-ਟੂ-ਹੈਵ: ਕਿਹੇ ਵੀ ਚੀਜ਼ਾਂ ਜੋ ਸਹੂਲਤ, ਗਤੀ, ਜਾਂ ਸੁੰਦਰਤਾ ਵਧਾਉਂਦੀਆਂ ਹਨ ਪਰ ਵਾਅਦੇ ਨੂੰ ਬਦਲਦੀਆਂ ਨਹੀਂ।
ਨਾਇਸ-ਟੂ-ਹੈਵ ਅਕਸਰ ਤੁਰੰਤ ਜਰੂਰੀ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ (ਟੈਂਪਲੇਟ, ਥੀਮ, ਇੰਟੀਗਰੇਸ਼ਨ)। ਉਨ੍ਹਾਂ ਨੂੰ "ਬਾਅਦ" ਦੀ ਲਿਸਟ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਸਕੋਪ ਚੁਪ-ਚਾਪ ਫੈਲ ਨਾ ਹੋਵੇ।
ਧਾਰਣਾ ਲਿਖੋ
ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਚੀਜ਼ਾਂ ਲਿਖੋ ਜੋ ਸਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:
- ਉਪਭੋਗਤਾ ਪਹਿਲਾ ਕਦਮ ਸਮਝ ਲੈਣਗੇ ਬਿਨਾਂ ਕਾਲ ਦੇ।\
- ਆਊਟਪੁਟ ਪਰਯਾਪਤ ਕੀਮਤੀ ਹੈ ਤਾਂ ਕਿ ਇਹ "ਸਫਲਤਾ" ਗਿਣੀ ਜਾਵੇ।\
- ਤੁਸੀਂ ਲੋੜੀਂਦਾ ਡੇਟਾ/ਟੂਲ ਪਹੁੰਚ ਸਕਦੇ ਹੋ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ।\
- ਉਪਭੋਗਤਾ ਇੱਕ ਵਾਰ ਜਿੱਤ ਤੋਂ ਬਾਅਦ ਇਸ ਵਰਕਫਲੋ ਨੂੰ ਦੁਹਰਾਉਣਗੇ (ਜਾਂ ਸਾਂਝਾ ਕਰਨਗੇ)।
ਇਹ ਧਾਰਣਾਂ ਤੁਹਾਡੀ ਸ਼ੁਰੂਆਤੀ ਟੈਸਟ ਯੋਜਨਾ ਬਣਦੀਆਂ ਹਨ—ਅਤੇ MVP ਨੂੰ ਸੱਚੇ ਰੱਖਦੀਆਂ ਹਨ।
ਪਹਿਲਾ ਪਤਲਾ ਏਂਡ-ਟੂ-ਏਂਡ ਸਲਾਇਸ ਬਣਾਓ
"ਥਿਨ ਸਲਾਇਸ" ਇੱਕ ਪੂਰਾ ਰਸਤਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਅਸਲ ਉਪਭੋਗਤਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ, ਮੁੱਖ ਕੰਮ ਕਰ ਸਕਦਾ, ਅਤੇ ਨਤੀਜੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ—ਬਿਨਾਂ ਅਧੂਰੇ ਹੋਣ ਦੇ। ਇਹ ਇਕ ਪ੍ਰੋਟੋਟਾਈਪ ਨਹੀਂ ਜੋ "ਲੱਗਦਾ" ਪੂਰਾ ਹੈ; ਇਹ ਇੱਕ ਵਰਕਫਲੋ ਹੈ ਜੋ "ਕੰਮ" ਕਰਦੀ ਹੈ।
ਇੱਕ ਪਤਲੇ ਸਲਾਇਸ ਦਾ ਅਸਲ ਮਤਲਬ
ਕਿਰਿਆਵਾਂ 'ਤੇ ਸੋਚੋ, ਸਕਰੀਨਾਂ 'ਤੇ ਨਹੀਂ। ਇੱਕ ਪਤਲਾ ਸਲਾਇਸ:
- ਇੱਕ ਉਪਭੋਗਤਾ ਟਾਈਪ (ਸਭ ਤੋਂ ਆਸਾਨ, ਆਮ, ਜਾਂ ਤਤਕਾਲੀ)\
- ਇੱਕ ਕਾਰਜ (ਉਹ ਇਕ ਕਾਰਨ ਜਿਸ ਲਈ ਉਹ ਆਏ)\
- ਇੱਕ ਸਫਲ ਅੰਤ-ਰੇਖਾ (ਇੱਕ ਨਤੀਜਾ ਜੋ ਉਹ ਵਰਤ ਸਕਦੇ)
ਉਦਾਹਰਣ: “ਖਾਤਾ ਬਣਾਓ → ਇੱਕ ਬੇਨਤੀ ਜਮ੍ਹਾਂ ਕਰੋ → 5 ਮਿੰਟ ਵਿੱਚ ਆਊਟਪੁਟ ਪ੍ਰਾਪਤ ਕਰੋ।” ਜੇ ਕੋਈ ਕਦਮ ਪੂਰਾ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਸਲਾਇਸ ਨਹੀਂ—ਟੁਕੜੇ ਹਨ।
ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਪਕਰਨ ਰੀਯੂਜ਼ ਕਰੋ
ਸਲਾਇਸ ਨੂੰ ਏਂਡ-ਟੂ-ਏਂਡ ਚਲਾਉਣ ਲਈ ਜਿੰਨਾ ਹੋ ਸਕੇ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਉਧਾਰ ਲਓ। ਸ਼ੁਰੂਆਤੀ ਰੂਪ ਵਿੱਚ "ਚੰਗੇ-ਕਾਫੀ" ਛੋਟੇ ਰਾਹ:
- ਪੇਮੈਂਟਸ: Stripe Checkout ਵਿਸ਼ੇਸ਼ ਬਿਲਿੰਗ ਦੇ ਥਾਂ\
- ਫਾਰਮ ਅਤੇ ਇੰਟੇਕ: Typeform/Tally ਬਦਲ ਵਿੱਚ\
- ਡੇਟਾਬੇਸ/ਐਡਮਿਨ: Airtable/Notion ਪਹਿਲੇ ਬੈਕ-ਅਫਿਸ ਲਈ\
- ਆਟੋਮੇਸ਼ਨ: Zapier/Make ਸੂਚਨਾ ਅਤੇ ਰਾਊਟਿੰਗ ਲਈ\
- ਸ਼ੈਡਿਊਲਿੰਗ: ਕਿਸੇ ਵੀ ਸਮੇਂ-ਆਧਾਰਤ ਹੈਂਡਆਫ ਲਈ Calendly
ਜੇ ਤੁਸੀਂ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਇਕ ਹੋਰ "ਉਧਾਰ ਲਿਆ ਇਨਫਰਾਸਟ੍ਰਕਚਰ" ਹੋ ਸਕਦਾ ਹੈ: ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਇੱਕ ਕੰਮ ਕਰਦੀ React ਵੈੱਬ ਐਪ (Go + PostgreSQL ਬੈਕਐਂਡ) ਤੈਅ ਕਰ ਸਕਦੇ ਹੋ, ਜਰੂਰਤ ਪੈਣ 'ਤੇ Flutter ਮੋਬਾਈਲ ਕੰਪੈਨਿਯਨ ਘੁਮਾਉ ਸਕਦੇ ਹੋ, ਅਤੇ ਦੁਹਰਾਉਂਦੇ ਸਮੇਂ snapshots/rollback ਵਰਤ ਸਕਦੇ ਹੋ। ਨੁਕਸ ਦਾ ਮਕਸਦ ਇੱਕੋ ਹੀ ਹੈ: ਸਲਾਇਸ ਭੇਜੋ, ਸਿੱਖੋ, ਫਿਰ ਕਦਮ ਬਦਲੋ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਕਮਾਏ ਹੋ।
ਫਰਮਾਨੀ ਕੀ ਹੱਥੋਂ-ਹੱਥ ਹੋ ਸਕਦਾ ਹੈ
ਇੱਕ ਪਤਲਾ ਸਲਾਇਸ ਪਿੱਛੇ ਹਿੱਸੇ ਵਿੱਚ ਹਿੱਸੇਦਾਰੀ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਠੀਕ ਹੈ ਜੇ ਉਪਭੋਗਤਾ ਇੱਕ ਬਟਨ ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ:
- ਜਮ੍ਹਾਂ ਕੀਤੀਆਂ ਜਾਣਕਾਰੀਆਂ ਨੂੰ ਇੱਕ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਿੱਚ ਸਮੀਖਿਆ ਕਰੋ,\
- ਇੱਕ ਸਕ੍ਰਿਪਟ ਹੱਥੋਂ ਚਲਾਓ,\
- ਨਤੀਜਾ ਈਮੇਲ ਕਰੋ,\
- ਜਾਂ ਇਕ-ਵਾਰ ਵਰਕਫਲੋ ਟ੍ਰਿਗਰ ਕਰੋ।
ਜਦ ਤੱਕ ਉਪਭੋਗਤਾ ਦਾ ਅਨੁਭਵ ਲਗਾਤਾਰ ਹੈ ਅਤੇ ਨਤੀਜਾ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਪਹੁੰਚਦਾ ਹੈ, ਹੱਥੋਂ-ਹੱਥ ਕਦਮ ਇੱਕ ਯਥਾਰਥ ਪੁਲ ਹਨ।
ਉਹ ਫੰਦੇ ਜੋ ਸਲਾਇਸ ਨੂੰ ਮਾਰ ਦਿੰਦੇ ਹਨ
ਸਕੋਪ ਕ੍ਰੀਪ ਨੂੰ ਧਿਆਨ ਰੱਖੋ ਜੋ "ਸਿਰਫ਼ ਪੂਰਾ ਹੋਣ" ਵਾਂਗ ਲੱਗਦਾ ਹੈ:
- ਪਹਿਲੀ ਸਫਲਤਾ ਤੋਂ ਪਹਿਲਾਂ ਬਹੁਤ ਸਾਰੇ ਸੈਟਿੰਗز\
- ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾ ਟਾਈਪ (“ਸਾਨੂੰ ਐਡਮਿੰਸ, ਟੀਮਾਂ, ਏਜੰਸੀਜ਼ ਵੀ ਚਾਹੀਦੀਆਂ ਹਨ…”)\
- ਬਹੁਤ ਸਾਰੇ ਪੇਜ (“ਮਾਰਕੀਟਿੰਗ ਸਾਈਟ, ਡੈਸ਼ਬੋਰਡ, ਰਿਪੋਰਟਸ, ਹੇਲਪ ਸੈਂਟਰ…”)\
- ਬਹੁਤ ਸਾਰੀਆਂ ਸ਼ਾਖਾਂ (“ਜੇ ਉਹ A ਚੁਣਦੇ ਹਨ, ਫਿਰ…”) ਦੀ ਬਜਾਏ ਇੱਕ ਡਿਫੋਲਟ ਪਥ
ਉਸ ਸਭ ਤੋਂ ਛੋਟੇ ਐਂਡ-ਟੂ-ਐਂਡ ਰਸਤੇ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜੋ ਅਸਲ ਮੁੱਲ ਦਿੰਦਾ ਹੈ—ਅਤੇ ਪਹਿਲਾਂ ਉਹੀ ਭੇਜੋ।
UX ਸਧਾਰਨ ਰੱਖੋ: ਪਹਿਲੀ ਵਰਤੋਂ 'ਤੇ ਸਮਝਣਯੋਗ ਬਣਾਓ
ਕ੍ਰੈਡਿਬਿਲਿਟੀ ਨਾਲ ਲੌਂਚ ਕਰੋ
ਟੈਸਟ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਤੁਹਾਡੇ MVP ਨੂੰ ਅਸਲੀਅਤ محسوس ਕਰਨ ਦੇਣ ਦਿਓ ਅਤੇ UX ਨੂੰ ਸਾਫ਼ ਤੇ ਘੱਟ ਰੱਖੋ।
ਜੇ ਕੋਈ ਤੁਹਾਡੀ ਉਤਪਾਦ ਨੂੰ ਪਹਿਲੀ ਮਿੰਟ ਵਿੱਚ ਸਮਝ ਨਹੀਂ ਸਕਦਾ, ਉਹ ਮੁੱਲ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੇਗਾ ਜੋ ਤੁਸੀਂ ਬਣਾਇਆ। ਸ਼ੁਰੂਆਤੀ UX ਸਟਾਈਲ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਹਟਾਉਣ ਬਾਰੇ ਹੈ।
ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫਲੋ ਦਾ ਮਸੌਦਾ ਬਣਾਓ
ਬੇਸਿਕ "ਹੈਪੀ ਪਾਥ" ਅਤੇ ਇੱਕ-ਦੋ ਆਮ ਡੈਟੋਰ (ਜਿਵੇਂ ਟਾਈਪੋ ਸਹੀ ਕਰਨਾ ਜਾਂ ਪਿੱਛੇ ਜਾਣا) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਤੁਸੀਂ ਇਹ ਕਾਗਜ਼ ਸਕੈਚਾਂ, ਸਟੀਕੀ ਨੋਟਸ, ਜਾਂ ਸਧਾਰਨ ਵਾਇਰਫ੍ਰੇਮ ਟੂਲ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਸੁਝਾਅ: 5–7 ਸਕਰੀਨਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ। ਜੇ ਹੋਰ ਦੀ ਲੋੜ ਪੈ ਰਹੀ ਹੈ ਤਾਂ ਮੰਨੋ ਕਿ ਫਲੋ MVP ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਰ ਰਿਹਾ ਹੈ।
ਰਿਸ਼ਤੇਦਾਰ ਲੇਬਲ ਵਰਤੋ, ਨੈਟਿਵ ਨਹੀਂ
ਸਪਸ਼ਟਤਾ ਨੂੰ ਦਿੱਖ ਤੇ ਤਰਜੀਹ ਦਿਓ। ਬਟਨ ਅਤੇ ਫੀਲਡ ਸਹੀ ਤੌਰ 'ਤੇ ਦੱਸਣ:
- “Create invoice” ਦੀ ਥਾਂ “ਚਲੋ ਇਨਵੌਇਸ ਬਣਾਓ” ਦੀ ਵਰਤੋਂ ਕਰੋ\
- “Send to client” ਦੀ ਥਾਂ “ਕਲਾਇੰਟ ਨੂੰ ਭੇਜੋ”\
- “Email address” ਦੀ ਥਾਂ “ਈਮੇਲ ਪਤਾ” ਦਾ ਪ੍ਰਯੋਗ ਕਰੋ
ਸੰਦੇਹ ਹੋਵੇ ਤਾਂ ਲੇਬਲ ਨੂੰ ਲੰਮਾ ਅਤੇ ਸਪਸ਼ਟ ਰੱਖੋ। ਬਾਅਦ ਵਿੱਚ ਤੁਸੀਂ ਛਾਂਟ ਸਕਦੇ ਹੋ।
ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਗਲਤੀਆਂ ਰੋਕੋ
ਸ਼ੁਰੂਆਤੀ ਉਪਭੋਗਤਾ ਆਮ ਤੌਰ ਤੇ ਨਿਯਤ ਤਰ੍ਹਾਂ ਦੀਆਂ ਭੁੱਲਾਂ ਕਰਨਗੇ: ਲਾਜ਼ਮੀ ਫੀਲਡ ਛੱਡ ਦੇਣਾ, ਗਲਤ ਫਾਰਮੈਟ ਵਿੱਚ ਦਾਖਲ ਕਰਨਾ, ਗਲਤ ਕਾਰਵਾਈ 'ਤੇ ਕਲਿੱਕ ਕਰਨਾ। ਸਧਾਰਨ ਗਾਰਡਰੇਲ ਜੋੜੋ:
- ਇਨਲਾਈਨ ਹਿੰਟ (ਉਦਾਹਰਣ ਫਾਰਮੈਟ: “[email protected]”)\
- ਸਪਸ਼ਟ ਲਾਜ਼ਮੀ ਨਿਸ਼ਾਨ ਤੇ ਮਨੁੱਖੀ ਭਾਸ਼ਾ (“ਕਿਰਪਾ ਕਰਕੇ ਡਿਊ ਤਾਰੀਖ ਜੋੜੋ”)\
- ਨਕੀਲੀ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀ (“ਡ੍ਰਾਫਟ ਮਿਟਾਉਣ?”)\
- ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ (ਸਭ ਤੋਂ ਆਮ ਵਿਕਲਪ ਪਹਿਲਾਂ ਚੁਣਿਆ ਹੋਇਆ)
ਉਪਯੋਗਿਤਾ ਪ੍ਰਭਾਵਤ ਕਰਨ ਵਾਲੇ ਐਕਸੈਸਬਿਲਿਟੀ ਬੁਨਿਆਦੀ ਮਾਮਲੇ
ਤੁਹਾਨੂੰ ਪਰਫੈਕਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਲੋਕਾਂ ਨੂੰ ਉਤਪਾਦ ਵਰਤਣ ਤੋਂ ਰੋਕੋ ਨਾ:
- ਲੇਖ ਪੜ੍ਹਣਯੋਗ ਹੈ (ਸਾਈਜ਼ ਅਤੇ spacing)\
- ਲੇਖ ਅਤੇ ਪਿਛੋਕੜ ਵਿਚ ਚੰਗਾ ਕਾਂਟ੍ਰਾਸਟ\
- ਬਟਨ ਬਟਨ ਵਰਗੇ ਲੱਗਣ ਤੇ ਫੋਕਸ ਸਟੇਟ ਸਪਸ਼ਟ ਹੋਣ
ਸਧਾਰਨ, ਸਮਝ ਆਉਂਣ ਵਾਲਾ UX ਇੱਕ ਫੀਚਰ ਹੈ। ਇਹ ਉਹੀ ਹੈ ਜੋ ਤੁਹਾਡੇ "ਥਿਨ ਸਲਾਇਸ" ਨੂੰ ਪਹਿਲੀ ਵਰਤੋਂ 'ਤੇ ਮੁੱਲ ਦੇਂਦਾ ਹੈ।
ਬੁਨਿਆਦੀ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰੋ ਅਤੇ ਤੇਜ਼ ਫੀਡਬੈਕ ਇਕੱਠਾ ਕਰੋ
ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੇਖ ਸਕਦੇ ਕਿ ਲੋਕ ਕਿੱਥੇ ਫੱਸ ਰਹੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ਾਂ ਨੂੰ ਠੀਕ ਕਰਨਗੇ। ਸ਼ੁਰੂਆਤੀ ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਵੱਡੇ ਐਨਾਲੇਟਿਕਸ ਪ੍ਰੋਜੈਕਟ ਦੀ ਲੋੜ ਨਹੀਂ—ਇਹ ਕੁਝ ਸਵਾਲਾਂ ਦਾ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਜਵਾਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਪਹਿਲਾ ਕੀ ਮਾਪਣਾ ਹੈ (ਤਿੰਨ ਸਿਗਨਲ)
ਆਪਣੇ ਪਤਲੇ ਸਲਾਇਸ ਲਈ ਇੱਕ ਸਧਾਰਨ ਫਨਲ ਸ਼ੁਰੂ ਕਰੋ:
- ਐਕਟੀਵੇਸ਼ਨ: ਉਹ ਲਹਜ਼ਾ ਜਦੋਂ ਨਵਾਂ ਉਪਭੋਗਤਾ ਪਹਿਲੀ ਅਸਲ ਕਦਰ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ (ਸਿਰਫ਼ “ਖਾਤਾ ਬਣਾਇਆ” ਨਹੀਂ)। ਉਦਾਹਰਨ: “ਇੱਕ ਫਾਇਲ ਇੰਪੋਰਟ ਕੀਤੀ,” “ਪਹਿਲਾ ਟਾਸ্ক ਜੋੜਿਆ,” “ਪਹਿਲਾ ਡ੍ਰਾਫਟ ਜਨਰੇਟ ਕੀਤਾ।”\
- ਕੰਪਲੀਸ਼ਨ: ਉਪਭੋਗਤਾ ਮੁੱਖ ਕੰਮ ਐਂਡ-ਟੂ-ਐਂਡ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ: “ਇਨਵੌਇਸ ਭੇਜਿਆ,” “ਲਿੰਕ ਸਾਂਝਾ ਕੀਤਾ,” “ਮੀਟਿੰਗ ਬੁੱਕ ਕੀਤੀ।”\
- ਦੁਹਰਾਉਣ ਵਾਲੀ ਵਰਤੋਂ: ਉਪਭੋਗਤਾ ਮੁੜ ਆਉਂਦਾ ਅਤੇ ਇਕ ਸਮੇਂ ਖਿੜਕੀ (ਅਕਸਰ 7 ਜਾਂ 14 ਦਿਨ) ਵਿੱਚ ਫਿਰੋਂ ਕੰਮ ਪੂਰਾ ਕਰਦਾ ਹੈ।
ਪਰਿਭਾਸ਼ਾਵਾਂ ਇੱਕ ਥਾਂ ਲਿਖੀਆਂ ਰੱਖੋ ਤਾਂ ਟੀਮ ਇੱਕੋ ਹੀ ਗੱਲ ਕਰੇ।
ਅਸਲ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਲੋਗਿੰਗ
ਤੁਹਾਨੂੰ ਪੂਰੇ ਡੈਸ਼ਬੋਰਡ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਤੁਹਾਨੂੰ ਅਜੇਹੀਆਂ breadcrumbs ਲੋੜੀਂਦੀਆਂ ਹਨ ਜੋ ਡੀਬੱਗ ਕਰਨ ਯੋਗ ਹੋਣ:
- ਹਰ ਫਨਲ ਕਦਮ ਲਈ ਮੁੱਖ ਘਟਨਾਵਾਂ (ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਯੂਜ਼ਰ/ਸੈਸ਼ਨ ID ਨਾਲ)\
- ਗਲਤੀਆਂ (API ਫੇਲਿਅਰ, ਵੈਲੀਡੇਸ਼ਨ error, timeout) ਇੱਕ ਛੋਟੇ ਸੰਦੇਸ਼ ਨਾਲ\
- ਸੰਦਰਭ ਜੋ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਮਝਾਏ (ਪ੍ਰੋਫ਼ਾਈਲ, ਡਿਵਾਈਸ ਟਾਈਪ, ਐਪ ਵਰਜਨ, ਅਤੇ ਉਹ ਵਸਤੂ ID ਜਿਸ 'ਤੇ ਉਹ ਕੰਮ ਕਰ ਰਹੇ ਸਨ)
ਲਕਸ਼ਯ ਇਹ ਹੋਵੇ ਕਿ “ਕੀ ਅਸੀਂ ਜੋ ਵਾਪ੍ਹਇਆ ਉਸਨੂੰ ਦੁਹਰਾਉ ਸਕਦੇ ਹਾਂ?” ਨਾ ਕਿ “ਹਰ ਚੀਜ਼ ਟ੍ਰੈਕ ਕਰੋ।” ਫੈਸਲਾ ਪਹਿਲਾਂ ਕਰੋ ਕਿ ਕੌਣ logs ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਅਤੇ ਕੁੱਲ ਕਿੰਨਾ ਸਮਾਂ ਰੱਖਿਆ ਜਾਵੇ—ਭਰੋਸਾ ਇੱਥੇ ਬਣਦਾ ਹੈ।
“ਕਿਉਂ” ਸੁਣਨ ਲਈ ਹਲਕੇ ਤਰੀਕੇ
ਗਿਣਤੀ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿੱਥੇ; ਗੁਣਾਤਮਕ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਉਂ।
- ਸੈਸ਼ਨ ਨੋਟਸ: ਸਪੋਰਟ ਚੈਟ ਜਾਂ ਕਾਲ ਤੋਂ 10 ਮਿੰਟ ਬਾਅਦ ਲਿਖੋ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਕੀ ਕੀਤਾ, ਕਿੱਥੇ ਫ਼ਸੇ, ਅਤੇ ਉਹ ਕੀ ਉਮੀਦ ਕਰ ਰਹੇ ਸਨ।\
- 5-ਪ੍ਰਸ਼ਨ ਸਰਵੇ: ਪੂਰਾ ਹੋਣ ਜਾਂ ਫੇਲ ਹੋਣ ਦੇ ਬਾਅਦ:\
- ਤੁਸੀਂ ਕੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ?\
- ਕੀ ਤੁਸੀਂ ਸਫਲ ਹੋਏ?\
- ਕੀ ਚੀਜ਼ ਨੇ ਤੁਹਾਨੂੰ ਰੋਕਿਆ?\
- ਕੀ ਨੇਰਿਹਾ ਕਰਕੇ ਹੈਰਾਨ ਕੀਤਾ?\
- ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਕੀ ਸੁਧਾਰ ਕਰੀਏ?\
- ਛੋਟੀਆਂ ਕਾਲਾਂ: 15 ਮਿੰਟ, ਸਕਰੀਨ-ਸ਼ੇਅਰਿੰਗ, ਉਹਨਾਂ ਨੂੰ ਮੁੱਖ ਫਲੋ ਕਰਨ ਦੇਖੋ।
ਫੀਡਬੈਕ ਲੂਪ ਦੀ ਰਿਥਮ ਤੇ ਮਾਲਕੀ
ਇੱਕ ਐਸਾ ਰਿਥਮ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਲਗਾਤਾਰ ਰੱਖ ਸਕੋ:
- ਰੋਜ਼ਾਨਾ (10–15 ਮਿੰਟ): ਗਲਤੀਆਂ, ਡਰੌਪ-ਆਫ, ਅਤੇ 3–5 ਉਪਭੋਗਤਾ ਟਿੱਪਣੀਆਂ ਦੇਖੋ।\
- ਸਪਤਾਹਿਕ (30–45 ਮਿੰਟ): ਉਹ 1–3 ਠੀਕ-ਕਰਨ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਫੈਸਲ ਕਰੋ ਜੋ ਮੁੱਲ ਨੂੰ ਅਨਲੌਕ ਕਰਦੀਆਂ ਹਨ।
ਇੱਕ ਸਪਸ਼ਟ ਮਾਲਕ (ਅਕਸਰ PM ਜਾਂ ਫਾਊਂਡਰ) ਨਿਯੁਕਤ ਕਰੋ ਜੋ ਇਨਪੁੱਟ ਇਕੱਠੇ ਕਰੇ, ਇੱਕ ਛੋਟਾ ਸਰੰਸ਼ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੇ, ਅਤੇ ਫੈਸਲਿਆਂ ਨੂੰ ਸ਼ਿਪ ਰੂਪ ਵਿੱਚ ਬਦਲਵਾਏ।
ਅਸਲ ਲੋਕਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਕਿਰਤੀ-ਪ੍ਰਤੀਕਲ ਪੇੜੇ ਨਾਲ ਨਹੀਂ
ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਬਣਾਓ
ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਪਭੋਗਤਾ, ਪਲ ਅਤੇ کامیابی ਮਾਪਦੰਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।
ਪર્સੋਨਾ ਸੰਰਚਨਾ ਸਹਿਮਤੀ ਲਈ ਸਹਾਇਕ ਹੈ, ਪਰ ਉਹ ਨਹੀਂ ਦੱਸ ਸਕਦੀਆਂ ਕਿ ਕਿਸੇ ਨੇ ਅਸਲ ਵਿੱਚ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰ ਲਿਆ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ, ਤੁਹਾਡਾ ਕੰਮ ਹੈ ਅਸਲ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਅਸਲ ਕਾਰਜ ਕਰਦੇ ਦੇਖਣਾ—ਫਿਰ ਜੋ ਰੋਕਦਾ ਹੈ ਉਹਨੂੰ ਠੀਕ ਕਰੋ।
ਉਪਭੋਗਤਾ ਗੱਲ-ਬਾਤ ਲਈ ਸਧਾਰਣ ਸਕ੍ਰਿਪਟ
ਗੱਲਬਾਤ ਨੂੰ ਇੱਕ ਨਜ਼ਦੀਕੀ, ਵਿਸ਼ੇਸ਼ ਸਥਿਤੀ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ (ਪਸੰਦਾਂ 'ਤੇ ਨਹੀਂ)।
- ਲક્ષ੍ਯ: “ਤੁਸੀਂ ਕੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ?”\
- ਕੋਸ਼ਿਸ਼: “ਕਦਮ-ਦਰ-ਕਦਮ ਦੱਸੋ ਜੋ ਤੁਸੀਂ ਕੀਤਾ।”\
- ਟਕਰਾਅ: “ਕਿੱਥੇ ਤੁਸੀਂ ਰੁਕੇ, ਹਚਕਿਚਾਏ, ਜਾਂ ਅਣਨਿਸ਼ਚਿਤ ਮਹਿਸੂਸ ਕੀਤਾ?”\
- ਨਤੀਜਾ: “ਅੰਤ ਵਿੱਚ ਕੀ ਹੋਇਆ? ਕੀ ਤੁਸੀਂ ਚਾਹੀਦਾ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕੀਤਾ?”
ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਕਹੋ ਅਤੇ ਸੋਚ-ਉਚਾਰ ਕਰਦੇ ਹੋਏ ਦੱਸਣ ਲਈ ਕਹੋ। ਜੇ ਉਹ ਤੁਹਾਡੀ ਮਦਦ ਦੇ ਬਿਨਾਂ ਇਸਦਾ ਉਪਯੋਗ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਡੇਟਾ ਹੈ।
ਸਿਰਫ ਰਾਏ ਨਹੀਂ—ਵਿਹਾਰ ਦੇਖੋ
ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਕਹਿ ਸਕਦੇ ਹਨ “ਚੰਗਾ ਲੱਗਦਾ ਹੈ” ਜਾਂ “ਮੈਂ ਇਸਨੂੰ ਵਰਤਾਂਗਾ,” ਖਾਸ ਕਰ ਕੇ ਜੇ ਉਹ ਤੁਹਾਨੂੰ ਪਸੰਦ ਕਰਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਨੂੰ ਸਵਿੱਚ ਸ਼ਲਾਇਨ ਸਮਝੋ।
ਅਵਲੰਬੀ ਸੰਕੇਤ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਉਹ ਪ੍ਰਧਾਨ ਕਰੋ:
- ਕੀ ਉਹ ਅਗਲਾ ਕਦਮ ਬਿਨਾਂ ਦੱਸੇ ਸਮਝਦੇ ਹਨ?\
- ਕੀ ਉਹ ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਕੀਤੀ ਮੁੱਖ ਕਾਰਵਾਈ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ?\
- ਕੀ ਉਹ जारी ਰੱਖਦੇ ਹਨ, ਜਾਂ ਧੱਤੇ ਛੱਡ ਦਿੰਦੇ ਹਨ?
ਜੇ ਤੁਸੀਂ ਰਾਏ ਪੁੱਛਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਚੋਣਾਂ ਨਾਲ ਸਬੰਧਿਤ ਰੱਖੋ: “ਅਗਲੇ ਕੀ ਕਰੋਗੇ?” ਜਾਂ “ਜੇ ਤੁਸੀਂ ਇਸ ਤੇ ਕਲਿੱਕ ਕਰੋਗੇ ਤਾਂ ਕੀ ਉਮੀਦ ਕਰਦੇ ਹੋ?”
ਪੈਟਰਨ ਕੈਪਚਰ ਕਰੋ: 3 ਬੜੇ ਰੋਕਾਵਟ ਅਤੇ 3 ਖੁਸ਼ੀ ਦੇ ਲਹਜੇ
ਹਰ ਸੈਸ਼ਨ ਤੋਂ ਬਾਅਦ ਲਿਖੋ:
- ਸਿਖਰ 3 ਰੋਕਾਵਟ: ਉਹ ਲਹਜ਼ੇ ਜੋ ਮੁੱਲ ਰੋਕਦੇ ਹਨ (ਗੁੰਝਲ, ਘੱਟ ਜਾਣਕਾਰੀ, ਭਰੋਸਾ ਚਿੰਤਾਵਾਂ)\
- ਸਿਖਰ 3 ਖੁਸ਼ੀ ਦੇ ਲਹਜੇ: ਉਹ ਪਲ ਜਿੱਥੇ ਮੁੱਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਦਾ (ਸਪਸ਼ਟਤਾ, ਗਤੀ, ਰਾਹਤ)
ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਜਿਹੜੀ ਚੀਜ਼ ਵਾਰ-ਵਾਰ ਆਉਂਦੀ ਹੈ, ਉਸਨੂੰ ਤਰਜੀਹ ਦਿਓ।
ਕਿੰਨੇ ਉਪਭੋਗਤਾ ਕਾਫ਼ੀ ਨੇ?
ਛੋਟੇ ਪਰ ਨਿਸ਼ਾਨਾ-ਨਿਸ਼ਚਿਤ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: 5–8 ਲੋਕ ਇਸ ਵਿਸ਼ੇਸ਼ ਦਰਸ਼ਕ ਤੋਂ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਰੋਕਾਂ ਨੂੰ ਬਤਾਉਂਦੇ ਹਨ। ਜੇ ਫੀਡਬੈਕ ਬਹੁਤ ਵੱਖਰਾ ਹੋਵੇ, ਤਾਂ ਤੁਹਾਡੀ ਟਰਗਟਿੰਗ ਬਹੁਤ ਵਿਆਪਕ ਹੈ—ਜਾਂ ਤੁਹਾਡਾ ਵਾਅਦਾ ਸਪਸ਼ਟ ਨਹੀਂ।
ਉਹ ਚੀਜ਼ਾਂ ਸੁਧਾਰੋ ਜੋ ਮੁੱਲ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ
ਇਤਰਾਫ-ਇਤਰਾਫ ਬਦਲਨਾ “ਬਦਲਦੇ ਰਹੋ” ਨਹੀਂ ਹੈ। ਇਹ ਉਪਭੋਗਤਾ ਅਤੇ ਤੁਹਾਡੇ ਵਾਅਦੇ ਵਿਚਕਾਰ ਦੀ ਰਗੜ ਹਟਾਉਣਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਫੀਚਰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਪਯੋਗੀ ਰੋਕਾਵਟ ਸਹੀ ਕਰੋ। ਜੇ ਕੋਈ ਉਪਭੋਗਤਾ ਮੁੱਖ ਨਤੀਜੇ ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ (ਜਾਂ ਨਤੀਜੇ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ), ਤਾਂ ਜੋ ਕੁਝ ਤੁਸੀਂ ਜੋੜੋਗੇ ਉਹ ਸਿਰਫ਼ ਸਜਾਵਟ ਹੈ।
“ਵੈਲਯੂ ਬਲੋਕਰ” ਨਿਰਧਾਰਿਤ ਕਰੋ
ਵੈਲਯੂ ਬਲੋਕਰ ਉਹ ਹੈ ਜੋ ਕਿਸੇ ਨੂੰ ਮੁੱਖ ਕੰਮ ਪੂਰਾ ਕਰਨ ਤੋਂ ਰੋਕਦਾ:
- ਉਹ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਸਕਦੇ (ਪਹਿਲਾ ਕਦਮ ਗੁੰਝਲਦਾਰ, ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਗੈਰਮੌਜੂਦ)\
- ਉਹ ਮੁਕੰਮਲ ਨਹੀਂ ਕਰ ਸਕਦੇ (ਫਲੋ ਟੁਟਦਾ, ਗਲਤੀਆਂ, ਲੋੜੀਂਦਾ ਵਿਸ਼ੇਸ਼ ਤਕਨਕੀ ਸਮਰਥਨ ਨਹੀਂ)\
- ਉਹ ਇਸ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ (ਅਨਸਪਸ਼ਟ ਨਤੀਜੇ, ਪੁਸ਼ਟੀ ਦੀ ਘਾਟ, ਡਰਾਉਣੀਆਂ ਅਨੁਮਤੀਆਂ)\
- ਇਹ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਂਦਾ (ਬਹੁਤ ਸਾਰੀਆਂ ਸਕਰੀਨ, ਗੈਰ-ਜ਼ਰੂਰੀ ਚੋਣਾਂ)
ਜਦੋਂ ਫੀਡਬੈਕ ਆਵੇ, ਉਸਨੂੰ ਇਨ੍ਹਾਂ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਫੋਰਸ ਕਰਕੇ ਪਾਉ। ਜੇ ਇਹਨਾਂ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ "ਬਾਅਦ" ਵਾਲੀ ਚੀਜ਼ ਹੈ।
ਪ੍ਰਭਾਵ ਬਨਾਮ ਕੋਸ਼ਿਸ਼ (ਤੁਰੰਤ) ਨਾਲ ਤਰਜੀਹ
ਇੱਕ ਸਧਾਰਨ 2×2 ਵਰਤੋ:
- ਉੱਚ ਪ੍ਰਭਾਵ / ਘੱਟ ਕੋਸ਼ਿਸ਼: ਅਗਲਾ ਕਰੋ\
- ਉੱਚ ਪ੍ਰਭਾਵ / ਉੱਚ ਕੋਸ਼ਿਸ਼: ਛੋਟਾ ਕਰੋ ਜਾਂ ਸ਼ਡਿਊਲ ਕਰੋ\
- ਘੱਟ ਪ੍ਰਭਾਵ / ਘੱਟ ਕੋਸ਼ਿਸ਼: ਸਿਰਫ ਜੇ ਇਹ ਰੋਕ ਹਟਾਉਂਦਾ ਹੋਵੇ\
- ਘੱਟ ਪ੍ਰਭਾਵ / ਉੱਚ ਕੋਸ਼ਿਸ਼: ਬਚੋ
ਇੱਥੇ ਪ੍ਰਭਾਵ ਦਾ ਮਤਲਬ ਹੈ “ਜ਼ਿਆਦਾ ਲੋਕਾਂ ਨੂੰ ਵਾਅਦੇ ਵਾਲੇ ਨਤੀਜੇ ਤੱਕ ਪਹੁੰਚਾਉਣਾ,” ਨਾ ਕਿ “ਇੰਪ੍ਰੈਸਿਵ ਲੱਗਦਾ ਹੈ।”
ਉਹ ਫੀਚਰ ਹਟਾਓ ਜੋ ਕੋਰ ਵਾਅਦੇ ਨੂੰ ਸਹਾਇਤਾ ਨਹੀਂ ਕਰਦੇ
ਜੇ ਕੋਈ ਫੀਚਰ:
- ਅਨੁਸਾਰੀ ਪੱਥ 'ਤੇ ਵਰਤਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਅਤੇ\
- ਕੰਪਲੀਸ਼ਨ ਜਾਂ ਭਰੋਸਾ ਨਹੀਂ ਵਧਾਉਂਦਾ,
ਤਾਂ ਇਸਨੂੰ ਅਜੇ ਹਟਾਓ (ਜਾਂ ਛੁਪਾਓ)। ਹਟਾਉਣਾ ਇਕ ਕੇਂਦਰੀਕਰਨ ਦਾ ਰੂਪ ਹੈ: ਘੱਟ ਵਿਕਲਪ ਸਹੀ ਕਾਰਵਾਈ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ।
ਹਰ ਇਟਰੇਸ਼ਨ ਲਈ ਸਮਾਂ ਸੀਮਾ ਰੱਖੋ
ਛੋਟਾ ਰਿਥਮ ਸੈੱਟ ਕਰੋ—3–7 ਦਿਨ ਪ੍ਰਤੀ ਇਟਰੇਸ਼ਨ ਇੱਕ ਵਧੀਆ ਡਿਫੋਲਟ ਹੈ। ਹਰ ਚੱਕਰ ਇੱਕ ਮਾਪਯੋਗ ਸੁਧਾਰ ਭੇਜੇ (ਉਦਾਹਰਨ: “ਕੰਪਲੀਸ਼ਨ ਦਰ +10%” ਜਾਂ “ਪਹਿਲੀ ਨਤੀਜੇ ਤੱਕ ਸਮਾਂ 60 ਸਕਿੰਟ ਤੋਂ ਘੱਟ”)। ਸਮਾਂਸੀਮਾ ਅਨੰਤ ਸੁਧਾਰਾਂ ਨੂੰ ਰੋਕਦੀ ਹੈ ਅਤੇ ਸਿੱਖਿਆ ਨੂੰ ਅਸਲ ਵਰਤੋਂ 'ਤੇ ਆਧਾਰਿਤ ਰੱਖਦੀ ਹੈ।
ਪਾਲਿਸ਼ ਕਦੋਂ ਜੋੜੀਏ ਅਤੇ ਸਕੇਲ ਕਦੋਂ
ਸ਼ੁਰੂ ਵਿੱਚ, “ਪਾਲਿਸ਼” ਅਤੇ “ਸਕੇਲ” ਤੁਹਾਡੀ ਗੰਭੀਰਤਾ ਦਾ ਸਬੂਤ ਲੱਗ ਸਕਦੇ ਹਨ। ਪਰ ਜੇ ਉਤਪਾਦ ਅਜੇ ਲਗਾਤਾਰ ਮੁੱਲ ਨਹੀਂ ਦੇ ਰਿਹਾ, ਤਾਂ ਦੋਹਾਂ ਮਹਿੰਗੇ ਵਿਵਾਦਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ।
ਪਾਲਿਸ਼ ਦੀ ਕਦਰ ਕਦੋਂ ਕਰੋ
ਜਦੋਂ ਇਹ ਲੋਕਾਂ ਲਈ ਘਰਾਇਆ ਰੁਕਾਵਟ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਚਾਹੁੰਦੇ ਹਨ। ਲੱਭੋ:
- ਦੁਹਰਾਉਣ ਵਾਲੀ ਵਰਤੋਂ: ਇੱਕੋ ਲੋਕ ਬਿਨਾਂ ਯਾਦ ਦਿਵਾਉਣ ਦੇ ਮੁੜ ਆਉਂਦੇ ਹਨ\
- ਸਿਫ਼ਾਰਸ਼ਾਂ: ਉਪਭੋਗਤਾ ਹੋਰਨਾਂ ਨੂੰ ਖਿੱਚ ਲੈ ਆਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਸਨੇ ਉਨ੍ਹਾਂ ਦੀ ਮਦਦ ਕੀਤੀ\
- “ਮੈਂ ਕਿਵੇਂ…?” ਸਵਾਲ ਘੱਟ ਹੋਣੇ: ਸਪੋਰਟ ਰਿਕਵੇਸਟਜ਼ ਆਮ ਨੇਵੀਗੇਸ਼ਨ ਤੋਂ ਬਦਲੇ ਐਡਜ ਕੇਸਾਂ ਵੱਲ ਮੁੜਦੇ ਹਨ
ਇਸ ਦਰਜੇ 'ਤੇ ਪਾਲਿਸ਼ ਦਾ ਮਤਲਬ ਹੈ ਸਪਸ਼ਟਤਮ ਕਾਪੀ, ਸਿਗੀ ਹੋਈ ਔਨਬੋਰਡਿੰਗ, ਘੱਟ ਕਦਮ, ਅਤੇ ਛੋਟੇ UI ਸੁਧਾਰ ਜੋ ਕੋਰ ਫਲੋ ਨੂੰ ਬੇਦਾਗ਼ ਬਣਾਉਂਦੇ ਹਨ।
ਸਕੇਲ ਦੀ ਲੋੜ ਕਦੋਂ ਹੈ
ਜਦੋਂ ਮੰਗ ਸਥਿਰ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੋਵੇ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿਕਾਸ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੋਵੇ:
- ਸਥਿਰ ਮੰਗ: ਵਰਤੋਂ ਇੱਕ ਹਫਤੇ ਦਾ spike ਨਹੀਂ, ਪਰ ਸਮੇਂ ਨਾਲ ਲਗਾਤਾਰ ਰਹਿੰਦੀ ਹੈ\
- ਜਾਣੇ-ਪਛਾਣ ਬੋਤਲਨੇਕ: ਤੁਸੀਂ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਟੁੱਟ ਰਿਹਾ (ਸਲੋ ਰਿਪੋਰਟ, ਕਿਉਂਕਿ ਕਤਾਰਾਂ)\
- ਅਪਟਾਈਮ ਲੋੜਾਂ: ਆਉਟੇਜ ਜਾਂ ਧੀਮਾਪਣ ਹੁਣ ਰਿਟੇਨਸ਼ਨ ਜਾਂ ਰੈਵਨਿਊ ਨੁਕਸਾਨ ਕਰ ਰਹੇ ਹਨ
ਸਕੇਲ ਦਾ ਮਤਲਬ ਹੈ ਸਮਰੱਥਾ, ਆਟੋਮੇਸ਼ਨ, ਮਾਨੀਟਰਿੰਗ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਪੱਕੜ—not ਕੇਵਲ “ਤੇਜ਼ ਸਰਵਰ।”
ਮਿਥਿਆ ਗੁਣਵੱਤਾ ਬਨਾਮ ਸਜਾਵਟੀ ਚੀਜ਼ਾਂ
ਕੁਝ “ਗੁਣਵੱਤਾ” ਦਿਨ-ਇੱਕ ਤੋਂ ਹੀ ਅਮਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ, ਪ੍ਰਾਈਵੇਸੀ, ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ। ਇਹ ਕੋਸਮੈਟਿਕ ਸੁਧਾਰ (ਐਨੀਮੇਸ਼ਨ, ਪ੍ਰਾਪਰ ਸਪੇਸਿੰਗ, ਬ੍ਰਾਂਡ ਫੁਲਿਸ਼) ਤੋਂ ਵੱਖ ਹਨ। ਮੋਹਰੀ ਗੁਣਵੱਤਾ ਸ਼ੁਰੂ ਤੋਂ ਕਰੋ; ਸਜਾਵਟੀ ਬਾਅਦ ਲਈ ਛੱਡੋ।
ਇੱਕ ਸੀਧਾ ਪਰਗਟੀ ਯੋਜਨਾ ਜੋ ਤੁਹਾਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖੇ
ਸਰਲ ਤਰਤੀਬ ਵਰਤੋ:
- ਉਪਯੋਗਤਾ: ਕੋਰ ਕੰਮ ਐਂਡ-ਟੂ-ਐਂਡ ਹੋਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ\
- ਭਰੋਸੇਯੋਗਤਾ: ਇਹ ਲਗਾਤਾਰ ਕੰਮ ਕਰਦਾ; ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਹੈ; ਨਾਕਾਮੀਆਂ ਨੂੰ ਸਮ੍ਹਾਲਿਆ ਜਾਂਦਾ ਹੈ\
- ਪਾਲਿਸ਼: ਘੱਟ ਰਗੜ ਹਟਾਓ; ਪਹਿਲੀ ਵਰਤੋਂ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ\
- ਸਕੇਲ: ਜਦ ਮੰਗ ਸਾਬਤ ਹੋ ਜਾਵੇ ਤਾਂ ਸਮਰੱਥਾ 'ਚ ਨਿਵੇਸ਼ ਕਰੋ
ਜੋਖਮ ਤੋਂ ਬਚੋ: ਸ਼ੁਰੂ ਤੋਂ ਭਰੋਸਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ
ਇਸਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਹੱਥ ਵਿੱਚ ਰੱਖੋ
ਲੋਕ ਟੈਸਟ ਕਰਨ ਲਈ ਇੱਕ ਵਰਕਿੰਗ ਬਿਲਡ ਹੋਸਟ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਤੁਹਾਡੇ ਬਿਨਾਂ ਹੈਪੀ ਪਾਥ ਆਜ਼ਮਾ ਸਕਣ।
ਸ਼ੁਰੂਆਤੀ ਤੌਰ 'ਤੇ ਸ਼ਿਪ ਕਰਨਾ ਲਚਕੀਲਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਇੱਕ ਛੋਟਾ MVP ਵੀ ਭਰੋਸਾ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ ਜੇ ਇਹ ਡੇਟਾ ਗੁਆ ਬੈਠੇ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਅਨੁਮਤੀਆਂ ਨਾਲ ਹੈਰਾਨ ਕਰੇ, ਜਾਂ ਚੁੱਪ ਚਾਪ ਫੇਲ ਹੋ ਜਾਵੇ। ਟੀਚਾ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਚੀਜ਼ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗਰੇਡ ਹੋਵੇ—ਇੱਕ ਦੋ ਭਰੋਸੇਯੋਗ ਅਤੇ ਨਾਨ-ਨੈਗੋਸ਼ੀਏਬਲ ਬੁਲਿਟੀਨ ਸ਼ੁਰੂ ਤੋਂ ਸਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਨੀਤੀ-ਨਿਰਣਾ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ
ਇਹ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ ਵੀ ਸਦਾ ਕੀ ਕਰੋਗੇ:
- ਡੇਟਾ ਹੈਂਡਲਿੰਗ: ਤੁਸੀਂ ਕਿਹੜਾ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਕਰੋਂਗੇ, ਕਿੰਨੀ ਦੇਰ ਲਈ, ਅਤੇ ਕੌਣ ਦੇਖ ਸਕਦਾ ਹੈ? ਜੇ ਤੁਹਾਨੂੰ ਲੋੜ ਨਹੀਂ, ਤਾਂ ਇਕੱਤਰ ਨਾ ਕਰੋ।\
- ਅਨੁਮਤੀਆਂ: ਸਿਰਫ ਉਹੀ ਐਕਸਸ ਮੰਗੋ ਜੋ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ ਤੇ ਜਾਇਜ਼ ਠਹਿਰਾ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਹਾਨੂੰ ਲੋਕੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਸ ਵੇਲੇ ਸਮਝਾਓ ਜਦੋਂ ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ।\
- ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ: ਜੇ ਉਪਭੋਗਤਾ ਕੀਮਤੀ ਚੀਜ਼ ਬਣਾਉਂਦਾ ਹੈ (ਨੋਟਸ, ਟਾਸਕ, ਫਾਈਲਾਂ), ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ “ਇਹ ਗਾਇਬ ਹੋ ਗਿਆ” ਮੋਮੈਂਟ ਨੂੰ ਕਿਵੇਂ ਰੋਕੋਗੇ। ਏਕ ਦਿਨੀ ਬੈਕਅੱਪ ਜਾਂ ਸਧਾਰਣ ਐਕਸਪੋਰਟ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕਾਫੀ ਹੋ ਸਕਦਾ ਹੈ।\
- ਐਰਰ ਸਟੇਟਸ: ਖਾਲੀ ਸਕ੍ਰੀਨਾਂ ਦੀ ਥਾਂ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਾਲੇ ਸੁਨੇਹੇ ਦਿਖਾਓ: ਕੀ ਹੋਇਆ, ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ।
ਜੋ ਤੁਸੀਂ ਲਗਾਤਾਰ ਨਹੀਂ ਦੇ ਸਕਦੇ ਉਹ ਦਾ ਵਾਅਦਾ ਨਾ ਕਰੋ
“ਗਤੀ,” “ਅਪਟਾਈਮ,” ਜਾਂ “ਕੰਪਲਾਇੰਸ” ਬਾਰੇ ਬਜ਼ਾਰਗਾਹੀ ਦਾਅਵੇ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਹ ਸਬੂਤ ਨਹੀਂ ਕਰਦੇ। ਸ਼ੁਰੂਆਤੀ ਉਪਭੋਗਤਾ "ਸੀਮਤ ਫੀਚਰ" ਨੂੰ ਮਾਫ਼ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਉਹਨਾਂ ਨੂੰ دھੋਖਾ ਮਹਿਸੂਸ ਕਰਨਾ ਪ੍ਰਸੰਨ ਨਹੀਂ ਕਰਦੇ। ਜੇ ਕੁਝ ਪ੍ਰਯੋਗਾਤਮਕ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਐਸਾ ਲੇਬਲ ਕਰੋ।
ਸਰਹੱਦਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ (ਆਪਣੇ ਲਈ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ)
ਇੱਕ ਛੋਟੀ "ਇਹ ਕੀ ਕਰਦਾ/ਨਹੀਂ ਕਰਦਾ" ਨੋਟ ਬਣਾਓ—ਇੱਕ ਪੰਨਾ ਕਾਫੀ ਹੈ। ਇਹ ਸੇਲਜ਼, ਸਪੋਰਟ, ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਲਾਈਨ ਤੇ ਰੱਖਦਾ ਹੈ ਅਤੇ ਗਲਤ ਵਾਅਦਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ। onboarding ਜਾਂ /help ਪੇਜ ਤੋਂ ਇਸਨੂੰ ਜੁੜਨ ਦਾ ਸੋਚੋ।
ਹਲਕਾ ਰੋਲਬੈਕ ਯੋਜਨਾ ਬਣਾਓ
ਰਿਲੀਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਗਲਤ ਬਦਲ ਨੂੰ ਕਿਵੇਂ ਉਲਟਾਓਗੇ:
- ਆਖਰੀ ਜਾਣੇ-ਚੰਗੇ build/version ਰੱਖੋ।\
- feature flags ਜਾਂ ਇੱਕ ਸਰਲ "ਬੰਦ ਸੁਇਚ" ਰੱਖੋ ਜੋ ਜੋਖਿਮ ਵਾਲੇ ਫੀਚਰਾਂ ਲਈ।\
- ਬੈਕਅੱਪ ਤੋਂ ਡੇਟਾ ਰੀਸਟੋਰ ਕਰਨ ਯੋਗ ਹੋਵੋ (ਇਕ ਵਾਰੀ ਇਸਨੂੰ ਟੈਸਟ ਕਰੋ)।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ ਜੋ snapshots (ਉਦਾਹਣ ਲਈ, Koder.ai snapshots ਅਤੇ rollback ਦਿੰਦਾ ਹੈ) ਸਮਰੱਥਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਆਪਣੀ ਸ਼ੁਰੂਆਤੀ ਸੁਰੱਖਿਆ ਜਾਲ ਵਿੱਚ ਵਰਤੋ—ਪਰ ਹਮੇਸ਼ਾ ਇਹ ਆਦਤ ਬਣਾਓ ਕਿ “ਕੀ ਅਸੀਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਉਲਟ ਸਕਦੇ ਹਾਂ?” ਭਾਵੇਂ ਟੂਲ ਕੀ ਹੋਵੈ।
ਇਹ ਬੁਨਿਆਦੀ ਕਦਮ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਇਕ ਐਸੀ ਚੀਜ਼ ਟੁੱਟਣ ਦੇ ਜੋ ਮੁੜ ਬਣਾਉਂਣ ਔਖਾ ਹੋਵੇ: ਭਰੋਸਾ।
ਇਸ ਮਹੀਨੇ ਕੁਝ ਉਪਯੋਗੀ ਸ਼ਿਪ ਕਰਨ ਲਈ ਪ੍ਰਯੋਗੀ ਚੈੱਕਲਿਸਟ
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ ਕੁਝ ਹਫ਼ਤੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਹੋਰ ਫੀਚਰ ਦੀ ਲੋੜ ਨਹੀਂ—ਤੁਸੀਂ ਇੱਕ ਕਸ ਕੇ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ “ਕਿਸੇ ਕੋਲ ਸਮੱਸਿਆ ਹੈ” ਤੋਂ “ਉਸਨੂੰ ਮੁੱਲ ਮਿਲ ਗਿਆ।” ਇਸ ਚੈੱਕਲਿਸਟ ਨੂੰ ਇੱਕ ਪੰਨੇ ਦੀ ਯੋਜਨਾ ਵਜੋਂ ਵਰਤੋ ਜੋ ਤੁਸੀਂ ਨੋਟਬੁੱਕ, ਡੌਕ, ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਬੋਰਡ 'ਤੇ ਚਲਾ ਸਕਦੇ ਹੋ।
ਇਕ-ਪੰਨੇ ਦੀ ਚੈੱਕਲਿਸਟ (ਆਈਡੀਆ → ਪਹਿਲੀ ਉਪਯੋਗੀ ਰਿਲੀਜ਼)
-
ਇੱਕ ਉਪਭੋਗਤਾ ਅਤੇ ਇੱਕ ਪਲ ਨਾਮ ਲਵੋ। ਉਹ ਕੌਣ ਹੈ, ਅਤੇ ਸਮੱਸਿਆ ਕਦੋਂ ਆਉਂਦੀ ਹੈ?
-
ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮੱਸਿਆ ਲਿਖੋ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਵੀ ਖੋਜ ਵਿੱਚ ਹੋ।
-
ਇੱਕ ਸਫਲਤਾ ਮੈਟਰਿਕ ਚੁਣੋ। ਉਦਾਹਰਨ: “ਉਪਭੋਗਤਾ X ਨੂੰ 2 ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਪੂਰਾ ਕਰਦਾ ਹੈ।”
-
ਥਿਨ ਸਲਾਇਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਸਭ ਤੋਂ ਛੋਟਾ ਐਂਡ-ਟੂ-ਐਂਡ ਫਲੋ ਜੋ ਵਾਅਦੇ ਵਾਲੇ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ।
-
ਸਕੋਪ ਨੂੰ ਜ਼ੋਰਦਾਰ ਤੌਰ 'ਤੇ ਕੱਟੋ। ਖਾਤੇ, ਸੈਟਿੰਗਸ, ਟੀਮ ਫੀਚਰ, ਆਟੋਮੇਸ਼ਨ, ਇੰਟੀਗਰੇਸ਼ਨ, ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ—ਸਿਵਾਏ ਜੇ ਉਹ ਮੁੱਲ ਲਈ ਜ਼ਰੂਰੀ ਹੁੰਦੇ।
-
ਹੈਪੀ ਪਾਥ 5–7 ਕਦਮਾਂ ਵਿੱਚ ਨਕਸ਼ਾ ਬਣਾਓ। ਹਰ ਕਦਮ ਨੂੰ ਪਹਿਲੀ ਵਰਤੋਂ 'ਤੇ ਸਪਸ਼ਟ ਬਨਾਓ।
-
ਕੇਵਲ ਜ਼ਰੂਰੀ ਭਰੋਸਾ ਬੁਨਿਆਦੀਆਂ ਜੋੜੋ। ਸਪਸ਼ਟ ਕਾਪੀ, ਭਰੋਸੇਯੋਗ ਗਲਤੀਆਂ, ਡੇਟਾ ਲੋਸ ਨਹੀਂ, ਇੱਕ ਸੰਪਰਕ/ਸਹਾਇਤਾ ਨੋਟ।
-
ਦੋ ਇਵੈਂਟ + ਇੱਕ ਨੋਟ ਨੂੰ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰੋ। ਸ਼ੁਰੂ, ਸਫਲਤਾ, ਅਤੇ ਇੱਕ ਛੋਟੀ “ਤੁਹਾਨੂੰ ਕੀ ਰੋਕਿਆ?” ਪ੍ਰਾਂਪਟ।
-
5 ਅਸਲ ਲੋਕਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ ਵਰਤਦੇ ਦੇਖੋ। ਸਮਝਾਉਣਾ ਨਹੀਂ—ਸੁਣੋ।
-
ਭੇਜੋ, ਫਿਰ ਸਭ ਤੋਂ ਵੱਡਾ ਰੋਕ ਸੁਧਾਰੋ। ਇੱਕ ਸੁਧਾਰ ਚੱਕਰ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਨਵੇਂ ਫੀਚਰ ਜੋੜੋ।
~3000-ਸ਼ਬਦਾਂ ਵਾਲੇ ਉਦਾਹਰਣ-ਚਲਿਤ ਗਾਈਡ ਲਈ ਸੁਝਾਅ ਰੂਪਰੇਖਾ
- ਇਕ ਛੋਟੀ ਫਰੇਮਿੰਗ ਕਹਾਣੀ: ਉਪਯੋਗਤਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੋਂ ਉੱਤੇ ਚੜ੍ਹਦੀ ਹੈ\
- ਇੱਕ ਉਪਭੋਗਤਾ + ਇੱਕ ਦਰਦਨਾਕ ਸਮੱਸਿਆ ਚੁਣਨਾ\
- ਸਮੱਸਿਆ ਨੂੰ ਮਾਪਯੋਗ ਟਾਰਗਟ ਵਿੱਚ ਬਦਲਨਾ\
- MVP ਮੁੱਲ ਵਾਅਦੇ ਦੀ ਰਚਨਾ\
- ਪਹਿਲਾ ਪਤਲਾ ਸਲਾਇਸ ਬਣਾਉਣਾ\
- UX ਸਧਾਰਨ ਰੱਖਣਾ (ਪਹਿਲੀ ਵਰਤੋਂ ਦੀ ਸਪਸ਼ਟਤਾ)\
- ਬੁਨਿਆਦੀ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ + ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ\
- ਅਸਲ ਲੋਕਾਂ ਨਾਲ ਟੈਸਟ (ਤੇ ਕੀ ਦੇਖਣਾ ਹੈ)
- ਮੁੱਲ ਰੋਕਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ ਇٽرੇਟ ਕਰਨਾ\
- ਪਾਲਿਸ਼ ਜੋੜਣ ਦਾ ਸਮਾਂ ਬਨਾਮ ਸਕੇਲ ਜੋੜਣ ਦਾ ਸਮਾਂ\
- ਦਿਨ-ਇੱਕ ਤੋਂ ਭਰੋਸਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਬੁਨਿਆਦੀ
- ਆਖਰੀ ਚੈੱਕਲਿਸਟ + “ਤੁਸੀਂ ਇਸ ਮਹੀਨੇ ਕੀ ਭੇਜੋਗੇ” ਯੋਜਨਾ
ਕਾਪੀ-ਪੇਸਟ ਟੈਮਪਲੇਟ
ਸਮੱਸਿਆ ਬਿਆਨ
For [specific user], when [situation], they struggle to [job-to-be-done] because [main constraint].
MVP ਸਕੋਪ
We will ship [thin slice outcome] using [core steps 1–3]. We will not build [3–5 excluded items].
ਫੀਡਬੈਕ ਨੋਟਸ
User tried to [goal]. Blocked at [step] because [reason]. Workaround: [what they did]. Fix idea: [small change].
ਕਾਲ ਟੂ ਐਕਸ਼ਨ
ਇੱਕ ਸਮੱਸਿਆ ਚੁਣੋ, ਥਿਨ ਸਲਾਇਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਅਤੇ ਇਸਨੂੰ ਭੇਜੋ। ਇਸ ਸਮੇਂ ਅਗਲੇ ਮਹੀਨੇ ਤੱਕ, ਇੱਕ ਅਸਲੀ ਵਿਅਕਤੀ ਦਾ ਟੀਚਾ ਰੱਖੋ ਕਿ ਉਹ ਹੈਪੀ ਪਾਥ ਤੁਹਾਡੇ ਬਿਨਾਂ ਪੂਰਾ ਕਰ ਸਕੇ—ਅਤੇ ਜੋ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਉਸਨੂੰ ਨਿਰਣਾ ਕਰੋ ਕਿ ਅਗਲਾ ਕੀ ਬਣਾਉਣਾ ਹੈ।