ਗੈਰ-ਤਕਨੀਕੀ ਫਾਊਂਡਰਾਂ ਲਈ ਪ੍ਰੀ-ਲਾਂਚ ਐਪ ਗੁਣਵੱਤਾ ਚੈਕਲਿਸਟ

ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ

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

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

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

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

ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਧਿਆਨ ਰੱਖੋ ਕਿ ਇੱਕ ਅਸਲੀ ਵਿਅਕਤੀ ਕੀ ਹਾਸਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ:

• ਖਾਤਾ ਬਣਾਉਣਾ
• ਮੁੱਖ ਟਾਸਕ ਪੂਰਾ ਕਰਨਾ
• ਗਲਤੀ ਠੀਕ ਕਰਨਾ
• ਵਾਪਸ ਜਾ ਕੇ ਕੁਝ ਬਦਲਣਾ
• ਪੂਰੇ ਵਿਸ਼ਵਾਸ ਨਾਲ ਮੁਕੰਮਲ ਕਰਨਾ

ਲੋਕ ਐਪਾਂ ਨੂੰ ਇੱਕ ਸਕ੍ਰੀਨਾਂ ਦੇ ਜਥੇ ਵਾਂਗ ਨਹੀਂ ਵੇਖਦੇ। ਉਹ ਇੱਕ ਲੜੀਵਾਰ ਛੋਟੇ ਫੈਸਲੇ ਵੇਖਦੇ ਹਨ। ਜਦੋਂ ਉਹ ਫੈਸਲੇ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ, ਐਪ ਪਾਲਿਸ਼ਡ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਇਹ ਅਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਲਾਂਚ ਸਮੱਸਿਆਵਾਂ ਤੇਜ਼ੀ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ, ਭਾਵੇਂ ਕੋਡ ਸਹੀ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ।

ਇੱਕ ਸਧਾਰਣ QA ਪਾਸ ਕਿਵੇਂ ਚਲਾਉਣਾ

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

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

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

ਨਵੇਂ ਯੂਜ਼ਰ ਵਾਂਗ ਟੈਸਟ ਚਲਾਓ

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

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

ਉਹੀ ਫਲੋ ਡੈਸਕਟਾਪ ਅਤੇ ਫੋਨ 'ਤੇ ਦੁਹਰਾਓ। ਜਿਹੜਾ ਰਸਤਾ ਲੈਪਟਾਪ 'ਤੇ ਸਹੀ ਲੱਗਦਾ ਹੈ, ਉਹ ਮੋਬਾਈਲ 'ਤੇ ਅਸਹਜ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਫਾਰਮ, ਪੋਪ-ਅੱਪ, ਡੇਟ ਪਿਕਰ, ਅਤੇ ਲੰਮੇ ਬਟਨ ਵਾਸਤੇ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਟੂਲ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਇਆ, ਇਹ ਹਿੱਸਾ ਫਿਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਰਹਿੰਦਾ ਹੈ। ਗਤੀ ਤੁਹਾਨੂੰ ਲਾਂਚ ਤੱਕ ਤੇਜ਼ ਪਹੁੰਚ ਦਿੰਦੀ ਹੈ, ਪਰ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਹੀ ਅਜਿਹੀਆਂ ਅਵਾਂਛਿਤ ਸ਼ਬਦਾਵਲੀ, ਗੁੰਝਲਦਾਰ ਕਦਮ, ਅਤੇ ਕਮਜ਼ੋਰ ਫੀਡਬੈਕ ਨੂੰ ਫੜਦੀ ਹੈ।

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

ਚੰਗੀ QA ਹਮੇਸ਼ਾਂ ਹਰ ਬੱਗ ਫੜਨ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ friction ਨੂੰ ਜਲਦੀ ਪਛਾਣਨ ਬਾਰੇ ਹੁੰਦੀ ਹੈ, ਜਦ ਤੱਕ fixes ਸਸਤੇ ਹਨ।

ਮੁੱਖ ਯੂਜ਼ਰ ਫਲੋ ਚੈੱਕ ਕਰੋ

ਤੁਹਾਡੀ ਐਪ ਸੋਹਣੀ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਫਿਰ ਵੀ ਉਹਨਾਂ ਕਦਮਾਂ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਲੋਕ ਸਬ ਤੋਂ ਜ਼ਿਆਦਾ ਵਰਤਦੇ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਰਾਹ ਨੂੰ ਲਓ ਜੋ ਸਭ ਤੋਂ ਵਧੇਰੇ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ: ਲੌਗ ਇਨ ਹੋਣਾ, ਮੁੱਖ ਟਾਸਕ ਕਰਨਾ, ਅਤੇ ਸਮਝਣਾ ਕਿ ਕੀ ਹੋਇਆ।

ਜੇ ਨਵਾਂ ਉਪਭੋਗਤਾ ਸਾਈਨ ਅਪ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਲਾਗਇਨ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਜਾਂ ਭੁੱਲਿਆ ਪਾਸਵਰਡ ਵਾਪਸ ਨਹੀਂ ਲੈ ਸਕਦਾ, ਤਾਂ ਬਾਕੀ ਉਤਪਾਦ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀ ਰਹਿੰਦਾ।

