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

ਸਕੈਚ ਸਕ੍ਰੀਨਾਂ ਬਣਾਉਣ ਜਾਂ ਐਲਗੋਰਿਦਮ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੇ ਐਪ ਦੇ ਸਿੱਖਣ ਕੰਮ ਬਾਰੇ ਸਹੀ ਤੌਰ 'ਤੇ ਸੋਚੋ। “ਨਿੱਜੀ ਸਿੱਖਣ ਪਾਥ” ਕਈ ਮਤਲਬ ਰਖ ਸਕਦੇ ਹਨ—ਅਤੇ ਬਿਨਾਂ ਸਪਸ਼ਟ ਲਕੜੀ ਦੇ ਤੁਸੀਂ ਐਸੇ ਫੀਚਰ ਬਣਾਓਗੇ ਜੋ ਸਿਆਣੇ ਲੱਗਦੇ ਹਨ ਪਰ ਲਰਨਰਾਂ ਨੂੰ ਨਤੀਜਿਆਂ ਵੱਲ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਲੈ ਜਾਂਦੇ।
ਮੁੱਖ ਯੂਜ਼ ਕੇਸ ਸਿੱਧਾ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਇੱਕ ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਉਸ ਵੇਲੇ ਕਾਮਯਾਬ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ “ਮੈਂ X ਸਿੱਖਣਾ ਚਾਹੁੰਦਾ ਹਾਂ” ਅਤੇ “ਮੈਂ X ਕਰ ਸਕਦਾ ਹਾਂ” ਦਰਮਿਆਨ ਦੀ ਘਿਸੱਟ ਘਟਾਉਂਦਾ ਹੈ। ਇੱਕ ਵਾਕ ਦਾ ਵਾਅਦਾ ਲਿਖੋ ਅਤੇ ਹਰ ਫੀਚਰ ਬੇਨਤੀ ਨੂੰ ਉਸ ਵਾਅਦੇ ਨਾਲ ਫਿਲਟਰ ਕਰੋ।
ਤੁਹਾਡੀ ਦਰਸ਼ਕ ਸਾਰੇ ਲਰਨਿੰਗ ਪਾਥ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। K–12 ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਛੋਟੇ ਸੈਸ਼ਨਾਂ, ਵੱਧ ਮਦਦ ਅਤੇ ਮਾਪੇ/ਅਧਿਆਪਕ ਦੀ ਦਿੱਖ ਚਾਹੀਦੀ ਹੋ ਸਕਦੀ ਹੈ। ਬਾਲਗ ਲਰਨਰ ਅਕਸਰ ਖੁਦਮੁਖਤਿਆਰਤਾ ਅਤੇ ਤੁਰੰਤ ਪ੍ਰਸੰਗਿਕਤਾ ਚਾਹੁੰਦੇ ਹਨ। ਕਾਰਪੋਰੇਟ ਲਰਨਰਾਂ ਨੂੰ ਅਕਸਰ కంపਲਾਇੰਸ ਟਰੈਕਿੰਗ ਅਤੇ ਮਾਸਟਰੀ ਦਾ ਸਾਫ਼ ਪ੍ਰਮਾਣ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਦੇ ਨਾਲ ਉਪਯੋਗ ਦੇ ਪ੍ਰਸੰਗ ਨੂੰ ਵੀ ਤੈਅ ਕਰੋ: ਕਮਿਊਟਿੰਗ, ਘੱਟ ਬੈਂਡਵਿਡਥ, ਆਫਲਾਈਨ-ਪਹਿਲਾ, ਸਾਂਝੇ ਜੰਤਰ ਜਾਂ ਸਖ਼ਤ ਪ੍ਰਾਈਵੇਸੀ ਲੋੜਾਂ। ਇਹ ਸੀਮਾਵਾਂ ਸਮੱਗਰੀ ਫਾਰਮੈਟ, ਸੈਸ਼ਨ ਦੀ ਲੰਬਾਈ ਅਤੇ ਮੁਲਾਂਕਣ ਦੀ ਸ਼ੈਲੀ ਨੂੰ ਰੂਪ ਦਿੰਦੀਆਂ ਹਨ।
“ਕਾਮਯਾਬ” ਦਿਖਣ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰੋ। ਅਨੁਕੂਲ ਸਿੱਖਣ ਲਈ ਉਪਯੋਗੀ ਮੈਟ੍ਰਿਕਸ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ:
ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸਿਰਫ਼ ਐਂਗੇਜ਼ਮੈਂਟ ਨਾਂ ਬਣਾਓ—ਅਸਲ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜੋ।
ਜਿਨ੍ਹਾਂ ਲੀਵਰਾਂ ਨੂੰ ਤੁਸੀਂ ਨਿੱਜੀਕਰਨ ਲਈ ਵਰਤੋਂਗੇ ਉਹਨਾਂ ਬਾਰੇ ਵਿਸ਼ੇਸ਼ ਬਣੋ:
ਇਸ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਨਿਯਮ ਵਜੋਂ ਲਿਖੋ: “ਅਸੀਂ ___ ਨੂੰ ___ ਦੇ ਆਧਾਰ 'ਤੇ ਨਿੱਜੀਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਲਰਨਰ ___ ਹਾਸਲ ਕਰਨ।” ਇਹ ਤੁਹਾਡੀ ਸਿੱਖਿਆ ਐਪ ਵਿਕਾਸ ਨੂੰ ਫੋਕਸਡ ਅਤੇ ਮਾਪਯੋਗ ਰੱਖਦਾ ਹੈ।
ਨਿੱਜੀ ਸਿੱਖਣ ਪਾਥ ਤਦ ਹੀ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਸਪਸ਼ਟ ਹੋ ਕਿ ਕੌਣ ਸਿੱਖ ਰਿਹਾ ਹੈ, ਉਹ ਕਿਉਂ ਸਿੱਖ ਰਿਹਾ ਹੈ, ਅਤੇ ਉਸ ਦੀ ਰਾਹ ਵਿੱਚ ਕੀ ਰੁਕਾਵਟ ਆ ਰਹੀ ਹੈ। ਐਪ ਦੇ ਪਹਿਲੇ ਵਰਜ਼ਨ ਲਈ ਹਕੀਕਤ-ਆਧਾਰਤ ਕੁਝ ਲਰਨਰ ਪ੍ਰੋਫਾਈਲ ਦਿੱਠੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹੋ।
2–4 ਪੇਰਸੋਨਾਜ਼ ਦਾ ਲਕੜੀ ਰੱਖੋ ਜੋ ਅਸਲ ਮੋਟਿਵੇਸ਼ਨ ਅਤੇ ਪ੍ਰਸੰਗ ਦਰਸਾਉਂਦੇ ਹੋਣ (ਸਿਰਫ ਡੈਮੋਗ੍ਰਾਫਿਕਸ ਨਹੀਂ)। ਉਦਾਹਰਨ:
ਹਰ ਪੇਰਸੋਨਾ ਲਈ ਕੈਪਚਰ ਕਰੋ: ਮੁੱਖ ਲਕੜੀ, ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ (ਉਦਾਹਰਨ: ਪਾਸ ਕਰਨਾ, ਪ੍ਰੋਜੈਕਟ ਪੂਰਾ ਕਰਨਾ), ਆਮ ਸੈਸ਼ਨ ਲੰਬਾਈ, ਅਤੇ ਕੀ ਉਹਨੂੰ ਛੱਡਣ 'ਤੇ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।
ਨਿੱਜੀਕਰਨ ਇਨਪੁੱਟ ਮੰਗਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਉਹੀ ਘੱਟੋ-ਘੱਟ ਜਾਣਕਾਰੀ ਲਵੋ ਜੋ ਮੁੱਲ ਦੇ ਸਕੇ। ਸਧਾਰਨ, ਉਪਯੋਗੀ ਡਾਟਾ ਪੁਆਇੰਟਾਂ:
ਹਰ ਆਈਟਮ ਲਈ ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ ਕਿਉਂ ਮੰਗਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਗੈਰ-ਜ਼ਰੂਰੀ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਛੱਡਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ।
ਸੀਮਾਵਾਂ ਪਾਥ ਨੂੰ ਉਤਨਾ ਹੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ ਜਿੰਨਾ ਕਿ ਲਕੜੀਆਂ। ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜੀ ਚੀਜ਼ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਹੈ:
ਇਹ ਫੈਕਟਰ ਪਾਠ ਦੀ ਲੰਬਾਈ ਤੋਂ ਲੈ ਕੇ ਡਾਊਨਲੋਡ ਆਕਾਰ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਰਣਨੀਤੀ ਤੱਕ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਇੰਸਟਰਕਟਰ, ਮੈਨੇਜਰ ਜਾਂ ਮਾਪੇ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਪਹਿਲਾਂ ਅਨੁਮਤੀਆਂ ਨਿਰਧਾਰਿਤ ਕਰੋ:
ਸਪਸ਼ਟ ਭੂਮਿਕਾਵਾਂ ਪ੍ਰਾਈਵੇਸੀ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਸਹੀ ਸਕ੍ਰੀਨ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ।
ਨਿੱਜੀ ਸਿੱਖਣ ਪਾਥ ਤਦ ਹੀ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਸਮੱਗਰੀ ਨੂੰ ਇਸ ਅਧਾਰ 'ਤੇ ਸੰਗਠਿਤ ਕਰੋ ਕਿ ਲਰਨਰ ਜੋ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ—ਨਾ ਕਿ ਸਿਰਫ ਕੀ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ। ਸਪਸ਼ਟ ਨਤੀਜੇ (ਉਦਾਹਰਨ: “ਮੁਢਲਾ ਗੱਲਬਾਤ ਕਰੋ”, “ਰੇਖੀ ਸਮੀਕਰਨ ਹੱਲ ਕਰੋ”, “ਇੱਕ SQL ਕ્વੈਰੀ ਲਿਖੋ”) ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਫਿਰ ਹਰ ਨਤੀਜੇ ਨੂੰ ਸਕਿੱਲ ਅਤੇ ਉਪ-ਸਕਿੱਲ ਵਿੱਚ ਵੰਡੋ।
ਇੱਕ ਸਕਿੱਲ ਮੈਪ ਬਣਾਓ ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਧਾਰਨਾਵਾਂ ਕਿਵੇਂ ਜੁੜੀਆਂ ਹਨ। ਹਰ ਸਕਿੱਲ ਲਈ ਪ੍ਰੀ-ਰਿਕਵਾਇਰਮੈਂਟ ਨੋਟ ਕਰੋ ਤਾਂ ਕਿ ਤੁਹਾਡੀ ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਅਗੇ ਵਧਣ ਜਾਂ ਰੀਮੀਡੀਏਟ ਕਰਨ ਦੌਰਾਨ ਅਨੁਮਾਨ ਨਾ ਲਗਾਏ।
ਇੱਕ ਸਧਾਰਨ ਢਾਂਚਾ ਜੋ ਲਰਨਿੰਗ ਪਾਥ ਡਿਜ਼ਾਈਨ ਲਈ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:
ਇਹ ਮੈਪ ਅਡਾਪਟਿਵ ਲਰਨਿੰਗ ਲਈ ਰੀੜ੍ਹ ਹੈ: ਇਹ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪ ਅਗਲਾ ਸੁਝਾਅ ਕਰਨ ਲਈ ਵਰਤਦੀ ਹੈ।
“ਲੈਸਨ” ਹੀ ਸਭ ਕੁਝ ਬਣਾਉਣ ਤੋਂ ਬਚੋ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਮਿਸ਼ਰਣ ਵੱਖ-ਵੱਖ ਪਲਾਂ ਲਈ ਸਹਾਇਕ ਹੁੰਦੀ ਹੈ:
ਸਰਵੋਤਮ ਨਿੱਜੀ ਪਾਥ ਅਕਸਰ ਅਭਿਆਸ 'ਤੇ ਭਾਰੀ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਸਮਝਾਓ ਜਦੋਂ ਲਰਨਰ ਸੰਘਰਸ਼ ਕਰਦੇ ਹਨ ਪਹੁੰਚਯੋਗ ਹੋਣਗੇ।
ਸਮੱਗਰੀ ਸਿਫਾਰਿਸ਼ਾਂ ਯੋਗ ਬਣਾਉਣ ਲਈ, ਹਰ ਸਮੱਗਰੀ ਟੁਕੜੇ ਨੂੰ ਲਗਾਤਾਰ ਟੈਗ ਕਰੋ:
ਇਹ ਟੈਗ ਖੋਜ, ਫਿਲਟਰ ਅਤੇ ਪ੍ਰਗਤੀ ਟਰੈਕਿੰਗ ਨੂੰ ਭਵਿਖ ਵਿੱਚ ਸੁਧਾਰਦੇ ਹਨ।
ਸਿੱਖਿਆ ਐਪ ਵਿਕਾਸ ਕਦੇ "ਮੁਕੰਮਲ" ਨਹੀਂ ਹੁੰਦਾ। ਸਮੱਗਰੀ ਗਲਤੀਆਂ ਫਿਕਸ ਹੋਣ, ਮਿਆਰ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਜਾਂ ਸਪਸ਼ਟਤਾ ਸੁਧਾਰਨ ਨਾਲ ਬਦਲੇਗੀ। ਵਰਜ਼ਨਿੰਗ ਜਲਦੀ ਤੋਂ ਜਲਦੀ ਯੋਜਨਾ ਕਰੋ:
ਇਸ ਨਾਲ ਗਲਤ ਪ੍ਰਗਤੀ ਰੀਸੈਟ ਤੋਂ ਬਚਾਵ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਐਨਾਲਿਟਿਕਸ ਅਰਥਪੂਰਕ ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਡੀ ਲਾਇਬ੍ਰੇਰੀ ਵੱਡੀ ਹੁੰਦੀ ਹੈ।
ਮੁਲਾਂਕਣ ਨਿੱਜੀ ਸਿੱਖਣ ਪਾਥ ਦਾ ਸਟੀਅਰਿੰਗ ਵੀਲ ਹਨ: ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਲਰਨਰ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਕੀ ਅਭਿਆਸ ਕਰੇਗਾ, ਅਤੇ ਕਦੋਂ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ। ਮਕਸਦ ਟੈਸਟ ਲਈ ਟੈਸਟ ਨਹੀਂ—ਇਹੋ ਜ਼ਰੂਰੀ ਸਿਗਨਲ ਇਕੱਠਾ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਅਗਲਾ ਕਦਮ ਚੰਗਾ ਹੋਵੇ।
ਛੋਟੇ ਆਨਬੋਰਡਿੰਗ ਮੁਲਾਂਕਣ ਨਾਲ ਲਰਨਰਾਂ ਨੂੰ ਸਹੀ ਐਂਟਰੀ ਪੌਇੰਟ ਤੇ ਰੱਖੋ। ਇਸਨੂੰ ਉਹ ਸਕਿੱਲਾਂ 'ਤੇ ਕੇਂਦਰਤ ਰੱਖੋ ਜੋ ਸੱਚਮੁੱਚ ਅਨੁਭਵ ਨੂੰ ਵੱਖ ਵੱਖ ਕਰਦੀਆਂ ਹਨ (ਪ੍ਰੀ-ਰਿਕਵਾਇਰਮੈਂਟ ਅਤੇ ਕੋਰ ਧਾਰਣਾਵਾਂ), ਨਾ ਕਿ ਸਭ ਕੁਝ ਜੋ ਤੁਸੀਂ ਪੜ੍ਹਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਪੈਟਰਨ 6–10 ਸਵਾਲ (ਜਾਂ 2–3 ਛੋਟੇ ਟਾਸਕ) ਹੈ ਜੋ ਕਈ ਮੁਸ਼ਕਿਲੀ ਪੱਧਰਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਜੇ ਲਰਨਰ ਸ਼ੁਰੂਆਤ ਦੇ ਆਈਟਮਾਂ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਅੱਗੇ ਸਕਿਪ ਕਰ ਸਕਦੇ ਹੋ; ਜੇ ਉਹ ਸੰਘਰਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਜਲਦੀ ਰੁਕ ਸਕਦੇ ਹੋ ਅਤੇ ਇਕ ਨਰਮ ਸ਼ੁਰੂਆਤੀ ਮੋਡੀਊਲ ਸੁਝਾ ਸਕਦੇ ਹੋ। ਇਹ “ਅਡੈਪਟਿਵ ਪਲੇਸਮੈਂਟ” ਨਿਰਾਸ਼ਾ ਅਤੇ ਸਮੇਂ-ਟੂ-ਵੈਲਯੂ ਘਟਾਉਂਦੀ ਹੈ।
ਆਨਬੋਰਡਿੰਗ ਤੋਂ ਬਾਅਦ, ਵੱਡੀਆਂ ਇਮਤਿਹਾਨਾਂ ਦੀ ਥਾਂ ਤੇਜ਼, ਅਕਸਰ ਚੈੱਕਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰੋ:
ਇਹ ਚੈੱਕ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਲਗਾਤਾਰ ਪਾਥ ਅਪਡੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ—ਬਿਨਾਂ ਲਰਨਰ ਦੇ ਫਲੋ ਨੂੰ ਰੋਕੇ।
ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਵਿਜ਼ ਐਪ ਨੂੰ ਦੰਡਕਾਰੀ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੇ ਹਨ। ਮੁਲਾਂਕਣ ਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਅਤੇ ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਕੁਝ ਵਿਕਲਪਿਕ ਰੱਖੋ:
ਜਦੋਂ ਲਰਨਰ ਕਿਸੇ ਧਾਰਨਾ 'ਚ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪਾਥ ਪ੍ਰਤਿਕਾਰ ਤਰੀਕੇ ਨਾਲ ਜਵਾਬ ਦੇਵੇ:
ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਛੋਟਾ ਰੀਮੀਡਿਏਸ਼ਨ ਕਦਮ ਭੇਜੋ (ਸਰਲ ਵਿਆਖਿਆ, ਉਦਾਹਰਨ, ਜਾਂ ਟਾਰਗੇਟ ਅਭਿਆਸ)
ਛੋਟੇ ਰੀ-ਅਸੈਸਮੈਂਟ ਨਾਲ ਦੁਬਾਰਾ ਜਾਂਚੋ (ਅਕਸਰ 1–2 ਸਵਾਲ)
ਜੇ ਫਿਰ ਵੀ ਮੁਸ਼ਕਲ ਰਹੇ ਤਾਂ ਇੱਕ ਵੈਨੀਕ ਰਾਹ (ਵਧ ਅਭਿਆਸ, ਵੱਖਰੀ ਵਿਆਖਿਆ ਸ਼ੈਲੀ, ਜਾਂ ਰੀਵਿਊ ਮੋਡੀਊਲ) ਦਿਓ
ਇਹ ਲੂਪ ਅਨੁਭਵ ਨੂੰ ਸਮਰਥਕ ਰੱਖਦਾ ਹੈ ਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰਗਤੀ ਕਮਾਈ ਗਈ ਹੈ, ਅਨੁਮਾਨ ਨਹੀਂ।
ਨਿੱਜੀਕਰਨ ਦਾ ਮਤਲਬ ਕਈ ਚੀਜ਼ਾਂ ਹੋ ਸਕਦਾ ਹੈ—ਸ਼ੁਰੂਆਤੀ ਬੁਨਿਆਦੀ ਨਿਯਮਾਂ ਤੋਂ ਲੈ ਕੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਡੈਪਟਿਵ ਲੈਸਨ ਸੀਰੀਜ਼ ਤੱਕ। ਮੋਬਾਈਲ ਲਰਨਿੰਗ ਐਪ ਲਈ ਮੁੱਖ ਫੈਸਲਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਅਗਲਾ ਕਦਮ ਕਿਵੇਂ ਚੁਣੋਗੇ: ਸਾਫ਼ ਨਿਯਮਾਂ ਨਾਲ, ਸਿਫਾਰਿਸ਼ਾਂ ਨਾਲ, ਜਾਂ ਦੋਹਾਂ ਦਾ ਮਿਲਾਪ।
ਨਿਯਮ-ਆਧਾਰਿਤ ਨਿੱਜੀਕਰਨ ਸਧਾਰਨ if/then ਲોજਿਕ ਵਰਤਦਾ ਹੈ। ਇਹ ਤੇਜ਼ ਬਣਦਾ, QA ਲਈ ਆਸਾਨ ਅਤੇ ਲਰਨਰਾਂ ਤੇ ਸਟੇਕਹੋਲਡਰਾਂ ਲਈ ਸਧਾਰਨ ਸਮਝਾਉਣ ਯੋਗ ਹੁੰਦਾ ਹੈ।
ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਉਦਾਹਰਨ:
ਨਿਯਮਾਂ ਖਾਸ ਕਰਕੇ MVP ਲਈ ਯੋਗ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰਭਾਵ ਸ਼ੁੱਧਤਾ ਅਤੇ ਪੇਸ਼ਗੋਈ ਦਿੰਦੇ ਹਨ: ਇਕੋ ਇਨਪੁੱਟ ਹਮੇਸ਼ਾ ਇਕੋ ਨਤੀਜੇ ਦੇਣਗੇ।
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕਾਫ਼ੀ ਸਿਗਨਲ (ਮੁਲਾਂਕਣ ਨਤੀਜੇ, ਸਮੇਂ-ਟੁ-ਟਾਸਕ, ਪੂਰਨਤਾ ਦਰ, ਭਰੋਸਾ ਦਰ) ਹੁੰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਰੇਕਮੰਡੇਸ਼ਨ ਲੇਅਰ ਜੋੜ ਸਕਦੇ ਹੋ ਜੋ “ਅਗਲਾ ਸਭ ਤੋਂ ਵਧੀਆ ਲੈਸਨ” ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ।
ਵਿਗਿਆਨਕ ਵਿਚਕਾਰਲਾ ਰਸਤਾ ਇਹ ਹੈ ਕਿ ਨਿਯਮ ਗਾਰਡਰੇਲ ਵਜੋਂ ਰਹਿਣ (ਉਦਾਹਰਨ: ਪ੍ਰੀ-ਰਿਕਵਾਇਰਮੈਂਟ, ਲੋੜੀਂਦਾ ਅਭਿਆਸ), ਫਿਰ ਉਹਨਾਂ ਹੱਦਾਂ ਦੇ ਅੰਦਰ ਸਭ ਤੋਂ ਵਧੀਆ ਆਈਟਮਾਂ ਨੂੰ ਰੈਂਕ ਕਰਨ ਲਈ ਸਿਫਾਰਿਸ਼ਾਂ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਰੱਖੋ। ਇਹ ਲਰਨਰ ਨੂੰ ਤਿਆਰ ਤੋਂ ਪਹਿਲਾਂ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦਾ ਪਰ ਫਿਰ ਵੀ ਨਿੱਜੀ ਮਹਿਸੂਸ ਕਰਵਾਂਦਾ ਹੈ।
ਨਿੱਜੀਕਰਨ ਓਹਦੋਂ ਠੀਕ ਨਹੀਂ ਰਹਿੰਦਾ ਜਦ ਡਾਟਾ ਘੱਟ ਜਾਂ ਗਲਤ ਹੋਵੇ। ਤਿਆਰ ਰaho:
ਯਕੀਨ ਓਦੋਂ ਬਣਦਾ ਹੈ ਜਦੋਂ ਲਰਨਰ ਸਮਝਦੇ ਹਨ ਕਿ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਸਿਫਾਰਿਸ਼ ਕਿਉਂ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਛੋਟੇ, ਦੋਸਤਾਨਾ ਵਜੋਂ ਕਾਰਨ ਦਿਖਾਓ:
ਸਾਥ ਹੀ ਸਧਾਰਣ ਨਿਯੰਤਰਣ ਰੱਖੋ (ਜਿਵੇਂ, “ਲਾਗੂ ਨਹੀਂ” / “ਵੱਖਰਾ ਵਿਸ਼ਾ ਚੁਣੋ”) ਤਾਂ ਕਿ ਲਰਨਰ ਬਿਨਾਂ ਦਬਾਅ ਮਹਿਸੂਸ ਕੀਤੇ ਆਪਣੇ ਰਸਤੇ ਨੂੰ ਸੰਜਾ ਸਕਣ।
ਇੱਕ ਨਿੱਜੀਕਰਤ ਲਰਨਿੰਗ ਐਪ ਤਦ ਹੀ “ਸਿਆਣਾ” ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਜਦੋਂ ਅਨੁਭਵ ਬੇਪਰਾ ਹੌਂਦਾ ਹੈ। ਫੀਚਰਾਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਸਕ੍ਰੀਨ ਸੁਤਰਾਂ ਬਣਾਓ ਜੋ ਲਰਨਰ ਹਰ ਰੋਜ਼ ਛੂਹਣਗੇ ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ 30-ਸਕਿੰਟ ਸੈਸ਼ਨ ਅਤੇ 10-ਮਿੰਟ ਸੈਸ਼ਨ ਵਿਚ ਐਪ ਕੀ ਕਰੇਗਾ।
ਸਰਲ ਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵਧਾਓ:
ਪ੍ਰਗਤੀ ਨੂੰ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਸਕੈਨ ਕਰਨ ਯੋਗ ਰੱਖੋ, ਮੀਨੀ-ਹਾਈਡ ਨਹੀਂ। ਮਾਈਲਸਟੋਨ, ਸਟ੍ਰੀਕਸ (ਨਰਮ), ਅਤੇ ਸਿਹਤਮੰਦ ਮਾਸਟਰੀ ਲੈਵਲ ਜਿਵੇਂ “ਨਵਾਂ → ਅਭਿਆਸ ਕਰ ਰਿਹਾ → ਯਕੀਨਨ” ਵਰਤੋ। ਹਰ ਇਨਡੀਕੇਟਰ ਨਾਲ ਦੱਸੋ ਕਿ ਕੀ ਬਦਲਿਆ, ਅਗਲਾ ਕੀ ਹੈ, ਅਤੇ ਸੁਧਾਰ ਕਿਵੇਂ ਹੋ ਸਕਦਾ ਹੈ।
ਮੋਬਾਈਲ ਸੈਸ਼ਨ ਅਕਸਰ ਰੁਕ-ਰੁਕ ਕੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਪ੍ਰਮੁੱਖ Continue ਬਟਨ ਰਖੋ, ਆਖਰੀ ਸਕ੍ਰੀਨ ਅਤੇ ਪਲੇਬੈਕ ਪੁਜ਼ੀਸ਼ਨ ਯਾਦ ਰੱਖੋ, ਅਤੇ “1-ਮਿੰਟ ਰਿਕੈਪ” ਜਾਂ “ਅਗਲਾ ਮਾਈਕ੍ਰੋ-ਕਦਮ” ਦੇ ਵਿਕਲਪ ਪੇਸ਼ ਕਰੋ।
ਡਾਇਨਾਮਿਕ ਫੋਂਟ ਸਾਈਜ਼, ਉੱਚ ਵਿਸ਼ਮਤਾ, ਸਪਸ਼ਟ ਫੋਕਸ ਸਥਿਤੀਆਂ, ਆਡੀਓ/ਵੀਡੀਓ ਲਈ ਕੈਪਸ਼ਨ/ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ, ਅਤੇ ਅੰਗੂਠੇ ਲਈ ਟੈਪ ਕਰਨਯੋਗ ਲਕੜੀਆਂ ਸਮਰਥਨ ਕਰੋ। ਪਹੁੰਚਯੋਗਤਾ ਸੁਧਾਰ ਆਮ ਤੌਰ 'ਤੇ ਹਰ ਕਿਸੇ ਲਈ ਉਪਯੋਗਤਾ ਵਧਾਉਂਦਾ ਹੈ।
ਪ੍ਰਗਤੀ ਟਰੈਕਿੰਗ ਨਿੱਜੀ ਪਾਥ ਦਾ ਦੂਜਾ ਸਟੀਅਰਿੰਗ ਵੀਲ ਹੈ: ਇਹ ਲਰਨਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਉਹ ਕਿੱਥੇ ਹਨ, ਅਤੇ ਇਹ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਅਗਲਾ ਸੁਝਾਉਣ 'ਚ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ। ਕੁੰਜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਪ੍ਰਗਤੀ ਨੂੰ ਕਈ ਪੱਧਰਾਂ 'ਤੇ ਟਰੈਕ ਕਰੋ ਤਾਂ ਕਿ ਅਨੁਭਵ ਦੋਹਾਂ ਪ੍ਰੇਰਕ ਅਤੇ ਸਹੀ ਮਹਿਸੂਸ ਹੋਵੇ।
ਇਕ ਸਧਾਰਨ ਹਾਇਰਾਰਕੀ ਡਿਜ਼ਾਈਨ ਕਰੋ ਅਤੇ UI ਵਿੱਚ ਇਹ ਦਿੱਖਾਉ:
ਲਰਨਰ ਕਦੇ-ਕਦੇ ਲੈਸਨ ਪੂਰੇ ਕਰਨ ਦੇ ਬਾਵਜੂਦ ਕਿਸੇ ਸਕਿੱਲ 'ਚ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਪੱਧਰ ਵੱਖ ਕਰਨ ਨਾਲ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਨਕਲੀ "100% ਮੁਕੰਮਲ" ਪਲਾਂ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।
ਮਾਸਟਰੀ ਕਿਛੇ ਹੋਵੇ ਇਸਦਾ ਨਿਯਮ ਸਿਸਟਮ ਨਾਲ ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਗਿਣਤੀ-ਮੁਕੰਮਲ ਕੀਤਾ ਜਾਵੇ। ਆਮ ਵਿਕਲਪ:
ਨਿਯਮ ਸਥਿਰ ਅਤੇ ਸਮਝਣਯੋਗ ਰੱਖੋ: ਲਰਨਰ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਐਪ ਕਿਉਂ ਕਹਿੰਦੀ ਹੈ ਉਹਨਾਂ ਨੇ ਕਿਸੇ ਚੀਜ਼ 'ਤੇ ਮਾਸਟਰੀ ਹਾਸਲ ਕੀਤੀ।
ਨਿੱਜੀਕਰਨ ਉਸ ਵੇਲੇ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਲਰਨਰ ਇਰਾਦਾ ਦਿਖਾਉਂਦੇ ਹਨ:
ਲਰਨਰਾਂ ਨੂੰ ਹਫ਼ਤਾਵਾਰੀ ਲਕੜੀਆਂ ਸੈੱਟ ਕਰਨ ਦਿਓ ਅਤੇ ਰਿਮਾਈਂਡਰਾਂ ਨੂੰ ਅਸਾਨੀ ਨਾਲ ਨਿਯੰਤਰਿਤ ਕਰਨ ਦੇ ਵਿਕਲਪ (ਫ੍ਰਿਕਵੇਂਸੀ, ਸ਼ਾਂਤ ਘੰਟੇ, ਅਰਾਮ) ਦਿਓ। ਰਿਮਾਈਂਡਰ ਸਹਾਇਤਾ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਦਬਾਅ ਵਾਂਗ ਨਹੀਂ—ਅਤੇ ਉਹ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ ਨਾਲ ਜੁੜੇ ਹੋਣ (ਜਿਵੇਂ “5 ਮਿੰਟ ਸਮੀਖਿਆ ਕਰੋ”)।
ਨਿੱਜੀਕਰਤ ਲਰਨਿੰਗ ਐਪ ਤਦ ਹੀ “ਸਿਆਣਾ” ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਭਰੋਸੇਯੋਗ ਹੋਵੇ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਮੀ-ਕਦੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਕੰਮ ਕਰਨਾ, ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਦੀ ਰੱਖਿਆ, ਅਤੇ ਲੋਗਿਨ ਵਿੱਚ ਆ ਸਕੂਲ ਰਹਿਤਾ।
ਉਹ ਪਲ ਸੂਚੀਬੱਧ ਕਰੋ ਜੋ ਕਦੇ ਫੇਲ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ: ਐਪ ਖੋਲ੍ਹਣਾ, ਅੱਜ ਦੀ ਯੋਜਨਾ ਦੇਖਣਾ, ਇੱਕ ਲੈਸਨ ਪੂਰਾ ਕਰਨਾ, ਅਤੇ ਪ੍ਰਗਤੀ ਨੂੰ ਸੇਵ ਕਰਨਾ। ਫਿਰ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਉਤਪਾਦ ਲਈ ਆਫਲਾਈਨ ਸਹਾਇਤਾ ਕੀ ਲੱਗੇਗੀ—ਪੂਰੇ ਕੋਰਸ ਡਾਊਨਲੋਡ, ਹਾਲ ਹੀ ਵਿੱਚ ਵਰਤੀ ਸਮੱਗਰੀ ਦਾ ਕੈਸ਼, ਜਾਂ सिर्फ "ਆਫਲਾਈਨ-ਪਹਿਲਾ" ਲੈਸਨ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਲਰਨਰਾਂ ਨੂੰ ਮੋਡੀਊਲ ਡਾਊਨਲੋਡ ਕਰਨ ਦਿਓ (ਵੀਡੀਓ, ਪਾਠ, ਕਵਿਜ਼) ਅਤੇ ਐਕਸ਼ਨਾਂ ਨੂੰ ਕਤਾਰ ਵਿੱਚ ਰੱਖੋ (ਕਵਿਜ਼ ਜਵਾਬ, ਲੈਸਨ ਸ_COMPLETE) ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸਿੰਕ ਕੀਤਾ ਜਾ ਸਕੇ। UI ਵਿੱਚ ਸਪਸ਼ਟ ਦਿਖਾਓ: ਕੀ ਡਾਊਨਲੋਡ ਹੈ, ਕੀ ਸਿੰਕ-ਬਾਕੀ ਹੈ, ਅਤੇ ਸਟੋਰੇਜ ਕਿੰਨੀ ਲੱਗ ਰਹੀ ਹੈ।
ਲਰਨਿੰਗ ਡਾਟਾ ਵਿੱਚ ਨਾਬਾਲਿਗਾਂ ਦੀ ਜਾਣਕਾਰੀ, ਪ੍ਰਦਰਸ਼ਨ ਇਤਿਹਾਸ ਅਤੇ ਵਿਹਾਰਿਕ ਸਿਗਨਲ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ—ਇਸਨੂੰ ਮੁੱਲਵਾਨ ਮੰਨੋ। ਪਛਾਣੋ ਕਿ ਤੁਹਾਨੂੰ ਨਿੱਜੀਕਰਨ ਲਈ ਕੇਵਲ ਲੋੜੀਂਦੇ ਇਨਪੁੱਟ ਹੀ ਲੈਣੇ ਹਨ ਅਤੇ ਪਲਾਂ ਤੇ ਸਪਸ਼ਟ ਦੱਸੋ।
ਡਾਟਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ: ਸੰਚਾਰ ਵਿੱਚ ਐਂਕ੍ਰਿਪਟ ਕਰੋ (HTTPS) ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਰੈਸਟ 'ਤੇ ਵੀ ਐਂਕ੍ਰਿਪਟ ਕਰੋ, ਅਤੇ ਸੀਕ੍ਰੇਟ ਖੁਦ ਐਪ ਬਾਈਨਰੀ 'ਚ ਨਹੀਂ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਐਨਾਲਿਟਿਕਸ ਜਾਂ ਕਰੈਸ਼ ਰਿਪੋਰਟਿੰਗ ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਿਅਕਤੀਗਤ ਸਮੱਗਰੀ ਕੈਪਚਰ ਨਾ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕਰੋ।
ਅਧਿਕ భాగ ਸਿੱਖਿਆ ਐਪਾਂ ਨੂੰ ਰੋਲ-ਆਧਾਰਤ ਐਕਸੈਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਲਰਨਰ, ਮਾਪੇ, ਅਧਿਆਪਕ ਅਤੇ ਐਡਮਿਨ। ਹਰ ਭੂਮਿਕਾ ਕੀ ਵੇਖ ਸਕਦੀ/ਕਰ ਸਕਦੀ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰੋ (ਉਦਾਹਰਨ: ਮਾਪੇ ਪ੍ਰਗਤੀ ਦੇਖ ਸਕਦੇ ਹਨ ਪਰ ਹੋਰ ਲਰਨਰਾਂ ਨੂੰ ਸੁਨੇਹੇ ਨਹੀਂ ਭੇਜ ਸਕਦੇ)।
ਆਖ਼ਰੀ ਵਿੱਚ, ਉਹ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਕਵਰ ਕਰੋ ਜੋ ਲੋਕ ਉਮੀਦ ਕਰਦੇ ਹਨ: ਪਾਸਵਰਡ ਰੀਸੈਟ, ਈਮੇਲ/ਫੋਨ ਵੈਰੀਫਿਕੇਸ਼ਨ ਜੇ ਲੋੜੀਂਦਾ, ਅਤੇ ਜੰਤਰ ਬਦਲਦੇ ਸਮੇਂ ਪ੍ਰਗਤੀ ਸਿੰਕ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਪਸ਼ਟ "ਸਾਈਨ ਆਊਟ" ਅਤੇ "ਅਕਾਊਂਟ ਮਿਟਾਓ" ਵਿਕਲਪ ਦਿਓ ਤਾਂ ਲਰਨਰਾਂ ਦਾ ਕਾਬੂ ਰਹੇ।
ਤੁਹਾਡੇ ਟੈਕ ਚੋਣਾਂ ਨੂੰ ਉਹ MVP ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ—ਨ ਕਿ ਦੂਰ-ਭਵਿੱਖ ਵਾਲੀ ਐਪ। ਲਕੜੀ ਇਹ ਹੈ ਕਿ ਨਿੱਜੀ ਪਾਥ ਭਰੋਸੇਯੋਗ ਹੋਣ, ਤੇ ਤੁਰੰਤ ਇਟਰੈਟ ਕਰਨ ਯੋਗ ਅਤੇ ਮਹਿੰਗੀ ਰੀ-ਰਾਈਟ ਤੋਂ ਬਚਾਉਣ ਵਾਲੀ ਹੋਵੇ।
ਮੋਬਾਈਲ ਅਨੁਭਵ ਕਿਵੇਂ ਦਿਓਗੇ ਇਹ ਤੈਅ ਕਰੋ:
ਜੇ ਨਿੱਜੀਕਰਨ ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਬੈਕਗ੍ਰਾਊਂਡ ਸਿੰਕ, ਜਾਂ ਆਫਲਾਈਨ ਡਾਊਨਲੋਡ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਚੁਣਿਆ ਗਿਆ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਉਹਨਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਰਥਿਤ ਕਰਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਲਰਨਿੰਗ ਐਪ ਅਕਸਰ ਕੁਝ “ਬਿਲਡਿੰਗ ਬਲੋਕ” ਲੋੜਦਾ ਹੈ:
ਪਹਿਲੇ ਵਰਜ਼ਨ ਨੂੰ ਹਲਕਾ ਰੱਖੋ, ਪਰ ਉਹ ਪ੍ਰਦਾਤਾਵਾਂ ਚੁਣੋ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਵਧ ਸਕਦੇ ਹੋ।
ਨਿੱਜੀ ਪਾਥ ਲਈ, ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਆਮ ਤੌਰ ਤੇ ਲੋੜਾਂ ਰੱਖਦਾ ਹੈ:
ਇੱਕ ਬੁਨਿਆਦੀ ਡਾਟਾਬੇਸ + ਇੱਕ ਛੋਟਾ ਸਰਵਿਸ ਲੇਅਰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਾਫੀ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਪਹਿਲੀ ਇਮਪਲੀਮੈਂਟੇਸ਼ਨ ਤੇਜ਼ ਕਰਨੀ ਹੋ (ਖਾਸ ਕਰਕੇ MVP ਲਈ), Koder.ai ਵਰਗਾ vibe-coding ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਵੈੱਬ ਐਡਮਿਨ ਡੈਸ਼ਬੋਰਡ (ਕੰਟੈਂਟ + ਟੈਗਿੰਗ), ਇੱਕ ਬੈਕਐਂਡ ਸਰਵਿਸ (Go + PostgreSQL), ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਲਰਨਰ-ਸਮੁਖ ਵੈੱਬ ਤਜਰਬਾ ਚੈਟ-ਚਲਾਇਆ ਨਿਰਦੇਸ਼ ਤੋਂ ਜਨਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਇਸਨੂੰ ਡੇਟਾ ਮਾਡਲ ਅਤੇ API ਰੂਪਾਂ ਦੀ ਜਾਂਚ ਲਈ ਵਰਤਦੀਆਂ ਹਨ, ਫਿਰ ਸੋর্স ਕੋਡ ਨੂੰ ਐਕਸਪੋਰਟ ਕਰਕੇ ਫੁੱਲ ਕੰਟਰੋਲ ਨਾਲ ਇਟਰੈਟ ਕਰਦੀਆਂ ਹਨ।
APIਜ਼ ਨੂੰ ਸਥਿਰ “ਆਬਜੈਕਟ” (User, Lesson, Attempt, Recommendation) ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰੋ ਨਾ ਕਿ ਸਕ੍ਰੀਨ-ਕਦਮਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ। ਲਾਭਦਾਇਕ ਐਂਡਪੌਇੰਟ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:
GET /me ਅਤੇ PATCH /me/preferencesGET /content?skill=… ਅਤੇ GET /lessons/{id}POST /attempts (ਜਵਾਬ/ਨਤੀਜੇ ਸੰਮਿਸ਼ਟ ਕਰੋ)GET /recommendations/nextਇਸ ਨਾਲ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਲਚਕੀਲਾ ਰਹਿਣ ਦਾ ਮੌਕਾ ਮਿਲਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸਕਿੱਲ ਮਾਸਟਰੀ, ਨਵੇਂ ਮੁਲਾਂਕਣ, ਜਾਂ ਵਿਕਲਪਤ ਰੇਕਮੰਡੇਸ਼ਨ ਲਾਜਿਕ ਜੋੜੋ।
ਨਿੱਜੀਕਰਤ ਲਰਨਿੰਗ ਐਪ ਫੀਡਬੈਕ ਲੂਪਾਂ ਨਾਲ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ, ਨ ਕਿ ਵੱਡੇ ਲਾਂਚ ਨਾਲ। ਤੁਹਾਡਾ MVP ਇੱਕ ਗੱਲ ਸਾਬਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਕਿ ਲਰਨਰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਲਗਾਤਾਰ ਇੱਕ “ਅਗਲਾ ਸਭ ਤੋਂ ਵਧੀਆ ਲੈਸਨ” ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਜੋ ਸਮਝਦਾਰ ਮਹਿਸੂਸ ਹੋਵੇ।
ਇੱਕ ਤੰਗ ਸਮੱਗਰੀ ਸੈੱਟ (ਉਦਾਹਰਨ ਵਜੋਂ 20–40 ਲੈਸਨ) ਅਤੇ ਸਿਰਫ 1–2 ਲਰਨਰ ਪੇਰਸੋਨਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਵਾਅਦਾ ਸਪਸ਼ਟ ਰੱਖੋ: ਇਕ ਸਕਿੱਲ ਖੇਤਰ, ਇਕ ਲਕੜੀ, ਇਕ ਪਾਥ ਲਾਜਿਕ। ਇਸ ਨਾਲ ਇਹ ਸੂਝਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿ ਨਿੱਜੀਕਰਨ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਗੁੰਝਲਦਾਰ ਬਣਾ ਰਿਹਾ ਹੈ।
ਇੱਕ ਵਧੀਆ MVP ਨਿਯਮ ਸੈੱਟ ਇੰਝ ਹੋ ਸਕਦਾ ਹੈ:
ਸਭ ਕੁਝ ਕੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਦੋ ਮੋਮੈਂਟਾਂ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ ਜੋ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਨ:
ਆਨਬੋਰਡਿੰਗ (ਲਕੜੀ + ਪੱਧਰ + ਉਪਲਬਧ ਸਮਾਂ)
“ਅਗਲਾ ਲੈਸਨ” ਸਕ੍ਰੀਨ (ਇਸ ਲੈਸਨ ਕਾਰਨ, ਅਗਲੇ ਕੀ ਹਨ)
ਹਰ ਪੇਰਸੋਨਾ ਲਈ 5–8 ਲੋਕਾਂ ਨਾਲ ਤੇਜ਼ ਯੂਜ਼ਬਿਲਿਟੀ ਟੈਸਟ ਚਲਾਓ। ਛੱਡਣਾ, ਹੇਜਿਟੇਸ਼ਨ ਅਤੇ “ਇਸਦਾ ਮਤਲਬ ਕੀ ਹੈ?” ਵਾਲੇ ਪਲ ਧਿਆਨ ਨਾਲ ਦੇਖੋ। ਜੇ ਲਰਨਰ ਸਮਝਦੇ ਨਹੀਂ ਕਿ ਇੱਕ ਲੈਸਨ ਕਿਉਂ ਸੁਝਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਭਰੋਸਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਆਗੇ ਵਧ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗੇ ਟੂਲ ਵੀ ਵਰਤ ਸਕਦੇ ਹੋ ਜੋ ਕਲਿੱਕਏਬਲ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਇੱਕ ਹਲਕਾ-ਫुल्कਾ ਬੈਕਐਂਡ ਘੜਦੇ ਹਨ ਜੋ ਪਲੇਸਮੈਂਟ ਨਤੀਜੇ ਅਤੇ "ਅਗਲਾ ਲੈਸਨ" ਫੈਸਲਿਆਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਯੂਜ਼ਰ-ਟੈਸਟਿੰਗ ਕੁਝ ਉਹਨਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਨਜ਼ਦੀਕੀ ਉਦਯੋਗ-ਪ੍ਰਵਿਹਾਰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ (ਨੇੜੇ ਪ੍ਰੋਡਕਸ਼ਨ) ਨਾ ਕਿ ਸਿਰਫ ਸਥਿਰ ਸਕ੍ਰੀਨਾਂ।
MVP ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਇੰਸਟੂਮੈਂਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਪੂਰਨਤਾ ਦਰ, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਦਰ, ਸਮਾਂ-ਟੁ-ਟਾਸਕ, ਅਤੇ ਮੁਲਾਂਕਣ ਨਤੀਜਿਆਂ ਵਰਗੇ ਲਰਨਿੰਗ ਸਿਗਨਲ ਦੇਖ ਸਕੋ। ਇਹਨਾਂ ਨਤੀਜਿਆਂ ਨਾਲ ਨਿਯਮਾਂ ਨੂੰ ਸੁਧਾਰੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਕਠਿਨਾਈ ਜ਼ਿਆਦਾ ਕਰੋਂ। ਜੇ ਸਧਾਰਨ ਨਿਯਮ ਲੀਨੀਅਰ ਪਾਥ ਨਾਲ ਬਿਹਤਰ ਨਹੀਂ ਕਰ ਰਹੇ, ਤਾਂ ਸਿਫਾਰਿਸ਼ਾਂ ਚਮਤਕਾਰਿਕ ਤੌਰ 'ਤੇ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਨਗੀਆਂ।
ਨਿੱਜੀਕਰਨ ਦੀ ਕੁਆਲਟੀ ਟੈਗਿੰਗ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਹਰ ਟੈਸਟ ਚੱਕਰ ਤੋਂ ਬਾਅਦ, ਸਕਿੱਲ, ਮੁਸ਼ਕਿਲੀ, ਪ੍ਰੀ-ਰਿਕਵਾਇਰਮੈਂਟ, ਫਾਰਮੈਟ (ਵੀਡੀਓ/ਕਵਿਜ਼) ਅਤੇ ਆਮ ਸਮਾਂ ਜਿਹੇ ਟੈਗਸ ਨੂੰ ਸੁਧਾਰੋ। ਟ੍ਰੈਕ ਕਰੋ ਕਿ ਕਿੱਥੇ ਟੈਗਸ ਗਾਇਬ ਜਾਂ ਅਸੰਗਤ ਹਨ—ਫਿਰ ਸਮੱਗਰੀ ਮੈਟਾ-ਡਾਟਾ ਨੂੰ ਨਿਰਧਾਰਿਤ ਕਰਕੇ ਹੋਰ ਫੀਚਰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ।
ਜੇ ਤੁਹਾਨੂੰ ਪ੍ਰਯੋਗਾਂ ਅਤੇ ਰਿਲੀਜ਼ ਕੈਡੈਂਸ ਲਈ ढਾਂਚਾ ਚਾਹੀਦਾ ਹੋਵੇ, ਤਾਂ /blog/mvp-testing-playbook 'ਤੇ ਇਕ ਹਲਕਾ-ਫुल्कਾ ਯੋਜਨਾ ਸ਼ਾਮਲ ਕਰੋ।
ਨਿੱਜੀਕਰਨ ਲਰਨਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਲੈ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਵੀ ਖਤਰਾ ਦਿਨਦਾ ਹੈ ਕਿ ਲੋਕ ਗਲਤ ਰਸਤੇ 'ਤੇ ਧੱਕੇ ਜਾ ਸਕਦੇ ਹਨ—ਜਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਉਸੇ ਰਸਤੇ 'ਤੇ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਨੈਤਿਕਤਾ ਅਤੇ ਪਾਰਦਰਸ਼ਤਾ ਨੂੰ ਇਕ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਵਜੋਂ ਵਰਤੋਂ, ਨਾ ਕਿ ਕਾਨੂੰਨੀ ਸੋਚ-ਵਿਚਾਰ ਦੇ ਤੌਰ 'ਤੇ।
ਇੱਕ ਸادہ ਨਿਯਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਸੰਵੇਦਨਸ਼ੀਲ ਗੁਣਾਂ ਦਾ ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ ਜੇ ਤਕ ਕਿ ਉਹ ਸਿੱਖਣ ਲਈ ਜਰੂਰੀ ਨਾ ਹੋਣ। ਉਹਨਾਂ ਗੱਲਾਂ ਤੋਂ ਬਚੋ ਜਿਵੇਂ ਸਿਹਤ ਦੀ ਹਾਲਤ, ਆਮਦਨ ਸਤਰ ਜਾਂ ਪਰਿਵਾਰਕ ਹਾਲਤ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਸਿਰਫ ਵਰਤਾਰ ਕਰਕੇ ਗੈਸ ਨਾ ਲਗਾਓ। ਜੇ ਉਮਰ ਸੰਬੰਧੀ ਲੋੜ ਹੈ (ਬਚਿਆਂ ਦੀ ਸੁਰੱਖਿਆ ਲਈ), ਤਾਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਕੱਠਾ ਕਰੋ ਅਤੇ ਕਾਰਨ ਦਿਓ।
ਨਰਮ ਸਿਗਨਲਾਂ ਨਾਲ ਵੀ ਸਾਵਧਾਨ ਰਹੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਦੇਰ ਰਾਤ ਅਧਿਐਨ ਕਰਨ ਵਾਲਾ ਸੈਸ਼ਨ ਆਪਣੇ ਆਪ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਲਰਨਰ “ਅਨੁਤਪਾਦਨ” ਹੈ ਜਾਂ “ਜੋਸ਼ੀਲਾ”—ਸਿਫਾਰਿਸ਼ਾਂ ਵਿੱਚ ਸਿੱਖਣ ਸਿਗਨਲ (ਸਹੀ-ਗਲਤ, ਸਮਾਂ-ਟੁ-ਟਾਸਕ, ਰੀਵਿਊ ਫ੍ਰਿਕਵੇਂਸੀ) ਵਰਤੋ ਅਤੇ ਵਿਆਖਿਆ ਘੱਟ ਰੱਖੋ।
ਰੇਕਮੰਡੇਸ਼ਨ ਸਿਸਟਮ ਤੁਹਾਡੇ ਸਮੱਗਰੀ ਜਾਂ ਡਾਟਾ ਦੇ ਪੈਟਰਨ ਨੂੰ ਜਿਆਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਮੀਖਿਆ ਅਭਿਆਸ ਬਣਾਓ:
ਜੇ ਤੁਸੀਂ ਮਨੁੱਖ-ਬਣਾਏ ਨਿਯਮ ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਉਨ੍ਹਾਂ ਦੀ ਭੀ ਇੰਨੀ ਹੀ ਜਾਂਚ ਕਰੋ—ਨਿਯਮਾਂ ਵੀ ਪੱਖਪਾਤ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਜਦ ਵੀ ਐਪ ਕਿਸੇ ਪਾਥ ਨੂੰ ਬਦਲਦੀ ਹੈ, ਇੱਕ ਛੋਟਾ ਕਾਰਨ ਦਿਖਾਓ: “ਸਿਫਾਰਿਸ਼ ਇਸ ਲਈ ਕਿ ਤੁਸੀਂ ਭਾਗ-ਹਿਸਿਆਂ 'ਤੇ ਗਲਤੀਆਂ ਕੀਤੀਆਂ” ਜਾਂ “ਅਗਲਾ ਕਦਮ ਤੁਹਾਡੇ ਲਕੜੀ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ: ‘ਗੱਲਬਾਤੀ ਮੁਢਲਾ’।” ਭਾਸ਼ਾ ਸਧਾਰਨ ਅਤੇ ਲਗਾਤਾਰ ਰੱਖੋ।
ਲਰਨਰ ਗੋਲ ਬਦਲ ਸਕਣ, ਪਲੇਸਮੈਂਟ ਦੁਬਾਰਾ ਕਰ ਸਕਣ, ਇਕ ਯੂਨਿਟ ਲਈ ਪ੍ਰਗਤੀ ਰੀਸੈਟ ਕਰ ਸਕਣ ਅਤੇ ਨੂਡੀਜ ਤੋਂ ਓਪਟ-ਆਊਟ ਹੋ ਸਕਣ। ਇੱਕ “ਮੇਰੀ ਯੋਜਨਾ ਸੋਧੋ” ਸਕ੍ਰੀਨ ਨਾਲ ਇਹ ਵਿਕਲਪ ਸ਼ਾਮਿਲ ਕਰੋ, ਅਤੇ “ਇਹ ਸਿਫਾਰਿਸ਼ ਠੀਕ ਨਹੀਂ” ਦੀ ਰਿਪੋਰਟਿੰਗ ਲਈ ਸਧਾ ਰਸਤਾ ਦਿਓ।
ਜੇ ਬੱਚੇ ਐਪ ਵਰਤ ਸਕਦੇ ਹਨ, ਤਾਂ ਡਿਫੋਲਟ ਤੌਰ ਤੇ ਸਖ਼ਤ ਪ੍ਰਾਈਵੇਸੀ, ਸੋਸ਼ਲ ਫੀਚਰਾਂ ਸੀਮਿਤ ਕਰੋ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਟ੍ਰੀਕ ਪ੍ਰੇਰਣਾ ਤੋਂ ਬਚੋ, ਅਤੇ ਜਦ ਲੋੜ ਹੋਵੇ ਮਾਪੇ/ਗਾਰਡਿਅਨ ਕੰਟਰੋਲ ਪ੍ਰਦਾਨ ਕਰੋ।
ਨਿੱਜੀਕਰਤ ਲਰਨਿੰਗ ਐਪ ਕਦੇ "ਮੁਕੰਮਲ" ਨਹੀਂ ਹੁੰਦੀ। ਪਹਿਲੀ ਰਿਲੀਜ਼ ਇਹ ਸਾਬਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਲਰਨਰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਸਕਦੇ ਹਨ, ਜ਼ੁੜੇ ਰਹਿ ਸਕਦੇ ਹਨ, ਅਤੇ ਅਸਲ ਤੌਰ 'ਤੇ ਇੱਕ ਪਾਥ 'ਤੇ ਪ੍ਰਗਤੀ ਕਰਦੇ ਹਨ ਜੋ ਉਨ੍ਹਾਂ ਲਈ ਠੀਕ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਲਾਂਚ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਡਾ ਕੰਮ ਫੀਡਬੈਕ ਲੂਪ ਬਣਾਉਣਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਆਨਬੋਰਡਿੰਗ → ਪਹਿਲਾ ਲੈਸਨ → ਹਫ਼ਤਾ 1 ਰਿਟੇਨਸ਼ਨ ਵਰਗੇ ਸਧਾਰਨ ਲਰਨਰ ਯਾਤਰਾ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਐਨਾਲਿਟਿਕਸ ਸੈੱਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ ਡਾਊਨਲੋਡ ਟ੍ਰੈਕ ਕਰੋਗੇ, ਤਾਂ ਅਸਲ ਕਹਾਣੀ ਚੁਕ ਜਾਵੇਗੀ।
ਉਨ੍ਹਾਂ ਥਾਵਾਂ ਦੀ ਖੋਜ ਕਰੋ ਜਿੱਥੇ ਯੂਜ਼ਰ ਆਨਬੋਰਡਿੰਗ ਛੱਡਦੇ ਹਨ (ਪ੍ਰਸ਼ਨਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ? ਅਸਪਸ਼ਟ ਮੁੱਲ?), ਪਹਿਲੇ ਮੈਨੀਫੇਸਟ ਵਿਨ (ਪੂਰਾ ਹੋਇਆ ਲੈਸਨ ਜਾਂ ਮਾਸਟਰ ਕੀਤਾ ਸਕਿੱਲ) ਤੱਕ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ, ਅਤੇ ਕੀ ਰਿਮਾਈਂਡਰ ਸਹਾਇਕ ਵਾਪਸੀ ਲਿਆਉਂਦੇ ਹਨ ਜਾਂ ਕੇਵਲ churn ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਨਿੱਜੀ ਪਾਥ ਚੁਪਚਾਪ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ: ਯੂਜ਼ਰ ਲਗਾਤਾਰ ਟੈਪ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ, ਪਰ ਉਹ ਗੁੰਝਲਦਾਰ ਜਾਂ ਫਸੇ ਹੋਏ ਹਨ। ਪਾਥ ਸਿਹਤ ਸਿਗਨਲਾਂ ਜੋਖੋ ਜਿਵੇਂ ਡਰੌਪ-ਆਫ, ਲੈਸਨ ਮੁਸ਼ਕਲੀਆਂ, ਅਤੇ ਇੱਕੋ ਧਾਰਨਾ 'ਤੇ ਦੁਹਰਾਈਆਂ ਕੋਸ਼ਿਸ਼ਾਂ। ਗਿਣਤੀ ਮੈਟਰਿਕਸ ਨੂੰ ਹਲਕਾ-ਫुल्कਾ ਗੁਣਵੱਤਾ ਇਨਪੁੱਟ (ਜਿਵੇਂ “ਇਹ ਬਹੁਤ ਆਸਾਨ/ਬਹੁਤ ਔਖਾ ਸੀ?”) ਨਾਲ ਮਿਲਾਓ।
ਕੋਡ-ਪੂਰਨ ਸਿਸਟਮਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਛੋਟੇ ਬਦਲਾਅ A/B ਟੈਸਟ ਕਰੋ: ਆਨਬੋਰਡਿੰਗ ਕਾਪੀ, ਪਲੇਸਮੈਂਟ ਕਵਿਜ਼ ਦੀ ਲੰਬਾਈ, ਜਾਂ ਰਿਮਾਈਂਡਰ ਦੇ ਸਮੇਂ। ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਸਿੱਖਣ ਵਜੋਂ ਲਓ—ਜੋ ਚੰਗਾ ਹੈ ਉਹ ਰੱਖੋ।
ਉਹ ਸੁਧਾਰ ਯੋਜਨਾਬੰਨ੍ਹੋ ਜੋ ਮੁੱਲ ਨੂੰ ਡੂੰਘਾ ਕਰਦੇ ਹਨ ਬਿਨਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਓਹਲੇ ਕੀਤਾ:
ਸਰਵੋਤਮ ਨਤੀਜਾ ਇੱਕ ਐਸਾ ਪਾਥ ਹੈ ਜੋ ਨਿੱਜੀ ਮਹਿਸੂਸ ਵੀ ਹੋਵੇ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਵੀ: ਲਰਨਰ ਸਮਝ ਲੈਂਦੇ ਹਨ ਕਿ ਉਹ ਕੁਝ ਕਿਉਂ ਦੇਖ ਰਹੇ ਹਨ, ਅਤੇ ਉਹ ਹਫ਼ਤਾ ਬਾਈ ਹਫ਼ਤਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੁਧਾਰ ਦੇਖ ਸਕਦੇ ਹਨ।
ਪرسਨਲਾਈਜ਼ੇਸ਼ਨ ਤਦ ਹੀ ਲਾਭਦਾਇਕ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਤੀਜੇ ਸੁਧਾਰੇ। ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਪ੍ਰੋਡਕਟ ਨਿਯਮ ਹੋ ਸਕਦਾ ਹੈ:
ਇਸ ਨੂੰ ਜਲਦੀ ਲਿਖੋ ਅਤੇ ਉਹਨੂੰ ਉਹਨਾਂ ਫੀਚਰਾਂ ਨੂੰ ਰੱਦ ਕਰਨ ਲਈ ਵਰਤੋਂ ਜੋ "ਸਿਆਣਾ" ਲੱਗਦੇ ਹਨ ਪਰ ਸਮੇਂ-ਟੂ-ਸਕਿਲ ਘਟਾਉਂਦੇ ਨਹੀਂ।
ਵਿਅੰਗ-ਮੁਕਾਬਲੇ engagement ਦੀ ਥਾਂ ਸਿੱਖਣ-ਨਤੀਜਿਆਂ ਨਾਲ ਜੁੜੇ ਮੈਟ੍ਰਿਕਸ ਵਰਤੋ। ਆਮ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
MVP ਲਈ 1–2 ਮੁੱਖ ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਇਵੈਂਟ ਜੋ ਤੁਸੀਂ ਟ੍ਰੈਕ ਕਰਦੇ ਹੋ ਉਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸੁਧਾਰਨ ਵਿੱਚ ਸਹਾਇਕ ਹੈ।
2–4 ਪ੍ਰੋਫਾਈਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਮੋਟਿਵੇਸ਼ਨ ਅਤੇ ਪ੍ਰਸੰਗ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ, ਸਿਰਫ਼ ਡੈਮੋਗ੍ਰਾਫਿਕਸ ਨਹੀਂ। ਹਰ ਇੱਕ ਲਈ ਟਿੱਪਣੀਆਂ ਕਰੋ:
ਇਸ ਨਾਲ ਤੁਹਾਡੇ ਪਹਿਲੇ ਲਰਨਿੰਗ ਪਾਥ ਹਕੀਕਤ-ਆਧਾਰਤ ਰਹਿੰਦੇ ਹਨ, ਨਾ ਕਿ ਸਭ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਸਰਵ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼।
ਨਿੱਜੀਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਘੱਟੋ-ਘੱਟ ਡਾਟਾ ਹੀ ਇਕੱਠਾ ਕਰੋ ਅਤੇ ਹਰ ਵਾਰੀ ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ ਕਿਉਂ ਮੰਗਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਉੱਚ-ਸੰਕੇਤ, ਉਪਭੋਗਤਾ-ਦੋਸਤਾਨਾ ਇਨਪੁੱਟ ਜਿਵੇਂ:
ਗੈਰ-ਜ਼ਰੂਰੀ ਪ੍ਰਸ਼ਨ ਛੱਡਣ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਵਿਸ਼ਿਆਂ ਨੂੰ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ ਜਦ ਤੱਕ ਉਹ ਸਿੱਖਣ ਲਈ ਜਰੂਰੀ ਨਾ ਹੋਣ।
ਇੱਕ ਸਕਿੱਲ ਮੈਪ ਬਣਾਓ: ਆਉਟਕਮ → ਸਕਿੱਲ → ਪ੍ਰੀ-ਰਿਕਵਾਇਰਮੈਂਟ → ਸਬੂਤ। ਹਰ ਸਕਿੱਲ ਲਈ ਨੂੰਲਦੀਆਂ ਚੀਜ਼ਾਂ ਨਿਰਧਾਰਤ ਕਰੋ:
ਇਹ ਮੈਪ ਤੁਹਾਡੇ ਨਿੱਜੀਕਰਨ ਦੀ ਰੀੜ੍ਹ ਹੈ: ਇਹ ਘਲਤ ਛਾਲਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਅਤੇ "ਅਗਲਾ ਪਾਠ" ਫੈਸਲੇ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ।
ਪਲੇਸਮੈਂਟ ਫਲੋ ਛੋਟਾ, ਅਡੈਪਟਿਵ ਅਤੇ ਬ੍ਰੈਂਚਿੰਗ-ਪੌਇੰਟਾਂ 'ਤੇ ਕੇਂਦਰਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਮਕਸਦ ਤੇਜ਼ ਅਤੇ ਸਹੀ ਪਲੇਸਮੈਂਟ ਹੈ—ਕੋਈ ਵਿਸ਼ਾਲ ਇਮਤਿਹਾਨ ਨਹੀਂ।
ਹਾਂ—MVP ਲਈ ਪਹਿਲਾਂ ਨਿਯਮ-ਆਧਾਰਿਤ ਨਿੱਜੀਕਰਨ ਜਾਰੀ ਕਰੋ ਤਾਂ ਜੋ ਪੇਸ਼ਗੋਈ ਅਤੇ ਸਾਫ਼ ਫੀਡਬੈਕ ਮਿਲੇ। ਸਹੀ MVP ਨਿਯਮਾਂ ਕੁਝ ਉਦਾਹਰਨ:
ਬਾਅਦ ਵਿੱਚ, ਰੁਲਜ਼ ਨੂੰ ਗਾਰਡਰੇਲ ਦੇ ਰੂਪ ਵਿੱਚ ਰੱਖ ਕੇ ਸਿਫਾਰਿਸ਼ਾਂ ਨੂੰ ਉਸ ਹੱਦ ਅੰਦਰ ਅਨੁਕ੍ਰਮਿਤ ਕਰੋ ਜਿੱਥੇ ਪ੍ਰੀ-ਰਿਕਵਾਇਰਮੈਂਟ ਅਤੇ ਮਾਸਟਰੀ ਨਿਯਮ ਹਮੇਸ਼ਾ ਲਾਗੂ ਰਹਿਣ।
ਨਵਾਂ ਯੂਜ਼ਰ/ਡੇਟਾ-ਘੱਟ ਹਾਲਤ ਲਈ ਸਿਧਾਂਤ ਅੰਦਾਜ਼:
ਹਮੇਸ਼ਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫੋਲਟ "ਅਗਲਾ ਕਦਮ" ਦਿਓ ਤਾਂ ਕਿ ਉਪਭੋਗਤਾ ਕਦੇ ਵੀ dead end ਤੇ ਨਾ ਪਹੁੰਚੇ।
ਸਿਫਾਰਿਸ਼ਾਂ ਨੂੰ ਸਮਝਣਯੋਗ ਅਤੇ ਨਿਯੰਤਰਣਯੋਗ ਬਣਾਓ:
ਜਦੋਂ ਲਰਨਰ ਆਪਣੀ ਰਾਹ-ਦਿਖਾਈ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹਨ ਤਾਂ ਨਿੱਜੀਕਰਨ ਸਹਾਇਕ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਨਾ ਕਿ ਮਨਮਾਨੀ।
ਆਫਲਾਈਨ ਲਈ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ-ਕੀ ਬਿਨਾਂ ਇੰਟਰਨੈਟ ਦੇ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:
ਪ੍ਰਾਈਵੇਸੀ ਲਈ, ਸਿੱਖਣ-ਡਾਟਾ ਨੂੰ ਮੁੱਲ ਰੱਖੋ: ਸੰਕੁਚਿਤ ਸੰਗ੍ਰਹਿ ਕਰੋ, ਟਰਾਂਸਮੀਸ਼ਨ ਤੇ ਐਂਕ੍ਰਿਪਟ ਕਰੋ ਅਤੇ ਵਿਅਕਤੀਗਤ ਸਮੱਗਰੀ ਨੂੰ ਐਨਾਲਿਟਿਕਸ ਵਿੱਚ ਨਾ ਫਸਾਓ।