ਨੀਲਸਨ ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ: ਤੇਜ਼ ਸਮੀਖਿਆ ਟੈਂਪਲੇਟ

ਸਮੱਸਿਆ: ਆਸਾਨ UX ਬੱਗ ਰਿਲੀਜ਼ ਵਿੱਚ ਫਿਸਲ ਜਾਂਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਰਿਲੀਜ਼-ਦਿਨ ਦੇ UX ਸਮੱਸਿਆਵਾਂ ਵੱਡੇ ਰੀਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਛੋਟੀਆਂ, ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਜਾਣ ਵਾਲੀਆਂ ਜਾਣਕਾਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਅਸੀਂ ਰੀਅਲ ਟਾਸਕ ਖਤਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਿਆਂ ਸਮੇਤ ਆਉਂਦੀਆਂ ਹਨ। ਨਤੀਜਾ ਪੈੱਲ ਅਨੁਮਾਨਤ ਹੈ: ਵੱਧ ਸਪੋਰਟ ਟਿਕਟਾਂ, ਵੱਧ churn, ਅਤੇ ਵੱਧ "ਤੇਜ਼ ਠੀਕਆਂ" ਜੋ ਇਕੱਠੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

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

ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲ ਰਹੇ ਹੋ, ਉਹੀ ਕਿਸਮਾਂ ਦੀਆਂ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਸਮੱਸਿਆਵਾਂ ਮੁੜ ਮੁੜ ਆਉਂਦੀਆਂ ਹਨ: ਐਸੇ ਸਕਰੀਨ ਜਿੱਥੇ ਅਗਲਾ ਸਪੱਸ਼ਟ ਕਦਮ ਨਹੀਂ, ਫੀਡਬੈਕ ਦੀ ਘਾਟ (ਕੀ ਸੇਵ ਹੋਇਆ, ਸਬਮਿਟ ਹੋਇਆ, ਜਾਂ ਫੇਲ?), ਐਸੇ ਐਰਰ ਸੁਨੇਹੇ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਦੋਸ਼ ਦਿੰਦੇ ਬਿਨਾਂ ਕੋਈ ਰਾਹ ਨਹੀਂ ਦਿਖਾਉਂਦੇ, ਨਿਯੰਤਰਣ ਜੋ ਕਲਿੱਕਯੋਗ ਲੱਗਦੇ ਪਰ ਨਹੀਂ ਹਨ, ਅਤੇ ਵਾਕ-ਚੋਣ ਜਿਹੜੀ ਸਕ੍ਰੀਨ-ਵਾਰ ਬਦਲਦੀ ਹੈ (Sign in vs Log in) ਅਤੇ ਧੀਰੇ-ਧੀਰੇ ਭਰੋਸਾ ਖ਼ਰਾਬ ਕਰ ਦਿੰਦੀ ਹੈ।

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

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

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

Jakob Nielsen ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਅਤੇ ਕਿਉਂ ਹਿਊਰਿਸਟਿਕਸ ਅਜੇ ਵੀ ਮਦਦ ਕਰਦੇ ਹਨ

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

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

ਤੁਹਾਨੂੰ ਹੁਣ ਦੇ ਉਤਪਾਦਾਂ ਲਈ ਹਿਊਰਿਸਟਿਕਸ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮੋਬਾਈਲ 'ਤੇ ਛੋਟੇ ਸਕ੍ਰੀਨ ਰਿਕਗਨਿਸ਼ਨ ਨੂੰ ਯਾਦ ਰੱਖਣ 'ਤੇ ਤਰਜੀਹ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਗਲਤੀਆਂ ਰੋਕਣ ਲੇਆਉਟ, ਅੰਗੂਠੇ ਦੀ ਪਹੁੰਚ ਅਤੇ ਮੁਆਫ ਕਰਨ ਵਾਲੇ ਇਨਪੁੱਟ ਬਾਰੇ ਹੋਰ ਪ੍ਰਾਥਮਿਕ ਹੁੰਦੀ ਹੈ। ਬਹੁ-ਕਦਮੀ ਫਲੋਜ਼ (signup, onboarding, payments) ਵਿੱਚ ਯੂਜ਼ਰ ਨਿਯੰਤਰਣ ਅਤੇ ਆਜ਼ਾਦੀ ਦਾ ਮਤਲਬ ਸੇਫ਼ ਬੈਕ ਐਕਸ਼ਨ, ਸੰਭਾਲੀ ਹੋਈ ਪ੍ਰਗਤੀ, ਅਤੇ ਕੋਈ ਝਟਕਾ ਨਹੀਂ ਜਦ ਇੱਕ ਕਦਮ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਭਾਵ ਪਾਂਦਾ ਹੈ। AI ਫੀਚਰਾਂ ਵਿੱਚ, visibility of system status ਸਿਰਫ਼ ਇਕ ਸਪੀਨਰ ਨਹੀਂ ਹੈ—ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਜਾਣਨਾ ਲੋੜੀ ਹੈ ਕਿ ਸਿਸਟਮ ਕੀ ਕਰ ਰਹਾ ਹੈ, ਕੀ ਵਰਤਿਆ ਗਿਆ, ਅਤੇ ਜਦ ਨਤੀਜੇ ਗਲਤ ਲੱਗਦੇ ਹਨ ਤਾਂ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।

ਹਿਊਰਿਸਟਿਕਸ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਭਾਸ਼ਾ ਵੀ ਦਿੰਦੇ ਹਨ। ਡਿਜ਼ਾਇਨਰ consistency ਅਤੇ standards ਦੀ ਗੱਲ ਕਰ ਸਕਦੇ ਹਨ ਬਜਾਏ ਸਵਾਦ ਦੇ बहਸ ਕਰਨ ਦੇ। ਪ੍ਰੋਡਕਟ ਮੁੱਦਿਆਂ ਨੂੰ ਡ੍ਰੌਪ-ਆਫ ਜਾਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ ਐਰਰ ਰਿਕਵਰ리를 ਨਿਰਧਾਰਤ ਟਾਸਕਾਂ (ਚੰਗੀ ਵੈਲੀਡੇਸ਼ਨ, ਸਾਫ਼ ਸੁਨੇਹੇ, ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ) ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਹਰ ਕੋਈ ਇੱਕੋ ਸ਼ਬਦ ਵਰਤਦਾ ਹੈ, ਤਾਹਨ ਪਹਿਲਾਂ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ, ਉਸ 'ਤੇ ਸਹਿਮਤੀ ਆਉਣੀ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ।