ਪਹਿਲਾਂ ਕੀ ਟੈਸਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਐਪ ਨੂੰ ਇੱਕ ਆਮ ਉਪਭੋਗਤਾ ਵਾਂਗ ਖੋਲ੍ਹੋ, ਨਾ ਉਹ ਫਾਊਂਡਰ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਜਾਣਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਧੀਰੇ-ਧੀਰੇ ਚਲੋ ਅਤੇ ਹਰ ਟਾਸਕ ਨੂੰ ਪੂਰਾ ਕਰੋ ਬਿਨਾਂ ਕਿਸੇ ਕਦਮ ਨੂੰ ਛੱਡੇ।

ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ:

• ਨਵਾਂ ਖਾਤਾ ਬਣਾਓ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਸਾਈਨ-ਅਪ ਸਪਸ਼ਟ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ
• ਲੌਗ ਆਉਟ ਕਰੋ ਅਤੇ ਮੁੜ ਲੌਗਇਨ ਕਰਕੇ ਦੇਖੋ ਕਿ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਲੌਗਿਨ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿ ਨਹੀਂ
• ਪਾਸਵਰਡ ਰੀਸੈਟ ਵਰਤੋ ਅਤੇ ਦੂਜਾ ਕਦਮ ਸਪਸ਼ਟ ਹੈ ਕਿ ਨਹੀਂ ਇਹ ਜਾਂਚੋ
• ਐਪ ਦਾ ਮੁੱਖ ਐਕਸ਼ਨ ਸ਼ੁਰੂ ਤੋਂ ਲੈ ਕੇ ਅੰਤ ਤੱਕ ਪੂਰਾ ਕਰੋ
• ਤੁਸੀਂ ਜੋ ਬਣਾਇਆ ਉਸਨੂੰ ਬਦਲੋ ਜਾਂ ਮਿਟਾਓ ਅਤੇ ਨਤੀਜੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਖੁਸ਼ੀ ਵਾਲਾ ਰਾਹ ਇੱਕ ਵਾਰ ਕੰਮ ਕਰਨ 'ਤੇ ਰੁਕੋ ਨਾ। ਇੱਕ ਟਾਸਕ ਦੇ ਦੌਰਾਨ ਪੇਜ ਰੀਫਰੇਸ਼ ਕਰੋ। ਬਰਾਊਜ਼ਰ ਦਾ ਬੈਕ ਬਟਨ ਦਬਾਓ। ਮੋਬਾਈਲ 'ਤੇ ਐਪ ਨੂੰ ਬੰਦ ਕਰਕੇ ਦੁਬਾਰਾ ਖੋਲ੍ਹੋ। ਇਹ ਛੋਟੇ ਕਦਮ ਅਕਸਰ ਟੁੱਟੇ ਹਾਲਤਾਂ, ਡੁਪਲੀਕੇਟ ਐਕਸ਼ਨ, ਜਾਂ ਗੁੰਮ ਡੇਟਾ ਦਾ ਪਤਾ ਲਾਉਂਦੇ ਹਨ।

ਹਰ ਮਹੱਤਵਪੂਰਨ ਐਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਗੁੰਝਲਦਾਰੀ ਨੂੰ ਦੇਖੋ। ਜੇ ਕਿਸੇ ਨੇ ਪ੍ਰੋਫਾਈਲ ਸੇਵ ਕੀਤੀ, ਫਾਰਮ ਜਮ੍ਹਾਂ ਕੀਤਾ, ਸਮਾਂ ਬੁੱਕ ਕੀਤਾ, ਜਾਂ ਕੋਈ ਆਈਟਮ ਮਿਟਾਇਆ—ਐਪ ਨੂੰ ਤੁਰੰਤ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ: ਕੀ ਇਹ ਹੋਇਆ? ਕੀ ਬਦਲਿਆ? ਹੁਣ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

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

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

ਇੱਕ ਚੰਗਾ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਹਰ ਮੁੱਖ ਫਲੋ ਦੋ ਵਾਰ ਟੈਸਟ ਕਰੋ। ਪਹਿਲਾਂ, ਉਮੀਦ ਅਨੁਸਾਰ ਕਰੋ। ਫਿਰ ਥੋੜ੍ਹਾ ਧਿਆਨ ਘਟਾ ਕੇ ਦੁਬਾਰਾ ਕਰੋ, ਕਿਉਂਕਿ ਅਸਲ ਯੂਜ਼ਰ ਇੰਝ ਹੀ ਹੁੰਦੇ ਹਨ।

ਹਰ ਸਕ੍ਰੀਨ ਨੂੰ ਪਹਿਲੀ ਵਾਰ ਦੇ ਉਪਭੋਗਤਾ ਵਾਂਗ ਪੜ੍ਹੋ

ਆਸ਼ਚਰਜਕ ਸੰਖਿਆ ਵਿੱਚ ਲਾਂਚ ਸਮੱਸਿਆਵਾਂ ਬੱਗ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ ਸ਼ਬਦਾਂ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਕਿਸੇ ਉਪਭੋਗਤਾ ਨੇ ਰੁਕ ਕੇ ਸੋਚਿਆ, "ਜੇ ਮੈਂ ਇਸ 'ਤੇ ਟੈਪ ਕਰਾਂ ਤਾਂ ਕੀ ਹੋਏਗਾ?" ਤਾਂ ਉਸ ਸਕ੍ਰੀਨ ਨੇ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਮੰਗ ਕੀਤੀ ਹੈ।

