29 ਅਕਤੂ 2025·5 ਮਿੰਟ
Marissa Mayer ਉਤਪਾਦ ਮੈਟ੍ਰਿਕਸ: UX ਦੇ ਹੰਗਾਮੇ ਤੋਂ ਬਿਨਾਂ ਰਫ਼ਤਾਰ
ਜਾਣੋ ਕਿ Marissa Mayer ਦੇ ਉਤਪਾਦ-ਮੈਟ੍ਰਿਕਸ ਦਾ ਸੋਚ ਕਿਵੇਂ UX ਫ੍ਰਿਕਸ਼ਨ ਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜਦਾ ਹੈ, A/B ਟੈਸਟਿੰਗ ਅਨੁਸ਼ਾਸਨ ਲਗਾਉਂਦਾ ਹੈ, ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਿਨਾਂ ਹੰਗਾਮੇ ਦੇ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਛੋਟੀ UX ਫ੍ਰਿਕਸ਼ਨ ਮਹਿੰਗੀ ਕਿਵੇਂ ਪੈਂਦੀ ਹੈ
ਛੋਟੀ UX ਫ੍ਰਿਕਸ਼ਨ ਉਹ ਨਿਛੋਟੀਆਂ ਘਟਨਾਵਾਂ ਹਨ ਜੋ ਯੂਜ਼ਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਪਰ ਅਕਸਰ ਢੰਗ ਨਾਲ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰਦੇ। ਇਹ ਹੋ ਸਕਦਾ ਹੈ: ਫਾਰਮ ਵਿੱਚ ਇੱਕ ਹੋਰ ਕਦਮ, ਇੱਕ ਬਟਨ ਲੇਬਲ ਜੋ ਲੋਕਾਂ ਨੂੰ ਦੇਰ ਕਰਵਾ ਦੇਂਦਾ ਹੈ, ਇੱਕ ਪੇਜ ਜੋ ਇੱਕ ਸਕਿੰਟ ਦੇ ਲਈ ਸੌਣ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਐਰਰ ਸੁਨੇਹਾ ਜੋ ਦੱਸਦਾ ਹੀ ਨਹੀਂ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ।
ਲਾਗਤ ਤੁਹਾਡੇ ਸਕੇਲ ਵਿੱਚ ਛੁਪੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਇਕੱਲਾ ਉਲਝਣ ਦਾ ਪਲ ਸਿਰਫ ਇਕ ਵਰਤੋਂਕਾਰ ਨੂੰ ਇਕ ਵਾਰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ; ਇਹ ਹਰ ਦਿਨ ਹਰ ਵਿਟਰ ਤੇ ਦੁਹਰਦਾ ਹੈ। ਹਰ ਕਦਮ 'ਤੇ 1% ਦੀ ਗਿਰਾਵਟ ਸਾਈਨਅਪ, ਖਰੀਦਾਂ, ਜਾਂ ਪ੍ਰਯੋਗਕਾਰੀ ਮੁੜ ਵਰਤੋਂ ਵਿੱਚ ਅਰਥਪੂਰਨ ਘਾਟੀ ਵਿੱਚ ਬਣ ਜਾਂਦੀ ਹੈ।
ਕੁਝ ਫ੍ਰਿਕਸ਼ਨ ਪੈਟਰਨ ਡਿਜ਼ਾਈਨ ਰਿਵਿਊ ਵਿੱਚ ਨਿਰਦੋਸ਼ ਲੱਗਦੇ ਹਨ ਪਰ ਨਤੀਜਿਆਂ ਨੂੰ ਚੁਪਕੇ ਨਾਲ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੇ ਹਨ:
- ਉਪਭੋਗਤਾ ਨੂੰ ਮੁੱਲ ਨਜ਼ਰ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਧੂ ਜਾਣਕਾਰੀ ਮੰਗਣਾ
- ਕਾਰਵਾਈਆਂ (CTAs) ਜੋ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੀਆਂ ਹਨ
- ਖਾਸ ਕਰਕੇ ਮੋਬਾਈਲ 'ਤੇ ਆਹਰੜੀ ਪਹਿਲੀ ਸਕਰੀਨ ਲੋਡ ਹੋਣਾ
- ਬਹੁਤ ਜਲਦੀ ਖਾਤਾ ਬਣਾਉਣ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਨਾ
- ਐਰਰ ਸੁਨੇਹੇ ਜੋ ਦੱਸਦੇ ਨਹੀਂ ਕਿ ਸਮੱਸਿਆ ਕਿਵੇਂ ਠੀਕ ਕਰਨੀ ਹੈ
ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ: ਜੇ 100,000 ਲੋਕ ਮਹੀਨੇ ਵਿੱਚ ਸਾਈਨਅਪ ਫਲੋ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਦੇਰੀ ਜਾਂ ਉਲਝਣ ਵਾਲਾ ਲੇਬਲ ਪੂਰਨਤਾ 30% ਤੋਂ 28% ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ 2,000 ਸਾਈਨਅਪ ਖੋ ਬੈਠੇ ਹੋ। ਇਹ ਉਸ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਐਕਟੀਵੇਸ਼ਨ ਅਤੇ ਰੀਟੇਨਸ਼ਨ ਦੇ ਅਸਰ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰਦੇ ਹੋ, ਜਿੱਥੇ ਫ਼ਰਕ ਅਕਸਰ ਵੱਧ ਜਾਂਦਾ ਹੈ।
ਇਸੇ ਲਈ ਰਾਇਆਂ ਕਾਫੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਮਜ਼ਬੂਤ ਉਤਪਾਦ ਟੀਮਾਂ “ਇਹ ਤਕਲੀਫ਼ਦੇਹ ਲੱਗਦਾ ਹੈ” ਨੂੰ ਮਾਪਯੋਗ ਸਵਾਲ ਵਿੱਚ ਬਦਲਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਅਨੁਸ਼ਾਸਿਤ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਬਾਰ-ਬਾਰ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਉਤਪਾਤ ਦੇ, ਪਰ ਇਹੋ ਜਦੋਂ ਸੰਭਵ ਹੈ ਜਦੋਂ ਰਫ਼ਤਾਰ ਸਬੂਤ ਨਾਲ ਜੁੜੀ ਹੋਵੇ।
“Marissa Mayer ਸਟਾਈਲ” ਉਤਪਾਦ ਨੇਤ੍ਰਿਤਵ ਨਾਲ ਲੋਕ ਕੀ ਮਤਲਬ ਰੱਖਦੇ ਹਨ
ਜਦੋਂ ਲੋਕ “Marissa Mayer ਸਟਾਈਲ” ਉਤਪਾਦ ਨੇਤ੍ਰਿਤਵ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ ’ਤੇ ਇਕ ਵਿਸ਼ੇਸ਼ ਆਦਤ ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ: ਉਤਪਾਦੀ ਫੈਸਲਿਆਂ ਨੂੰ ਵਿਚਾਰ-ਵਿਵਾਦ ਬਜਾਏ ਟੈਸਟ ਕਰਨ ਯੋਗ ਪ੍ਰਸ਼ਨਾਂ ਵਾਂਗੋਂ ਦੇਖੋ। ਇਸਦਾ ਸਾਰ ਅਰਥ ਹੈ Marissa Mayer product metrics—ਇਹ ਵਿਚਾਰ ਕਿ ਛੋਟੀਆਂ UX ਚੋਣਾਂ ਨੂੰ ਵੀ ਮਾਪਿਆ ਜਾਣਾ ਚਾਹੀਦਾ, ਤੁਲਨਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਅਤੇ ਜਦੋਂ ਵਰਤੋਂਕਾਰ ਸੰਕਟ ਵਿੱਚ ਦਿਖਣ ਤਾਂ ਦੁਬਾਰਾ ਦੇਖੀ ਜਾਣੀ ਚਾਹੀਦੀ।
ਇੱਥੇ ਲਾਭਦੀ ਗੱਲ ਨਿੱਜੀਅਤ ਜਾਂ ਕਹਾਣੀ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਵਾਦੀ ਵਿਚਾਰਧਾਰਾ ਹੈ: ਕੁਝ ਸੰਕੇਤ ਚੁਣੋ ਜੋ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ, ਸਾਫ਼ ਪ੍ਰਯੋਗ ਚਲਾਓ, ਅਤੇ ਸਿੱਖਣ ਦੇ ਚੱਕਰ ਛੋਟੇ ਰੱਖੋ।
ਮਾਪਯੋਗ UX ਦਾ ਮਤਲਬ ਹੈ “ਇਹ ਫਲੋ ਨਿਰਾਸ਼ਾਜਨਕ ਹੈ” ਜਿਹੇ ਅਹਿਸਾਸ ਨੂੰ ਨਿਗਰਾਨੀਯੋਗ ਬਣਾਉਣਾ। ਜੇ ਕੋਈ ਸਕਰੀਨ ਉਲਝਣ ਵਾਲੀ ਹੈ ਤਾਂ ਇਹ ਵਰਤਾਰ ਵਿੱਚ ਦਿੱਖਦੀ ਹੈ: ਘੱਟ ਲੋਕ ਪੂਰਾ ਕਰਦੇ ਹਨ, ਜ਼ਿਆਦਾ ਲੋਕ ਵਾਪਸ ਚਲੇ ਜਾਂਦੇ ਹਨ, ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਵੱਧਦੀ ਹੈ, ਜਾਂ ਕਿਸੇ ਕਾਰਜ ਨੂੰ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
ਰਫ਼ਤਾਰ ਦੀ ਇੱਕ ਵਪਾਰਕ ਟ੍ਰੇਡ-ਆਫ ਹੁੰਦੀ ਹੈ। ਬਿਨਾਂ ਨਿਯਮਾਂ ਦੇ ਰਫ਼ਤਾਰ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀ ਹੈ। ਟੀਮਾਂ ਲਗਾਤਾਰ ਸ਼ਿਪ ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ, ਨਤੀਜੇ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਡਾਟਾ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ। ਇਹ “ਸਟਾਈਲ” ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਟਰੇਸ਼ਨ ਦੀ ਰਫ਼ਤਾਰ ਨਿਰੰਤਰ ਮਾਪ ਨਾਲ ਜੁੜੀ ਹੋਵੇ।
ਸਧਾਰਨ ਅਨੁਸ਼ਾਸਨ ਇਹ ਹੁੰਦੀ ਹੈ: ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਸਫਲਤਾ ਕੀ ਹੋਵੇਗੀ, ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਗਲਤੀਆਂ ਬਦਲੋ, ਅਤੇ ਟੈਸਟ ਮਿਆਦ ਐਨੀ ਲੰਮੀ ਰੱਖੋ ਕਿ ਯਾਦ੍ਰਚਿਕ ਉਚਾਲਾਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।
ਓਹੋ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਅਸਲ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਦਰਸਾਉਂਦੇ ਹਨ
ਚੰਗੇ ਮੈਟ੍ਰਿਕਸ ਉਹ ਹਨ ਜੋ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਵਰਤੋਂਕਾਰ ਵਾਕਈ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਕੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦਾ ਹੈ। Marissa Mayer product metrics ਦਾ ਆਧਾਰ ਸਧਾਰਨ ਹੈ: ਕੁਝ ਭਰੋਸੇਯੋਗ ਅੰਕ ਚੁਣੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਅਕਸਰ ਵੇਖੋ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਫੈਸਲਿਆਂ ਨਾਲ ਸਾਂਝਾ ਕਰਨ ਦਿਓ।
ਆਪਣੇ ਕੋਰ ਉਤਪਾਦ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਲੋਕ ਮੁੱਲ ਕਿਵੇਂ ਲੈ ਰਹੇ ਹਨ ਅਤੇ ਵਾਪਸ ਆ ਰਹੇ ਹਨ:
- Activation (ਨਵੇਂ ਯੂਜ਼ਰ ਇੱਕ ਪਹਿਲੀ ਮਾਨਤਵਪੂਰਣ ਕਾਮਯਾਬੀ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ)
- Time to value (ਉਹ ਪਹੁੰਚਣ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ)
- Retention (ਕੌਣ ਹਫ਼ਤਾ-1 ਜਾਂ ਮਹੀਨਾ-1 ਬਾਅਦ ਵਾਪਸ ਆਉਂਦਾ ਹੈ)
- Conversion (ਮੁਫ਼ਤ ਤੋਂ ਭੁਗਤਾਨ, ਟ੍ਰਾਇਲ ਤੋਂ ਐਕਟਿਵ)
- Churn (ਕੌਣ ਉਤਪਾਦ ਵਰਤਣਾ ਛੱਡ ਦਿੰਦਾ ਹੈ)
ਫਿਰ ਇੱਕ ਜਾਂ ਦੋ UX ਹੈਲਥ ਮੈਟ੍ਰਿਕਸ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਮੁੱਖ ਫਲੋਜ਼ ਵਿੱਚ ਫ੍ਰਿਕਸ਼ਨ ਦਰਸਾਉਂਦੇ ਹਨ। ਟਾਸਕ ਸੈਕਸੈਸ ਰੇਟ ਇੱਕ ਚੰਗਾ ਡੀਫਾਲਟ ਹੈ। ਇਸਨੂੰ Error rate ਜਾਂ Time on task ਦੇ ਨਾਲ ਜੋੜੋ।
ਟੈਨੋ ਸੋਚੋ ਕਿ ਲੀਡਿੰਗ ਅਤੇ ਲੈਗਿੰਗ ਸੰਕੇਤਕਾਂ ਵਿੱਚ ਵੰਡ ਕਰੋ।
ਲੀਡਿੰਗ ਸੰਕੇਤਕ ਤੇਜ਼ ਹਿਲਦੇ ਹਨ ਅਤੇ ਅੱਗੇ ਦਾ ਸੂਚਨ ਦਿੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਾਈਨਅਪ ਸਧਾਰਨ ਕਰਦੇ ਹੋ ਅਤੇ ਅਗਲੇ ਦਿਨ ਟਾਸਕ ਸਫਲਤਾ 72% ਤੋਂ 85% ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਫਲੋ ਸੁਧਾਰਿਆ।
ਲੈਗਿੰਗ ਸੰਕੇਤਕ ਲੰਮੇ ਸਮੇਂ ਦਾ ਪ੍ਰਭਾਵ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਹਫ਼ਤੇ-4 ਰੀਟੇਨਸ਼ਨ। ਇਹ ਤੁਰੰਤ ਨਹੀਂ ਦਿੱਖਦਾ, ਪਰ ਅਕਸਰ ਅਸਲ ਮੁੱਲ ਇੱਥੇ ਹੀ ਨਿਕਲਦਾ ਹੈ।
ਵੈਨੀਟੀ ਮੈਟ੍ਰਿਕਸ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ। ਕੁੱਲ ਸਾਈਨਅਪ, ਪੇਜ਼-ਵਿਊਜ਼, ਅਤੇ ਰਾ ਸੈਸ਼ਨ ਗਿਣਤੀ ਵਧ ਸਕਦੀ ਹੈ ਪਰ ਅਸਲ ਤਰੱਕੀ ਫਲੈੱਟ ਰਹਿ ਸਕਦੀ ਹੈ। ਜੇ ਕੋਈ ਮੈਟ੍ਰਿਕ ਤੁਹਾਨੂੰ ਅਗਲੀ ਵਾਰ ਕੀ ਬਣਾਉਣਾ ਹੈ ਇਹ ਨਹੀਂ ਦੱਸਦੀ, ਤਾਂ ਉਹ ਸ਼ਾਇਦ ਸ਼ੋਰ ਹੈ।
UX ਸ਼ਿਕਾਇਤ ਨੂੰ ਮਾਪਯੋਗ ਸਵਾਲ ਵਿੱਚ ਬਦਲੋ
UX ਸ਼ਿਕਾਇਤਾਂ ਅਕਸਰ ਅਧੂਰੀਆਂ ਭਾਵਨਾਵਾਂ ਵਜੋਂ ਆਉਂਦੀਆਂ ਹਨ: “ਸਾਈਨਅਪ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ” ਜਾਂ “ਇਹ ਪੇਜ ਧੀਮਾ ਹੈ।” ਇਲਾਜ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅਹਿਸਾਸ ਨੂੰ ਅਜਿਹਾ ਸਵਾਲ ਬਣਾ ਦਿਓ ਜੋ ਡਾਟਾ ਨਾਲ ਜਵਾਬਯੋਗ ਹੋਵੇ।
ਸਫਰ ਨੂੰ ਜਿਵੇਂ ਅਸਲ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਪਰੋਖੋ, ਨਾ ਕਿ ਫਲੋਚਾਰਟ ਜਿਵੇਂ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। ਓਥੇ ਵੇਖੋ ਜਿੱਥੇ ਲੋਕ ਠਹਿਰਦੇ, ਵਾਪਸ ਜਾਂ ਛੱਡਦੇ ਹਨ। ਫ੍ਰਿਕਸ਼ਨ ਅਕਸਰ ਛੋਟੇ ਵੇਰਵਿਆਂ ਵਿੱਚ ਲੁਕਿਆ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਉਲਝਣ ਭਰੀ ਲੇਬਲ, ਇੱਕ ਵਾਧੂ ਫੀਲਡ, ਇੱਕ ਲੋਡਿੰਗ ਦੇਰੀ, ਜਾਂ ਇੱਕ ਅਸਪਸ਼ਟ ਐਰਰ।
ਕਦਮ ਲਈ ਸਫਲਤਾ ਸਧਾਰਣ ਸ਼ਬਦਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਕਿਹੜੀ ਕਾਰਵਾਈ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ, ਅਤੇ ਕਿੰਨੀ ਵਿਸ਼ਵਾਸਯੋਗਤਾ ਨਾਲ। ਉਦਾਹਰਨ ਵਜੋਂ:
- “ਜੋ ਯੂਜ਼ਰ ਸਾਈਨਅਪ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ, ਘੱਟੋ-ਘੱਟ 85% ਖਤਮ ਕਰਨ।”
- “ਯੂਜ਼ਰ 60 ਸੈਕਿੰਡਾਂ ਦੇ ਅੰਦਰ ਪੁਸ਼ਟੀ ਸਕਰੀਨ 'ਤੇ ਪਹੁੰਚਣ।”
ਇਕ ਪ੍ਰਯੋਗੀ ਢੰਗ: ਇੱਕ ਕਦਮ ਚੁਣੋ ਜਿੱਥੇ ਬੱਸ-ਸਪੱਸ਼ਟ ਡ੍ਰੌਪ-ਆਫ ਹੈ, ਫਿਰ ਇੱਕ ਇੱਕਲ-ਪਰੇਖ ਵਾਕ ਬਣਾਓ: “ਕੀ ਫੀਲਡ X ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਮੋਬਾਈਲ ਉਪਭੋਗਤਿਆਂ ਦੀ ਪੂਰਨਤਾ Y% ਵੱਧਦੀ ਹੈ?”
ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਬਹੁਤ ਮਹੱਤਵਪੂਰਕ ਹੈ। ਤੁਹਾਨੂੰ ਐਸੇ ਇਵੈਂਟ ਚਾਹੀਦੇ ਹਨ ਜੋ ਕਦਮ ਨੂੰ ਪੂਰੇ ਤੌਰ ਤੇ ਵੇਰਵਾ ਦਿੰਦੇ ਹਨ, ਨਾਲ ਹੀ ਸੰਦਰਭ ਵੀ ਜੋ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਉਪਯੋਗਕ ਪ੍ਰਾਪਰਟੀਜ਼ ਵਿੱਚ device, traffic source, form length, error type, ਅਤੇ load time buckets ਸ਼ਾਮਿਲ ਹਨ।
ਸਥਿਰਤਾ ਬਾਅਦ ਵਿੱਚ ਰਿਪੋਰਟਿੰਗ ਹੰਗਾਮੇ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਨਾਂ-ਕਨਵੈਨਸ਼ਨ ਮਦਦ ਕਰਦੀ ਹੈ: events ਲਈ verb_noun ਵਰਤੋ (start_signup, submit_signup), ਇੱਕ-ਮਰੁਦਾ ਨਾਮ ਇੱਕ ਹੀ ਸੰਕਲਪ ਲਈ ਰੱਖੋ ("register" ਅਤੇ "signup" ਮਿਲਾ ਕੇ ਨਾ ਵਰਤੋ), property keys ਸਥਿਰ ਰੱਖੋ (plan, device, error_code), ਅਤੇ ਸਾਰੇ ਲਈ event ਸੂਤਰ-ਸੂਚੀ ਕਿਸੇ ਥਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦੇ ਹੋ, “ਸਾਈਨਅਪ ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ” ਕੁਝ ਇਸ ਰੂਪ ਵਿੱਚ ਬਣ ਜਾਂਦਾ ਹੈ: “ਕਦਮ 3 ਮੋਬਾਈਲ 'ਤੇ 22% ਡ੍ਰੌਪ-ਆਫ ਕਰਵਾਂਦਾ ਹੈ ਪਾਸਵਰਡ ਐਰਰਾਂ ਕਾਰਨ।” ਇਹ ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਹੈ ਜਿਸ ਨੂ ਤੁਸੀਂ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ।
A/B ਟੈਸਟਿੰਗ ਅਨੁਸ਼ਾਸਨ ਜੋ ਬੇਤਰਤੀਬੀ ਸ਼ਿਪਿੰਗ ਨੂੰ ਰੋਕਦਾ ਹੈ
ਫ੍ਰਿਕਸ਼ਨ ਨੂੰ ਟੈਸਟ ਵਿੱਚ ਬਦਲੋ
Koder.ai ਵਿੱਚ ਆਪਣੀ UX ਫਲੋ ਬਣਾਓ ਤੇ ਿਪਰ ਨਤੀਜੇ ਮਾਪੋ।
A/B ਟੈਸਟਾਂ ਉਸ ਵੇਲੇ ਬੇਕਾਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ “ਕੁਝ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕੀ ਹੁੰਦਾ” ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ। ਸੁਧਾਰ ਸਧਾਰਨ ਹੈ: ਹਰ ਟੈਸਟ ਨੂੰ ਇੱਕ ਛੋਟੇ ਠੇਕੇ ਵਾਂਗ ਲਓ। ਇੱਕ ਬਦਲਾਅ, ਇੱਕ ਉਮੀਦ ਕੀਤੀ ਨਤੀਜਾ, ਇੱਕ ਦਰਸ਼ਕ।
ਇੱਕ ਵਾਕ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਟੀਮਮੈਟ ਨੂੰ ਦੇ ਸਕੋ: “ਜੇ ਅਸੀਂ X ਬਦਲਾਂਗੇ ਤਾਂ Z ਲਈ Y ਸੁਧਰੇਗਾ, ਕਿਉਂਕਿ…” ਇਹ ਸਪਸ਼ਟਤਾ ਲਿਆਂਦਾ ਹੈ ਅਤੇ ਐਸੇ ਬਲੈੰਡਡ ਬਦਲਾਅ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਨਤੀਜਿਆਂ ਦੀ ਵਿਵੇਚਨਾ ਅਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਜੋ ਉਹ ਯੂਜ਼ਰ ਕਾਰਵਾਈ ਦਰਸਾਂਦਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਪਰਵਾਹ ਕਰਦੇ ਹੋ (ਸਾਈਨਅਪ ਕੰਪਲੀਟ, ਚੈਕਆਊਟ ਪੂਰਾ, ਪਹਿਲਾ ਸੁਨੇਹਾ ਭੇਜਣ ਦਾ ਸਮਾਂ)। ਕੁਝ ਗਾਰਡਰੇਲ ਜੋ ਤੁਸੀਂ ਨੁਕਸਾਨ ਤੋਂ ਬਚਾਓ: ਕਰੈਸ਼ ਰੇਟ, ਐਰਰ ਰੇਟ, ਸਪੋਰਟ ਟਿਕਟ, ਰਿਫੰਡ, ਜਾਂ ਰੀਟੇਨਸ਼ਨ।
ਮਿਆਦ ਅਤੇ ਨਮੂਨੇ ਦਾ ਆਕਾਰ ਕਾਰਗਰ ਰੱਖੋ। ਝੂਠੀ ਜਿੱਤ ਤੋਂ ਬਚਣ ਲਈ ਤੁਹਾਨੂੰ ਮਹਿੰਗੇ ਅੰਕੜੇ ਦੀ ਲੋੜ ਨਹੀਂ; ਤੁਹਾਨੂੰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੱਗਭਗ ਕਾਫੀ ਟ੍ਰੈਫਿਕ ਚਾਹੀਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਨਤੀਜੇ ਸਥਿਰ ਹੋਣ ਅਤੇ ਕਦਮ-ਕਦਮ ਚੱਕਰ (ਉਦਾਹਰਣ ਲਈ ਹਫ਼ਤੇ-ਅਤੇ-ਹਫ਼ਤੇ) ਕਵਰ ਹੋ ਜਾਣ।
ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਹਰ ਨਤੀਜੇ ਨਾਲ ਕੀ ਕਰੋਗੇ। ਇਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਬਾਦ ਵਿੱਚ ਕਹਾਣੀ ਬਣਨ ਤੋਂ ਰੋਕਦੀ ਹੈ। ਸਪਸ਼ਟ ਜਿੱਤ ਤੁਰੰਤ ਰੁਲ-ਆਉਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਮਨਟਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; ਸਪਸ਼ਟ ਹਾਰ ਰੋਲਬੈਕ ਹੁੰਦੀ ਹੈ ਅਤੇ ਲਿਖੀ ਜਾਂਦੀ ਹੈ; ਅਸਪਸ਼ਟ ਨਤੀਜਾ ਜਾਂ ਤਾਂ ਹੋਰ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧਣਾ ਬਿਨਾਂ ਢੇਰ ਸਾਰਾ ਹੰਗਾਮਾ ਪੈਦਾ ਕੀਤੇ
ਰਫ਼ਤਾਰ ਸਿਰਫ ਰਿਲੀਜ਼-ਰਫ਼ਤਾਰ ਨਹੀਂ, ਇਹ ਫੀਡਬੈਕ-ਰਫ਼ਤਾਰ ਵੀ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਇਹ ਬਣਾਉਣਾ ਹੈ ਕਿ “ਸੁਰੱਖਿਅਤ” ਡੀਫਾਲਟ ਹੋਵੇ ਤਾਂ ਕਿ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਹਫ਼ਤੇ-ਲੰਬੀ ਐਮਰਜੈਂਸੀ ਨਾਹ ਬਣੇ।
ਗਾਰਡਰੇਲ ਸ਼ੁਰੂਆਤੀ IS: ਸੰਖਿਆਵਾਂ ਜੋ ਸੁਸਪੰਸ਼ਨ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ। ਉਹ ਸੰਕੇਤਜੋ ਅਸਲੀ ਦਰਦ ਨੂੰ ਜਲਦੀ ਫੜਨ: ਪੇਜ ਲੋਡ ਟਾਈਮ, ਕਰੈਸ਼ ਜਾਂ ਐਰਰ ਰੇਟ, ਅਤੇ ਮੂਲ ਐਕਸੈਸੀਬਿਲਟੀ ਚੈਕ। ਜੇ ਕੋਈ ਬਦਲਾਅ CTR ਵਧਾਉਂਦਾ ਹੈ ਪਰ ਪੇਜ ਹੌਲੀ ਕਰ ਦਿੰਦਾ ਹੈ ਜਾਂ ਐਰਰ ਵਧ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਜਿੱਤ ਨਹੀਂ।
ਗਾਰਡਰੇਲਾਂ ਨੂੰ ਲਿਖੋ। ਉਹ ਨਿਰੀਖਣਯੋਗ ਹੋਣ: ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਬਜਟ, ਇੱਕ ਐਕਸੈਸੀਬਿਲਟੀ ਬੇਸਲਾਈਨ, ਇੱਕ ਐਰਰ ਸੀਮਾ, ਅਤੇ ਰਿਲੀਜ਼ ਦੇ ਬਾਦ ਸਹਾਇਤਾ ਸੰਕੇਤਾਂ ਨੂੰ ਦੇਖਣ ਲਈ ਇੱਕ ਛੋਟਾ ਵਿੰਡੋ।
ਫਿਰ ਬਲਾਸਟ ਰੇਡੀਅਸ ਘਟਾਓ। ਫੀਚਰ ਫਲੈਗ ਅਤੇ ਸਟੇਜਡ ਰੋਲਆਉਟ ਤੁਹਾਨੂੰ ਝਟਕੇ ਤੋਂ ਪਹਿਲਾਂ ਛੋਟੇ ਗਰੁੱਪਾਂ 'ਤੇ ਪਰਖਣ ਦਿੰਦੇ ਹਨ। ਅੰਦਰੂਨੀ ਯੂਜ਼ਰ → ਛੋਟੀ ਪ੍ਰਤੀਸ਼ਤ → ਵੱਡੀ ਪ੍ਰਤੀਸ਼ਤ। ਰੋਲਬੈਕ ਇੱਕ ਬਟਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਹਲਚਲ ਨਹੀਂ।
ਇਹ ਵੀ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਸੇ ਨੇ ਕੀਤਾ-ਕੀ ਸ਼ਿਪ ਕਰ ਸਕਦਾ ਹੈ ਦੀ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਾ ਹੋਵੇ। ਘੱਟ-ਖ਼ਤਰਾ UI ਕਾਪੀ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਦਾਖਲ ਹੋ ਸਕਦੇ ਹਨ; ਉੱਚ-ਖ਼ਤਰਾ ਵਰਕਫਲੋ ਬਦਲਾਅ (ਸਾਈਨਅਪ, ਚੈੱਕਆਊਟ) ਨੂੰ ਵਾਧੂ ਸਮੀਖਿਆ ਅਤੇ ਇੱਕ ਨਿਰਧਾਰਿਤ ਮਾਲਿਕ ਚਾਹੀਦਾ ਹੈ ਜੋ ਮੈਟ੍ਰਿਕ ਡਿੱਪ ਤੇ ਫੈਸਲਾ ਕਰ ਸਕੇ।
ਕਦਮ-ਬਾਇ-ਕਦਮ: ਇੱਕ ਤੇਜ਼, ਦੋਹਰਣਯੋਗ ਪ੍ਰਯੋਗ ਲੂਪ
ਲਗਾਤਾਰ ਇਟਰੇਸ਼ਨ ਨੂੰ ਸਹਿਯੋਗ ਦੇਵੋ
ਜ਼ਿਆਦਾ ਟ੍ਰੈਫਿਕ ਹੋਣ 'ਤੇ ਤੇਜ਼ ਪ੍ਰਯੋਗਿਕ ਲਹਿਰ ਲਈ ਛੋਟੇ-ਛੋਟੇ ਪ੍ਰਯੋਗਾਂ ਦੀ ਰੁਟਿਨ ਬਣਾਓ।
ਤੇਜ਼ ਟੀਮਾਂ ਅਨੁਮਾਨ ਨਾਲ ਤੇਜ਼ ਨਹੀਂ ਹੁੰਦੀਆਂ; ਉਹ ਛੋਟੇ, ਨਿਰੰਤਰ ਅਤੇ ਦੁਹਰਣਯੋਗ ਲੂਪ ਨਾਲ ਤੇਜ਼ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਕ ਫਨਲ ਵਿੱਚ ਇੱਕ friction ਮੋਮੈਂਟ ਚੁਣੋ। ਉਸਨੂੰ ਗਿਰੰਟੀਬੱਧ ਚੀਜ਼ ਵਿੱਚ ਬਦਲੋ, ਜਿਵੇਂ completion rate ਜਾਂ time to finish। ਫਿਰ ਇੱਕ ਕਸਰ-ਭਰਿਆ ਹਿਪੋਥੈਸਿਸ ਲਿਖੋ: ਕੀ ਬਦਲੋ, ਕਿਹੜਾ ਨੰਬਰ ਹਿਲੇਗਾ, ਅਤੇ ਕੀ ਨਹੀਂ ਖਰਾਬ ਹੋਣਾ ਚਾਹੀਦਾ।
ਬਦਲਾਅ ਨੂੰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਛੋਟਾ ਰੱਖੋ ਪਰ ਮਾਇਨੇ ਰੱਖਣ ਵਾਲਾ। ਇੱਕ ਸਕਰੀਨ ਟਵੀਕ, ਇੱਕ ਘੱਟ ਫੀਲਡ, ਜਾਂ ਸਪਸ਼ਟ ਕਾਪੀ ਅਸਾਨੀ ਨਾਲ ਸ਼ਿਪ, ਟੈਸਟ ਅਤੇ ਰੋਲਬੈਕ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ ਦੁਹਰਣਯੋਗ ਲੂਪ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:
- ਇੱਕ ਫਨਲ ਮੈਟ੍ਰਿਕ ਨਾਲ ਜੁੜਿਆ ਇੱਕ ਫ੍ਰਿਕਸ਼ਨ ਪੌਇੰਟ ਚੁਣੋ
- ਹਿਪੋਥੈਸਿਸ, ਪ੍ਰਾਇਮਰੀ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ, ਅਤੇ 1-2 ਗਾਰਡਰੇਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
- ਸਭ ਤੋਂ ਛੋਟੀ ਬਦਲਾਅ ਬਣਾਓ ਜੋ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ ਸਕੇ
- ਟੈਸਟ ਰਨ ਕਰੋ, ਰੋਜ਼ਾਨਾ ਮਨਟਰ ਕਰੋ, ਫਿਰ ਫੈਸਲਾ: ਰੱਖੋ, ਵਾਪਸ ਲਓ, ਜਾਂ ਸੁਧਾਰੋ
- ਸਿੱਖਿਆ ਇੱਕ ਛੋਟੀ ਨੋਟ ਵਿੱਚ ਸਾਂਭੋ ਤਾਂ ਕਿ ਕੋਈ ਇੱਕੋ ਜਿਹਾ ਟੈਸਟ ਮੁੜ ਨਾ ਕਰੇ
ਆਖ਼ਰੀ ਕਦਮ ਇੱਕ ਖਾਮੋਸ਼ ਫ਼ਾਇਦਾ ਦਿੰਦਾ ਹੈ: ਉਹ ਟੀਮਾਂ ਜੋ ਯਾਦ ਰੱਖਦੀਆਂ ਹਨ ਉਹ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਦੀਆਂ ਹਨ ਬਨਿਸ਼ਪਤ ਕੀਵਿਆਂ ਤੋਂ ਤੇਜ਼ ਸ਼ਿਪ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਨਾਲੋਂ।
ਰਫ਼ਤਾਰਦੀ ਅਸਲ ਮਤਲਬ: ਫੀਡਬੈਕ ਦੀ ਰਫ਼ਤਾਰ, ਸਿਰਫ ਰਿਲੀਜ਼ ਦੀ ਨਹੀਂ
ਸਾਈਨਅਪ ਫ੍ਰਿਕਸ਼ਨ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਠੀਕ ਕਰੋ
ਇਕ ਸਾਫ਼ ਫਾਰਮ, ਘੱਟ ਫੀਲਡ ਅਤੇ ਸਪਸ਼ਟ ਐਰਰ ਸੰਦਰਭ ਪਹਿਲਾਂ-ਵਾਰ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰੋ।
ਤੇਜ਼ ਸ਼ਿਪਿੰਗ ਚੰਗੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਉਹੀ ਨਹੀਂ ਜਿਵੇਂ ਯੂਜ਼ਰ ਸਫਲ ਹੋਣ। “ਅਸੀਂ ਸ਼ਿਪ ਕੀਤਾ” ਅੰਦਰੂਨੀ ਗੱਲ ਹੈ। “ਯੂਜ਼ਰ ਕੰਮ ਮੁਕੰਮਲ ਕੀਤਾ” ਹੀ ਮਹੱਤਵਪੂਰਨ ਨਤੀਜਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ ਰਿਲੀਜ਼ ਨੂੰ ਮਨਾਓਗੇ, ਤਾਂ ਛੋਟੀ UX ਫ੍ਰਿਕਸ਼ਨ ਆਹਿਸਤ-ਆਹਿਸਤ ਗੁਪਤ ਰਹਿ ਜਾਵੇਗੀ ਅਤੇ ਸਪੋਰਟ ਟਿਕਟਾਂ, ਚਰਨ ਅਤੇ ਡ੍ਰੌਪ-ਆਫ ਹੌਲੀ-ਹੌਲੀ ਵੱਧਦੇ ਰਹਿਣਗੇ।
ਰਫ਼ਤਾਰ ਦੀ ਇਕ ਪ੍ਰਯੋਗਿਕ ਪਰਿਭਾਸ਼ਾ: ਤੁਸੀਂ ਕੁਹੁੰਜ਼ ਸੱਚ ਨੂੰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਸਕਦੇ ਹੋ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਬਦਲਦੇ ਹੋ? ਤੇਜ਼ ਬਣਾਉਣਾ ਬਿਨਾਂ ਤੇਜ਼ ਮਾਪਣ ਦੇ ਤੇਜ਼ ਅਨੁਮਾਨ ਹੀ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਹਫ਼ਤਾਵਾਰ ਰਿਦਮ ਜੋ ਰਫ਼ਤਾਰ ਨੂੰ ਸੱਚਾ ਰੱਖਦੀ ਹੈ
ਇੱਕ ਢੰਗੀ ਰੁਦਿਮ ਬਦਲਾਅ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਬਣਾਉਂਦੀ ਹੈ ਬਿਨਾਂ ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਜੋੜੇ:
- ਸੋਮਵਾਰ: ਇੱਕ ਕੇਂਦਰਤ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰੋ ਜਿਸ ਦਾ ਸਪੱਸ਼ਟ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਹੋਵੇ
- ਮੰਗਲਵਾਰ ਤੋਂ ਵੀਰਵਾਰ: ਲੀਡਿੰਗ ਇੰਡੀਕੇਟਰ ਅਤੇ ਗਾਰਡਰੇਲ ਮਨਟਰ ਕਰੋ
- ਸ਼ੁੱਕਰਵਾਰ: ਨਤੀਜਿਆਂ ਦੇ ਆਧਾਰ ਤੇ ਰੱਖੋ, ਰੋਲਬੈਕ ਕਰੋ, ਜਾਂ ਦੁਬਾਰਾ ਸੋਚੋ
ਨੰਬਰਾਂ ਵਿੱਚ ਅੰਧੇ ਖ਼ਾਣੇ ਹੋ ਸਕਦੇ ਹਨ, ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਮੈਟ੍ਰਿਕਸ ਠੀਕ ਲੱਗਦੇ ਹਨ ਪਰ ਯੂਜ਼ਰ ਨਿਰਾਸ਼ ਹਨ। ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਕੁੱਝ ਹਲਕੀ ਗੁਣਾਤਮਕ ਜਾਂਚਾਂ ਨਾਲ ਜੋڑੋ: ਕੁਝ ਸਪੋਰਟ ਚੈਟਾਂ ਵੇਖੋ, ਕਈ ਸੈਸ਼ਨ ਰਿਕਾਰਡਿੰਗਾਂ, ਜਾਂ ਇੱਕ ਛੋਟੀ ਯੂਜ਼ਰ-ਕਾਲ ਖਾਸ ਇੱਕ ਫਲੋ 'ਤੇ। ਗੁਣਾਤਮਕ ਨੋਟ ਅਕਸਰ ਦੱਸਦੇ ਹਨ ਕਿ ਮੈਟ੍ਰਿਕ ਕਿਉਂ ਹਿਲਿਆ (ਜਾਂ ਕਿਉਂ ਨਹੀਂ)।
ਮੈਟ੍ਰਿਕਸ ਅਤੇ A/B ਟੈਸਟਾਂ ਨਾਲ ਟੀਮਾਂ ਦੀਆਂ ਆਮ ਗਲਤੀਆਂ
ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਭਰੋਸਾ ਖੋਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਗੰਦੇ ਪ੍ਰਯੋਗ ਚਲਾਉਣਾ ਹੈ। ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਹਿਲਦੀਆਂ ਹਨ ਪਰ ਕੁਝ ਵੀ ਨਹੀਂ ਸਿੱਖਦੀਆਂ, ਜਾਂ ਗਲਤ ਨਤੀਜੇ ਲੈਂਦੀਆਂ ਹਨ।
ਬਦਲਾਅ ਜੋੜਨਾ ਇੱਕ ਕਲਾਸਿਕ ਫੇਲURE ਹੈ। ਨਵਾਂ ਬਟਨ ਲੇਬਲ, ਲੇਆਉਟ ਸ਼ਿਫਟ, ਅਤੇ ਆਨਬੋਰਡਿੰਗ ਕਦਮ ਇੱਕੱਠੇ ਸ਼ਿਪ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਲੁਕਾਵਟ ਲੱਗਦਾ ਹੈ। ਫਿਰ ਟੈਸਟ ਇੱਕ ਉਥਲੇ ਵਾਧੇ ਦਿਖਾਉਂਦਾ ਹੈ ਪਰ ਕੋਈ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਕਾਰਨ ਸੀ।
ਟੈਸਟ ਨੂੰ ਜਲਦੀ ਖਤਮ ਕਰਨਾ ਵੀ ਖਤਰਨਾਕ ਹੈ। ਛੋਟੀ-ਨਮੂਨਾ ਜਾਂ ਅਸਥਿਰ ਟ੍ਰੈਫਿਕ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਚਾਰਟ ਅਣਿਸ਼ਚਿਤ ਹੋ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਲਾਈਨ ਊਪਰ ਜਾਂਦੀ ਹੈ, ਉਹੀ ਸਮੇਂ ਬੰਦ ਕਰਨਾ ਤਜਰਬਾ-ਕੁਤੂਹਲ ਨੂੰ ਨસીਬ ਕਰਦਾ ਹੈ।
ਗਾਰਡਰੇਲ ਛੱਡ ਦੇਣ ਨਾਲ ਦੇਰ ਨਾਲ ਦਰਦ ਆ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਕੰਵਰਜ਼ਨ ਵਧਾ ਸਕਦੇ ਹੋ ਪਰ ਸਪੋਰਟ ਟਿਕਟ, ਰਿਫੰਡ ਜਾਂ ਪੇਜ ਸਪੀਡ ਖਰਾਬ ਹੋ ਰਹੀ ਹੋ ਸਕਦੀ ਹੈ—ਇਹ ਨੁਕਸਾਨ ਟੀਮ ਦੇ ਜਸ਼ਨ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਾਹਮਣੇ ਆ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਸਵਾਲ ਪੁੱਛੋ: ਕੀ ਅਸੀਂ ਕਿਸੇ ਲੌਕਲ ਮੈਟ੍ਰਿਕ ਨੂੰ ਬੇਤਰ ਬਣਾਇਆ ਜਿਸ ਨਾਲ ਪੂਰੀ ਯਾਤਰਾ ਖ਼ਰਾਬ ਹੋ ਗਈ? ਉਦਾਹਰਣ ਲਈ, “Next” ਬਟਨ ਨੂੰ ਚਮਕਦਾਰ ਕਰਨ ਨਾਲ ਕਲਿਕ ਵadh ਸਕਦੇ ਹਨ ਪਰ ਪੂਰਨਤਾ ਘਟ ਸਕਦੀ ਹੈ ਜੇ ਯੂਜ਼ਰ ਰੂਪ ਵਿੱਚ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਕੇ ਇੱਕ ਲਾਜ਼ਮੀ ਫੀਲਡ ਮਿਸ ਕਰ ਦੇਂ।
ਡੈਸ਼ਬੋਰਡ ਸਹਾਇਕ ਹਨ ਪਰ ਉਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਲੋਕ ਕਿਉਂ ਸੰਘਰਸ਼ ਕਰ ਰਹੇ ਹਨ। ਹਰੇਕ ਗੰਭੀਰ ਮੈਟ੍ਰਿਕ ਸਮੀਖਿਆ ਨੂੰ ਕੁਝ ਹਕੀਕਤ ਨਾਲ ਜੋੜੋ: ਕੁਝ ਸਪੋਰਟ ਟਿਕਟ, ਇੱਕ ਛੋਟੀ ਕਾਲ, ਜਾਂ ਫਲੋ ਦੀਆਂ ਰਿਕਾਰਡਿੰਗਾਂ ਦੇਖੋ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
ਮੈਨੂੰ ਕਿਵੇਂ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਕਿਹੜੀ “ਛੋਟੀ UX ਫ੍ਰਿਕਸ਼ਨ” ਸਾਡੇ ਲਈ ਪੈਸਾ ਖੋ ਰਹੀ ਹੈ?
ਉਹਲੇ-ਨਾਲ-ਵਾਲੀ ਭਰਪਾਈ ਜਾਂ ਵਧੀਆ ਮੁੱਲ ਵਾਲੇ ਫਲੋ (ਸਾਈਨਅਪ, ਚੈਕਆਊਟ, ਆਨਬੋਰਡਿੰਗ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਉਹਨਾਂ ਅੰਸ਼ਾਂ ‘ਤੇ ਤੱਕੋ ਜਿੱਥੇ ਯੂਜ਼ਰ ਠਹਿਰਦੇ, ਵਾਪਸ ਜਾਂ ਛੱਡਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਾਪੋ (ਕੰਪਲੀਸ਼ਨ ਰੇਟ, ਖਤਮ ਕਰਨ ਦਾ ਸਮਾਂ, ਐਰਰ ਰੇਟ)। ਇੱਕ ਉੱਚ-ਟ੍ਰੈਫਿਕ ਕਦਮ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਪੰਜ ਘੱਟ-ਟ੍ਰੈਫਿਕ ਸਕਰੀਨਾਂ ਨੂੰ ਫੈਲਾਉਣ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ।
ਫਨਲ ਦੇ ਇੱਕ ਕਦਮ ਵਿੱਚ 1–2% ਦੀ ਡ੍ਰੌਪ ਦਾ ਅੰਦਾਜ਼ਾ ਮੈਂ ਕਿਵੇਂ ਲਗਾ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?
ਸਧਾਰਨ ਫਨਲ ਗਣਿਤ ਵਰਤੋ:
- ਮਹੀਨਾਵਾਰ ਸ਼ੁਰੂਆਤਕਾਰ × (ਪੁਰਾਣੀ ਪੂਰਨਤਾ ਦਰ − ਨਵੀਂ ਪੂਰਨਤਾ ਦਰ) = ਘਟੇ ਹੋਏ ਪੂਰਨਤਾ
- ਘਟੇ ਹੋਏ ਪੂਰਨਤਾ × ਐਕਟੀਵੇਸ਼ਨ ਰੇਟ = ਘਟੇ ਹੋਏ ਸਰਗਰਮ ਯੂਜ਼ਰ
- ਘਟੇ ਹੋਏ ਸਰਗਰਮ ਯੂਜ਼ਰ × ਕੰਵਰਜ਼ਨ ਰੇਟ × ARPA = ਲਗਭਗ ਰੈਵਨਿਊ ਪ੍ਰਭਾਵ
ਚਾਹੇ ਮਾਤਰ ਇੱਕ ਜਾਂ ਦੋ ਪੌਇੰਟ ਦੀ ਘਟ ਹੋਵੇ, ਜਦੋਂ ਟਾਪ-ਆਫ-ਫਨਲ ਵੱਡਾ ਹੋਵੇ ਤਾਂ ਨਤੀਜੇ ਵੱਡੇ ਹੁੰਦੇ ਹਨ।
ਜੇ ਮੈਂ “ਮਾਪਯੋਗ UX” ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ ਹਾਂ ਪਰ ਡੈਸ਼ਬੋਰਡ ਘੁੰਮਾਉਣਾ ਨਹੀਂ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ, ਤਾਂ ਪਹਿਲਾਂ ਕਿਹੜੇ ਮੈਟ੍ਰਿਕਸ ਟਰੈਕ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ?
ਇੱਕ ਵਧੀਆ ਡੀਫਾਲਟ ਸੈੱਟ:
- Activation (ਪਹਿਲੀ ਮਹੱਤਵਪੂਰਣ ਕਾਮਯਾਬੀ)
- Time to value (ਉਹ ਪਹੁੰਚਣ ਦਾ ਸਮਾਂ)
- Retention (ਹਫ਼ਤੇ-1 ਜਾਂ ਮਹੀਨੇ-1)
- Conversion (ਮੁਫ਼ਤ→ਭੁਗਤਾਨ / ਟ੍ਰਾਇਲ→ਭੁਗਤਾਨ)
- Churn
ਫਿਰ ਆਪਣੀ ਮੁੱਖ ਫਲੋ ਵਿੱਚ ਇੱਕ UX ਹੈਲਥ ਮੈਟ੍ਰਿਕ ਸ਼ਾਮਿਲ ਕਰੋ, ਜਿਵੇਂ ਟਾਸਕ ਸక్సੈਸ ਰੇਟ ਜਾਂ ਐਰਰ ਰੇਟ।
ਮੈਂ ਇੱਕ ਮੁੰਹ-ਬੋਲਣ ਵਾਲੀ UX ਸ਼ਿਕਾਇਤ ਨੂੰ ਕਿਸ ਤਰ੍ਹਾਂ ਪ੍ਰਯੋਗਯੋਗ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?
ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸ਼ਿਕਾਇਤ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਮਾਪਯੋਗ ਸਵਾਲ ਵਿੱਚ ਲਿਖੋ:
- ਸ਼ਿਕਾਇਤ: “ਸਾਈਨਅਪ ਨਿਰਾਸ਼ਾਜਨਕ ਹੈ।”
- ਮਾਪਯੋਗ: “ਕਿਹੜਾ ਕਦਮ ਮੋਬਾਈਲ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਡ੍ਰੌਪ-ਆਫ ਕਰਵਾਂਦਾ ਹੈ?”
- ਟੈਸਟਯੋਗ: “ਕੀ ਫੀਲਡ X ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਮੋਬਾਈਲ ਪੂਰਨਤਾ Y% ਨਾਲ ਵਧਦੀ ਹੈ?”
ਲਕੜੀ ਦਾ ਮਕਸਦ ਇੱਕ ਸਾਫ਼ ਅਤੇ ਨਿਰੀਖਣਯੋਗ ਵਰਤਾਰ ਨੂੰ ਪਰਖਣਾ ਹੈ, ਨਾ ਕਿ ਜਨਰਲ ਅਹਿਸਾਸ।
UX ਬਦਲਾਵਾਂ 'ਤੇ A/B ਟੈਸਟ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਨੂੰ ਕਿਹੜੀ ਇੰਸਟ੍ਰੂਮੇਂਟੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ?
ਪੁੜ-ਟੂ-ਏਂਡ ਇਵੈਂਟ ਨਾਂਵਾਂ ਅਤੇ ਕੁਝ ਮਹੱਤਵਪੂਰਣ ਪ੍ਰਾਪਰਟੀਜ਼ ਨਾਲ ਫਲੋ ਟਰੈਕ ਕਰੋ।
ਘੱਟੋ-ਘੱਟ ਇਵੈਂਟਸ:
start_stepview_stepsubmit_steperror_step(ਜਿਸ ਵਿੱਚerror_codeਹੋਵੇ)complete_step
ਉਪਯੋਗੀ ਪ੍ਰਾਪਰਟੀਜ਼: device, traffic_source, load_time_bucket, form_length, variant.
ਇਹ ਜਾਣਕਾਰੀ ਤੁਹਾਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਸਮੱਸਿਆ ਦੀ ਵਜ੍ਹਾ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ।
A/B ਟੈਸਟਿੰਗ ਦਾ ਸਭ ਤੋਂ ਸਧਾਰਨ ਅਨੁਸ਼ਾਸਨ ਕੀ ਹੈ ਜੋ ਬੇਤਰਤੀਬੀ ਢੰਗ ਨਾਲ ਸ਼ਿਪਿੰਗ ਨੂੰ ਰੋਕਦਾ ਹੈ?
ਇੱਕ ਸਧਾਰਨ ਅਨੁਸ਼ਾਸਨ:
- ਹਰ ਟੈਸਟ ਵਿੱਚ ਇਕ ਹੀ ਮਹੱਤਵਪੂਰਣ ਗੱਲ ਬਦਲੋ
- ਇੱਕ ਪ੍ਰਧਾਨ ਮੈਟ੍ਰਿਕ ਨਿਰਧਾਰਿਤ ਕਰੋ (ਉਹ ਵਰਤੋਂਕਾਰ ਕਾਰਵਾਈ ਜਿਹੜੀ ਤੁਹਾਨੂੰ ਚਾਹੀਦੀ ਹੈ)
- 1–2 ਗਾਰਡਰੇਲ ਰੱਖੋ (ਕਾਰਜਕੁਸ਼ਲਤਾ, ਐਰਰ, ਸਪੋਰਟ ਟਿਕਟ ਆਦਿ)
- ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕਦੋਂ ਨੂੰ ਜਿੱਤ/ਹਾਰ/ਅਸੰਪੂਰਨ ਮੰਨਿਆ ਜਾਵੇ
ਇਹ ਤਰੀਕਾ “ਅਸੀਂ ਬਹੁਤ ਕੁਝ ਸ਼ਿਪ ਕੀਤਾ” ਦੀ ਗਲਤਫਹਮੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਕਿੰਨ੍ਹਾਂ ਸਮੇਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗ ਚਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਅਸੀਂ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੀਏ?
ਚਰਚੇ ਦੀ ਕਮੀ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਪ੍ਰਯੋਗ 'ਤੇ ਸੱਚ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਗਤੀ:
- ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪੂਰਾ ਹਫ਼ਤਾ (ਅਕਸਰ ਦੋ) ताकि ਹਫ਼ਤੇ-ਵਾਰੀ ਰੁਝਾਨ ਕੈਚ ਹੋ ਸਕਣ
- ਰੁਕੋ ਤਾਂ ਹੀ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪੂਰਨਤਾਵਾਂ ਦੀ ਸੰਪੱਤੀ ਸਥਿਰ ਹੋ ਜਾਏ (ਸਿਰਫ਼ ਵਿਜ਼ਟਰ ਨਹੀਂ)
ਜੇ ਤੁਰੰਤ ਫੈਸਲਾ ਲੈਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਨੁਕसान ਘਟਾਉਣ ਲਈ ਸਟੇਜਡ ਰੋਲਆਉਟ ਅਤੇ ਮਜ਼ਬੂਤ ਗਾਰਡਰੇਲ ਵਰਤੋ।
ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਕਿਵੇਂ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹਾਂ ਬਿਨਾਂ ਚੀਜ਼ਾਂ ਨੁੱਕਸਾਨ ਪਹੁੰਚਾਉਣ ਜਾਂ UX ਹੰਗਾਮੇ ਪੈਦਾ ਕਰਨ?
ਰਫ਼ਤਾਰ ਉਸ ਸਮੇਂ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਨੁਕਸਾਨ ਦੀ ਅਗਾਅਸ਼ੀ ਕਰ ਸਕੋ।
ਮੁੱਲ-ਪੂਰਨ ਗਾਰਡਰੇਲ ਨਿਰਧਾਰਿਤ ਕਰੋ: ਪੇਜ ਲੋਡ ਟਾਈਮ, ਕਰੈਸ਼/ਐਰਰ ਰੇਟ, ਅਤੇ ਬੁਨਿਆਦੀ ਐਕਸੈਸੀਬਿਲਟੀ ਚੈਕ। ਜੇ ਕੋਈ ਬਦਲਾਅ CTR ਵਧਾਉਂਦਾ ਹੈ ਪਰ ਪੇਜ ਧੀਮਾ ਕਰ ਦਿੰਦਾ ਹੈ ਜਾਂ ਐਰਰ ਵਧਦੇ ਹਨ, ਤਾਂ ਉਹ ਜਿੱਤ ਨਹੀਂ।
ਰੋਲਆਉਟ ਦੀ ਰਣਨੀਤੀ: ਫੀਚਰ ਫ਼ਲੈਗ, ਸਮੂਹ-ਵਾਰ ਰੋਲਆਉਟ (ਪਹਿਲਾਂ ਅੰਦਰੂਨੀ, ਫਿਰ ਛੋਟੀ ਪਰਸੈਂਟੇਜ, ਆਖिरਕਾਰ ਵਿਆਪਕ)। ਰੋਲਬੈਕ ਇੱਕ ਸਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਕ ਭਗਦੜ ਨਹੀਂ।
ਟીમਾਂ ਆਮ ਤੌਰ 'ਤੇ ਮੈਟ੍ਰਿਕਸ ਅਤੇ A/B ਟੈਸਟਾਂ ਵਿੱਚ ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਕਰਦੀਆਂ ਹਨ?
ਬੇਤਰਤੀਬੀ ਪ੍ਰਯੋਗ ਅਤੇ ਗਲਤ ਸਿੱਖਣ ਤੋਂ ਬਚਣ ਲਈ ਕੁਝ ਆਮ ਗਲਤੀਆਂ:
- ਇੱਕੱਠੇ ਬਦਲਾਅ ਜਮ੍ਹਾਂ ਕਰ ਦੇਣਾ: ਨਤੀਜੇ ਆਉਂਦੇ ਹਨ ਪਰ ਕੋਈ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਕਾਰਨ ਸੀ।
- ਪ੍ਰਯੋਗ ਨੂੰ ਜਲਦੀ ਸਮਾਪਤ ਕਰਨਾ: ਛੋਟੇ ਨਮੂਨੇ ਜਾਂ ਅਨੇਕ ਤਰ੍ਹਾਂ ਦੇ ਟ੍ਰੈਫਿਕ ਨਾਲ ਪਹਿਲੇ ਚਾਰਟ ਧੋਖੇਬਾਜ਼ ਹੋ ਸਕਦੇ ਹਨ।
- ਗਾਰਡਰੇਲਾਂ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨਾ: ਤੁਸੀਂ ਕੰਵਰਜ਼ਨ ਵਧਾ ਸਕਦੇ ਹੋ ਪਰ ਸਪੋਰਟ ਟਿਕਟਾਂ, ਰਿਫੰਡ ਜਾਂ ਲੰਬੇ ਸਮੇਂ ਦੀ ਰੀਟੇਨਸ਼ਨ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹੋ।
ਹਮੇਸ਼ਾ ਪੁੱਛੋ: ਕੀ ਅਸੀਂ ਕਿਸੇ ਸਥਾਨਕ ਮੈਟ੍ਰਿਕ ਨੂੰ ਅਾਪਟਿਮਾਈਜ਼ ਕਰਕੇ ਸਾਰੀਆਂ ਯਾਤਰਾ ਖਰਾਬ ਕਰ ਦਿੱਤੀ ਹੈ? ਡੈਸ਼ਬੋਰਡ ਵਰਗੀ ਮਿਜਾਜ਼ ਨੂੰ ਕੁਝ ਹਕੀਕਤਾਂ ਨਾਲ ਜੋੜੋ: ਸਪੋਰਟ ਟਿਕਟਾਂ, ਛੋਟੇ ਯੂਜ਼ਰ-ਕੋਲ੍ਹ, ਜਾਂ ਸਕਰੀਨ ਰਿਕਾਰਡਿੰਗ।
ਲੋ-ਡਰਾਮਾ ਇਟਰੇਸ਼ਨ ਲਈ ਪੂਰਵ-ਸ਼ਿਪ ਚੈਕਲਿਸਟ ਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?
ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਪਰਚੀ-ਚੈੱਕਲਿਸਟ:
- ਇਕ ਵਾਕ ਵਿੱਚ ਸਪੱਸ਼ਟ ਕਰੋ: “ਅਸੀਂ ਮੰਨਦੇ ਹਾਂ ਕਿ X ਕਰਨ ਨਾਲ Y ਉਪਭੋਗਤਿਆਂ ਲਈ Z ਬਦਲਾਅ ਆਵੇਗਾ ਕਿਉਂਕਿ…” ਜੇ ਇਹ ਵਾਕ ਸੀਧਾ ਨਹੀਂ ਬਣ ਰਿਹਾ, ਪ੍ਰਯੋਗ ਤਿਆਰ ਨਹੀਂ।
- ਮੈਜ਼ਰਮੈਂਟ ਯੋਜ਼ਨਾ ਲਾਕ ਕਰੋ: ਇੱਕ ਮੁੱਖ ਮੈਟ੍ਰਿਕ ਅਤੇ ਕੁਝ ਗਾਰਡਰੇਲ
- ਲਾਂਚ ਤੋਂ ਠੀਕ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ: ਹਿਪੋਥੈਸਿਸ ਬਦਲਾਅ ਨਾਲ ਮਿਲਦੀ ਹੈ, ਮੈਟ੍ਰਿਕਸ ਨਾਂ ਅਤੇ ਬੇਸਲਾਈਨ ਤਿਆਰ ਨੇ, ਰੋਲਬੈਕ ਤੇਜ਼ ਹੈ, ਅਤੇ ਇੱਕ ਵਿਅਕਤੀ ਫੈਸਲੇ ਦੀ ਮਿਤੀ ਦਾ ਮਾਲਿਕ ਹੈ।
ਇੱਕ ਸਾਫ਼ ਪ੍ਰਯੋਗ ਨਾਲ ਸਾਈਨਅਪ ਫ੍ਰਿਕਸ਼ਨ ਕਿਵੇਂ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?
ਸਾਈਨਅਪ ਫਲੋ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਫੀਲਡ (ਜਿਵੇਂ “ਕੰਪਨੀ ਦਾ ਆਕਾਰ”) ਜੁੜਨਾ ਉਹ ਉਦਾਹਰਨ ਹੈ ਜੋ ਵਾਹਿਗੁਰੂ ਧਿਆਨ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਟੁੱਟਣ ਵਾਲੀ ਥਾਂ ਅਤੇ ਪ੍ਰਭਾਵ ਨਿਰਧਾਰਿਤ ਕਰੋ:
- ਕਦਮ-ਦਰ-ਕਦਮ ਡ੍ਰੌਪ-ਆਫ
- ਪੂਰਨ ਸਾਈਨਅਪ ਦਾ ਮੈਡੀਅਨ ਸਮਾਂ
- ਨਵੀਂ ਫੀਲਡ 'ਤੇ ਐਰਰ ਰੇਟ
ਫਿਰ ਇੱਕ ਸਾਫ਼ A/B ਟੈਸਟ ਦਵਾਓ:
- Variant A: ਫੀਲਡ ਹਟਾਓ
- Variant B: ਫੀਲਡ ਰਹੇ ਪਰ ਵਿਕਲਪਿਕ ਬਣਾਓ ਅਤੇ ਛੋਟੀ ਵਜ੍ਹਾ ਦਿਖਾਓ
ਪਹਿਲਾਂ ਨਿਯਮ ਰੱਖੋ: ਪ੍ਰਾਇਮਰੀ ਮੈਂਟਰਿਕ ਸਾਈਨਅਪ ਕੰਪਲੀਸ਼ਨ, ਸਮਾਂ ਨਾ ਵਧੇ, ਸਪੋਰਟ ਟਿਕਟ ਨਾ ਵਧਣ। ਹਫ਼ਤੇ-ਵਾਰੀ ਵਿਵਹਾਰ ਕਵਰ ਕਰਨ ਲਈ ਪਰਯੋਗ ਲੰਬਾ ਚਲਾਓ।
A ਜਿੱਤਦਾ ਹੈ ਤਾਂ ਫੀਲਡ ਇਸ ਵੇਲੇ ਲਾਭਕਾਰੀ ਨਹੀਂ; B ਜਿੱਤਦਾ ਹੈ ਤਾਂ ਵੈਲਯੂ ਸਕੇਲ ਕਰਨ ਵਾਲੀ ਸਿੱਖ ਹੈ: ਸਪਸ਼ਟਤਾ ਅਤੇ ਵਿਕਲਪਿਕਤਾ ਹਟਾਉਣ ਤੋਂ ਬਿਹਤਰ ਹਨ।
ਅਗਲੇ ਕਦਮ ਕੀ ਹਨ: ਇੱਕ ਹਲਕੀ-ਫੁਲਕੀ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਪ੍ਰਯੋਗ ਰੁਟੀਨ ਬਣਾਉਣ ਲਈ?
ਤੇਜ਼ੀ ਵੱਲ ਜਦੋਂ ਤਕ ਨਿਯਮ ਹੋਣ ਤਾਂ ਹੀ ਅਦਾਇਗੀ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀ ਹੈ। ਛੋਟਾ ਪ੍ਰਯੋਗ ਬੈਕਲੌਗ ਰੱਖੋ ਜਿਸ ਨੂੰ ਲੋਕ ਵਾਸਤੇ ਵਰਤ ਸਕਣ: ਇੱਕ ਫ੍ਰਿਕਸ਼ਨ ਪੌਇੰਟ, ਇੱਕ ਮੈਟ੍ਰਿਕ, ਇੱਕ ਮਾਲਿਕ, ਇੱਕ ਅਗਲਾ ਕਦਮ।
ਹਰ ਪ੍ਰਯੋਗ ਲਈ ਇੱਕ-ਪੰਨੇ ਦਾ ਟੇਮਪਲੇਟ ਵਰਤੋ: ਹਿਪੋਥੈਸਿਸ, ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ, ਗਾਰਡਰੇਲ, ਦਰਸ਼ਕ ਅਤੇ ਸਮਾਂ, ਕੀ ਬਦਲਿਆ, ਫੈਸਲੇ ਦਾ ਨਿਯਮ।
ਜੇਤੋਂ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਹੋ (ਖ਼ਾਸ ਕਰ ਕੇ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ), ਇਹ ਅਨੁਸ਼ਾਸਨ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਜ਼ਿਆਦਾ ਬਦਲਾਅ ਆਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੀਆਂ ਸਹੂਲਤਾਂ ਮਦਦਗਾਰ ਹੋ ਸਕਦੀਆਂ ਹਨ।