ਹਿਊਰਿਸਟਿਕਸ 1-4 ਆਧੁਨਿਕ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਉਦਾਹਰਣਾਂ ਸਾਥ

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

1) ਸਿਸਟਮ ਸਥਿਤੀ ਦੀ ਦਿਖਾਈ (Visibility of system status)

ਲੋਕਾਂ ਨੂੰ ਕਦੇ ਇਹ ਸੋਚਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, "ਕੀ ਇਹ ਕੰਮ ਕੀਤਾ?" ਲੋਡਿੰਗ, ਸੇਵਿੰਗ, ਅਤੇ ਖਤਮ ਹੋਣ ਲਈ ਸਪਸ਼ਟ ਫੀਡਬੈਕ ਦਿਖਾਓ।

ਸਰਲ ਟੈਸਟ: ਧੀਮੀ ਕਨੈਕਸ਼ਨ 'ਤੇ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ (Save, Pay, Send) ਨੂੰ ਟੈਪ ਕਰੋ। ਜੇ UI ਇੱਕ ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਇਕਸਾਰ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਇਕ ਸੰਕੇਤ ਜੋੜੋ। ਇਹ ਸਪੀਨਰ, ਪ੍ਰੋਗ੍ਰੈਸ ਟੈਕਸਟ, ਜਾਂ ਅਸਥਾਈ ਅਪਾਹਰਿਤ ਸਥਿਤੀ ਹੋ ਸਕਦੀ ਹੈ। ਫਿਰ ਸਫਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਇੱਕ ਸੁਨੇਹੇ ਨਾਲ ਕਰੋ ਜੋ ਪੜ੍ਹਨ ਲਈ ਕਾਫੀ ਲੰਬਾ ਰਹੇ।

2) ਸਿਸਟਮ ਅਤੇ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਵਿਚਕਾਰ ਮੇਲ (Match between system and the real world)

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

ਉਦਾਹਰਣ: ਇੱਕ ਟਰੈਵਲ ਐਪ ਜੋ "Given name" ਅਤੇ "Surname" ਮੰਗਦਾ ਹੈ, ਕੁਝ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਗੁੰਝਲਦਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਬਹੁਤਰ ਆਡੀਅੰਸ "First name" ਅਤੇ "Last name" ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਸੀ ਨੂੰ ਵਰਤੋ। ਮੋਬਾਈਲ ਫਾਰਮਾਂ 'ਤੇ, ਖੇਤਰਾਂ ਨੂੰ ਅਸਲ ਟਾਸਕ ਵਾਂਗ ਗਰੁੱਪ ਕਰੋ: ਪਹਿਲਾਂ ਯਾਤਰੀ ਵੇਰਵੇ, ਫਿਰ ਭੁਗਤਾਨ, ਫਿਰ ਪੁਸ਼ਟੀ।

3) ਯੂਜ਼ਰ ਨਿਯੰਤਰਣ ਅਤੇ ਆਜ਼ਾਦੀ (User control and freedom)

ਲੋਕ ਗਲਤੀਆਂ ਕਰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰਾਹ ਦਿਓ।

ਮੋਬਾਈਲ 'ਤੇ, ਇਹ ਅਕਸਰ ਨੁਕਸਾਨਦਾਇਕ ਕਾਰਵਾਈ (Delete, Remove) ਤੋਂ ਬਾਦ undo ਦੀ ਘਾਟ ਵੱਜੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਲੰਬੇ ਟਾਸਕਾਂ (uploads, exports) ਲਈ ਕੋਈ cancel ਚੋਣ ਨਹੀਂ, ਇੱਕ ਬੈਕ ਕਾਰਵਾਈ ਜੋ ਫਾਰਮ ਪ੍ਰਗਤੀ ਖ਼ਤਮ ਕਰ ਦੇਵੇ, ਜਾਂ ਮੋਡਲ ਅਤੇ ਫੁੱਲ-ਸਕ੍ਰੀਨ ਫਲੋਜ਼ ਜਿਨ੍ਹਾਂ 'ਚ ਕੋਈ ਸਪੱਸ਼ਟ ਬਾਹਰ ਨਿਕਲਣ ਨਹੀਂ।

ਜੇ ਯੂਜ਼ਰ ਸਿਰਫ਼ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਕੇ ਗਲਤੀ ਸੁਧਾਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਸਪੋਰਟ ਟਿਕਟਾਂ ਆਉਣਗੀਆਂ।

4) ਇਕਸਾਰਤਾ ਅਤੇ ਮਿਆਰ (Consistency and standards)

ਸਕ੍ਰੀਨ-ਵਾਰ ਪੈਟਰਨ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ ਅਤੇ ਪਲੈਟਫਾਰਮ ਨਾਰਮਾਂ ਨਾਲ ਮੇਲ ਖਾਓ। ਜੇ ਇੱਕ ਸਕ੍ਰੀਨ "Done" ਵਰਤਦੀ ਹੈ ਅਤੇ ਦੂਜੀ "Save," ਤਾਂ ਇੱਕ ਚੁਣੋ। ਜੇ ਲਿਸਟ ਵਿੱਚ swipe-to-delete ਹੈ, ਤਾਂ delete ਨੂੰ ਦੂਜੇ ਥਾਂ 메뉴 ਦੇ ਪਿੱਛੇ ਨਹੀਂ ਛੁਪਾਉ।

