ਸਮਾਰਟ ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਰਿਮਾਈਂਡਰ ਲਈ ਮੋਬਾਈਲ ਐਪ ਬਣਾਓ: ਗਾਈਡ

ਸਮਾਰਟ ਨੋਟੀਫਿਕੇਸ਼ਨ ਐਪ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਇੱਕ ਸਮਾਰਟ ਨੋਟੀਫਿਕੇਸ਼ਨ ਐਪ ਦਾ ਮਤਲਬ "ਹੋਰਨ ਨੋਟੀਫਿਕੇਸ਼ਨ" ਨਹੀਂ ਹੈ। ਇਸਦਾ ਮਕਸਦ ਘੱਟ ਪਰ ਵਧੀਆਂ-ਸਮੇਂ ਵਾਲੀਆਂ ਸੁਝਾਵਾਂ ਦੇ ਕੇ ਲੋਕਾਂ ਨੂੰ ਉਹ ਕੰਮ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਾ ਹੈ ਜਿਸ ਦੀ ਉਹ ਪਹਿਲਾਂ ਹੀ ਪਰਵਾਹ ਕਰਦੇ ਹਨ—ਉਹਨਾਂ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ।

"ਸਮਾਰਟ" ਦਾ ਅਰਥ ਪੂਰਾ ਕਰੋ

ਸਕ੍ਰੀਨ ਡਿਜ਼ਾਈਨ ਜਾਂ ਟੂਲ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ ਉਤਪਾਦ ਲਈ "ਸਮਾਰਟ" ਦੀ ਸਧਾਰਨ ਪਰਿਭਾਸ਼ਾ ਲਿਖੋ। ਇੱਕ ਪ੍ਰਯੋਗਤਮਿਕ ਵਰਜਨ ਇਹ ਹੈ:

• ਸਹੀ ਸਮਾਂ: ਜਦੋਂ ਯੂਜ਼ਰ ਕਾਰਵਾਈ ਕਰ ਸਕਦਾ ਹੋਵੇ (ਸੋਣ, ਮੀਟਿੰਗਾਂ ਜਾਂ ਸਫ਼ਰ ਦੇ ਦੌਰਾਨ ਨਹੀਂ—ਜਦ ਤੱਕ ਉਹਨਾਂ ਨੇ ਮੰਗਿਆ ਨਾ ਹੋਵੇ).
• ਸਹੀ ਸੁਨੇਹਾ: ਛੋਟਾ, ਵਿਸ਼ੇਸ਼ ਅਤੇ ਕਾਰਵਾਈ-ਕੇਂਦਰਿਤ ("ਬਿਜਲੀ ਦਾ ਬਿੱਲ ਭਰੋ", "Reminder" ਨਾਲੋਂ ਬਿਹਤਰ).
• ਸਹੀ ਚੈਨਲ: ਲੋਕਲ ਅਲਰਟ, ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ, SMS, ਈਮੇਲ ਜਾਂ ਇਨ-ਐਪ ਬੈਨਰ—ਤਾਤਕਾਲਤਾ ਅਤੇ ਯੂਜ਼ਰ ਪਸੰਦ ਮੁਤਾਬਕ.

ਜੇ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਬਤਾ ਸਕਦੇ ਕਿ ਯਾਦ ਦਿਵਾਉਣ ਵਾਲੀ ਸੂਚਨਾ ਹੁਣ ਕਿਉਂ ਭੇਜੀ ਜਾ ਰਹੀ ਹੈ, ਤਾਂ ਇਹ ਹਾਲੇ ਸਮਾਰਟ ਨਹੀਂ ਹੈ।

ਉਹ ਰਿਮਾਈਂਡਰ ਕਿਸਮਾਂ ਜੋ ਤੁਸੀਂ ਸਹਾਇਤਾ ਕਰਨੀ ਚਾਹੁੰਦੇ ਹੋ (ਜਾਂ ਸੋਚ-ਸਮਝ ਕੇ ਛੱਡ ਦੇਵੋ)

ਜਿਆਦਾਤਰ ਰਿਮਾਈਂਡਰ ਐਪ ਪਹਿਲਾਂ ਇੱਕ-ਦੋ ਕਿਸਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ ਅਤੇ ਜਿਵੇਂ ਸਿਖਦੇ ਹਨ ਵਧਦੇ ਹਨ।

• ਟਾਈਮ-ਅਧਾਰਤ ਰਿਮਾਈਂਡਰ: “ਕੱਲ੍ਹ 9 ਵਜੇ।” ਇਹ ਬੁਨਿਆਦ ਹਨ।
• ਲੋਕੇਸ਼ਨ-ਅਧਾਰਤ ਰਿਮਾਈਂਡਰ: “ਜਦੋਂ ਮੈਂ ਗ੍ਰੋਸਰੀ ਸਟੋਰ ਪਹੁੰਚਾਂ।” ਲਾਭਦਾਇਕ ਪਰ ਪਰਮੀਸ਼ਨ ਸੰਵੇਦਨਸ਼ੀਲ।
• ਹੈਬਿਟ ਰਿਮਾਈਂਡਰ: ਆਉਟਲਾਈ ਰਹਿਣ ਵਾਲੇ ਨੁਡਜ਼ (“ਹਰ ਕਾਰਜਦਿਵਸ 8 ਵਜੇ ਰਾਤ”)। ਫੈਟਿਗ ਤੋਂ ਬਚਣ ਲਈ ਅਕਸਰ ਫ੍ਰੀਕੈਂਸੀ ਨਿਯੰਤਰਣ ਚਾਹੀਦੇ।
• ਟਾਸਕ-ਅਧਾਰਤ रਿਮਾਈਂਡਰ: ਇੱਕ ਟੂ-ਡੂ ਆਈਟਮ ਨਾਲ ਜੁੜੇ ਹੋਏ, ਜਿਸਦਾ ਇੱਕ ਸਪਸ਼ਟ “ਕੰਮ ਮੁਕੰਮਲ” ਐਕਸ਼ਨ ਹੁੰਦਾ ਹੈ।
• ਇਵੈਂਟ ਰਿਮਾਈਂਡਰ: ਕੈਲੰਡਰ ਘਟਨਾਵਾਂ ਜਾਂ ਇੱਕ-ਵਾਰੀ ਸਮਿਆਂ (ਟਿਕਟ, ਅਪਾਇੰਟਮੈਂਟ) ਨਾਲ ਸਿੰਕ ਹੋਕੇ।

ਮੁੱਖ ਗੱਲ ਹੈ ਇਕਸਾਰਤਾ: ਹਰ ਰਿਮਾਈਂਡਰ ਕਿਸਮ ਦੀ ਭਵਿੱਕ-ਕਿਰਿਆ (ਸਨੂਜ਼, ਰੀ-ਸ਼ੈਡਿਊਲ, ਕੰਪਲੀਟ) ਪੇਸ਼ਗੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਐਪ 'ਤੇ ਭਰੋਸਾ ਕਰਨ।

ਸਫਲਤਾ ਮੈਟਰਿਕਸ ਜਲਦੀ ਚੁਣੋ

"ਇੰਨਗੇਜ਼ਮੈਂਟ" ਅਸਪਸ਼ਟ ਹੈ। ਐਸੇ ਮੈਟਰਿਕ ਚੁਣੋ ਜੋ ਦਰਸਾਉਣ ਕਿ ਰਿਮਾਈਂਡਰ ਵਾਸਤਵ ਵਿੱਚ ਮਦਦਗਾਰ ਨੇ:

• Opt-in ਦਰ: ਕਿੰਨੇ ਯੂਜ਼ਰ ਨੋਟੀਫਿਕੇਸ਼ਨ (ਅਤੇ ਜੇ ਲਾਗੂ ਹੋਵੇ ਤਾਂ ਲੋਕੇਸ਼ਨ) ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ।
• Open rate / action rate: ਨੋਟੀਫਿਕੇਸ਼ਨ 'ਤੇ ਟੈਪ ਜਾਂ ਸਿੱਧੀਆਂ ਕਾਰਵਾਈਆਂ (Done, Snooze)।
• Completion rate: ਉਹ ਰਿਮਾਈਂਡਰ ਜੋ ਇੱਕ ਨਿਰਧਾਰਤ ਵਿੰਡੋ (ਜਿਵੇਂ 24 ਘੰਟਿਆਂ) ਵਿੱਚ ਪੂਰੇ ਹੋ ਜਾਂਦੇ ਹਨ।
• Retention: ਕੀ ਯੂਜ਼ਰ 7/30 ਦਿਨਾਂ ਬਾਅਦ ਵੀ ਰਿਮਾਈਂਡਰ ਬਣਾਉਂਦੇ ਅਤੇ ਪੂਰਾ ਕਰਦੇ ਹਨ?

ਇਹ ਮੈਟਰਿਕ ਦੇਸੀਜ਼ਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨਗੀਆਂ—ਜਿਵੇਂ ਡਿਫੌਲਟ ਸ਼ਡਿਊਲ, ਸ਼ਾਂਤ ਘੰਟੇ ਅਤੇ ਕਾਪੀ।

ਲੱਖੀ ਪਲੇਟਫਾਰਮ ਤੇ ਸਕੋਪ ਨਿਰਧਾਰਤ ਕਰੋ

ਜੋ ਤੁਸੀਂ ਬਣਾ ਰਹੇ ਹੋ ਉਸ ਦੇ ਨੁਸਖੇ ਮੁਤਾਬਕ iOS, Android, ਜਾਂ cross-platform ਚੁਣੋ—ਸਿਰਫ ਡਿਵੈਲਪਰਸ ਦੀ ਆਸਾਨੀ ਲਈ ਨਹੀਂ। ਪਲੇਟਫਾਰਮ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿਹਾਰ ਵਿੱਚ ਫਰਕ ਹੁੰਦਾ ਹੈ (ਪਰਮੀਸ਼ਨ ਪ੍ਰੰਪਟ, ਡਿਲਿਵਰੀ ਨਿਯਮ, ਗਰੂਪਿੰਗ), ਇਸ ਕਰਕੇ ਇਹਨਾਂ ਫਰਕਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ।

ਆਪਣੇ ਐਪ ਦਾ ਮੁੱਖ ਵਾਅਦਾ ਸਪਸ਼ਟ ਕਰੋ

ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਜੋ ਤੁਸੀਂ app store ਲਿਸਟਿੰਗ ਵਿੱਚ ਰਖ ਸਕੋ। ਉਦਾਹਰਨਾਂ:

• “ਇਹ ਰਿਮਾਈਂਡਰ ਸੈਟ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਸ਼ਡਿਊਲ ਨਾਲ ਢਲ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਉਹਨਾਂ ਵੇਲਿਆਂ 'ਤੇ ਨੋਟੀਫਾਈ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹੋ।”
• “ਇੱਕ ਰਿਮਾਈਂਡਰ ਐਪ ਜੋ ਨਰਮ ਆਦਤਾਂ ਅਤੇ ਇੱਕ-ਟੈਪ ਮੁਕੰਮਲਤਾ ਨਾਲ ਤੁਹਾਡੇ ਕੰਮਾਂ 'ਤੇ ਰੱਖਦਾ ਹੈ।”

ਉਹ ਵਾਕ ਫੀਚਰ ਰਿਕੁਐਸਟਾਂ ਲਈ ਫਿਲਟਰ ਬਣ ਜਾਂਦਾ ਹੈ: ਜੇ ਇਹ ਵਾਅਦੇ ਨੂੰ ਮਜ਼ਬੂਤ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਸ਼ਾਇਦ ਇਹ ਫੇਜ਼ ਦੋ ਦੀ ਚੀਜ਼ ਹੈ।