ਧੀਰੇ ਹੋਵੋ ਅਤੇ ਹਰ ਸਕ੍ਰੀਨ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪੜ੍ਹੋ ਜਿਵੇਂ ਤੁਸੀਂ ਕਦੇ ਉਤਪਾਦ ਨਹੀਂ ਵੇਖਿਆ। ਜਿਸ ਫੀਚਰ ਨੂੰ ਇਹ ਕਰਨ ਲਈ ਬਣਿਆ ਗਿਆ ਹੈ ਉਸਨੂੰ ਭੁੱਲ ਜਾਓ ਅਤੇ ਧਿਆਨ ਦਿਓ ਕਿ ਸ਼ਬਦ ਨਵੇਂ ਵਿਅਕਤੀ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਦੱਸਦੇ ਹਨ।

ਬਟਨਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਪੁੱਛੋ, "ਕੀ ਇਹ ਲੇਬਲ ਨਤੀਜੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ?" "Continue" ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ। "Create account", "Book slot", ਜਾਂ "Send request" ਜਿਹੇ ਵਾਕ ਉਪਭੋਗਤਾ ਨੂੰ ਅਗਲਾ ਕਦਮ ਸਪਸ਼ਟ ਦੱਸਦੇ ਹਨ।

ਇਹੀ ਨਿਯਮ ਹੈਡਿੰਗਜ਼, ਮੈਨੂ ਲੇਬਲ ਅਤੇ ਫਾਰਮ ਫੀਲਡਾਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਸ਼ਬਦ ਤਦੋਂ ਹੀ ਚੰਗੇ ਹਨ ਜਦੋਂ ਉਹ ਵਿਸ਼ੇਸ਼ ਹੋਣ। "Details" ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦਾ ਹੁੰਦਾ ਹੋ ਸਕਦਾ ਹੈ। "Booking details" ਜਾਂ "Company details" ਸ਼ੱਕ ਦੂਰ ਕਰ ਦਿੰਦੇ ਹਨ।

ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੋਵੇ, ਸੁਨੇਹਾ ਯੂਜ਼ਰ ਨੂੰ ਵਾਪਸੀ ਦਾ ਰਸਤਾ ਦਿਖਾਏ। "Error occurred" ਬੇਕਾਰ ਹੈ। "Card was declined. Try another payment method" ਇੱਕ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ ਦਿੰਦਾ ਹੈ।

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

ਹਰ ਮੁੱਖ ਸਕ੍ਰੀਨ 'ਤੇ ਇਹ ਪਲ ਦੇਖੋ:

• ਬਟਨ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਕਰਣਗੇ
• ਹੈਡਿੰਗ ਪੰਨੇ ਦਾ ਮਕਸਦ ਸਪਸ਼ਟ ਬਣਾਂਦੇ ਹਨ
• ਐਰਰ ਸੁਨੇਹੇ ਸਮੱਸਿਆ ਅਤੇ ਹੱਲ ਦੋਵੇਂ ਦੱਸਦੇ ਹਨ
• ਖਾਲੀ ਹਾਲਤ ਉਪਭੋਗਤਾ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਤਰੀਕਾ ਦਿਖਾਉਂਦੀ ਹੈ
• ਪੁਸ਼ਟੀ ਸੁਨੇਹੇ ਇਸ ਗੱਲ ਦਾ ਸੰਦੇਹ ਨਹੀਂ ਛੱਡਦੇ ਕਿ ਕੀ ਹੋਇਆ

ਪੁਸ਼ਟੀ ਸੁਨੇਹੇ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ, ਪਰ ਉਹ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਕਿਸੇ ਨੇ ਭੁਗਤਾਨ ਕੀਤਾ, ਫਾਰਮ ਜਮ੍ਹਾਂ ਕੀਤਾ, ਜਾਂ ਕੋਈ ਆਈਟਮ ਮਿਟਾਇਆ—ਉਹਨਾਂ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਾਰਵਾਈ ਹੋ ਗਈ। "Saved" ਠੀਕ ਹੈ। "Booking confirmed for Tuesday at 3:00 PM" ਹੋਰ ਵਧੀਆ ਹੈ।

ਡੀਫਾਲਟ ਅਤੇ ਖਾਲੀ ਹਾਲਤਾਂ ਦੀ ਸਮੀਖਿਆ

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

ਦੇਖੋ ਕਿ ਉਤਪਾਦ ਉਪਭੋਗਤਾ ਵੱਲੋਂ ਕੁਝ ਵੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਮੰਨ ਰਿਹਾ ਹੈ। ਫਿਰ ਪੁੱਛੋ ਕਿ ਇਹ ਧਾਰਣਾ ਸੁਰੱਖਿਅਤ, ਸਪਸ਼ਟ, ਅਤੇ ਬਦਲਣ ਵਿੱਚ ਆਸਾਨ ਹੈ ਕਿ ਨਹੀਂ।

ਕੀ ਪਹਲੇ-ਈ ਚੁਣਿਆ ਗਿਆ ਹੈ ਚੈਕ ਕਰੋ