ਵੈਬ 'ਤੇ ਲਿੰਕ ਲਿੰਕ ਵਰਗੇ ਲੱਗਣੇ ਚਾਹੀਦੇ ਹਨ। ਮੋਬਾਈਲ 'ਤੇ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਤਿਥੇ-ਉਮੀਦਵਾਰ ਥਾਵਾਂ 'ਤੇ ਹੋਣ। ਇਕਸਾਰਤਾ ਸਿੱਖਣ ਦਾ ਸਮਾਂ ਘਟਾਉਂਦੀ ਅਤੇ ਟਾਲ-ਯੋਗ ਵੈਬ ਐਪ UX ਗਲਤੀਆਂ ਰੋਕਦੀ ਹੈ।

ਹਿਊਰਿਸਟਿਕਸ 5-8 ਜੋ ਤੁਸੀਂ ਮਿੰਟਾਂ ਵਿੱਚ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹੋ

5) ਗਲਤੀ ਰੋਕਥਾਮ (Error prevention)

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

ਚੰਗੀ ਰੋਕਥਾਮ ਅਕਸਰ ਸਮਝਦਾਰ ਡਿਫੌਲਟ, ਸਪਸ਼ਟ ਪਾਬੰਦੀਆਂ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈਆਂ ਦਾ ਮਤਲਬ ਹੁੰਦੀ ਹੈ। ਜੇ ਇੱਕ ਫਾਰਮ ਨੂੰ country code ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਡਿਵਾਈਸ ਖੇਤਰ ਦੇ ਅਧਾਰ 'ਤੇ ਉਸਨੂੰ ਡਿਫੌਲਟ ਦੇ ਕੇ ਦਿਓ, ਅਤੇ ਅਸੰਭਵ ਮੁੱਲਾਂ ਨੂੰ ਬਲੌਕ ਕਰੋ ਬਜਾਏ ਉਹਨਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਫੇਲ ਹੋਣ ਦੇ। ਖ਼ਤਰਨਾਕ ਕਾਰਵਾਈਆਂ (delete, remove access, publish) ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਸਭ ਤੋਂ ਆਸਾਨ ਹੋਵੇ।

6-8) ਪਛਾਣ, ਕੁਸ਼ਲਤਾ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਡਿਜ਼ਾਈਨ (Recognition, efficiency, and minimal design)

ਇਹ ਤਿੰਨੇ ਤੇਜ਼ੀ ਨਾਲ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਵਾਧੂ ਸੋਚ ਅਤੇ ਵਾਧੂ ਬਦਲਾਅ ਵਜੋਂ ਦਿਸਦੇ ਹਨ। Nielsen ਦੀਆਂ ਹਿਊਰਿਸਟਿਕਸ ਤੁਹਾਨੂੰ ਚੋਣਾਂ ਦਿਖਾਉਣ, ਦੁਹਰਾਏ ਵਰਤੋਂ ਲਈ ਤੇਜ਼ ਰਾਹ ਸਹਾਇਤਾ ਕਰਨ, ਅਤੇ ਸ਼ੋਰ ਹਟਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀਆਂ ਹਨ।

ਇੱਕ ਤੇਜ਼ ਸਮੀਖਿਆ:

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

ਉਦਾਹਰਣ: "Create project" ਫਲੋ ਵਿਚ ਜੇ ਯੂਜ਼ਰ ਨੂੰ ਪਿਛਲੇ ਸਕ੍ਰੀਨ ਤੋਂ ਇੱਕ ਵਰਕਸਪੇਸ ਨਾਮ ਯਾਦ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਰਿਕਾਲ ਮੰਗ ਰਹੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਹਾਲੀਆ ਵਰਕਸਪੇਸ ਦਿਖਾਉਂਦੇ ਹੋ ਅਤੇ ਆਖ਼ਰੀ ਵਾਲਾ ਪ੍ਰੀ-ਸਿਲੈਕਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਰਿਕਗਨੀਸ਼ਨ 'ਤੇ ਲਿਆਉਂਦੇ ਹੋ—ਫਾਰਮ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਬਿਨਾਂ ਨਵੇਂ ਫੀਚਰ ਜੋੜੇ।

ਹਿਊਰਿਸਟਿਕਸ 9-10: ਐਰਰ ਅਤੇ ਮਦਦ ਜੋ ਸਪੋਰਟ ਬੋਝ ਘਟਾਉਂਦੇ ਹਨ

Heuristic 9 (Help users recognize, diagnose, and recover from errors) ਜੋ ਕੁਝ ਗਲਤ ਹੋਣ 'ਤੇ ਹੁੰਦਾ ਹੈ, ਉਸ ਬਾਰੇ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦ ਇੱਥੇ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਡਰਾਉਣੇ ਸੁਨੇਹੇ, ਕੋਡ, ਜਾਂ ਡੈੱਡ ਐਂਡ ਦਿਖਾਉਂਦੇ ਹਨ।

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

Heuristic 9 ਲਈ ਤੇਜ਼ ਚੈੱਕ:

• ਕੀ ਸੁਨੇਹਾ ਵਾਕ ਵਾਂਗ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਲਾਗ ਨਾ ਹੋਵੇ?
• ਕੀ ਇਹ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਸਹੀ ਮੁੱਦੇ (ਫੀਲਡ, ਕਦਮ, ਫਾਇਲ) ਵੱਲ ਖਿੱਚਦਾ ਹੈ?
• ਕੀ ਇਹ ਇੱਕ ਸਬ ਤੋਂ ਚੰਗਾ ਅਗਲਾ ਕਦਮ ਪੇਸ਼ ਕਰਦਾ ਹੈ (retry, edit, contact, cancel)?
• ਕੀ ਇਹ ਕੰਮ ਬਚਾਉਂਦਾ ਹੈ (ਡਰਾਫਟ, ਚੋਣਾਂ) ਐਰਰ ਤੋਂ ਬਾਅਦ?
• ਕੀ ਇਹ ਦੋਸ਼-ਚਿੱਠੇ ਸ਼ਬਦਾਂ ਤੋਂ ਬਚਦਾ ਹੈ ("fatal", "invalid user")?

