05 ਅਗ 2025·8 ਮਿੰਟ
ਨੀਲਸਨ ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ: ਤੇਜ਼ ਸਮੀਖਿਆ ਟੈਂਪਲੇਟ
ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਨਾਲ ਇੱਕ ਤੇਜ਼ UX ਸਮੀਖਿਆ ਚਲਾਓ, ਆਮ ਸਮੱਸਿਆਵਾਂ ਜਲਦੀ ਫੜੋ, ਅਤੇ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਐਪਸ ਨੂੰ ਵਰਤੋਂ-ਯੋਗ ਰੱਖੋ।
ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਨਾਲ ਇੱਕ ਤੇਜ਼ UX ਸਮੀਖਿਆ ਚਲਾਓ, ਆਮ ਸਮੱਸਿਆਵਾਂ ਜਲਦੀ ਫੜੋ, ਅਤੇ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਐਪਸ ਨੂੰ ਵਰਤੋਂ-ਯੋਗ ਰੱਖੋ।
ਜ਼ਿਆਦਾਤਰ ਰਿਲੀਜ਼-ਦਿਨ ਦੇ UX ਸਮੱਸਿਆਵਾਂ ਵੱਡੇ ਰੀਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਛੋਟੀਆਂ, ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਣ ਵਾਲੀਆਂ ਜਾਣਕਾਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਅਸੀਂ ਰੀਅਲ ਟਾਸਕ ਖਤਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਿਆਂ ਸਮੇਤ ਆਉਂਦੀਆਂ ਹਨ। ਨਤੀਜਾ ਪੈੱਲ ਅਨੁਮਾਨਤ ਹੈ: ਵੱਧ ਸਪੋਰਟ ਟਿਕਟਾਂ, ਵੱਧ churn, ਅਤੇ ਵੱਧ "ਤੇਜ਼ ਠੀਕਆਂ" ਜੋ ਇਕੱਠੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਟੀਮਾਂ ਇਹਨਾਂ ਮੁੱਦਿਆਂ ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਥੋੜ੍ਹਾ ਪਹਿਲਾਂ ਮਿਸ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰੋਡਕਟ ਬਣਾਉਣ ਵਾਲਿਆਂ ਲਈ ਇਹ ਪਹਿਲਾਂ ਹੀ ਸਮਝ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ। ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਬਟਨ ਦਾ ਕੀ ਕੰਮ ਹੈ, ਲੇਬਲ ਦਾ ਕੀ ਅਰਥ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਵੇਂ ਉਪਭੋਗਤਾਂ ਕੋਲ ਉਹ ਪ੍ਰਸੰਗ ਨਹੀਂ ਹੁੰਦਾ।
ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲ ਰਹੇ ਹੋ, ਉਹੀ ਕਿਸਮਾਂ ਦੀਆਂ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਸਮੱਸਿਆਵਾਂ ਮੁੜ ਮੁੜ ਆਉਂਦੀਆਂ ਹਨ: ਐਸੇ ਸਕਰੀਨ ਜਿੱਥੇ ਅਗਲਾ ਸਪੱਸ਼ਟ ਕਦਮ ਨਹੀਂ, ਫੀਡਬੈਕ ਦੀ ਘਾਟ (ਕੀ ਸੇਵ ਹੋਇਆ, ਸਬਮਿਟ ਹੋਇਆ, ਜਾਂ ਫੇਲ?), ਐਸੇ ਐਰਰ ਸੁਨੇਹੇ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਦੋਸ਼ ਦਿੰਦੇ ਬਿਨਾਂ ਕੋਈ ਰਾਹ ਨਹੀਂ ਦਿਖਾਉਂਦੇ, ਨਿਯੰਤਰਣ ਜੋ ਕਲਿੱਕਯੋਗ ਲੱਗਦੇ ਪਰ ਨਹੀਂ ਹਨ, ਅਤੇ ਵਾਕ-ਚੋਣ ਜਿਹੜੀ ਸਕ੍ਰੀਨ-ਵਾਰ ਬਦਲਦੀ ਹੈ (Sign in vs Log in) ਅਤੇ ਧੀਰੇ-ਧੀਰੇ ਭਰੋਸਾ ਖ਼ਰਾਬ ਕਰ ਦਿੰਦੀ ਹੈ।
ਛੋਟੀ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੀ ਸਮੀਖਿਆ ਇੱਕ ਲੰਮੇ ਇਕ-ਵਾਰ ਆਡਿਟ ਤੋਂ ਬੇਹਤਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸ਼ਿਪਿੰਗ ਦੀ ਰਿਧਮ ਵਿੱਚ ਫਿਟ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਹਰ ਰਿਲੀਜ਼ 'ਤੇ ਉਹੀ ਜਾਂਚ ਕਰ ਸਕਦੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਆਮ ਗਲਤੀਆਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਸਸਤੇ ਸਮੇਂ ਵਿੱਚ ਫੜ ਲੈਂਦੇ ਹੋ।
ਇਥੇ Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਮਦਦ ਕਰਦੇ ਹਨ। ਇਹ ਆਮ-ਅਮਲੀ ਨਿਯਮ ਹਨ ਜੋ ਪਹਿਲੇ ਦੌਰ 'ਤੇ ਸਪਸ਼ਟ UX ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਛਾਣਣ ਲਈ ਨੇ। ਇਹ ਯੂਜ਼ਰ ਟੈਸਟਿੰਗ, ਖੋਜ, ਜਾਂ ਐਨਾਲਿਟਿਕਸ ਦੀ ਥਾਂ ਨਹੀਂ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਤੇਜ਼ ਸੁਰੱਖਿਆ ਜਾਂਚ ਸਮਝੋ: ਇਹ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਨਗੇ ਕਿ ਡਿਜ਼ਾਈਨ ਬੇਹਤਰੀਨ ਹੈ, ਪਰ ਅਕਸਰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਲੋਕ ਕਿਉਂ ਅਟਕ ਜਾਂਦੇ ਹਨ।
ਤੁਹਾਨੂੰ ਇੱਕ ਸਧਾਰਣ ਯੂਜ਼ੇਬਿਲਟੀ ਸਮੀਖਿਆ ਟੈਂਪਲੇਟ ਮਿਲੇਗਾ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕਦੇ ਹੋ, ਨਾਲ ਹੀ ਆਧੁਨਿਕ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਫਲੋਅ ਉਦਾਹਰਣਾਂ, ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਸਭ ਤੋਂ ਆਮ UX ਗਲਤੀਆਂ ਉਪਭੋਗਤਿਆਂ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰ ਸਕੇ।
Jakob Nielsen ਇੱਕ ਯੂਜ਼ੇਬਿਲਟੀ ਰਿਸਰਚਰ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਇੱਕ ਅਮਲੀ ਵਿਚਾਰ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ: ਜ਼ਿਆਦਾਤਰ UX ਸਮੱਸਿਆਵਾਂ ਰਹੱਸਮਈ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਉਤਪਾਦਾਂ ਵਿੱਚ ਦੁਹਰਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਉਸ ਦੇ 10 ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਸਧਾਰਨ-ਸਮਝ ਨਿਯਮ ਹਨ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਉਪਭੋਗਤਾ ਇੱਕ ਇੰਟਰਫੇਸ ਵਰਤਣ ਵੇਲੇ ਕੀ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਸਾਫ਼ ਫੀਡਬੈਕ ਮਿਲਣਾ, ਨਿਯੰਤਰਣ ਵਿੱਚ ਰਹਿਣਾ, ਅਤੇ ਚੀਜ਼ਾਂ ਯਾਦ ਰੱਖਣ 'ਤੇ ਮਜ਼ਬੂਰ ਨਾ ਕੀਤਾ ਜਾਣਾ।
ਇਹ ਆਧੁਨਿਕ ਐਪਾਂ 'ਤੇ ਵੀ ਫਿੱਟ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਮਨੁੱਖੀ ਵਿਹਾਰ ਦੀਆਂ ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਬਦਲੀ ਨਹੀਂਆਂ। ਲੋਕ ਤੁਰੰਤ ਸਕਿੰਮ ਕਰਦੇ ਹਨ, ਵੇਰਵੇ ਗੁਆਉਂਦੇ ਹਨ, ਗਲਤ ਜਗ੍ਹਾ ਟੈਪ ਕਰਦੇ ਹਨ, ਅਤੇ ਜਦ ਉਹ ਸੋਚਦੇ ਹਨ ਕਿ ਉਹਨੇ ਕੰਮ ਗੁਆ ਦਿੱਤਾ ਤਾਂ ਘਬਰਾਂਦੇ ਹਨ। ਚਾਹੇ ਵੈਬ ਡੈਸ਼ਬੋਰਡ ਹੋਵੇ, ਮੋਬਾਈਲ ਚੈਕਆਉਟ ਹੋਵੇ, ਜਾਂ ਸੈਟਿੰਗ ਸਕ੍ਰੀਨ, ਉਹੀ ਸਮੱਸਿਆਵਾਂ ਆਉਂਦੀਆਂ ਹਨ: ਅਸਪਸ਼ਟ ਸਥਿਤੀ, ਉਲਝਣ ਵਾਲੇ ਲੇਬਲ, ਲੁਕੀਆਂ ਕਾਰਵਾਈਆਂ, ਅਤੇ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਅਸੰਗਤ ਵਿਹਾਰ।
ਤੁਹਾਨੂੰ ਹੁਣ ਦੇ ਉਤਪਾਦਾਂ ਲਈ ਹਿਊਰਿਸਟਿਕਸ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮੋਬਾਈਲ 'ਤੇ ਛੋਟੇ ਸਕ੍ਰੀਨ ਰਿਕਗਨਿਸ਼ਨ ਨੂੰ ਯਾਦ ਰੱਖਣ 'ਤੇ ਤਰਜੀਹ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਗਲਤੀਆਂ ਰੋਕਣ ਲੇਆਉਟ, ਅੰਗੂਠੇ ਦੀ ਪਹੁੰਚ ਅਤੇ ਮੁਆਫ ਕਰਨ ਵਾਲੇ ਇਨਪੁੱਟ ਬਾਰੇ ਹੋਰ ਪ੍ਰਾਥਮਿਕ ਹੁੰਦੀ ਹੈ। ਬਹੁ-ਕਦਮੀ ਫਲੋਜ਼ (signup, onboarding, payments) ਵਿੱਚ ਯੂਜ਼ਰ ਨਿਯੰਤਰਣ ਅਤੇ ਆਜ਼ਾਦੀ ਦਾ ਮਤਲਬ ਸੇਫ਼ ਬੈਕ ਐਕਸ਼ਨ, ਸੰਭਾਲੀ ਹੋਈ ਪ੍ਰਗਤੀ, ਅਤੇ ਕੋਈ ਝਟਕਾ ਨਹੀਂ ਜਦ ਇੱਕ ਕਦਮ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਭਾਵ ਪਾਂਦਾ ਹੈ। AI ਫੀਚਰਾਂ ਵਿੱਚ, visibility of system status ਸਿਰਫ਼ ਇਕ ਸਪੀਨਰ ਨਹੀਂ ਹੈ—ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਜਾਣਨਾ ਲੋੜੀ ਹੈ ਕਿ ਸਿਸਟਮ ਕੀ ਕਰ ਰਹਾ ਹੈ, ਕੀ ਵਰਤਿਆ ਗਿਆ, ਅਤੇ ਜਦ ਨਤੀਜੇ ਗਲਤ ਲੱਗਦੇ ਹਨ ਤਾਂ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।
ਹਿਊਰਿਸਟਿਕਸ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਵੀ ਦਿੰਦੇ ਹਨ। ਡਿਜ਼ਾਇਨਰ consistency ਅਤੇ standards ਦੀ ਗੱਲ ਕਰ ਸਕਦੇ ਹਨ ਬਜਾਏ ਸਵਾਦ ਦੇ बहਸ ਕਰਨ ਦੇ। ਪ੍ਰੋਡਕਟ ਮੁੱਦਿਆਂ ਨੂੰ ਡ੍ਰੌਪ-ਆਫ ਜਾਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ ਐਰਰ ਰਿਕਵਰ리를 ਨਿਰਧਾਰਤ ਟਾਸਕਾਂ (ਚੰਗੀ ਵੈਲੀਡੇਸ਼ਨ, ਸਾਫ਼ ਸੁਨੇਹੇ, ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ) ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਹਰ ਕੋਈ ਇੱਕੋ ਸ਼ਬਦ ਵਰਤਦਾ ਹੈ, ਤਾਹਨ ਪਹਿਲਾਂ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ, ਉਸ 'ਤੇ ਸਹਿਮਤੀ ਆਉਣੀ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇਹ ਪਹਿਲੇ ਚਾਰ Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਬਹੁਤ ਸਾਰੀ ਰੋਜ਼ਾਨਾ ਘਰੜੀ ਫ੍ਰਿਕਸ਼ਨ ਫੜ ਲੈਂਦੇ ਹਨ। ਤੁਸੀਂ ਇੱਕ-ਦੋ ਮਿੰਟਾਂ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਦੋਹਾਂ 'ਤੇ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਪੂਰੇ ਯੂਜ਼ਰ ਟੈਸਟ ਤੋਂ ਪਹਿਲਾਂ।
ਲੋਕਾਂ ਨੂੰ ਕਦੇ ਇਹ ਸੋਚਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, "ਕੀ ਇਹ ਕੰਮ ਕੀਤਾ?" ਲੋਡਿੰਗ, ਸੇਵਿੰਗ, ਅਤੇ ਖਤਮ ਹੋਣ ਲਈ ਸਪਸ਼ਟ ਫੀਡਬੈਕ ਦਿਖਾਓ।
ਸਰਲ ਟੈਸਟ: ਧੀਮੀ ਕਨੈਕਸ਼ਨ 'ਤੇ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ (Save, Pay, Send) ਨੂੰ ਟੈਪ ਕਰੋ। ਜੇ UI ਇੱਕ ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਇਕਸਾਰ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਇਕ ਸੰਕੇਤ ਜੋੜੋ। ਇਹ ਸਪੀਨਰ, ਪ੍ਰੋਗ੍ਰੈਸ ਟੈਕਸਟ, ਜਾਂ ਅਸਥਾਈ ਅਪਾਹਰਿਤ ਸਥਿਤੀ ਹੋ ਸਕਦੀ ਹੈ। ਫਿਰ ਸਫਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਇੱਕ ਸੁਨੇਹੇ ਨਾਲ ਕਰੋ ਜੋ ਪੜ੍ਹਨ ਲਈ ਕਾਫੀ ਲੰਬਾ ਰਹੇ।
ਉਹ ਸ਼ਬਦ ਵਰਤੋ ਜੋ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਉਸ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖੋ ਜੋ ਮਨੁੱਖ ਸੋਚਦੇ ਹਨ।
ਉਦਾਹਰਣ: ਇੱਕ ਟਰੈਵਲ ਐਪ ਜੋ "Given name" ਅਤੇ "Surname" ਮੰਗਦਾ ਹੈ, ਕੁਝ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਗੁੰਝਲਦਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਬਹੁਤਰ ਆਡੀਅੰਸ "First name" ਅਤੇ "Last name" ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਸੀ ਨੂੰ ਵਰਤੋ। ਮੋਬਾਈਲ ਫਾਰਮਾਂ 'ਤੇ, ਖੇਤਰਾਂ ਨੂੰ ਅਸਲ ਟਾਸਕ ਵਾਂਗ ਗਰੁੱਪ ਕਰੋ: ਪਹਿਲਾਂ ਯਾਤਰੀ ਵੇਰਵੇ, ਫਿਰ ਭੁਗਤਾਨ, ਫਿਰ ਪੁਸ਼ਟੀ।
ਲੋਕ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰਾਹ ਦਿਓ।
ਮੋਬਾਈਲ 'ਤੇ, ਇਹ ਅਕਸਰ ਨੁਕਸਾਨਦਾਇਕ ਕਾਰਵਾਈ (Delete, Remove) ਤੋਂ ਬਾਦ undo ਦੀ ਘਾਟ ਵੱਜੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਲੰਬੇ ਟਾਸਕਾਂ (uploads, exports) ਲਈ ਕੋਈ cancel ਚੋਣ ਨਹੀਂ, ਇੱਕ ਬੈਕ ਕਾਰਵਾਈ ਜੋ ਫਾਰਮ ਪ੍ਰਗਤੀ ਖ਼ਤਮ ਕਰ ਦੇਵੇ, ਜਾਂ ਮੋਡਲ ਅਤੇ ਫੁੱਲ-ਸਕ੍ਰੀਨ ਫਲੋਜ਼ ਜਿਨ੍ਹਾਂ 'ਚ ਕੋਈ ਸਪੱਸ਼ਟ ਬਾਹਰ ਨਿਕਲਣ ਨਹੀਂ।
ਜੇ ਯੂਜ਼ਰ ਸਿਰਫ਼ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਕੇ ਗਲਤੀ ਸੁਧਾਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਆਉਣਗੀਆਂ।
ਸਕ੍ਰੀਨ-ਵਾਰ ਪੈਟਰਨ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ ਅਤੇ ਪਲੈਟਫਾਰਮ ਨਾਰਮਾਂ ਨਾਲ ਮੇਲ ਖਾਓ। ਜੇ ਇੱਕ ਸਕ੍ਰੀਨ "Done" ਵਰਤਦੀ ਹੈ ਅਤੇ ਦੂਜੀ "Save," ਤਾਂ ਇੱਕ ਚੁਣੋ। ਜੇ ਲਿਸਟ ਵਿੱਚ swipe-to-delete ਹੈ, ਤਾਂ delete ਨੂੰ ਦੂਜੇ ਥਾਂ 메뉴 ਦੇ ਪਿੱਛੇ ਨਹੀਂ ਛੁਪਾਉ।
ਵੈਬ 'ਤੇ ਲਿੰਕ ਲਿੰਕ ਵਰਗੇ ਲੱਗਣੇ ਚਾਹੀਦੇ ਹਨ। ਮੋਬਾਈਲ 'ਤੇ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਤਿਥੇ-ਉਮੀਦਵਾਰ ਥਾਵਾਂ 'ਤੇ ਹੋਣ। ਇਕਸਾਰਤਾ ਸਿੱਖਣ ਦਾ ਸਮਾਂ ਘਟਾਉਂਦੀ ਅਤੇ ਟਾਲ-ਯੋਗ ਵੈਬ ਐਪ UX ਗਲਤੀਆਂ ਰੋਕਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ "ਯੂਜ਼ਰ ਗਲਤੀ" ਅਸਲ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ। ਜ਼ਿਆਦਾ ਧਿਆਨ ਓਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਦਿਓ ਜਿੱਥੇ ਇੰਟਰਫੇਸ ਲੋਕਾਂ ਨੂੰ ਬਹੁਤ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਚੀਜ਼ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਖ਼ਾਸ ਕਰਕੇ ਮੋਬਾਈਲ 'ਤੇ ਜਿੱਥੇ ਟੈਪ ਅਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ।
ਚੰਗੀ ਰੋਕਥਾਮ ਅਕਸਰ ਸਮਝਦਾਰ ਡਿਫੌਲਟ, ਸਪਸ਼ਟ ਪਾਬੰਦੀਆਂ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈਆਂ ਦਾ ਮਤਲਬ ਹੁੰਦੀ ਹੈ। ਜੇ ਇੱਕ ਫਾਰਮ ਨੂੰ country code ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਡਿਵਾਈਸ ਖੇਤਰ ਦੇ ਅਧਾਰ 'ਤੇ ਉਸਨੂੰ ਡਿਫੌਲਟ ਦੇ ਕੇ ਦਿਓ, ਅਤੇ ਅਸੰਭਵ ਮੁੱਲਾਂ ਨੂੰ ਬਲੌਕ ਕਰੋ ਬਜਾਏ ਉਹਨਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਫੇਲ ਹੋਣ ਦੇ। ਖ਼ਤਰਨਾਕ ਕਾਰਵਾਈਆਂ (delete, remove access, publish) ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਸਭ ਤੋਂ ਆਸਾਨ ਹੋਵੇ।
ਇਹ ਤਿੰਨੇ ਤੇਜ਼ੀ ਨਾਲ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਵਾਧੂ ਸੋਚ ਅਤੇ ਵਾਧੂ ਬਦਲਾਅ ਵਜੋਂ ਦਿਸਦੇ ਹਨ। Nielsen ਦੀਆਂ ਹਿਊਰਿਸਟਿਕਸ ਤੁਹਾਨੂੰ ਚੋਣਾਂ ਦਿਖਾਉਣ, ਦੁਹਰਾਏ ਵਰਤੋਂ ਲਈ ਤੇਜ਼ ਰਾਹ ਸਹਾਇਤਾ ਕਰਨ, ਅਤੇ ਸ਼ੋਰ ਹਟਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀਆਂ ਹਨ।
ਇੱਕ ਤੇਜ਼ ਸਮੀਖਿਆ:
ਉਦਾਹਰਣ: "Create project" ਫਲੋ ਵਿਚ ਜੇ ਯੂਜ਼ਰ ਨੂੰ ਪਿਛਲੇ ਸਕ੍ਰੀਨ ਤੋਂ ਇੱਕ ਵਰਕਸਪੇਸ ਨਾਮ ਯਾਦ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਰਿਕਾਲ ਮੰਗ ਰਹੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਹਾਲੀਆ ਵਰਕਸਪੇਸ ਦਿਖਾਉਂਦੇ ਹੋ ਅਤੇ ਆਖ਼ਰੀ ਵਾਲਾ ਪ੍ਰੀ-ਸਿਲੈਕਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਰਿਕਗਨੀਸ਼ਨ 'ਤੇ ਲਿਆਉਂਦੇ ਹੋ—ਫਾਰਮ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਬਿਨਾਂ ਨਵੇਂ ਫੀਚਰ ਜੋੜੇ।
Heuristic 9 (Help users recognize, diagnose, and recover from errors) ਜੋ ਕੁਝ ਗਲਤ ਹੋਣ 'ਤੇ ਹੁੰਦਾ ਹੈ, ਉਸ ਬਾਰੇ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦ ਇੱਥੇ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਡਰਾਉਣੇ ਸੁਨੇਹੇ, ਕੋਡ, ਜਾਂ ਡੈੱਡ ਐਂਡ ਦਿਖਾਉਂਦੇ ਹਨ।
ਇੱਕ ਚੰਗਾ ਐਰਰ ਸੁਨੇਹਾ ਤਿੰਨ ਗੱਲਾਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸਦਾ ਹੈ: ਕੀ ਹੋਇਆ, ਕਿਉਂ ਹੋਇਆ (ਜੇ ਤੁਹਾਨੂੰ ਪਤਾ ਹੈ), ਅਤੇ ਯੂਜ਼ਰ ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਕੀ ਕਰੇ। ਅਗਲਾ ਕਦਮ ਸਪੱਸ਼ਟ ਬਣਾਓ। ਜੇ ਫਾਰਮ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਹੀ ਫੀਲਡ ਨੂੰ ਹਾਈਲਾਈਟ ਕਰੋ ਅਤੇ ਜੋ ਯੂਜ਼ਰ ਪਹਿਲਾਂ ਭਰਿਆ ਸੀ ਉਹ ਰੱਖੋ। ਜੇ ਭੁਗਤਾਨ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਦੱਸੋ ਕਿ ਕਾਰਡ decline ਹੋਇਆ ਕਿ ਨੈੱਟਵਰਕ ਟਾਈਮਆਉਟ ਹੋਇਆ, ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੀਟ੍ਰਾਈ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ। ਜੇ ਮੋਬਾਈਲ ਪਰਮਿਸ਼ਨ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਰੋਕ ਰਹੀ ਹੈ, ਤਾਂ ਦੱਸੋ ਕਿ ਕੀ ਐਨੇਬਲ ਕਰਨਾ ਹੈ ਅਤੇ ਟਾਸਕ ਤੇ ਵਾਪਸ ਜਾਣ ਦਾ ਰਸਤਾ ਦਿਓ।
Heuristic 9 ਲਈ ਤੇਜ਼ ਚੈੱਕ:
Heuristic 10 (Help and documentation) ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ "ਇੱਕ help center ਬਣਾਓ." ਇਹ ਹੈ "ਉਹ ਜਗ੍ਹਾ 'ਤੇ ਮਦਦ ਰੱਖੋ ਜਿੱਥੇ ਲੋਕ ਅਟਕਦੇ ਹਨ।" Onboarding, empty states, ਅਤੇ edge cases ਵੱਡੇ ਜੀਤ ਹਨ।
ਇੱਕ empty list ਦੱਸੇ ਕਿ ਓਥੇ ਕੀ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਪਹਿਲਾ ਆਈਟਮ ਕਿਵੇਂ ਜੋੜਨਾ ਹੈ। ਪਹਿਲੀ ਵਾਰੀ ਵਾਲੀ ਸਕ੍ਰੀਨ ਇੱਕ ਮੁੱਖ ਸੰਕਲਪ ਸਮਝਾਏ, ਫਿਰ ਰਾਹ ਚਲੋ। ਇਕ ਦੁਰਲਭ edge case ਲਈ ਛੋਟਾ ਮਦਦਕ ਸੁਨੇਹਾ ਓਸ ਵੇਲੇ ਦਿਖਾਓ, ਲੰਬੇ ਲੇਖ ਦੀ ਥਾਂ।
ਐਰਰ ਸਟੇਟਾਂ ਦਾ ਸਮੀਖਿਆ ਕਰਨ ਲਈ ਪ੍ਰੈਕਟਿਕਲ ਤਰੀਕਾ: ਮੁੱਖ ਫਲੋ ਚਲਾਓ ਅਤੇ ਹਰ ਇੱਕ ਸ਼ਰਤ ਦੀ ਲਿਸਟ ਬਣਾਓ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਪੂਰੀ کرਨੀ ਪੈਂਦੀ ਹੈ (ਲਾਜ਼ਮੀ ਫੀਲਡ, ਪਰਮਿਸ਼ਨ, ਸੀਮਾਵਾਂ, ਕਨੈਕਟਿਵਿਟੀ)। ਹਰ ਨੁਕਤੇ ਲਈ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਕ ਸਪਸ਼ਟ ਐਰਰ, ਰਿਕਵਰੀ ਰਾਹ, ਅਤੇ ਇੱਕ ਛੋਟਾ "Need help?" ਨਿਸ਼ਾਨ ਹੈ ਜੋ ਸਕ੍ਰੀਨ 'ਤੇ ਫਿੱਟ ਬੈਠਦਾ ਹੋਵੇ।
ਇਸਨੂੰ ਇੱਕ ਪ੍ਰੀ-ਫਲਾਈਟ ਚੈੱਕ ਵਾਂਗ ਸਲੂਕ ਕਰੋ, ਖੋਜ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਮ ਸਮੱਸਿਆਵਾਂ ਫੜੀਆਂ ਜਾਣ ਤਾਂ ਜੋ ਤਬਦੀਲੀਆਂ ਹਾਲੇ ਸਸਤੇ ਹੋਣ ਵੇਲੇ ਠੀਕ ਕੀਤੀਆਂ ਜਾ ਸਕਣ।
ਪਹਿਲਾਂ ਇਕ ਜਾਂ ਦੋ ਆਹਮ ਯਾਤਰਾਵਾਂ ਚੁਣੋ ਜੋ ਅਸਲ ਮੁੱਲ ਦਰਸਾਂਦੀਆਂ ਹਨ। ਚੰਗੇ ਚੋਣਾਂ ਹਨ: signup, first-time setup, checkout, ਕੁਝ ਨਵਾਂ ਬਣਾਉਣਾ, ਪਬਲਿਸ਼ ਕਰਨਾ, ਜਾਂ ਇੱਕ ਟੀਮਮੇਟ ਨੂੰ ਬੁਲਾਉਣਾ। ਜੇ ਤੁਸੀਂ ਪੂਰੇ ਉਤਪਾਦ ਨੂੰ ਕਵਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਮਿਸ ਕਰ ਦੇਵੋਗੇ।
ਅਗਲਾ, ਇਸ ਰਿਲੀਜ਼ ਲਈ ਡਿਵਾਈਸ ਸੈੱਟ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ। ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਲਈ, ਇਹ ਮਤਲਬ ਡੈਸਕਟਾਪ ਨਾਲ-ਨਾਲ ਮੋਬਾਈਲ ਵੈਬ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਨੈਟਿਵ ਐਪ ਹੈ, ਤਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ iOS ਜਾਂ Android ਡਿਵਾਈਸ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਸਲ ਕੀਬੋਰਡ, ਪਰਮਿਸ਼ਨ, ਅਤੇ ਲੇਆਉਟ ਵਿਹਾਰ ਵੇਖ ਸਕੋ।
ਸਮੀਖਿਆ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਚਲਾਓ:
ਨੋਟਾਂ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਰੱਖੋ। "Confusing" ਔਖਾ ਹੈ; "Button label says Save, but it actually publishes" ਸਪੱਸ਼ਟ ਹੈ।
ਇੱਕ 10-ਮਿੰਟ ਦਾ ਸੋਰਟਿੰਗ ਪਾਸ ਨਾਲ ਖਤਮ ਕਰੋ। ਛੋਟੀਆਂ ਜਿੱਤਾਂ (ਕਾਪੀ, ਲੇਬਲ, ਸਪੇਸਿੰਗ, ਡਿਫੌਲਟ) ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਅਲੱਗ ਕਰੋ ਅਤੇ ਉਹ ਮੁੱਦੇ ਜੋ ਤੁਰੰਤ ਠੀਕ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ (ਬ্লੌਕਡ ਟਾਸਕ, ਡੇਟਾ ਲਾਸਕ ਦਾ ਖਤਰਾ, ਅਸਪਸ਼ਟ ਐਰਰ) ਨੂੰ ਉੱਪਰ ਰੱਖੋ।
ਹਿਊਰਿਸਟਿਕ ਸਮੀਖਿਆਵਾਂ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਸਕ੍ਰੀਨ-ਬਾਈ-ਸਕ੍ਰੀਨ ਆਲੋਚਨਾ ਬਣ ਕੇ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ। ਬਹੁਤ ਸਾਰੀ UX ਸਮੱਸਿਆਵਾਂ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ ਅਸਲ ਟਾਸਕ ਖਤਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਅਸਲ ਪਾਬੰਦੀਆਂ (ਛੋਟੇ ਸਕ੍ਰੀਨ, ਰੁਕਾਵਟਾਂ, ਧੀਮਾ ਨੈੱਟਵਰਕ) ਹੇਠਾਂ।
ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਵਿਅਕਤਿਗਤ ਪੰਨਿਆਂ ਨੂੰ ਵੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਟੁੱਟੇ ਹੋਏ ਹੈਂਡਅਫਜ਼ ਮਿਸ ਕਰ ਜਾਵੋਗੇ: ਇਕ ਫਿਲਟਰ ਜੋ checkout ਤੋਂ ਬਾਅਦ ਰੀਸੈਟ ਹੋ ਜਾਂਦਾ, "Saved" ਟੋਸਟ ਆਉਂਦੀ ਪਰ ਕੁਝ ਸੇਵ ਨਹੀਂ ਹੁੰਦਾ, ਜਾਂ ਇਕ ਬੈਕ ਬਟਨ ਜੋ ਗਲਤ ਕਦਮ 'ਤੇ ਵਾਪਸ ਲੈ ਜਾਂਦਾ।
ਇਸ ਤੋਂ ਬਚਣ ਲਈ ਇੱਕ ਛੋਟੇ ਸੈਟ ਦੇ ਟਾਪ ਟਾਸਕਾਂ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਸਮੀਖਿਆ ਕਰੋ। ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਫਲੋ ਚਲਾਉਣ ਦਿਓ ਤੇ ਦੂਜੇ ਨੂੰ ਹਿਊਰਿਸਟਿਕ ਉਲੰਘਣਾ ਲਿਖਣ ਲਈ ਰੱਖੋ।
"ਹਿਊਰਿਸਟਿਕ ਕਹਿੰਦੀ ਹੈ ਇਹ ਮਾੜਾ ਹੈ" ਇੱਕ ਨਤੀਜਾ ਨਹੀਂ। ਇੱਕ ਵਰਤੀ ਯੋਗ ਨੋਟ ਹਿਊਰਿਸਟਿਕ ਨੂੰ ਸਕ੍ਰੀਨ 'ਤੇ ਹੋਈ ਘਟਨਾ ਨਾਲ ਜੋੜਦੀ ਹੈ।
ਮਜ਼ਬੂਤ ਨਤੀਜਾ ਤਿੰਨ ਹਿੱਸਿਆਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ: ਯੂਜ਼ਰ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ, ਉਸਨੂੰ ਕੀ ਦਿੱਸਿਆ, ਅਤੇ ਕੀ ਬਦਲਾਅ ਕਰਨੇ ਚਾਹੀਦੇ। ਉਦਾਹਰਣ: "ਮੋਬਾਈਲ 'ਤੇ, ਟੈਪ ਕਰਕੇ Done ਕੀਬੋਰਡ ਬੰਦ ਕਰਦਾ ਹੈ ਪਰ ਫਾਰਮ ਸੇਵ ਨਹੀਂ ਹੁੰਦਾ। Rename to Close keyboard ਜਾਂ close ਤੇ auto-save ਜੋੜੋ."
"Confusing" ਜਾਂ "clunky" ਵਰਗੇ ਸ਼ਬਦ ਕਿਸੇ ਦੀ ਮਦਦ ਨਹੀਂ ਕਰਦੇ।
ਅਸਪਸ਼ਟ ਨੋਟਾਂ ਦੀ ਥਾਂ ਠੋਸ, ਟੈਸਟੇਬਲ ਬਦਲਾਅ ਦੇਵੋ। ਅਤੇ ਬਿਲਕੁਲ ਉਦਾਹਰਣ ਦੇਵੋ: ਸਹੀ ਤੱਤ (button label, icon, error text, step title) ਨਾਂ ਦਿਓ। ਮਿਸ-ਮੈਚ ਦਿੱਸਾਓ (ਉਮੀਦ vs واقعہ)، ਇੱਕ ਵਿਸ਼ੇਸ਼ ਬਦਲਾਅ ਸੁਝਾਓ (copy, placement, default, validation)। ਇੱਕ ਸਕ੍ਰੀਨਸ਼ਾਟ ਰੇਫਰੈਂਸ ਜਾਂ ਕਦਮ ਨੰਬਰ ਜੋੜੋ ਤਾਂ ਲੱਭਣਾ ਆਸਾਨ ਹੋਵੇ। ਪ੍ਰਭਾਵ ਵੀ ਦਸੋ (ਟਾਸਕ ਬਲੌਕ ਕਰਦਾ ਹੈ, ਗਲਤੀਆਂ ਕਰਵਾਂਦਾ ਹੈ, ਯੂਜ਼ਰ ਨੂੰ ਸਲੋ ਕਰਦਾ ਹੈ)।
ਡੈਸਕਟਾਪ ਸਮੀਖਿਆ ਮੈਨੂੰ ਇਹ ਸਮੱਸਿਆਵਾਂ ਛੱਡ ਸਕਦੀ ਹੈ: ਕੀਬੋਰਡ ਫੀਲਡ ਨੂੰ ਢੱਕਦਾ ਹੈ, ਇਸ਼ਾਰੇ ਟਕਰਾਉਂਦੇ ਹਨ, ਛੋਟੇ ਟੈਪ ਟਾਰਗਟ, ਅਤੇ ਸੇਫ-ਏਰੀਆ ਕਟਆਫ।
ਇਸੇ ਟਾਸਕ ਨੂੰ ਅਸਲ ਫੋਨ 'ਤੇ ਦੁਹਰਾਓ। ਇਕ ਵਾਰੀ ਰੋਟੇਟ ਕਰੋ। ਇਕ-ਹੱਥ ਨਾਲ ਵਰਤ ਕੇ ਦੇਖੋ।
ਇੱਕ ਫਲੋ ਤੇਜ਼ ਨੈੱਟਵਰਕ 'ਤੇ ਬਿਲਕੁਲ ਠੀਕ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।
ਹਮੇਸ਼ਾ no-results ਸਕ੍ਰੀਨ, ਪਹਿਲੀ ਵਾਰੀ ਖਾਲੀ ਸਟੇਟ, 5 ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਲੋਡਿੰਗ, ਆਫਲਾਈਨ ਮੋਡ (ਜੇ ਲਾਗੂ ਹੋ), ਅਤੇ ਫੇਲ ਰਿਕਵਾਈਰੀ ਦੀ ਜਾਂਚ ਕਰੋ। ਇਹ ਅਕਸਰ ਫਰਕ ਹੈ "ਚੱਲਦਾ ਹੈ" ਅਤੇ "ਭਰੋਸੇਯੋਗ" ਦਰਮਿਆਨ।
ਇਸਨੂੰ ਆਪਣੀਆਂ ਰਿਲੀਜ਼ ਨੋਟਸ ਜਾਂ QA ਡੌਕ ਵਿੱਚ ਪੇਸਟ ਕਰੋ ਅਤੇ ਸਕ੍ਰੀਨ-ਵਾਇਜ਼ ਟਿਕ ਕਰੋ। ਇਹ ਇੱਕ ਤੇਜ਼ ਪਾਸ ਹੈ ਜੋ ਬਿਨਾਂ ਪੂਰੇ ਰਿਸਰਚ ਸਪ੍ਰਿੰਟ ਦੇ ਆਮ ਮੁੱਦੇ ਫੜ ਲੈਂਦਾ ਹੈ ਅਤੇ Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਨਾਲ ਮੈਪ ਕੀਤਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਕੋਰ ਫਲੋ (sign up, checkout, create project, invite teammate) ਚੁਣੋ ਅਤੇ ਇਹਨਾਂ ਚੈੱਕਾਂ ਨੂੰ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਚਲਾਓ।
System status ਸਪਸ਼ਟ ਹੈ: ਲੋਡਿੰਗ ਅਤੇ ਸੇਵਿੰਗ ਸਥਿਤੀਆਂ ਦਰਸਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਬਟਨ ਵਿਯਸਤ ਹੋਣ ਦੌਰਾਨ ਟੈਪਯੋਗ ਨਹੀਂ ਦਿਖਦੇ, ਅਤੇ ਸਫਲਤਾ ਫੀਡਬੈਕ ਪੜ੍ਹਨ ਲਈ ਕਾਫੀ ਸਮੇਂ ਰੁਕਦੀ ਹੈ।
ਖ਼ਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਉਲਟਣਯੋਗ ਹਨ: ਨੁਕਸਾਨਦਾਇਕ ਜਾਂ ਮਹਿੰਗੇ ਕਦਮਾਂ ਲਈ ਸਪਸ਼ਟ cancel ਰਾਹ, undo ਜਿੱਥੇ ਠੀਕ ਹੋਵੇ, ਅਤੇ ਮੋਡਲਾਂ ਅਤੇ ਬਹੁ-ਕਦਮੀ ਫਾਰਮਾਂ ਵਿੱਚ Back ਉਮੀਦ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ।
ਸ਼ਬਦ ਉਪਭੋਗਤਾ ਦੀ ਦੁਨੀਆ ਨਾਲ ਮਿਲਦੇ ਹਨ: ਲੇਬਲ ਆਮ ਭਾਸ਼ਾ ਵਰਤਦੇ ਹਨ, ਅੰਦਰੂਨੀ ਟਰਮ ਨਹੀਂ। ਜੇ ਤਕਨੀਕੀ ਟਰਮ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਤਾਂ ਚੋਣ ਵਾਲੀ ਜਗ੍ਹਾ 'ਤੇ ਛੋਟਾ ਹਿੰਟ ਦਿਉ।
ਐਰਰ ਲੋਕਾਂ ਨੂੰ ਅਗਲਾ ਕਦਮ ਦੱਸਦੇ ਹਨ: ਸੁਨੇਹੇ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਗਲਤ ਹੋਇਆ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ (ਫੀਲਡ ਠੀਕ ਕਰੋ, ਮੁੜ ਕੋਸ਼ਿਸ ਕਰੋ, ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ). ਸੁਨੇਹਾ ਸਮੱਸਿਆ ਵਾਲੀ ਜਗ੍ਹਾ ਦੇ ਨੇੜੇ ਦਿਖਾਈਂ, ਸਿਰਫ਼ ਉੱਪਰ ਨਹੀਂ।
ਸਕ੍ਰੀਨਾਂ ਵਿਚ ਇਕਸਾਰਤਾ: ਬਟਨ ਦੇ ਨਾਮ, ਥਾਂ, ਅਤੇ ਆਈਕਨ ਦਾ ਮਤਲਬ ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹਾ ਰਹੇ। ਜੇ ਇੱਕ ਸਕ੍ਰੀਨ "Save" ਅਤੇ ਦੂਜੀ "Update" ਕਹਿੰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਚੁਣੋ।
ਰਿਲੀਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀਬੋਰਡ ਅਤੇ ਅੰਗੂਠੇ ਨਾਲ ਇੱਕ ਤੇਜ਼ ਪਾਸ ਕਰੋ।
ਇਕ ਛੋਟੀ ਟੀਮ ਨੇ ਚਾਰ ਟੀਅਰਾਂ (Free, Pro, Business, Enterprise) ਲਈ ਨਵਾਂ ਪ੍ਰਾਈਸਿੰਗ ਅਤੇ ਅਪਗਰੇਡ ਫਲੋ ਸ਼ਿਪ ਕੀਤਾ। ਮਕਸਦ ਸਧਾਰਣ ਹੈ: ਇੱਕ ਯੂਜ਼ਰ ਨੂੰ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਦੋਹਾਂ 'ਤੇ ਇਕ ਮਿੰਟ ਵਿੱਚ ਅਪਗਰੇਡ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਣਾ।
Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਦੀ ਇੱਕ ਛੋਟੀ ਪਾਸ ਦੌਰਾਨ, ਟੀਮ ਇੱਕੋ ਰਾਹ ਦੋ ਵਾਰੀ ਚਲਾਉਂਦੀ ਹੈ: ਪਹਿਲਾਂ ਇੱਕ ਨਵੇਂ Free ਯੂਜ਼ਰ ਵਜੋਂ, ਫਿਰ ਇੱਕ ਭੁਗਤਾਨ ਕਰਨ ਵਾਲੇ ਯੂਜ਼ਰ ਵਜੋਂ ਜੋ ਯੋਜਨਾ ਬਦਲ ਰਹੇ ਹਨ। ਨੋਟਾਂ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਡਿਜ਼ਾਈਨ ਜਾਰਗਨ ਨਹੀਂ।
ਇੱਥੇ ਉਹਨਾਂ ਨੇ ਜਲਦੀ ਫੜਿਆ, ਹਿਊਰਿਸਟਿਕਸ ਨਾਲ ਨਕਸ਼ੇਬੱਧ:
ਉਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਹੁਣ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ ਅਤੇ ਬਾਦ ਵਿੱਚ ਕੀ ਰੱਖਣਾ ਹੈ। ਜੇ ਕੋਈ ਚੀਜ਼ ਭੁਗਤਾਨ ਨੂੰ ਬਲੌਕ ਕਰਦੀ ਹੈ ਜਾਂ ਸਪੋਰਟ ਟਿਕਟ ਬਣਾਏਗੀ ਤਾਂ ਉਸਨੂੰ ਤੁਰੰਤ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕਾਪੀ ਦੀਆਂ ਸੁਧਾਰਾਂ ਅਤੇ ਨਾਂ ਵਿੱਚ ਇਕਸਾਰਤਾ ਨੂੰ ਸ਼ੈਡੀਊਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਜੇ ਉਹ ਮਿੱਡ-ਅਪਗਰੇਡ 'ਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਕਰਦੇ।
ਉਹੀ ਟੈਂਪਲੇਟ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਦੋਹਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਸਵਾਲ ਇੱਕੋ-ਸਮਾਨ ਰਹਿੰਦੇ ਹਨ: ਕੀ ਯੂਜ਼ਰ ਦੇਖ ਸਕਦੇ ਹਨ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਗਲਤੀਆਂ ਉਲਟ ਸਕਦੇ ਹਨ, ਅਤੇ ਸਕ੍ਰੀਨ 'ਤੇ ਦਿੱਤੇ ਸ਼ਬਦ ਸਮਝ ਆਉਂਦੇ ਹਨ? ਸਿਰਫ਼ ਸਤਹ ਬਦਲਦੇ ਹਨ (ਵੈਬ 'ਤੇ ਮੋਡਲ, ਮੋਬਾਈਲ 'ਤੇ ਸਕ੍ਰੀਨ ਅਤੇ ਬੈਕ ਇਸ਼ਾਰੇ)।
ਇੱਕ ਹਿਊਰਿਸਟਿਕ ਸਮੀਖਿਆ ਉਸ ਤਰੀਕੇ 'ਤੇ ਜੀਉਂਦੀ ਜਾਂ ਮਰਦੀ ਹੈ ਜਿਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਉਸਨੂੰ ਲਿਖਦੇ ਹੋ। ਹਰ ਨਤੀਜੇ ਨੂੰ ਛੋਟਾ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ: ਯੂਜ਼ਰ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ, ਕੀ ਗਲਤ ਹੋਇਆ, ਕਿੱਥੇ ਹੋਇਆ, ਅਤੇ ਕਿਹੜੀ ਹਿਊਰਿਸਟਿਕ ਤੋੜੀ ਗਈ। ਸਕ੍ਰੀਨਸ਼ਾਟ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕੀ ਕਰਨਾ ਹੈ ਇਹ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਹਲਕੇ ਵਜ਼ਨ ਦਾ ਸੀਵਰਿਟੀ ਸਕੋਰ ਵਰਤੋ ਤਾਂ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਛਾਂਟ ਸਕਣ:
Priority ਲਈ, severity ਨੂੰ reach ਨਾਲ ਜੋੜੋ। ਮੁੱਖ signup ਫਲੋ 'ਤੇ severity 2 ਕਦੇ ਕਦੇ ਕਿਸੇ ਲਿਮਟਡ settings ਸਕ੍ਰੀਨ 'ਤੇ severity 3 ਨੂੰ ਹਰਾ ਸਕਦੀ ਹੈ।
ਦੋਹਰਾਵਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨ ਲਈ, findings ਨੂੰ ਇੱਕ ਛੋਟੇ ਲੇਬਲ ਨਾਲ ਟੈਗ ਕਰੋ (ਉਦਾਹਰਣ: "unclear error text" ਜਾਂ "hidden primary action") ਅਤੇ ਹਰ ਰਿਲੀਜ਼ ਨਾਲ ਗਿਣਤੀ ਰੱਖੋ। ਜੇ ਇਕੋ ही ਵੈਬ ਐਪ UX ਗਲਤੀ ਵਾਰ-ਵਾਰ ਆ ਰਹੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਟੀਮ ਨਿਯਮ ਜਾਂ ਅਗਲੇ ਸਮੀਖਿਆ ਲਈ ਚੈੱਕਲਿਸਟ ਆਈਟਮ ਬਣਾਓ।
ਟਾਈਮਬਾਕਸ ਖਤਮ ਹੋਣ 'ਤੇ ਰੁਕੋ ਜਦ ਨਵੇਂ ਨਤੀਜੇ ਮੁੱਖ ਤੌਰ 'ਤੇ "nice to have" ਹੋਣ। ਜੇ ਤੁਸੀਂ 10 ਮਿੰਟ ਲਈ ਸਿਰਫ਼ severity 0-1 ਨੁਕਤੇ ਲੱਭ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਚੰਗੇ ਰਿਟਰਨ ਪੌਇੰਟ ਤੋਂ ਪਾਰ ਹੋ।
ਹਿਊਰਿਸਟਿਕਸ ਸਾਰੀ ਕਹਾਣੀ ਨਹੀਂ ਹਨ। ਉਸ ਵੇਲੇ escalate ਕਰੋ ਜਦੋਂ ਤੁਸੀਂ ਅਣਸੱਲੀ ਵੀਵਾਦ ਦੇਖੋ ਕਿ ਉਪਭੋਗਤਾ ਕੀ ਕਰਨਗੇ, ਐਨਾਲਿਟਿਕਸ ਵਿੱਚ ਅਜਿਹੇ ਡ੍ਰੌਪ-ਆਫਜ਼ ਜੋ ਸਪਸ਼ਟ ਨਾ ਹੋਣ, ਇਕੋ ਕਦਮ ਲਈ ਦੁਹਰਾਏ ਸਪੋਰਟ ਟਿਕਟ, ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਫਲੋ (payments, privacy, onboarding), ਜਾਂ ਕੋਈ ਨਵਾਂ ਇੰਟਰੈਕਸ਼ਨ ਪੈਟਰਨ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਨੇ ਪਹਿਲਾਂ ਨਹੀਂ ਅਜ਼ਮਾਇਆ। ਉਸ ਸਮੇ, ਇੱਕ ਛੋਟਾ ਯੂਜ਼ਰ ਟੈਸਟ ਅਤੇ ਐਨਾਲਿਟਿਕਸ/ਸਪੋਰਟ ਡੇਟਾ ਦੇਖਣਾ Nielsen ਹਿਊਰਿਸਟਿਕਸ 'ਤੇ ਹੋਰ ਬਹਿਸ ਕਰਨ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮੁਫ਼ੀਦ ਹੁੰਦਾ ਹੈ।
ਹਿਊਰਿਸਟਿਕ ਸਮੀਖਿਆਵਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਤਦੋਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਬੋਰਿੰਗ ਅਤੇ ਪੇਸ਼ਗੋਈ ਵਾਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਨੂੰ ਛੋਟੀ ਸੁਰੱਖਿਆ ਜਾਂਚ ਵਾਂਗ ਸਲੂਕ ਕਰੋ, ਨਾ ਕਿ ਇਕ ਵਿਸ਼ੇਸ਼ ਸਮਾਗਮ। ਹਰ ਰਿਲੀਜ਼ ਲਈ ਇਕ ਮਾਲਕ ਚੁਣੋ (ਰੋਟੇਟ ਕਰੋ), ਇੱਕ ਕੈਡੈਂਸ ਸੈੱਟ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਸ਼ਿਪਿੰਗ ਰਿਦਮ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋਵੇ, ਅਤੇ ਸਕੋਪ ਨੂੰ ਤੰਗ ਰੱਖੋ ਤਾਂ ਜੋ ਇਹ ਅਸਲ ਵਿੱਚ ਹੋਵੇ।
ਇਕ ਸਧਾਰਣ ਰੀਟਿਨ ਜੋ ਸਮੇਂ-ਕਾ-ਸਥਿਰ ਰਹੇ:
ਕੰਝ ਰਿਲੀਜ਼ਾਂ 'ਤੇ, ਤੁਸੀਂ ਈਸਟੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਮੁੜ ਵੇਖੋਗੇ: ਅਸਪਸ਼ਟ ਬਟਨ ਲੇਬਲ, ਅਸੰਗਤ ਸ਼ਬਦ, ਧੁੰਦਲੇ ਐਰਰ ਸੁਨੇਹੇ, ਘੱਟ ਖਾਲੀ ਸਟੇਟ, ਅਤੇ ਅਚਾਨਕ ਪੁਸ਼ਟੀਕਰਨ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ ਫਿਕਸ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਬਦਲੋ ਜੋ ਟੀਮ ਦੁਹਰਾਉਂਦੀ ਰਹੇ। ਅਮਲੀ ਰੱਖੋ: ਮਨਜ਼ੂਰ ਕੀਤੀ ਮਾਈਕ੍ਰੋ-ਕਾਪੀ ਐਰਰਾਂ ਲਈ, ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਲਈ ਇੱਕ ਮਿਆਰੀ ਪੈਟਰਨ, ਅਤੇ ਕੁਝ ਚੰਗੇ ਫਾਰਮ ਵੈਲਿਡੇਸ਼ਨ ਉਦਾਹਰਣ।
ਯੋਜਨਾ ਬਣਾਉਣ ਵਾਲੀਆਂ ਨੋਟਾਂ ਤੁਹਾਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ ਕਿ ਮੁੱਦੇ ਸ਼ਿਪ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਆ ਜਾਣ। ਆਪਣੇ ਯੋਜਨਾ ਜਾਂ ਡਿਜ਼ਾਈਨ ਨੋਟਾਂ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਹਿਊਰਿਸਟਿਕ ਪਾਸ ਜੋੜੋ, ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਕੋਈ ਫਲੋ ਬਦਲਦੀ ਹੈ। ਜੇ ਕੋਈ ਤਬਦੀਲੀ ਕਦਮ ਵਧਾਉਂਦੀ ਹੈ, ਨਵੇਂ ਸ਼ਬਦ ਪੇਸ਼ ਕਰਦੀ ਹੈ, ਜਾਂ ਨਵੇਂ ਐਰਰ ਕੇਸ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਖਤਰੇ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਛਾਣ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਅਤੇ ਦੁਹਰਾਉਂਦੇ ਹੋ ਇਕ chat-driven app builder ਨਾਲ, ਤਾਂ ਉਹ ਛੋਟੇ ਨਿਰਮਾਣਾਂ ਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਯੂਐਕਸ ਚੈੱਕ ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ। Koder.ai (koder.ai) ਵਰਤਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ, Planning Mode ਨਾਲ snapshots ਅਤੇ rollback ਨਾਲ ਇਹ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿ فਲੋ ਅਤੇ ਕਾਪੀ ਉੱਤੇ ਪਹਿਲਾਂ ਸਹਿਮਤੀ ਬਣਾਈ ਜਾਵੇ, ਤਬਦੀਲੀਆਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕੀਤੀਆਂ ਜਾਣ, ਅਤੇ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਫਿਕਸਾਂ ਨੂੰ ਇਕੋ ਬੇਸਲਾਈਨ ਦੇ ਖਿਲਾਫ਼ ਵੈਰੀਫਾਈ ਕੀਤਾ ਜਾਵੇ।
ਉਨ੍ਹਾਂ ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਸੁਰੱਖਿਆ ਜाँच ਵਜੋਂ ਵਰਤੋ। ਇਹ ਤੁਹਾਨੂੰ ਸਪਟਨੇ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ (ਲੋਡਿੰਗ ਫੀਡਬੈਕ ਦੀ ਘਾਟ, ਉਲਝਣ ਵਾਲੇ ਲੇਬਲ, ਡੈਡ-ਐਨਡ ਐਰਰ) ਫੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ, ਪਰ ਇਹ ਯੂਜ਼ਰ ਟੈਸਟਿੰਗ ਜਾਂ ਐਨਾਲਿਟਿਕਸ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦੇ।
1–2 ਆਹਮ ਯੂਜ਼ਰ ਜਰਨੀਆਂ (signup, checkout, create, invite) 'ਤੇ 30–45 ਮਿੰਟ ਦੀ ਪਾਸ ਕਰੋ। ਇੱਕ ਤੇਜ਼ ਦੌੜ ਸਾਰ-ਇੰਤਹਾ ਕਰੋ, ਫਿਰ ਧੀਰੇ ਧੀਰੇ ਇੱਕ ਦੌੜ ਕਰੋ ਜਿੱਥੇ ਤੁਸੀਂ ਮੁੱਦੇ ਲਿਖੋ, ਹਰ ਇੱਕ ਨੂੰ ਇੱਕ ਹਿਊਰਿਸਟਿਕ ਨਾਲ ਟੈਗ ਕਰੋ, ਅਤੇ ਸਧਾਰਨ ਸੀਵਰਿਟੀ (low/medium/high) ਨਿਰਧਾਰਤ ਕਰੋ।
ਤਾਜ਼ਾ ਨਜ਼ਰ ਅਤੇ ਘੱਟ ਅੰਧ-ਦਾਗ ਲਈ ਆਮ ਤੌਰ 'ਤੇ 2-3 ਲੋਕ ਚੰਗੇ ਹੁੰਦੇ ਹਨ: ਇੱਕ ਚਲਾਉਂਦਾ ਹੈ, ਇੱਕ ਨੋਟ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ ਅਕਸਰ ਅਣਦੇਖੇ ਸਟੇਟ ਜਾਂ ਅਸਮਰਥਤੀਆਂ پکੜਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਕਲੇ ਹੋ, ਤਿਹਾਂ ਦੋ ਪਾਸ ਕਰੋ: ਇੱਕ "ਸਪੀਡ ਰਨ" ਅਤੇ ਇੱਕ "ਵੇਰਵਾ ਰਨ"।
ਜੇ کوئی ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਇੱਕ ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਲੈਂਦਾ ਹੈ ਤਾਂ ਕੁਝ ਦਿਖਾਓ:
ਅਜਿਹਾ ਟੈਸਟ ਹੌਲੀ ਨੈੱਟਵਰਕ 'ਤੇ ਵੀ ਕਰੋ—ਕਈ ਵਾਰੀ "ਠੀਕ" ਫਲੋ ਉੱਥੇ ਫੇਲ ਹੁੰਦਾ ਹੈ।
ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਜ਼ਿੰਦਗੀ-ਭਾਸ਼ਾ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
ਖ਼ਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਨੂੰ ਉਲਟਿਆ ਜਾ ਸਕਣ ਯੋਗ ਬਣਾਓ:
ਇੱਕ ਨਾਮ ਅਤੇ ਪੈਟਰਨ ਚੁਣੋ ਅਤੇ ਹਰ ਥਾਂ ਇਕਸਾਰ ਰਹੋ:
ਅਸੰਗਤਤਾ ਗੁਪਤ ਤੌਰ 'ਤੇ ਗਲਤੀਆਂ ਅਤੇ ਸਪੋਰਟ ਟਿਕਟ ਵਧਾਉਂਦੀ ਹੈ।
ਗਲਤੀਆਂ ਨੂੰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕੋ:
ਬੁਰੇ ਇਨਪੁਟ ਨੂੰ ਬਾਅਦ ਵਿਚ ਸਵੀਕਾਰ ਨਾ ਕਰਕੇ ਅਧੂਰਾ ਐਰਰ ਨਾ ਦਿਖਾਓ।
ਇੱਕ ਵਧੀਆ ਐਰਰ ਸੁਨੇਹਾ ਤਿੰਨ ਗੱਲਾਂ ਦੱਸਦਾ ਹੈ:
ਨਾਲ ਹੀ: ਯੂਜ਼ਰ ਜੋ ਭਰਿਆ ਸੀ ਉਹ ਰੱਖੋ, ਮੁੱਦੇ ਵਾਲੀ ਜਗ੍ਹਾ ਉੱਤੇ ਹਾਈਲਾਈਟ ਕਰੋ, ਅਤੇ ਦੋਸ਼ੀ ਭਾਸ਼ਾ ਤੋਂ ਬਚੋ।
ਨੀਚੇ ਦਿੱਤੇ ਹਾਲਾਤਾਂ 'ਚ ਅਗਲੇ ਕਦਮ ਵਜੋਂ ਯੂਜ਼ਰ ਟੈਸਟ ਕਰੋ:
ਇਸ ਵੇਲੇ ਛੋਟਾ ਯੂਜ਼ਰ ਟੈਸਟ ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਜਾਂ ਸਪੋਰਟ ਡੇਟਾ ਦੇਖੋ।