12 ਨਵੰ 2025·8 ਮਿੰਟ
ਭੁੱਝਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਤੋਂ ਬਚੋ: Don Norman ਦੇ UX ਸਿਧਾਂਤ
Don Norman ਦੇ UX ਸਿਧਾਂਤ ਤੁਹਾਨੂੰ ਗੁੰਝਲਦਾਰ ਫਲੋਜ਼ ਪਹਿਚਾਣਨ, ਸਪੋਰਟ ਖਰਚ ਘਟਾਉਣ ਅਤੇ ਉਸ ਵੇਲੇ ਪਹਿਲਾਂ chat-ਤਿਆਰ ਸਕ੍ਰੀਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਯੂਜ਼ਰ ਫਸਣ।
Don Norman ਦੇ UX ਸਿਧਾਂਤ ਤੁਹਾਨੂੰ ਗੁੰਝਲਦਾਰ ਫਲੋਜ਼ ਪਹਿਚਾਣਨ, ਸਪੋਰਟ ਖਰਚ ਘਟਾਉਣ ਅਤੇ ਉਸ ਵੇਲੇ ਪਹਿਲਾਂ chat-ਤਿਆਰ ਸਕ੍ਰੀਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਯੂਜ਼ਰ ਫਸਣ।
ਭੁੰਝਲ-ਭਰਮ ਵਾਲੇ ਇੰਟਰਫੇਸ ਸਿਰਫ਼ ਖਰਾਬ ਮਹਿਲੂਸ ਨਹੀਂ ਰਹਿੰਦੇ — ਉਹ ਮਾਪਯੋਗ ਖਰਚ ਪੈਦਾ ਕਰਦੇ ਹਨ: ਲੋਕ ਸਾਈਨ-ਅਪ ਜਾਂ ਚੇਕਆਊਟ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਰਿਫੰਡ ਲੈ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਸਹਾਇਤਾ ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹਨ ਜਿਹੜੀਆਂ ਗੱਲਾਂ ਸਾਫ਼ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਸਨ।
ਅਕਸਰ ਸਮੱਸਿਆ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੁੰਦੀ; ਮੁੱਦਾ ਸਪਸ਼ਟਤਾ ਹੁੰਦੀ ਹੈ। ਯੂਜ਼ਰ ਨਹੀਂ ਸਮਝ ਪਾਉਂਦੇ ਕਿ ਸਿਸਟਮ ਕੀ ਚਾਹੁੰਦਾ ਹੈ, ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ, ਜਾਂ ਅੱਗੇ ਵੱਧਣਾ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇਹ ਭੁੱਲ-ਪੁਲਟਾ ਕੁਝ ਆਮ ਤਰੀਕਿਆਂ ਨਾਲ ਅਸਲ ਪੈਸਾ ਅਤੇ ਸਮਾਂ ਬਣ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਸ਼ੱਕ ਵਿੱਚ ਰੁਕ ਜਾਂਦਾ ਹੈ ਤਾਂ ਡ੍ਰਾਪ-ਆਫ਼ ਵੱਧਦੇ ਹਨ। ਸਹਾਇਤਾ ਵਿੱਚ "X ਕਿੱਥੇ ਹੈ?" ਅਤੇ "ਇਹ ਕਿਉਂ ਹੋਇਆ?" ਵਾਲੇ ਟਿਕਟ ਭਰ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਕੀਮਤ, ਪੁਸ਼ਟੀ, ਜਾਂ ਰੱਦ ਕਰਨ ਦੇ ਫਲੋ ਅਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ ਤਾਂ ਰਿਫੰਡ ਅਤੇ ਚਾਰਜਬੈਕ ਵੱਧਦੇ ਹਨ। ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਟੀਮਾਂ ਗਾਈਡ ਅਤੇ ਵਰਕअरਾਊਂਡ ਲਿਖਣ ਵਿੱਚ ਸਮਾਂ ਖਰਚ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰੋਡਕਟ ਖੁਦ ਨਾਈ ਸਮਝਾਉਂਦਾ।
ਛੋਟੀ-ਮੁਸ਼ਕਲ ਮਹਿੰਗੀ ਪੈਂਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਆਮ ਫਲੋ ਵਿੱਚ ਦੁਹਰਾਈ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਗੁੰਝਲਦਾਰ ਸਾਈਨ-ਅਪ ਇੱਕ ਵੇਰ੍ਹੇ ਲਈ ਯੂਜ਼ਰ ਦੀ ਕੀਮਤ ਹੋ ਸਕਦਾ ਹੈ; ਇੱਕ ਗੁੰਝਲਦਾਰ ਚੇਕਆਊਟ ਹਰ ਵਾਰੀ ਖਰਚੀ ਹੋ ਸਕਦਾ ਹੈ।
ਸਧਾਰਨ ਇੱਕ ਦਰਸ਼ਾਉਂਦਾ ਦ੍ਰਿਸ਼ ਹੁੰਦਾ ਹੈ: ਕੋਈ ਖਾਤਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸੈਟਿੰਗ ਬਦਲਦਾ ਹੈ (ਜਿਵੇਂ ਨੋਟੀਫਿਕੇਸ਼ਨ ਫ੍ਰਿਕਵੈਂਸੀ)। ਉਹ ਇੱਕ ਟੌਗਲ ਵੇਖਦਾ, ਸਪર્શ ਕਰਦਾ, ਅਤੇ ਕੋਈ ਪੁਸ਼ਟੀ ਨਹੀਂ ਮਿਲਦੀ। ਬਾਅਦ ਵਿੱਚ ਉਹ ਫਿਰ ਵੀ ਈਮੇਲ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਸਪੋਰਟ ਟਿਕਟ ਹੈ, ਯੂਜ਼ਰ ਆਪਣੇ ਆਪ ਨੂੰ ਧੋਖੇ ਵਿੱਚ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਭਰੋਸਾ ਘਟ ਜਾਂਦਾ ਹੈ। UI ਸਾਫ਼ ਲੱਗ ਸਕਦੀ ਹੈ, ਪਰ ਅਨੁਭਵ ਅਸਪਸ਼ਟ ਹੈ।
ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਣ ਨਾਲ ਇਹ ਗਲਤੀਆਂ ਛੁਪਣ ਲਈ ਆਸਾਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਉਹਨਾਂ ਚੈਟ ਟੂਲਾਂ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਸਕ੍ਰੀਨ ਅਤੇ ਫਲੋ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਕਈ ਕਦਮ ਉਸ ਨਿਰਮਾਤਾ ਲਈ ਤਰਕਸੰਗਤ ਹੋ ਸਕਦੇ ਹਨ ਪਰ ਪਹਿਲੀ ਵਾਰੀ ਦੇ ਯੂਜ਼ਰ ਲਈ ਨਹੀਂ।
ਸੁਧਾਰ Don Norman ਨਾਲ ਸਬੰਧਤ ਕੁਝ ਆਸਾਨ ਵਿਚਾਰਾਂ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਕਾਰਵਾਈਆਂ ਸਪਸ਼ਟ ਬਣਾਓ, ਯੂਜ਼ਰ ਦੇ ਮਾਨਸਿਕ ਮਾਡਲ ਨਾਲ ਮੇਲ ਖਾਓ, ਤੇਜ਼ ਫੀਡਬੈਕ ਦਿਓ, ਅਤੇ ਗਲਤੀਆਂ ਵਾਪਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕੋ। ਹੇਠਾਂ ਦੀ ਗਾਈਡ ਵਿਆਵਹਾਰਿਕ ਰਹੇਗੀ: ਥੋੜ੍ਹੇ ਸਿਧਾਂਤ ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਰੂਟੀਨ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਬਣਾਈ ਕਿਸੇ ਵੀ ਫਲੋ ਨੂੰ ਪ੍ਰਚੀਨ ਯੂਜ਼ਰਾਂ ਦੇ ਫਸਣ ਤੋਂ ਪਹਿਲਾਂ ਵੈਧ ਕਰਨ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ।
ਲੋਕ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹਦੇ। ਉਹ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ।
ਯੂਜ਼ਰ ਇੱਕ ਮਾਨਸਿਕ ਮਾਡਲ ਲੈ ਕੇ ਆਉਂਦੇ ਹਨ — ਉਹ ਇੱਕ ਕਹਾਣੀ ਜੋ ਉਹ ਮਨ ਵਿੱਚ ਰੱਖਦੇ ਹਨ ਕਿ ਕੁਝ ਕਿਵੇਂ ਕੰਮ ਕਰੇਗਾ, ਹੋਰ ਐਪਸ, ਅਸਲੀ ਜਗਤ ਦੀਆਂ ਚੀਜ਼ਾਂ ਅਤੇ ਆਦਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ। ਜਦੋਂ ਤੁਹਾਡਾ ਇੰਟਰਫੇਸ ਉਸ ਮਾਡਲ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੇ ਹਨ। ਜਦੋਂ ਇਹ ਮਾਡਲ ਦਾ ਵਿਰੋਧ ਕਰਦਾ ਹੈ, ਉਹ ਰੁਕ ਜਾਂਦੇ, ਹਿੱਲਦੇ ਅਤੇ jene ਕਹਿੰਦੇ 'ਗਲਤੀਆਂ' ਕਰਦੇ ਹਨ ਜੋ ਦਰਅਸਲ ਡਿਜ਼ਾਈਨ ਦੀਆਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਕ ਯੂਜ਼ਰ ਜੋ "Save" ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦਾ ਕੰਮ ਸੁਰੱਖਿਅਤ ਹੋ ਗਿਆ। "Delete" ਤੇ ਕਲਿੱਕ ਕਰਨ ਵਾਲੇ ਨੂੰ ਚੇਤਾਵਨੀ ਜਾਂ ਵਾਪਸੀ ਦਾ ਆਸਾਨ ਰਸਤਾ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਸੇਅਰਚ ਬੌਕਸ ਦੇਖ ਕੇ ਯੂਜ਼ਰ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਟਾਈਪ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ Enter ਦਬਾ ਸਕਦਾ ਹੈ। ਇਹ ਉਮੀਦਾਂ ਸਹਾਇਕ ਟੈਕਸਟ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੁੰਦੀਆਂ ਹਨ।
ਚੰਗੀ UX ਉਹਨਾਂ ਉਮੀਦਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਨਾ ਕਿ ਲੋਕਾਂ ਨੂੰ ਦੁਬਾਰਾ ਸਿਖਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼।
ਅਫੋਰਡੈਂਸ ਉਹ ਹੈ ਜੋ ਇਕ ਐਲਿਮੈਂਟ ਕਰ ਸਕਦਾ ਹੈ। ਸਾਈਨਿਫਾਇਰ ਉਹ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਟੈਕਸਟ ਫੀਲਡ ਟਾਈਪ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ। ਸਾਈਨਿਫਾਇਰ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਬਾਕਸ, ਕਰਸਰ, ਅਤੇ ਕਦੇ-ਕਦੇ ਪਲੇਸਹੋਲਡਰ ਟੈਕਸਟ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਬਟਨ ਕਲਿੱਕ ਹੋ ਸਕਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ। ਸਾਈਨਿਫਾਇਰ ਉਸਦੀ ਸ਼ਕਲ, ਕਾਂਟਰਾਸਟ ਅਤੇ ਲੇਬਲ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਬਟਨ ਨੂੰ ਸਧਾਰਨ ਟੈਕਸਟ ਵਰਗੀ ਦਿਖਾਓਗੇ, ਅਫੋਰਡੈਂਸ ਨਹੀਂ ਬਦਲੇਗੀ ਪਰ ਸਾਈਨਿਫਾਇਰ ਕਮਜ਼ੋਰ ਹੋ ਜਾਵੇਗਾ, ਇਸ ਲਈ ਲੋਕ ਇਸਨੂੰ ਦੇਖ ਨਹੀਂ ਪਾਓਗੇ।
Gulf of execution ਉਹ ਖਾਈ ਹੈ ਜੋ ਯੂਜ਼ਰ ਜੋ ਚਾਹੁੰਦਾ ਹੈ ਅਤੇ UI ਦੇ ਉਪਲਬਧ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਹੈ। ਜੇ ਕਿਸੇ ਨੂੰ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ ਬਦਲਣਾ ਹੋ ਪਰ ਉਹ ਸਿਰਫ਼ "Edit Profile" ਵੇਖਦਾ ਹੈ, ਉਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕੀ ਕਰਨਾ ਹੈ।
Gulf of evaluation ਉਹ ਖਾਈ ਹੈ ਜੋ ਸਿਸਟਮ ਨੇ ਕੀ ਕੀਤਾ ਅਤੇ ਯੂਜ਼ਰ ਸਕ੍ਰੀਨ ਤੋਂ ਕੀ ਸਮਝ ਸਕਦਾ ਹੈ ਵਿੱਚ ਹੈ। ਜੇ ਉਹ "Pay" ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਹੁੰਦਾ (ਜਾਂ ਸਿਰਫ਼ ਛੋਟਾ ਸਪਿਨਰ), ਉਹ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਕਿ ਉਹ ਕੰਮ ਹੋਇਆ, ਫੇਲ ਹੋਇਆ ਜਾਂ ਅਜੇ ਪ੍ਰੋਸੈਸ ਹੋ ਰਿਹਾ ਹੈ।
ਚੰਗਾ ਫੀਡਬੈਕ ਤੇਜ਼, ਸਪਸ਼ਟ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਇਹ ਕੰਮ ਕੀਤਾ, ਕੀ ਬਦਲਿਆ, ਅਤੇ ਮੈਨੂੰ ਅਗਲਾ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
ਇਹ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਚੈਟ-ਅਧਾਰਿਤ ਟੂਲਾਂ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ। ਜਨਰੇਟ ਕੀਤੀਆਂ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਵੀ ਸਪਸ਼ਟ ਸਾਈਨਿਫਾਇਰਾਂ ਅਤੇ ਕੋਈ ਭੁੱਲ-ਗੁੰਝਲ ਨਹੀਂ ਛੱਡਣ ਵਾਲੇ ਫੀਡਬੈਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ ਪਹਿਲੀ ਵਾਰੀ ਦੇ ਯੂਜ਼ਰ ਫਸਣ ਨਾ ਜਾਣ।
ਗੁੰਝਲ ਵਾਲੇ ਇੰਟਰਫੇਸ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ ਗਲਤ ਹੋਣ ਕਾਰਨ ਨਹੀਂ fail ਹੁੰਦੇ, ਬਲਕਿ ਇਸ ਕਾਰਨ ਕਿ ਸਕ੍ਰੀਨ ਉਸ ਚੀਜ਼ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ ਜੋ ਲੋਕ ਅਗਲੇ ਕਦਮ 'ਤੇ ਹੋਵੇਗਾ ਸੋਚਦੇ ਹਨ।
ਕਲਾਸਿਕ ਉਦਾਹਰਨ "Save vs Submit vs Publish" ਦਾ ਗੁੰਝਲ ਹੈ। ਕਈ ਟੂਲਾਂ ਵਿੱਚ, "Save" ਦਾ ਮਤਲਬ "ਡ੍ਰਾਫਟ ਸੇਵ" ਹੋ ਸਕਦਾ ਹੈ, "ਸੇਅਰ ਕਰਨ ਲਈ ਸੇਵ" ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ " ਪ੍ਰਕਿਰਿਆ ਖਤਮ" ਹੋ ਸਕਦਾ ਹੈ। ਜੋ ਯੂਜ਼ਰ ਸਿਰਫ਼ ਆਪਣਾ ਕੰਮ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹਨ ਉਹ ਸੰਕોચਤ ਹੋਣਗੇ, ਜਾਂ ਗਲਤ বোਟਨ ਦਬਾ ਕੇ ਪੈਨਿਕ ਕਰਨਗੇ। "Save draft" ਅਤੇ "Publish now" ਵਰਗੇ ਲੇਬਲ ਉਸ ਡਰ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਨਤੀਜੇ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ।
ਸੈਟਿੰਗ ਸਕ੍ਰੀਨਾਂ ਵੀ ਬਹੁਤ ਖਾਮੋਸ਼ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀਆਂ ਹਨ। ਅਣਸਪਸ਼ਟ ਜਾਂ ਉਲਟੇ ਟੌਗਲ ਹਰ ਥਾਂ ਮਿਲਦੇ ਹਨ: "Notifications" ਨਾਮ ਦੇ ਇੱਕ switch ਜਿਸ ਵਿੱਚ ਨਹੀਂ ਦੱਸਿਆ ਕਿ ON ਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਹੋਰ ਬੁਰਾ ਉਦਾਹਰਣ ਉਹ ਹੈ ਜੋ ਦਿੱਖ ਵਿੱਚ ਚਾਲੂ ਲੱਗਦਾ ਹੈ ਪਰ ਅਸਲ ਵਿੱਚ ਕੋਈ ਹੋਰ ਨਿਰਭਰਤਾ ਦੇ ਕਾਰਨ ਬੰਦ ਹੈ। ਲੋਕ ਪੇਜ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ ਅਤੇ ਅਨੁਮਾਨ ਲਗਾਉਣ ਲੱਗਦੇ ਹਨ।
ਫਾਰਮ ਵੀ ਅਕਸਰ ਦੁਹਰਾਓ ਵਾਲੇ ਮੁਤਲਬ ਹਨ। ਇੱਕ ਸਾਈਨਅਪ ਫਾਰਮ ਜੋ ਗਲਤੀ ਦੇਣ ਤੋਂ ਬਾਅਦ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਉਂ ਫੇਲ ਹੋਇਆ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰ ਨੂੰ ਕਹਿੰਦਾ ਹੈ "ਤਕਦੀਰ ਆਜ਼ਮਾਓ"। ਪਾਸਵਰਡ ਨਿਯਮ ਜੇ ਇਰਰ ਤੋਂ ਬਾਅਦ ਹੀ ਦਿੱਖਦੇ ਹਨ, ਜ਼ਰੂਰੀ ਫੀਲਡ ਸਿਰਫ਼ ਇੱਕ ਛੋਟੀ ਲਾਲ ਰੇਖਾ ਨਾਲ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਜਾਂ ਸੁਨੇਹੇ "Invalid input" ਵਰਗੇ ਸਾਰੇ ਵਾਧੂ ਕਾਮ ਕਰਵਾਉਂਦੇ ਹਨ।
ਖਾਲੀ ਸਥਿਤੀਆਂ ਵੀ ਲੋਕਾਂ ਨੂੰ ਫਸਾ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਖਾਲੀ ਡੈਸ਼ਬੋਰਡ ਜਿਸ 'ਤੇ ਸਿਰਫ਼ "No data yet" ਲਿਖਿਆ ਹੋਵੇ ਯੂਜ਼ਰ ਨੂੰ ਰਾਹ ਭੁਲਾ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਮਦਦਗਾਰ ਖਾਲੀ ਸਥਿਤੀ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਅਗਲੇ ਕੀ ਕਰਨ? ਇੱਕ ਸਧਾਰਨ "Create your first project" ਅਤੇ ਇੱਕ ਵਾਕ ਤੇ ਦੱਸਣਾ ਕਿ ਇਸ ਤੋਂ ਬਾਅਦ ਕੀ ਹੋਵੇਗਾ ਕਾਫੀ ਹੁੰਦਾ ਹੈ।
ਸੰਘਟਨਕ ਕਾਰਵਾਈਆਂ ਅਕਸਰ ਮਾਸੂਮ ਲਫ਼ਜ਼ਾਂ ਦੇ ਪਿੱਛੇ ਲੁਕਿਆ ਹੁੰਦੇ ਹਨ। "Remove" ਦਾ ਮਤਲਬ "ਇਸ ਲਿਸਟ ਤੋਂ ਹਟਾਓ" ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ "ਸਦਾ ਲਈ ਮਿਟਾ ਦਿਓ" ਵੀ। ਜੇ ਨਤੀਜਾ ਰਿਵਰਸਿਬਲ ਨਹੀਂ ਹੈ ਤਾਂ ਸ਼ਬਦਾਵਲੀ ਨੂੰ ਸਪਸ਼ਟ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਖੇਤਰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਦੁਬਾਰਾ ਜਾਂਚਣ ਯੋਗ ਹਨ: ਬਟਨ ਲੇਬਲ ਨਤੀਜੇ ਦਾ ਵਰਣਨ ਕਰਨ, ਟੌਗਲਾਂ ਨੂੰ ON ਤੇ OFF ਦਾ ਅਰਥ ਦੱਸਣਾ, ਫਾਰਮ ਗਲਤੀਆਂ ਨੂੰ ਸਹੀ ਫੀਲਡ ਅਤੇ ਨਿਯਮ ਤੇ ਸੰਕੇਤ ਕਰਨਾ, ਖਾਲੀ ਸਥਿਤੀਆਂ ਨੂੰ ਅਗਲਾ ਕਦਮ ਦਿਖਾਉਣਾ, ਅਤੇ ਵਿਨਾਸ਼ਕ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸਪਸ਼ਟ ਨਾਮ ਦੇ ਕੇ ਢੁੱਕਵੀਂ ਪੁਸ਼ਟੀ ਰੱਖਣਾ।
ਜਿਆਦਾਤਰ ਗੁੰਝਲ ਉਸ ਸਮੇਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਉਤਪਾਦ ਸਕ੍ਰੀਨਾਂ ਤੋਂ ਬਾਹਰ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਯੂਜ਼ਰ ਦੇ ਮਕਸਦ ਤੋਂ ਅੰਦਰੋਂ। ਇੱਕ ਸਕ੍ਰੀਨ ਪੂਰੀ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਇਹ ਕਿਸੇ ਨੂੰ ਉਹ ਕੰਮ ਮੁਕੰਮਲ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਨਹੀਂ ਕਰਦੀ ਜਿਸ ਲਈ ਉਹ ਆਏ।
ਇੱਕ ਲਕੜੀ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਟਾਸਕ ਵਾਂਗ ਲਿਖੋ, ਫੀਚਰ ਵਾਂਗ ਨਹੀਂ: "ਇੱਕ ਚਲਦਾ-ਫਿਰਦਾ ਇਨਵੌਇਸ ਬਣਾਓ ਅਤੇ ਭੇਜੋ," "ਸ਼ੁੱਕਰਵਾਰ ਲਈ ਹੇਅਰਕਟ ਬੁੱਕ ਕਰੋ," ਜਾਂ "ਲੈਂਡਿੰਗ ਪੇਜ ਪਬਲਿਸ਼ ਕਰੋ।" ਉਦਦੇਸ਼ ਤੁਹਾਡਾ ਐਂਕਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ "ਮੁਕੰਮਲ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ।
ਫਿਰ ਯਾਤਰਾ ਨੂੰ ਉਹਨਾਂ ਚੁੱਣੇ ਹੋਏ ਕਦਮਾਂ ਤੱਕ ਘਟਾਓ ਜੋ ਕੁਦਰਤੀ ਲਗਦੇ ਹਨ। ਗੁੰਝਲ ਘਟਾਉਣ ਦੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਿਆਂ ਵਿਚੋਂ ਇੱਕ ਹੈ ਉਹ ਕਦਮ ਹਟਾ ਦੇਣਾ ਜੋ ਸਿਰਫ਼ ਨਿਰਮਾਤਾ ਦੇ ਲਈ ਸੰਦਰਭ ਰੱਖਦੇ ਸਨ। ਨਿਰਮਾਤਾ ਆਮ ਤੌਰ 'ਤੇ ਸੈੱਟਅੱਪ ਦੌਰਾਨ ਆੱਗੇ ਛੱਡਦੇ ਹਨ। ਨਵੇਂ ਯੂਜ਼ਰ ਅਕਸਰ ਪਹਿਲਾਂ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸੈਟਿੰਗਸ ਅਨੁਕੂਲ ਕਰ ਲੈਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਟੈਸਟ ਹਰ ਕਦਮ ਨੂੰ ਤਿੰਨ ਸਵਾਲਾਂ ਨਾਲ ਜਾਂਚਣਾ ਹੈ:
ਜਦੋਂ ਕਿਸੇ ਵੀ ਕਦਮ ਦਾ ਇੱਕ ਵੀ ਸਵਾਲ ਫੇਲ ਹੋਵੇ, ਯੂਜ਼ਰ ਧੀਰੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਉਹ ਹੋਵਰ, ਸਕ੍ਰੋਲ, ਅਨੇਕ ਮੇਨੂੰ ਖੋਲ੍ਹਣਾ ਜਾਂ ਸਹਿਕਰਮੀ ਕੋਲ ਪੁੱਛਣ ਲਈ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਰੁਕਣ ਵਾਲੀਆਂ ਥਾਵਾਂ ਲਈ ਧਿਆਨ ਦਿਓ: ਇੱਕ ਚੋਣ ਜਿਸਦੇ ਵਿਚਕਾਰ ਅੰਤਰ ਅਸਪਸ਼ਟ ਹੈ ("Workspace" vs "Project"), ਇੱਕ ਫਾਰਮ ਜੋ ਉਹ ਜਾਣਕਾਰੀ ਮੰਗਦਾ ਹੈ ਜੋ ਉਨ੍ਹਾਂ ਕੋਲ ਹੁਣ ਨਹੀਂ ਹੈ, ਇੱਕ ਪੇਜ਼ ਜਿਸ 'ਤੇ ਕਈ ਮੁੱਖ ਬਟਨ ਹਨ, ਜਾਂ ਇੱਕ ਫਲੋ ਜੋ ਮੱਧ ਰਾਹ ਵਿੱਚ ਸ਼ਬਦਾਵਲੀ ਬਦਲ ਦਿੰਦਾ ਹੈ (ਸਾਈਨਅਪ, ਫਿਰ "provision," ਫਿਰ "deploy").
ਜਦੋਂ ਤੁਸੀਂ ਰੁਕਣ ਵਾਲੀ ਥਾਂ ਨੂੰ ਪਛਾਣੋ, ਅਗਲੀ ਕਾਰਵਾਈ ਨੂੰ ਲਕੜੀ ਨਾਲ ਮੇਲ ਖਵਾਉ। ਯੂਜ਼ਰ ਦੇ ਸ਼ਬਦ ਵਰਤੋ, ਅਡਵਾਂਸਡ ਸੈਟਿੰਗਸ ਬਾਅਦ ਵੱਖਰੇ ਕਰੋ, ਅਤੇ ਇੱਕ ਸੰਪ੍ਰਤਮ ਅਗਲਾ ਕਦਮ ਬਣਾਓ। ਫਲੋ ਇੱਕ ਦਿੱਖਾਈ ਰਾਹ ਦੀ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੋਈ ਪ੍ਰਸ਼ਨਾਵਲੀ ਨਹੀਂ।
ਲੋਕ ਲਗਭਗ ਕਿਸੇ ਵੀ ਇੰਟਰਫੇਸ ਨੂੰ ਦੇਖ ਭਾਲ ਸਕਦੇ ਹਨ ਜੇ ਉਹ ਜਾਣਦੇ ਹਨ ਕਿ ਸਿਸਟਮ ਕੀ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੇ ਕਿੰਝ ਕਾਰਵਾਈ ਕੀਤੀ। ਗੁੰਝਲ ਉਦੋਂ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਸਕ੍ਰੀਨ ਚੁੱਪ ਰਹਿੰਦੀ ਹੈ: ਕੋਈ ਸੇਵਿੰਗ ਦਾ ਚਿੰਨ੍ਹ ਨਹੀਂ, ਕੋਈ ਇशਾਰਾ ਕਿ ਕੰਮ ਹੋ ਰਿਹਾ ਹੈ, ਕੋਈ ਸਬੂਤ ਨਹੀਂ ਕਿ ਬਟਨ ਨੇ ਕੁਝ ਕੀਤਾ।
ਤੇਜ਼ ਫੀਡਬੈਕ ਸੁੰਦਰਤਾ ਲਈ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਇੰਟਰਫੇਸ ਦੇਣ ਦਾ ਤਰੀਕਾ ਹੈ, "ਮੈਂ ਤੁਹਾਨੂੰ ਸੁਣ ਲਿਆ।" ਇਹ ਡਬਲ ਕਲਿੱਕ, ਗੁੱਸੇ ਵਿੱਚ ਰੀਫਰੈਸ਼, ਅਤੇ ਛੱਡੇ ਹੋਏ ਫਾਰਮਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਜੋ ਵੀ ਕਾਰਵਾਈ ਇਕ ਝਲਕ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦੀ ਹੈ, ਉਸ ਲਈ ਦਿੱਖਾਈ ਸਥਿਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਪੇਜ਼ ਲੋਡ ਹੋਣਾ, ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸ ਕਰਨਾ, ਫਾਈਲ ਅਪਲੋਡ ਕਰਨਾ, ਰਿਪੋਰਟ ਜੈਨਰੇਟ ਕਰਨਾ, ਜਾਂ ਸੁਨੇਹਾ ਭੇਜਣਾ ਸ਼ਾਮਿਲ ਹੈ।
ਠ ਸੂਤਰ: ਜੇ ਯੂਜ਼ਰ ਪੁੱਛ ਸਕਦਾ ਹੈ "ਕੀ ਇਹ ਹੋ ਗਿਆ?" ਤਾਂ ਤੁਹਾਡੀ UI ਪਹਿਲਾਂ ਹੀ ਜਵਾਬ ਦੇ ਰਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇਸਨੂੰ ਠੋਸ ਰੱਖੋ:
ਇੱਕ ਪੁਸ਼ਟੀ ਸਿਰਫ਼ ਤਦ ਹੀ ਲਾਭਕਾਰੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਦੱਸੇ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਇਹ ਕਿੱਥੇ ਮਿਲੇਗਾ। "Success" ਘੁੱਟਕ ਹੁੰਦਾ ਹੈ। "Invoice sent to [email protected]. You can see it in Sent invoices" ਸ਼ਾਂਤੀਦਾਇਕ ਹੁੰਦਾ ਹੈ।
ਗਲਤੀਆਂ ਦਿਸ਼ਾ-ਦਰਸ਼ਨ ਕਰਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਸਜ਼ਾ ਨਹੀਂ। ਚੰਗੇ ਐਰਰ ਫੀਡਬੈਕ ਵਿੱਚ ਤਿੰਨ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ: ਕੀ ਗਲਤ ਹੋਇਆ, ਇਸਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ, ਅਤੇ ਯਕੀਨ ਦਿਲਾਉਣਾ ਕਿ ਯੂਜ਼ਰ ਦਾ ਕੰਮ ਗੁੰਮ ਨਹੀਂ ਹੋਇਆ। ਜੋ ਉਨ੍ਹਾਂ ਨੇ ਟਾਇਪ ਕੀਤਾ ਉਹ ਰੱਖੋ। ਇੱਕ ਫੀਲਡ ਗਲਤ ਹੋਣ 'ਤੇ ਫਾਰਮ ਨੂੰ ਰੀਸੈੱਟ ਨਾ ਕਰੋ।
ਚੁੱਪFailures ਸਭ ਤੋਂ ਵੱਝੀਆ ਨੇਗੇਟਿਵ ਹੁੰਦੇ ਹਨ। ਜੇ ਕੁਝ ਫੇਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸਪਸ਼ਟ ਦੱਸੋ ਅਤੇ ਅਗਲਾ ਕਾਰਵਾਈ ਦਿਓ (Retry, Edit, Contact support). ਜੇ ਤੁਸੀਂ autosave ਕਰਦੇ ਹੋ ਤਾਂ ਇਹ ਦਿਖਾਓ। ਜੇ ਤੁਸੀਂ ਸੇਵ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਦ ਕਾਰਨ ਦੱਸੋ।
ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤੀਆਂ ਇਸ ਲਈ ਨਹੀਂ ਕਰਦੇ ਕਿ ਉਹ ਲਾਪਰਵਾਹ ਹਨ। ਉਹ ਇਸ ਲਈ ਕਰਦੇ ਹਨ ਕਿ ਇੰਟਰਫੇਸ ਚੁੱਪਚਾਪ ਗਲਤ ਕਦਮ ਨੂੰ ਇਜ਼ਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਾਂ ਅਗਲੇ ਹੋਣ ਵਾਲੇ ਨਤੀਜੇ ਨੂੰ ਨਹੀਂ ਦਿੱਖਾਉਂਦਾ।
Don Norman ਦਾ ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨ ਕਾਰਵਾਈ ਬਣਾਓ।
ਚੰਗੀ ਪਾਬੰਧੀ ਮ੍ਰਿਤ ਬਿੰਦੂ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਕੁਝ ਨਿਸ਼ਕ੍ਰਿਆਤਮਕ ਹੈ, ਯੂਜ਼ਰ ਨੂੰ ਸਮਝ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਉਂ ਅਤੇ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ। "Save" ਧੁੰਦਲਾ ਅਤੇ ਗ੍ਰੇ ਹੋ ਕੇ ਬਿਨਾਂ ਵਜਹ ਦਿਖਾਇਆ ਫਰਜੀ ਲੱਗਦਾ ਹੈ। "Save (add a title to continue)" ਮਦਦਗਾਰ ਲੱਗਦਾ ਹੈ।
ਕੁਝ ਪੈਟਰਨ ਗੁੰਝਲ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਯੂਜ਼ਰ ਨੂੰ ਨੁਕਸਾਨ ਮਹਿਸੂਸ ਕਰਵਾਏ। ਜੇ ਮੁੜ-ਟੈਕਸਟ ਘਲਤੀਆਂ ਬਚ ਸਕਦੀਆਂ ਹਨ ਤਾਂ ਪਿਕਰ ਜਾਂ ਪ੍ਰੀਸੈਟ ਵਰਤੋ (ਤਾਰੀਖਾਂ, ਦੇਸ਼, ਭੂਮਿਕਾਵਾਂ)। ਸਭ ਤੋਂ ਆਮ ਕੇਸ ਲਈ ਸੰਵੇਧਨਸ਼ੀਲ ਡੀਫੌਲਟ ਦਿਓ ਅਤੇ ਫਿਰ ਅਡਵਾਂਸ ਯੂਜ਼ਰਾਂ ਨੂੰ ਬਦਲਨ ਦਿਓ। ਜਿਵੇਂ-ਜਿਵੇਂ ਯੂਜ਼ਰ ਟਾਈਪ ਕਰਦਾ ਹੈ ਵੈਧਤਾ ਦਿਖਾਓ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਸੁਨੇਹੇ ਦਿਓ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਕਾਰਵਾਈ ਨੂੰ ਨਿਸ਼ਕ੍ਰਿਆਤਮਕ ਕਰਦੇ ਹੋ ਤਾਂ ਵਜਹ ਸਿੱਧੇ ਨਾਲ ਲਗਾ ਦਿਓ ਕਿ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ।
ਇਕ ਨਿਰਦੇਸ਼ਕ ਉਦਾਹਰਨ: "Create workspace" ਫਲੋ ਵਿੱਚ ਜੇ ਡਾਟਾਬੇਸ ਰੀਜਨ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਟਾਈਪ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਪਿਕਰ ਦਿਓ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸੁਝਾਅਤ ਡੀਫੌਲਟ ਹੋਵੇ ਅਤੇ ਛੋਟਾ ਨੋਟ ਹੋਵੇ ਕਿ ਇਹ ਕਿਉਂ ਅਹਮ ਹੈ। ਜੇ ਨਾਮ ਲਾਜ਼ਮੀ ਹੈ, ਰੂਲ ਸ਼ੁਰੂ ਵਿੱਚ ਦਿਖਾਓ ("3 to 30 characters") ਬਜਾਏ ਕਿ ਅਖੀਰਲੇ ਕਦਮ 'ਤੇ ਇਸਨੂੰ ਦਿਖਾਉ।
ਪੁਸ਼ਟੀ ਡਾਇਲਾਗ ਡਰਾਉਣ ਵਾਲੇ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ; ਉਹ ਸਪਸ਼ਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। "Are you sure?" ਦੀ ਥਾਂ ਇਸ ਗੱਲ ਨੂੰ ਦਰਸਾਓ ਕਿ ਕੀ ਮਿਟਾਇਆ ਜਾ ਰਿਹਾ ਹੈ, ਕੀ ਖੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਇਸ ਦਾ ਉਲਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਸੇਫ਼ ਬਾਹਰੀ ਰਾਹ ਗਲਤੀ ਰੋਕਣ ਦਾ ਹਿੱਸਾ ਹੈ। "Cancel" ਅਤੇ "Back" ਨੂੰ ਪ੍ਰਗਟ ਤੌਰ 'ਤੇ ਪ੍ਰਗਟ ਕੀਤਾ ਜਾਵੇ; ਉਹ ਪ੍ਰਗਟ ਤੌਰ 'ਤੇ ਅਡੇ ਨਹੀਂ ਘਟਾਉਣ। ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਟੀਚਾ-ਕਾਰਵਾਈਆਂ (ਜਿਵੇਂ ਟੀਮਮੀ ਦੇ ਹਟਾਉਣਾ ਜਾਂ ਡ੍ਰਾਫਟ ਮਿਟਾਉਣਾ) ਲਈ Undo ਦਿਓ।
ਉੱਚ ਮੁੱਲ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਲਈ ਵਾਧੂ ਧੀਰਜ ਕਾਬਿਲ-ਕਦਰ ਹੈ: ਭੁਗਤਾਨ, ਪਲਾਨ ਅੱਪਗਰੇਡ, ਡੇਟਾ ਜਾਂ ਖਾਤਿਆਂ ਨੂੰ ਮਿਟਾਉਣਾ, ਅਨੁਮਤੀਆਂ ਦੇਣਾ, ਗਾਹਕਾਂ ਨੂੰ ਨਿਯੋਤਾ ਭੇਜਣਾ, ਜਾਂ ਅਟੂਟ ਨਿਰਯਾਤ ਅਤੇ ਰੀਸੈਟ। ਮਕਸਦ ਲੋਕਾਂ ਨੂੰ ਰੋਕਣਾ ਨਹੀਂ ਹੈ—ਮਗਰ ਇਹ ਹੈ ਕਿ ਹੋਣ ਵਾਲੇ ਨਤੀਜੇ ਕਲਿੱਕ ਤੋਂ ਪਹਿਲਾਂ ਸਪਸ਼ਟ ਹੋਣ।
ਜਦੋਂ ਤੁਸੀਂ ਚੈਟ-ਅਧਾਰਿਤ ਬਿਲਡਰ ਨਾਲ ਫੀਚਰ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਖ਼ਤਰਾ ਖਰਾਬ ਕੋਡ ਨਹੀਂ ਹੁੰਦਾ; ਖ਼ਤਰਾ ਇੱਕ ਐਸੀ ਯਾਤਰਾ ਹੈ ਜੋ ਨਿਰਮਾਤਾ ਲਈ ਤਰਕਸੰਗਤ ਲੱਗਦੀ ਹੈ ਪਰ ਪਹਿਲੀ ਵਾਰੀ ਯੂਜ਼ਰ ਲਈ ਨਹੀਂ। ਕਿਸੇ ਹੋਰ ਨੂੰ ਤਨਖਾਹ ਚਾਹੁੰਦਾ ਹੈ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਛੋਟੀ ਵੈਧਤਾ ਚਕ੍ਰ ਵਰਤੋ।
ਇੱਕ ਇਕ-ਜੁਮਲੇ ਯੂਜ਼ਰ ਸਟੋਰੀ ਲਿਖੋ। ਵਿਅਕਤੀ, ਉਦੇਸ਼, ਅਤੇ "ਮੁਕੰਮਲ" ਦਾ ਕੀ ਮਤਲਬ ਲਿਖੋ। ਉਦਾਹਰਨ: "A first-time customer wants to reset their password and end up signed in again." ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, ਫਲੋ ਸ਼ਾਇਦ ਬਹੁਤ ਵੱਡਾ ਹੈ।
ਕਦਮ ਲੇਖੋ, ਫਿਰ ਕੱਟੋ। ਸਕ੍ਰੀਨ ਜਾਂ ਕਾਰਵਾਈਆਂ ਦੀ ਦਰਸਾਉਟ ਬਣਾਓ। ਜੇ ਕੋਈ ਕਦਮ ਯੂਜ਼ਰ ਨੂੰ ਲਕੜੀ ਦੇ ਨੇੜੇ ਨਹੀਂ ਲੈ ਜਾਂਦਾ ਤਾਂ ਉਸਨੂੰ ਹਟਾਓ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਮੂਵ ਕਰੋ।
ਲੇਬਲਾਂ ਨੂੰ ਸਟੋਰੀ ਨਾਲ ਤੂਲੋ। ਹਰ ਸਕ੍ਰੀਨ ਤੇ ਮੁੱਖ ਬਟਨ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਲਕੜੀ ਨਾਲ ਮਿਲਦਾ ਹੈ। ਅਸਪਸ਼ਟ ਲੇਬਲਾਂ ਜਿਵੇਂ "Continue" ਨੂੰ "Send reset link" ਜਾਂ "Save address" ਵਰਗੇ ਨਤੀਜਾ-ਅਧਾਰਿਤ ਲੇਬਲ ਨਾਲ ਬਦਲੋ। ਸੁਰਖੀਸ਼ ਦੇ ਖਿਤਾਬ ਨੂੰ ਇਸ ਨਾਲ ਮੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
5-ਮਿੰਟ ਦਾ ਹਾਲਵੇ-ਟੈਸਟ ਚਲਾਓ। ਫਲੋ ਉਨ੍ਹਾਂ ਨੂੰ ਦਿਓ ਜਿਹੜੇ ਇਸਨੂੰ ਬਣਾਉਣ ਵਾਲੇ ਨਹੀਂ ਸੀ। ਸਿਰਫ਼ ਯੂਜ਼ਰ ਸਟੋਰੀ ਦਿਓ ਅਤੇ ਇੱਕ ਨਿਯਮ: ਕੋਈ ਇਸ਼ਾਰਾ ਨਹੀਂ।
ਰੁਕਾਵਟਾਂ ਦੀ ਦਰਜ ਕਰੋ, ਰਾਏ ਨਹੀਂ। ਹਰ ਰੁਕਾਵਟ, ਵਾਪਸੀ, ਗਲਤ ਕਲਿੱਕ ਅਤੇ "ਮੈਂ ਕਿੱਥੇ ਹਾਂ?" ਮੋਮੈਂਟ ਨੂੰ ਨੋਟ ਕਰੋ। ਹਰ ਇੱਕ ਇਕ ਸੰਪੂਰਨ ਸੋਧ ਬਣੇਗੀ: ਸ਼ਬਦ ਬਦਲੋ, ਫੀਲਡ ਮੂਵ ਕਰੋ, ਫੀਡਬੈਕ ਜੋੜੋ, ਜਾਂ ਚੋਣ ਹਟਾਓ।
ਦੋਬਾਰਾ ਟੈਸਟ ਕਰੋ ਜਦ ਤੱਕ ਇਹ ਸਪਸ਼ਟ ਨਾ ਲੱਗੇ। ਸਭ ਤੋਂ ਵੱਡੀਆਂ 2–3 ਸਮੱਸਿਆਵਾਂ ਠੀਕ ਕਰੋ, ਫਿਰ ਨਵੇਂ ਵਿਅਕਤੀ ਨਾਲ ਮੁੜ ਟੈਸਟ ਕਰੋ। ਰੁਕੋ ਜਦੋਂ ਲੋਕ ਟਾਸਕ ਸਹੀ-ਤਰ੍ਹਾਂ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹੋਣ ਅਤੇ ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਮਝਾ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਹੋਇਆ।
ਛੋਟੀ ਲੂਪ, ਤੇਜ਼ੀ ਨਾਲ, ਇੱਕ ਵਾਰੀ ਹੋਣ ਵਾਲੇ ਲੰਬੇ ਰਿਵਿਊਜ਼ ਨੂੰ ਹਰਾ ਦਿੰਦੇ ਹਨ।
ਤੇਜ਼ੀ ਚੰਗੀ ਗੱਲ ਹੈ, ਜਦ ਤੱਕ ਇਹ ਤੁਹਾਡੇ ਧਿਆਨ ਨੂੰ ਬਦਲ ਨਾ ਕਰ ਦੇਵੇ। ਚੈਟ ਟੂਲਾਂ ਖਾਲੀ ਥਾਵਾਂ ਨੂੰ ਸਮਝਦਾਰ ਤਰੀਕੇ ਨਾਲ ਭਰ ਸਕਦੀਆਂ ਹਨ। ਯੂਜ਼ਰ ਨਹੀਂ ਕਰਨਗੇ। ਉਹ ਆਪਣੀਆਂ ਸ਼ਬਦਾਂ, ਲਕੜੀਆਂ ਅਤੇ ਧੀਰਜ ਲੈ ਕੇ ਆਉਂਦੇ ਹਨ।
ਇੱਕ ਆਮ ਨਾਕਾਮੀ ਸ਼ਬਦਾਵਲੀ ਭਟਕ ਜਾਣਾ ਹੈ। ਨਿਰਮਾਤਾ ਅਤੇ ਚੈਟ ਪ੍ਰਾਂਪਟ ਅੰਦਰੂਨੀ ਸ਼ਬਦ ਵਰਗੇ "workspace", "entity", "billing profile", ਜਾਂ "sync" ਉੱਤੇ ਫਿਸਲ ਜਾਂਦੇ ਹਨ। ਨਵਾਂ ਯੂਜ਼ਰ ਸਿਰਫ਼ "add a teammate" ਜਾਂ "send an invoice" ਚਾਹੁੰਦਾ ਹੈ। ਜੇ ਲੇਬਲ ਯੂਜ਼ਰ ਦੇ ਮਾਨਸਿਕ ਮਾਡਲ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਤਾਂ ਲੋਕ ਧੀਰੇ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਦੂਜਾ ਫੰਸ ਇਹ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਡਾਟਾਬੇਸ ਨੂੰ ਸਿੱਧਾ ਦਿਖਾਉਣ ਲੱਗਦਾ ਹੈ। ਇਹ ਆਕਰਸ਼ਕ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਤਪਾਦਨ ਲਈ ਆਸਾਨ ਹੈ: first_name, status_id, plan_tier. ਪਰ ਲੋਕ ਸਹੀ-ਤਰ੍ਹਾਂ ਟੇਬਲ ਕਾਲਮਾਂ ਵਿੱਚ ਨਹੀਂ ਸੋਚਦੇ। ਉਹ ਸਵਾਲਾਂ ਅਤੇ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਸੋਚਦੇ ਹਨ: "ਇਹ ਕਿਸ ਲਈ ਹੈ?", "ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ?", "ਕੀ ਮੈਂ ਇਸਨੂੰ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹਾਂ?"
ਤੇਜ਼ ਬਿਲਡਿੰਗ ਵੀ ਫੀਚਰ-ਪਾਈਲਿੰਗ ਨੂੰ ਆਮ ਬਣਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਕਦਮ ਅਜੀਬ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਪ੍ਰੇਰਣਾ ਇਹ ਹੁੰਦੀ ਹੈ ਕਿ ਇੱਕ ਵਿਕਲਪ, ਇੱਕ ਟੈਬ ਜਾਂ ਇੱਕ ਅਡਵਾਂਸਡ ਸੈਕਸ਼ਨ जोड़ ਦਿਓ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮੂਲ ਸਮੱਸਿਆ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ: ਪਹਿਲਾ ਗੁੰਝਲ-ਪਲ ਮੁੱਖ ਤੌਰ 'ਤੇ ਅਜੇ ਵੀ ਗੁੰਝਲਦਾਰ ਹੁੰਦਾ ਹੈ।
ਹੈਲਪਰ ਟੈਕਸਟ ਨੂੰ ਇੱਕ ਝਪਰਸਿਆਂ ਦੇ ਤੌਰ 'ਤੇ ਵਰਤਣ ਵੇਲੇ ਸਾਵਧਾਨ ਰਹੋ। ਪਲੇਸਹੋਲਡਰ ਅਤੇ ਛੋਟੇ ਨੋਟ ਇੱਕ ਐਸੇ ਲੇਆਊਟ ਨੂੰ ਬਚਾ ਨਹੀਂ ਸਕਦੇ ਜੋ ਖੁਦ ਨੂੰ ਸਪਸ਼ਟ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਸਕ੍ਰੀਨ ਨੂੰ ਪੈਰਾ-ਪੈਰਾ ਵਿਆਖਿਆ ਦੀ ਲੋੜ ਹੈ, ਡਿਜ਼ਾਈਨ ਯੂਜ਼ਰ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਬਜਾਏ ਕਰਨਾ ਮੰਗ ਰਿਹਾ ਹੈ।
ਅੰਤ ਵਿੱਚ, "ਸਾਫ਼" ਮਹਿੰਗਾ ਬਣ ਸਕਦਾ ਹੈ। ਮੁੱਖ ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਮੇਨੂ ਦੇ ਅੰਦਰ ਛੁਪਾਉਣਾ ਸਫਾਈ ਦਿਖਾ ਸਕਦਾ ਹੈ, ਪਰ ਲੋਕਾਂ ਨੂੰ ਖੋਜਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ। ਜੇ ਸਕ੍ਰੀਨ 'ਤੇ ਇੱਕ ਕੁੰਜੀ ਕਾਰਵਾਈ ਹੈ ਤਾਂ ਉਸਨੂੰ ਕੁੰਜੀ ਕਾਰਵਾਈ ਵਾਂਗ ਨਜ਼ਰ ਆਉਂਣਾ ਚਾਹੀਦਾ ਹੈ।
ਅਤੇ ਆਖਿਰ ਵਿੱਚ, ਤੇਜ਼ੀ ਕੋਨੇ-ਕੇਸਾਂ ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ। ਇੱਕ ਫਲੋ ਜੋ ਪੂਰੇ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਉਹ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਖਾਲੀ ਸਥਿਤੀਆਂ, ਧੀਮੀ ਨੈੱਟਵਰਕ, ਗਲਤ ਇਨਪੁੱਟ ਜਾਂ ਯੂਜ਼ਰ ਦੇ ਮਿਡ-ਸਟੈਪ ਬੈਕਆਉਟ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।
ਇੱਕ ਗੁੰਝਲਦਾਰ ਫਲੋ ਅਸ silently ਸਹਾਇਤਾ ਟਿਕਟ, ਰਿਫੰਡ ਅਤੇ ਛੱਡੇ ਹੋਏ ਸਾਈਨਅਪ ਜੋੜਦਾ ਹੈ। ਤੁਸੀਂ ਜੇਕਰ ਤੇਜ਼ੀ ਨਾਲ ਕੋਈ ਸਕ੍ਰੀਨ ਜਾਂ ਫਲੋ ਤਿਆਰ ਕੀਤਾ ਹੈ ਤਾਂ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ 10-ਮਿੰਟ ਦੀ ਸੋਧ ਕਰੋ ਅਤੇ ਇੱਕੋ ਤਿੰਨ ਵਿਚਾਰਾਂ ਉੱਤੇ ਫੋਕਸ ਰੱਖੋ: ਸਪਸ਼ਟ ਸਾਈਨਿਫਾਇਰ, ਤੁਰੰਤ ਫੀਡਬੈਕ, ਅਤੇ ਨਰਮ ਪਾਬੰਧੀਆਂ।
ਮੁੱਖ ਰਸਤੇ (ਉਹ ਕੰਮ ਜੋ ਜ਼ਿਆਦਾਤਰ ਯੂਜ਼ਰ ਕਰਨ ਆਏ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਜਾਂਚੋ:
ਇਕ ਜाँच ਜੋ ਲੋਕ ਛੱਡਦੇ ਹਨ: ਸਫਲਤਾ ਅਤੇ ਅਸਫਲਤਾ ਦੋਹਾਂ ਤੋਂ ਬਾਅਦ ਅਗਲਾ ਕਦਮ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਫਲਤਾ ਦੀ ਸਥਿਤੀ ਅਗਲੀ ਲਾਭਦਾਇਕ ਕਾਰਵਾਈ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ (View receipt, Track order, Invite teammates)। ਅਸਫਲਤਾ ਦੀ ਸਥਿਤੀ ਯੂਜ਼ਰ ਨੂੰ ਨਿਯੰਤਰਣ ਵਿੱਚ ਰੱਖੇ (Fix this field, Retry, Contact support) ਬਿਨਾਂ ਇਨਪੁੱਟ ਮਿਟਾਏ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਸ ਚੈੱਕਲਿਸਟ ਨੂੰ UI ਕਾਪੀ ਅਤੇ ਸਥਿਤੀਆਂ ਦੀ ਆਖ਼ਰੀ ਜਾਂਚ ਵਾਂਗ ਵਰਤੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਡਿਪਲੌਇ ਕਰੋ। Planning Mode ਤੁਹਾਨੂੰ ਇੱਕ-ਜੁਮਲੇ ਲਕੜੀ ਅਤੇ ਉਮੀਦੀ ਕਦਮ ਪਹਿਲਾਂ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਜੋ ਜਨਰੇਟ ਕੀਤੀ UI ਅੰਤ ਵਿੱਚ ਖਤਮ ਨਜ਼ਰ ਨਾ ਆਵੇ ਪਰ ਮਜ਼ੇਦਾਰ-ਸਮਝਦਾਰ ਨਾ ਬਣੇ।
ਤੇਜ਼ੀ ਲਕਸ਼ ਨਹੀਂ ਹੈ। ਸਪਸ਼ਟਤਾ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ ਬਿਲਡ ਵੀ ਨਾਕਾਮ ਹੈ ਜੇ ਲੋਕ ਉਹ ਇੱਕ ਚੀਜ਼ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜੋ ਉਹ ਆਏ ਸਨ।
ਇੱਕ ਸਧਾਰਨ ਆਦਤ ਜੋ ਤੁਹਾਨੂੰ ਸੱਚਾ ਰੱਖਦੀ ਹੈ: ਹਰ ਰਿਲੀਜ਼ ਵਿੱਚ ਇੱਕ ਕੋਰ ਫਲੋ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਉਹ ਫਲੋ ਚੁਣੋ ਜੋ ਬਿੱਲ ਭੁਗਤਦਾ ਹੈ ਜਾਂ ਭਰੋਸਾ ਬਣਾਂਦਾ (ਸਾਈਨ-ਅਪ, ਬਣਾਉ, ਅਦਾ, ਨਿਯੋਤਾ). ਜਦੋਂ ਉਹ ਫਲੋ ਸਪਸ਼ਟ ਹੋਵੇ, ਹੋਰ ਸਭ ਕੁਝ ਵੀ ਆਸਾਨ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।
ਛੋਟੇ ਅਤੇ ਦਿੱਖਣਯੋਗ ਬਦਲਾਅ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਹੀ ਵਾਰੀ ਬਟਨ ਲੇਬਲ, ਐਰਰ ਸੁਨੇਹਾ, ਅਤੇ ਪੇਜ਼ ਲੇਆਊਟ ਬਦਲਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ ਕੀ ਮਦਦਗਾਰ ਸੀ।
ਅਸਲ ਯੂਜ਼ਰ ਟੈਸਟਿੰਗ ਨੂੰ ਲੈਬ ਦੀ ਲੋੜ ਨਹੀਂ। ਕਿਸੇ ਨੂੰ ਸਧਾਰਨ ਟਾਸਕ ਦਿਓ ਅਤੇ ਚੁੱਪ ਰਹੋ। ਜੇ ਉਹ ਹਿੱਲਦਾ ਹੈ, ਉਹ ਤੁਹਾਡੀ ਬੱਗ ਰਿਪੋਰਟ ਹੈ।
ਟੀਮਾਂ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੀਆਂ ਅਤੇ ਦੁਹਰਾਉਂਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਲਈ Koder.ai ਵਰਗੇ ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਡਿਪਲੌਇ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ UX ਦੇ ਮੂਲ ਨਿਯਮ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਯੂਜ਼ਰ ਕੰਮ ਪੂਰਾ ਕਰਨਗੇ ਜਾਂ ਨਹੀਂ। ਸਪਸ਼ਟਤਾ ਦੇ ਕੰਮ ਨੂੰ ਬਿਲਡ ਦਾ ਹਿੱਸਾ ਮੰਨੋ, ਇੱਕ ਸਾਫ-ਅਫ਼ਤ ਨਹੀ।
Confusing UI creates repeatable costs:
Clarity is about whether a first-time user can answer three questions at each step:
A UI can be visually “clean” and still fail if it doesn’t make outcomes predictable.
A mental model is the user’s expectation of how something should work based on other apps and everyday habits.
Default approach: match common expectations (e.g., “Save” keeps work safe; “Delete” warns or is reversible). If you need to break an expectation, do it with explicit labels and feedback so people aren’t forced to guess.
An affordance is what something can do. A signifier is what makes that action obvious.
Example: a button still “works” if it looks like plain text, but the signifier is weak, so people won’t notice it. Practical fix: improve signifiers with clear labels, contrast, placement, and state changes (pressed/loading/disabled).
Use them as a quick diagnosis:
To close both: make the next action easy to find, and make results unmistakable.
Use outcome-based labels.
Goal: a user should know the consequence before clicking.
Make ON/OFF meaning explicit and keep the system truthful:
Avoid toggles that look on while the feature is effectively off.
Default rule: if someone can ask “Did it work?” your UI should already be answering.
Practical patterns:
Prevent errors by making the safe path the easiest path:
For destructive actions, confirm with details (what will be deleted, what’s lost, whether it can be undone).
Run a short validation loop before shipping:
If you’re building in Koder.ai, use Planning Mode to define the intended steps and states up front, then do this pass before deploying.