12 ਨਵੰ 2025·8 ਮਿੰਟ
48 ਘੰਟਿਆਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਪ੍ਰੋਟੋਟਾਈਪ ਨਾਲ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ
48 ਘੰਟਿਆਂ ਵਿੱਚ ਵਰਤਣ ਯੋਗ ਪ੍ਰੋਟੋਟਾਈਪ ਨਾਲ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ ਯੋਜਨਾ ਬਣਾਓ: ਤੇਜ਼ੀ ਨਾਲ ਭਰਤੀ ਕਰੋ, ਟਾਸਕ ਸਕ੍ਰਿਪਟ ਲਿਖੋ, ਨੋਟ ਲਵੋ, ਅਤੇ ਫੀਡਬੈਕ ਨੂੰ ਸਪਸ਼ਟ ਬਿਲਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਬਦਲੋ।
48 ਘੰਟਿਆਂ ਵਿੱਚ ਵਰਤਣ ਯੋਗ ਪ੍ਰੋਟੋਟਾਈਪ ਨਾਲ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ ਯੋਜਨਾ ਬਣਾਓ: ਤੇਜ਼ੀ ਨਾਲ ਭਰਤੀ ਕਰੋ, ਟਾਸਕ ਸਕ੍ਰਿਪਟ ਲਿਖੋ, ਨੋਟ ਲਵੋ, ਅਤੇ ਫੀਡਬੈਕ ਨੂੰ ਸਪਸ਼ਟ ਬਿਲਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਬਦਲੋ।
ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਹੁਤ ਸਾਰੀਆਂ ਬਹਿਸਾਂ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਅਸਲੀ ਟਾਸਕ ਕਰ ਕੇ ਦੇਖਦਾ ਹੈ, ਤਦ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ੱਕਦਾ ਛੱਡ ਕੇ ਦੇਖਦੇ ਹੋ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੇ ਹਨ। ਇਸੀ ਲਈ, ਖਰਾਬ ਹੋਵੇ ਤਾਂ ਵੀ ਵਰਤਣਯੋਗ ਪ੍ਰੋਟੋਟਾਈਪ ਨਾਲ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ ਚੈਟ ਵਿੱਚ ਧਾਰਨਾਵਾਂ 'ਤੇ ਬਹਿਸ ਤੋਂ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ।
3 ਤੋਂ 6 ਸੈਸ਼ਨਾਂ ਨਾਲ, ਜੇ ਤੁਸੀਂ ਸਕੋਪ ਸੀਮਾ ਰੱਖਦੇ ਹੋ ਤਾਂ ਬਹੁਤ ਕੁਝ ਪਤਾ ਲੱਗ ਸਕਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਸੰਪੂਰਨ ਅੰਕੜੇ ਨਹੀਂ ਮਿਲਣਗੇ, ਪਰ ਤੁਹਾਨੂੰ ਉਹ ਦੁਹਰਾਏ ਪੈਟਰਨ ਮਿਲਣਗੇ ਜੋ ਤੁਸੀਂ ਇਸ ਹਫਤੇ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।
48 ਘੰਟਿਆਂ ਵਿੱਚ ਤੁਸੀਂ ਵਿਸ਼ਵਾਸਯੋਗ ਤਰੀਕੇ ਨਾਲ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਲੋਕ ਕਿੱਥੇ ਫਸਦੇ ਜਾਂ ਵਾਪਸ ਜਾਂਦੇ ਹਨ, ਕਿਹੜੇ ਲੇਬਲ ਉਨ੍ਹਾਂ ਨੂੰ ਭੁੱਲਾ ਦਿੰਦੇ ਹਨ, ਉਹ ਪਹਿਲਾਂ ਕੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ (ਅਤੇ ਕੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ), ਕਿਸ ਚੀਜ਼ ਦੀ ਘਾਟ ਮਹਿਸੂਸ ਹੁੰਦੀ ਜਿਹੜੀ ਪ੍ਰੋਫ਼ਬ ਸਥਿਤੀ ਨੂੰ ਭਰੋਸਾ ਦੇਣ ਤੱਕ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਪਲ ਸੰਦਿਹ ਪੈਦਾ ਕਰਦੇ ਹਨ—ਜਿਵੇਂ ਕੀਮਤ, ਪਰਮੀਸ਼ਨਾਂ, ਜਾਂ ਕੰਮ ਬਚਾਉਣ।
ਇਹ ਤਰੀਕਾ ਵੱਡੇ ਰੀਸਰਚ ਪ੍ਰੋਜੈਕਟਾਂ, ਲੰਬੇ ਸਰਵੇ ਅਤੇ ਖੁੱਲ੍ਹੇ-ਅੰਤ ਵਾਲੀਆਂ ਖੋਜਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਸਾਰੇ ਬਾਜ਼ਾਰ ਦਾ ਨਕਸ਼ਾ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਤੁਸੀਂ ਇੱਕ ਮਹੱਤਵਪੂਰਣ ਫਲੋ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਰੁਕਾਵਟ ਹਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ।
ਕਿਸੇ ਨੂੰ ਵੀ ਸ਼ਡਿਊਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਿੰਗਲ ਲਕ਼ਸ਼ ਨਿਰਧਾਰਿਤ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਫਾਰਮੈਟ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: “ਕੀ ਪਹਿਲੀ ਵਾਰੀ ਵਾਲਾ ਉਪਭੋਗਤਾ X ਨੂੰ Y ਮਿੰਟਾਂ ਵਿੱਚ ਬਿਨਾਂ ਮਦਦ ਦੇ ਕਰ ਸਕਦਾ ਹੈ?” ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਰਲ CRM ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਹੋ ਸਕਦਾ ਹੈ: “ਕੀ ਇੱਕ ਨਵਾਂ ਯੂਜ਼ਰ ਇੱਕ ਸੰਪਰਕ ਜੋੜ ਸਕਦਾ ਹੈ, ਉਸਨੂੰ ਟੈਗ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਵਾਪਸ ਲੱਭ ਸਕਦਾ ਹੈ?”
ਜੇ ਤੁਸੀਂ ਆਪਣਾ ਪ੍ਰੋਟੋਟਾਈਪ तेज਼ੀ ਨਾਲ ਕਿਸੇ ਟੂਲ ਜਿਵੇਂ Koder.ai ਵਿੱਚ ਬਣਾਇਆ ਹੈ, ਤਾ ਲਕ਼ਸ਼ ਉਹੀ ਰਹਿੰਦਾ ਹੈ: ਇੱਕ ਫਲੋ ਚੁਣੋ, ਅਸਲੀ ਲੋਕਾਂ ਨੂੰ ਦੇਖੋ ਉਹ ਕੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਬਿਲਕੁਲ ਦਰਸਾਓ ਕਿ ਕੀ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ।
48 ਘੰਟੇ ਦਾ ਰਾਊਂਡ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸਕੋਪ ਘੱਟ ਕਰਦੇ ਹੋ। ਇੱਕ ਵਿਸ਼ੇਸ਼ ਯੂਜ਼ਰ ਕਿਸਮ ਅਤੇ ਇੱਕ ਸਹੀ ਸਿਨਾਰਿਓ ਚੁਣੋ ਜਿਸਨੂੰ ਉਹ ਪਹਿਲਾਂ ਸਮਝਦਾ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਇੱਕੋ ਸੈਸ਼ਨ ਵਿੱਚ ਆਨਬੋਰਡਿੰਗ, ਪ੍ਰਾਈਸਿੰਗ, ਸੈਟਿੰਗਜ਼ ਅਤੇ ਏਜ ਕੇਸ ਆਦਿ ਕਵਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਰਾਏਆਂ ਦੀ ਥਾਂ ਸਬੂਤ ਦੀ ਬਜਾਏ ਰਾਏਆਂ ਮਿਲਣਗੀਆਂ।
ਇੱਕ ਵਾਕ ਦਾ ਲਕ਼ਸ਼ ਲਿਖੋ ਜਿਵੇਂ: “ਕੀ ਇੱਕ ਪਹਿਲੀ ਵਾਰੀ ਵਾਲਾ ਫ੍ਰੀਲਾਂਸ ਡਿਜ਼ਾਈਨਰ ਇੱਕ ਇਨਵੌਇਸ ਬਣਾਕੇ ਭੇਜ ਸਕਦਾ ਹੈ ਅਤੇ 3 ਮਿੰਟਾਂ ਵਿੱਚ ਬਿਨਾਂ ਮਦਦ ਦੇ ਕਰ ਲੈ?” ਉਹ ਵਾਕ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਵਿਅਕਤੀ ਕੌਣ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਕੀ ਕਰਨਾ ਹੈ ਅਤੇ ਕੀ “ਚੰਗਾ” ਮੰਨਿਆ ਜਾਵੇਗਾ।
ਕਿਸੇ ਨਾਲ ਗੱਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਮਾਪੋਂਗੇ। ਇਸਨੂੰ ਸੈਸ਼ਨ ਦੌਰਾਨ ਸਾਦਾ ਅਤੇ ਦਿੱਖ-ਯੋਗ ਰੱਖੋ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਇਹ ਸਮਾਂ (ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ), ਘਰੜ (ਕਿੰਨੀ ਵਾਰੀ ਉਹ ਫਸਦੇ ਹਨ ਜਾਂ “ਹੁਣ ਕੀ?” ਪੁੱਛਦੇ ਹਨ), ਨੈਵੀਗੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ (ਹਿਜੜ, ਮੁੜ-ਪੜ੍ਹਨਾ, ਵਾਪਸੀ), ਅਤੇ ਭਰੋਸੇ ਦੇ ਸੰਕੇਤ (ਭੁਗਤਾਨ, ਪ੍ਰਾਈਵੇਸੀ, ਜਾਂ ਐਰਰ ਬਾਰੇ ਚਿੰਤਾ) ਦਾ ਮਿਸ਼ਰਣ ਹੁੰਦਾ ਹੈ।
ਫਿਰ 3 ਤੋਂ 5 ਸਵਾਲ ਲਿਖੋ ਜੋ ਰਾਊਂਡ ਦੇ ਅੰਤ ਤੱਕ ਜਰੂਰੀ ਹੋਣਗੇ। ਉਦਾਹਰਣ:
ਸਿਰਫ ਇਸ ਲਈ ਇੰਟਰਵਿਊ ਨਾ ਜਾਰੀ ਰੱਖੋ ਕਿਉਂਕਿ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਪਹਿਲਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕਦੋਂ ਰੁਕਣਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੁਬਾਰਾ ਬਿਲਡਿੰਗ ਤੇ ਵਾਪਸ ਆ ਸਕੋ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਪੰਜ ਸੈਸ਼ਨਾਂ ਮਗਰੋਂ ਰੁਕੋ, ਜਾਂ ਪਹਿਲਾਂ ਰੁਕੋ ਜੇ ਇਕੋ ਦੋ ਮੁੱਖ ਮੁੱਦੇ ਤਿੰਨ ਲੜੀਵਾਰ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਦੁਹਰਾਏ ਜਾਣ।
ਉਦਾਹਰਣ: ਜੇ ਪੰਜ ਵਿੱਚੋਂ ਤਿੰਨ ਭਾਗੀਦਾਰ “Create invoice” ਨਹੀਂ ਲੱਭ ਸਕਦੇ ਕਿਉਂਕਿ ਇਹ “Billing” ਹੇਠਾਂ ਛੁਪਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਪਸ਼ਟ ਬਿਲਡ ਬੇਨਤੀ ਹੈ: ਲੇਬਲ ਨੂੰ ਰੀਨੇਮ ਕਰੋ, ਐਂਟਰੀ ਪੋਇੰਟ ਨੂੰ ਸਥਾਨਾਂਤਰਿਤ ਕਰੋ, ਅਤੇ ਉਸ ਇੱਕ ਬਦਲਾਅ ਨੂੰ ਫਿਰ-ਟੈਸਟ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਛੋਟੀ ਸਪ੍ਰਿੰਟ ਵਾਂਗ ਵਰਤੋਂ, ਤਾਂ ਤੁਸੀਂ ਦੋ ਦਿਨਾਂ ਵਿੱਚ ਵਰਤਣ ਯੋਗ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ ਚਲਾ ਸਕਦੇ ਹੋ: ਭਰਤੀ ਕਰੋ, ਤਿਆਰੀ ਕਰੋ, ਚਲਾਓ, ਫਿਰ ਤਾਜ਼ਾ ਯਾਦਾਂ ਦੇ ਹੋਣ ਤੇ ਸੁੰਞਾ ਕਰੋ। 3 ਤੋਂ 5 ਸੈਸ਼ਨਾਂ ਲਈ ਟਾਰਗਟ ਕਰੋ। ਤਿੰਨ ਘੱਟੋ-ਘੱਟ ਹਨ ਤਾਕਿ ਸਭ ਤੋਂ ਵੱਡੇ ਸਮੱਸਿਆਂ ਨੂੰ ਨੋਟ ਕੀਤਾ ਜਾ ਸਕੇ; ਪੰਜ ਆਮ ਤੌਰ 'ਤੇ ਪੈਟਰਨ ਦਿਖਾਉਂਦੇ ਹਨ।
ਇੱਕ ਹਕੀਕਤੀ ਯੋਜਨਾ ਇੰਝ ਦਿਖਦੀ ਹੈ:
ਜੇ ਭਰਤੀ ਢੀਲੀ ਹੋ ਰਹੀ ਹੈ ਤਾਂ ਉਡੀਕ ਨਾ ਕਰੋ। ਸਕੋਪ ਘਟਾਓ ਅਤੇ ਉਪਲਬਧਤਾ ਵਿਸਥਾਰੋ। ਹੋਰ ਸਮਾਂ-ਸਲਾਟ ਦਿਓ (ਸਵੇਰੇ ਜਾਂ ਸ਼ਾਮ), ਸੈਸ਼ਨਾਂ ਨੂੰ 15 ਮਿੰਟ ਤੱਕ ਘਟਾਓ, ਜਾਂ ਨੇੜਲੇ ਸਰਕਲ ਤੋਂ ਭਰਤੀ ਕਰੋ ਜੋ ਫਿਰ ਵੀ ਤੁਹਾਡੇ ਟਾਰਗੇਟ ਯੂਜ਼ਰ ਨੂੰ ਮਿਲਦਾ ਹੋਵੇ।
ਮਾਮਲਿਆਂ ਨੂੰ ਠੀਕ-ਠਾਕ ਰੱਖਣ ਲਈ, ਪਹਿਲੀ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਫੋਲਡਰ ਸਿਸਟਮ ਬਣਾ ਲਵੋ:
01_Recruiting02_Recordings03_Notes04_Synthesis05_Ticketsਫਾਇਲਾਂ ਦੇ ਨਾਮ ਜਿਵੇਂ P01_2026-01-16_Record.mp4 ਅਤੇ P01_Notes.md ਰੱਖੋ। ਇਹ ਛੋਟੀ ਆਦਤ ਪ੍ਰੋਟੋਟਾਈਪ ਯੂਜ਼ਬਿਲਟੀ ਟੈਸਟਿੰਗ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਵੇਖਣ ਲਈ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ।
ਰਫਤਾਰ ਪਰਨਾਂਕ ਹੈ। ਤੁਹਾਡਾ ਲਕ਼ਸ਼ ਪ੍ਰਮਾਣਿਕ ਨਮੂਨਾ ਨਹੀਂ ਹੈ। ਇਹ 5 ਤੋਂ 8 ਅਸਲ ਲੋਕ ਹਨ ਜੋ ਲਗਭਗ ਉਹੀ ਯੂਜ਼ਰ ਹਨ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਜੋ ਇੱਕ ਦਿਨ ਦੇ ਅੰਦਰ ਬੁੱਕ ਹੋ ਜਾ ਰਹੇ ਹਨ।
ਸਭ ਤੋਂ ਤੇਜ਼ ਪੂਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਵਿਸਥਾਰ ਕਰੋ। ਉਤਪਾਦ ਦੇ ਨੇੜਲੇ ਲੋਕਾਂ (ਖਰੀਦਦਾਰ, ਟ੍ਰਾਇਲ ਯੂਜ਼ਰ, ਵੈਟਲਿਸਟ), ਫਿਰ ਹਾਲੀਆ ਗੱਲਬਾਤਾਂ (ਸਪੋਰਟ ਥ੍ਰੇਡ, ਡੈਮੋ ਅਨੁਰੋਧ, ਈਮੇਲ ਜਵਾਬ). ਜੇ ਹੋਰ ਚਾਹੀਦੇ ਹਨ, ਉਹ ਕਮਿਊਨਿਟੀਜ਼ ਲੱਭੋ ਜਿੱਥੇ ਸਮੱਸਿਆ ਚਰਚਾ ਹੈ, ਦੋਸਤਾਂ ਦੇ ਦੋਸਤਾਂ ਤੋਂ ਇੰਟਰੋ ਮੰਗੋ (ਰਾਏਆਂ ਨਹੀਂ), ਅਤੇ ਪਿਛਲੇ ਸਹਿਯੋਗੀਆਂ ਜਾਂ ਗਾਹਕਾਂ ਨੂੰ ਸੰਪਰਕ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੇ ਕੰਮ-ਤਰਤੀਬ ਇੱਕੋ-ਜਿਹੀ ਸੀ।
ਨਿਮੰਤਰਣ ਛੋਟਾ ਅਤੇ ਨਿਰਧਾਰਿਤ ਰੱਖੋ। ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ ਇਹ ਵਿਕਰੀ ਕਾਲ ਨਹੀਂ ਹੈ, ਤੁਸੀਂ ਉਤਪਾਦ ਨੂੰ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਬਦਲੇ ਵਿੱਚ ਉਹ ਕੀ ਕਰਨਗੇ (20 ਮਿੰਟ ਵੀਡੀਓ ਜਾਂ ਆਡੀਓ), ਅਤੇ ਕੀ ਮਿਲੇਗਾ (ਛੋਟਾ ਗਿਫਟ ਕਾਰਡ, ਇੱਕ ਮਹੀਨਾ ਮੁਫ਼ਤ, ਜਾਂ ਦਾਨ). ਦੋ ਸਮਾਂ-ਚੋਣ ਅੱਜ ਜਾਂ ਕੱਲ੍ਹ ਦਿਓ।
ਜੇ ਤੁਸੀਂ ਫ੍ਰੀਲਾਂਸਰਾਂ ਲਈ ਇੱਕ ਸਧਾਰਣ ਅੰਦਰੂਨੀ CRM ਪ੍ਰੋਟੋਟਾਈਪ (ਉਦਾਹਰਣ ਲਈ Koder.ai ਵਿੱਚ) ਬਣਾਇਆ ਹੈ, ਤਾਂ ਦੋਹਾਂ “ਗੰਦੇ spreadsheet” ਯੂਜ਼ਰਾਂ ਅਤੇ ਜੋ ਪਹਿਲਾਂ CRM ਵਰਤ ਰਹੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਬੁਲਾਓ। ਇਹ ਮਿਕਸ ਤੁਹਾਡੇ ਨਾਲਫ਼ੀਡਬੈਕ ਨੂੰ ਸਿਰਫ ਪਾਵਰ ਯੂਜ਼ਰਾਂ ਤੋਂ ਆਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਅਤੇ ਬਹੁਤ ਨੇੜਲੇ ਦੋਸਤਾਂ 'ਤੇ ਹੀ ਨਿਰਭਰ ਨਾ ਰਹੋ—ਉਹ ਮਿੱਠਾ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ।
ਇਨਸੈਂਟਿਵ ਸਧਾਰਨ ਮਹਿਸੂਸ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਜੀਬ ਨਹੀਂ। ਇੱਕ ਛੋਟੀ ਫਿਕਸ ਰਕਮ “ਜੋ ਤੁਸੀਂ ਸੋਚੋ ਉਸ ਮੁਤਾਬਕ ਭੂਗਤਾਨ ਕਰੋ” ਨਾਲੋਂ ਚੰਗੀ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਮੁਫ਼ਤ ਮਹੀਨਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਕਿਸੇ ਖਰੀਦ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦਾ।
ਅੰਤ ਵਿੱਚ, ਬੈਕਅਪ ਬੁੱਕ ਕਰੋ। ਤੁਹਾਨੂੰ ਜ਼ਿਆਦਾ ਲੋਕ ਭਰਤੀਆਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ (ਉਦਾਹਰਨ: ਜਿੰਨੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਉਸ ਤੋਂ ਦੋ ਵੱਧ) ਕਿਉਂਕਿ ਕੋਈ-ਕੋਈ ਨੋ-ਸ਼ੋ ਹੁੰਦੇ ਹਨ।
ਟਾਈਮ ਬਚਾਉਣ ਲਈ ਸਕਰੀਨਿੰਗ, ਸ਼ਡਿਊਲਿੰਗ ਅਤੇ ਸਹਿਮਤੀ ਨੂੰ ਇੱਕ ਛੋਟੀ ਪ੍ਰਕਿਰਿਆ ਵਾਂਗ ਕਰੋ। ਇਹ ਪੱਕਾ ਕਰੋ ਕਿ ਉਹ ਤੁਹਾਡੇ ਅਸਲ ਯੂਜ਼ਰ ਵਰਗੇ ਹਨ, ਟਾਈਮ ਬੁੱਕ ਕਰੋ, ਅਤੇ ਰਿਕਾਰਡਿੰਗ ਅਤੇ ਨੋਟ-ਲੇਣ ਬਾਰੇ ਸਪਸ਼ਟਤਾ ਪਹਿਲਾਂ ਹੀ ਦਿਓ।
ਹਲਕੀ ਸਕ੍ਰੀਨਰ ਸਿਰਫ ਤਿੰਨ ਸਵਾਲ ਹੋ ਸਕਦਾ ਹੈ:
ਚੇਤਾਵਨੀ ਲਈ ਨਿਸ਼ਾਨ ਵੇਖੋ ਜਿਹੜੇ ਸੈਸ਼ਨਾਂ ਨੂੰ ਬਰਬਾਦ ਕਰ ਸਕਦੇ ਹਨ। ਜੋ ਬਹੁਤ ਦੂਰ ਹਨ, ਉਹ ਗੱਲਾਂ ਦੇ ਫੈਸਲੇ ਦੇਣਗੇ ਜੋ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ। ਜਿਨ੍ਹਾਂ ਦਾ ਜ਼ਿਆਦਾ ਰੁਝਾਨ ਹੈ (ਨੇੜੇ ਦੋਸਤ, ਸਾਥੀ, ਜਾਂ ਕੋਈ ਜੋ ਇਕੋ ਚੀਜ਼ ਬਣਾ ਰਿਹਾ ਹੋਵੇ) ਉਹ ਨਿੱਜੀ ਏਜੰਞਾ ਰੱਖ ਸਕਦੇ ਹਨ। ਜੋ ਬਹੁਤ ਵਿਅਸਤ ਹਨ, ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਕਰਕੇ, ਬਹੁਤ ਕੰਮ-ਕਾਜ ਕਰਕੇ, ਜਾਂ ਨਾ-ਅਪਣਾਂਗੇ।
ਸ਼ਡਿਊਲਿੰਗ ਲਈ, ਕਸੇ ਬੰਦੋਬਸਤ ਰੱਖੋ: 30 ਮਿੰਟ ਸੈਸ਼ਨ ਅਤੇ 15 ਮਿੰਟ ਬਫਰ। ਬਫਰ ਵਿੱਚ ਤੁਸੀਂ ਸਾਫ ਨੋਟਸ ਲਿਖਦੇ ਹੋ, ਰਿਕਾਰਡਿੰਗ ਨਾਂ ਰੱਖਦੇ ਹੋ, ਅਤੇ ਪ੍ਰੋਟੋਟਾਈਪ ਰੀਸੈਟ ਕਰਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਕਾਲਾਂ ਬਿਨਾ ਬਫਰ ਸਧੇਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਨੋਟਸ ਘੱਟ ਗੁਣਵੱਤਾ ਵਾਲੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਪੈਟਰਨਾਂ ਮਿਸ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਸਹਿਮਤੀ ਇੱਕ ਛੋਟੀ ਸਨੇਹਕੀ ਹੋ ਸਕਦੀ ਹੈ: ਰਿਕਾਰਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਮੰਗੋ, ਦੱਸੋ ਕਿ ਨੋਟਸ ਉਤਪਾਦ ਸੁਧਾਰ ਲਈ ਵਰਤੇ ਜਾਣਗੇ, ਅਤੇ ਕੋਟਸ ਨੂੰ ਐਨੋਨੀਮਾਈਜ਼ ਕੀਤਾ ਜਾਵੇਗਾ ਜੇ ਸਾਂਝੇ ਕੀਤੇ ਜਾਣ। ਇੱਕ ਆਸਾਨ opt-out ਦਿਓ: ਉਹ ਰਿਕਾਰਡਿੰਗ ਲਈ ਨਾ ਕਹਿ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਹਸੀਂ ਨੋਟ ਲੈ ਲਵੋਗੇ।
ਇੱਕ ਸਾਦਾ ਪ੍ਰੀ-ਕਾਲ ਸੁਨੇਹਾ ਭੇਜੋ ਜਿਸ ਵਿੱਚ ਸਮਾਂ, ਉਮੀਦਿਤ ਲੰਬਾਈ, ਅਜੰਞਾ (5 ਮਿੰਟ ਇੰਟਰੋ, 20 ਮਿੰਟ ਟਾਸਕ, 5 ਮਿੰਟ ਰੈਪ-ਅਪ), ਅਤੇ ਉਹਨਾਂ ਦੀ ਲੋੜ (ਲੈਪਟੌਪ ਬਨਾਮ ਫੋਨ, ਲੌਗਿਨ ਜੇ ਲੋੜੀਂਦਾ, ਸ਼ਾਂਤ ਥਾਂ). ਇਹ “ਮੈਂ ਮੋਬਾਈਲ ਤੇ ਜੁੜਿਆ” ਵਾਲੇ ਆਚਜੇਕਟਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਪ੍ਰੋਟੋਟਾਈਪ ਟੈਸਟਿੰਗ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹਨ।
ਚੰਗਾ ਇੰਟਰਵਿਊ ਵੀ ਫਿਰ ਵੀ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਪ੍ਰੋਟੋਟਾਈਪ ਗੰਦਾ ਹੋਵੇ। ਲਕ਼ਸ਼ ਇੰਪ੍ਰੈਸ ਕਰਨ ਦਾ ਨਹੀਂ—ਉਹ ਹੈ ਕਿ ਉਹਨਾਂ ਲਈ ਟਾਸਕਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ ਬਿਨਾਂ ਉਡੀਕ ਦੇ ਜਾਂ ਤੁਹਾਡੀ ਵਿਆਖਿਆ ਦੀ ਲੋੜ ਪਏ।
ਪ੍ਰੋਟੋਟਾਈਪ ਛੋਟਾ ਰੱਖੋ। ਸਿਰਫ ਉਹ ਸਕ੍ਰੀਨ ਅਤੇ ਰਸਤੇ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਟਾਸਕ ਲਈ ਜ਼ਰੂਰੀ ਹਨ, ਅਤੇ ਬਾਕੀ ਛੁਪਾਓ। ਇੱਕ ਛੋਟਾ ਰਸਤਾ ਆਧੂਰੇ "ਫੁੱਲ ਐਪ" ਤੋਂ ਜ਼ਿਆਦਾ ਬਿਹਤਰ ਹੈ।
ਸਮੱਗਰੀ ਨੂੰ ਵਾਸਤਵਿਕ ਮਹਿਸੂਸ ਕਰਵਾਓ। Lorem ipsum ਦੀ ਥਾਂ ਵਿਸ਼ਵਾਸਯੋਗ ਕਾਪੀ ਅਤੇ ਡੇਟਾ ਰੱਖੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵਿਤ ਹੋਣ। ਜੇ ਤੁਸੀਂ CRM ਫਲੋ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ 6-10 ਸੰਪਰਕਾਂ ਦੇ ਨਾਮ, ਕੰਪਨੀ ਅਤੇ ਕੁਝ ਨੋਟਸ ਦਿਖਾਓ। ਜੇ ਚੈੱਕਆਊਟ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਹਕੀਕਤੀ ਕ਼ੀਮਤਾਂ ਅਤੇ ਡਿਲਿਵਰੀ ਚੋਣਾਂ ਦਿਓ। ਨਕਲੀ ਪਰ ਨਿਰਧਾਰਿਤ ਹਕੀਕਤ ਤੋਂ ਜ਼ਿਆਦਾ ਚੰਗਾ ਹੈ।
ਸੈਸ਼ਨਾਂ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਕੀ ਨਿਰੀਖੋ ਗੇ: ਉਹ ਪਹਿਲਾਂ ਕਿੱਥੇ ਕਲਿੱਕ ਕਰਦੇ ਹਨ, ਭੁੱਲ-ਗਲਤੀਆਂ ਦੇ ਪਲ (ਉਹ ਕੀ ਕਹਿ ਰਹੇ ਸਨ ਅਤੇ ਅਗਲੇ ਵੱਧ ਕੀ ਕੀਤਾ), ਕਿੱਥੇ ਉਹ ਘੁੰਮਦੇ ਜਾਂ ਵਾਪਸ ਆਉਂਦੇ ਹਨ, ਉਹ ਫੀਚਰਾਂ ਲਈ ਜੋ ਸ਼ਬਦ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਉਹ ਸਵਾਲ ਜੋ ਘਾਟ ਦਿਖਾਂਦੇ ਹਨ।
ਇੱਕ ਸਮਰਪਿਤ ਟੈਸਟ ਅਕਾਊਂਟ ਅਤੇ ਰੀਸੈਟ ਰੁਟੀਨ ਸੈਟ ਕਰੋ ਤਾਂ ਕਿ ਹਰ ਭਾਗੀਦਾਰ ਇੱਕੋ ਸਥਿਤੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੇ। ਜੇ ਪ੍ਰੋਟੋਟਾਈਪ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟੀ ਰੀਸੈਟ ਚੈੱਕਲਿਸਟ ਰੱਖੋ (ਕਾਰਟ ਖਾਲੀ ਕਰੋ, ਆਖਰੀ ਬਣਾਈ ਚੀਜ਼ ਹਟਾਓ, ਹੋਮ ਸਕ੍ਰੀਨ ਤੇ ਵਾਪਸੀ, ਲੌਗ ਆਊਟ ਅਤੇ ਦੁਬਾਰਾ ਲੌਗਿਨ)।
ਕੈਪਚਰ ਟੂਲ ਚੁਣੋ ਪਹਿਲਾਂ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਨਾਲ ਗੱਲ ਕਰਦਿਆਂ ਹੋ। ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਕਾਲ ਰਿਕਾਰਡ ਕਰੋ, ਅਤੇ ਇੱਕ ਸਾਦਾ ਨੋਟਸ ਟੈਮਪਲੇਟ ਰੱਖੋ ਜਿਸ ਵਿੱਚ ਤਿੰਨ ਕਾਲਮ ਹੋਣ: Task, Observations (ਕੀ ਹੋਇਆ), ਅਤੇ Quotes (ਠੀਕ-ਠੀਕ ਸ਼ਬਦ)। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲੇ ਸੈਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ snapshot ਲੈਣ ਨਾਲ ਦਿਨ ਦੌਰਾਨ ਅਣਚਾਹੇ ਬਦਲਾਅ ਵਾਪਸ ਕਰਨ ਵਿੱਚ ਆਸਾਨੀ ਰਹਿੰਦੀ ਹੈ।
ਇੱਕ ਚੰਗੀ ਟਾਸਕ ਸਕ੍ਰਿਪਟ ਲੋਕਾਂ ਨੂੰ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀ ਹੈ, ਨ ਕਿ ਟੈਸਟ ਦੀ ਤਰ੍ਹਾਂ। ਇਸਨੂੰ ਛੋਟਾ, ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਅਤੇ ਇਕ ਮੁੱਖ ਸਿਨਾਰਿਓ ਨਾਲ ਜੁੜਿਆ ਰੱਖੋ। ਇੱਕ ਵਰਕਿੰਗ ਪ੍ਰੋਟੋਟਾਈਪ ਲਈ ਆਮ ਤੌਰ 'ਤੇ 2 ਤੋਂ 4 ਟਾਸਕ ਕਾਫ਼ੀ ਹਨ ਤਾਂ ਕਿ ਪੈਟਰਨ ਨਿਕਲ ਜਾਣ ਪਰ ਰੁਸ਼ ਨਹੀਂ ਹੋਵੋ।
ਮੁੱਖ ਸਿਨਾਰਿਓ ਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਨਾਂ ਦਿਓ (ਉਦਾਹਰਣ: “ਮੈਂ ਆਪਣਾ ਪਹਿਲਾ ਪ੍ਰੋਜੈਕਟ ਸੈਟਅਪ ਕਰਕੇ ਇੱਕ ਟੀਮ-ਮੈਂਬਰ ਨੂੰ ਨਿਯੋਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ”)। ਫਿਰ ਟਾਸਕ ਚੁਣੋ ਜੋ ਉਹ ਮੋਹੜੇ ਦਰਸਾਉਂਦੇ ਹਨ ਜਿੱਥੇ ਫੇਲ੍ਹ ਹੋਣਾ ਸਭ ਤੋਂ ਨੁਕਸਾਨਦਾਇਕ ਹੋਵੇ: ਪਹਿਲੀ ਵਾਰੀ ਸੈਟਅਪ, ਇੱਕ ਮੁੱਖ ਫੀਚਰ ਲੱਭਣਾ, ਅਤੇ ਇੱਕ ਮੈਨੀਫੁਲ ਕਾਰਵਾਈ ਪੂਰੀ ਕਰਨਾ।
ਹਰ ਸੈਸ਼ਨ ਵਿੱਚ ਇੱਕੋ ਰਚਨਾ ਵਰਤੋਂ ਤਾਂ ਕਿ ਨਤੀਜੇ ਤੁਲਨਯੋਗ ਹੋਣ:
ਹਰ ਟਾਸਕ ਪ੍ਰਾਂਪਟ ਐਸਾ ਲਿਖੋ ਕਿ ਇਹ ਬਟਨ ਦਾ ਨਾਂ ਜਾਂ ਸਟੀਪ-ਬਾਈ-ਸਟੀਪ ਪਾਥ ਨਹੀਂ ਦੱਸੇ। ਮਿਸਾਲ: ਮਾੜਾ: “Click Snapshots and roll back.” ਚੰਗਾ: “ਤੁਸੀਂ ਇੱਕ ਗਲਤੀ ਕੀਤੀ ਅਤੇ ਕੱਲ੍ਹ ਦੇ ਵਰਜ਼ਨ 'ਤੇ ਵਾਪਸ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਮੈਨੂੰ ਦਿਖਾਓ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ।”
ਹਰ ਟਾਸਕ ਤੋਂ ਬਾਅਦ ਇੱਕ ਛੋਟਾ ਸਵਾਲ ਪੁੱਛੋ। ਕਲਿੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ: “ਤੁਸੀਂ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋਗੇ?” ਬਾਅਦ: “ਤੁਸੀਂ ਉਹ ਰਸਤਾ ਕਿਉਂ ਚੁਣਿਆ?” ਜੇ ਉਹ ਫਸ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਪੁੱਛੋ “ਤੁਸੀਂ ਹੁਣ ਕੀ ਲੱਭ ਰਹੇ ਹੋ?” ਨਾ ਕਿ “ਕੀ ਤੁਸੀਂ ਨੇਵੇਂ ਮੀਨੂ ਨੂੰ ਵੇਖਿਆ?”
ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਟੋਟਾਈਪ Koder.ai ਵਿੱਚ ਬਣਾਇਆ ਹੈ, ਤਾਂ ਟਾਸਕਾਂ ਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜੋ (ਐਪ ਬਣਾਓ, ਸੋਰਸ ਕੋਡ ਇਕਸਪੋਰਟ ਕਰੋ, ਕਸਟਮ ਡੋਮੇਨ ਸੈੱਟ ਕਰੋ) ਤਾਕਿ ਤੁਹਾਡੇ ਨੋਟ ਸਾਫ਼-ਸੁਥਰੇ ਬਿਲਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਬਦਲੇ ਜਾ ਸਕਣ।
ਹਰ ਸੈਸ਼ਨ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਹ ਨਰਵਸ ਨੂੰ ਘੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਤੁਲਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਨਾਲ ਖੋਲ੍ਹੋ: ਧੰਯਵਾਦ ਕਰੋ, ਵਾਰ्ता ਕਰੋ ਕਿ ਤੁਸੀਂ ਉਤਪਾਦ ਨੂੰ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ (ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ), ਅਤੇ ਕੋਈ ਗਲਤ ਜਵਾਬ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਸੋਚ-ਵੋਇਸ ਕਰਨ ਲਈ ਕਹੋ ਅਤੇ ਤੁਸੀਂ ਕਲਿੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਦੀ ਉਮੀਦ ਸੁਣੋ।
ਇੱਕ-ਇੱਕ ਟਾਸਕ ਦਿਓ ਅਤੇ ਫਿਰ ਸ਼ਾਂਤ ਰਹੋ। ਤੁਹਾਡੀ ਮੁੱਖ ਨੌਕਰੀ ਦੇਖਣਾ ਹੈ ਕਿ ਉਹ ਕਿੱਥੇ ਹਿਜੜਦੇ ਹਨ ਅਤੇ ਸੰਖੇਪ ਨਿਰਪੱਖ ਸਵਾਲ ਪੁੱਛਣੇ ਹਨ ਜਿਵੇਂ “ਤੁਸੀਂ ਕੀ ਸੋਚ ਰਹੇ ਹੋ?” ਅਤੇ “ਤੁਹਾਨੂੰ ਕੀ ਉਮੀਦ ਸੀ?” ਸਿੱਖਾਉਣ, ਤਾਰੀਫ਼ ਕਰਨ ਜਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਦੀ ਰੱਖਿਆ ਕਰਨ ਤੋਂ ਬਚੋ।
ਜਦੋਂ ਉਹ ਫਸ ਜਾਂਦੇ ਹਨ, ਰਿਸਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਰਮ ਤੌਰ 'ਤੇ ਨੋਚੋ। ਚੰਗਾ ਨਰਡ ਉਨ੍ਹਾਂ ਦੇ ਲਕੜੀ ਉੱਤੇ ਧਿਆਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਇੰਟਰਫੇਸ 'ਤੇ: “ਹੁਣ ਤੁਸੀਂ ਅਗਲਾ ਕੀ ਟਰਾਇ ਕਰੋਗੇ?” ਜਾਂ “ਤੁਸੀਂ ਇਹ ਕਿੱਥੇ ਲੱਭੋਗੇ?” ਜੇ ਉਹ ਇੱਕ ਮਿੰਟ ਤੋਂ ਵੱਧ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਲੌਕ ਹਨ, ਤਾ ਅੱਗੇ ਵਧੋ ਅਤੇ ਇਸਨੂੰ ਉੱਚ-ਗੰਭੀਰਤਾ ਮੁੱਦੇ ਵਜੋਂ ਨੋਟ ਕਰੋ। ਮਿਡ-ਕਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਸੁਧਾਰ ਕਰਨ ਦੀ ਆਵਸ਼ਕਤਾ ਤੋਂ ਬਚੋ। ਇਸ ਨੂੰ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਸੈਸ਼ਨ ਨੂੰ ਚਲਦੇ ਰਹੋ।
ਫੀਚਰ ਰਿਕਵੈਸਟ ਉਪਯੋਗੀ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ 'ਤੇ ਬਹਿਸ ਨਾ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ ਇਕ ਸਵਾਲ ਨਾਲ ਪਾਰੱਕ ਕਰੋ: “ਉਹ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰੇਗਾ?” ਫਿਰ ਮੌਜੂਦਾ ਟਾਸਕ 'ਤੇ ਵਾਪਸ ਆ ਜਾਓ।
ਨਿਰੰਤਰ ਤੌਰ 'ਤੇ ਬੰਦ ਕਰੋ। ਪੁੱਛੋ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕੀ ਪਸੰਦ ਆਇਆ, ਕੀ ਨਿਰਾਸ਼ ਕੀਤਾ, ਕੀ ਉਹ ਭੁਗਤਾਨ ਕਰਨਗੇ (ਅਤੇ ਕੀ ਗੁਣ-ਘੱਟ ਮਹਿਸੂਸ ਹੋ ਰਿਹਾ), ਅਤੇ ਕਿ ਕੀ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਗਲੇ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਸੰਪਰਕ ਕਰ ਸਕਦੇ ਹੋ।
ਚੰਗੀਆਂ ਨੋਟਸ “ਜੋ ਕੁਝ ਵੀ ਹੋਇਆ” ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਛੋਟੇ, ਲਗਾਤਾਰ ਯੂਨਿਟ ਹੋਣਗੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਕਰ ਸਕੋ। ਜੇ ਤੁਸੀਂ ਸਾਰਿਆਂ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਓਹੀ ਬਣਤਰ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੀਜੇ ਇੰਟਰਵਿਊ ਦੇ ਬਾਅਦ ਪੈਟਰਨ ਸਪੱਸ਼ਟ ਹੋ ਜਾਣਗੇ।
ਇੱਕ ਨੋਟਸ ਡੌਕ ਜਾਂ ਸਪ੍ਰੈਡਸ਼ੀਟ ਪਿਕ ਕਰੋ ਜੋ ਹਰ ਨਿਰੀਖਣਕਾਰ ਵਰਤੇ। ਹਰ ਟਾਸਕ ਕੋਸ਼ਿਸ਼ ਲਈ ਇੱਕ ਕਤਾਰ ਬਣਾਓ ਅਤੇ ਹਰ ਵਾਰੀ ਛੋਟੇ, ਤੱਥ-ਅਧਾਰਿਤ ਨੋਟਸ ਉਨ੍ਹਾਂ ਹੀ ਥਾਵਾਂ ਤੇ ਲਿਖੋ। ਇੱਕ ਸਧਾਰਨ ਲੇਆਊਟ:
ਟਾਈਮਸਟੈਂਪ ਤੁਹਾਨੂੰ ਰਿਕਾਰਡਿੰਗ 'ਤੇ ਵਾਪਸ ਜਾਣ ਅਤੇ ਸ਼ਬਦਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ। ਟਾਸਕ ਨੰਬਰ ਤੁਹਾਨੂੰ ਫਲੋਜ਼ ਵਿੱਚ ਮੁੱਦਿਆਂ ਨੂੰ ਮਿਲਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੋਵੇ, ਇਸਨੂੰ ਇੱਕ ਸਧਾਰਾ ਵਾਕ ਲਿਖੋ ਜੋ ਕਿਸੇ ਟੀਮਮੇਟ ਨੂੰ ਬਿਨਾਂ ਸੰਦਰਭ ਦੇ ਸਮਝ ਆ ਸਕੇ। ਮੂਲ-ਵਿਆਖਿਆ ਨਾਂ ਲਿਖੋ।
ਉਦਾਹਰਣ: “T2 06:14: Clicked ‘Save’ expecting a confirmation, but nothing changed and they asked if it worked.”
ਜਦੋਂ ਕੋਟ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋੜੋ, ਖ਼ਾਸ ਕਰਕੇ ਭਰੋਸਾ ਜਾਂ ਗੁੰਝਲ ਲਈ (“ਮੈਨੂੰ ਪਤਾ ਨਹੀਂ ਇਹ ਸੁਰੱਖਿਅਤ ਹੈ” ਜਾਂ “ਮੈਂ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰਾਂ?”)। ਕੋਟਸ ਪ੍ਰਭਾਵ ਦਿਖਾਉਂਦੇ ਹਨ ਅਤੇ ਪ੍ਰਾਇਰਟੀ ਦੇਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਟੈਗ ਛੋਟੇ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਫਿਲਟਰ ਕਰ ਸਕੋ:
ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਟੋਟਾਈਪ Koder.ai ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਤਾਂ ਨੋਟਸ ਯੂਜ਼ਰ ਬਿਹੇਵਿਯਰ ਅਤੇ ਉਤਪਾਦ ਵਿਹਾਰ ਉੱਤੇ ਧਿਆਨ ਰੱਖੋ, ਨਾ ਕਿ ਇਹ ਕਿ ਪ੍ਰੋਟੋਟਾਈਪ ਕਿਵੇਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ।
ਅੰਤਿਮ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਨੋਟ ਨੂੰ ਟਿਕਟ ਸਿਰਲੇਖ ਵਿੱਚ ਬਦਲ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਦੁਬਾਰਾ ਲਿਖੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਕਰ ਨਾ ਸਕੋ।
ਤੁਰੰਤ ਗਤਿਵਿਧੀ ਖੋਣੀ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਕਿ ਫੀਡਬੈਕ ਨੂੰ ਸਿਰਫ ਕੋਟਸ ਅਤੇ ਵਾਇਬਸ ਵਜੋਂ ਛੱਡਣਾ। ਜੋ ਤੁਸੀਂ ਦੇਖਿਆ ਹੈ, ਉਸ ਨੂੰ ਐਸਾ ਬਦਲੋ ਜੋ ਇੱਕ ਬਣਾਉਣ ਵਾਲਾ ਬਿਨਾਂ ਅੰਦਾਜ਼ੇ ਦੇ ਹੀ ਕਰ ਸਕੇ।
ਮੁਦਿਆਂ ਨੂੰ ਟਾਸਕ ਅਨੁਸਾਰ ਗਰੁੱਪ ਕਰੋ, ਨ ਕਿ ਵਿਅਕਤੀ ਅਨੁਸਾਰ। ਜੇ ਤਿੰਨ ਲੋਕ “ਖਾਤਾ ਬਣਾਉ” ਦੌਰਾਨ ਫਸ ਗਏ, ਤਾਂ ਉਹ ਇੱਕ ਸਮੱਸਿਆ ਹੈ ਜਿਸਦੇ ਕਈ ਡੇਟਾ ਪੌਇੰਟ ਹਨ, ਨ ਕਿ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਰਾਏ।
ਹਰ ਮੁੱਦੇ ਲਈ ਇੱਕ ਸਧਾਰਨ ਬੇਨਤੀ ਫਾਰਮੈਟ ਵਰਤੋਂ:
“ਵਰਡਿੰਗ ਅਤੇ ਸਪੱਸ਼ਟਤਾ” ਸੁਧਾਰਾਂ ਨੂੰ “ਸਕੋਪ” ਬਦਲਾਅ ਤੋਂ ਅਲੱਗ ਰੱਖੋ। “ਮੈਂ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਇਹ ਬਟਨ ਕੀ ਕਰਦਾ ਹੈ” ਅਕਸਰ ਲੇਬਲ ਜਾਂ ਪਲੇਸਮੈਂਟ ਦਾ ਮੁੱਦਾ ਹੁੰਦਾ ਹੈ। “ਮੈਨੂੰ exports, roles, ਅਤੇ approvals ਚਾਹੀਦੇ ਹਨ” ਇਕ ਵੱਡਾ ਪ੍ਰੋਡਕਟ ਫੈਸਲਾ ਹੈ। ਇਸਨੂੰ ਮਿਲਾਉਂਦੇ ਹੋਏ ਟਿਕਟਾਂ ਭਾਰੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਫਿਰ ਹਰ ਮੁੱਦੇ 'ਤੇ ਫੈਸਲਾ ਕਰੋ: ਹੁਣੀ ਫਿਕਸ ਕਰੋ, ਫਿਰ-ਟੈਸਟ ਕਰੋ, ਜਾਂ ਬਾਅਦ ਲਈ ਪਾਰਕ ਕਰੋ। ਇੱਕ ਸਧਾਰਨ ਆਰਡਰਿੰਗ ਤਰੀਕਾ ਹੈ: ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ, ਕੋਸ਼ਿਸ਼ (ਇਫੋਰਟ), ਵਿਸ਼ਵਾਸ (ਕੀ ਇਹ ਦੁਹਰਾਇਆ ਗਿਆ?), ਅਤੇ ਅਗਲਾ ਕਾਰਵਾਈ (build, re-test, park)।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ acceptance ਚੈੱਕ ਨੂੰ ਸਧਾਰਣ ਅੰਗ੍ਰੇਜ਼ੀ ਵਿੱਚ ਲਿਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਆਪਣੀ ਬਿਲਡ ਚੈਟ ਵਿੱਚ ਸਿੱਧਾ ਪੇਸਟ ਕਰ ਸਕੋ।
ਇੱਕ ਗੈਰ-ਟੈਕਨਿਕਲ ਫਾਊਂਡਰ ਨੇ Koder.ai ਵਿੱਚ ਇੱਕ ਸਧਾਰਣ CRM ਆਨਬੋਰਨਿੰਗ ਫਲੋ ਬਣਾਇਆ, ਫਿਰ ਅਗਲੇ ਦਿਨ ਯੂਜ਼ਰ ਇੰਟਰਵਿਊ ਚਲਾਏ। ਲਕ਼ਸ਼ ਤੰਗ ਸੀ: ਕੀ ਇੱਕ ਸੇਲਜ਼ ਰੈਪ “ਪਹਿਲਾ ਡੀਲ ਬਣਾਇਆ” ਬਿਨਾਂ ਮਦਦ ਦੇ ਕਰ ਸਕਦਾ ਹੈ।
ਭਰਤੀ ਤੇਜ਼ ਸੀ: ਉਹਨਾਂ ਨੇ ਆਪਣੀ ਨੈਟਵਰਕ ਅਤੇ ਕੁਝ ਲੋਕੀ ਸੇਲਜ਼ ਕਮਿਊਨਿਟੀਆਂ ਨੂੰ ਸੁਨੇਹਾ ਭੇਜਿਆ, ਛੋਟਾ ਗਿਫਟ ਕਾਰਡ ਦिता। ਪੰਜ ਸੇਲਜ਼ ਰੈਪ ਨੇ ਇਕ ਦੁਪਹਿਰ ਵਿੱਚ 20-ਮਿੰਟ ਸਲਾਟ ਬੁੱਕ ਕੀਤੇ।
ਹਰ ਸੈਸ਼ਨ ਇੱਕੋ ਤਿੰਨ ਟਾਸਕ ਵਰਤਦਾ, ਸ਼ਬਦ-ਬ-ਸ਼ਬਦ ਪੜ੍ਹੇ:
ਪੰਜ ਸੈਸ਼ਨਾਂ ਵਿੱਚ, ਉਹਨਾਂ ਨੇ ਦੁਹਰਾਏ ਹੋਏ ਮੁੱਦੇ ਅਤੇ ਕੁਝ ਬਲਾਕਰ ਲਿਖੇ। ਦੋ ਰੈਪ ਇੰਪੋਰਟ ਲੱਭਣ ਵਿੱਚ ਅਸਮਰੱਥ ਸਨ। ਤਿੰਨ ਰੈਪ ਸੋਚਦੇ ਸਨ ਕਿ “Reminder” ਇੱਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸੈਟਿੰਗ ਹੈ, ਫਾਲੋ-ਅਪ ਨਹੀਂ।
ਦਿਨ ਦੇ ਅੰਤ ਤੱਕ, ਉਹ ਨਿਰੀਖਣ ਬਿਲਡ ਬੇਨਤੀਆਂ ਵਿੱਚ ਅਜੇਹੀਆਂ ਬਣ ਗਈਆਂ:
ਇਹੀ ਮਕਸਦ ਹੈ: ਇਕੋ ਜਿਹੇ ਟਾਸਕ, ਦੁਹਰਾਏ ਪੈਟਰਨ, ਅਤੇ ਇੰਨੇ ਸਪਸ਼ਟ ਟਿਕਟ ਜਿੰਨ੍ਹਾਂ ਨੂੰ ਇੱਕੋ ਦਿਨ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਜਾ ਸਕੇ।
ਜ਼ਿਆਦਾਤਰ ਖਰਾਬ ਨਤੀਜੇ ਕੁਝ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਨ ਕਿ ਪ੍ਰੋਟੋਟਾਈਪ ਸਵੈ-ਵਿੱਚ।
ਲਿਡਿੰਗ ਸਵਾਲ ਜਿਵੇਂ “ਇਹ ਸਮਝ ਆਉਂਦਾ ਹੈ, ਹੈ ਨਾ?” ਨਰਮ ਸਹਿਮਤੀ ਲੈ ਲੈਂਦੇ ਹਨ। ਨਿਰਪੱਖ ਪ੍ਰੰਪਟ ਵਰਤੋਂ ਜਿਵੇਂ “ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਇਹ ਕੀ ਕਰਦਾ ਹੈ?” ਅਤੇ ਫਿਰ ਚੁੱਪ ਰਹੋ।
ਇੱਕ ਸੈਸ਼ਨ ਵਿੱਚ ਬਹੁਤ ਕੁਝ ਟੈਸਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਸਭ ਸਤਹੀ ਰਾਏਆਂ ਅਤੇ ਕਮਜ਼ੋਰ ਸੰਕੇਤ ਮਿਲਦੇ ਹਨ। 2-3 ਕੋਰ ਫਲੋਜ਼ ਚੁਣੋ।
ਮਧ-ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਬਦਲਣਾ ਤੁਲਨਯੋਗਤਾ ਤੋੜਦਾ ਹੈ। ਨਵੀਆਂ ਸੋਚਾਂ ਨੂੰ ਬੈਕਲੌਗ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਟਾਸਕ ਸਥਿਰ ਰੱਖੋ।
ਗੰਦੇ ਨੋਟਸ ਹੋਰ ਇਕ ਚੁਪਕਾ ਨੁਕਸਾਨ ਹਨ। ਜੇ ਤੁਸੀਂ ਯਾਦ 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮਜ਼ੇਦਾਰ ਹਿਸਿਆਂ ਨੂੰ ਯਾਦ ਰੱਖੋਗੇ, ਨ ਕਿ ਦਰਦਨਾਕ ਹਿੱਸਿਆਂ ਨੂੰ। ਉਸ ਸਟੈਪ ਨੂੰ ਲਿਖੋ ਜਿੱਥੇ ਉਹ ਫਸੇ ਅਤੇ ਉਹਨਾਂ ਨੇ ਅਗਲੇ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ।
ਇੱਕ ਸਧਾਰਨ ਹਕੀਕਤ-ਚੈੱਕ: ਜੇ ਭਾਗੀਦਾਰ ਕਹਿ ਦਿੰਦਾ “ਵਧੀਆ ਲੱਗਦਾ ਹੈ” ਪਰ ਅਗਲਾ ਬਟਨ ਲੱਭਣ ਵਿੱਚ 90 ਸਕਿੰਟ ਲਗਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਦੀ ਕਰਵਾਈ ਅਸਲੀ ਡੇਟਾ ਹੈ। ਤਾਰੀਫ਼ ਸ਼ੋਰ ਹੈ।
ਇੱਕ ਉੱਚੀ ਆਵਾਜ਼ ਵਾਲੀ ਰਾਏ ਯੋਜਨਾ ਬਣ ਸਕਦੀ ਹੈ। ਤਦੇ ਸਖਤ ਰਾਏ ਨੂੰ ਇੱਕ ਹਾਈਪੋਥਿਸਿਸ ਮੰਨੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇੱਕੋ ਮਸਲੇ ਨੂੰ ਕਈ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਨਹੀਂ ਵੇਖਦੇ।
ਜੇ ਤੁਸੀਂ ਵੱਡੇ ਸੋਧ ਕਰਦੇ ਹੋ, ਤਾਂ ਜਲਦੀ ਤੋਂ ਰੀ-ਟੈਸਟ ਕਰੋ। ਦੋ ਛੋਟੀਆਂ ਸੈਸ਼ਨ ਵੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿ ਤੁਸੀਂ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਪਹਿਲੀ ਕਾਲ ਬੁੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਖ ਚੀਜ਼ਾਂ ਲਾਕ ਕਰੋ:
ਹਰ ਸੈਸ਼ਨ ਤੁਰੰਤ ਬਾਅਦ, ਤਿੰਨ ਮਿੰਟ ਦੀ ਚੈੱਕ ਕਰੋ: ਆਪਣੀ ਟੌਪ ਤਿੰਨ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਇੱਕ ਹੈਰਾਨੀ ਲਿਖੋ। ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਦਾ ਨਾਂ ਨਹੀਂ ਲੈ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਟਾਸਕ ਬਹੁਤ ਵਿਸ਼ਾਲ ਹੋ ਸਕਦੇ ਹਨ ਜਾਂ ਨੋਟਸ ਬਹੁਤ vague ਹਨ।
ਉਸੇ ਦਿਨ ਇੱਕ ਛੋਟੀ ਰੈਪ-ਅਪ ਕਰੋ ਜੋ ਰਾ-ਨੋਟਸ ਨੂੰ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲੇ। ਸਮਾਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰੋ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ ਚੁਣੋ, ਅਤੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਅਗਲੇ ਕੀ ਬਦਲਾਂਗੇ।
ਫਿਰ ਫਿਕਸ ਸ਼ਿਪ ਕਰਨ ਤੋਂ 72 ਘੰਟਿਆਂ ਦੇ ਅੰਦਰ ਰੀ-ਟੈਸਟ ਦੀ ਸ਼ਡਿਊਲ ਬਣਾਓ। ਇੱਥੇ ਤਕ ਕਿ ਤਿੰਨ ਛੋਟੇ ਸੈਸ਼ਨ ਵੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਬਦਲਾਅ ਕੰਮ ਕਰ ਰਹੇ ਨੇ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਿੱਚ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਤੁਹਾਨੂੰ ਨਤੀਜੇ ਸਪੇਕਡ ਟਾਸਕਾਂ ਵਾਂਗ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ (“Change X so user can do Y without Z”), ਅਤੇ snapshots ਬਿਨਾ ਇੱਕ ਸਥਿਰ ਵਰਜ਼ਨ ਗੁਆਉਂਦੇ ਤੇਜ਼ੀ ਨਾਲ ਫਿਕਸ آزمਾਉਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਲਕ਼ਸ਼: 3 ਤੋਂ 5 ਸੈਸ਼ਨ। ਤਿੰਨ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਰੁਕਾਵਟਾਂ ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ਪੰਜ ਅਕਸਰ ਪੈਟਰਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਾਫੀ ਹੁੰਦੇ ਹਨ। ਜੇ ਇਕੋ ਦੋ ਮੁੱਖ ਮਾਮਲੇ ਤਿੰਨ ਸੈਸ਼ਨ ਲਗਾਤਾਰ ਦੁਹਰਾਏ ਜਾਣ, ਤਾਂ ਜਲਦੀ ਰੁਕੋ ਅਤੇ ਬਿਲਡ/ਰਿਟੈਸਟ ਤੇ ਵਾਪਸ ਜਾਓ।
ਇੱਕ ਵਾਕ ਜੋ ਯੂਜ਼ਰ, ਟਾਸਕ ਅਤੇ ਮਾਪਯੋਗ ਮਾਪਦੰਡ ਦੱਸੇ। ਇੱਕ ਅੱਤ ਸਧਾਰਨ ਫਾਰਮੈਟ: “ਕੀ ਇੱਕ ਪਹਿਲੀ ਵਾਰੀ ਵਾਲਾ [ਯੂਜ਼ਰ ਟਾਈਪ] ਬਿਨਾਂ ਮਦਦ ਦੇ [ਟਾਸਕ] ਨੂੰ [ਸਮਾਂ] ਵਿੱਚ ਕਰ ਸਕਦਾ ਹੈ?” ਇਹ ਸੈਸ਼ਨ ਨੂੰ ਵੱਖ-ਵੱਖ ਬਿਹੇਵਿਯਰ ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦਾ ਹੈ।
ਪ੍ਰਤੀ ਸੈਸ਼ਨ ਲਈ 2 ਤੋਂ 4 ਟਾਸਕ ਚੁਣੋ ਜੋ ਇੱਕ ਫਲੋ ਦੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ ਮੋਹੜਿਆਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ—ਜਿਵੇਂ ਪਹਿਲੀ ਵਾਰੀ ਸੈਟਅਪ ਜਾਂ ਇੱਕ ਮੈਨੀਫੁਲ ਐਕਸ਼ਨ ਮੁਕੰਮਲ ਕਰਨਾ। ਟਾਸਕ ਨਤੀਜਾ-ਆਧਾਰਿਤ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇਹ ਟੈਸਟ ਕਰੋ ਕਿ ਲੋਕ ਕਾਮਯਾਬ ਹੋ ਰਹੇ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਹ ਕਿ ਉਹ ਕਿਸੇ ਖਾਸ ਬਟਨ ਨੂੰ ਲੱਭ ਲੈਂ।
ਸ਼ੁਰੂਆਤ ਤੇਜ਼ ਸਰੋਤਾਂ ਨਾਲ ਕਰੋ: ਉਤਪਾਦ ਦੇ ਨੇੜਲੇ ਲੋਕ ਜਿਵੇਂ ਟ੍ਰਾਇਲ ਯੂਜ਼ਰ, ਵੈਟਲਿਸਟ, ਹਾਲੀਆ ਸਹਾਇਤਾ ਸੂਤਰ ਜਾਂ ਡੈਮੋ ਅਨੁਰੋਧ। ਨਿਮੰਤਰਣ ਛੋਟਾ ਅਤੇ ਸਪਸ਼ਟ ਰੱਖੋ—ਇਹ ਵਿਕਰੀ ਕਾਲ ਨਹੀਂ ਹੈ, 20 ਮਿੰਟ, 2-3 ਟਾਸਕ, ਅਤੇ ਛੋਟਾ ਇਨਾਮ ਦਿਓ। ਦੋ ਨਿਸ਼ਚਿਤ ਸਮਾਂ-ਵਿਕਲਪ ਦਿਓ ਤਾਹੀਂ ਸੰਚਾਰ ਘੱਟ ਹੋਵੇ।
ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਸਕ੍ਰੀਨਰ ਵਿੱਚ ਤਿੰਨ ਸਵਾਲ ਹੋ ਸਕਦੇ ਹਨ: ਉਹ ਅੱਜ ਇਸ ਸਮੱਸਿਆ ਲਈ ਕੀ ਵਰਤਦੇ ਹਨ, ਆਖਰੀ ਵਾਰ ਉਹ ਕੀ ਕੀਤਾ ਸੀ ਅਤੇ ਕਿੜਾ ਰੋਲ ਉਹ ਨਿਭਾਂਦੇ ਹਨ। ਜਿਹੜੇ ਟਾਰਗੇਟ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹਨ, ਜ਼ਿਆਦਾ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ (ਜਿਵੇਂ ਨਜ਼ਦੀਕੀ ਦੋਸਤ ਜਾਂ ਮੁਕਾਬਲੇ), ਜਾਂ ਬਹੁਤ ਵਿਅਸਤ ਹਨ—ਉਹ ਚੁਣਨ ਤੋਂ ਬਚੋ।
ریکਾਰਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਪੁੱਛੋ, ਦੱਸੋ ਕਿ ਰਿਕਾਰਡਿੰਗ ਅਤੇ ਨੋਟ ਕਿਵੇਂ ਉਤਪਾਦ ਨੂੰ ਬਿਹਤਰ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਣਗੇ, ਅਤੇ ਕਹੋ ਕਿ ਜੇ ਤੁਸੀਂ ਸਿੱਟੇ ਸਾਂਝੇ ਕਰੋਗੇ ਤਾਂ ਉਨ੍ਹਾਂ ਦੇ ਕੋਟਸ ਐਨੋਨੀਮਾਈਜ਼ ਕੀਤੇ ਜਾਣਗੇ। ਸਪੱਸ਼ਟ opt-out ਦਿਓ: ਉਹ ਦੁਬਾਰਾ ਰਿਕਾਰਡਿੰਗ ਨੂੰ ਮਨਜ਼ੂਰ ਨਾ ਕਰਨ ਤਾਂ ਵੀ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ ਤੇ ਤੁਸੀਂ ਨੋਟ ਲੈ ਲਵੋਗੇ।
ਸਿਰਫ ਉਹ ਸਕਰੀਨ ਅਤੇ ਰਸਤੇ ਰੱਖੋ ਜੋ ਤੁਹਾਡੇ ਟਾਸਕ ਲਈ ਲੋੜੀਂਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਛुपਾਓ। Lorem ipsum ਦੀ ਥਾਂ ਹਕੀਕਤੀ ਵਰਗਾ ਟੈਕਸਟ ਅਤੇ ਡੇਟਾ ਦਿਓ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਪ੍ਰਾਕ੍ਰਿਤਿਕ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਆ ਦੇਣ। ਇੱਕ ਟੈਸਟ ਅਕਾਉਂਟ ਬਣਾਓ ਅਤੇ ਕਾਇਮ ਰੀਸੈਟ ਰੁਟੀਨ ਰੱਖੋ ਤਾਂ ਹਰ ਭਾਗੀਦਾਰ ਇੱਕੋ ਸਟੇਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੇ।
ਹਰ ਸੈਸ਼ਨ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਖੋਲ੍ਹੋ: ਧੰਨਵਾਦ, ਦੱਸੋ ਕਿ ਅਸੀਂ ਉਤਪਾਦ ਨੂੰ ਟੈਸਟ ਕਰ ਰਹੇ ਹਾਂ (ਉਨ੍ਹਾਂ ਨੂੰ ਨਹੀਂ), ਅਤੇ ਕੋਈ ਗਲਤ ਜਵਾਬ ਨਹੀਂ ਹੈ। ਇੱਕ-ਇੱਕ ਟਾਸਕ ਦਿਓ ਅਤੇ ਫਿਰ ਚੁੱਪ ਰਹੋ। ਨਰਟਿਵ ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ ਜਿਵੇਂ “ਤੁਸੀਂ ਹੁਣ ਕੀ ਸੋਚ ਰਹੇ ਹੋ?” ਜਾਂ “ਤੁਹਾਨੂੰ ਕੀ ਉਮੀਦ ਸੀ?” ਸਿੱਖਾਉਣ ਜਾਂ ਬਚਾਉਣ ਤੋਂ ਬਚੋ।
ਹਰ ਟਾਸਕ ਕੋਸ਼ਿਸ਼ ਲਈ ਇੱਕ ਕਤਾਰ ਬਣਾਓ: ਉਨ੍ਹਾਂ ਨੇ ਕੀ ਕੀਤਾ, ਉਹ ਕੀ ਉਮੀਦ ਕਰ ਰਹੇ ਸਨ, ਅਤੇ ਕੀ ਹੋਇਆ—ਇੱਕ ਜਥੇਦਾਰ ਕੋਟ ਜਦੋਂ ਲੋੜੀਏ। ਇੱਕ ਸਾਦਾ severity ਟੈਗ ਰੱਖੋ (blocker, slows down, minor) ਤਾਂ ਕਿ ਤੁਸੀਂ ਤੁਰੰਤ ਪ੍ਰਾਇਰਟੀ ਕਰ ਸਕੋ।
ਹਰ ਦੁਹਰਾਏ ਮਸਲੇ ਨੂੰ ਇੱਕ ਬਿਲਡ ਬੇਨਤੀ ਵਿੱਚ ਬਦਲੋ ਜਿਸ ਵਿੱਚ 5 ਹਿੱਸੇ ਹੋਣ: ਸਮੱਸਿਆ, ਗਵਾਹੀ (ਉਬਜੈਕਟਿਵ ਨੋਟ ਜਾਂ ਕੋਟ + ਕਿੱਥੇ ਹੋਇਆ), ਪ੍ਰਭਾਵ, ਸੁਝਾਈ ਗਈ ਬਦਲਾਅ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ acceptance ਚੈੱਕ ਜੋ ਅਗਲੇ ਟੈਸਟ ਵਿੱਚ ਵਰਿਫ਼ਾਈ ਹੋ ਸਕੇ। ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਟਾਸਕ-ਅਧਾਰਿਤ ਸਮੂਹਬੱਧ ਕਰੋ ਤਾਂ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਪੰਜ ਵੱਖ-ਵੱਖ ਰਾਏ ਨਾ ਬਣ ਤੀ।