ਪੂਰਨ-ਭਰਨ ਵਾਲੀ ਫੀਲਡਾਂ ਸਮਾਂ ਬਚਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਸਿਰਫ਼ ਉਹੀ ਸਥਿਤੀ ਜਦ ਉਹ ਜ਼ਿਆਦਤਰ ਉਪਭੋਗਤਿਆਂ ਲਈ ਸਹੀ ਹੋਵਨ। ਜੇ ਬੁਕਿੰਗ ਫਾਰਮ ਪਹਿਲਾਂ ਹੀ ਕੋਈ ਸਥਾਨ, ਟੀਮ ਆਕਾਰ, ਜਾਂ ਯੋਜਨਾ ਚੁਣਦਾ ਹੈ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਚੋਣ ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਮਦਦਗਾਰ ਹੈ, ਨਾ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਗਲਤ ਰਾਹ 'ਤੇ ਧਕੇਲਦੀ ਹੋਵੇ।

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

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

ਡੇਟਾ ਮੌਜੂਦ ਨਹੀਂ ਹੋਣ 'ਤੇ ਐਪ ਵੇਖੋ

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

ਇੱਕ ਚੰਗੀ ਖਾਲੀ ਹਾਲਤ ਤਿੰਨ ਗੱਲਾਂ ਕਰਦੀ ਹੈ:

• ਜੋ ਚੀਜ਼ ਮੌਜੂਦ ਨਹੀਂ ਹੈ ਉਹਦਾ ਨਾਂ ਦਿੰਦੀ ਹੈ
• ਆਮ ਬੋਲੀ ਵਿੱਚ ਅਗਲਾ ਕਦਮ ਸਮਝਾਉਂਦੀ ਹੈ
• ਇਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ ਦਿੰਦੀ ਹੈ

ਪਰਮੀਸ਼ਨ ਦੀਆਂ ਬੇਨਤੀਆਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਐਪ ਖੋਲ੍ਹਦੇ ਹੀ ਕੈਮਰਾ, ਟਿਕਾਣਾ, ਨੋਟੀਫਿਕੇਸ਼ਨ, ਜਾਂ ਸੰਪਰਕ ਪੂਛਣਾ ਠੀਕ ਨਹੀਂ ਜਦ ਤੱਕ ਕਾਰਨ ਸਪਸ਼ਟ ਨਾ ਹੋਵੇ। ਉਸ ਫੀਚਰ ਦੀ ਲੋੜ ਤੋੜੀ ਹੀ ਮੰਗੋ, ਇੱਕ ਛੋਟੀ ਵਜ੍ਹਾ ਦੇ ਕੇ।

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

ਭੁੱਲੇ ਜਾਣ ਵਾਲੇ ਐਜ ਕੇਸ ਟੈਸਟ ਕਰੋ

ਜ਼ਿਆਦਾਤਰ ਲਾਂਚ ਬੱਗ ਉਹ ਸਮੇਂ ਉभर ਕੇ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਸਭ ਕੁਝ ਠੀਕ ਨਹੀਂ ਜਾਂਦਾ। ਉਹ ਦੋਸਤੋਂ ਕੀਤੀ ਗਲਤੀਆਂ, ਕਨੈਕਸ਼ਨ ਖੋ ਜਾਣਾ, ਜਾਂ ਪੁਰਾਣੇ ਲਿੰਕ 'ਤੇ ਵਾਪਸ ਆਉਣਾ—ਇਹ ਛੋਟੀਆਂ ਨਾਕਾਮੀਆਂ ਹਨ ਪਰ ਅਕਸਰ ਲੋਕ ਇਨ੍ਹਾਂ ਕਾਰਨਾਂ ਕਰਕੇ ਛੱਡ ਦਿੰਦੇ ਹਨ।

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

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

ਇੱਕ ਬੁਕਿੰਗ ਐਪ ਚੰਗਾ ਉਦਾਹਰਨ ਹੈ। ਇੱਕ ਸਾਫ਼ ਡੇਟਾ ਨਾਲ ਇੱਕ ਸਲਾਟ ਬੁੱਕ ਕਰਨਾ ਸ਼ਾਇਦ ਠੀਕ ਹੋਵੇ—ਪਰ ਕੀ ਹੁੰਦਾ ਹੈ ਜੇ ਦੋ ਲੋਕ same ਸਮਾਂ 'ਤੇ ਬੁਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ? ਜੇ ਸਲਾਟ ਭੁੱਗਤਾਨ ਤੋਂ ਪਹਿਲਾਂ ਗੁਮ ਹੋ ਜਾਂਦਾ ਹੈ? ਜਾਂ ਜੇ ਯੂਜ਼ਰ ਵਾਪਸ ਜਾ ਕਰ ਫੀਲਡ ਸੋਧਣ ਤੋਂ ਬਾਅਦ ਫਾਰਮ ਫਿਰ ਵੀ ਜਮ੍ਹਾਂ ਹੋ ਜਾਂਦਾ ਹੈ?

ਤੁਰੰਤ ਐਜ ਕੇਸ ਜੋ ਟੈਸਟ ਕਰਨ

