22 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
ਕਦਮ ਦਰ ਕਦਮ: ਇੱਕ ਸਧਾਰਨ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਮੋਬਾਈਲ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਸਿੱਖੋ ਕਿ ਇੱਕ ਸਰਲ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਮੋਬਾਈਲ ਐਪ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ ਅਤੇ ਬਣਾਉਣਾ ਹੈ: ਕੋਰ ਫੀਚਰ, UX ਪੈਟਰਨ, ਟੈਕ ਚੋਇਸ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਟੈਸਟਿੰਗ ਅਤੇ ਲਾਂਚ ਕਦਮ।
ਸਿੱਖੋ ਕਿ ਇੱਕ ਸਰਲ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਮੋਬਾਈਲ ਐਪ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ ਅਤੇ ਬਣਾਉਣਾ ਹੈ: ਕੋਰ ਫੀਚਰ, UX ਪੈਟਰਨ, ਟੈਕ ਚੋਇਸ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਟੈਸਟਿੰਗ ਅਤੇ ਲਾਂਚ ਕਦਮ।
"ਸਰਲ ਸਮੇਂ ਦੀ ਜਾਗਰੂਕਤਾ" ਦਿਨ ਦੇ ਦੌਰਾਨ ਆਪਣੇ ਸਮੇਂ ਦੇ ਵਾਪਸ ਜਾਣੇ ਦੀ ਨੋਟਿਸ ਕਰਨ ਦੀ ਆਦਤ ਹੈ—ਹਰ ਮਿੰਟ ਦਾ ਪੂਰਾ ਲੋਗ ਬਣਾਉਣਾ ਨਹੀਂ।
ਇੱਕ ਸਮੇਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਇੱਕ ਸਪੀਡਸ਼ੀਟ ਵਰਗੀ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਨਰਮ ਧੱਕਾ ਹੈ: ਰੁਕੋ, ਉੱਪਰ ਦੇਖੋ, ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅਗਲਾ ਸਮਾਂ ਕਿਸ ਚੀਜ਼ ਲਈ ਹੋਵੇਗਾ. ਇਹ ਇਰਾਦੇ ਬਾਰੇ ਹੈ, ਲੇਖਾ-ਜੋਖਾ ਬਾਰੇ ਨਹੀਂ।
ਸਰਲ ਸਮੇਂ ਦੀ ਜਾਗਰੂਕਤਾ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਚੈਕ-ਇਨ, ਹਲਕੇ-ਫੁਲਕੇ ਟਾਈਮਰ, ਅਤੇ ਛੋਟੇ-ਪੱਧਰ ਦੀਆਂ ਚਿੰਤਨਾਵਾਂ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਮਕਸਦ "ਆਟੋਪਾਈਲਟ" ਪਲਾਂ ਨੂੰ ਘਟਾਉਣਾ ਹੈ—ਜਿਵੇਂ ਅਣਚਾਹੇ ਲੰਮੇ ਸਕ੍ਰੋਲਿੰਗ, ਬਿਨਾਂ ਪਤਾ ਟਾਸਕ-ਸਵਿੱਚਿੰਗ, ਜਾਂ ਦਿਨ ਦੀ ਸ਼ੁਰੂਆਤ ਬਿਨਾਂ ਕੋਈ ਯੋਜਨਾ ਦੇ।
ਇਹ ਪੂਰੇ ਸਮੇਂ ਦੀ ਟ੍ਰੈਕਿੰਗ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਹਰ ਗਤੀਵਿਧੀ ਦੀ ਵਰਗੀ ਕਰਨ ਜਾਂ ਦਿਨ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰ ਰਹੇ। ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕੁਝ ਛੋਟੇ ਪ੍ਰਾਂਪਟ ਦਿੰਦੇ ਹੋ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਰਾਹ ਵੇਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਇਹ ਪਹੁੰਚ ਉਹਨਾਂ ਲੋਕਾਂ ਦੀ ਮਦਦ ਕਰਦੀ ਹੈ ਜੋ ਬਹੁਤ ਵਿਆਸਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਪਰ ਨਹੀਂ ਸਮਝ ਪਾਉਂਦੇ ਕਿ ਘੰਟੇ ਕਿੱਥੇ ਗਏ, ਸ਼ਾਮਲ ਹਨ:
ਦ੍ਰਿਸ਼: ਇੱਕ ਰਿਮੋਟ ਵਰਕਰ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ "45 ਮਿੰਟ ਫੋਕਸ" ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਜਦ ਟਾਈਮਰ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਐਪ ਇੱਕ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ: “ਕੀ ਤੁਸੀਂ ਉਸ ਚੀਜ਼ ‘ਤੇ ਕੰਮ ਕੀਤਾ ਜੋ ਤੁਸੀਂ ਮਨਾਇਆ ਸੀ?” ਉਹ ਇੱਕ ਸਧਾਰਨ ਚੈੱਕਪੋਇੰਟ ਦਿਨ ਭਰ ਦੀਆਂ ਗਲਤ ਟਾਸਕ-ਹਾਪਿੰਗਾਂ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।
ਦ੍ਰਿਸ਼: ਕੋਈ ਸ਼ਾਮ ਦੀ ਸਕ੍ਰੋਲਿੰਗ ਘਟਾਉਣਾ ਚਾਹੁੰਦਾ ਹੈ—ਉਹਨੂੰ 9:30 PM 'ਤੇ ਚੈਕ-ਇਨ ਮਿਲਦਾ ਹੈ: “ਅਗਲਾ ਘੰਟਾ ਤੁਹਾਨੂੰ ਕਿਵੇਂ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਚਾਹੀਦਾ ਹੈ?” ਉਹ "ਸ਼ਾਂਤ" ਚੁਣਦਾ ਹੈ ਅਤੇ ਇੱਕ ਛੋਟੀ ਵਿੰਡ-ਡਾਊਨ ਰੁਟੀਨ ਵੱਲ ਸੁਇਚ ਕਰ ਲੈਂਦਾ ਹੈ।
ਉਪਭੋਗਤਾ ਦੇ ਮਹਿਸੂਸ ਕਰਨ ਵਾਲੀ ਬਦਲਾਅ ਵਜੋਂ ਸਫਲਤਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਫੀਚਰ ਕ੍ਰੀਪ ਤੋਂ ਬਚਣ ਲਈ ਸਪੱਸ਼ਟ ਹੋਵੋ:
ਜੇ ਉਪਭੋਗਤਾ ਹਰ ਚੈਕ-ਇਨ 'ਤੇ 10 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਕੀਮਤ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਠੀਕ ਕਿਸਮ ਦੀ ਸਧਾਰਣਤਾ ਬਣਾ ਰਹੇ ਹੋ।
ਇੱਕ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਲਈ MVP "ਛੋਟਾ ਐਪ" ਨਹੀਂ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦਾ ਇਕ ਵਾਅਦਾ ਹੈ ਜੋ ਹਰ ਰੋਜ਼ ਪੂਰਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡਾ ਲਕਸ਼ ਹੈ ਕਿਸੇ ਨੂੰ ਸਮਾਂ ਨੋਟਿਸ ਕਰਨ, ਇਕ ਛੋਟਾ ਫੈਸਲਾ ਕਰਨ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸਾਫ਼ ਮਹਿਸੂਸ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਾ—ਉਦੇਸ਼ੀਤਾ ਤੇਜ਼ੀ ਜਾਂ ਬਹੁਤ ਸੈਟਅਪ ਦੀ ਲੋੜ ਬਿਨਾਂ।
ਫੀਚਰਾਂ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਨਤੀਜੇ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਉਪਭੋਗਤਾ 30 ਸਕਿੰਟ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:
ਜੇ ਕੋਈ ਵਿਚਾਰ ਸਿੱਧਾ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਨਤੀਜਿਆਂ ਵਿੱਚ ਸੁਧਾਰ ਨਹੀਂ ਲਿਆਉਂਦਾ, ਤਾਂ ਉਹ MVP ਵਿੱਚ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਇਕਲੌਤਾ ਲੂਪ ਚੁਣੋ ਅਤੇ ਹਰ ਚੀਜ਼ ਨੂੰ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰੋ:
Prompt → quick action → feedback
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਲੂਪ ਇੱਕ ਹੱਥ ਨਾਲ, 10 ਸਕਿੰਟ ਤੋਂ ਘੱਟ, ਬਿਨਾਂ ਆਵਾਜ਼ ਦੇ ਪੂਰਾ ਹੋ ਸਕਦਾ ਹੋਵੇ।
ਰਿਟੇਨਸ਼ਨ ਲਈ ਗੇਮੀਫਿਕੇਸ਼ਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਚੁਣੋ:
ਦੋਹਾਂ ਨੂੰ ਮਿਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ MVP ਵਰਜਨ ਨੂੰ ਘੱਟ ਰੱਖੋ: ਇੱਕ ਸਕ੍ਰੀਨ ਜੋ ਪ੍ਰਗਟੀ ਨੂੰ ਹਕੀਕਤ محسوس ਕਰਵਾਏ।
ਸਪਸ਼ਟਤਾ ਜਲਦੀ ਕੈਪਚਰ ਕਰਨ ਲਈ ਇਕ-ਪੰਨੇ ਦਾ PRD ਬਣਾਓ:
ਜੇ ਤੁਸੀਂ MVP ਨੂੰ ਇਕ-ਪੰਨੇ 'ਤੇ ਵੇਰਵਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਲੂਪ ਅਜੇ ਤਿੱਖਾ ਨਹੀਂ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਉਦੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਕੁਝ "ਚੀਜ਼ਾਂ" ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਇਆ ਗਿਆ ਹੋਵੇ ਜੋ ਉਪਭੋਗਤਾ ਬਣਾਉਂਦੇ, ਦੇਖਦੇ ਅਤੇ ਸੋਧਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕੋਰ ਐਨਟੀਟੀਆਂ ਸਪੱਸ਼ਟ ਰੱਖੋਗੇ, ਤਾਂ ਬਾਕੀ ਪੈਦਾ (ਸਕ੍ਰੀਨ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਐਨਾਲਿਟਿਕਸ) ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਵੇਗਾ।
ਉਹ ਮਾਡਲ ਚੁਣੋ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਵਰਤਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਟੈਗ, ਪ੍ਰੋਜੈਕਟ, ਗੋਲ, ਕੈਲੇਂਡਰ, ਜਾਂ ਜਟਿਲ ਰਿਪੋਰਟਾਂ ਜੋੜਨ ਦੀ ਸੋਚ ਰਹੇ ਹੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਬਾਅਦ ਲਈ ਰੱਖੋ। ਤੁਹਾਡੇ MVP ਨੂੰ ਤੇਜ਼ "record → reflect" ਲੂਪ ਦੀ ਲੋੜ ਹੈ।
ਤੁਹਾਡੀ ਪਹਿਲੀ ਸਫਲ ਚੈਕ-ਇਨ ਐਪ ਖੋਲ੍ਹਣ ਤੇ ਇੱਕ ਮਿੰਟ ਦੇ ਅੰਦਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਫਲੋ ਇਹ ਹੈ:
ਇਸ ਫਲੋ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਨਾਲ ਇੱਕ ਆਮ ਗਲਤੀ ਰੋਕੀ ਜਾ ਸਕਦੀ ਹੈ: ਸੈਟਿੰਗਸ, ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਉਸ ਵੇਲੇ ਬਨਾਉਣਾ ਜਦੋਂ ਉਪਭੋਗਤਾ ਅਸਾਨੀ ਨਾਲ ਮੁਢਲਾ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਗਰੈਨੂਲੈਰਟੀ ਸਭ ਕੁਝ ਬਦਲ ਦਿੰਦੀ ਹੈ: UI, ਰਿਮਾਈਂਡਰ, ਅਤੇ ਸਮਰੀਜ਼।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਸਮਝੌਤਾ ਇਹ ਹੈ ਕਿ ਡਿਫੋਲਟ ਤੇ ਵਿਆਪਕ ਬਲਾਕ ਦਿਓ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮਿੰਟਾਂ 'ਤੇ ਸਵਿੱਚ ਕਰਨ ਦਾ ਵਿਕਲਪ। ਜੇ ਤੁਸੀਂ ਮਿੰਟ-ਸਤਰ ਸਮਰਥਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਠੀਕ ਅੰਤ ਸਮਾਂ ਚੁਣਨ ਲਈ ਮਜ਼ਬੂਰ ਨਾ ਕਰੋ—"ਹੁਣ ਰੋਕੋ" ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ ਅਤੇ ਅੰਦਾਜ਼ਾ ਲਗਾਓ।
ਲੋਕ ਸਬਵੇ ਵਿੱਚ, ਕੰਧਾਂ ਵਾਲੀਆਂ ਇਮਾਰਤਾਂ ਵਿੱਚ ਜਾਂ ਬੈਟਰੀ-ਸੇਵਰ 'ਤੇ ਚੈਕ-ਇਨ ਕਰਨਗੇ। ਤੁਹਾਡਾ MVP ਮੂਲ ਰੂਪ ਵਿੱਚ ਫਲਾਈਨ-ਫਰਸਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਇਹ ਫੈਸਲੇ ਪਹਿਲਾਂ ਹੀ ਕੀਤੇ ਜਾਂ, ਤਾਂ ਤੁਹਾਡੀਆਂ "Core Features" ਇਚਿੱਕ ਇਛਾ-ਚਾਹ-ਸੂਚੀ ਤੋਂ ਬਦਲ ਕੇ ਇਕ ਸੁਤੰਤਰ, ਟੈਸਟ ਕਰਨ ਵਾਲੀ ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਦੀ ਸੈੱਟ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਨੂੰ ਇੱਕ ਤੇਜ਼ ਨਜ਼ਰ ਜਿਹਾ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੰਮ ਦੀ ਲਿਸਟ ਨਹੀਂ। ਸਭ ਤੋਂ ਵਧੀਆ UI ਪੈਟਰਨ ਹੈ: "ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ, ਫਿਰ ਤੁਸੀਂ ਖਤਮ"। ਹਰ ਸਕ੍ਰੀਨ 'ਤੇ ਵਿਕਲਪ ਘਟਾਓ, ਲੇਬਲ ਸਾਬਤ ਰੱਖੋ, ਅਤੇ ਵਿਜ਼ੂਅਲ ਸ਼ੋਰ ਤੋਂ ਬਚੋ ਜੋ ਉਪਭੋਗਤাকে ਦੂਜਾ-ਅਨੁਮਾਨ ਬਣਾਉਂਦੀ ਹੈ।
ਹੋਮ ਸਕ੍ਰੀਨ ਨੂੰ ਇੱਕ ਸ਼ਾਂਤ ਸਥਿਤੀ ਦਰਸ਼ਾਉਣ ਵਾਲੇ ਵਿਊ ਵੱਜੋਂ ਤਵਾਜੋ:
ਜੇ ਤੁਸੀਂ ਸੈਕੰਡਰੀ ਕਾਰਵਾਈਆਂ (ਹਿਸਟਰੀ, ਸੈਟਿੰਗਸ) ਜੋੜਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਛੋਟੇ ਅਤੇ ਸਥਿਰ ਰੱਖੋ—ਕੋਨਿਕ ਆਈਕਨ ਜਾਂ ਕੋਰਨਾਂ ਵਿੱਚ ਨਰਮ ਲੇਖ।
ਚੈਕ-ਇਨ ਸਕ੍ਰੀਨ ਇੱਕ ਟੈਪ ਨਾਲ ਪੂਰੀ ਹੋ ਸਕਦੀ ਹੈ:
ਦੋਸਤਾਨਾ ਮਾਈਕ੍ਰੋਕਾਪੀ ਵਰਤੋਂ ਜਿਵੇਂ "ਆਪਸ਼ਨਲ" ਜਾਂ "Skip" ਤਣਾਅ ਹਟਾਉਣ ਲਈ।
ਹਿਸਟਰੀ ਸਭ ਤੋਂ ਵਧੀਆ ਨਿਰਭਰਤਾ ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ: ਇੱਕ ਟਾਈਮਲਾਈਨ ਚੈਕ-ਇਨਸ ਜਾਂ ਇੱਕ ਕੈਲੇਂਡਰ ਡੌਟਸ ਲਈ। ਮੂਲ ਤੌਰ 'ਤੇ ਭਾਰੇ ਚਾਰਟਸ ਤੋਂ ਬਚੋ; ਇੱਕ ਸਪੱਸ਼ਟ "ਤੁਸੀਂ ਇਸ ਹਫ਼ਤੇ 4 ਵਾਰੀ ਚੈਕ-ਇਨ ਕੀਤਾ" ਯਕੀਨੀ ਕਰਨ ਲਈ ਕਾਫੀ ਹੈ।
ਸੈਟਿੰਗਸ ਛੋਟੀਆਂ ਅਤੇ ਸਾਫ਼ ਗਰੂਪ ਕੀਤੀਆਂ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ:
ਵੱਡੀ ਟਾਈਪ, ਉੱਪਯੁਕਤ ਸਪੇਸਿੰਗ, ਅਤੇ ਉੱਚ ਕੰਟ੍ਰਾਸਟ ਵਰਤੋ ਤਾਂ ਜੋ ਐਪ ਚਲਦਿਆਂ, ਯਾਤਰਾ ਕਰਦਿਆਂ ਜਾਂ ਮੀਟਿੰਗਾਂ ਦੇ ਵਿਚਕਾਰ ਵੀ ਕੰਮ ਕਰੇ। ਵੱਡੇ ਟੈਪ ਟਾਰਗਟ ਅਤੇ ਸਥਿਰ ਲੇਆਉਟ ਦਾ ਲਕਸ਼ ਰੱਖੋ ਤਾਂ ਕਿ ਗਲਤ-ਟੈਪ ਘੱਟ ਹੋਣ।
ਸਭ ਤੋਂ ਵਧੀਆ ਟੈਕ ਚੋਇਸ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਚਹੇ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕੇ, ਰੱਖ-ਰਖਾਅ ਕਰ ਸਕੇ ਅਤੇ ਪਾਲਿਸ਼ ਕਰ ਸਕੇ—ਬਿਨਾਂ ਵਿਘਨ ਦੇ। ਸ਼ੁਰੂਆਤੀ ਵਰਜਨ ਸਰਲਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿਉਂਦੇ ਹਨ: ਤੇਜ਼ ਸਕ੍ਰੀਨ, ਭਰੋਸੇਯੋਗ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਅਤੇ ਡੇਟਾ ਜੋ "ਅਚਾਨਕ" ਗਾਇਬ ਨਾ ਹੋਵੇ।
ਨੈਟਿਵ (Swift iOS ਲਈ, Kotlin Android ਲਈ) ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਹੈ ਜੇ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮ ਫੀਲ ਅਤੇ ਸਿਸਟਮ ਫੀਚਰਾਂ (ਨੋਟੀਫਿਕੇਸ਼ਨ, ਵਿਜੇਟਸ, Focus ਮੋਡ, ਅਕਸੈਸਬਿਲਿਟੀ) ਨਾਲ ਘੱਟ ਘਰਮੇ ਮਹਿਸੂਸ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।
ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ (Flutter ਜਾਂ React Native) ਇੱਕ ਵਧੀਆ ਫਿੱਟ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਕੋਡਬੇਸ ਅਤੇ ਤੇਜ਼ ਇਤਰੈਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ, ਖਾਸ ਕਰਕੇ ਛੋਟੀ ਟੀਮਾਂ ਲਈ।
ਅੰਤਰ-ਗੁਣ ਜਿੰਨਾਂ ਦੀ ਉਮੀਦ ਰੱਖੋ:
ਇੱਕ ਵਾਜਬ ਨਿਯਮ: ਜੇ ਤੁਹਾਡਾ MVP ਬਹੁਤ ਜ਼ਿਆਦਾ ਰਿਮਾਈਂਡਰ, ਬੈਕਗ੍ਰਾਊਂਡ ਵਿਹੇਵਿਅਰ, ਜਾਂ ਵਿਜੇਟਸ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਨੈਟਿਵ ਵੱਲ ਝੁਕੋ। ਜੇ MVP ਮੁੱਖ ਤੌਰ 'ਤੇ ਲਾਗਿੰਗ/ਚੈਕ-ਇਨ ਅਤੇ ਸਧਾਰਨ ਟਾਈਮਰ ਹੈ, ਤਾਂ ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਆਮ ਤੌਰ 'ਤੇ ਠੀਕ ਹੈ।
ਜੇ ਤੁਸੀਂ ਉਤਪਾਦ ਲੂਪ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਪਹਿਲਾਂ ਕਿ ਪੂਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਪਾਈਪਲਾਈਨ 'ਤੇ ਫੈਸਲਾ ਕਰੋ, ਤਾਂ "vibe-coding" ਪਹੁੰਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਟੀਮਾਂ ਨੂੰ ਵੈੱਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ-ਸਬੰਧਤ ਫੰਕਸ਼ਨैलਟੀ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਅਤੇ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ (ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ, ਡਿਪਲੋਇਮੈਂਟ, ਅਤੇ ਰੋਲਬੈਕ ਨਾਲ). ਇਹ ਖਾਸ ਕਰਕੇ ਤੁਹਾਡੇ ਡੇਟਾ ਮਾਡਲ (check-ins/sessions/reminders), ਸਮਰੀ ਸਕ੍ਰੀਨ ਅਤੇ ਐਡਮਿਨ ਟੂਲਿੰਗ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪਰਖਣ ਲਈ ਉਪਯੋਗੀ ਹੈ—ਫਿਰ ਜਦੋਂ ਲੂਪ ਸਕਿੱਕੀ ਹੋ ਜਾਏ, ਤਾਂ ਪ੍ਰੋਡਕਸ਼ਨ-ਗਰੇਡ ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਵੱਲ ਜਾਓ।
MVP ਲਈ, ਕੋਈ ਬੈਕਐਂਡ ਨਹੀਂ ਵਿਚਾਰ ਕਰੋ: ਸਭ ਕੁਝ ਡਿਵਾਈਸ 'ਤੇ ਸਟੋਰ ਕਰੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ export/import ਦਾ ਵਿਕਲਪ ਦਿਓ। ਇਸ ਨਾਲ ਲਾਗਤ, ਕਾਨੂੰਨੀ/ਪ੍ਰਾਇਵੇਸੀ ਸਤਹ ਅਤੇ ਫੇਲਿਅਰ ਪੁਆਇੰਟ ਘਟਦੇ ਹਨ।
ਜੇ ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਸਿੰਕ ਲਾਜ਼ਮੀ ਹੈ (ਮਲਟੀ-ਡਿਵਾਈਸ ਵਰਤੋਂ ਕੋਰ ਹੈ), ਤਾਂ ਇਸਨੂੰ ਘੱਟ ਰੱਖੋ: ਆਥੰਟੀਕੇਸ਼ਨ + ਸਧਾਰਨ ਕਲਾਉਡ ਸਟੋਰੇਜ਼ ਇਕ ਛੋਟੇ ਯੂਜ਼ਰ ਡੇਟਾਸੇਟ ਲਈ।
ਇੱਕ ਲੋਕਲ ਸਟੋਰ ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਕਮੇਟ ਕਰੋ:
ਰਿਮਾਈਂਡਰ ਉਹ ਪਲ ਹਨ ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਕਿਸੇ ਦੇ ਦਿਨ ਵਿੱਚ ਦਰਖ਼ਾਸ਼ਤ ਕਰਦੀ ਹੈ—ਇਸ ਲਈ ਇਹ ਨਰਮ ਧੱਕਾ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਲਗਾਤਾਰ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲਾ। ਮਕਸਦ ਜਾਗਰੂਕਤਾ ਨੂੰ ਸਹਾਇਤਾ ਦੇਣਾ ("ਕਿੰਨਾ ਸਮਾਂ ਹੋ ਗਿਆ? ਮੈਂ ਕੀ ਕਰਨਾ ਸੀ?") ਅਤੇ ਇਸੇ ਸਮੇਂ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾ ਸਕਣਾ।
ਇੱਕ ਚੰਗੀ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ ਕੁਝ ਤਰੀਕੇ ਚਾਹੀਦੇ ਹਨ ਜਿਹੜੇ ਚੈਕ-ਇਨ ਲਈ ਪ੍ਰਾਂਪਟ ਕਰਦੇ ਹਨ:
ਚਾਬੀ ਹੈ ਡਿਫੋਲਟ ਹਲਕਾ ਰੱਖਣਾ: ਇੱਕ ਜਾਂ ਦੋ ਰਿਮਾਈਂਡਰ/ਦਿਨ ਅਤੇ ਫਿਰ ਉਪਭੋਗਤਾ ਵਧਾਉਂਦਾ ਜੇ ਉਹ ਚਾਹੇ।
ਲੋਕ ਉਹ ਐਪ ਜੋ ਬਹੁਤ ਵਾਰੀ ਪਿੰਗ ਕਰਦੀਆਂ ਹਨ ਤੇ ਭਰੋਸਾ ਘਟਾ ਦਿੰਦੇ ਹਨ। ਨੋਟੀਫਿਕੇਸ਼ਨ ਓਵਰਲੋਡ ਰੋਕਣ ਲਈ ਕੰਟਰੋਲ ਸ਼ਾਮਲ ਕਰੋ:
ਇਹ ਵਿਕਲਪ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਣ-ਯੋਗ ਅਤੇ ਬਦਲਣ-ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ—ਇਕੋ ਸਕ੍ਰੀਨ 'ਤੇ ਜਿੱਥੇ ਰਿਮਾਈਂਡਰ ਕਨਫ਼ਿਗਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਨੋਟੀਫਿਕੇਸ਼ਨ ਟੈਕਸਟ ਛੋਟਾ, ਦੋਸਤਾਨਾ, ਅਤੇ ਅਗਲੇ ਕਦਮ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਦੋਸ਼ਣਾ-ਪੁਰੀ ਕਾਪੀ ਤੋਂ ਬਚੋ।
ਉਦਾਹਰਨ:
ਲੋਕਾਂ ਨੂੰ ਐਪ ਖੋਲ੍ਹੇ ਬਿਨਾਂ ਜਵਾਬ ਦੇਣ ਦਿਓ:
ਜੇ ਤੁਸੀਂ ਹੇਠਾਂ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਸਹੀ ਨਹੀਂ ਸਮਭਾਲਦੇ, ਰਿਮਾਈਂਡਰ ਅਜੀਬ ਤਰੀਕੇ ਨਾਲ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ:
ਫੀਡਬੈਕ ਲੂਪ ਹਨ ਜਿਹੜੇ ਇੱਕ ਸਧਾਰਨ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਨੂੰ ਸਹਾਇਕ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ, ਖਾਲੀ ਨਹੀਂ। ਟ੍ਰਿੱਕ ਇਹ ਹੈ ਕਿ ਫੀਡਬੈਕ ਛੋਟਾ, ਸਪਸ਼ਟ, ਅਤੇ ਵਿਕਲਪਕ ਹੋਵੇ—ਤਾਂ ਕਿ ਉਪਭੋਗਤਾ ਮਾਰਗਦਰਸ਼ਿਤ ਮਹਿਸੂਸ ਕਰਨ, ਪਰ ਅਦਾਲਤੀ ਨਹੀਂ।
ਹਰ ਕੋਰ ਐਕਸ਼ਨ ਨੂੰ ਇੱਕ ਸ਼ਾਂਤ ਪੁਸ਼ਟੀ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾਲ ਇੱਕ ਛੋਟੀ ਇਨਸਾਈਟ।
ਉਦਾਹਰਨ, ਇੱਕ mindful check-in ਜਾਂ ਪੂਰਾ ਹੋਇਆ ਫੋਕਸ ਸੈਸ਼ਨ ਦੇ ਬਾਅਦ:
ਇਨਸਾਈਟ ਤੱਥਿਕ ਅਤੇ ਹਲਕੀ ਰੱਖੋ। ਪਾਪਅੱਪਸ ਤੋਂ ਬਚੋ ਜੋ ਧਿਆਨ ਦੀ माँਗ ਕਰਦੇ ਹੋਣ ਜਾਂ ਵਾਧੂ ਟੈਪ ਮੰਗਦੇ ਹੋਣ।
ਰੋਜ਼ਾਨਾ ਅਤੇ ਹਫ਼ਤਾਵਾਰ ਸਮਰੀਜ਼ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਪੜ੍ਹੀਆਂ ਜਾ ਸਕਣ, ਸਧਾਰਨ ਮੈਟ੍ਰਿਕਸ ਨਾਲ—ਭਾਰੀ ਚਾਰਟਸ ਦੀ ਥਾਂ। ਸੋਚੋ:
ਇੱਕ ਛੋਟਾ ਵਾਕ ਜੋ ਨੰਬਰਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੋਵੇ ਜੋ ਨਿਰਪੱਖ ਹੋਆ: "ਤੁਸੀਂ ਹਫ਼ਤੇ ਦੌਰਾਨ ਦੇਰ ਨਾਲ ਸ਼ੁਰੂ ਕੀਤਾ।" ਜੇ ਤੁਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਤਾਂ ਨਾ ਕਹੋ।
ਸਟ੍ਰੀਕ ਮੋਟਿਵੇਟ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਦਬਾਅ ਵੀ ਬਣਾਉਂਦੇ ਹਨ। ਸਟ੍ਰੀਕ ਨੂੰ ਨਰਮ ਲਗਾਤਾਰਤਾ ਵਜੋਂ ਵਰਤੋ, ਨਾ ਕਿ ਇਕ ਖੇਡ:
ਇਸੇ ਤਰ੍ਹਾਂ ਉਪਭੋਗਤਾ ਉਹ ਲਕਸ਼ ਦਿਓ ਜੋ ਉਨ੍ਹਾਂ ਦੀ ਜ਼ਿੰਦਗੀ ਨਾਲ ਮਿਲਦੇ ਹਨ: ਲਚਕੀਲੇ ਸਮਾਂ-ਖਿੱਤੇ, ਕਸਟਮ ਟਾਈਮ ਵਿੰਡੋ, ਅਤੇ ਅਨੁਕੂਲ ਲਕਸ਼ (ਉਦਾਹਰਨ: "ਸਪੀੱਕ-ਬਲਾਕ: ਦਿਨ ਵਿੱਚ 2 ਫੋਕਸ ਬਲਾਕ" ). ਜਦ ਤੁਸੀਂ ਨੁਦ ਦਿੰਦੇ ਹੋ, ਤਦ ਵਿਕਲਪ ਸੁਝਾਓ—"ਕੀ ਤੁਸੀਂ ਇਹ ਰਿਮਾਈਂਡਰ 10:30 'ਤੇ ਟਰਾਂਸਫਰ ਕਰਨਾ ਚਾਹੋਗੇ?"—ਨਾ ਕਿ ਦੋਸ਼-ਪ੍ਰੇਰਿਤ ਸੁਨੇਹੇ।
ਮਕਸਦ ਏਹ ਹੈ ਕਿ ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ ਬਣੇ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਪੈਟਰਨ ਨੋਟਿਸ ਕਰਨ ਅਤੇ ਢੋਲਵਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇ, ਐਪ ਨੂੰ ਛੱਡਣਾ ਆਸਾਨ ਰਹੇ।
ਐਨਾਲਿਟਿਕਸ ਨੂੰ ਇੱਕ ਛੋਟੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ: ਕੀ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਵੈਲੂ ਪਾ ਰਹੇ ਹਨ? ਕਿਹੜੇ ਰਿਮਾਈਂਡਰ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਜ਼ਿਆਦਤੀਆਂ ਹਨ? ਉਪਭੋਗਤਾ ਕਿੱਥੇ ਛੱਡ ਰਹੇ ਹਨ? ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਕੋਈ ਮੈਟ੍ਰਿਕ ਕਿਸ ਫੈਸਲੇ ਨੂੰ ਸਹਾਰਤ ਦੇਵੇਗੀ, ਤਾਂ ਉਸਨੂੰ ਟਰੈਕ ਨਾ ਕਰੋ।
ਇੱਕ ਸਧਾਰਨ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਲਈ, ਉਪਯੋਗੀ "ਇਵੈਂਟ ਡੇਟਾ" ਘੱਟ ਰਹਿ ਸਕਦਾ ਹੈ:
set_reminder, check_in, snooze, dismiss)ਮੁਫ਼ਤ-ਫਾਰਮ ਟੈਕਸਟ, ਸੰਪਰਕ ਸੂਚੀਆਂ, ਟਿਕਾਣਾ ਜਾਂ ਕੋਈ ਅਜਿਹੀ ਚੀਜ਼ ਜੋ ਉਪਭੋਗਤਾ ਦੀ ਪਛਾਣ ਖੋਲ ਸਕੇ, ਸਿਵਾਏ ਜਰੂਰਤ ਦੇ ਇਕੱਤਰ ਕਰਨ ਤੋਂ ਬਚੋ।
ਇੱਕ ਛੋਟੀ ਸੂਚੀ ਚੁਣੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਹਫ਼ਤੇ ਵਾਰੀ ਵੇਖ ਸਕੋ:
ਇਹ ਮੈਟ੍ਰਿਕਸ ਦੱਸਦੇ ਹਨ ਕਿ ਰਿਮਾਈਂਡਰ ਆਦਤ ਬਣਾਉਂਦੇ ਹਨ—ਜਾਂ ਘੜਕੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਨ ਫੰਨੇਲ ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਨਿਰੰਤਰ ਰੱਖੋ:
Install → first reminder created → first reminder delivered → first check-in
ਜੇ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾ "created" ਅਤੇ "delivered" ਦਰਮਿਆਨ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪਰਵਾਨਗੀ ਜਾਂ ਸ਼ਡਿਊਲਿੰਗ ਮੁੱਦੇ ਹੋ ਸਕਦੇ ਹਨ। ਜੇ "delivered" ਉੱਚ ਹੈ ਪਰ "check-in" ਘੱਟ ਹੈ, ਤਾਂ ਰਿਮਾਈਂਡਰ ਦੀ ਸਮੱਗਰੀ ਜਾਂ ਸਮਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਮੁਸ਼ਕਲ ਹੈ।
ਡਿਫੋਲਟ ਤੌਰ 'ਤੇ ਅਜਾਣੇ IDs ਵਰਤੋਂ। ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ analytics ਲਈ opt-out ਦਿਓ, ਅਤੇ ਐਪ ਨੂੰ ਉਦੋਂ ਵੀ ਕਾਰਗਰ ਰੱਖੋ ਜਦ ਯੂਜ਼ਰ opt-out ਕਰਦੇ ਹਨ।
ਇੱਕ ਬੁਨਿਆਦੀ ਡੈਸ਼ਬੋਰਡ ਤੁਹਾਡੇ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਹਫ਼ਤੇ-ਦਰ-ਹਫ਼ਤੇ ਬਦਲਾਅ ਦਿਖਾਊਂਦਾ ਹੋਵੇ, ਅਤੇ ਪਰਯੋਗਾਂ ਲਈ ਇੱਕ ਛੋਟਾ ਨੋਟਸ ਖੇਤਰ (ਉਦਾਹਰਨ: "ਮੰਗਲਵਾਰ ਨੂੰ ਨਵਾਂ ਰਿਮਾਈਂਡਰ ਕਾਪੀ ਸ਼ਿਪ ਕੀਤਾ")। ਇਹ ਇਤਰੈਸ਼ਨ ਨੂੰ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਓਵਰਲੋਡ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਇੱਕ "ਸਰਲ" ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਅਗਲੇ ਸਮੇਂ ਵਿੱਚ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਇਹ ਪੜ੍ਹਨ ਵਿੱਚ ਔਖਾ ਹੋਵੇ, ਚਲਾਉਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹੋਵੇ, ਜਾਂ ਖੇਤਰਾਂ ਵਿੱਚ ਗਲਤ ਸਪੱਸ਼ਟ ਹੋਵੇ। ਅਕਸੈਸਬਿਲਿਟੀ ਅਤੇ ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਕੋਰ ਫੰਕਸ਼ਨਾਲਟੀ ਵਜੋਂ ਮਨੋ, ਨਾ ਕਿ ਬਸ ਪਾਲਿਸ਼।
ਡਾਇਨਾਮਿਕ ਟਾਈਪ ਅਤੇ ਵੱਡੀ ਲੇਖ ਸਹਾਇਤਾ ਦਿਓ ਤਾਂ ਕਿ ਇੰਟਰਫੇਸ ਫਟਕੇ ਹੋਣ 'ਤੇ ਵੀ ਟੁੱਟੇ ਨਾ। ਲੇਆਉਟ ਲਚਕੀਲੇ ਰੱਖੋ: ਬਟਨ ਵਧਣ ਯੋਗ ਹੋਣ, ਲੇਬਲ ਲਪੇਟ ਸਕਣ, ਅਤੇ ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਹਮੇਸ਼ਾ ਹਾਸਲ ਕਰਨ-ਯੋਗ ਰਹਿਣ।
ਉੱਚ ਕਨਟ੍ਰਾਸਟ ਵਰਤੋਂ ਅਤੇ ਰੰਗ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ (ਉਦਾਹਰਨ: "overdue" ਸਿਰਫ ਲਾਲ ਨਾ ਦਿਖਾਓ ਬਿਨਾਂ ਆਈਕਨ ਜਾਂ ਲੇਬਲ ਦੇ)। ਹਰ ਇੰਟਰਐਕਟਿਵ ਤੱਤ ਨੂੰ ਸਪੱਸ਼ਟ, ਵੇਰਵਾ ਦਿੰਦਾ ਸ್ಕਰੀਨ-ਰੀਡਰ ਲੇਬਲ ਚਾਹੀਦਾ—ਖਾਸ ਕਰਕੇ ਕਸਟਮ ਕੰਟਰੋਲ ਜਿਵੇਂ ਟਾਈਮ ਪਿਕਰ, "quiet hours" ਟੌਗਲ, ਅਤੇ "snooze" ਕਾਰਵਾਈਆਂ।
ਸਮਾਂ ਖੇਤਰ ਅਤਿ-ਖੇਤਰਿਅਲ ਹੁੰਦੇ ਹਨ। ਡਿਵਾਈਸ ਸੈਟਿੰਗਸ ਦੀ ਪਾਲਣਾ ਕਰੋ 12/24-ਘੰਟੇ ਦੇ ਫਾਰਮੈਟ, ਹਫ਼ਤੇ ਦਾ ਪਹਿਲਾ ਦਿਨ, ਅਤੇ ਸਥਾਨਕ ਮਿਤੀ ਫਾਰਮੈਟ ਲਈ। "AM/PM" ਜਾਂ "Mon–Sun" ਵਰਗੇ ਸਟਰਿੰਗਜ਼ ਨੂੰ ਹਾਰਡ-ਕੋਡ ਨਾ ਕਰੋ। ਜਦੋਂ ਰੇਂਜ (ਉਦਾਹਰਨ: quiet hours) ਦਿਖਾਏ ਜਾਣ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਯੂਜ਼ਰ ਦੇ ਫਾਰਮੈਟ ਅਤੇ ਭਾਸ਼ਾ ਵਿੱਚ ਪੇਸ਼ ਕਰੋ।
ਟਾਈਮ-ਜ਼ੋਨ ਅਤੇ ਡੇਲਾਈਟ ਸੇਵਿੰਗ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ। ਟਾਈਮਸਟੈਂਪ ਇੱਕ ਸਥਿਰ ਫਾਰਮੈਟ (ਆਮ ਤੌਰ 'ਤੇ UTC) ਵਿੱਚ ਸਟੋਰ ਕਰੋ ਅਤੇ ਪ੍ਰੋਗਟ ਕਰਨ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਰੂਪਾਂਤਰ ਕਰੋ। ਜੇ ਯੂਜ਼ਰ ਯਾਤਰਾ ਕਰਦਾ ਹੈ, ਤਦ ਇਹ ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਕੀ ਰਿਮਾਈਂਡਰ ਮੌਜੂਦਾ ਸਥਾਨਕ ਸਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨਗੇ ਜਾਂ ਇੱਕ ਚੁਣਿਆ ਹੋਇਆ "ਘਰ" ਟਾਈਮਜ਼ੋਨ।
ਅਸਲੀ ਡਿਵਾਈਸਾਂ 'ਤੇ ਟੈਸਟ ਕਰੋ (ਕੇਵਲ simulator ਨਹੀਂ), ਜਿਸ ਵਿੱਚ ਘੱਟ ਬੈਟਰੀ ਮੋਡ ਅਤੇ ਖ਼ਰਾਬ ਕਨੈਕਟਿਵਿਟੀ ਸ਼ਾਮਲ ਹਨ। ਇਹ ਫ਼ਲੋਜ਼ end-to-end ਵੈਰੀਫਾਈ ਕਰੋ:
ਜੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਬੰਦ ਹਨ, ਤਦ ਸਿਰਫ਼ ਖਾਲੀ ਸਟੇਟ ਨਾ ਦਿਖਾਓ। ਦੱਸੋ ਕਿ ਕੀ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ, ਇੱਕ in-app ਵਿਕਲਪ ਦਿਓ (ਉਦਾਹਰਨ: ਸਕਰੀਨ 'ਤੇ ਚੈਕ-ਇਨ), ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ permissions ਮੁੜ-ਚਾਲੂ ਕਰਨ ਲਈ ਸਪੱਸ਼ਟ, ਗੈਰ-ਦੋਸ਼ਪੂਰਕ ਭਾਸ਼ਾ ਵਿੱਚ ਗਾਈਡ ਕਰੋ।
ਤੁਹਾਡੀ ਐਪ ਕੁਝ ਪਲਾਂ 'ਤੇ ਕਾਮਯਾਬ/ਨਾਕਾਮ ਹੁੰਦੀ ਹੈ: ਉਪਭੋਗਤਾ ਇਹ ਖੋਲ੍ਹਦਾ ਹੈ, ਛੋਟਾ ਚੈਕ-ਇਨ ਕਰਦਾ ਹੈ, ਅੱਜ ਦੀ ਸਥਿਤੀ ਸਮਝਦਾ ਹੈ, ਅਤੇ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਰਿਮਾਈਂਡਰ ਸਹਾਇਕ ਹਨ ਜਾਂ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲੇ। ਤੁਸੀਂ ਇਹ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਜ਼ਰੂਰਤ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟ ਕੋਡ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਹਲਕਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ ਜੋ ਕੋਰ ਲੂਪ ਨੂੰ ਨਕਲੀ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਏ: open → check-in → ਸਧਾਰਨ ਸਮਰੀ → ਰਿਮਾਈਂਡਰ ਸੈੱਟ/ਸਮਟ. ਫਿਰ 5–10 ਛੋਟੇ ਇੰਟਰਵਿਊ ਚਲਾਓ ਉਹਨਾਂ ਲੋਕਾਂ ਨਾਲ ਜੋ ਤੁਹਾਡੇ ਟਾਰਗਟ ਸਮੂਹ ਨਾਲ ਮਿਲਦੇ ਹਨ।
ਸੈਸ਼ਨ ਪ੍ਰਯੋਗਕਾਰੀ ਰੱਖੋ: ਉਨ੍ਹਾਂ ਨੂੰ ਕਾਰਜ ਪੂਰੇ ਕਰਨ ਲਈ ਕਹੋ ਅਤੇ ਸੋਚ-ਆਵਾਜ਼ ਵਿੱਚ ਰਹਿਣ ਦਿਓ। ਦੇਖੋ ਕਿ ਉਹ ਕਿੱਥੇ ਹਿਚਕਿਚਾਉਂਦੇ ਹਨ, ਕੀ ਉਨ੍ਹਾਂ ਨੇ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ, ਅਤੇ ਕਿਹੜੀ ਚੀਜ਼ ਉਹ ਟੈਪ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ ਜੋ ਟੈਪਯੋਗ ਨਹੀਂ।
ਆਪਣੇ ਪ੍ਰਸ਼ਨ ਅਤੇ ਨਿਰੀਖਣਾਂ ਨੂੰ ਹੇਠਾਂ ਆਧਾਰਿਤ ਰੱਖੋ:
ਜੇ ਉਪਭੋਗਤਾ ਸਮਰੀ ਆਪਣੀ ਭਾਸ਼ਾ ਵਿੱਚ ਨਹੀਂ ਦੱਸ ਸਕਦੇ, ਤਾਂ ਇਹ ਕਾਫੀ ਸਪਸ਼ਟ ਨਹੀਂ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਦੌਰ 'ਚ A/B ਟੈਸਟਿੰਗ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ। ਘੱਟ ਉਪਭੋਗਤਾ ਨਾਲ, ਨਤੀਜੇ ਸ਼ੋਰਦਾਰ ਹੋਣਗੇ ਅਤੇ ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ ਨੂੰ optimize ਕਰ ਸਕਦੇ ਹੋ। ਛੋਟੇ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਰੋਲਬੈਕ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਬਦਲਾਅ ਪ੍ਰਾਥਮਿਕਤਾ ਪਾਓ—ਕਾਪੀ ਟਵੀਕ, ਇਕ-ਸਕਰੀਨ ਲੇਆਉਟ ਬਦਲਾਅ, ਜਾਂ ਇੱਕ ਸਧਾਰਨ ਰਿਮਾਈਂਡਰ ਸੈਟਿੰਗ।
ਰਿਮਾਈਂਡਰ ਜਾਂ ਸਮਰੀ ਦੇ ਬਾਦ ਇਕ-ਪ੍ਰਸ਼ਨ ਵਾਲਾ ਫੀਡਬੈਕ ਸ਼ਾਮਲ ਕਰੋ:
"ਕੀ ਇਹ ਲਾਭਦਾਇਕ ਸੀ?"
ਇਖਲੋ-ਇੱਕ ਛੋਟਾ free-text ਨੋਟ ਵੇਖਣ ਦੀ ਆਗਿਆ ਦੇ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਰੋ।
ਹਰ ਦੌਰ ਦੇ ਬਾਅਦ, ਉਹ 3 ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲਿਖੋ ਜੋ ਕੋਰ ਲੂਪ ਨੂੰ ਰੋਕ ਰਹੀਆਂ ਹਨ। ਫਿਰ ਉਹਨਾਂ ਫੀਚਰਾਂ ਨੂੰ ਖੱਟੋ ਜੋ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀਆਂ। ਜੇ ਕੋਈ ਨਵਾਂ ਵਿਚਾਰ ਚੈਕ-ਇਨ ਦੀ ਤੇਜ਼ੀ, ਰਿਮਾਈਂਡਰ ਅਰਾਮ, ਜਾਂ ਸਮਰੀ ਸਪੱਸ਼ਟਤਾ ਵਿਚ ਸੁਧਾਰ ਨਹੀਂ ਲਿਆਉਂਦਾ, ਤਾਂ ਉਹ ਬਾਅਦ ਲਈ ਠਹਿਰੇ।
ਇੱਕ ਸਧਾਰਨ ਸਮਾਂ-ਜਾਗਰੂਕਤਾ ਐਪ ਲਾਂਚ ਕਰਨਾ ਜ਼ਿਆਦਾਤਰ ਭਰੋਸੇ ਬਾਰੇ ਹੈ: ਇਹ ਤੇਜ਼ ਖੁਲਣਾ, ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣਾ, ਅਤੇ ਰਿਮਾਈਂਡਰ ਜਿਸ ਸਮੇਂ ਕਿਹਾ ਉਹ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਕੱਟੜ ਚੈੱਕਲਿਸਟ ਤੁਹਾਨੂੰ "ਲਗਭਗ ਕੰਮ ਕਰ ਰਿਹਾ" ਬੇਚਣ ਤੋਂ ਬਚਾਂਵੇਗੀ।
ਤੁਹਾਡੇ ਸਕ੍ਰੀਨਸ਼ਾਟਸ ਐਪ ਨੂੰ ਸਕਿੰਟਾਂ ਵਿੱਚ ਸਿਖਾਉਣੇ ਚਾਹੀਦੇ ਹਨ। 3 ਫਰੇਮ ਲਈ ਲਕਸ਼ ਰੱਖੋ ਜੋ ਮੁੱਖ ਲੂਪ ਦੀ ਨਕਲ ਕਰਦੇ ਹਨ:
ਰਿਧਮ ਚੁਣੋ (ਉਦਾਹਰਨ: ਹਰ 60 ਮਿੰਟ ਚੈਕ-ਇਨ)
ਇੱਕ ਸ਼ਾਂਤ ਪ੍ਰਾਂਪਟ ਪ੍ਰਾਪਤ ਕਰੋ (ਨਰਮ ਨੁਦ, ਮੰਗ ਨਹੀਂ)
ਇੱਕ ਟੈਪ ਵਿੱਚ ਲਾਗ (ਉਦਾਹਰਨ, "On track / Behind / Break") ਅਤੇ ਜ਼ਿੰਦਗੀ ਵੱਲ ਵਾਪਸੀ
ਛੋਟੇ ਕੈਪਸ਼ਨਾਂ ਅਤੇ ਅਸਲੀ UI ਸਟੇਟਸ ਦਿਖਾਓ (ਲਾਕ ਸਕ੍ਰੀਨ ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਟਾਈਲ ਵੀ ਜੇ ਸਟੋਰ ਨਿਯਮ ਆਗਿਆ ਦਿੰਦੇ ਹਨ)।
ਪਹਿਲੇ ਸਕਰੀਨ 'ਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਦੀ ਆਗਿਆ ਨਾ ਮੰਗੋ। ਪਹਿਲਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਆਪਣੀ ਚੈਕ-ਇਨ ਸ਼ੈਲੀ ਚੁਣਨ ਦਿਓ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਦਾ ਪ੍ਰੀਵਿਊ ਦਿਖਾਓ। ਫਿਰ ਉਸ ਸਮੇਂ ਅਣੁਗ੍ਰਹਿ ਕਰੋ ਜਦੋਂ ਇਹ ਸਪੱਸ਼ਟ ਲਾਭਦਾਇਕ ਹੋ: "ਕੀ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਮੈਂ 3:00 ਨੂੰ ਤੁਹਾਨੂੰ ਨੁਦ ਕਰਾਂ?" ਜੇ ਉਹ ਨਾ ਕਹਿੰਦੇ, ਤਾਂ ਇੱਕ ਸ਼ਾਂਤ ਬੈਕਅੱਪ (in-app ਬੈਨਰ) ਦਿਓ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ enable ਕਰਨ ਦਾ ਰਾਹ ਦਿੱਓ।
ਸਪੱਸ਼ਟ ਰੱਖੋ:
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨ ਕਰੋ:
ਪਹਿਲੇ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਤਿੰਨ ਅਪਗ੍ਰੇਡ ਚੁਣੋ:
ਸਮਾਰਟ quieter hours (ਮੀਟਿੰਗਾਂ, ਨੀਂਦ ਵਿੰਡੋ)
ਵਧੇਰੇ ਲਚਕੀਲੇ ਸ਼ਡਿਊਲ (ਵਰਕਡੇਸ ਬਨਾਮ ਵੀਕਐਂਡ)
ਬਿਹਤਰ ਸਮਰੀਜ਼ (ਇੱਕ ਹਫ਼ਤਾਵਾਰ ਇਨਸਾਈਟ ਜੋ ਉਤਸ਼ਾਹਿਤ ਕਰੇ, ਨਾ ਕਿ ਨਿੰਦਾ)
ਛੋਟੀਆਂ ਅਪਡੇਟਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰੋ, ਅਤੇ ਕੋਰ ਲੂਪ ਨੂੰ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਬੇਨਤੀ ਕੀਤੀ ਹੈ।
"ਸਰਲ ਸਮੇਂ ਦੀ ਜਾਗਰੂਕਤਾ" ਭਾਰੀ ਰਿਕਾਰਡਿੰਗ ਨਹੀਂ, ਬਲਕਿ ਹਲਕੀ-ਫੁਲਕੀ ਧਿਆਨਦਾਰੀ ਹੈ। ਐਪ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਰੋਕ ਕੇ ਦੇਖਣ ਅਤੇ ਅਗਲੇ ਸਮੇਂ ਦੇ ਬਲਾਕ ਲਈ ਨਿਰਣਾ ਲੈਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ—ਅਮੂਮਨ ਇੱਕ ਛੋਟਾ ਚੈਕ-ਇਨ, ਇੱਕ ਛੋਟੀ ਟਾਈਮਰ ਅਤੇ ਇੱਕ ਨਿੱਕੀ ਸੋਚ-ਵਿਚਾਰ ਨਾਲ।
ਇਹ ਉਨ੍ਹਾਂ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜੋ ਬਹੁਤ ਵਿਆਸਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਪਰ ਨਹੀਂ ਸਮਝ ਪਾਉਂਦੇ ਕਿ ਘੰਟੇ ਕਿੱਥੇ ਚਲੇ ਗਏ—ਖਾਸ ਕਰਕੇ:
ਇੱਕ ਤੰਗ MVP ਲੂਪ ਹੈ:
ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਇੱਕ ਹੱਥ ਨਾਲ 10 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ MVP ਲਈ ਭਾਰੀ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ 3–5 ਐਨਟੀਟੀਆਂ ਨਾਲ ਜੋ ਸਾਦਗੀ ਨਾਲ ਸਮਝਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ:
V1 ਵਿੱਚ ਪ੍ਰੋਜੈਕਟ/ਟੈਗ/ਗੋਲਜ਼ ਨਹੀਂ ਜੋੜੋ ਜੇਕਰ ਉਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਚੈਕ-ਇਨ ਲੂਪ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕਰਦੇ।
ਡਿਫੋਲਟ ਤੌਰ 'ਤੇ ਵਿਸ਼ਾਲ ਬਲੌਕ (broad blocks) ਜ਼ਿਆਦਾ ਚੰਗੇ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸ਼ਾਂਤ ਅਤੇ ਅਸਾਨੀ ਨਾਲ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕਾਇਮ ਰਹਿੰਦੇ ਹਨ। ਬਾਅਦ ਵਿੱਚ ਜੋ précision ਚਾਹੀਦੀ ਹੋਵੇ ਉਹ ਦੇਣ ਦੀ ਵਿਕਲਪ ਦਿਓ।
ਵਿਆਵਹਾਰਿਕ ਸਮਝੌਤਾ:
ਪਹਿਲੀ ਕਾਮਯਾਬ ਚੈਕ-ਇਨ ਇਕ ਮਿੰਟ ਦੇ ਅੰਦਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:
ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਸੈਟਿੰਗਸ ਨੂੰ ਪਹਿਲੇ ਚੈਕ-ਇਨ ਤੋਂ ਪਹਿਲਾਂ ਨਹੀਂ ਰੱਖੋ।
ਇੱਕ “ਕੈਲਮ ਡੈਸ਼ਬੋਰਡ” ਪੈਟਰਨ ਵਰਤੋਂ:
ਚੈਕ-ਇਨ ਲਈ: ਇੱਕ ਸਵਾਲ, ਵੱਡੇ ਟੈਪ ਟਾਰਗੇਟ ਅਤੇ ਇੱਕ ਆਪਸ਼ਨਲ ਨੋਟ ਜਿਹੜਾ ਟੈਪ ਕਰਕੇ ਖੁੱਲਦਾ ਹੈ।
ਹੌਲੀ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਆਸਾਨ ਇਗਨੋਰ ਕਰਨ ਯੋਗ ਬਣਾਓ:
ਨਰਮ, ਦੋਸਤਾਨਾ ਕਾਪੀ ਲਿਖੋ (ਜਿਵੇਂ, “Quick check-in: what are you doing right now?”)।
ਹਾਂ—MVP ਲਈ offline-first ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੈ:
ਜੇਕਰ ਕੁਝ ਫੀਚਰ ਮਲਟੀ-ਡਿਵਾਈਸ ਲਈ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹਨ, ਤਾਂ ਉਹ imply ਨਾ ਕਰੋ।
ਕੇਵਲ ਉਹੀ ਟਰੈਕ ਕਰੋ ਜੋ ਸਪੱਸ਼ਟ ਉਤਪਾਦ ਫੈਸਲੇ ਸਹਾਇਕ ਹੋਵੇ:
check_in, set_reminder, snooze, dismissਮੁਫ਼ਤ-ਫਾਰਮ ਟੈਕਸਟ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਤੋਂ ਬਚੋ। ਯੂਜ਼ਰ ਨੂੰ analytics ਤੋਂ opt-out ਕਰਨ ਦਾ ਵਿਕਲਪ ਦਿਓ ਅਤੇ ਐਪ ਉਹਨਾਂ ਬਿਨਾਂ ਵੀ ਕੰਮ ਕਰੇ।