Heuristic 10 (Help and documentation) ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ "ਇੱਕ help center ਬਣਾਓ." ਇਹ ਹੈ "ਉਹ ਜਗ੍ਹਾ 'ਤੇ ਮਦਦ ਰੱਖੋ ਜਿੱਥੇ ਲੋਕ ਅਟਕਦੇ ਹਨ।" Onboarding, empty states, ਅਤੇ edge cases ਵੱਡੇ ਜੀਤ ਹਨ।

ਇੱਕ empty list ਦੱਸੇ ਕਿ ਓਥੇ ਕੀ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਪਹਿਲਾ ਆਈਟਮ ਕਿਵੇਂ ਜੋੜਨਾ ਹੈ। ਪਹਿਲੀ ਵਾਰੀ ਵਾਲੀ ਸਕ੍ਰੀਨ ਇੱਕ ਮੁੱਖ ਸੰਕਲਪ ਸਮਝਾਏ, ਫਿਰ ਰਾਹ ਚਲੋ। ਇਕ ਦੁਰਲਭ edge case ਲਈ ਛੋਟਾ ਮਦਦਕ ਸੁਨੇਹਾ ਓਸ ਵੇਲੇ ਦਿਖਾਓ, ਲੰਬੇ ਲੇਖ ਦੀ ਥਾਂ।

ਐਰਰ ਸਟੇਟਾਂ ਦਾ ਸਮੀਖਿਆ ਕਰਨ ਲਈ ਪ੍ਰੈਕਟਿਕਲ ਤਰੀਕਾ: ਮੁੱਖ ਫਲੋ ਚਲਾਓ ਅਤੇ ਹਰ ਇੱਕ ਸ਼ਰਤ ਦੀ ਲਿਸਟ ਬਣਾਓ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਪੂਰੀ کرਨੀ ਪੈਂਦੀ ਹੈ (ਲਾਜ਼ਮੀ ਫੀਲਡ, ਪਰਮਿਸ਼ਨ, ਸੀਮਾਵਾਂ, ਕਨੈਕਟਿਵਿਟੀ)। ਹਰ ਨੁਕਤੇ ਲਈ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਕ ਸਪਸ਼ਟ ਐਰਰ, ਰਿਕਵਰੀ ਰਾਹ, ਅਤੇ ਇੱਕ ਛੋਟਾ "Need help?" ਨਿਸ਼ਾਨ ਹੈ ਜੋ ਸਕ੍ਰੀਨ 'ਤੇ ਫਿੱਟ ਬੈਠਦਾ ਹੋਵੇ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਹਿਊਰਿਸਟਿਕ ਸਮੀਖਿਆ ਚਲਾਓ

45-ਮਿਨਟ ਰਿਲੀਜ਼ ਰੀਟਰਲ

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

ਪਹਿਲਾਂ ਇਕ ਜਾਂ ਦੋ ਆਹਮ ਯਾਤਰਾਵਾਂ ਚੁਣੋ ਜੋ ਅਸਲ ਮੁੱਲ ਦਰਸਾਂਦੀਆਂ ਹਨ। ਚੰਗੇ ਚੋਣਾਂ ਹਨ: signup, first-time setup, checkout, ਕੁਝ ਨਵਾਂ ਬਣਾਉਣਾ, ਪਬਲਿਸ਼ ਕਰਨਾ, ਜਾਂ ਇੱਕ ਟੀਮਮੇਟ ਨੂੰ ਬੁਲਾਉਣਾ। ਜੇ ਤੁਸੀਂ ਪੂਰੇ ਉਤਪਾਦ ਨੂੰ ਕਵਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਮਿਸ ਕਰ ਦੇਵੋਗੇ।

ਅਗਲਾ, ਇਸ ਰਿਲੀਜ਼ ਲਈ ਡਿਵਾਈਸ ਸੈੱਟ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ। ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਲਈ, ਇਹ ਮਤਲਬ ਡੈਸਕਟਾਪ ਨਾਲ-ਨਾਲ ਮੋਬਾਈਲ ਵੈਬ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਨੈਟਿਵ ਐਪ ਹੈ, ਤਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ iOS ਜਾਂ Android ਡਿਵਾਈਸ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਸਲ ਕੀਬੋਰਡ, ਪਰਮਿਸ਼ਨ, ਅਤੇ ਲੇਆਉਟ ਵਿਹਾਰ ਵੇਖ ਸਕੋ।

ਸਮੀਖਿਆ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਚਲਾਓ:

1. 2-3 ਸਮੀਖਾਕਰਤਾ ਅਤੇ ਇੱਕ ਨੋਟ-ਟੇਕਰ ਨਾਲ 30-45 ਮਿੰਟ ਲਈ ਟਾਈਮਬਾਕਸ ਕਰੋ।
2. ਜਰਨੀ ਨੂੰ ਬਿਨਾਂ ਰੁਕੇ ਐਂਡ-ਟੂ-ਐਂਡ ਵਾਕ ਕਰੋ, ਸਿਰਫ਼ ਫਲੋ ਮਹਿਸੂਸ ਕਰਨ ਅਤੇ ਜਿੱਥੇ ਤੁਸੀਂ ਹੇਜ਼ਟੇਟ ਕਰਦੇ ਹੋ ਉਥੇ ਨਜ਼ਰ ਪਾਉਣ ਲਈ।
3. ਫਿਰ ਧੀਰੇ-ਧੀਰੇ ਦੁਬਾਰਾ ਵਾਕ ਕਰੋ ਅਤੇ ਹਰ ਸਕ੍ਰੀਨ 'ਤੇ ਜਿਹੜੀਆਂ ਨੋਟਾਂ ਆਉਂਦੀਆਂ ਹਨ ਉਹ ਲਾਗ ਕਰੋ।
4. ਹਰ ਨਤੀਜੇ ਨੂੰ ਟੈਗ ਕਰੋ: (a) ਹਿਊਰਿਸਟਿਕ, (b) ਸੀਵਰਿਟੀ (low, medium, high), ਅਤੇ (c) ਸਹੀ ਸਕ੍ਰੀਨ ਜਾਂ ਕਦਮ।
5. ਤੇਜ਼ ਸਬੂਤ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕੈਪਚਰ ਕਰੋ: ਤੁਸੀਂ ਕੀ ਕੀਤਾ, ਕੀ ਉਮੀਦ ਸੀ, ਕੀ ਹੋਇਆ।