• ਫਾਰਮਾਂ ਨੂੰ ਮਿਸਿੰਗ ਜਾਂ ਗਲਤ ਫਾਰਮੈਟ ਡੇਟਾ ਨਾਲ ਜਮ੍ਹਾਂ ਕਰੋ
• ਡੁਪਲਿਕੇਟ ਖਾਤੇ, ਦੁਹਰਾਈਆਂ ਬੁਕਿੰਗਾਂ, ਜਾਂ ਦੁਹਰਾਈਆਂ ਪੇਮੈਂਟ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ
• ਲੰਮੇ ਟੈਕਸਟ, ਵਿਸ਼ੇਸ਼ ਅੱਖਰ, ਅਤੇ ਅਜਿਹੇ ਨਾਮ ਵਰਤੋ
• ਮਿਆਦ ਖ਼ਤਮ ਹੋ ਚੁੱਕੇ ਪਾਸਵਰਡ ਰੀਸੈਟ ਜਾਂ ਇੰਵਾਈਟ ਲਿੰਕ ਖੋਲ੍ਹੋ
• ਟਾਸਕ ਦੇ ਅੱਧੇ ਵਿਚ ਪੇਜ ਰੀਫਰੇਸ਼ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕੀ ਸੰਭਾਲਿਆ ਗਿਆ

ਕਨੈਕਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਵੀ ਮੈਟਰ ਕਰਦੀਆਂ ਹਨ। ਐਪ ਨੂੰ ਸਿਰਫ਼ ਤੇਜ਼ ਓਫ਼ਿਸ Wi‑Fi 'ਤੇ ਨਹੀਂ, ਧੀਮੀ ਇੰਟਰਨੈੱਟ 'ਤੇ ਵੀ ਟੈਸਟ ਕਰੋ। ਪੰਨੇ ਬਿਨਾਂ ਵਜ੍ਹਾ ਨਹੀਂ ਫ੍ਰੀਜ਼ ਕਰਨੇ ਚਾਹੀਦੇ। ਸਕ੍ਰੀਨ ਲੋਡ ਹੋਣ 'ਚ ਕੁਝ ਵਖਤ ਜੇ ਲੱਗੇ ਤਾਂ ਬਟਨਾਂ ਨੂੰ ਦੋ ਵਾਰੀ ਜਮ੍ਹਾਂ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।

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

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

ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਖੁਸ਼ੀ ਵਾਲਾ ਰਾਹ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਡੈਮੋ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ। ਐਜ ਕੇਸ ਦੱਸਦੇ ਹਨ ਕਿ ਉਤਪਾਦ ਅਸਲ ਲੋਕਾਂ ਲਈ ਤਿਆਰ ਹੈ ਕਿ ਨਹੀਂ।

ਫਾਊਂਡਰਾਂ ਦੀਆਂ ਆਮ ਗਲਤੀਆਂ

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

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

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

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

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

ਹੇਸੈਟੇਸ਼ਨ ਨੂੰ ਧਿਆਨ ਨਾਲ ਦੇਖੋ, ਸਿਰਫ਼ ਐਰਰ ਨਹੀਂ। ਜੇ ਕੋਈ ਵਿਅਕਤੀ ਪੰਜ ਸਕਿੰਟ ਲਈ ਠਹਿਰ ਕੇ ਪੁੱਛਦਾ ਹੈ, "ਜੇ ਮੈਂ ਇਸ 'ਤੇ ਟੈਪ ਕਰਾਂ ਤਾਂ ਕੀ ਹੋਏਗਾ?" ਤਾਂ ਇਹ ਵੀ ਗੁਣਵੱਤਾ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਨਿਸ਼ਾਨ ਜੋ ਲਾਇਕੀਟ ਕੀਤੇ ਜਾਂਣ:

• ਵਾਰ-ਵਾਰ ਪਿੱਛੇ ਮੁੜਨਾ
• ਇੱਕ ਕਲਿੱਕ ਤੋਂ ਪਹਿਲਾਂ ਲੰਮਾ ਰੁਕਣਾ
• ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਬਾਰੇ ਸਵਾਲ
• ਡੀਫਾਲਟ ਸੈਟਿੰਗਜ਼ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਭਰਮ
• ਫਾਰਮਾਂ ਦਾ ਅੰਤ ਦੇ ਨੇੜੇ ਛੱਡ ਦਿੱਤਾ ਜਾਣਾ

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

ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੁਰੰਤ ਚੈਕਲਿਸਟ

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

ਧੀਰੇ ਚਲੋ। ਜੇ ਤੁਸੀਂ ਰੁਕੇ, ਅਣਿਸ਼ਚਿਤ ਮਹਿਸੂਸ ਕੀਤਾ, ਜਾਂ ਅਨੁਮਾਨ ਲਾਇਆ—ਇਸਨੂੰ ਲਿਖੋ। ਇਹ ਛੋਟੇ ਲਹਜ਼ੇ ਅਕਸਰ ਬਾਅਦ ਵਿੱਚ ਸਪੋਰਟ ਟਿਕਟ ਬਣ ਜਾਂਦੇ ਹਨ।

ਪੰਜ ਚੈਕ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਫੜ ਲੈਂਦੇ ਹਨ

• ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਵੇਖੋ ਕਿ ਨਵਾਂ ਉਪਭੋਗਤਾ ਬਿਨਾਂ ਮਦਦ ਦੇ ਮੁੱਖ ਟਾਸਕ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਨਹੀਂ।
• ਜਾਣ-ਬੂਝ ਕੇ ਕੁਝ ਸਧਾਰਣ ਗਲਤੀਆਂ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ ਐਪ ਸਮੱਸਿਆ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਨਹੀਂ।
• ਕੀਮਤਾਂ, ਤਾਰੀਖਾਂ, ਸਮਿਆਂ, ਟੋਟਲ ਅਤੇ ਯੋਜਨਾਵਾਂ ਦੇ ਨਾਮਾਂ ਨੂੰ ਨਜ਼ਦੀਕ ਤੋਂ ਵੇਖੋ। ਇਹ ਵਿਵਰਣ ਆਸਾਨੀ ਨਾਲ ਸਕੈਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਗਲਤ ਫ਼ਹਮੀ ਰੋਕਣੇ ਚਾਹੀਦੇ ਹਨ।
• ਹਰ ਮਹੱਤਵਪੂਰਨ ਐਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ ਦੀ ਨਜ਼ਰ ਰੱਖੋ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਦੇ ਵੀ ਸੋਚਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, "ਕੀ ਇਹ ਹੋਇਆ?"
• ਹਰ ਸਕ੍ਰੀਨ ਨੂੰ ਛੁਪੇ ਹੋਏ ਧਾਰਣਾਂ ਲਈ ਸਕੈਨ ਕਰੋ। ਜੇ ਕੋਈ ਲੇਬਲ ਅਸਪਸ਼ਟ ਹੈ ਜਾਂ ਖਾਲੀ ਹਾਲਤ ਕੋਈ ਅਗਲਾ ਕਦਮ ਨਹੀਂ ਦਿਖਾਉਂਦੀ, ਤਾਂ ਐਪ ਹਾਲੇ ਵੀ ਲੋਕਾਂ ਤੋਂ ਅਨੁਮਾਨ ਲਗਵਾਉਂਦੀ ਹੈ।

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

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

ਇੱਕ ਆਖਰੀ ਚੈੱਕ ਬਹੁਤ ਮਦਦਗਾਰ ਹੈ। ਟੀਮ ਤੋਂ ਬਾਹਰ ਕਿਸੇ ਨੂੰ ਐਪ ਅਦਾਇਗੀ ਬਿਨਾਂ ਦੱਸਿਆ ਦਿਓ। ਚੁੱਪ ਰਹੋ, ਉਹ ਕਿੱਥੇ ਰੁਕਦੇ ਹਨ ਉਹ ਦੇਖੋ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਸਹੀ ਸਵਾਲ ਲਿਖੋ।

ਉਦਾਹਰਨ: ਇੱਕ ਸਰਲ ਬੁਕਿੰਗ ਐਪ ਰਿਵਿਊ

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

ਪਹਿਲੀ ਸਕ੍ਰੀਨ 'ਤੇ ਸ਼ੁਰੂ ਕਰੋ। ਕੀ ਇਹ ਸਪਸ਼ਟ ਹੈ ਕਿ ਐਪ ਤੁਹਾਨੂੰ ਕੀ ਬੁਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਇਹ ਕਿੰਨੀ ਦੇਰ ਲਵੇਗਾ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ? ਜੇ ਕਿਸੇ ਨੂੰ ਪਹਿਲੇ ਬਟਨ 'ਤੇ ਟੈਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜ਼ਿਆਦਾ ਸੋਚਣਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਗੁਣਵੱਤਾ ਸਮੱਸਿਆ ਹੈ।

ਫਿਰ ਪੂਰੇ ਰਸਤੇ ਤੋਂ ਪੁਸ਼ਟੀਬੱਧ ਬੁਕਿੰਗ ਤੱਕ ਜਾਓ। ਇੱਕ ਸੇਵਾ ਚੁਣੋ, ਮਿਤੀ ਚੁਣੋ, ਸਮਾਂ ਚੁਣੋ, ਵੇਰਵੇ ਦਿਓ, ਅਤੇ ਬੁਕਿੰਗ ਪੂਰੀ ਕਰੋ। ਵੇਖੋ: ਕੀ ਸਮਾਂ-ਸਲਾਟ ਸਪਸ਼ਟ ਹਨ ਪਰ ਬੁਕ ਨਹੀਂ ਹੋ ਸਕਦੇ? ਕੀ ਬਟਨ ਵਿਆਖਿਆ ਬਿਨਾਂ ਬੇਨਤੀ ਰੂਪ ਤੋਂ ਡਿਏਬਲਡ ਰਹਿ ਜਾਂਦੇ ਹਨ? ਕੀ ਫਾਰਮ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਾਣਕਾਰੀਆਂ ਪਹਿਲਾਂ ਹੀ ਮੰਗਦਾ ਹੈ? ਕੀ ਪੁਸ਼ਟੀ ਸਕ੍ਰੀਨ ਇਹ ਸਪਸ਼ਟ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਅਗਲੇ ਕਦਮ ਕੀ ਹਨ?