ਯੂਜ਼ਰ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ, ਯੂਜ਼ ਕੇਸ, ਅਤੇ ਸਪਸ਼ਟ ਐਪ ਲਕਸ਼

ਇੱਕ ਰਿਮਾਈਂਡਰ ਐਪ ਤਦ ਜ਼ਿਆਦਾ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਅਸਲੀ ਰੁਟੀਨਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ—ਨਾ ਕਿ ਵਧੇਰੇ ਸੈਟਿੰਗਜ਼ ਦੇ ਪੇਸ਼ਕਸ਼ ਨਾਲ। ਨੋਟੀਫਿਕੇਸ਼ਨ ਸ਼ਡਿਊਲਿੰਗ ਲਾਜਿਕ ਜਾਂ ਪੁਸ਼ ਡਿਜ਼ਾਈਨ ਚੁਣਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਦੀ ਮਦਦ ਕਰ ਰਹੇ ਹੋ, ਉਹ ਕੀ ਹਾਸਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਲਈ "ਸਫਲਤਾ" ਕੀ ਹੈ।

ਡਿਜ਼ਾਈਨ ਲਈ ਮੁੱਖ ਯੂਜ਼ਰ ਗਰੂਪ

ਕੁਝ ਪ੍ਰਾਇਮਰੀ ਦਰਸ਼ਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਹਰ ਇੱਕ ਦੇ ਵੱਖਰੇ ਸੀਮਾਵਾਂ ਹੋਂਦੀਆਂ ਹਨ:

• ਬਜ਼ੀ ਪ੍ਰੋਫੈਸ਼ਨਲਜ਼ ਜੋ ਮੀਟਿੰਗਾਂ, ਡੈੱਡਲਾਈਨ ਅਤੇ ਯਾਤਰਾ ਦੇ ਸਮੇਂ ਬਰਾਬਰ ਸੰਭਾਲਦੇ ਹਨ।
• ਛਾਤਰ/ਸਟੂਡੈਂਟਸ ਜੋ ਕਲਾਸ ਸ਼ਡਿਊਲ, ਪੜ੍ਹਾਈ ਬਲਾਕ ਅਤੇ ਅਸਾਈਨਮੈਂਟ ਦੀਆਂ ਮਿਆਦਾਂ ਸੰਭਾਲਦੇ ਹਨ।
• ਕੇਅਰਗਿਵਰਜ਼ ਜੋ ਦਵਾਈਆਂ, ਅਪਾਇੰਟਮੈਂਟ ਅਤੇ ਪਰਿਵਾਰਕ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਟਰੈਕ ਕਰਦੇ ਹਨ।

ਇਹ ਗਰੂਪ ਰੁਕਾਵਟਾਂ, ਬਦਲਦੇ ਯੋਜਨਾਵਾਂ ਦੀ ਆਵਿਰਤੀ, ਅਤੇ ਸਾਂਝੇ ਰਿਮਾਈਂਡਰ ਦੀ ਲੋੜ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ।

ਅਸਲ-ਜ਼ਿੰਦਗੀ ਪਰਿਸਥਿਤੀਆਂ ਨਕਸ਼ਾ ਕਰੋ (ਜਿੱਥੇ ਰਿਮਾਈਂਡਰ ਫੇਲ ਹੁੰਦੇ ਹਨ)

ਉਹ ਪਰਿਸਥਿਤੀਆਂ ਜਮ੍ਹਾਂ ਕਰੋ ਜੋ ਕਾਰਵਾਈਆਂ ਛੱਡਣ ਦਾ ਕਾਰਨ ਬਣਦੀਆਂ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸੰਕੇਤਕ ਯੂਜ਼ ਕੇਸ ਬਣਾਓ:

• ਯਾਦ ਰਹਿਣ ਨਾ ਆਉਣਾ ਕਿਉਂਕਿ ਰਿਮਾਈਂਡਰ ਕੰਮ ਦੇ ਦੌਰਾਨ ਜਾਂ ਸਫ਼ਰ ਵਿੱਚ fired ਹੋ ਗਿਆ।
• ਬਿੱਲ ਦੀ ਮਿਆਦ ਭੁੱਲ ਜਾਣਾ ਕਿਉਂਕਿ ਸੁਨੇਹਾ ਬਹੁਤ ਪਹਿਲਾਂ ਆ ਕੇ ਦਬ ਗਿਆ।
• ਮੀਟਿੰਗਾਂ ਗੁਆਂਢ ਚੁੱਕ ਜਾਣਾ ਕਿਉਂਕਿ “ਹੁਣ ਨਿਕਲੋ” ਲਈ ਟਰੈਫਿਕ ਅਤੇ ਥਾਂ ਤੇ ਨਿਰਭਰ ਹੈ।
• ਦੈਨੀਕ ਰੁਟੀਨ (ਹਾਈਡਰੇਸ਼ਨ, ਘੁਮਾਵਟ, ਜਰਨਲਿੰਗ) ਜੋ ਨਰਮ ਪਰਾਲੋਗਾਂ ਬਿਨਾਂ ਫੈਡ ਹੋ ਜਾਂਦੇ ਹਨ।

ਇਹ ਲਿਖਦੇ ਸਮੇਂ, ਸੰਦਰਭ ਸ਼ਾਮਲ ਕਰੋ: ਸਮਾਂ ਵਿੰਡੋ, ਸਥਾਨ, ਆਮ ਡਿਵਾਈਸ ਹਾਲਤ (ਸਾਇਲੈਂਟ ਮੋਡ, ਘੱਟ ਬੈਟਰੀ), ਅਤੇ ਯੂਜ਼ਰ ਨੇ ਬਦਲ ਕੇ ਕੀ ਕੀਤਾ।

ਉਹ ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼ ਲਿਖੋ ਜੋ "ਸਮਾਰਟ ਨੋਟੀਫਿਕੇਸ਼ਨ" ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ

ਵਧੀਆ ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼ ਤੁਹਾਡੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਡਿਜ਼ਾਈਨ ਫੈਸਲੇ ਸਪਸ਼ਟ ਕਰ ਦਿੰਦੀਆਂ ਹਨ:

• “ਮੈਨੂੰ ਉਸ ਵੇਲੇ ਯਾਦ ਦਿਵਾਓ ਜਦੋਂ ਮੇਰੀ ਮੀਟਿੰਗ ਤੋਂ 30 ਮਿੰਟ ਪਹਿਲਾਂ ਅਤੇ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਹੋਰ ਮੀਟਿੰਗ ਵਿੱਚ ਨਹੀਂ ਹਾਂ।”
• “ਮੇਰੀ ਫੋਕਸ ਘੰਟਿਆਂ ਦੌਰਾਨ ਮੈਨੂੰ ਯਾਦ ਨਾ ਦਿਵਾਓ, ਜੇ ਤੱਕ ਉਹ ਊਰਜਨਸ਼ੀਲ ਨਹੀਂ ਚਿੰਨ੍ਹਿਤ।”
• “ਜੇ ਮੈਂ ਇੱਕ ਰਿਮਾਈਂਡਰ ਨੂੰ ਅਣਦੇਖਾ ਕਰ ਦਿੰਦਾ ਹਾਂ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਇਕ ਨਰਮ ਨਜਰ ਕੋਈ ਦਿਓ—ਪਰ ਦੋ ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਬਾਅਦ ਰੁਕ ਜਾਓ।”

ਪ੍ਰਾਇਮਰੀ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਚੁਣੋ

ਐਪ ਦੇ ਲਕਸ਼ ਸਾਫ ਅਤੇ ਮਾਪਣ ਯੋਗ ਰੱਖੋ। ਜ਼ਿਆਦਾਤਰ ਰਿਮਾਈਂਡਰ ਐਪ ਚਾਰ ਮੁੱਖ ਕੰਮ ਨਿਭਾਉਂਦੇ ਹਨ:

1. ਯਾਦ ਰੱਖਣਾ (ਸਹੀ ਆਈਟਮ ਨੂੰ ਸਹੀ ਸਮੇਂ ਉੱਪਰ ਲਿਆਉਣਾ)।
2. ਯੋਜਨਾ ਬਨਾਉਣਾ (इरਾਦੇ ਨੂੰ ਘੱਟ ਵੀਘਟ ਵਿੱਚ ਨਿਰਧਾਰਿਤ ਕਾਰਵਾਈ ਵਿੱਚ ਬਦਲਨਾ)।
3. ਅਮਲ ਕਰਵਾਉਣਾ (ਸਨੂਜ਼, ਰੀ-ਸ਼ੈਡਿਊਲ, ਅਤੇ ਮੁਕੰਮਲ ਬਿਨਾਂ ਰੁਕਾਵਟ)।
4. ਤਣਾਅ ਘਟਾਉਣਾ (ਘੱਟ, ਬਿਹਤਰ ਨੋਟੀਫਿਕੇਸ਼ਨ—ਵੱਧ ਭਰੋਸਾ)।

ਡਿਫੌਲਟ ਵਿਹਾਰ ਨਿਰਧਾਰਤ ਕਰੋ (ਸੈਟਅਪ ਘੱਟ ਕਰਨ ਲਈ)

ਡਿਫੌਲਟ ਨਤੀਜੇ ਤੇਜ਼ੇ ਨਾਲ ਰਿਜ਼ਲਟ ਬਣਾਉਂਦੇ ਹਨ। ਇੱਕ ਸਾਫ ਬੇਸਲਾਈਨ ਨਿਰਧਾਰਤ ਕਰੋ: ਸਮਝਦਾਰ ਸ਼ਾਂਤ ਘੰਟੇ, ਇੱਕ ਮਿਆਰੀ ਸਨੂਜ਼ ਅਵਧੀ, ਅਤੇ ਨਰਮ ਏਸਕਲੇਸ਼ਨ ਪੈਟਰਨ। ਲਕਸ਼ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰ ਸਕਿੰਟਾਂ ਵਿੱਚ ਰਿਮਾਈਂਡਰ ਬਣਾਵੇ—ਅਤੇ ਫਿਰ ਵੀ ਐਪ ਨੂੰ ਬਿਨਾਂ ਬਹੁਤ ਟਿੂਨਿੰਗ ਦੇ "ਸਮਾਰਟ" ਮਹਿਸੂਸ ਕਰੇ।

ਰਿਮਾਈਂਡਰ ਲਈ ਮੁੱਖ ਫੀਚਰ ਅਤੇ ਡੇਟਾ ਮਾਡਲ

ਰਿਮਾਈਂਡਰ ਐਪ ਉਸ ਬਰੋਟ 'ਤੇ ਟਿਕਿਆ ਹੋਇਆ ਹੁੰਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਇਰਾਦਾ ਕੈਪਚਰ ਕਰ ਸਕਦਾ ਹੈ ("ਮੈਨੂੰ ਯਾਦ ਦਿਵਾਉ") ਅਤੇ ਉਨ੍ਹਾਂ ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਇਹ ਸਹੀ ਵੇਲੇ ਚਲੇਗਾ। "ਸਮਾਰਟ" ਲਾਜਿਕ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ, ਮੁੱਖ ਰਿਮਾਈਂਡਰ ਇਨਪੁੱਟ, ਸ਼ਡਿਊਲ ਨਿਯਮ, ਅਤੇ ਇੱਕ ਸਾਫ਼ ਡੇਟਾ ਮਾਡਲ ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਫਸਾ ਨਾ ਕਰੇ।

ਰਿਮਾਈਂਡਰ ਸਰੋਤ ਚੁਣੋ (ਕਿਵੇਂ ਰਿਮਾਈਂਡਰ ਬਣਦੇ ਹਨ)

ਅਸਲੀ ਰਵੈਯੇ ਨਾਲ میل ਖਾਣ ਵਾਲੇ ਕੁਝ ਬਣਾਉਣ ਦੇ ਰਾਹਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:

• ਮੈਨੂਅਲ ਇਨਟਰੀ: ਤੇਜ਼ "ਸਿਰਲੇਖ + ਸਮਾਂ" ਫਲੋ ਨਾਲ ਵਿਕਲਪਿਕ ਵੇਰਵੇ।
• ਕੈਲੰਡਰ ਇੰਪੋਰਟ: ਇਵੈਂਟਾਂ ਨੂੰ ਰਿਮਾਈਂਡਰ ਵਿੱਚ ਬਦਲੋ (ਸਪਸ਼ਟ ਮੈਪਿੰਗ ਅਤੇ ਆਸਾਨ opt-out).
• ਈਮੇਲ ਪਾਰਸਿੰਗ: ਵיקלਪਿਕ ਅਤੇ ਪਰਮੀਸ਼ਨ-ਭਾਰੀ; ਜੇ ਜਰੂਰੀ ਨਾ ਹੋਵੇ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਵਿਚਾਰ ਕਰੋ।
• ਟੈਂਪਲੇਟਸ: "ਕਿਰਾਇਆ ਭਰੋ", "ਦਵਾਈ ਲਓ", "ਸਾਪਤਾਹਿਕ ਰਿਪੋਰਟ"—ਟਾਇਪ ਘਟਾਉਣ ਅਤੇ ਇੱਕਸਾਰਤਾ ਵਧਾਉਣ ਲਈ।

ਅੱਚਾ ਨਿਯਮ: ਹਰ ਸਰੋਤ ਨੂੰ ਉ same ਹੀ ਅੰਦਰੂਨੀ ਰਿਮਾਈਂਡਰ ਓਬਜੈਕਟ ਉਤਪੰਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਵੱਖਰਾ ਪ੍ਰਕਾਰ ਨਹੀਂ।

ਰੀਕਰਿੰਗ ਲਾਜਿਕ (ਅਤੇ ਯੂਜ਼ਰ ਜੋ ਨੋਟਿਸ ਕਰਨਗੇ ਉਹ ਨਿਯਮ)

ਰੀਕਰਿੰਗ ਰਿਮਾਈਂਡਰ ਅਕਸਰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸਪੋਰਟ ਟਿਕਟ ਬਣਾਉਂਦੇ ਹਨ। ਨਿਯਮ ਸਪਸ਼ਟ ਰੱਖੋ:

• ਪੈਟਰਨ: ਦੈਨੀਕ, ਸਾਪਤਾਹਿਕ, ਮਹੀਨਾਵਾਰ, ਕਸਟਮ ਅੰਤਰਾਲ।
• ਆਪਤੀਆਂ: ਇੱਕ ਤਾਰੀਖ skip ਕਰੋ, ਛੁੱਟੀ ਲਈ ਰੋਕੋ, ਜਾਂ "ਸਿਰਫ਼ ਕਾਰਜ ਦਿਨ"।
• ਸਨੂਜ਼ ਨਿਯਮ: ਕਿੰਨੀ ਦੇਰ, ਕਿੰਨੀ ਵਾਰ, ਅਤੇ ਕੀ ਸਨੂਜ਼ਿੰਗ ਸੀਰੀਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਜਾਂ ਕੇਵਲ ਇਕ ਘਟਨਾ ਨੂੰ।
• ਸਮਾਂ ਵਿੰਡੋ: "9am–6pm ਦੇ ਵਿਚਕਾਰ ਨੋਟੀਫਾਈ ਕਰੋ" ਜਾਂ "ਮੀਟਿੰਗਾਂ ਤੋਂ ਬਚੋ" ਜੇ ਤੁਸੀਂ ਸ਼ਾਂਤ ਘੰਟੇ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ।

ਟਾਈਮ ਜ਼ੋਨ ਅਤੇ ਯਾਤਰਾ ਵਿਹਾਰ

ਇੱਕ ਸਾਫ ਮਾਡਲ ਚੁਣੋ ਅਤੇ ਉਸ ਤੇ ਟਿਕੇ ਰਹੋ:

• ਲੋਕਲ ਸਮਾਂ ਰੱਖੋ (ਜਿਵੇਂ, "ਹਰ ਰੋਜ਼ 8am" ਯਾਤਰਾ ਕਰਨ ਤੇ ਢਲ ਜਾਂਦਾ ਹੈ)।
• ਫਿਕਸਡ ਟਾਈਮ (ਉਦਾਹਰਨ: "8am New York time" ਇੱਕ ਖਾਸ ਜ਼ੋਨ 'ਚ ਟਿਕਿਆ ਰਹਿੰਦਾ ਹੈ)।

ਗੈਰ-ਟੈਕਨੀਕਲ ਯੂਜ਼ਰਾਂ ਲਈ, ਇਸਨੂੰ "ਯਾਤਰਾ ਕਰਨ 'ਤੇ ਢਲ ਜਾਵੇ" ਬਨਾਮ "ਘਰੇਲੂ ਟਾਈਮਜ਼ੋਨ ਰੱਖੋ" ਦੇ ਰੂਪ ਵਿੱਚ ਲੇਬਲ ਕਰੋ।

ਆਫਲਾਈਨ ਵਿਹਾਰ (ਕਨੈਕਟਿਵਿਟੀ ਬਿਨਾਂ ਭਰੋਸਾ)

ਲੋਕ ਲੋਕਾਂ ਨੂੰ ਰਾਹ ਵਿੱਚ ਰਿਮਾਈਂਡਰ ਬਣਾਉਣੇ ਪੈਂਦੇ ਹਨ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਯੂਜ਼ਰ ਆਫਲਾਈਨ ਰਿਚੀਏਟ/ਐਡੀਟ ਕਰ ਸਕਦੇ ਹਨ, ਬਦਲਾਵ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਟੋਰ ਹੋਣ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸਿੰਕ ਹੋ ਜਾਣ। ਜੇ ਟਕਰਾਅ ਹੋਣ, ਤਾਂ "latest edit wins" ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਅਤੇ ਸਧਾਰਨ ਐਕਟਿਵਿਟੀ ਲੌਗ ਰੱਖੋ।

ਇਕ ਸਧਾਰਨ ਡੇਟਾ ਮਾਡਲ ਜੋ ਤੁਸੀਂ ਵਧਾ ਸਕਦੇ ਹੋ

ਇਸਨੂੰ ਪਤਲਾ ਰੱਖੋ ਪਰ ਸੰਰਚਿਤ:

• Reminder: id, title, notes, status (active/completed), createdAt.
• Schedule: nextTriggerAt, recurrenceRule, timeZoneMode, quietHours.
• Context: source (manual/calendar/template), optional tags, optional location.
• User preferences: default snooze duration, travel behavior, notification window.

ਇਹ ਬੁਨਿਆਦ ਪਰਸਨਲਾਈਜ਼ੇਸ਼ਨ ਬਾਅਦ ਵਿੱਚ ਆਸਾਨ ਬਣਾਂਦੀ ਹੈ—ਬਿਨਾਂ ਇਸਦੇ ਕਿ ਤੁਹਾਨੂੰ ਰਿਮਾਈਂਡਰ ਸਟੋਰ ਅਤੇ ਸ਼ਡਿਊਲ ਕਰਨ ਦਾ ਢਾਂਚਾ ਮੁੜ ਬਣਾਉਣਾ ਪਵੇ।

ਉੱਚ-ਸਤ੍ਹਰੀ ਆਰਕੀਟੈਕਚਰ: ਲੋਕਲ ਬਨਾਮ ਸਰਵਰ ਨੋਟੀਫਿਕੇਸ਼ਨ

ਇੱਕ ਰਿਮਾਈਂਡਰ ਐਪ ਸੁਨੇਹੇ ਕਈ ਚੈਨਲਾਂ ਰਾਹੀਂ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰੇ ਲਈ ਦਰਸ਼ਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਐਪ ਪਹਿਲਾਂ ਲੋਕਲ ਨੋਟੀਫਿਕੇਸ਼ਨ (ਡਿਵਾਈਸ 'ਤੇ ਸ਼ਡਿਊਲ ਕੀਤੇ) ਅਤੇ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ (ਸਰਵਰ ਤੋਂ ਭੇਜੇ) ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ। ਈਮੇਲ/SMS "ਨਹਿ-ਮਿਸ" ਰਿਮਾਈਂਡਰ ਲਈ ਵਿਕਲਪ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਵਾਧੂ ਲਾਗਤ, ਕਾਨੂੰਨੀ ਪਾਬੰਦੀਆਂ ਅਤੇ ਡਿਲਿਵਰੇਬਿਲਟੀ ਕੰਝਣੀਆਂ ਲਿਆਉਂਦੇ ਹਨ।

ਨੋਟੀਫਿਕੇਸ਼ਨ ਚੈਨਲ (ਕਿਹੜਾ ਰਿਮਾਈਂਡਰ ਫਾਇਰ ਕਰਦਾ ਹੈ)

ਲੋਕਲ ਨੋਟੀਫਿਕੇਸ਼ਨ ਆਫਲਾਈਨ ਵਰਤੋਂ ਅਤੇ ਸਧਾਰਣ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਰਿਮਾਈਂਡਰ ਲਈ ਚੰਗੇ ਹਨ। ਇਹ ਤੇਜ਼ ਹਨ ਪਰ OS ਨਿਯਮਾਂ (ਬੈਟਰੀ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ, iOS 'ਤੇ ਨਿਯਮ) ਨਾਲ ਸੀਮਤ ਹੋ ਸਕਦੇ ਹਨ।

ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕ੍ਰਾਸ-ਡਿਵਾਈਸ ਸਿੰਕ, "ਸਮਾਰਟ" ਟਾਈਮਿੰਗ, ਅਤੇ ਸਰਵਰ-ਚਲਿਤ ਅੱਪਡੇਟ (ਉਦਾਹਰਨ: ਜਦੋਂ ਕੰਮ ਹੋਰ ਥਾਂ 'ਤੇ ਮੁਕੰਮਲ ਹੋ ਜਾਏ ਤਾਂ ਰਿਮਾਈਂਡਰ ਰੱਦ ਕਰੋ) ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਇਹ APNs/FCM ਦੀ ਭਰੋਸੇਯੋਗਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਅਤੇ ਬੈਕਇੰਡ ਇੰਫ਼ਰਾਸਟਰੱਕਚਰ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ।

"ਸਮਾਰਟਨੈੱਸ" ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ

ਤੁਹਾਡੇ ਕੋਲ ਮੁੱਖ ਤੌਰ 'ਤੇ ਦੋ ਵਿਕਲਪ ਹਨ:

• ਡਿਵਾਈਸ-ਉਤੇ ਨਿਯਮ: ਐਪ ਸਥਾਨਕ ਡੇਟਾ ਦੇ ਅਧਾਰ 'ਤੇ ਨੋਟੀਫਾਈ ਕਰਦਾ ਹੈ (ਆਦਤਾਂ, ਹਾਲੀਆ ਵਿਹਾਰ, ਟਾਈਮਜ਼ੋਨ)। ਫਾਇਦੇ: ਗੋਪਨੀਯਤਾ, ਆਫਲਾਈਨ ਕੰਮ ਕਰਦਾ ਹੈ। ਨੁਕਸਾਨ: ਕੇਂਦਰੀ ਤੌਰ ਤੇ ਪ੍ਰਯੋਗ ਕਰਨਾ ਅਤੇ ਸਭ ਡਿਵਾਈਸਾਂ 'ਤੇ ਲੋਜਿਕ ਸਹੀ ਰੱਖਣਾ ਮੁਸ਼ਕਲ।
• ਸਰਵਰ-ਸਾਈਡ ਸ਼ਡਿਊਲਿੰਗ: ਬੈਕਇੰਡ ਸਭ ਤੋਂ ਵਧੀਆ ਸਮਾਂ ਗਿਣਦਾ ਹੈ ਅਤੇ ਪੁਸ਼ ਭੇਜਦਾ ਹੈ। ਫਾਇਦੇ: A/B ਟੈਸਟਿੰਗ, ਗਲੋਬਲ ਲੋਜਿਕ ਅੱਪਡੇਟ, ਬਹੁ-ਡਿਵਾਈਸ ਨਿਰੰਤਰਤਾ। ਨੁਕਸਾਨ: ਜ਼ਿਆਦਾ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਹੈਂਡਲਿੰਗ ਅਤੇ ਅਪਟਾਈਮ ਦੀ ਲੋੜ।

ਕਈ ਟੀਮਾਂ ਹਾਇਬਰਿਡ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ: ਡਿਵਾਈਸ-ਉਤੇ fallback (ਬੁਨਿਆਦੀ ਰਿਮਾਈਂਡਰ) + ਸਰਵਰ-ਸਾਈਡ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ (ਸਮਾਰਟ ਨੁਡਜ਼)।

ਜ਼ਰੂਰੀ ਬੈਕਐਂਡ ਸਰਵਿਸਿਜ਼

ਘੱਟੋ-ਘੱਟ ਯੋਜਨਾ ਬਣਾਓ: authentication, ਇੱਕ ਡੇਟਾਬੇਸ ਰਿਮਾਈਂਡਰ/ਪਸੰਦਾਂ ਲਈ, ਟਾਈਮਡ ਕੰਮ ਲਈ ਜੌਬ ਸ਼ਡਿਊਲਰ/ਕਿਊ, ਅਤੇ ਡਿਲਿਵਰੀ/ਓਪਨ/ਕੰਪਲੀਸ਼ਨ ਈਵੈਂਟਸ ਲਈ ਅਨਲਿਟਿਕਸ।

ਜੇ ਤੁਸੀਂ ਤੁਰੰਤ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ ਚੈਟ-ਡ੍ਰਿਵਨ ਬਿਲਡ ਫਲੋ ਤੁਹਾਡੇ ਲਈ ਕੋਰ ਸਟੈਕ (React web surface, Go + PostgreSQL ਬੈਕਇੰਡ, Flutter ਮੋਬਾਈਲ) ਤੇਜ਼ੀ ਨਾਲ ਖੜਾ ਕਰਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ—ਫਿਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲਾਜਿਕ 'ਤੇ ਸਿੱਖ ਕੇ ਇਟਰੇਟ ਕਰੋ।

ਸਕੇਲੈਬਿਲਟੀ ਯੋਜਨਾ

ਮਾਰਨਿੰਗ ਰੁਟੀਨ, ਲੰਚ ਟਾਈਮ, ਸ਼ਾਮ ਦੇ ਅੰਤਰਾਲ ਵਗੈਰਾ 'ਤੇ ਟ੍ਰੈਫਿਕ spike ਦੀ ਉਮੀਦ ਰੱਖੋ। ਆਪਣੇ ਸ਼ਡਿਊਲਰ ਅਤੇ ਪੁਸ਼ ਪਾਈਪਲਾਈਨ ਨੂੰ ਬਰਸਟੀ ਸੈਂਡ, ਰੀਟ੍ਰਾਈ ਅਤੇ ਰੇਟ-ਲਿਮਿਟ ਹਨਡਲ ਕਰਨ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ।

ਬਾਅਦ ਵਿੱਚ ਜੋੜਨਯੋਗ ਇਨਟੀਗ੍ਰੇਸ਼ਨ

ਕੈਲੰਡਰ ਸਿੰਕ, ਹੈਲਥ/ਐਕਟਿਵਿਟੀ ਸਿਗਨਲ, ਅਤੇ ਮੈਪਸ/ਲੋਕੇਸ਼ਨ ਟ੍ਰਿੱਗਰ ਲਈ ਐਕਸਟੈੰਸ਼ਨ ਪੋਇੰਟ ਰੱਖੋ—ਪਰ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ ਇਹਨਾਂ ਨੂੰ ਲਾਜ਼ਮੀ ਨਾ ਬਣਾਓ।

ਪਰਮਿਸ਼ਨ, ਆਨਬੋਰਡਿੰਗ, ਅਤੇ Opt-In ਰਣਨੀਤੀ

ਰਿਮਾਈਂਡਰ ਐਪ ਦੀ ਕਾਇਮਾਤ opt-in 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ ਪਰਮੀਸ਼ਨ ਮੰਗਦੇ ਹੋ, ਬਹੁਤ ਸਾਰੇ ਲੋਕ "Don’t Allow" ਦਬਾ ਦੇਣਗੇ ਅਤੇ ਫਿਰ ਮੁੜ ਨਹੀਂ ਆਉਣਗੇ। ਲਕਸ਼ ਸਧਾਰਨ ਹੈ: ਪਹਿਲਾਂ ਮੁੱਲ ਦਿਖਾਓ, ਫਿਰ ਛੋਟਾ ਤੇ ਲਾਜ਼ਮੀ ਪਰਮੀਸ਼ਨ ਮੰਗੋ ਜਦੋਂ ਉਸ ਦੀ ਸਪਸ਼ਟ ਲੋੜ ਹੋਵੇ।

ਆਨਬੋਰਡਿੰਗ: ਪ੍ਰੰਪਟ ਤੋਂ ਪਹਿਲਾਂ "ਕਿਉਂ" ਦੱਸੋ

ਛੋਟੀ ਆਨਬੋਰਡਿੰਗ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਨਤੀਜਿਆਂ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ, ਫੀਚਰ ਨਹੀਂ:

• “ਕਦੇ ਵੀ ਬਿੱਲ ਭੁੱਲੋ ਨਾ”
• “ਸਬ ਤੋਂ ਵਧੀਆ ਸਮੇਂ ਤੇ ਵਰਕਆਉਟ ਲਈ ਨੁਡਜ਼ ਪ੍ਰਾਪਤ ਕਰੋ”
• “ਸ਼ਾਂਤ ਘੰਟੇ ਤਾਂ ਜੋ ਰਿਮਾਈਂਡਰ ਨੀਂਦ ਵਿੱਚ ਰੁਕਾਵਟ ਨਾ ਪਹੁੰਚਾਏ”

ਇੱਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਪ੍ਰੀਵਿਊ ਸਕਰੀਨ ਦਿਓ ਜੋ ਦਿਖਾਵੇ ਕਿ ਰਿਮਾਈਂਡਰ ਕਿਵੇਂ ਲੱਗੇਗਾ (title, body, timing, ਅਤੇ tapped ਤੇ ਕੀ ਹੁੰਦਾ)। ਇਹ ਅਚੰਭੇ ਨੂੰ ਘਟਾਉਂਦਾ ਅਤੇ ਭਰੋਸਾ ਵਧਾਉਂਦਾ ਹੈ।

ਪਰਮੇਸ਼ਨਾਂ ਨੂੰ ਸੰਦਰਭ ਅਨੁਸਾਰ ਮੰਗੋ (ਸਬ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟ)

ਨੋਟੀਫਿਕੇਸ਼ਨ ਪਰਮਿਸ਼ਨ ਸਿਰਫ ਉਸ ਵੇਲੇ ਮੰਗੋ ਜਦੋਂ ਯੂਜ਼ਰ ਪਹਿਲਾ ਰਿਮਾਈਂਡਰ ਬਣਾਉਂਦਾ ਹੈ (ਜਾਂ ਮੁੱਖ ਯੂਜ਼ ਕੇਸ ਚਾਲੂ ਕਰਦਾ ਹੈ)। ਰਿਕਵੈਸਟ ਨੂੰ ਕਿਸੇ ਕਾਰਵਾਈ ਨਾਲ ਜੋੜੋ:

• “ਇਸ ਰਿਮਾਈਂਡਰ ਨੂੰ 8:00 AM 'ਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਲੂ ਕਰੋ।”

ਪਹਿਲੀ ਮੰਗ ਨੂੰ ਕੰਮ ਅਤੇ ਸਿਰਫ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲਈ ਰੱਖੋ; ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਵਧ ਦੇ ਹੱਕ ਮੰਗੋ (ਜਿਵੇਂ ਕੈਲੰਡਰ ਐਕਸੈਸ)। iOS ਅਤੇ Android 'ਤੇ ਇੱਕ-ਪਿੱਠੇ ਕਈ ਪਰਮੀਸ਼ਨ ਪ੍ਰੰਪਟ ਨਾ ਦਿਖਾਓ।

ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਸਲ ਕੰਟਰੋਲ ਦਿਓ

ਐਪ ਦੇ ਅੰਦਰ ਪਸੰਦਾਂ ਸਿੱਧੇ ਦਿਓ (ਸਿਸਟਮ ਸੈਟਿੰਗ ਵਿੱਚ ਛੁਪਾ ਕੇ ਨਹੀਂ):

• ਸ਼ਾਂਤ ਘੰਟੇ ਅਤੇ ਦਿਨ (ਵਰਕਡੇ ਬਨਾਮ ਵੀਕਐਂਡ)
• ਪ੍ਰਾਇਰਟੀ (urgent ਵਿਰੁੱਧ normal)
• ਚੈਨਲ/ਸ਼੍ਰੇਣੀਆਂ (ਜਿਵੇਂ Health, Bills, Work) ਅਤੇ ਧੁਨੀਆਂ
• ਫ੍ਰੀਕੈਂਸੀ ਨਿਯਮ (ਉਦਾਹਰਨ: ਪ੍ਰਤੀ ਦਿਨ ਮੈਕਸ ਰਿਮਾਈਂਡਰ)

ਇਹਨਾਂ ਨੂੰ ਰਿਮਾਈਂਡਰ ਬਣਾਉਣ ਦੀ ਸਕਰੀਨ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ Settings ਖੇਤਰ ਤੋਂ ਆਸਾਨੀ ਨਾਲ ਪਹੁੰਚਯੋਗ ਬਣਾਓ।

“permission denied” ਦਾ ਸਮਝਦਾਰੀ ਨਾਲ ਯੋਜਨਾਬੰਧ

ਫੋਲਬੈਕ ਵਰਤੋਂ:

• ਜੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਮਨਾਂ ਕੀਤੇ ਗਏ ਹਨ, ਤਾਂ ਇਨ-ਐਪ ਰਿਮਾਈਂਡਰ (ਬੈਜ, ਇਨਬਾਕਸ ਜਾਂ ਬੈਨਰ) ਦਿਖਾਓ ਅਤੇ ਦੱਸੋ ਕਿ ਸਿਸਟਮ ਸੈਟਿੰਗ ਵਿੱਚ ਕਿਵੇਂ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਹੈ।
• ਈਮੇਲ/SMS ਵਿਕਲਪ ਸਿਰਫ਼ ਜੇ ਉਹ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਹਨ ਅਤੇ ਸਹਿਮਤੀ ਸਪਸ਼ਟ ਹੋ।
• ਨਿਕਾਸ ਚੈਨਲ (Android) ਪਛਾਣੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਨਿਰਦਿਸ਼ਟ ਚੈਨਲ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਮਾਰਗ ਦਰਸਾਓ, ਸਿਰਫ਼ "ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਲੂ ਕਰੋ" ਨਾ ਕਹੋ।

ਨੋਟੀਫਿਕੇਸ਼ਨ UX: ਸਮੱਗਰੀ, ਆਵ੍ਰਿਤੀ, ਅਤੇ ਡੀਪ ਲਿੰਕ

ਨੋਟੀਫਿਕੇਸ਼ਨ UX ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਇੱਕ "ਸਮਾਰਟ" ਰਿਮਾਈਂਡਰ ਐਪ ਮਦਦਗਾਰ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਜਾਂ ਬੈਕਗਰਾਊਂਡ ਸ਼ੋਰ ਬਣ ਜਾਂਦਾ ਹੈ। ਵਧੀਆ UX ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਬਾਰੇ ਹੈ: ਸਹੀ ਗੱਲ ਕਹਿਣਾ, ਸਹੀ ਗਤੀ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਸਹੀ ਸਕ੍ਰੀਨ 'ਤੇ ਲੈ ਕੇ ਜਾਣਾ।

ਨੋਟੀਫਿਕੇਸ਼ਨ ਟੈਕਸੋਨੋਮੀ ਬਣਾਓ

ਉਹ ਕਿਸਮਾਂ ਦੇ ਨਾਮ ਰੱਖੋ ਜੋ ਤੁਹਾਡਾ ਐਪ ਭੇਜੇਗਾ। ਇੱਕ ਸਾਫ ਟੈਕਸੋਨੋਮੀ ਕਾਪੀ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖਦੀ ਹੈ ਅਤੇ ਹਰ ਕਿਸਮ ਲਈ ਵੱਖ-ਵੱਖ ਨਿਯਮ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ:

• Reminder: ਟਾਈਮ-ਅਧਾਰਤ ("ਅੱਜ ਕਿਰਾਇਆ ਭਰੋ") ਜਾਂ ਇਵੈਂਟ-ਅਧਾਰਤ ("ਹੁਣ ਨਿਕਲੋ ਤਾਂ ਕਿ 3:00 PM ਤੱਕ ਪਹੁੰਚ ਜਾਓ").
• Nudge: ਨਰਮ ਪ੍ਰੰਪਟ ਜਦੋਂ ਟਾਸਕ ਡ੍ਰਿਫਟ ਕਰ ਰਿਹਾ ਹੋਵੇ ("ਕੀ ਤੁਸੀਂ ਆਪਣਾ 10 ਮਿੰਟ ਦਾ ਸਟ੍ਰੈਚ ਪੂਰਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ?").
• Follow-up: ਅਧੂਰਾ ਕਾਰਵਾਈ ਦੇ ਬਾਅਦ ("ਤੁਸੀਂ ਗ੍ਰੋਸਰੀ ਲਿਸਟ ਸ਼ੁਰੂ ਕੀਤੀ—ਅਖੀਰਲੇ ਦੋ ਆਈਟਮ ਸ਼ਾਮਲ ਕਰੋ?").
• Summary: ਬੈਚਡ ਡਾਈਜੇਸਟ ("ਅੱਜ 3 ਕੰਮ ਦੇ ਰੂਪ ਹਨ, 1 ਓਵਰਡਿਊ")।

ਇਕ ਨਜ਼ਰ ਵਿੱਚ ਸਮਝ ਆਉਣ ਵਾਲੀ ਕਾਪੀ ਲਿਖੋ

ਸ਼ਾਨਦਾਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਾਪੀ ਕੀ, ਕਦੋਂ, ਅਤੇ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ—ਬਿਨਾਂ ਐਪ ਖੋਲ੍ਹੇ ਵਿਚਾਰ ਜ਼ਰੂਰਤ ਬਣਾਉਣ ਦੇ।

ਉਦਾਹਰਨ:

• “ਪੌਦੇ ਨੂੰ ਪਾਣੀ ਦਿਓ • ਅੱਜ 6:00 PM • Mark done ਜਾਂ Snooze”
• “ਖਰਚਾ ਰਿਪੋਰਟ ਜਮ੍ਹਾਂ ਕਰੋ • 2 ਘੰਟੇ ਵਿੱਚ ਡਿਊ • Review now”

ਸਿਰਲੇਖ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ, ਅਸਪਸ਼ਟ ਫਰੇਜ਼ਾਂ ਤੋਂ ਬਚੋ ("ਭੁੱਲੋ ਨਾ!"), ਅਤੇ ਕਾਰਵਾਈ ਬਟਨਾਂ ਨੂੰ ਸੰਭਾਲ ਕੇ ਅਤੇ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਵਰਤੋ (ਜਿਵੇਂ Snooze, Complete, Reschedule)।

ਆਵ੍ਰਿਤੀ ਕੰਟਰੋਲ: caps, ਬੈਚਿੰਗ, ਅਤੇ ਪ੍ਰਭਾਵ-ਰੋਕਥਾਮ

ਇੱਕ ਸਮਾਰਟ ਰਿਮਾਈਂਡਰ ਐਪ ਸ਼ਾਂਤ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਰੋਜ਼ਾਨਾ cap ਪ੍ਰਤੀ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਿਸਮ ਅਤੇ ਘੱਟ-ਤਾਤਕਾਲਤਾ ਆਈਟਮਾਂ ਨੂੰ summaries ਵਿੱਚ ਬੈਚ ਕਰਨ ਵਰਗੀਆਂ ਨੀਤੀਆਂ ਰੱਖੋ।

ਨਾਲ ਹੀ "ਸਮਾਰਟ ਸਰੈਸਪਸ਼ਨ" ਨਿਯਮ ਜਿਵੇਂ:

• ਜੇ ਯੂਜ਼ਰ ਨੇ ਹੁਣੇ ਹੀ ਟਾਸਕ ਖੋਲ੍ਹਿਆ, ਤਾਂ ਨਜਰ ਨਾ ਭੇਜੋ।
• ਯੂਜ਼ਰ Do Not Disturb / Focus ਮੋਡ ਵਿੱਚ ਹੋਵੇ ਤਾਂ ਰਿਮਾਈਂਡਰ ਰੋਕੋ (ਜਿੱਥੇ ਸਹਾਇਤਾ ਮਿਲੇ)।
• ਇੱਕ ਤਰਕਸੰਗਤ ਸੰਖਿਆ ਤੋਂ ਬਾਅਦ ਓਵਰਡਿਊ ਅਲਰਟ ਰਿਪੀਟ ਕਰਨਾ ਬੰਦ ਕਰੋ ਅਤੇ ਇਕ ਸਪਸ਼ਟ ਸੁਝਾਅ ਦਿਓ ("Reschedule?").

ਡੀਪ ਲਿੰਕ ਜੋ ਸਹੀ ਸਕ੍ਰੀਨ 'ਤੇ ਲੈਂਡ ਕਰਦੇ ਹਨ

ਹਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਯੂਜ਼ਰ ਨੂੰ ਸਿੱਧਾ ਸੰਬੰਧਿਤ ਟਾਸਕ 'ਤੇ ਖੋਲ੍ਹਣਾ ਚਾਹੀਦਾ ਹੈ, ਘਰ ਸਕ੍ਰੀਨ ਤੇ ਨਹੀਂ। ਡੀਪ ਲਿੰਕ ਉਦਾਹਰਨਾਂ:

• /tasks/123
• /tasks/123?action=reschedule

ਇਸ ਨਾਲ ਰੁਕਾਵਟ ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਮੁਕੰਮਲਤਾ ਵੱਧਦੀ ਹੈ।

ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਐਕਸੈਸਬਿਲਿਟੀ

ਪਾਠ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ (ਛੋਟੀ, ਭਾਰੀ ਲਿਖਤ ਤੋਂ ਬਚੋ), ਸਕ੍ਰੀਨ ਰੀਡਰਾਂ ਲਈ ਮੈਨੀੰਗਫੁਲ ਲੇਬਲ ਦਿਓ, ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਾਰਵਾਈਆਂ ਲਈ ਟੈਪ ਟਾਰਗੇਟ ਵੱਡੇ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਵਾਇਸ ਅਸਿਸਟੈਂਟ ਜਾਂ ਵੋਇਸ ਇਨਪੁਟ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਬੋਲਤਰਿਕ ਵਿਵਹਾਰ ਨਾਲ ਸ਼ਬਦਾਵਲੀ ਮੇਲ ਖਾਂਦੀ ਹੋਵੇ ("30 ਮਿੰਟ ਲਈ ਸਨੂਜ਼ ਕਰੋ").

ਪर्सਨਲਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਨੋਟੀਫਿਕੇਸ਼ਨ "ਸਮਾਰਟ" ਬਣਾਉਣਾ

"ਸਮਾਰਟ" ਦਾ ਮਤਲਬ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਜਟਿਲ AI ਹੋਵੇ। ਦੀਨ ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਸਹੀ ਰਿਮਾਈਂਡਰ, ਇਕ ਐਸੇ ਸਮੇਂ ਤੇ ਅਤੇ ਇਕ ਐਸੇ ਲਹਜੇ ਵਿੱਚ ਭੇਜੋ ਜੋ ਮੁਕੰਮਲਤਾ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧਾਏ—ਬਿਨਾਂ ਪਰੇਸ਼ਾਨ ਕਰਨ ਦੇ।

ਨਿਯਮਾਂ ਅਤੇ ਸਧਾਰਨ ਸਕੋਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

Machine learning ਤੋਂ ਪਹਿਲਾਂ, ਸਾਫ ਨਿਯਮ ਅਤੇ ਹਲਕਾ ਸਕੋਰਿੰਗ ਮਾਡਲ ਲਗਾਓ। ਹਰ ਸੰਭਵ ਭੇਜਣ ਵੇਲੇ ਲਈ ਕੁਝ ਸਿਗਨਲਾਂ (ਜਿਵੇਂ, "ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ 30 ਮਿੰਟ ਵਿੱਚ ਪੂਰਾ ਕਰਦਾ ਹੈ", "ਹੁਣ ਮੀਟਿੰਗ ਵਿੱਚ ਹੈ", "ਰਾਤ ਦੇ ਦੇਰ ਘੰਟੇ ਹਨ") ਤੋਂ ਸਕੋਰ ਗਣਨਾ ਕਰੋ। ਪਰਵੇਨਕ ਸਪਤ ਤੱਤੇ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਵਧੀਆ ਸਕੋਰ ਵਾਲਾ ਸਮਾਂ ਚੁਣੋ।

ਇਹ ਢੰਗ ਬਲੈਕ-ਬੌਕਸ ਮਾਡਲ ਨਾਲੋਂ ਆਸਾਨ ਸਮਝਣਯੋਗ, ਡੀਬੱਗ ਅਤੇ ਸੁਧਾਰ ਯੋਗ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਫਿਰ ਵੀ ਨਿੱਜੀ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

ਉਹ ਵਰਤੋਂ ਦੀਆਂ ਆਦਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਉਨ੍ਹਾਂ ਦਾ ਵਰਤੋਂ ਕਰੋ

ਵਧੀਆ ਪर्सਨਲਾਈਜ਼ੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਪੈਟਰਨਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਟਰੈਕ ਕਰਦੇ ਹੋ:

• ਆਮ ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ: ਜੇ ਯੂਜ਼ਰ ਆਮ ਤੌਰ 'ਤੇ 8–9am 'ਚ ਟਾਸਕ ਪੂਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸ ਸਮੇਂ ਨੂੰ ਡਿਫੌਲਟ ਬਣਾਉ।
• ਸਨੂਜ਼ ਪੈਟਰਨ: ਜੇ ਉਹ ਹਮੇਸ਼ਾ 15 ਮਿੰਟ ਲਈ ਸਨੂਜ਼ ਕਰਦੇ ਹਨ, ਤਾਂ "Snooze 15m" ਮੁੱਖ ਕਾਰਵਾਈ ਬਣਾਉ।
• ਲੋਕੇਸ਼ਨ ਜਾਂ ਰੁਟੀਨ ਸੰਦਰਭ: ਜੇ "ਕਿਰਾਣਾ ਖਰੀਦੋ" ਆਮ ਤੌਰ 'ਤੇ ਸਟੋਰ ਦੇ ਨੇੜੇ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਨੇੜਤਾ 'ਤੇ ਸੁਝਾਅ ਦਿਓ (ਸਿਰਫ਼ ਸਪਸ਼ਟ opt-in ਨਾਲ)।

ਸੰਦੇਸ਼ ਦੇਣ ਬਿਨਾਂ 'ਚੀਪ' ਨਾ ਹੋਵੋ

ਸੰਦਰਭ ਉਹ ਸਮੇਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ ਜਦ ਇਹ ਸਪਸ਼ਟ ਅਤੇ ਆਦਰਸ਼ੀਕ ਹੋ:

• ਕੈਲੰਡਰ ਬਜ਼ੀ ਸਥਿਤੀ: ਗੈਰ-ਤਾਤਕਾਲੀ ਰਿਮਾਈਂਡਰ ਨੂੰ ਯੂਜ਼ਰ ਦੇ ਬਜ਼ੀ ਹੋਣ ਦੌਰਾਨ ਡੇਲੇ ਕਰੋ।
• ਡਿਵਾਈਸ ਫੋਕਸ ਮੋਡ / ਸਿਸਟਮ DND: OS ਨਾਲ ਵਿਵਾਦ ਨਾ ਕਰੋ—ਉਸਦੇ ਨਾਲ ਮਿਲ ਕੇ ਚੱਲੋ।
• ਦਿਨ ਦਾ ਸਮਾਂ: ਰਾਤ ਨੂੰ ਨਰਮ ਨੁਡਜ਼ ਵਰਤੋ; ਘੱਟ ਪ੍ਰਾਇਰਟੀ ਵਾਲੇ ਆਈਟਮ ਸਵੇਰੇ ਲਈ ਰੋਕੋ।

ਸਮਾਰਟ ਸੈਂਡ ਵਿੰਡੋ ਅਤੇ ਸ਼ਾਂਤ ਘੰਟੇ

ਸਮਾਰਟ ਸੈਂਡ ਵਿੰਡੋ ਲਾਗੂ ਕਰੋ: ਇਕ ਇਕਲ ਟਾਈਮਸਟੈਂਪ ਦੀ ਬਜਾਏ, ਯੂਜ਼ਰ-ਮਾਨਯਤਿਤ ਰੇਂਜ (ਉਦਾਹਰਨ: 9–11am) ਦੇ ਵਿੱਚ ਭੇਜੋ। ਇਸ ਨੂੰ do-not-disturb ਪੀਰੀਅਡ (ਜਿਵੇਂ 10pm–7am) ਨਾਲ ਜੋੜੋ ਅਤੇ ਪ੍ਰਤੀ ਰਿਮਾਈਂਡਰ overrides ਦੀ ਆਗਿਆ ਦਿਓ ਜੇ ਆਈਟਮ urgent ਹੈ।

ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਝਾਓ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ override ਦੀ ਆਗਿਆ ਦਿਓ

ਯੂਜ਼ਰ ਨੂੰ ਦੱਸੋ ਕਿ ਰਿਮਾਈਂਡਰ ਕਿਉਂ moved ਹੋਇਆ: “ਅਸੀਂ ਇਹ 9:30am ਲਈ ਸ਼ਡਿਊਲ ਕੀਤਾ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸਮਾਨ ਟਾਸਕ ਸਵੇਰੇ ਵਿੱਚ ਮੁਕੰਮਲ ਕਰਦੇ ਹੋ।” ਛੇਤੀ ਕੰਟਰੋਲ ਜਿਵੇਂ “ਮੂਲ ਸਮੇਂ 'ਤੇ ਭੇਜੋ” ਜਾਂ “ਹਮੇਸ਼ਾ 8am 'ਤੇ ਭੇਜੋ” ਸ਼ਾਮਲ ਕਰੋ। ਪर्सਨਲਾਈਜ਼ੇਸ਼ਨ ਇੱਕ ਮਦਦਗਾਰ ਸਹਾਇਕ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਗੁਪਤ ਸੈਟਿੰਗ ਵਾਂਗ ਨਹੀਂ।

ਰਿਮਾਈਂਡਰ ਫਲੋ: ਬਣਾਉਣਾ, ਸਨੂਜ਼, ਰੀ-ਸ਼ੈਡਿਊਲ, ਅਤੇ ਮੁਕੰਮਲ

ਜਦੋਂ ਯੂਜ਼ਰ ਬਹੁਤ ਵਿਆਸਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਐਪ ਉਸ ਵੇਲੇ effortless ਹੋਵੇ ਤਾਂ ਇਹ "ਸਮਾਰਟ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਪੂਰੇ ਲਾਈਫਸਾਈਕਲ ਦਾ ਡਿਜ਼ਾਈਨ: create → alert → act → schedule ਨੂੰ ਅਪਡੇਟ ਕਰੋ → ਲੂਪ ਬੰਨ ਕਰੋ।

ਰਿਮਾਈਂਡਰ ਬਣਾਉਣਾ (ਤੇਜ਼ ਪਰ ਸੰਰਚਿਤ)

ਬਣਾਉਣ ਹਲਕਾ ਰੱਖੋ: ਸਿਰਲੇਖ, ਸਮਾਂ, ਅਤੇ (ਵਿਕਲਪਿਕ) ਰੀਪੀਟ ਨਿਯਮ। ਹੋਰ ਸਭ—ਨੋਟ, ਸਥਾਨ, ਪ੍ਰਾਇਰਟੀ—ਜੋੜਨਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਲਾਜ਼ਮੀ ਨਹੀਂ।

ਜੇ ਤੁਸੀਂ ਰੀਕਰਿੰਗ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਿਯਮ ਨੂੰ ਹਰੇਕ ਘਟਨਾ ਤੋਂ ਅਲੱਗ ਸਟੋਰ ਕਰੋ। ਇਸ ਨਾਲ "ਅਗਲੀ ਘਟਨਾ" ਦਿਖਾਉਣਾ ਅਤੇ ਸ਼ਡਿਊਲ ਦੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

ਨੋਟੀਫਿਕੇਸ਼ਨ ਤੋਂ ਕਾਰਵਾਈ: ਤੇਜ਼ ਕਾਰਵਾਈਆਂ

ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਨੂੰ quick actions ਸਹਾਇਤਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਐਪ ਖੋਲ੍ਹਣ ਤੋਂ ਬਿਨਾਂ ਮੁਕੰਮਲ ਕਰ ਸਕੇ:

• Mark done (ਮੌਜੂਦਾ ਘਟਨਾ ਨੂੰ ਪੂਰਾ ਮੰਨ ਲੈਂਦਾ ਹੈ)
• Snooze (ਇੱਕ ਵਾਰੀ ਦੇ ਲਈ ਦੇਰੀ)
• Reschedule (ਨਵੇਂ ਸਮੇਂ 'ਤੇ ਲਿਜਾਣਾ)
• Skip (ਰੀਕਰਿੰਗ ਰਿਮਾਈਂਡਰ ਲਈ—ਕੇਵਲ ਇਸ ਘਟਨਾ ਨੂੰ ਛੱਡੋ)

ਜਦੋਂ ਇੱਕ quick action ਸ਼ਡਿਊਲ ਬਦਲਦਾ ਹੈ, UI ਨੂੰ ਤੁਰੰਤ ਅਪਡੇਟ ਕਰੋ ਅਤੇ ਰਿਮਾਈਂਡਰ ਇਤਿਹਾਸ ਵਿੱਚ ਲੌਗ ਰੱਖੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਯੂਜ਼ਰ ਵੇਖ ਸਕੇ ਕਿ ਕੀ ਹੋਇਆ।

ਸਨੂਜ਼ ਅਤੇ ਰੀ-ਸ਼ੈਡਿਊਲ ਜੋ ਦੋਹਰਾਅ ਨਹੀਂ ਲੱਗਦੇ

ਸਨੂਜ਼ ਜ਼ਿਆਦਾਤਰ ਸਮੇਂ ਇੱਕ ਟੈਪ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਈ ਪ੍ਰੀਸੈੱਟ ਦਿਓ (ਉਦਾਹਰਨ: 5 ਮਿੰਟ, 15 ਮਿੰਟ, 1 ਘੰਟਾ, ਸਵੇਰੇ ਕੱਲ੍ਹ) ਅਤੇ ਕਸਟਮ ਟਾਈਮ ਪਿਕਰ ਵੀ।

ਰੀ-ਸ਼ੈਡਿਊਲ ਸਨੂਜ਼ ਤੋਂ ਵੱਖਰਾ ਹੈ: ਇਹ ਇਕ ਇਰਾਦਾਪੂਰਕ ਬਦਲਾਅ ਹੈ। ਇਕ ਸਧਾਰਨ ਪਿਕਰ ਅਤੇ ਸਮਾਰਟ ਸੁਝਾਅ (ਅਗਲਾ ਖਾਲੀ ਸਮਾਂ, ਆਮ ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ, "ਮੇਰੀ ਮੀਟਿੰਗ ਤੋਂ ਬਾਅਦ") ਦਿਓ। ਬਿਨਾਂ ਜਟਿਲ ਪर्सਨਲਾਈਜ਼ੇਸ਼ਨ ਦੇ ਵੀ, "ਅੱਜ ਬਾਅਦ" ਅਤੇ "ਕੱਲ੍ਹ" ਸ਼ਾਰਟਕਟ ਤਕਲੀਫ ਘਟਾਉਂਦੇ ਹਨ।

ਸਾਫ ਰਿਮਾਈਂਡਰ ਡੀਟੇਲ ਪੇਜ (ਇਤਿਹਾਸ ਸਮੇਤ)

ਜਦੋਂ ਯੂਜ਼ਰ ਰਿਮਾਈਂਡਰ ਖੋਲ੍ਹਦਾ ਹੈ, ਦਿਖਾਓ:

• ਅਗਲੀ ਘਟਨਾ (ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ)
• ਨਿਯਮ ਜਾਂ ਸ਼ਡਿਊਲ ਸਾਰ (“Every weekday at 9:00”)
• ਇਕ ਹਲਕੀ ਇਤਿਹਾਸ (created, snoozed, rescheduled, completed, skipped)

ਇਹ ਡੀਟੇਲ ਪੇਜ ਗਲਤੀਆਂ undo ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਜਗ੍ਹਾ ਹੈ।

ਛੁੱਟ ਗਈਆਂ 알ਰਟਾਂ: ਇੱਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸੈਂਟਰ ਇਨਬਾਕਸ

ਪੁਸ਼ ਅਤੇ ਲੋਕਲ ਨੋਟੀਫਿਕੇਸ਼ਨ dismiss ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਇਕ ਇਨ-ਐਪ Notification Center ਜੋ ਮਿਸਡ ਰਿਮਾਈਂਡਰਾਂ ਨੂੰ ਹੱਲ ਹੋਣ ਤੱਕ ਰੱਖੇ, ਜੋੜੋ। ਹਰ ਆਈਟਮ ਤੇ ਉਹੇ ਕਾਰਵਾਈਆਂ ਮਿਲਣ: done, snooze, reschedule।

ਸ਼ੁਰੂਆਤੀ ਇਜਾਜ਼ਤਾਂ (Edge cases) ਜੋ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੱਲ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ

ਅਸਲੀ ਜ਼ਿੰਦਗੀ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ:

• ਡੁਪਲਿਕੇਟਸ: ਸਵੇਰ ਸੇਵ ਕਰਨ ਜਾਂ ਸਿੰਕ ਕਰਨ ਸਮੇਂ ਦੋਹਰਾਅ ਤੋਂ ਬਚਾਓ
• Expired reminders: ਜੇ ਸਮਾਂ ਗੁਜ਼ਰ ਗਿਆ ਤਾਂ ਕੀ ਹੁੰਦਾ (ਤੁਰੰਤ ਡਿਲਿਵਰ, inbox ਵਿੱਚ ਰੱਖੋ, ਜਾਂ missed ਮਾਰਕ ਕਰੋ)
• Rapid reschedules: ਬਦਲਾਵਾਂ ਨੂੰ debounce ਕਰੋ ਅਤੇ ਨਵੀਂ ਯੂਜ਼ਰ ਮਨਸ਼ਾ ਨੂੰ ਸਰੋਤ-ਸੱਚਾਈ ਬਣਾਓ

ਇਹ ਫੈਸਲੇ ਗੁਲਾਬੀਪਣ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਐਪ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਅਨਾਲਿਟਿਕਸ, ਪ੍ਰਯੋਗ, ਅਤੇ ਇਟਰੇਸ਼ਨ

ਸਮਾਰਟ ਰਿਮਾਈਂਡਰ "ਰੱਖਉ" ਨਹੀਂ ਹਨ। ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਰਿਲੈਵੈਂਸੀ ਬਹਿਤਰ ਕਰਨ ਦਾ ਉਹ ਹੈ ਕਿ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨੂੰ ਉਤਪਾਦ ਸਰਫੇਸ ਵਜੋਂ ਮਾਪੋ, ਟੈਸਟ ਕਰੋ ਅਤੇ ਸੁਧਾਰੋ।

ਸਹੀ ਈਵੈਂਟਸ ਇੰਸਟ੍ਰੂਮੈਂਟ ਕਰੋ

ਰਿਮਾਈਂਡਰ ਲਾਈਫਸਾਈਕਲ ਨਾਲ ਮੈਪ ਹੋਣ ਵਾਲੇ ਈਵੈਂਟਸ ਲੌਗ ਕਰਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। iOS ਅਤੇ Android 'ਤੇ ਨਾਮ ਇਕਸਾਰ ਰੱਖੋ ਤਾਂ ਤੁਸੀਂ ਵਿਵਰਤੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕੋ।

ਘੱਟੋ-ਘੱਟ ਟਰੈਕ ਕਰੋ:

• Permission status: prompted, granted, denied (ਅਤੇ ਯੂਜ਼ਰ ਨੇ ਬਾਅਦ ਵਿੱਚ بدਲਿਆ)
• Notification flow: scheduled, delivered, opened
• Outcome: reminder completed, snoozed, rescheduled, dismissed

ਸੰਦਭ ਪ੍ਰਾਪਰਟੀਆਂ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਸਮਝਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂ ਕੁਝ ਹੋਇਆ: reminder type, scheduled time, user timezone, channel (local vs push), ਅਤੇ ਕੀ ਇਹ personalization rule ਵੱਲੋਂ trigger ਹੋਇਆ।

ਡੈਸ਼ਬੋਰਡ ਜੋ ਉਤਪਾਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ

ਡੈਸ਼ਬੋਰਡ ਤੁਹਾਨੂੰ ਅਗਲਾ ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਸਿਰਫ vanity metrics ਰਿਪੋਰਟ ਕਰਨ ਲਈ ਨਹੀਂ। ਉਪਯੋਗੀ ਦ੍ਰਿਸ਼:

• Opt-in funnel: install → permission prompt shown → granted
• Delivery health: scheduled vs delivered (ਅਤੇ ਫੇਲ੍ਹ ਦੇ ਕਾਰਨ)
• Engagement: open rate by reminder category and time window
• Completion: opened → completed conversion, ਨਾਲ ਹੀ time-to-complete

ਜੇ ਤੁਸੀਂ ਡੀਪ ਲਿੰਕ ਸਮਰਥਨ ਕਰਦੇ ਹੋ, ਤਾਂ "open to intended screen" ਦਰ ਮਾਪੋ ਤਾਂ ਜੋ ਟੁੱਟੀ ਰੂਟਿੰਗ ਪਤਾ ਲੱਗੇ।

ਪ੍ਰਯੋਗ ਬਿਨਾਂ ਯੂਜ਼ਰ ਨੂੰ ਹੈਰਾਨ ਕੀਤੇ

A/B ਟੈਸਟਿੰਗ ਸਮੇਂ-ਵਿੰਡੋ ਅਤੇ ਕਾਪੀ ਬਦਲਾਅ ਲਈ ਆਦਰਸ਼ ਹੈ, ਪਰ ਆਦਰਸ਼ ਨਾਲ। ਯੂਜ਼ਰ ਪਸੰਦਾਂ (quiet hours, frequency caps, categories) ਹਮੇਸ਼ਾਂ ਉੱਚਤਰ ਤਰਜੀਹ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਟੈਸਟ ਵਿਚਾਰ:

• ਸਮਾਂ ਵਿੰਡੋ: ਸਮਾਂ ਤੋਂ 15 ਮਿੰਟ ਪਹਿਲਾਂ ਵਿਰੁੱਧ ਸਮੇਂ 'ਤੇ ਵਿਰੁੱਧ 10 ਮਿੰਟ ਬਾਅਦ
• ਕਾਪੀ: ਸਿੱਧਾ ਵਿਰੁੱਧ ਮਦਦਗਾਰ ਲਹਜਾ, ਛੋਟਾ ਵਿਰੁੱਧ ਵਿਸ਼ੇਸ਼

"ਸਮਾਰਟ" ਵਿਹਾਰ ਲਈ ਫੀਡਬੈਕ ਲੂਪ

ਜਦੋਂ ਯੂਜ਼ਰ ਬਾਰ-ਬਾਰ ਸਨੂਜ਼ ਜਾਂ ਰੀ-ਸ਼ੈਡਿਊਲ ਕਰਦਾ ਹੈ, ਇਹ ਇਕ ਸਿਗਨਲ ਹੈ। ਇਕ ਨਿਰਧਾਰਤ ਪੈਟਰਨ (ਉਦਾਹਰਨ: ਹਫਤੇ ਵਿੱਚ ਤਿੰਨ ਸਨੂਜ਼) ਤੋਂ ਬਾਅਦ, ਇਕ ਛੋਟਾ ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ: “ਕੀ ਇਹ ਮਦਦਗਾਰ ਸੀ?” ਅਤੇ ਇਕ-ਟੈਪ ਸੁਧਾਰ ਦਿਓ ਜਿਵੇਂ "ਟਾਈਮ ਬਦਲੋ" ਜਾਂ "ਰਿਮਾਈਂਡਰ ਘਟਾਓ"।

ਕੋਹੋਰਟਸ ਅਤੇ ਇਟਰੇਸ਼ਨ ਕੈਡੈਂਸ

ਕੋਹੋਰਟ ਵਿਸ਼ਲੇਸ਼ਣ ਨਾਲ ਦੇਖੋ ਕਿ ਕੀ ਚੀਜ਼ ਯੂਜ਼ਰਾਂ ਨੂੰ ਜ਼ਿੰਦਾ ਰੱਖਦੀ ਹੈ: ਰਿਮਾਈਂਡਰ ਕਿਸਮ, opt-in ਸਮਾਂ, ਜਾਂ ਪਹਿਲੇ ਹਫ਼ਤੇ ਦੀ completion rate। ਨਤੀਜੇ ਨੂੰ ਨਿਯਮਤ ਕੈਡੈਂਸ 'ਤੇ ਰਿਵਿਊ ਕਰੋ, ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰੋ, ਅਤੇ ਜੋ ਸਿੱਖਿਆ ਉਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਕਿ ਪרסਨਲਾਈਜ਼ੇਸ਼ਨ ਨਿਯਮ ਸਬੂਤ ਦੇ ਆਧਾਰ 'ਤੇ ਵਿਕਸਤ ਹੋਣ।

ਪ੍ਰਾਈਵੇਸੀ, ਸੁਰੱਖਿਆ, ਅਤੇ ਅਨੁਕੂਲਤਾ ਦੀਆਂ ਬੁਨਿਆਦੀ ਗੱਲਾਂ

ਸਮਾਰਟ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨਿੱਜੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਗੋਪਨੀਯਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਗੈਰ-ਚਰਚਾ ਯੋਗ ਹਨ। ਸਭ ਤੋਂ ਸਧਾਰਨ ਤਰੀਕਾ ਜੋ ਖਤਰੇ ਘਟਾਉਂਦਾ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਰਿਮਾਈਂਡਰ ਐਪ ਘੱਟੋਂ-ਘੱਟ ਨਿੱਜੀ ਡੇਟਾ ਨਾਲ ਮੁੱਲ ਪਹੁੰਚਾ ਸਕੇ—ਅਤੇ ਜੋ ਕੁਝ ਵੀ ਤੁਸੀਂ ਇਕੱਠਾ ਕਰਦੇ ਹੋ ਉਸ ਬਾਰੇ ਪਾਰਦਰਸ਼ੀ ਹੋਵੋ।

ਜ਼ਰੂਰੀ ਹੀ ਜੋ ਇਕੱਤਰ ਕਰੋ

"ਨੋ-ਨੋ-ਨੋ" ਮਨੋਵਿਰਤੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਰਿਮਾਈਂਡਰ ਬਿਨਾਂ ਲੋਕੇਸ਼ਨ, ਕੰਟੈਕਟ ਜਾਂ ਕੈਲੰਡਰ ਐਕਸੈਸ ਦੇ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਮੰਗੋ ਹੀ ਨਾ। ਜੇ ਸੰਵੇਦਨਸ਼ੀਲ ਇਨਪੁਟ ਦੀ ਲੋੜ ਹੈ (ਜਿਵੇਂ ਲੋਕੇਸ਼ਨ-ਅਧਾਰਤ ਰਿਮਾਈਂਡਰ), ਤਾਂ ਉਹ ਵਿਕਲਪਿਕ ਰੱਖੋ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਉਸ ਫੀਚਰ ਨਾਲ ਜੋੜੋ ਜੋ ਯੂਜ਼ਰ ਨੇ ਖੋਲ੍ਹਿਆ।

ਇੱਕ عملي ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਇਕ ਫੀਲਡ ਸਟੋਰ ਕਰਨ ਦਾ ਕਾਰਨ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਦੱਸ ਸਕਦੇ, ਤਾਂ ਉਸਨੂੰ ਹਟਾ ਦੇਵੋ।

ਡੇਟਾ ਉਪਯੋਗ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ (ਅਤੇ ਉਹ ਓਥੇ ਰੱਖੋ ਜਿੱਥੇ ਯੂਜ਼ਰ ਵੇਖਦੇ ਹਨ)

ਡੇਟਾ ਉਪਯੋਗ ਦੋ ਥਾਵਾਂ 'ਤੇ ਸਮਝਾਓ:

• ਆਨਬੋਰਡਿੰਗ ਪਰਮੀਸ਼ਨ ਪ੍ਰੰਪਟ: ਛੋਟਾ, ਫੀਚਰ-ਆਧਾਰਿਤ (“ਸਮੇਂ 'ਤੇ ਰਿਮਾਈਂਡਰ ਪਾਉਣ ਲਈ ਨੋਟੀਫਿਕੇਸ਼ਨ ਚਾਲੂ ਕਰੋ”).
• ਸੈਟਿੰਗਜ਼ ਪ੍ਰਾਈਵੇਸੀ ਸੈਕਸ਼ਨ: ਵਧੇਰੇ ਵੇਰਵਾ (“ਅਸੀਂ ਤੁਹਾਡਾ ਡਿਵਾਈਸ ਪੁਸ਼ ਟੋਕਨ ਸਟੋਰ ਕਰਦੇ ਹਾਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜਣ ਲਈ; ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਵੇਲੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ”).

ਅਸਪਸ਼ਟ ਭਾਸ਼ਾ ਤੋਂ ਬਚੋ। ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕੀ ਇਕੱਤਰ ਕਰਦੇ ਹੋ, ਕਿਉਂ, ਅਤੇ ਕਿੰਨੀ ਦੇਰ ਲਈ ਰੱਖਦੇ ਹੋ।

ਸੁਰੱਖਿਅਤ ਸਟੋਰੇਜ, ਰੀਟੇਨਸ਼ਨ, ਅਤੇ ਮਿਟਾਉਣਾ

ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲਈ ਡਿਵਾਈਸ ਟੋਕਨ (APNs on iOS, FCM on Android) ਲੋੜੀਂਦੇ ਹਨ। ਟੋਕਨਾਂ ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਤੱਤ ਸਮਝੋ:

• ਟੋਕਨਾਂ ਅਤੇ ਯੂਜ਼ਰ ਡੇਟਾ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਸਟੋਰੇਜ (at rest) 'ਚ ਰੱਖੋ ਅਤੇ TLS (in transit) ਵਰਤੋਂ।
• ਐਕਸੈਸ ਲਿਮਿਟ ਕਰੋ (least-privilege roles, audited admin access)।
• ਰੀਟੇਨਸ਼ਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਸਿਰਫ਼ ਉਹ ਰੱਖੋ ਜੋ ਰਿਮਾਈਂਡਰ ਅਤੇ ਅਨਲਿਟਿਕਸ ਲਈ ਲਾਜ਼ਮੀ ਹੈ; ਪੁਰਾਣੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਲੋਗਾਂ ਲਈ ਆਟੋਮੈਟਿਕ ਮਿਟਾਉ।

ਦਿਨ ਪਹਿਲਾਂ ਹੀ ਯੂਜ਼ਰ-ਚਲਾਉ ਉਤਪਾਦ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ: ਖਾਤਾ ਮਿਟਾਉਣ 'ਤੇ ਨਿੱਜੀ ਡੇਟਾ ਹਟਾ ਦਿਓ ਅਤੇ ਪੁਸ਼ ਟੋਕਨਾਂ ਨੂੰ ਅਮਾਨਤ ਕਰੋ।

ਪਲੇਟਫਾਰਮ ਨੀਤੀਆਂ ਅਤੇ ਯੂਜ਼ਰ ਕੰਟਰੋਲ

iOS/Android ਨੀਤੀਆਂ ਅਤੇ ਸਹਿਮਤੀ ਦੀਆਂ ਲੋੜਾਂ ਦਾ ਸਤਿਕਾਰ ਕਰੋ: ਕੋਈ ਲੁਕਾਇਆ ਟ੍ਰੈਕਿੰਗ ਨਹੀਂ, opt-in ਬਿਨਾਂ ਪੁਸ਼ ਨਾ ਭੇਜੋ, ਅਤੇ ਗੁਮਰਾਹ ਕਰਨ ਵਾਲੀ ਸਮੱਗਰੀ ਨਾ ਭੇਜੋ।

ਯੂਜ਼ਰ ਕੰਟਰੋਲ ਜੋ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹਨ:

• ਡੇਟਾ ਐਕਸਪੋਰਟ (ਬੁਨਿਆਦੀ portability)
• ਖਾਤਾ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਇਤਿਹਾਸ ਮਿਟਾਉਣਾ
• ਨੋਟੀਫਿਕੇਸ਼ਨ ਇਤਿਹਾਸ/ਲੋਗ ਲਈ ਸੀਮਾਵਾਂ (ਉਦਾਹਰਨ: ਪਿਛਲੇ 30–90 ਦਿਨ)

ਇਹ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਬਾਅਦ ਵਿੱਚ ਅਨੁਕੂਲਤਾ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ “ਸਮਾਰਟ” ਫੀਚਰਾਂ ਨੂੰ ਯੂਜ਼ਰ ਅਸਹਜਤਾ ਵਿੱਚ ਨਹੀਂ ਬਦਲਣ ਦਿੰਦੀਆਂ।

ਟੈਸਟਿੰਗ, ਲਾਂਚ ਚੈੱਕਲਿਸਟ, ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸੁਧਾਰ

ਨੋਟੀਫਿਕੇਸ਼ਨ ਉਹ ਫੀਚਰ ਹਨ ਜੋ ਡੈਮੋ ਵਿੱਚ ਠੀਕ ਲੱਗ ਸਕਦੇ ਹਨ ਪਰ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ। ਟੈਸਟਿੰਗ ਅਤੇ ਲਾਂਚ ਤਿਆਰੀ ਨੂੰ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਸਮਝੋ, ਨਾ ਕਿ ਆਖਰੀ ਰੁਕਾਵਟ।

ਟੈਸਟਿੰਗ: ਡਿਲਿਵਰੀ, ਟਾਈਮਿੰਗ, ਅਤੇ ਐਜ ਕੇਸ

ਕਈ OS ਵਰਜ਼ਨਾਂ ਅਤੇ ਨਿਰਮਾਤਿਆਂ (ਮੁੱਖ ਤੌਰ 'ਤੇ Android) 'ਤੇ ਡਿਲਿਵਰੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸ ਹਾਲਤਾਂ ਨਾਲ ਏਕ ਰਿਮਾਈਂਡਰ ਐਂ-ਟੂ-ਐਂਡ ਟੈਸਟ ਕਰੋ:

• Idle ਅਤੇ backgrounded app
• Low Power Mode / Battery Saver
• Do Not Disturb / Focus modes
• ਖਰਾਬ ਨੈੱਟਵਰਕ, airplane mode, ਅਤੇ ਦੁਬਾਰਾ ਕਨੈਕਟ

ਟਾਈਮਿੰਗ ਬੱਗ ਭਰੋਸਾ ਖੋਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹਨ। ਖਾਸ QA ਸ਼ਾਮਲ ਕਰੋ:

• ਟਾਈਮਜ਼ੋਨ (ਯਾਤਰਾ ਪਰਿਸਥਿਤੀਆਂ)
• DST ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ (ਸਪ੍ਰਿੰਗ ਫਾਰਵਰਡ / ਫਾਲ ਬੈਕ)
• ਮੈਨੂਅਲ ਘੜੀ ਬਦਲਣਾ (ਯੂਜ਼ਰ ਘੜੀ ਬਦਲਦਾ ਹੈ, ਗਲਤ ਸਿਸਟਮ ਸਮਾਂ)
• ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਫਾਰਮੈਟਿੰਗ (12/24-ਘੰਟਾ, ਭਾਸ਼ਾ)

ਜੇ ਤੁਸੀਂ ਰੀਕਰਿੰਗ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ "ਮਹੀਨੇ ਦਾ ਆਖਰਾ ਦਿਨ", ਲੀਪ-ਈਅਰ, ਅਤੇ "ਸਿਰਫ਼ ਕਾਰਜ ਦਿਨ" ਲਾਜਿਕ ਟੈਸਟ ਕਰੋ।

ਲਾਂਚ ਚੈੱਕਲਿਸਟ: ਅਚੰਭਿਆਂ ਨੂੰ ਘੱਟ ਕਰੋ

ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੀ ਟੀਮ ਲਈ ਇੱਕ ਆਸਾਨ ਚੈੱਕਲਿਸਟ ਤਿਆਰ ਕਰੋ ਜੋ ਦੁਹਰਾਈ ਜਾ ਸਕੇ:

• App Store / Play ਆਸੈਟ: ਰਿਮਾਈਂਡਰ ਫਲੋ ਦਿਖਾਉਂਦੇ ਸਕਰੀਨਸ਼ਾਟ, ਸਾਫ ਪਰਮੀਸ਼ਨ ਕਾਰਣ
• ਸਪੋਰਟ ਡੌਕਸ: "ਮੈਨੂੰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਿਉਂ ਨਹੀਂ ਮਿਲੀ?", "ਰਿਮਾਈਂਡਰ ਦਾ ਸਮਾਂ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ", ਅਤੇ ਰਿਫੰਡ/ਸਪੋਰਟ ਰਸਤੇ
• ਕਰੈਸ਼ ਅਤੇ ਪਰਫਾਰਮੈਂਸ ਮਾਨੀਟਰਨਗ ਨਾਲ ਅਲਰਟ (ਨੋਟੀਫਿਕੇਸ਼ਨ-ਸੰਬੰਧੀ ਸੈਸ਼ਨ ਟੈਗ ਕਰਨ ਦਾ ਤਰੀਕਾ)
• ਇੰਟਰਨਲ ਰਨਬੁੱਕ: ਕਿਵੇਂ ਮੁਹਿੰਮ ਰੋਕਨੀ, ਗਲਤ ਟੈਂਪਲੇਟ ਨਿਰਸੰਲ ਕਰਨੀ, ਜਾਂ ਹਾਟਫਿਕਸ ਜਾਰੀ ਕਰਨੀ

ਜੇ ਤੁਸੀਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਜਾਂ ਲਗਾਤਾਰ ਇਟਰੇਸ਼ਨ ਲਈ ਸਹਾਇਤਾ ਦੀ ਯੋਜਨਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਮੀਦਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪੰਨਿਆਂ ਜਿਵੇਂ /pricing ਉੱਤੇ ਸੰਗਠਿਤ ਕਰੋ।

ਲੰਬੇ ਸਮੇਂ ਲਈ ਸੁਧਾਰ: ਸਮੇਂ ਨਾਲ ਭਰੋਸਾ ਜੀਤੋ

ਪੋਸਟ-ਲਾਂਚ, ਉਹ ਅੱਪਗਰੇਡਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਸ਼ੋਰ ਘਟਾਉਂਦੀਆਂ ਅਤੇ ਉਪਯੋਗੀਤਾ ਵਧਾਉਂਦੀਆਂ ਹਨ:

• ਸੰਦਰਭ ਅਤੇ ਲਹਜੇ ਮੁਤਾਬਕ ਹੋਰ ਸੁਨੇਹਾ ਟੈਂਪਲੇਟ
• ਸਪਸ਼ਟ ਓਪਟ-ਇਨ ਨਾਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (ਕੈਲੰਡਰ, ਈਮੇਲ, ਟਾਸਕ)
• ਬਹੁਤ ਸਾਰੇ ਪਿੰਗ ਇੱਕ ਛੋਟੀ ਖਿੱਚ ਵਿੱਚ ਨਾ ਹੋਣ ਲਈ ਸਮਾਰਟ ਬੈਚਿੰਗ

ਜੇ ਤੁਹਾਡੀ ਟੀਮ v1 ਤੋਂ ਬਾਅਦ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਰੱਖਣਾ ਚਾਹੁੰਦੀ ਹੈ, ਤਾਂ Koder.ai ਵਰਗੇ ਟੂਲਸ ਤੁਹਾਨੂੰ ਬਦਲਾਅ ਛੋਟੇ ਲੂਪਾਂ ਵਿੱਚ ship ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ (UI, ਬੈਕਐਂਡ, ਮੋਬਾਈਲ) ਅਤੇ ਇੱਕਸਾਰ ਸਰੋਤ ਕੋਡ ਨਿਰੀਆਤ ਕਰਨ ਅਤੇ ਕਸਟਮ ਡੋਮੇਨ ਨਾਲ ਡਿਪਲੌਇ ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦੇ ਹਨ—ਜਦੋਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਸ਼ਡਿਊਲ ਲਾਜਿਕ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਤ ਹੋ ਰਹੀ ਹੋ।

For deeper guidance on content, frequency, and deep links, see /blog/notification-ux-best-practices.