ਨੋਟਾਂ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਰੱਖੋ। "Confusing" ਔਖਾ ਹੈ; "Button label says Save, but it actually publishes" ਸਪੱਸ਼ਟ ਹੈ।

ਇੱਕ 10-ਮਿੰਟ ਦਾ ਸੋਰਟਿੰਗ ਪਾਸ ਨਾਲ ਖਤਮ ਕਰੋ। ਛੋਟੀਆਂ ਜਿੱਤਾਂ (ਕਾਪੀ, ਲੇਬਲ, ਸਪੇਸਿੰਗ, ਡਿਫੌਲਟ) ਨੂੰ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਅਲੱਗ ਕਰੋ ਅਤੇ ਉਹ ਮੁੱਦੇ ਜੋ ਤੁਰੰਤ ਠੀਕ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ (ਬ্লੌਕਡ ਟਾਸਕ, ਡੇਟਾ ਲਾਸਕ ਦਾ ਖਤਰਾ, ਅਸਪਸ਼ਟ ਐਰਰ) ਨੂੰ ਉੱਪਰ ਰੱਖੋ।

ਟੀਮਾਂ ਜੋ ਫਸ ਜਾਦੀਆਂ ਹੋਣ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂ (ਅਤੇ ਕਿਵੇਂ ਬਚਣਾ)

ਹਿਊਰਿਸਟਿਕ ਸਮੀਖਿਆਵਾਂ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਸਕ੍ਰੀਨ-ਬਾਈ-ਸਕ੍ਰੀਨ ਆਲੋਚਨਾ ਬਣ ਕੇ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ। ਬਹੁਤ ਸਾਰੀ UX ਸਮੱਸਿਆਵਾਂ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਈ ਅਸਲ ਟਾਸਕ ਖਤਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਅਸਲ ਪਾਬੰਦੀਆਂ (ਛੋਟੇ ਸਕ੍ਰੀਨ, ਰੁਕਾਵਟਾਂ, ਧੀਮਾ ਨੈੱਟਵਰਕ) ਹੇਠਾਂ।

ਫੰਸ 1: ਅਲੱਗ-ਅਲੱਗ ਸਕ੍ਰੀਨਾਂ ਦੀ ਸਮੀਖਿਆ

ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਵਿਅਕਤਿਗਤ ਪੰਨਿਆਂ ਨੂੰ ਵੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਟੁੱਟੇ ਹੋਏ ਹੈਂਡਅਫਜ਼ ਮਿਸ ਕਰ ਜਾਵੋਗੇ: ਇਕ ਫਿਲਟਰ ਜੋ checkout ਤੋਂ ਬਾਅਦ ਰੀਸੈਟ ਹੋ ਜਾਂਦਾ, "Saved" ਟੋਸਟ ਆਉਂਦੀ ਪਰ ਕੁਝ ਸੇਵ ਨਹੀਂ ਹੁੰਦਾ, ਜਾਂ ਇਕ ਬੈਕ ਬਟਨ ਜੋ ਗਲਤ ਕਦਮ 'ਤੇ ਵਾਪਸ ਲੈ ਜਾਂਦਾ।

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

ਫੰਸ 2: ਹਿਊਰਿਸਟਿਕਸ ਨੂੰ ਰਾਏਆਂ ਵਿੱਚ ਬਦਲਣਾ

"ਹਿਊਰਿਸਟਿਕ ਕਹਿੰਦੀ ਹੈ ਇਹ ਮਾੜਾ ਹੈ" ਇੱਕ ਨਤੀਜਾ ਨਹੀਂ। ਇੱਕ ਵਰਤੀ ਯੋਗ ਨੋਟ ਹਿਊਰਿਸਟਿਕ ਨੂੰ ਸਕ੍ਰੀਨ 'ਤੇ ਹੋਈ ਘਟਨਾ ਨਾਲ ਜੋੜਦੀ ਹੈ।

ਮਜ਼ਬੂਤ ਨਤੀਜਾ ਤਿੰਨ ਹਿੱਸਿਆਂ ਵਿੱਚ ਹੁੰਦਾ ਹੈ: ਯੂਜ਼ਰ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ, ਉਸਨੂੰ ਕੀ ਦਿੱਸਿਆ, ਅਤੇ ਕੀ ਬਦਲਾਅ ਕਰਨੇ ਚਾਹੀਦੇ। ਉਦਾਹਰਣ: "ਮੋਬਾਈਲ 'ਤੇ, ਟੈਪ ਕਰਕੇ Done ਕੀਬੋਰਡ ਬੰਦ ਕਰਦਾ ਹੈ ਪਰ ਫਾਰਮ ਸੇਵ ਨਹੀਂ ਹੁੰਦਾ। Rename to Close keyboard ਜਾਂ close ਤੇ auto-save ਜੋੜੋ."

ਫੰਸ 3: ਢਿੱਲ੍ਹੀਆਂ ਨੋਟਾਂ ਲਿਖਣਾ

"Confusing" ਜਾਂ "clunky" ਵਰਗੇ ਸ਼ਬਦ ਕਿਸੇ ਦੀ ਮਦਦ ਨਹੀਂ ਕਰਦੇ।