ਫਿਰ ਵਾਪਸ ਜਾ ਕੇ ਬੁਕਿੰਗ ਬਦਲੋ। ਇੱਥੇ ਕਈ ਐਪ ਪਹਿਲਾਂ ਠੀਕ ਲੱਗਦੇ ਹਨ, ਅਗਲੇ ਕਦਮ 'ਚ ਟੁਟ ਜਾਂਦੇ ਹਨ। ਕੀ ਯੂਜ਼ਰ ਮੁੜ-ਸਮੀਕਰਨ ਕਰ ਸਕਦਾ ਬਿਨਾਂ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੇ? ਜੇ ਉਹ ਦੂਜੇ ਦਿਨ 'ਤੇ ਸਵਿਚ ਕਰਦਾ ਹੈ, ਕੀ ਪੁਰਾਣਾ ਸਮਾਂ ਗਲਤੀ ਨਾਲ ਅਜੇ ਵੀ ਚੁਣਿਆ ਰਹਿੰਦਾ ਹੈ? ਜੇ ਕੋਈ ਰੱਦ ਨੀਤੀ ਹੈ, ਕੀ ਇਹ ਯੂਜ਼ਰ ਨੇ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਾਈ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ?

ਭੁਗਤਾਨ ਜਾਂ ਮਨਜ਼ੂਰੀ ਨਾਲ ਸਬੰਧਤ ਹਰ ਸੁਨੇਹੇ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਪੜ੍ਹੋ। ਜੇ ਭੁਗਤਾਨ ਲਾਜ਼ਮੀ ਹੈ, ਤਦ ਐਪ ਨੂੰ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਦੋਂ ਕਾਰਡ ਤੋਂ ਰਕਮ ਕਟੇਗੀ, ਕੀ refundable ਹੈ, ਅਤੇ ਜੇ ਬੇਨਤੀ ਸਿਰਫ਼ pending approval 'ਚ ਹੈ ਤਾਂ ਕੀ ਹੋਵੇਗਾ। "submitted", "confirmed", ਅਤੇ "reserved" ਵਰਗੇ ਸ਼ਬਦ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਮਿਲਦੇ ਜੁਲਦੇ ਲੱਗ ਸਕਦੇ ਹਨ ਪਰ ਨਵੇਂ ਉਪਭੋਗਤਾ ਲਈ ਇਹ ਵਖਰੇ ਮਤਲਬ ਰੱਖਦੇ ਹਨ।

ਹੁਣ ਅਜਿਹੇ awkward ਪਲ ਟੈਸਟ ਕਰੋ। ਜੇ ਇਸ ਹਫ਼ਤੇ ਕੋਈ ਸਲਾਟ ਨਹੀਂ, ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਇੱਕ ਖਾਲੀ ਕੈਲੰਡਰ ਜਾਂ dead-end ਸੁਨੇਹਾ ਲੋਕਾਂ ਨੂੰ ਬਾਹਰ ਭੇਜ ਦੇਵੇਗਾ। ਇੱਕ ਬਿਹਤਰ ਸੰਸਕਰਣ ਅਗਲਾ ਉਪਲਬਧ ਦਿਨ ਦਿਖਾਉਂਦੀ ਹੈ ਜਾਂ ਕਿਸੇ ਹੋਰ ਵਿਕਲਪ ਦੀ ਸਪਸ਼ਟ ਹਦਾਇਤ ਦਿੰਦੀ ਹੈ।

ਆਖਰੀ ਜਾਂਚ ਸਧਾਰਨ ਹੈ: ਨੋਟ ਕਰੋ ਕਿ ਨਵੇਂ ਉਪਭੋਗਤਾ ਕਿੱਥੇ ਰੁਕ ਸਕਦਾ ਹੈ। ਸ਼ਾਇਦ ਟਾਈਮ ਪਿਕਰ ਗੁੰਝਲਦਾਰ ਹੋਵੇ, ਕੀਮਤ ਬਹੁਤ ਦੇਰ ਨਾਲ ਦਿਖਾਈ ਦੇਵੇ, ਜਾਂ ਪੁਸ਼ਟੀ ਸੁਨੇਹਾ ਬਹੁਤ ਅਸਪਸ਼ਟ ਹੋਵੇ। ਇਹ ਛੋਟੇ ਬਿੰਦੂ ਅਕਸਰ ਉਸ ਕਾਰਨ ਹੁੰਦੇ ਹਨ ਕਿ ਬੁਕਿੰਗਾਂ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਡ੍ਰੌਪ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

ਅਗਲੇ ਕਦਮ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ

ਇਸ ਮੋੜ 'ਤੇ, ਤੁਹਾਨੂੰ ਹੋਰ ਰਾਏ ਨਹੀਂ ਚਾਹੀਦੀਆਂ। ਤੁਹਾਨੂੰ ਇਕ ਸਾਫ਼ ਕੰਮਾਂ ਦੀ ਤਰਤੀਬ ਚਾਹੀਦੀ ਹੈ। ਜ਼ਰੂਰੀ ਗਲਤੀਆਂ ਠੀਕ ਕਰੋ ਜਿਹੜੀਆਂ ਸਾਈਨ-ਅਪ, ਭੁਗਤਾਨ, ਬੁਕਿੰਗ, ਜਾਂ ਖਾਤੇ ਤੱਕ ਪਹੁੰਚ ਰੋਕਦੀਆਂ ਹਨ—ਫਿਰ ਛੋਟੀ ਲਿਖਤੀਆਂ ਜਾਂ ਵਿਜ਼ੂਅਲ ਪਾਲਿਸ਼ ਤੇ ਜਾਓ।

