14 ਜੁਲਾ 2025·8 ਮਿੰਟ
Bumble ਦੀ ਵੱਖਰੀ ਪਛਾਣ: ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਅਤੇ ਡਿਜ਼ਾਈਨ ਰਾਹੀਂ ਭਰੋਸਾ
ਜਾਣੋ ਕਿ Bumble ਦੀ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਅਤੇ ਭਰੋਸਾ-ਪਹਿਲਾਂ ਫੀਚਰਾਂ ਨੇ ਇਸਨੂੰ ਭਰੇ ਹੋਏ ਉਪਭੋਗਤਾ ਐਪਾਂ ਵਿੱਚ ਵੱਖਰਾ ਕਿਵੇਂ ਬਣਾਇਆ—ਅਤੇ ਇਹ ਪਾਠ ਤੁਹਾਡੇ ਉਤਪਾਦ 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨੇ ਹਨ।
ਜਾਣੋ ਕਿ Bumble ਦੀ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਅਤੇ ਭਰੋਸਾ-ਪਹਿਲਾਂ ਫੀਚਰਾਂ ਨੇ ਇਸਨੂੰ ਭਰੇ ਹੋਏ ਉਪਭੋਗਤਾ ਐਪਾਂ ਵਿੱਚ ਵੱਖਰਾ ਕਿਵੇਂ ਬਣਾਇਆ—ਅਤੇ ਇਹ ਪਾਠ ਤੁਹਾਡੇ ਉਤਪਾਦ 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾ ਐਪ ਫੀਚਰਾਂ ਦੀ ਘਾਟ ਕਾਰਨ ਨਹੀਂ ਹਾਰਦੀਆਂ। ਉਹ ਇਸ ਲਈ ਹਾਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਪਭੋਗੀ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਇਹ ਨਹੀਂ ਸਮਝ ਸਕਦੇ ਕਿ ਇਹ ਐਪ ਦੂਜੇ ਨਾਲੋਂ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ।
ਭਰੇ ਹੋਏ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ, ਫੀਚਰ ਸੈੱਟ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਹੋ ਜਾਂਦੇ ਹਨ: ਮੈਸੇਜਿੰਗ, ਸਿਫਾਰਸ਼ਾਂ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਪ੍ਰੋਫਾਈਲ, ਭੁਗਤਾਨ, ਅਤੇ “ਪ੍ਰੀਮੀਅਮ” ਲੇਅਰ ਆਮ ਤੌਰ 'ਤੇ ਅਦਲਾ-ਬਦਲੀ ਲੱਗਣ ਲੱਗਦੇ ਹਨ। ਜਦੋਂ ਹਰ ਚੀਜ਼ ਇੱਕੋ ਜਿਹੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਾਪਤੀ ਮਹਿੰਗੀ ਹੋ ਜਾਂਦੀ ਹੈ, churn ਵਧਦਾ ਹੈ, ਅਤੇ ਵਿਕਾਸ ਉਤਪਾਦ ਦੀ ਖਿੱਚ ਦੀ ਥਾਂ ਤੇ ਹਾਊ-ਲਾਉਡ ਮਾਰਕੀਟਿੰਗ 'ਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦਾ ਹੈ।
ਦੋ ਤਾਕਤਾਂ ਭਰੇ ਹੋਏ ਐਪਾਂ ਨੂੰ ਖ਼ਾਸ ਕਰਕੇ ਜਿੱਤਣ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀਆਂ ਹਨ:
ਜਿੱਤਣ ਵਾਲੀ ਰਣਨੀਤੀ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ ਨਜ਼ਰੀਆ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ: ਇੱਕ ਵਾਅਦਾ ਜੋ ਉਪਭੋਗੀ ਕਿਸੇ ਦੋਸਤ ਨੂੰ ਦੁਹਰਾ ਸਕਦੇ ਹਨ, ਜਿਸਨੂੰ ਉਤਪਾਦ ਨਿਯਮ ਅਤੇ ਅਨੁਭਵ ਡਿਜ਼ਾਈਨ ਦੁਆਰਾ ਮਜ਼ਬੂਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
Bumble ਦੋ ਪਹਲੂਆਂ ਤੋਂ ਬਣੀ ਵੱਖ-ਭੇਦ ਦੀ ਸਾਫ਼ ਉਦਾਹਰਨ ਹੈ ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:
ਤੁਹਾਨੂੰ ਡੇਟਿੰਗ ਐਪ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਇੱਥੋਂੋਂ ਸਿੱਖਿਆ ਲੈ ਸਕੋ। ਇਹੀ ਗਤੀਵਿਧੀਆਂ ਮਾਰਕੀਟਪਲੇਸ, ਸੋਸ਼ਲ ਐਪ, ਕ੍ਰੀਏਟਰ ਪਲੇਟਫ਼ਾਰਮ, ਅਤੇ ਕਿਸੇ ਵੀ ਉਤਪਾਦ 'ਚ ਆਉਂਦੀਆਂ ਹਨ ਜਿੱਥੇ ਲੋਕ ਇੱਕ ਦੂਜੇ ਨਾਲ ਇੰਟریکਟ ਕਰਦੇ ਹਨ।
ਇਹ ਨ ਤਾਂ ਕਿਸੇ ਫਾਊਂਡਰ ਦੀ ਪ੍ਰੋਫਾਇਲ ਹੈ ਅਤੇ ਨ ਹੀ ਭਵਿੱਖਬਾਣੀ। ਇਹ ਦਿੱਖਣਯੋਗ ਉਤਪਾਦ ਚੋਇਸਜ਼ ਅਤੇ ਸ਼੍ਰੇਣੀ ਡਾਇਨਾਮਿਕਸ 'ਤੇ ਧਿਆਨ ਦੇਵੇਗੀ—ਕਿਵੇਂ ਪੋਜ਼ਿਸ਼ਨਿੰਗ UX, ਨੀਤੀਆਂ, ਅਤੇ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਰਾਹੀਂ ਅਸਲ ਬਣਦੀ ਹੈ। ਇਹ ਅੰਦਰੂਨੀ ਮੈਟ੍ਰਿਕਸ, ਮੋਟਿਵਾਂ, ਜਾਂ ਬਿਹਾਇਂਡ-ਦ-ਸੀਨ ਫੈਸਲਿਆਂ ਬਾਰੇ ਅਨੁਮਾਨ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰੇਗੀ।
ਤੁਹਾਨੂੰ ਅਮਲਯੋਗ ਤਰੀਕੇ ਮਿਲਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਜੋ ਤੁਸੀਂ:
Bumble ਦੀ ਸਥਾਪਨਾ 2014 ਵਿੱਚ Whitney Wolfe Herd ਨੇ ਕੀਤੀ, ਜੋ pehle Tinder ਦੀ ਕੋ-ਫਾਊਂਡਰ ਰਹਿ ਚੁੱਕੀ ਸਨ। ਉਸਨੇ Bumble ਨੂੰ ਇੱਕ ਐਸੀ ਡੇਟਿੰਗ ਐਪ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਲਾਂਚ ਕੀਤਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਭਰੀ ਹੋਈ ਸੀ—ਜਿੱਥੇ “ਹੋਰ ਐਪਾਂ ਵਰਗੇ ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਸਵਾਈਪ” ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ।
Bumble ਦੀ ਸ਼ੁਰੂਆਤੀ ਵੈਜ ਸਹਜ ਅਤੇ ਯਾਦ ਰਹਿਣਯੋਗ ਸੀ: ਹੇਟੇਰੋਸੈਕਸੁਅਲ ਮੇਚਜ਼ ਵਿੱਚ, ਮਹਾਵਲਾਂ ਪਹਿਲਾਂ ਸੁਨੇਹਾ ਭੇਜਦੀਆਂ ਹਨ। ਇਹ ਕੇਵਲ ਸਲੋਗਨ ਨਹੀਂ ਸੀ—ਇਹ ਡੇਟਿੰਗ ਕਿਵੇਂ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਬਾਰੇ ਇੱਕ ਸਪਸ਼ਟ ਨਜ਼ਰੀਆ ਸੀ, ਅਤੇ ਇਸ ਨੇ ਉਪਭੋਗੀਆਂ ਨੂੰ “ਕਿਉਂ Bumble?” ਦਾ ਇੱਕ ਇਕ-ਵਾਕ ਜਵਾਬ ਦਿੱਤਾ।
ਭਰੇ ਹੋਏ ਉਪਭੋਗਤਾ ਸ਼੍ਰੇਣੀਵਾਂ ਵਿੱਚ, ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਦੁਹਰਾਉਣਯੋਗ ਵਾਅਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਮੌਖਿਕ ਪਰਚਾਰ ਰਾਹੀਂ ਫੈਲਦੀ ਹੈ। ਲੋਕ ਫੀਚਰ-ਚੈੱਕਲਿਸਟ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਇਕ ਮਹਿਸੂਸ ਅਤੇ ਇਕ ਨਿਯਮ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਨ।
ਦੇਰ ਨਾਲ ਲਾਂਚ ਕਰਨ ਦਾ ਮਤਲਬ ਦੋ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਹੁੰਦਾ ਹੈ:
ਇਸ ਲਈ ਫਰਕ UI ਟਿੱਕੜੇ ਜਾਂ ਨਵੇਂ ਆਨਬੋਰਡਿੰਗ ਫਲੋ ਤੋਂ ਗਹਿਰਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਇਹ ਉਸ ਅਨੁਭਵ 'ਤੇ ਨਿਰਭਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਬਣਾਉਣ ਦੀ ਮੰਨਤਾ ਰੱਖਦੇ ਹੋ।
ਕਈ ਕੰਪਨੀਆਂ ਮਾਰਕੀਟਿੰਗ ਪੋਜ਼ਿਸ਼ਨਿੰਗ 'ਤੇ ਹੀ ਰੁਕ ਜਾਂਦੀਆਂ ਹਨ: ਟੈਗਲਾਈਨ, ਬ੍ਰੈਂਡ ਵੀਡੀਓਜ਼, ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਮੁਹਿੰਮਾਂ ਜੋ ਇਰਾਦਾਤਯੁਕਤ ਅਨੁਭਵ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ।
Bumble ਇਸ ਤੋਂ ਅੱਗੇ ਗਿਆ ਅਤੇ ਉਤਪਾਦ-ਲਾਗੂ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਵਿੱਚ ਧੱਕਿਆ: ਕੋਰ ਨਿਯਮ ਅਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਵਰਤਾਰਾ ਰੂਪ ਦਿੰਦਾ। ਜਦੋਂ ਉਤਪਾਦ ਮਕੈਨਿਕਸ ਵਾਅਦੇ ਨੂੰ ਅਜ਼ਮਾਵਦੇ ਹਨ, ਤਾਂ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਕੀਵਲ ਦਾਅਵਾ ਨਹੀਂ ਰਹਿੰਦੀ—ਉਹ ਹਰ ਵਾਰੀ ਇਕ ਮੇਚ ਹੁੰਦੇ ਸਮੇਂ ਜੀਈ ਜਾਂਦੀ ਹੈ।
ਉਤਪਾਦ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਉਹ ਸਧਾਰਣ, ਯਾਦ ਰਹਿਣਯੋਗ ਵਾਅਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ: “ਕੀ ਇਹ ਮੇਰੇ ਲਈ ਹੈ?” ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ, ਇਹ ਚਾਰ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕਿਸ ਲਈ, ਕਿਸ ਕੰਮ ਲਈ, ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ, ਅਤੇ ਕਿਉਂ ਵੱਖਰਾ।
ਭਰੇ ਹੋਏ ਉਪਭੋਗਤਾ ਐਪਾਂ ਵਿੱਚ, ਸਭ ਤੋਂ ਵਧੀਆ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਦੁਹਰਾਉਣਯੋਗ ਹੁੰਦੀ ਹੈ। ਜੇ ਉਪਭੋਗੀ ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਉਹ ਇਸ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕਰਨਗੇ—ਅਤੇ ਉਹ ਅੰਦਰ ਹੀ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਇਸ ਵਿੱਚ ਕਿਸ ਤਰ੍ਹਾਂ ਵਰਤਾਰਾ ਕਰਨੀ ਹੈ।
ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਸਿਰਫ਼ ਇੱਕ ਟੈਗਲਾਈਨ ਨਹੀਂ ਹੁੰਦੀ। ਕੁਝ ਇਰਾਦਾਤਮਕ ਚੋਣਾਂ ਤੁਹਾਡੇ ਮੁੱਲ ਅਤੇ “ਕਮਰੇ ਦੇ ਨਿਯਮ” ਨੂੰ ਸੰਚਾਰਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇਹ ਦਰਸਾ ਸਕਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋ:
ਇਹ ਚੋਣਾਂ ਉਪਭੋਗੀਆਂ ਨੂੰ ਸਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ “ਅੱਛਾ” ਕੀ ਦਿੱਖਦਾ ਹੈ—ਅਕਸਰ ਮਾਰਕੀਟਿੰਗ ਕਾਪੀ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ।
ਭੁੱਲ ਜਾਣ ਦੀ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਕਿਵੇਂ ਭੁੱਲ ਜਾਵੋ: ਹਰ ਕਿਸੇ ਵਰਗਾ ਬੋਲਣਾ (ਜੋ ਅਕਸਰ ਕਿਸੇ ਲਈ ਨਹੀਂ ਹੁੰਦਾ), ਜਨਰਿਕ ਸੁਨੇਹਾ (“ਜੁੜੋ”, “ਖੋਜੋ”, “ਲੋਕ ਮਿਲੋ”) ਬਿਨਾਂ ਨਜ਼ਰੀਏ ਦੇ, ਫੀਚਰ ਸੂਚੀ ਨੂੰ ਵਾਅਦੇ ਨਾਲ ਗਲਤ ਮਿਲਾਉਣਾ, ਜਾਂ ਵਾਅਦੇ ਅਤੇ ਅਨੁਭਵ ਵਿਚ ਗੈਰ-ਮੇਲ।
ਇਸਨੂੰ ਇੱਕ ਇਕ-ਵਾਕ ਵਾਅਦੇ ਲਈ ਵਰਤੋ:
For [specific audience], [product name] is the [category/alternative] that helps you [primary job] by [unique mechanism], so you get [clear outcome] without [key pain you remove].
ਜੇ ਤੁਸੀਂ ਇਹ ਭਰ ਨਹੀਂ ਸਕਦੇ ਬਿਨਾਂ ਧੁੰਦਲੇ ਸ਼ਬਦਾਂ ਦੇ, ਤਾਂ ਤੁਹਾਡੀ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸੰਵਾਰਨ ਦੀ ਲੋੜ ਹੈ।
ਬ੍ਰੈਂਡ ਵਾਅਦਾ ਉਹ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਮੁਹਿੰਮ ਵਿੱਚ ਕਹਿੰਦੇ ਹੋ—ਇਹ ਉਹ ਹੁੰਦਾ ਹੈ ਜੋ ਉਪਭੋਗੀ ਹਰ ਵਾਰੀ ਅਨੁਭਵ ਕਰਦੇ ਹਨ। ਭਰੇ ਹੋਏ ਐਪਾਂ ਵਿੱਚ, ਵਾਅਦੇ ਨੂੰ ਹਕੀਕਤ ਬਣਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਾਹ ਇਹ ਹੈ ਕਿ ਉਸਨੂੰ ਇੱਕ ਐਸੇ ਨਿਯਮ ਵਿੱਚ ਬਦਲ ਦਿਓ ਜੋ ਵਰਤਾਰਾ ਰੂਪ ਨੂੰ ਘੜੇ, ਨਾ ਕਿ ਕੇਵਲ ਇੱਕ ਸਕ੍ਰੀਨ।
UI ਕੁਝ ਕਾਰਵਾਈਆਂ ਨੂੰ ਉਤਸ਼ਾਹਤ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਨਿਯਮ ਨਤੀਜੇ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਉਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਕੌਣ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਸਨੇ ਜਵਾਬ ਦੇਣ ਲਈ ਕਿੰਨਾ ਸਮਾਂ, “ਵਧੀਆ ਭਾਗੀਦਾਰੀ” ਕੀ ਹੈ, ਅਤੇ ਜੇ ਲੋਕ ਨਿਯਮ ਤੋੜਦੇ ਹਨ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਰੋਕਾਵਟਾਂ ਸੰਸਕ੍ਰਿਤੀ ਬਣ ਜਾਂਦੀਆਂ ਹਨ: ਉਪਭੋਗੀ ਆਪਣੇ-ਆਪ ਨੂੰ ਉਸ ਵਾਤਾਵਰਨ ਵਿੱਚ ਚੁਣ ਲੈਂਦੇ ਹਨ ਜੋ ਉਹ ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ friction ਤੋਂ ਬਚਣ ਲਈ ਆਪਣੀ ਵਰਤਾਰਾ ਅਨੁਕੂਲ ਕਰ ਲੈਂਦੇ ਹਨ।
Bumble ਦੀ ਮੁੱਖ ਮਕੈਨਿਕ ਨਾ ਕੇਵਲ ਇੱਕ ਫੀਚਰ ਸੀ—ਇਹ ਇੱਕ ਸਪਸ਼ਟ ਸਮਾਜਿਕ ਸਮਝੌਤਾ ਲਾਗੂ ਕਰਦੀ ਸੀ: ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਗੱਲ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਨਿਯਮ ਮਹਿਲਾਵਾਂ ਕੋਲ ਸੀ। ਇਸ ਨੇ “ਮਹਿਲਾ-ਪਹਿਲੀ ਸੁਨੇਹਾ” ਨੂੰ ਬ੍ਰੈਂਡਿੰਗ ਤੋਂ interaction ਡਿਫਾਲਟ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।
ਨਤੀਜੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੇਸ਼ਗੋਈਯੋਗ ਹਨ: ਮਰਦ ਵੱਡੀ ਮਾਤਰਾ ਵਾਲੇ ਉੱਦਮ ਨਾਲ ਔਪਨਰਾਂ ਨੂੰ ਸਪੈਮ ਉੱਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਅਤੇ ਮਹਿਲਾਵਾਂ ਨੂੰ ਫੈਸਲੇਕਾਰੀ ਪਲ 'ਤੇ ਇੱਕ ਮਜ਼ਬੂਤ ਅਹਿਸਾਸ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਹਰ ਗੱਲ-ਬਾਤ ਬਿਹਤਰ ਹੋਵੇਗੀ ਕਿ ਨਹੀਂ—ਦੂਜਾ ਮੁੱਦਾ ਹੈ; ਪਰ ਨਿਯਮ ਐਪ ਨੂੰ ਕੁੱਝ ਮਿੰਟਾਂ ਵਿੱਚ ਹੀ ਅਰਥਪੂਰਨ ਤਰੀਕੇ ਨਾਲ ਵੱਖਰਾ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
ਨਿਯਮ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦੇ ਹਨ ਜੋ ਵਾਅਦੇ ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਰੱਦ ਵੀ ਕਰਦੇ ਹਨ ਜੋ ਨਹੀਂ ਚਾਹੁੰਦੇ। ਇਹ ਇੱਕ ਤਾਕਤ ਹੋ ਸਕਦੀ ਹੈ।
ਕੁਝ ਉਪਭੋਗੀ ਇਸ ਸਪਸ਼ਟਤਾ ਅਤੇ ਅਣਚਾਹੇ ਧਿਆਨ ਘੱਟ ਹੋਣ ਦੀ ਕਦਰ ਕਰਨਗੇ। ਦੂਜੇ ਸੰਕੁਚਿਤ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਉਹ ਮਹਿਲਾਵਾਂ ਜੋ ਸੁਰੂ ਕਰਨਾ ਨਹੀਂ ਚਾਹੁੰਦੀਆਂ, ਜਾਂ ਉਹ ਮਰਦ ਜੋ ਜ਼ਿਆਦਾ ਪਰੋਐਕਟਿਵ ਕੰਟਰੋਲ پسند ਕਰਦੇ ਹਨ)। “ਰੱਦ ਕਰਨ” ਪ੍ਰਭਾਵ ਹੇਠਾਂ ਆਉਣ ਦਾ ਹਿੱਸਾ ਹੈ: ਇਹ ਮਿਸ਼ਰਿਤ ਉਮੀਦਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਕਮਿਊਨਿਟੀ ਨੂੰ ਇੱਕ ਸਥਿਰ ਨਿਯਮ 'ਤੇ ਇਕਰੂਪ ਕਰਦਾ ਹੈ।
ਛੋਟੇ ਅਤੇ ਮਾਪਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਉਦੇਸ਼ ਆਪਣੀ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਨੂੰ ਮਨੋ-ਜੋਖਿਰੀ ਬਣਾ ਲਈ ਨਾ ਹੈ—ਇਸਦਾ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਅਣਦਿੱਖੀ ਨ ਰਹੇ।
ਟਰੱਸਟ ਡਿਜ਼ਾਈਨ ਫੀਚਰਾਂ ਅਤੇ ਉਪਭੋਗੀ ਫਲੋਜ਼ ਨੂੰ ਇਰਾਦਾਤਮਕ ਤੌਰ 'ਤੇ ਰੂਪ ਦੇਂਦਾ ਹੈ ਤਾਂ ਜੋ ਡਰ, ਨੁਕਸਾਨ ਅਤੇ ਅਣਨਿਰਧਾਰਤਾ ਘਟੇ—ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਉਹ ਬਾਊਂਸ ਕਰਨ ਦੇ ਕਾਰਨ ਬਣ ਜਾਣ। ਇਹ ਇਕ ਅਲੱਗ “Safety” ਟੈਬ ਜਾਂ ਨੀਤੀ ਪੰਨਾ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਕਿਵੇਂ ਵਰਤਦੀ ਹੈ ਉਹਨਾਂ ਪਲਾਂ 'ਤੇ ਜਦੋਂ ਉਪਭੋਗੀ ਚੁਪਕੇ-ਚੁਪਕੇ ਪੁੱਛਦੇ ਹਨ: ਕੀ ਇਹ ਅਸਲੀ ਹੈ? ਕੀ ਮੈਂ ਸੁਰੱਖਿਅਤ ਹਾਂ? ਕੀ ਮੈਨੂੰ ਅਫਸੋਸ ਹੋਵੇਗਾ?
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਟਰੱਸਟ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਜੋਖਮ-ਪ੍ਰਬੰਧਨ ਵਜੋਂ ਦੇਖਦੀਆਂ ਹਨ: ਲਾਜ਼ਮੀ, ਮਹਿੰਗਾ, ਅਤੇ ਵੱਖਰਾ ਵਿਕਾਸ। ਪਰ ਉਪਭੋਗਤਵਾਦੀ ਐਪਾਂ ਵਿੱਚ—ਖ਼ਾਸ ਕਰਕੇ ਜਿੱਥੇ ਅਣਜਾਣ ਲੋਕ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ—ਟਰੱਸਟ ਸਿੱਧਾ ਕਨਵਰਜ਼ਨ ਚਲਾਉਂਦਾ ਹੈ।
ਜੇ ਉਪਭੋਗੀ ਹਿੱਕ ਰਹਿੰਦੇ ਹਨ, ਉਹ ਨਹੀਂ ਕਰਦੇ:
ਚੰਗਾ ਟਰੱਸਟ ਡਿਜ਼ਾਈਨ ਓਹ ਸਾਰੀਆਂ friction ਹਟਾਂਦਾ ਹੈ ਜੋ ਭਰੋਸਾ ਨਹੀਂ ਵਧਾਉਂਦੀਆਂ (ਉਲਝਣਵਾਲਾ ਰਿਪੋਰਟਿੰਗ, ਅਸਪਸ਼ਟ ਕੰਟਰੋਲ) ਅਤੇ ਜੋ friction ਵਧਾਉਂਦੀਆਂ ਹਨ ਉਹ ਜੋ ਭਰੋਸਾ ਵਧਾਉਂਦੀਆਂ ਹਨ (ਵੈਰੀਫਿਕੇਸ਼ਨ, consent-ਅੱਗੇ ਡਿਫਾਲਟ, ਸਪਸ਼ਟ ਸਰਹੱਦ)। ਨਤੀਜਾ: ਜ਼ਿਆਦਾ ਪਹਿਲੀ ਕਾਰਵਾਈਆਂ ਅਤੇ ਬਿਹਤਰ ਰਿਟੇਨਸ਼ਨ ਕਿਉਂਕਿ ਉਪਭੋਗੀ ਨਿਯੰਤਰਣ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਟਰੱਸਟ ਖਾਸ ਪਲਾਂ ਵਿੱਚ ਬਣਦਾ (ਜਾਂ ਖ਼ਤਮ ਹੁੰਦਾ) ਹੈ:
ਕੁਝ ਰੁਝਾਨ ਸਫਲ ਉਪਭੋਗਤਾ ਐਪਾਂ ਵਿੱਚ ਵਾਰ-ਵਾਰ ਆਉਂਦੇ ਹਨ:
ਚਾਬੀ ਸਮਾਂ ਹੋਣਾ: ਇੱਥੇ ਜੋਖਮ ਵੱਧਦਾ ਹੈ ਉਹਥੇ friction ਜੋੜੋ, ਘੱਟ-ਖਤਰੇ ਪਲਾਂ ਨੂੰ ਤੇਜ਼ ਰੱਖੋ।
ਟਰੱਸਟ ਉਪਾਂਚੇ ਛੇਤੀ ਤਰਕ ਵਿੱਚ ਘਟਾ ਸਕਦੇ ਹਨ (ਉਦਾਹਰਨ: ਜੇ verification ਲਾਜ਼ਮੀ ਹੋਵੇ ਤਾਂ ਸਾਈਨਅਪ ਘੱਟ ਹੋ ਸਕਦੇ ਹਨ)। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ activation ਲਈ optimize ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸੁਰੱਖਿਆ ਹਟਾਉਣ ਦੀ ਲੋਭਣਾ ਮਹਿਸੂਸ ਕਰੋਗੇ। ਇਸਨੂੰ ਸੰਤੁਲਿਤ ਰੱਖੋ:
ਜਦੋਂ ਟਰੱਸਟ ਡਿਜ਼ਾਈਨ ਮੂਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਸੁਰੱਖਿਆ “ਵਾਧੂ” ਨਹੀਂ ਰਹਿੰਦੀ—ਇਹ ਉਹੀ ਚੀਜ਼ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸ ਲਈ ਉਪਭੋਗੀ ਵਾਪਸ ਆਉਂਦੇ ਹਨ।
ਟਰੱਸਟ ਇਕ ਫੀਚਰ ਨਹੀਂ ਜੋ ਤੁਸੀਂ “ਸ਼ਾਮਲ” ਕਰਦੇ ਹੋ। ਇਹ ਛੋਟੇ ਸੰਕੇਤਾਂ ਅਤੇ ਰੱਖਿਆਵਾਂ ਦੀ ਲੜੀ ਹੈ ਜੋ ਉਹਨਾਂ ਪਲਾਂ 'ਤੇ ਦਿੱਤੀ ਜਾਂਦੀਆਂ ਹਨ ਜਿੱਥੇ ਉਪਭੋਗੀ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨਜ਼ੁਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਇਸ ਨੂੰ ਯੋਜਨਾ ਬਣਾਉਣ ਦਾ ਇੱਕ ਉਪਯੋਗੀ ਢੰਗ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਰਲ ਟਰੱਸਟ ਯਾਤਰਾ (ਲਗਾਤਾਰ) ਨਕਸ਼ਾ ਬਣਾਓ, ਫਿਰ ਹਰ ਪੜਾਅ ਤੇ ਉਤਪਾਦ ਕੀ ਵਾਅਦਾ ਕਰੇਗਾ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ।
ਆਨਬੋਰਡਿੰਗ → ਮੈਚਿੰਗ → ਮੈਸੇਜਿੰਗ → ਮਿਲਣਾ → ਪੋਸਟ-ਇੰਟਰੈਕਸ਼ਨ। ਹਰ ਮੰਚ ਲਈ ਪੁੱਛੋ: ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ, ਇੱਕ ਸੁਰੱਖਿਅਤ ਉਪਭੋਗੀ ਕੀ ਉਮੀਦ ਕਰੇਗਾ, ਅਤੇ ਕੀ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ ਬਨਾਮ ਸਿਰਫ਼ ਨਾ-ਪਸੰਦ ਕੀਤੀ ਜਾਣੀ ਚੀਜ਼?
ਕੁਝ ਪੈਟਰਨ ਸਫਲ ਉਤਪਾਦਾਂ ਵਿੱਚ ਨੇਹਰੇ-ਨੇਹਰੇ ਦਿਖਦੇ ਹਨ:
ਸੰਕੇਤ ਸਮਾਂ ਬਹੁਤ ਜਰੂਰੀ ਹੈ: ਜੋਖਮ ਵੱਧਣ 'ਤੇ friction ਜੋੜੋ, ਘੱਟ-ਖਤਰੇ ਪਲਾਂ ਤੇ ਤੇਜ਼ ਰਹੋ।
ਪਹਿਲਾਂ ਉਹ ਪਲ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜਿੱਥੇ ਜੋਖਮ ਸਭ ਤੋਂ ਵੱਧ ਹੈ—ਅਤੇ ਉਤਪਾਦ ਦਾ ਸੁਰੱਖਿਆ ਵਾਅਦਾ ਮਹਿਸੂਸ ਕਰਨ ਯੋਗ ਬਣਾਓ, ਸਿਰਫ਼ ਵਰਣਨ ਕਰਨ ਯੋਗ ਨਹੀਂ।
ਦੋ-ਪਾਸੇ ਉਪਭੋਗਤਾ ਐਪ (ਡੇਟਿੰਗ, ਰਾਈਡ, ਜਾਂ ਮਾਰਕੀਟਪਲੇਸ) ਸਿੱਧੀ ਲਕੀਰ ਵਿੱਚ ਨਹੀਂ ਵਧਦੀਆਂ। ਉਹ ਨੈੱਟਵਰਕ ਪ੍ਰਭਾਵਾਂ ਰਾਹੀਂ ਵਧਦੀਆਂ ਹਨ: ਜਦੋਂ ਐਪ ਕੀਮਤੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਲੋਕ ਹੋਰ ਲੋਕਾਂ ਨੂੰ ਬੁਲਾਂਦੇ ਹਨ, ਜੋ ਇਸਨੂੰ ਹੋਰ ਕੀਮਤੀ ਬਣਾਉਂਦਾ ਹੈ। ਪਰ ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ “ਨੈੱਟਵਰਕ” ਨਾਜ਼ੁਕ ਹੁੰਦੀ ਹੈ—ਇੱਕ ਮਾੜਾ ਪਹਿਲਾ ਪ੍ਰਭਾਵ ਹੀ ਲੂਪ ਨੂੰ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਰੋਕ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਉਪਭੋਗੀ ਘੱਟ ਹੁੰਦੇ ਹਨ, ਹਰ ਇੰਟਰੈਕਸ਼ਨ ਕੁੱਲ ਅਨੁਭਵ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਸਪੈਮੀ ਪ੍ਰੋਫਾਈਲ ਜਾਂ ਆਕਰਮਣਕ ਸੁਨੇਹੇ ਵਾਈਬ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਨਵੇਂ ਉਪਭੋਗੀਆਂ ਨੂੰ ਦੂਰ ਭਜੇ ਦੇ ਸਕਦੇ ਹਨ। ਇਹ ਇਕ ਗੰਢੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦੀ ਹੈ: ਘੱਟ ਚੰਗੇ ਉਪਭੋਗੀ ਆਉਂਦੇ ਹਨ, ਜਿਹੜੇ ਤਦ ਮੰਚ ਹੋਰ ਮਾੜਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤੇ ਹੋਰ ਚੰਗੇ ਉਪਭੋਗੀ ਦੂਰ ਰਹਿਣਦੇ ਹਨ।
ਟਰੱਸਟ ਅਤੇ ਸੁਰੱਖਿਆ ਸਿਰਫ਼ ਜੋਖਮ-ਪ੍ਰਬੰਧਨ ਨਹੀਂ—ਇਹ ਮਾਰਕੀਟਪਲੇਸ ਰੱਖ-ਰਖਾਅ ਹੈ। ਉਤਪਾਦ ਚੋਇਸਜ਼ ਜਿਵੇਂ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਸਪਸ਼ਟ ਰਿਪੋਰਟਿੰਗ ਫਲੋਜ਼, ਦੁਹਰਾਉਣ ਵਾਲੇ ਦੋਸ਼ੀਆਂ ਲਈ friction, ਅਤੇ ਘੱਟ-ਇਰਾਦੇ ਵਾਲੇ ਵਰਤਾਰਿਆਂ 'ਤੇ ਸੀਮਾਵਾਂ ਨਕਾਰਾਤਮਕ ਇੰਟਰੈਕਸ਼ਨਾਂ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ ਜੋ ਲੋਕਾਂ ਨੂੰ ਦੂਰ ਭਜਾਉਂਦੀਆਂ ਹਨ।
ਨਤੀਜਾ ਸਿਰਫ ਘਟੀਆ ਘਟਨਾ ਨਹੀਂ ਹੁੰਦੀ; ਇਹ ਭਾਗੀਦਾਰੀ ਵਿੱਚ ਵਾਧਾ ਵੀ ਲਿਆਉਂਦੀ ਹੈ। ਹੋਰ ਲੋਕ ਮੇਲ-ਮਿਲਾਪ, ਮੈਸੇਜਿੰਗ, ਅਤੇ ਵਾਪਸੀ ਲਈ ਆਰਾਮ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ—ਜੋ ਉਹ ਸਰਗਰਮੀਆਂ ਹਨ ਜੋ ਦੂਜਿਆਂ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ।
ਸਿਰਫ਼ ਮਾਤਰਾ ਲਈ optimize ਕਰਨਾ ਆਕਰਸ਼ਕ ਹੁੰਦਾ ਹੈ: ਸਾਈਨ-ਅਪ, ਮੇਚ, ਅਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਵੱਧ ਕਰਨਾ। ਪਰ ਜੇ ਤੁਸੀਂ ਲਿਕਵਿਡਿਟੀ ਵਧਾਉਣ ਲਈ ਮਿਆਰ ਘਟਾ ਦਿਓ (ਬੋਟ ਆਉਣ ਦਿਓ, ਉਤਪੀੜਨ ਚੱਲਣ ਦਿਓ, ਸਪੈਮੀ outreach ਨੂੰ ਉਤਸ਼ਾਹਤ ਕਰੋ), ਤਾਂ ਤੁਸੀਂ ਊਪਰੀ ਗਿਣਤੀ ਵਧਾ ਸਕਦੇ ਹੋ ਪਰ ਰਹਿਣ ਨੂੰ ਖ਼ਤਮ ਕਰ ਦੇ ਸਕਦੇ ਹੋ—ਖ਼ਾਸ ਕਰਕੇ ਉਹ ਉਪਭੋਗੀ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ਸਥਿਰ ਲਿਕਵਿਡਿਟੀ ਉਹ ਹੈ ਜਦੋਂ ਉਪਭੋਗੀ ਮੁੜ-ਮੁੜ ਸ਼ਾਮਿਲ ਹੋਣ ਲਈ ਕਾਫ਼ੀ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਵਿਕਾਸ ਨੂੰ ਗੁਣਵੱਤਾ ਨਾਲ ਸੰਤੁਲਿਤ ਕਰਨ ਲਈ ਟਰੈਕ ਕਰੋ:
ਜੇ ਸੁਨੇਹੇ ਵਧ ਰਹੇ ਹਨ ਪਰ ਦੁਹਰਾਓ ਘਟ ਰਹੇ ਹਨ—ਜਾਂ ਰਿਪੋਰਟ ਦਰ ਚੜ੍ਹ ਰਹੀ ਹੈ—ਤਾਂ ਤੁਸੀਂ ਲਿਕਵਿਡਿਟੀ ਨਹੀਂ ਬਣਾ ਰਹੇ; ਤੁਸੀਂ churn ਤੇਜ਼ ਕਰ ਰਹੇ ਹੋ।
ਟਰੱਸਟ ਫੀਚਰਾਂ ਨੂੰ ਇੱਕ ਲੁਕਾਏ ਹੋਏ “Safety” ਮੈਨੂ ਵਿੱਚ ਛੱਡ ਕੇ ਨਾ ਰੱਖੋ; ਜਦੋਂ ਸੁਰੱਖਿਆ ਬ੍ਰੈਂਡ ਵਾਅਦੇ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਦਿੱਸਣਯੋਗ, ਸਪਸ਼ਟ, ਅਤੇ ਗੱਲ ਕਰਨ ਯੋਗ ਹੋ ਜਾਂਦੀ ਹੈ—ਕੁਝ ਜੋ ਉਪਭੋਗੀ ਐਪ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਿਆਂ ਦਰਸਾ ਸਕਦੇ ਹਨ।
ਟਰੱਸਟ ਜਲਦੀ ਬ੍ਰੈਂਡ ਇਕੇਵਟੀ ਬਣਦਾ ਹੈ ਜਦੋਂ ਉਹ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਸਬੂਤ ਬਣ ਜਾਂਦੇ ਹਨ:
ਇਹ ਤੱਤ ਮਾਰਕੀਟਿੰਗ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਉਹੀ ਪਲ 'ਤੇ ਅਣਨਿਸ਼ਚਿਤਾ ਘਟਾਉਂਦੇ ਹਨ ਜਦੋਂ ਉਪਭੋਗੀ ਭਾਗ ਲੈਣ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹਨ।
ਜੇ ਉਤਪਾਦ ਕਹਿੰਦਾ ਹੈ “ਅਸੀਂ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੇ ਹਾਂ,” ਪਰ ਸਪੋਰਟ ਹੌਲੀ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਾਂ canned ਜਵਾਬ ਵਰਤੀਦਾ ਹੈ, ਤਾਂ ਉਪਭੋਗੀ ਵਾਅਦੇ ਨੂੰ ਹੋਰ ਕੀਵਡ ਵਰਗ ਮਹਿਸੂਸ ਕਰਨਗੇ। ਸੰਰੂਪਤਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦੀ ਹੈ:
ਇੱਕ ਆਮ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਉਹ ਵਿਕਾਸ ਪ੍ਰਯੋਗ ਚਲਾਉਂਦੇ ਹਨ ਜੋ ਟਰੱਸਟ ਵਾਅਦੇ ਦੇ ਵਿਰੁੱਧ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਨਾਂ: ਮੋਡਰੇਸ਼ਨ ਨੂੰ ਢਿੱਲਾ ਕਰਨਾ ਤਾਂ ਕਿ ਮੈਸੇਜਿੰਗ ਵਧੇ, ਰਿਪੋਰਟ ਕਰਨ ਵਾਲੇ ਲੋਕਾਂ ਨੂੰ ignore ਕਰਦੇ ਹੋਏ ਉਨ੍ਹਾਂ ਨੂੰ re-engage ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜਣਾ, ਜਾਂ “ਟਾਈਮ ਟੂ ਫਸਟਰਟ ਮੈਸੇਜ” ਨੂੰ optimize ਕਰਨਾ ਜਿਵੇਂ ਉਪਭੋਗੀਆਂ ਨੂੰ ਅਣਚਾਹੇ interactions ਲਈ ਦਬਾਅ ਪਾਉਣਾ।
ਬ੍ਰੈਂਡ ਈਕਵੀਟੀ ਉਸ ਸਮੇਂ ਬਣਦੀ ਹੈ ਜਦੋਂ ਟਰੱਸਟ ਰੋਕਾਵਟਾਂ ਨੂੰ ਗੈਰ-ਬਾਤ-ਚਾਰਤ ਉਤਪਾਦ ਨਿਯਮਾਂ ਵਜੋਂ ਸਮਝਿਆ ਜਾਵੇ—ਨ ਕਿ ਅਜਿਹਾ ਕੁਝ ਜੋ ਮੈਟ੍ਰਿਕਸ ਲਈ ਸਮੇਂ-ਵਾਰ ਬਦਲਿਆ ਜਾਵੇ।
ਫੀਚਰ ਤੇਜ਼ੀ ਨਾਲ ਨਕਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਪੋਜ਼ਿਸ਼ਨਿੰਗ—ਉਹ ਜੋ ਉਪਭੋਗੀ ਮੰਨਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਸ ਲਈ ਹੋ—ਨਕਲ ਕਰਨਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਮੀਦਾਂ, ਆਦਤਾਂ, ਅਤੇ ਕਮਿਊਨਿਟੀ ਦੇ ਵਰਤਾਰਿਆਂ ਵਿੱਚ ਬਸਿਆ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਮੁਕਾਬਲੀ ਬੰਦੀ “ਵੈਰੀਫਿਕੇਸ਼ਨ”, “ਮਹਿਲਾ ਪਹਿਲਾਂ ਸੁਨੇਹਾ”, ਜਾਂ “ਰਿਪੋਰਟਿੰਗ ਟੂਲ” ਰਿਲੀਜ਼ ਕਰ ਸਕਦੀ ਹੈ। ਪਰ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਦੀ ਨਕਲ ਕਰਨੀ ਇਹ ਮੰਗਦੀ ਹੈ ਕਿ ਉਪਭੋਗੀ ਨੂੰ ਮੁੜ-ਸਿੱਖਾਇਆ ਜਾਵੇ ਕਿ ਉਤਪਾਦ ਕਿਸ ਲਈ ਹੈ ਅਤੇ ਇਹ ਕਿਸ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਵਾਅਦਾ ਸਧਾਰਨ enough ਹੋਵੇ (“ਇਹ ਉਹ ਐਪ ਹੈ ਜਿੱਥੇ…”), ਤਾਂ ਹਰ ਸਕ੍ਰੀਨ, ਨਿਯਮ, ਅਤੇ ਸਹਾਇਤਾ ਇੰਟਰੈਕਸ਼ਨ ਇਸਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ। ਇੱਕ ਨਕਲ ਕਰਨ ਵਾਲਾ UI ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸਾਲਾਂ ਦੀ ਕਾਂਸਿਸਟੈਂਸੀ ਵਾਲੀਆਂ ਨਤੀਜਿਆਂ ਨੂੰ ਤੁਰੰਤ ਦੁਹਰਾਉਣ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਰੱਖਯੋਗਤਾ ਉਸ ਸਿਸਟਮ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜੋ ਇੰਟਰਫੇਸ ਦੇ ਪਿੱਛੇ ਹੈ:
ਜਦੋਂ ਇਹ ਹਿੱਸੇ মিল ਜਾਂਦੇ ਹਨ, ਟਰੱਸਟ ਇੱਕ ਫੀਚਰ ਨਹੀਂ ਰਹਿੰਦੀ; ਇਹ ਲੋਕਾਂ ਦੇ ਰਹਿਣ ਦੀ ਵਜ੍ਹਾ ਬਣ ਜਾਂਦੀ ਹੈ।
ਉਪਭੋਗਤਾ ਐਪ ਆਮ ਤੌਰ 'ਤੇ ਠੇਕੇ ਨਾਲ ਯੂਜ਼ਰ ਨੂੰ ਬੰਨ੍ਹਦੇ ਨਹੀਂ। ਉਹ ਲੋਕਾਂ ਨੂੰ ਇੰਝ ਰੱਖਦੇ ਹਨ:
ਜਿੰਨਾ ਮਜ਼ਬੂਤ ਤੁਹਾਡਾ ਟਰੱਸਟ ਸਿਸਟਮ ਹੋਵੇਗਾ, ਉੱਥੇ ਤੋ ਤਕ ਦੀ ਇੱਜ਼ਤ ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਬਣਦੀ ਜਾਏਗੀ।
ਤੁਸੀਂ ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਨੂੰ ਵਿਕਸਤ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਸਨੂੰ ਛੱਡੇ। ਕੋਰ ਵਾਅਦਾ ਸਥਿਰ ਰੱਖੋ, ਫਿਰ ਨਜ਼ਦੀਕੀ ਫਾਇਦਿਆਂ ਨਾਲ ਘੇਰਾ ਫੈਲਾਓ (ਉਦਾਹਰਣ: “ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ” ਤੋਂ “ਜ਼ਿਆਦਾ ਮਨਸੂਕ” ਜਾਂ “ਸਮਰਥ” ਤੋਂ “ਉੱਚ ਗੁਣਵੱਤਾ”)। ਸੁਨੇਹਾ ਤਹਾਂ-ਤਹਾਂ ਬਦਲੋ, ਇੱਕ ਸਤਹ (ਆਨਬੋਰਡਿੰਗ) 'ਤੇ ਟੈਸਟ ਕਰੋ, ਅਤੇ ਫਿਰ ਹੀ ਇਹ ਵਿਕਲਪ ਉਤਪਾਦ 'ਤੇ ਫੈਲਣ ਦਿਓ।
ਵੱਖਰਾ ਕਰਨਾ ਇਕ ਸਲੋਗਨ ਨਹੀਂ—ਇਹ ਉਸ ਉਤਪਾਦੀ ਫੈਸਲਿਆਂ ਦਾ ਸੈਟ ਹੈ ਜੋ ਤੁਸੀਂ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਛੋਟੀ ਪਲੇਅਬੁੱਕ ਨਾਲ “ਪੋਜ਼ਿਸ਼ਨਿੰਗ + ਟਰੱਸਟ ਬਾਈ ਡਿਜ਼ਾਈਨ” ਨੂੰ ਹਫ਼ਤਾਵਾਰੀ ਕਾਰਜ ਵਿੱਚ ਬਦਲੋ।
ਇੱਕ ਵਾਕ ਲਿਖੋ ਜੋ ਨਾਮ ਲਵੇ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨੂੰ ਸੇਵਾ ਦੇ ਰਹੇ ਹੋ ਅਤੇ ਸਫਲਤਾ ਕਿਵੇਂ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।
ਊਦਾਹਰਣ ਸਾਂਚਾ: “For [specific group], our app helps them [complete one meaningful outcome] without [the main anxiety or friction].” ਜੇ ਤੁਸੀਂ “everyone” ਵਰਤਦੇ ਹੋ ਜਾਂ ਤਿੰਨ ਨਤੀਜੇ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਇਹ ਅਜੇ ਵੀ ਬਹੁਤ ਚੌੜਾ ਹੈ।
ਇੱਕ ਨਿਯਮ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਕੋਡ ਵਿੱਚ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ—ਕੇਵਲ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਨਹੀਂ। ਵਧੀਆ ਨਿਯਮ ਸਧਾਰਨ, ਦਿੱਖਣਯੋਗ, ਅਤੇ ਗਲਤ ਸਮਝਣ ਦੇ ਲਈ ਔਖੇ ਹੁੰਦੇ ਹਨ।
ਪੁੱਛੋ: ਪਹਿਲੇ 60 ਸਕਿੰਟਾਂ ਵਿੱਚ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਵੱਖਰਾ ਬਣਾਉਣ ਵਾਲੀ ਇੱਕ ਸੀਮਿਤ ਰੋਕ ਕੀ ਹੋਵੇਗੀ? (ਉਦਾਹਰਨ: ਕੌਣ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਸ ਵੇਲੇ ਮੈਸੇਜਿੰਗ ਖੁਲਦੀ ਹੈ, ਕਿਹੜੀ ਗਤੀਵਿਧੀ ਪੋਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ)
ਆਨਬੋਰਡਿੰਗ, ਪਹਿਲਾ ਇੰਟਰੈਕਸ਼ਨ, ਜਾਰੀ ਭਾਗੀਦਾਰੀ, ਅਤੇ ਬਹਿਰ ਜਾਣੇ ਸਮੇਂ ਵਿੱਚ ਆਪਣੇ ਮੁੱਖ ਜੋਖਿਮ ਨਕਸ਼ਾ ਬਣਾਓ।
ਫਿਰ ਇਹ "ਟਰੱਸਟ ਮੋਮੈਂਟ" ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਾਟੋਟਾਈਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗੇ ਟੂਲਸ ਚੈਟ ਰਾਹੀਂ onboarding copy, verification gates, reporting UX ਅਤੇ admin ਵਰਕਫਲੋਜ਼ ਨੂੰ ਜ਼ਲਦੀ ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ—ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਫਲੋਜ਼ ਨੂੰ ਕੱਠਾ ਕਰਕੇ ਆਸਾਨੀ ਨਾਲ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।
ਟਰੱਸਟ ਨੂੰ ਇੱਕ ਕੋਰ ਉਤਪਾਦ ਮੈਟਰਿਕ ਵਜੋਂ ਲਓ, ਨਾ ਕਿ ਸਿਰਫ਼ ਸਪੋਰਟ ਬੈਕਲੌਗ।
ਛੋਟਾ ਸੈਟ ਟਰੈਕ ਕਰੋ: ਰਿਪੋਰਟ ਦਰ, ਸਮਾਂ-ਤਕ-ਰੈਜ਼ੋਲੂਸ਼ਨ, ਦੁਹਰਾਓਣ ਵਾਲੇ ਦੋਸ਼ੀਆਂ ਦੀ ਦਰ, ਵੈਰੀਫਾਇਡ-ਤੋਂ-ਅਨਵੇਰੀਫਾਇਡ ਰੂਪਾਂਤਰਣ, ਬਲੌਕ/ਮਿਊਟ ਵਰਤੋ, ਅਤੇ “ਸੁਰੱਖਿਅਤ ਇੰਟਰੈਕਸ਼ਨ” ਵਿਰੁੱਧ “ਖਤਰਨਾਕ ਇੰਟਰੈਕਸ਼ਨ” ਦੌਰਾਨ ਸੈਗਮੈਂਟ ਕੀਤਾ ਰਿਟੇਨਸ਼ਨ। ਪ੍ਰੋਡੈਕਟ, ਡਿਜ਼ਾਈਨ, ਅਤੇ ਓਪਸ ਮੀਟਿੰਗ ਵਿੱਚ ਇਹਨਾ ਨੂੰ ਹਫਤਾਵਾਰੀ ਵੇਖੋ।
ਇੱਕ ਜਾਂ ਦੋ ਪੰਗਤੀਆਂ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਉਦੋਂ ਦੁਰਬੀਨ ਕਰ ਸਕੇ ਜਦੋਂ ਵਿਕਾਸ ਵਿਚਾਰ-ਵਿਮਰਸ਼ ਕਰ ਰਹੀ ਹੋਵੇ।
ਉਦਾਹਰਨ: “We prioritize [user group] feeling [safe outcome] over maximizing [engagement metric]. If an experiment improves clicks but increases [harm signal], we don’t ship it.”
ਜੇ ਟਰੱਸਟ ਫੀਚਰ ਵਿਸ਼ੇਸ਼, ਦਿੱਖਣਯੋਗ, ਅਤੇ ਲਗਾਤਾਰ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ ਤਾਂ ਉਹ ਨਾਟਕ ਬਣ ਸਕਦੇ ਹਨ। ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਿਸ਼ਵਾਸ ਖਤਮ ਕਰ ਦੇਣ ਦਾ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ “ਸੁਰੱਖਿਆ” ਦਾ ਵਾਅਦਾ ਕੀਤਾ ਜਾਵੇ ਪਰ ਮਾੜੇ ਵਰਤਾਰਿਆਂ ਨੂੰ ਬਿਨਾਂ ਰੋਕ-ਥਾਮ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ—ਜਾਂ ਕੰਟਰੋਲ ਇੰਨੇ ਛੁਪੇ ਹੋਣ ਕਿ ਕੇਵਲ ਪਾਵਰ ਯੂਜ਼ਰ ਉਹਨਾਂ ਤੱਕ ਪਹੁੰਚ ਪਾਵੇ।
ਅਕਸਰ ਗਲਤੀ ਹੈ: ਢਿੱਲਾ ਸੁਰੱਖਿਆ ਸੰਦੇਸ਼ (“ਅਸੀਂ ਸੁਰੱਖਿਆ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਂਦੇ ਹਾਂ”) ਬਿਨਾਂ ਉਪਭੋਗੀ-ਦੇਖਣਯੋਗ ਸਬੂਤ ਦੇ: ਵੈਰੀਫਿਕੇਸ਼ਨ ਦਰ, ਰਿਪੋਰਟਿੰਗ ਉਮੀਦਾਂ, ਜਾਂ ਰਿਪੋਰਟ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ।
ਅਸੰਘਟਿਤ ਪਰਵਾਨਗੀ ਨੂ ਕਦੇ-ਕਦੇ ਕੋਈ ਹੋਰ ਨਾਲੋਂ ਭੇਤਰ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਦੋ ਵੱਖ-ਵੱਖ ਉਪਭੋਗੀਆਂ ਨੇ ਇੱਕੋ ਵਰਤੀ ਵਰਤਾਰਾ ਰਿਪੋਰਟ ਕੀਤਾ ਅਤੇ ਵੱਖ-ਵੱਖ ਨਤੀਜੇ ਮਿਲੇ, ਤਾਂ ਲੋਕ ਸਿਸਟਮ ਨੂੰ ਬੇਰੁਖੀ ਜਾਂ ਪੱਖਪਾਤੀ ਸਮਝ ਲੈਂਦੇ ਹਨ।
ਲੁਕਾਏ ਹੋਏ ਕੰਟਰੋਲ ਵੀ ਇਕ ਫੇਲ ਹੋਣ ਦਾ ਤਰੀਕਾ ਹੈ: ਬਲਾਕਿੰਗ, ਰਿਪੋਰਟਿੰਗ, ਅਤੇ ਮੈਸੇਜ਼ ਫਿਲਟਰ ਉਸ ਸਮੇਂ ਉਪਲਬਧ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜਦੋਂ ਉਪਭੋਗੀ ਨੂੰ ਜ਼ਰੂਰਤ ਹੋਵੇ—ਨ ਕਿ ਕਈ ਮੀਨੂਅ ਬੀਚ ਓਹਨਾਂ ਨੂੰ ਲੁਕਾਉਣਾ।
ਕੁਝ ਵਿਕਾਸ ਤਕਨੀਕਾਂ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਟਰੱਸਟ-ਨੈਗੇਟਿਵ ਹੁੰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ: mass-messaging ਨੂੰ ਇਨਾਮ ਦੇਣਾ, ਉਹਨਾਂ ਨੂੰ re-engagement ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜਣਾ ਜਿਨ੍ਹਾਂ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਕਿਸੇ ਨੂੰ ਰਿਪੋਰਟ ਕੀਤਾ ਹੋਵੇ, ਜਾਂ ਰੈਫਰਲ ਬੋਨਸ ਜੋ disposable accounts ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੇ ਮੈਟ੍ਰਿਕਸ “ਸਨੇਹੇ ਭੇਜੇ” ਦੀ ਉਤਸ਼ਾਹੀ ਕਰਦੇ ਹਨ ਬਿਨਾਂ ਗੁਣਵੱਤਾ ਨਿਪਟਾਰੇ ਦੇ, ਤਾਂ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਸਪੈਮ ਅਤੇ ਉਤਪੀੜਨ ਨੂੰ ਸਹਾਇਕ ਕਰ ਦਿਓਗੇ। ਇਕ ਸਿਹਤਮੰਦ ਨਾਰਥ-ਸਟਾਰ “ਅਰਥਪੂਰਕ ਗੱਲ-ਬਾਤਾਂ” ਜਾਂ “ਸੁਰੱਖਿਅਤ ਮੇਚਜ਼” ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਗੁਣਵੱਤਾ ਸੰਕੇਤਾਂ ਨਾਲ ਮਾਪਿਆ ਜਾਵੇ।
ਪ੍ਰਯੋਗ ਸੰਭਵ ਹਨ, ਪਰ ਸੁਰੱਖਿਆ ਲਈ ਗਾਰਡਰੇਲ ਚਾਹੀਦੇ ਹਨ:
ਆਟੋਮੇਸ਼ਨ ਸਪੱਸ਼ਟ ਪੈਟਰਨ (ਡੁਪਲੀਕੇਟ ਸਪੈਮ, ਜਾਣੇ-ਪਹਚਾਣੇ ਖਰਾਬ ਲਿੰਕ) ਫੜ ਸਕਦੀ ਹੈ, ਪਰ ਸੁੱਖੀ ਸਥਿਤੀਆਂ ਲੋਕਾਂ ਦੀ ਲੋੜ ਹੈ। ਉੱਚ-ਸੰਭਾਵਨਾ ਵਾਲੀਆਂ ਰਿਪੋਰਟਾਂ ਅਤੇ ਦੁਹਰRepeating offenders ਲਈ ਇੱਕ ਹਲਕੀ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਕਤਾਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਜਿਵੇਂ ਵਾਲਿਆੰ ਵਧੇ ਉਹਨਾਂ ਨੂੰ ਤਰਤੀਬੀਕਰਨ ਦੇ-ਨਾਲ ਆਟੋਮੇਟ ਕਰੋ (ਤਰੀਅੱਜ, ਤਰਜੀਹ)।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਾਯੋਗਿਕ ਢਾਂਚਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog/trust-by-design ਦੇਖੋ।
ਭਰਿਆ ਹੋਇਆ ਉਪਭੋਗੀ ਵਰਗ ਵਿਭਾਗਾਂ ਵਿੱਚ, ਮੁਕਾਬਲੇ ਤੇਜ਼ੀ ਨਾਲ ਨਜ਼ਰ ਆਉਣ ਵਾਲੀਆਂ ਫੀਚਰਾਂ ਦੀ ਨਕਲ ਕਰ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਐਪ ਅਕਸਰ ਇਸ ਲਈ ਹਾਰ ਜਾਂਦਾ ਹੈ ਕਿ ਉਪਭੋਗੀ ਤੁਰੰਤ ਸਮਝ ਨਹੀਂ ਪਾਉਂਦੇ ਕਿ ਅਨੁਭਵ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਵੱਖਰਾ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਹਰ ਚੀਜ਼ ਇੱਕੋ ਜਿਹੀ ਲੱਗਣੀ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇ, ਤਾਂ ਪ੍ਰਾਪਤੀ ਮਹਿੰਗੀ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਰੱਖ-ਰਖਾਵ ਘਟਦਾ ਹੈ ਕਿਉਂਕਿ ਕਿਸੇ ਇਕ ਉਤਪਾਦ ਨੂੰ ਚੁਣਨ ਜਾਂ ਉਸ ਨਾਲ ਟਿਕੇ ਰਹਿਣ ਦਾ ਸਪਸ਼ਟ ਕਾਰਨ ਨਹੀਂ ਰਹਿੰਦਾ।
ਪੋਜ਼ਿਸ਼ਨਿੰਗ ਇੱਕ ਸਧਾਰਣ, ਦੁਹਰਾਉਣਯੋਗ ਵਾਅਦਾ ਹੈ ਜੋ ਉਪਭੋਗੀ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ: “ਕੀ ਇਹ ਮੇਰੇ ਲਈ ਹੈ?” ਇਹ ਇੱਕ ਵਾਕ ਵਿਚ ਸਮਝਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ:
ਇੱਕ ਨਿਯਮ-ਆਧਾਰਿਤ ਫਰਕ ਉਹ ਉਤਪਾਦੀ ਮਕੈਨਿਜ਼ਮ ਹੈ ਜੋ ਵਾਅਦੇ ਨੂੰ ਬੱਸ ਮਾਰਕੀਟਿੰਗ ਨਹੀਂ ਰੱਖਦਾ, ਸਗੋਂ ਅਮਲ ਵਿੱਚ ਲਿਆਂਦਾ ਹੈ। Bumble ਦਾ “ਮਹਿਲਾ ਪਹਿਲੇ ਸੁਨੇਹੇ ਭੇਜੇ” ਵਾਲਾ ਨਿਯਮ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਕਿਉਂਕਿ ਉਪਭੋਗੀ ਨਿਰਣਾੈਕ ਪਲ ਤੇ ਫਰਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ (ਪਹਿਲੇ ਸੰਪਰਕ 'ਤੇ), ਅਤੇ ਨਿਯਮ ਪ੍ਰੇਰਣਾਵਾਂ ਅਤੇ ਵਰਤਾਰਾ ਬਦਲ ਦਿੰਦਾ ਹੈ—ਸਿਰਫ਼ UI ਨਹੀਂ।
ਇੱਕ ਖਾਕਾ ਲਿਖੋ:
For [specific audience], [product] is the [category/alternative] that helps you [primary job] by [unique mechanism], so you get [outcome] without [key anxiety/friction].
ਜੇ ਤੁਸੀਂ “everyone” ਪਾ ਸਕਦੇ ਹੋ ਜਾਂ ਤੁਹਾਨੂੰ vague ਸ਼ਬਦ ਵਰਗੇ “better” ਜਾਂ “smarter” ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਦਰਸ਼ਕ, ਕੰਮ, ਜਾਂ ਮਕੈਨਿਜ਼ਮ ਨੂੰ ਤੰਗ ਕਰੋ ਜਦ ਤੱਕ ਵਾਕ ਸਪਸ਼ਟ ਨਾ ਹੋ ਜਾਵੇ।
ਟਰੱਸਟ ਡਿਜ਼ਾਈਨ ਉਹ ਹੈ ਜੋ ਫਲੋਜ਼ ਅਤੇ ਉਤਪਾਦੀ ਚੋਇਸਜ਼ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੰਵਾਰਦਾ ਹੈ ਕਿ ਡਰ ਅਤੇ ਅਣਨਿਰਧਾਰਤਾ ਘਟੇ—ਉਹ ਪਲ ਜਦੋਂ ਉਪਭੋਗੀ ਸਰਗਰਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸੋਚਦੇ ਹਨ: ‘ਕੀ ਇਹ ਅਸਲੀ ਹੈ? ਕੀ ਮੈਂ ਸੁਰੱਖਿਅਤ ਹਾਂ? ਕੀ ਮੈਨੂੰ ਅਫਸੋਸ ਹੋਵੇਗਾ?’ ਇਹ ਸਿਰਫ਼ ਇਕ Trust & Safety ਪੰਨਾ ਨਹੀਂ ਹੈ; ਇਹ ਓਹ ਹੀ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਸਪਸ਼ਟ ਸੰਕੇਤ, ਸਹਿਯੋਗੀ ਕੰਟਰੋਲ ਅਤੇ ਖਤਰੇ ਵਾਲੇ ਕਦਮਾਂ 'ਤੇ ਰੁਕਾਵਟਾਂ ਰੱਖਦੀਆਂ ਹਨ।
ਇਹ ਦਿਖਾਈ ਦੇਂਦਾ ਹੈ:
ਯਾਤਰਾ ਵਿੱਚ ਟਰੱਸਟ ਪਲ ਨਕਸ਼ਾ ਬਣਾਓ ਅਤੇ ਹਰ ਪੜਾਅ ਲਈ ਇਹ ਸੋਚੋ: ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ, ਇੱਕ ਸੁਰੱਖਿਅਤ ਉਪਭੋਗੀ ਕੀ ਉਮੀਦ ਕਰੇਗਾ, ਅਤੇ ਕੀ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ ਬਨਾਮ ਸਿਰਫ਼ ਨਿਰੋਧ ਕਰਨਾ?
ਮੁੱਖ ਪੜਾਅ:
ਬੁਰਾਈ ਸੰਕੇਤਾਂ ਅਤੇ ਭਾਗੀਦਾਰੀ ਦੇ ਸੰਕੇਤ ਦੋਹਾਂ ਨੂੰ ਟਰੈਕ ਕਰੋ, ਉਦਾਹਰਨ ਲਈ:
ਇਨ੍ਹਾਂ ਨੂੰ ਰਿਟੇਨਸ਼ਨ (D7/D30) ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਐਸਾ ਵਿਕਾਸ ਨਾ ਕਰ ਰਹੇ ਹੋ ਜੋ ਦਰਅਸਲ churn ਵਧਾਂਦਾ ਹੋਵੇ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਗੁਣਵੱਤਾ ਜ਼ਿਆਦਾ ਅਹੰਕਾਰਪੂਰਣ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਜਦੋਂ ਉਪਭੋਗੀਆਂ ਘੱਟ ਹੁੰਦੇ ਹਨ ਤਾਂ ਹਰੇਕ ਇੰਟਰੈਕਸ਼ਨ ਕੁੱਲ ਅਨੁਭਵ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਸਪੈਮੀ ਪ੍ਰੋਫਾਈਲ ਜਾਂ ਆਕਰਮਣਕ ਸੁਨੇਹੇ ਇੱਕ ਦੂਜੇ ਉੱਤੇ ਅਧਿਕ ਅਸਰ ਪਾ ਸਕਦੇ ਹਨ ਅਤੇ ਨਵੇਂ ਉਪਭੋਗੀਆਂ ਨੂੰ ਦੂਰ ਭੱਜਾ ਦੇਂਦੇ ਹਨ—ਇਸ ਨਾਲ ਮਾਰਕੀਟਪਲੇਸ ਆਪਣੇ ਆਪ ਮਾੜਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਟਰੱਸਟ ਅਤੇ ਸੁਰੱਖਿਆ ਕੁਨੂੰਨ ਹੋਸਟ/ਹਜਮ ਦਾ ਕੰਮ ਕਰਦੇ ਹਨ: ਵੈਰੀਫਿਕੇਸ਼ਨ, ਸਪਸ਼ਟ ਰਿਪੋਰਟਿੰਗ, ਦੁਹਰਾਉਣ ਵਾਲੇ ਦੋਸ਼ੀਆਂ ਲਈ ਰੁਕਾਵਟਾਂ, ਅਤੇ ਨੀਮਾਂ ਘੱਟ ਨਕਾਰਾਤਮਕ ਇੰਟਰੈਕਸ਼ਨਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ।
ਇਹ ਸੁਰੱਖਿਆ ਤੱਤ 'Safety' ਮੈਨੂ ਵਿੱਚ ਲੁਕਾਏ ਹੋਏ ਨਾ ਛੱਡੋ; ਜਦੋਂ ਸੁਰੱਖਿਆ ਬ੍ਰੈਂਡ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਦਿੱਖਣ ਯੋਗ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਗੱਲ ਕਰਨ ਯੋਗ ਹੋ ਜਾਂਦੇ ਹਨ—ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਵਾਂਗ ਜੋ ਉਪਭੋਗੀ ਆਪਣੇ ਦੋਸਤ ਨੂੰ ਦੱਸ ਸਕਦੇ ਹਨ:
ਇਹ ਤੱਤ ਮਾਰਕੀਟਿੰਗ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਉਨਾਂ ਪਲਾਂ 'ਤੇ ਅਣਵਿਚਾਰਤਾ ਘਟਾਉਂਦੇ ਹਨ ਜਦੋਂ ਉਪਭੋਗੀ ਨਿਰਣਯ ਲੈਂਦੇ ਹਨ।
ਫੀਚਰਜ਼ ਜਲਦੀ ਨਕਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਪੋਜ਼ਿਸ਼ਨਿੰਗ—ਜੋ ਉਪਭੋਗੀਆਂ ਇਹ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਸ ਲਈ ਖੜੇ ਹੋ—ਉਸ ਨੂੰ ਚੁੱਕਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਮੀਦਾਂ, ਰਿਵਾਜ਼ਾਂ, ਅਤੇ ਕਿਵੇਂ ਕਮਿਊਨਿਟੀ ਵਰਤਦੀ ਹੈ ਵਿੱਚ ਵੱਸਦਾ ਹੈ।
ਰੱਖਿਆ ਲਈ:
ਜਦੋਂ ਇਹ ਟੁਕੜੇ ਮਿਲਦੇ ਹਨ, ਤਾਂ ਟਰੱਸਟ ਇੱਕ ਫੀਚਰ ਨਹੀਂ ਰਹਿੰਦੀ—ਇਹ ਵਜ੍ਹਾ ਬਣ ਜਾਂਦੀ ਹੈ ਕਿ ਲੋਕ ਕਿਉਂ ਰਹਿੰਦੇ ਹਨ।
ਇੱਕ ਤੀਬਰ ਲੜੀਬੱਧ ਪਲੇਅਬੁੱਕ:
ਨੋਟ: ਜਲਦ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਲਈ Koder.ai ਵਰਗੇ ਟੂਲਸ ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਰਾਹੀਂ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ—ਆਨਬੋਰਡਿੰਗ ਕਾਪੀ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਗੇਟ, ਰਿਪੋਰਟਿੰਗ UX ਅਤੇ ਐਡਮਿਨ ਵਰਕਫਲੋਜ਼ ਜਿਹੜੇ ਜ਼ਰੂਰੀ ਹਨ, ਉਹ ਪਹਿਲਾਂ ਟੈਸਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਗਲਤੀਆਂ ਭਰੋਸਾ ਹੌਲੀ-ਹੌਲੀ ਖ਼ਤਮ ਕਰ ਦਿੰਦੀਆਂ ਹਨ:
ਜਦੋਂ ਸੁਰੱਖਿਆ ਨੂੰ ਫੀਚਰ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ ਪਰ ਇਸਦੇ ਨਤੀਜੇ ਲਗਾਤਾਰ ਨਹੀਂ ਹੋਂਦੇ, ਤਾਂ ਵਹ ਬਿਸ਼ਵਾਸ ਘਟ ਜਾਂਦਾ ਹੈ।
ਪਹਲੇ ਉਹ ਪਲ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜਿੱਥੇ ਨਿੱਜੀ ਜੋਖਿਮ ਵਧਦਾ ਹੈ (ਸਿੱਧਾ ਪਛਾਣ, ਬਹਿਭਚਨ, ਆਫ-ਪਲੈਟਫਾਰਮ ਸੰਪਰਕ)।