ਅਸਪਸ਼ਟ ਨੋਟਾਂ ਦੀ ਥਾਂ ਠੋਸ, ਟੈਸਟੇਬਲ ਬਦਲਾਅ ਦੇਵੋ। ਅਤੇ ਬਿਲਕੁਲ ਉਦਾਹਰਣ ਦੇਵੋ: ਸਹੀ ਤੱਤ (button label, icon, error text, step title) ਨਾਂ ਦਿਓ। ਮਿਸ-ਮੈਚ ਦਿੱਸਾਓ (ਉਮੀਦ vs واقعہ)، ਇੱਕ ਵਿਸ਼ੇਸ਼ ਬਦਲਾਅ ਸੁਝਾਓ (copy, placement, default, validation)। ਇੱਕ ਸਕ੍ਰੀਨਸ਼ਾਟ ਰੇਫਰੈਂਸ ਜਾਂ ਕਦਮ ਨੰਬਰ ਜੋੜੋ ਤਾਂ ਲੱਭਣਾ ਆਸਾਨ ਹੋਵੇ। ਪ੍ਰਭਾਵ ਵੀ ਦਸੋ (ਟਾਸਕ ਬਲੌਕ ਕਰਦਾ ਹੈ, ਗਲਤੀਆਂ ਕਰਵਾਂਦਾ ਹੈ, ਯੂਜ਼ਰ ਨੂੰ ਸਲੋ ਕਰਦਾ ਹੈ)।

ਫੰਸ 4: ਮੋਬਾਈਲ-ੋਨਲੀ ਮੁੱਦਿਆਂ ਨੂੰ ਛੱਡਣਾ

ਡੈਸਕਟਾਪ ਸਮੀਖਿਆ ਮੈਨੂੰ ਇਹ ਸਮੱਸਿਆਵਾਂ ਛੱਡ ਸਕਦੀ ਹੈ: ਕੀਬੋਰਡ ਫੀਲਡ ਨੂੰ ਢੱਕਦਾ ਹੈ, ਇਸ਼ਾਰੇ ਟਕਰਾਉਂਦੇ ਹਨ, ਛੋਟੇ ਟੈਪ ਟਾਰਗਟ, ਅਤੇ ਸੇਫ-ਏਰੀਆ ਕਟਆਫ।

ਇਸੇ ਟਾਸਕ ਨੂੰ ਅਸਲ ਫੋਨ 'ਤੇ ਦੁਹਰਾਓ। ਇਕ ਵਾਰੀ ਰੋਟੇਟ ਕਰੋ। ਇਕ-ਹੱਥ ਨਾਲ ਵਰਤ ਕੇ ਦੇਖੋ।

ਫੰਸ 5: ਖਾਲੀ, ਆਫਲਾਈਨ, ਅਤੇ ਧੀਮੀ ਸਟੇਟਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ

ਇੱਕ ਫਲੋ ਤੇਜ਼ ਨੈੱਟਵਰਕ 'ਤੇ ਬਿਲਕੁਲ ਠੀਕ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।

ਹਮੇਸ਼ਾ no-results ਸਕ੍ਰੀਨ, ਪਹਿਲੀ ਵਾਰੀ ਖਾਲੀ ਸਟੇਟ, 5 ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਲੋਡਿੰਗ, ਆਫਲਾਈਨ ਮੋਡ (ਜੇ ਲਾਗੂ ਹੋ), ਅਤੇ ਫੇਲ ਰਿਕਵਾਈਰੀ ਦੀ ਜਾਂਚ ਕਰੋ। ਇਹ ਅਕਸਰ ਫਰਕ ਹੈ "ਚੱਲਦਾ ਹੈ" ਅਤੇ "ਭਰੋਸੇਯੋਗ" ਦਰਮਿਆਨ।

ਤੇਜ਼ ਚੈੱਕਲਿਸਟ ਜੋ ਤੁਸੀਂ ਹਰ ਰਿਲੀਜ਼ ਸਮੀਖਿਆ ਵਿੱਚ ਕਾਪੀ ਕਰ ਸਕਦੇ ਹੋ

ਇਸਨੂੰ ਆਪਣੀਆਂ ਰਿਲੀਜ਼ ਨੋਟਸ ਜਾਂ QA ਡੌਕ ਵਿੱਚ ਪੇਸਟ ਕਰੋ ਅਤੇ ਸਕ੍ਰੀਨ-ਵਾਇਜ਼ ਟਿਕ ਕਰੋ। ਇਹ ਇੱਕ ਤੇਜ਼ ਪਾਸ ਹੈ ਜੋ ਬਿਨਾਂ ਪੂਰੇ ਰਿਸਰਚ ਸਪ੍ਰਿੰਟ ਦੇ ਆਮ ਮੁੱਦੇ ਫੜ ਲੈਂਦਾ ਹੈ ਅਤੇ Nielsen ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਨਾਲ ਮੈਪ ਕੀਤਾ ਹੁੰਦਾ ਹੈ।

5-ਮਿੰਟ UX ਤੇਜ਼ ਜਾਂਚ (ਪਰ ਮੁੱਖ ਫਲੋ ਲਈ)

ਇੱਕ ਕੋਰ ਫਲੋ (sign up, checkout, create project, invite teammate) ਚੁਣੋ ਅਤੇ ਇਹਨਾਂ ਚੈੱਕਾਂ ਨੂੰ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ ਚਲਾਓ।

1. System status ਸਪਸ਼ਟ ਹੈ: ਲੋਡਿੰਗ ਅਤੇ ਸੇਵਿੰਗ ਸਥਿਤੀਆਂ ਦਰਸਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਬਟਨ ਵਿਯਸਤ ਹੋਣ ਦੌਰਾਨ ਟੈਪਯੋਗ ਨਹੀਂ ਦਿਖਦੇ, ਅਤੇ ਸਫਲਤਾ ਫੀਡਬੈਕ ਪੜ੍ਹਨ ਲਈ ਕਾਫੀ ਸਮੇਂ ਰੁਕਦੀ ਹੈ।