ਟਾਈਪੋ ਵੀ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਟੁੱਟਿਆ ਹੋਇਆ ਮੁੱਖ ਫਲੋ ਨਹੀਂ।

ਫਿਰ ਕੁਝ ਤਾਜ਼ਾ ਟੈਸਟ ਕਰਨ ਵਾਲੇ ਲੈਓ। ਉਹ ਲੋਕ ਜੋ ਪਹਿਲਾਂ ਐਪ ਵੇਖ ਚੁੱਕੇ ਹਨ, ਅਕਸਰ ਵਿਵਹਾਰਕ ਵੱਖਰੇ ਹੱਲ ਜਾਣ ਲੈਂਦੇ ਹਨ ਬਿਨਾਂ ਮਹਿਸੂਸ ਕੀਤੇ। 3‑5 ਨਵੀਂ ਲੋਕਾਂ ਨੂੰ ਕਹੋ ਕਿ ਉਹ ਮੁੱਖ ਟਾਸਕ ਆਪਣੇ ਆਪ ਪੂਰਾ ਕਰਨ ਅਤੇ ਆਪਾਂ ਚੁੱਪ ਰਹੋ।

ਛੋਟੀ-ਛੋਟੀ ਸਮੱਸਿਆਵਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਜੇ ਉਹ ਰੁਕਦੇ ਹਨ, ਲੇਬਲ ਫਿਰ ਤੋਂ ਪੜ੍ਹਦੇ ਹਨ, ਗਲਤ ਬਟਨ 'ਤੇ ਟੈਪ ਕਰਦੇ ਹਨ, ਜਾਂ ਪੁੱਛਦੇ ਹਨ ਕਿ ਅਗਲੇ ਕਦਮ ਕੀ ਹਨ, ਤਾਂ ਇਹ ਲਾਭਦਾਇਕ ਫੀਡਬੈਕ ਹੈ।

ਹਰ ਫਿਕਸ ਤੋਂ ਬਾਅਦ ਪੂਰੀ ਯਾਤਰਾ ਨੂੰ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ, ਸਿਰਫ਼ ਉਸ ਸਕ੍ਰੀਨ ਨੂੰ ਨਹੀਂ ਜਿੱਥੇ ਸਮੱਸਿਆ ਆਈ। ਲੌਗਿਨ, ਫਾਰਮ ਨਿਯਮ, ਕੀਮਤਾਂ, ਜਾਂ ਨੇਵੀਗੇਸ਼ਨ ਵਿੱਚ ਕੀਤੀ ਗਈ ਕੋਈ ਬਦਲਾਅ ਦੋ ਕਦਮ ਬਾਅਦ ਨਵੀਂ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ।

ਇੱਕ ਸਧਾਰਣ ਰਿਲੀਜ਼ ਕ੍ਰਮ ਮਦਦਗਾਰ ਹੈ:

• ਰੋਕਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ, ਫਿਰ ਛੋਟੀ ਲਿਖਤੀਆਂ ਜਾਂ ਡਿਜ਼ਾਈਨ ਸੋਧ
• ਕੁਝ ਨਵੇਂ ਟੈਸਟ ਕਰਨ ਵਾਲਿਆਂ ਨੂੰ ਕਹੋ core flow ਦੁਹਰਾਉਣ ਲਈ
• ਹਰ ਫਿਕਸ ਤੋਂ ਬਾਅਦ ਸਬੰਧਤ ਕਦਮ ਦੁਬਾਰਾ ਚੈੱਕ ਕਰੋ
• ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ ਸਮੂਹ ਨੂੰ ਲਾਂਚ ਕਰੋ, ਫਿਰ ਮੁੱਖ ਫਲੋ ਸਥਿਰ ਹੋਣ 'ਤੇ ਵਿਸਤਾਰ ਕਰੋ

ਜੇ ਤੁਸੀਂ Koder.ai 'ਚ ਬਣਾ ਰਹੇ ਹੋ, late changes ਲਈ planning mode ਵਰਤੋ ਅਤੇ live ਵਿਹਾਰ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ snapshots ਰੱਖੋ। ਇਸ ਨਾਲ ਰੋਲਬੈਕ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜੇ ਆਖ਼ਰੀ-ਮਿੰਟ ਫਿਕਸ ਕੋਈ ਨਵੀਂ ਸਮੱਸਿਆ ਬਣਾਏ।

ਐਪ ਨੂੰ ਪੂਰਨ ਮਹਿਸੂਸ ਹੋਣ ਦੀ ਉਡੀਕ نہ ਕਰੋ। ਛੋਟੇ ਪੈਮਾਨੇ 'ਤੇ ਲਾਂਚ ਕਰੋ, ਫੀਡਬੈਕ ਇਕੱਠਾ ਕਰੋ, ਅਤੇ ਬੇਤਰ ਬਣਾਉ। ਨਿਯੰਤ੍ਰਿਤ ਲਾਂਚ ਅਤੇ ਅਸਲ ਯੂਜ਼ਰਾਂ ਤੋਂ ਮਿਲਦੇ ਨੋਟ ਤੁਹਾਨੂੰ ਹੋਰ ਸਿਖਾਉਣਗੇ ਬਿਨਾਂ ਹੋਰ ਲੰਬੇ ਅੰਤਰਕੁਲੀ ਸਮੀਖਿਆਂ ਦੇ।