2. ਖ਼ਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਉਲਟਣਯੋਗ ਹਨ: ਨੁਕਸਾਨਦਾਇਕ ਜਾਂ ਮਹਿੰਗੇ ਕਦਮਾਂ ਲਈ ਸਪਸ਼ਟ cancel ਰਾਹ, undo ਜਿੱਥੇ ਠੀਕ ਹੋਵੇ, ਅਤੇ ਮੋਡਲਾਂ ਅਤੇ ਬਹੁ-ਕਦਮੀ ਫਾਰਮਾਂ ਵਿੱਚ Back ਉਮੀਦ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ।

3. ਸ਼ਬਦ ਉਪਭੋਗਤਾ ਦੀ ਦੁਨੀਆ ਨਾਲ ਮਿਲਦੇ ਹਨ: ਲੇਬਲ ਆਮ ਭਾਸ਼ਾ ਵਰਤਦੇ ਹਨ, ਅੰਦਰੂਨੀ ਟਰਮ ਨਹੀਂ। ਜੇ ਤਕਨੀਕੀ ਟਰਮ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਤਾਂ ਚੋਣ ਵਾਲੀ ਜਗ੍ਹਾ 'ਤੇ ਛੋਟਾ ਹਿੰਟ ਦਿਉ।

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

5. ਸਕ੍ਰੀਨਾਂ ਵਿਚ ਇਕਸਾਰਤਾ: ਬਟਨ ਦੇ ਨਾਮ, ਥਾਂ, ਅਤੇ ਆਈਕਨ ਦਾ ਮਤਲਬ ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹਾ ਰਹੇ। ਜੇ ਇੱਕ ਸਕ੍ਰੀਨ "Save" ਅਤੇ ਦੂਜੀ "Update" ਕਹਿੰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਚੁਣੋ।

accessibility ਦੇ ਮੁਢਲੀ ਗੱਲਾਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਵੇਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ

ਰਿਲੀਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀਬੋਰਡ ਅਤੇ ਅੰਗੂਠੇ ਨਾਲ ਇੱਕ ਤੇਜ਼ ਪਾਸ ਕਰੋ।

• ਟੈਪ ਟਾਰਗਟ ਆਸਾਨੀ ਨਾਲ ਹਿੱਟ ਹੋਣ (ਕੇਵਲ ਛੋਟੇ ਆਈਕਨ ਨਹੀਂ)
• ਟੈਕਸਟ ਅਤੇ ਮੁੱਖ UI ਦੀ ਕਾਂਟ੍ਰਾਸਟ ਡਿਮ ਰੌਸ਼ਨੀ 'ਚ ਵੀ ਪੜ੍ਹੀ ਜਾ ਸਕੇ
• ਫੋਕਸ ਆਰਡਰ ਸੂਝਵਾਨ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਕਿ ਫੋਕਸ ਕਿੱਥੇ ਹੈ
• ਐਰਰ ਕਿਵੇਂ ਵੀ ਕੇਵਲ ਰੰਗ ਜਾਂ ਆਈਕਨ 'ਤੇ ਨਿਰਭਰ ਨਾ ਹੋਣ, ਅਤੇ ਉਹ ਐਸਿਸਟਿਵ ਟੈਕਨੋਲੋਜੀ ਦੁਆਰਾ ਪੜ੍ਹੇ ਜਾ ਸਕਣ

ਉਦਾਹਰਣ ਵਾਕ-ਚਾਲ: ਇਕ ਅਸਲ ਫੀਚਰ ਫਲੋ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਫੜੋ

ਇਕ ਛੋਟੀ ਟੀਮ ਨੇ ਚਾਰ ਟੀਅਰਾਂ (Free, Pro, Business, Enterprise) ਲਈ ਨਵਾਂ ਪ੍ਰਾਈਸਿੰਗ ਅਤੇ ਅਪਗਰੇਡ ਫਲੋ ਸ਼ਿਪ ਕੀਤਾ। ਮਕਸਦ ਸਧਾਰਣ ਹੈ: ਇੱਕ ਯੂਜ਼ਰ ਨੂੰ ਵੈਬ ਅਤੇ ਮੋਬਾਈਲ ਦੋਹਾਂ 'ਤੇ ਇਕ ਮਿੰਟ ਵਿੱਚ ਅਪਗਰੇਡ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਣਾ।

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

ਇੱਥੇ ਉਹਨਾਂ ਨੇ ਜਲਦੀ ਫੜਿਆ, ਹਿਊਰਿਸਟਿਕਸ ਨਾਲ ਨਕਸ਼ੇਬੱਧ:

• Status visibility: "Upgrade" ਟੈਪ ਕਰਨ ਤੋਂ ਬਾਅਦ ਐਪ checkout ਲੋਡ ਹੋਣ ਦੌਰਾਨ ਖਾਲੀ ਸਕ੍ਰੀਨ ਦਿਖਾਉਂਦੀ ਹੈ। ਮੋਬਾਈਲ 'ਤੇ ਯੂਜ਼ਰ ਸੋਚਦੇ ਹਨ ਕਿ ਇਹ ਅਟਕ ਗਿਆ। ਇਕ ਸਪਸ਼ਟ ਲੋਡਿੰਗ ਸਟੇਟ ਜੋੜੋ ਅਤੇ ਯੋਜਨਾ ਨਾਮ ਦਿਖਾਇਆ ਰਹੇ।
• Match with real world: ਪ੍ਰਾਈਸਿੰਗ ਪੰਨਾ "credits" ਕਹਿੰਦਾ ਹੈ ਬਿਨਾਂ ਇਹ ਦੱਸੇ ਕਿ ਇੱਕ credit ਕੀ ਖਰੀਦਦਾ ਹੈ। ਲੇਬਲ ਨੂੰ ਨਾਂ ਬਦਲੋ ਜਾਂ ਕੀਮਤ ਦੇ ਨੇੜੇ ਇੱਕ ਇਕ-ਲਾਈਨ ਦਾ ਵਿਆਖਿਆ ਜੋੜੋ।
• User control and freedom: checkout ਜਾਂਦਾ ਸਮੇਂ ਕੋਈ Back ਜਾਂ Cancel ਨਹੀਂ। ਇੱਕ ਦਿੱਖਣ ਯੋਗ close ਬਟਨ ਜੋੜੋ ਅਤੇ ਦਾਖਲ ਕੀਤੇ ਡੇਟਾ ਨੁਕਸਾਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ।
• Consistency and standards: ਉਹੀ ਯੋਜਨਾ ਵੈਬ 'ਤੇ "Business" ਅਤੇ ਮੋਬਾਈਲ 'ਤੇ "Team" ਕਹਾਈ ਜਾ ਰਹੀ ਹੈ। ਇੱਕ ਨਾਂ ਚੁਣੋ ਅਤੇ ਹਰ ਥਾਂ, ਰਸੀਦਾਂ ਸਮੇਤ, ਵਰਤੋ।
• Error prevention and recovery: promo code ਫੀਲਡ spaces ਲੈ ਲੈਂਦਾ ਹੈ ਅਤੇ ਫਿਰ "Invalid." ਦਿਖਾਉਂਦਾ ਹੈ। spaces ਆਪਣੇ ਆਪ trim ਕਰੋ ਅਤੇ "Codes have no spaces." ਵਰਗੀ ਮਦਦ-ਭਰੀ ਸੁਨੇਹਾ ਦਿਖਾਓ।

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

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

ਨਤੀਜੇ ਲਿਖਣ ਅਤੇ ਪਹਿਲਾਂ ਕੀ ਠੀਕ ਕਰਨਾ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦੇ ਤਰੀਕੇ

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

ਹਲਕੇ ਵਜ਼ਨ ਦਾ ਸੀਵਰਿਟੀ ਸਕੋਰ ਵਰਤੋ ਤਾਂ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਛਾਂਟ ਸਕਣ:

• 0: ਸਮੱਸਿਆ ਨਹੀਂ (ਸਿਰਫ਼ ਨੋਟ)
• 1: ਨਿੱਕੀ (ਸਮਾਂ ਹੋਵੇ ਤਾਂ ਠੀਕ)
• 2: ਦਰਮਿਆਨਾ (ਜਲਦੀ ਠੀਕ ਕਰੋ, ਯੂਜ਼ਰ ਨੋਟਿਸ ਕਰਦੇ ਹਨ)
• 3: ਵੱਡੀ (ਟਾਸਕ ਬਲੌਕ ਜਾਂ ਗੰਭੀਰ ਉਲਝਣ)
• 4: ਸੰਕਟ (ਡੇਟਾ ਲਾਸ, ਭੁਗਤਾਨ, ਖਾਤਾ ਪਹੁੰਚ, ਸੁਰੱਖਿਆ)

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 ਯੂਜ਼ੇਬਿਲਟੀ ਹਿਊਰਿਸਟਿਕਸ ਨੂੰ ਛੋਟੀ ਸੁਰੱਖਿਆ ਜਾਂਚ ਵਾਂਗ ਸਲੂਕ ਕਰੋ, ਨਾ ਕਿ ਇਕ ਵਿਸ਼ੇਸ਼ ਸਮਾਗਮ। ਹਰ ਰਿਲੀਜ਼ ਲਈ ਇਕ ਮਾਲਕ ਚੁਣੋ (ਰੋਟੇਟ ਕਰੋ), ਇੱਕ ਕੈਡੈਂਸ ਸੈੱਟ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਸ਼ਿਪਿੰਗ ਰਿਦਮ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋਵੇ, ਅਤੇ ਸਕੋਪ ਨੂੰ ਤੰਗ ਰੱਖੋ ਤਾਂ ਜੋ ਇਹ ਅਸਲ ਵਿੱਚ ਹੋਵੇ।

ਇਕ ਸਧਾਰਣ ਰੀਟਿਨ ਜੋ ਸਮੇਂ-ਕਾ-ਸਥਿਰ ਰਹੇ:

• ਪ੍ਰਤੀ ਪਲੈਟਫਾਰਮ (web, iOS, Android) 20 ਤੋਂ 40 ਮਿੰਟ ਲਈ ਟਾਈਮਬਾਕਸ ਕਰੋ।
• ਪਹਿਲਾਂ ਟਾਪ 3-5 ਯੂਜ਼ਰ ਰਾਹਾਂ (sign up, search, checkout, settings) ਦੀ ਸਮੀਖਿਆ ਕਰੋ।
• findings ਨੂੰ "issue + heuristic + screenshot + suggested fix" ਵਜੋਂ ਕੈਪਚਰ ਕਰੋ।
• ਇੱਕ ਛੋਟੀ ਫੈਸਲਾ ਪਹੁੰਚ 'ਤੇ ਖਤਮ ਕਰੋ: ਹੁਣ ਠੀਕ ਕਰੋ, ਸ਼ੈਡੀਊਲ ਕਰੋ, ਜਾਂ ਇਕ ਵਜ੍ਹਾ ਦੇ ਕੇ ਸਵੀਕਾਰ ਕਰੋ।

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

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

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਅਤੇ ਦੁਹਰਾਉਂਦੇ ਹੋ ਇਕ chat-driven app builder ਨਾਲ, ਤਾਂ ਉਹ ਛੋਟੇ ਨਿਰਮਾਣਾਂ ਨੂੰ ਇੱਕ ਦੁਹਰਾਏ ਯੂਐਕਸ ਚੈੱਕ ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ। Koder.ai (koder.ai) ਵਰਤਣ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ, Planning Mode ਨਾਲ snapshots ਅਤੇ rollback ਨਾਲ ਇਹ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿ فਲੋ ਅਤੇ ਕਾਪੀ ਉੱਤੇ ਪਹਿਲਾਂ ਸਹਿਮਤੀ ਬਣਾਈ ਜਾਵੇ, ਤਬਦੀਲੀਆਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕੀਤੀਆਂ ਜਾਣ, ਅਤੇ ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਫਿਕਸਾਂ ਨੂੰ ਇਕੋ ਬੇਸਲਾਈਨ ਦੇ ਖਿਲਾਫ਼ ਵੈਰੀਫਾਈ ਕੀਤਾ ਜਾਵੇ।