ਐਡਮਿਨ ਟੂਲਸ ਲਈ ਕ੍ਰਮਿਕ ਪ੍ਰਗਟਾਵਾ — ਓਪਰੇਟਰ ਲਈ ਸੁਰੱਖਿਅਤ UI

ਐਡਮਿਨ ਟੂਲਾਂ ਕਿਉਂ ਗਲਤੀਆਂ ਅਤੇ ਸਪੋਰਟ ਲੋਡ ਪੈਦਾ ਕਰਦੇ ਹਨ

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

ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਵੀ ਬਿਨਾਂ ਯੋਜਨਾ ਦੇ ਵਧਦੇ ਹਨ। ਹਰ ਨਵੀਂ ਫੀਚਰ ਇੱਕ ਹੋਰ ਟੌਗਲ, ਬਟਨ ਜਾਂ ਡ੍ਰਾਪਡਾਊਨ ਜੋੜਦਾ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ ਤੁਸੀਂ ਕੰਟਰੋਲਾਂ ਦੀ ਇੱਕ ਭੀੜ ਪਾ ਲੈਂਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਕੋਈ ਸਪੱਸ਼ਟ ਹਾਇਰਾਰਕੀ ਨਹੀਂ ਹੁੰਦੀ। ਓਪਰੇਟਰ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਦੇ ਹਨ, ਤੇਜ਼ੀ ਨਾਲ ਕਲਿੱਕ ਕਰਦੇ ਹਨ, ਅਤੇ ਮਾਸਲ-ਮੇਮਰੀ 'ਤੇ ਨਰਭਰ ਹੋ ਜਾਂਦੇ ਹਨ। ਫਿਰ ਗਲਤ ਕਲਿੱਕ ਹੋਂਦੇ ਹਨ।

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

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

ਇਹ ਗਲਤੀਆਂ ਕਦੇ ਵੀ ਲਾਪਰਵਾਹ ਲੋਕਾਂ ਕਰਕੇ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਉਹ ਸਕ੍ਰੀਨਾਂ ਹਨ ਜੋ ਆਮ, ਘੱਟ-ਖੱਤਰੇ ਵਾਲੇ ਟਾਸਕਾਂ ਨੂੰ ਦੁਰੁਸਤ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਆਮ ਨਜ਼ਾਰਿਆਂ ਤੋਂ ਵੱਖ ਨਹੀਂ ਰੱਖਦੀਆਂ। ਜਦ ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਹਮੇਸ਼ਾਂ ਵਿਖਾਈ ਦਿੰਦੀਆਂ, ਹਮੇਸ਼ਾਂ ਸ ([enabled]) ਹੁੰਦੀਆਂ, ਅਤੇ ਇੱਕ ਕਲਿੱਕ ਦੂਰ ਹੁੰਦੀਆਂ, UI ਯੂਜ਼ਰਾਂ ਨੂੰ ਟੂਲ ਤੋਂ ਡਰਣਾ ਜਾਂ ਉਨ੍ਹਾਂ ਤੋਂ ਬਚਣਾ ਸਿੱਖਾ ਦਿੰਦੀ ਹੈ ਜਦ ਤੱਕ ਕੁਝ ਤਤਕਾਲੀ ਨਾ ਹੋ ਜਾਵੇ।

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

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ chat-to-app ਪਲੇਟਫਾਰਮ ਨਾਲ ਐਡਮਿਨ ਟੂਲ ਬਣਾ ਰਹੇ ਹੋ, ਫਿਰ ਵੀ ਜਨਰੇਟ ਕੀਤੀਆਂ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਇਸ ਲੈਂਸ ਨਾਲ ਵੇਖਣਾ ਲਾਭਦਾਇਕ ਹੈ। ਗਤੀ ਮਦਦ ਕਰਦੀ ਹੈ, ਪਰ ਓਪਰੇਟਰ ਸੁਰੱਖਿਆ ਸਪਸ਼ਟ ਸੰਰਚਨਾ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕੇ ਪੇਜ 'ਤੇ ਹੋਰ ਕੰਟਰੋਲ ਭਰਦਿਆਂ।

ਐਡਮਿਨ UI ਵਿੱਚ ਕ੍ਰਮਿਕ ਪ੍ਰਗਟਾਵੇ ਦਾ ਕੀ ਅਰਥ ਹੈ

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

ਡਿਫੌਲਟ ਨਜ਼ਾਰਾ ਦਿਨ-ਦਰ-ਦਿਨ ਦੇ ਕੰਮ ਨਾਲ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ: ਤੇज़ ਲੁਕਅੱਪ, ਰੁਟੀਨ ਅਪਡੇਟ, ਅਤੇ ਸਪੱਸ਼ਟ ਸਥਿਤੀ। Advanced ਸੈਟਿੰਗਾਂ ਮੌਜੂਦ ਹਨ, ਪਰ ਉਹ ਇਕ ਇਰਾਦਾਪੂਰਕ ਕਦਮ ਤੋਂ ਬਾਅਦ ਹੀ ਦਰਸਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ — ਜਿਵੇਂ ‘‘Advanced’’ ਪੈਨਲ ਖੋਲ੍ਹਣਾ, ‘‘Edit’’ ਮੋਡ ਵਿੱਚ ਜਾਣਾ, ਜਾਂ ਇਕ ਅਲੱਗ ਫਲੋ ਜਿਸ ਨੂੰ ਪੁਸ਼ਟੀ ਦੀ ਲੋੜ ਹੋਵੇ।

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

ਕੁਝ ਰੱਖ-ਸਥਿਤੀ ਨਿਯਮ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੇ ਸਾਬਤ ਹੁੰਦੇ ਹਨ:

• ਡਿਫੌਲਟ ਨਜ਼ਾਰਾ ਰੀਡ-ਓਨਲੀ ਵੇਰਵੇ, ਸਪਸ਼ਟ ਸੁਰੱਖਿਅਤ ਟੌਗਲ ਅਤੇ ਇੱਕ ਸਭ ਤੋਂ ਆਮ ਕਾਰਵਾਈ 'ਤੇ ਫੋਕਸ ਰੱਖੇ।
• ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ, ਬਲਕ ਆਪਰੇਸ਼ਨ ਅਤੇ ਮੁਸ਼ਕਿਲ-ਨੁਕਸਾਨ ਵਾਲੇ ਬਦਲਾਅ disclosure ਦੇ ਪਿੱਛੇ ਰੱਖੋ।
• ਵਿਕਲਪ ਉਸ ਸਮੇਂ ਖੋਲ੍ਹੋ ਜਦੋਂ ਇਰਾਦਾ ਸਪਸ਼ਟ ਹੋਵੇ (ਉਦਾਹਰਣ ਲਈ, ਖਾਸ ਆਈਟਮ ਚੁਣਨ ਤੋਂ ਬਾਅਦ, ਪਹਿਲਾਂ ਨਹੀਂ)।
• ਵਿਕਲਪ ਉਸ ਸਮੇਂ ਖੋਲ੍ਹੋ ਜਦੋਂ ਸੰਦਰਭ ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਹੋਵੇ (ਉਦਾਹਰਣ ਲਈ, "Disable account" ਸਿਰਫ ਉਹ ਯੂਜ਼ਰ ਦੇ ਪੇਜ 'ਤੇ ਦਿਖਾਓ, ਜਿੱਥੇ ਨਾਮ ਅਤੇ ਭੂਮਿਕਾ ਵੇਖਣਯੋਗ ਹੋਵਾਂ)।
• ਵਿਕਲਪ ਉਸ ਸਮੇਂ ਖੋਲ੍ਹੋ ਜਦੋਂ ਵਿਸ਼ਵਾਸ ਵੱਧ ਹੋਵੇ (ਉਦਾਹਰਣ ਲਈ, ਜਦੋਂ ਓਪਰੇਟਰ ਕੋਲ ਸਹੀ ਅਨੁਮਤੀ ਹੋ)।

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

ਉਦਾਹਰਣ: ਇੱਕ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ ਸਕ੍ਰੀਨ 'ਤੇ, ਡਿਫੌਲਟ ਨਜ਼ਾਰਾ ਨਾਮ, ਈਮੇਲ, ਭੂਮਿਕਾ ਅਤੇ ਇੱਕ ਸਧਾਰਨ "Reset password" ਕਾਰਵਾਈ ਦਿਖਾ ਸਕਦਾ ਹੈ। ਇਕ ਵੱਖਰਾ "Advanced" ਖੰਡ "Revoke all sessions" ਜਾਂ "Delete user" ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਵਾਧੂ ਰੁਕਾਵਟ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਇੰਟਰਨਲ ਐਡਮਿਨ ਟੂਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਹੀ ਵਿਚਾਰ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਬੇਸਿਕ ਸਕ੍ਰੀਨ ਨਾਲ ਲਾਕਦੇ ਹੋ, ਫਿਰ ਜਦੋਂ ਵਰਕਫ਼ਲੋ ਸਪਸ਼ਟ ਹੋ ਜਾਣ, Advanced ਪੈਨਲ ਅਤੇ ਪੁਸ਼ਟੀਕਰਨ ਜੋੜਦੇ ਹੋ।

ਭੂਮਿਕਾਵਾਂ, ਟਾਸਕ ਅਤੇ ਖਤਰਾ ਪੱਧਰਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਟਾਸਕ ਨਾਲ ਜੋੜੋ

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

ਇੱਕ ਆਮ ਵੰਡ ਇਹ ਹੈ:

• Viewer: ਸਥਿਤੀ ਦੇਖਣਾ, ਲਾਗਜ਼ ਪੜ੍ਹਨਾ, ਰਿਪੋਰਟ ਐਕਸਪੋਰਟ ਕਰਨਾ
• Agent: ਟਿਕਟਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ, ਪਾਸਵਰਡ ਰੀਸੈੱਟ, ਨਿਯਤਾਂ ਮੁੜ-ਭੇਜੇ ਜਾਣਾ
• Manager: ਟੀਮਾਂ ਦਾ ਪ੍ਰਬੰਧ, ਬਦਲਾਅ ਮਨਜ਼ੂਰ ਕਰਨਾ, ਸੀਮਾਵਾਂ ਢਾਲਣਾ
• Admin: ਸੁਰੱਖਿਆ ਕਾਨਫਿਗਰ ਕਰਨਾ, ਇੰਟੇਗ੍ਰੇਸ਼ਨ, ਬਿਲਿੰਗ, ਡੇਟਾ ਰੀਟੇਨਸ਼ਨ

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

ਉਦਾਹਰਣ ਲਈ, ਇੱਕ ਏਜੰਟ ਨੂੰ ਰੋਜ਼ਾਨਾ "Reset user password" ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਉਸਨੂੰ "Disable SSO for the whole workspace" ਇੱਕੋ ਹੀ ਪੰਨੇ 'ਤੇ ਨਹੀਂ ਚਾਹੀਦਾ। ਦੋਹਾਂ ਨੂੰ পাশ-ਪਾਸ ਰੱਖਣ ਨਾਲ ਗਲਤੀ ਦਾ ਖਤਰਾ ਵੱਧਦਾ ਹੈ, ਭਾਵੇਂ UI ਵਿੱਚ ਚੇਤਾਵਨੀ ਹੋਵੇ।

ਕਾਰਵਾਈਆਂ ਨੂੰ ਖਤਰੇ ਅਨੁਸਾਰ ਦਰਜਾ ਦਿਓ

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

• Read: ਸੈਟਿੰਗਾਂ ਵੇਖਣਾ, ਬਦਲਾਅ ਦੇ ਪ੍ਰੀਵਿਊ, ਆਡਿਟ ਐਂਟਰੀਜ਼ ਚੈੱਕ ਕਰਨਾ
• Change: ਫੀਲਡ ਸੋਧਣਾ, ਫੀਚਰ ਟੌਗਲ ਕਰਨਾ, ਭੂਮਿਕਾਵਾਂ ਅਪਡੇਟ ਕਰਨਾ
• Delete: ਯੂਜ਼ਰ ਹਟਾਉਣਾ, ਕੀਜ਼ ਰੀਵੋਕ ਕਰਨਾ, ਡੇਟਾ ਮਿਟਾਉਣਾ
• Irreversible: ਇਨਕ੍ਰਿਪਸ਼ਨ ਕੀਜ਼ ਰੋਟੇਟ ਕਰਨਾ, ਡੇਟਾ ਪੁਰਜ ਕਰਨਾ, ਖਾਤੇ ਬੰਦ ਕਰਨਾ

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

ਸਪੋਰਟ ਕੇਸ ਸੱਚਾਈ ਦੀ ਇੱਕ ਛੋਟੀਂ ਕਹਾਣੀ ਦੱਸਦੇ ਹਨ। ਹਾਲ ਹੀ ਦੇ ਟਿਕਟਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਜੋ "I clicked" ਜਾਂ "We didn't mean to" ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ। ਉਹ ਕਹਾਣੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਅਸਲ ਖਤਰਾ ਵਾਲੇ ਖੇਤਰ ਦਿਖਦੀਆਂ ਹਨ: ਭੁਲੇ-ਭਟਕੇ ਟੌਗਲ, ਬਲਕ ਕਾਰਵਾਈਆਂ ਜੋ ਨਿਰਪੱਖ ਦਿਖਦੀਆਂ ਹਨ, ਜਾਂ ਸੈਟਿੰਗਾਂ ਜੋ ਹਰ ਕਿਸੇ 'ਤੇ ਅਸਰ ਪਾਉਂਦੀਆਂ ਹਨ ਜਦ ਓਪਰੇਟਰ ਸੋਚਦਾ ਹੈ ਉਹ ਕਿਵੇਂ ਇਕ ਯੂਜ਼ਰ ਨੂੰ ਬਦਲ ਰਿਹਾ ਹੋਵੇ।

ਐਡਮਿਨ ਟੂਲਾਂ ਵਿੱਚ ਕਾਰਜਕਾਰੀ UI ਪੈਟਰਨ ਜੋ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ

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

ਭੀੜ ਅਤੇ ਗਲਤੀਆਂ ਘਟਾਉਣ ਵਾਲੇ ਪੈਟਰਨ

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

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

ਰੁਕ-ਰੁਕ ਕੇ ਛੁਟੇ-ਮੋਟੇ ਤਕਨੀਕੀ ਵੇਰਵੇ ਦਿਖਾਓ ਜਦੋਂ ਲੋੜ ਹੋਵੇ। IDs, ਰਾਅ payloads, ਅਤੇ ਲੰਮੇ ਲਾਗਜ਼ਾਂ ਲਈ "Show details" ਟੌਗਲ ਰੱਖੋ ਤਾਂ ਮੁੱਖ UI ਪਾਠਯੋਗ ਰਹੇ ਪਰ ਡਿਬੱਗਿੰਗ ਲਈ ਜਾਣਕਾਰੀ ਮਿਲੇ।

ਇਕ ਛੋਟਾ ਸਟਾਰਟਰ ਸੈੱਟ:

• ਕ੍ਰਮਿਕ ਫੀਲਡ ਜੋ ਸਿਰਫ਼ ਸਪਸ਼ਟ ਚੋਣ ਤੋਂ ਬਾਅਦ ਦਿਖਦੇ ਹਨ
• ਸਧਾਰਨ-ਭਾਸ਼ਾ ਲੇਬਲਾਂ ਵਾਲੇ ਕੋਲੈਪਸਿਬਲ "Advanced" ਪੈਨਲ
• ਵਾਰੀ-ਵਾਰੀ ਜਾਂ ਉੱਚ-ਖਤਰੇ ਸੈਟਿੰਗਾਂ ਲਈ ਵੱਖਰੇ ਸਕ੍ਰੀਨ ਜਾਂ ਫਲੋ
• IDs, ਲਾਗਜ਼ ਅਤੇ ਟਾਈਮਸਟੈਂਪਾਂ ਲਈ ਇਨਲਾਈਨ "Show details" ਟੌਗਲ
• ਸਭ ਤੋਂ ਘੱਟ-ਖ਼ਤਰਾ ਵਾਲੇ ਵਿਕਲਪਾਂ ਦੇ ਨਾਲ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ

ਇੱਜ਼ਤਦਾਰ ਪਰ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ

ਡਿਫੌਲਟਾਂ ਨੂੰ ਸਿਸਟਮ ਦੀ ਰੱਖਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਬਿਨਾਂ ਓਪਰੇਟਰ ਨੂੰ ਸਜ਼ਾ ਦਿੱਤੇ। ਜੇ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਹੀ ਸਭ ਤੋਂ ਆਮ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਪੂਰਵ-ਚੁਣਿਆ ਰੱਖੋ ਅਤੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾਓ। ਉਦਾਹਰਣ ਵਜੋਂ, permission ਬਦਲ ਨੂੰ "View only" 'ਤੇ ਡਿਫੌਲਟ ਕਰੋ ਅਤੇ "Manage" ਦੇਣ ਲਈ ਦੂਜਾ ਕਦਮ ਲੋੜੀਂਦਾ ਬਣਾਓ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਐਡਮਿਨ ਟੂਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਪੈਟਰਨ ਆਮ UI ਟੁਕੜਿਆਂ ਨਾਲ ਸਹੀ ਤਰ੍ਹਾਂ ਮਿਲਦੇ ਹਨ (ਫਾਰਮ, ਕੋਲੈਪਸਿਬਲ ਪੈਨਲ, ਮੋਡਲ)। ਚਾਬੀ ਇਹੀ ਹੈ: ਪਹਿਲਾਂ ਸ਼ਾਂਤ ਡਿਫੌਲਟ ਨਜ਼ਾਰਾ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਫਿਰ ਜਦੋ ਇਰਾਦਾ ਮਿਲੇ ਤਾਂ ਪਾਵਰ ਜੋੜੋ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਇਕ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਨੂੰ ਪ੍ਰਗਟਾਵੇ ਨਾਲ ਰੀਫੈਕਟਰ ਕਰੋ

ਉਹ ਇੱਕ ਸਕ੍ਰੀਨ ਚੁਣੋ ਜੋ ਆਮ ਤੌਰ 'ਤੇ "ਉਪਸ" момменਟਸ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਉਹ ਚੀਜ਼ ਚੁਣੋ ਜਿਸ ਨੂੰ ਓਪਰੇਟਰ ਬਹੁਤ ਵਾਰ ਦਿਖਾਈ ਜਾਂਦੇ ਹਨ ਅਤੇ ਜਿੱਥੇ ਗਲਤ ਕਲਿੱਕ ਟਿਕਟਾਂ, ਰੀਫੰਡ ਜਾਂ ਡਾਊਨਟਾਈਮ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਸਭ ਤੋਂ ਸਖਤ ਸਕ੍ਰੀਨ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਕਰੋ—ਉਸ ਥਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜਿੱਥੇ ਛੋਟੇ ਬਦਲਾਅ ਨਾਲ ਸਪੋਰਟ ਲੋਡ ਤੇਜ਼ੀ ਨਾਲ ਘਟ ਸਕਦਾ ਹੈ।

ਸਕ੍ਰੀਨ 'ਤੇ ਹਰ ਇਕ ਕੰਟਰੋਲ ਦਾ ਇਨਵੈਂਟਰੀ ਬਣਾਓ ਅਤੇ ਉਸਨੂੰ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਲੇਬਲ ਕਰੋ: ਇਸ ਦੀ ਵਰਤੋਂ ਕਿੰਨੀ ਵਾਰ ਹੁੰਦੀ ਹੈ (ਆਮ ਵਰਤੀ ਜਾਂ ਕਦੇ-ਕਦੇ) ਅਤੇ ਜੇ ਗਲਤ ਵਰਤੀ ਹੋਏ ਤਾਂ ਕੀ ਨਤੀਜਾ ਹੈ (ਗੁਣਾਤਮਕ vs ਉੱਚ-ਖਤਰਾ)। ਉਹ ਮੈਪ ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਕੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕੀ ਇਕ ਇਰਾਦਾਪੂਰਕ ਕਾਰਵਾਈ ਦੇ ਪਿੱਛੇ ਛੁਪਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਕੁਝ ਵਿਹਾਰਕ ਡਿਸਕਲੋਜ਼ਰ ਚਲਾਂ:

• ਕਦੇ-ਕਦੇ ਦੇ ਵਿਕਲਪਾਂ ਨੂੰ "Advanced" expander ਦੀ ਪਿੱਛੇ ਰੱਖੋ ਅਤੇ ਸਪਸ਼ਟ ਲੇਬਲ ਦਿਓ।
• ਉੱਚ-ਖਤਰੇ ਕਾਰਵਾਈਆਂ ਨੂੰ ਵੱਖਰੇ ਫਲੋ (ਇਕ ਸਮਰਪਿਤ ਪੰਨਾ ਜਾਂ ਮੋਡਲ) ਵਿੱਚ ਭੇਜੋ ਜਿਸ ਨੂੰ ਮਜ਼ਬੂਤ ਸੰਦਰਭ ਮਿਲੇ।
• ਪੁਸ਼ਟੀਕਰਨ ਮੰਗੋ ਜੋ ਪੜ੍ਹਨ-ਲਾਈਕ ਬਣਾਂਦੇ ਹਨ (type-to-confirm, ਇੱਕ ਕਾਰਨ ਚੁਣੋ, ਜਾਂ ਪ੍ਰੀਵਿਊ ਦਿਖਾਓ)।
• ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸਿਰਫ UI ਛੁਪਾਉਣ ਨਾਲ ਨਹੀਂ, ਬਲਕਿ ਅਨੁਮਤੀਆਂ ਦੇ ਪਿੱਛੇ ਵੀ ਰੱਖੋ।
• ਜੇ ਨਤੀਜਾ ਮੁਸ਼ਕਿਲ ਹੈ, ਤਾਂ "dry run" ਜਾਂ ਪ੍ਰੀਵਿਊ ਦਿਖਾਓ।

ਆਖ਼ਰ ਵਿੱਚ ਦੋ-ਤਿੰਨ ਹਕੀਕਤੀ ਟਾਸਕਾਂ ਨਾਲ ਟੈਸਟ ਕਰੋ ਜੋ ਓਪਰੇਟਰ ਅਸਲ ਵਿੱਚ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਣ: "ਇੱਕ ਗਾਹਕ ਦੀ ਯੋਜਨਾ ਬਦਲੋ, ਆਖਰੀ ਚਲਾਨ ਨੂੰ ਰੀਫੰਡ ਕਰੋ, ਅਤੇ ਐਕਸੇਸ ਜਾਰੀ ਰੱਖੋ।" ਹੇਠਾਂ ਹਨੇਰੇ, ਗਲਤ ਕਲਿੱਕ ਅਤੇ ਬੈਕਟ੍ਰੈਕ ਵੇਖੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਇਤਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਸਮਾਂ snapshots ਅਤੇ rollback ਵਰਤਣ ਲਈ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਨਵੀਂ ਸਕੀਨ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕੋ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਝਟ ਤੋਂ ਵਾਪਸ ਆ ਸਕੋ।

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

ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਨੂੰ ਗਲਤੀ ਨਾਲ ਟ੍ਰਿਗਰ ਹੋਣਾ ਮੁਸ਼ਕਿਲ ਬਣਾਓ

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

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

ਲੇਬਲਜ਼ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀਆਂ ਹਨ। ਅਸਪਸ਼ਟ ਬਟਨਾਂ ਜਿਵੇਂ "Confirm" ਜਾਂ "Yes" ਤੋਂ ਬਚੋ। ਬਟਨ ਨੂੰ ਇਹ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਨਤੀਜਾ ਕੀ ਹੋਵੇਗਾ, ਉਦਾਹਰਣ ਵਜੋਂ "Delete user" ਜਾਂ "Reset API key"। ਸਪਸ਼ਟ ਕਿਰਿਆ-ਵਚਨ ਓਪਰੇਟਰ ਨੂੰ ਖੁਦ-ਚੈੱਕ ਕਰਨ ਦਿੰਦੇ ਹਨ।

ਸੱਚਮੁੱਚ ਅਪਰਿਵਰਤਨੀ ਬਦਲਾਵਾਂ ਲਈ, ਸਪਸ਼ਟ ਇਰਾਦਾ ਲੋੜੀਂਦਾ ਕਰੋ। ਇਕ ਮੋਡਲ ਅਤੇ ਚੈੱਕਬਾਕਸ ਅਕਸਰ ਕਾਫੀ ਨਹੀਂ ਹੁੰਦੇ। Typed confirmation ਨਾਲ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵਾਕ ਦੀ ਲੋੜ ਕਰੋ ਅਤੇ ਲਕੜੀ ਨਾਂ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਕਿ "ਗਲਤ ਟੈਬ" ਦੀ ਖ਼ਤਰਨਾਕੀ ਘੱਟ ਹੋ ਜਾਵੇ। ਉਦਾਹਰਣ: Acme Team ਨੂੰ ਹਟਾਉਣ ਲਈ DELETE ਲਿਖੋ।

ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕੀ ਬਦਲਣ ਵਾਲਾ ਹੈ ਦਾ ਇੱਕ ਛੋਟਾ-सा ਪ੍ਰੀਫਲਾਈਟ ਸੰਖੇਪ ਦਿਖਾਓ। ਇਸਨੂੰ ਸਕੈਨ ਕਰਨਯੋਗ ਰੱਖੋ:

• ਕੀ ਹਟਾਇਆ ਜਾਂ ਅਪਘਟ ਕੀਤਾ ਜਾਵੇਗਾ
• ਕੀ ਡੇਟਾ ਰੱਖਿਆ ਜਾਵੇਗਾ (ਜੇ ਕੋਈ)
• ਕਿਹੜੇ ਯੂਜ਼ਰ ਜਾਂ ਸਿਸਟਮ ਪ੍ਰਭਾਵਿਤ ਹੋਣਗੇ
• ਕੀ ਕਾਰਵਾਈ ਵਾਪਸ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ
• ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ (ਉਦਾਹਰਣ ਲਈ, ਸੈਸ਼ਨਾਂ ਰੀਵੋਕ ਹੋਣਾ)

ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਦਿਓ। ਬਹੁਤ ਸਾਰੇ "delete" ਬਸ "ਮੈਨੂੰ ਇਹ ਹਟਾਉਣਾ ਹੈ" ਦੇ ਇੱਛਾ ਹੋ ਸਕਦੇ ਹਨ। ਵਿਕਲਪ ਦੇਵੋ ਜਿਵੇਂ disable, archive ਜਾਂ suspend, ਅਤੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਅੰਤਰ ਸਮਝਾਓ। ਇੱਕ ਯੂਜ਼ਰ ਨੂੰ suspend ਕਰਨਾ ਲੌਗਿਨ ਨੂੰ ਰੋਕਦਾ ਹੈ ਪਰ ਹਿਸਟਰੀ ਅਤੇ ਬਿਲਿੰਗ ਰਿਕਾਰਡ ਰੱਖਦਾ ਹੈ। delete ਖਾਤਾ ਹਟਾਉਂਦਾ ਹੈ ਅਤੇ ਸੰਬੰਧਤ ਡੇਟਾ ਨੂੰ ਮਿਟਾ ਵੀ ਸਕਦਾ ਹੈ।

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

ਫੀਡਬੈਕ, ਆਡਿਟ ਅਤੇ ਰਿਕਵਰੀ ਜੋ ਯੂਜ਼ਰ ਸਮਝ ਸਕਦੇ ਹਨ

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

ਚੰਗਾ ਫੀਡਬੈਕ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਂਦਾ ਹੈ: ਕੀ ਬਦਲਿਆ, ਕਿੱਥੇ ਬਦਲਿਆ, ਅਤੇ ਕਿਸ ਨੇ ਬਦਲਿਆ। "Password policy updated for Workspace A by Maya (you) just now" ਵਰਗਾ ਪੁਸ਼ਟੀਕਰਨ ਇੱਕ ਜਨਰਿਕ "Saved" ਨਾਲੋਂ ਵਧੀਆ ਹੈ। ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਮੁਖ ਭਿੰਨ-ਭਿੰਨ ਫੀਲਡ ਜੋ ਬਦਲੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਓਦੋ ਹੀ ਦਿਖਾਓ।

ਆਡਿਟ ਟਰੇਲ ਇੱਕ ਸੁਰੱਖਿਆ ਜਾਲ ਹੈ ਜਦੋਂ ਕਿਸੇ ਨੇ ਪੁੱਛਿਆ, "ਇਹ ਕਿਸਨੇ ਕੀਤਾ?" ਇਸਨੂੰ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ। ਹਰ ਐਂਟਰੀ ਵਿੱਚ ਟਾਈਮਸਟੈਂਪ, ਐਕਟਰ, ਅਤੇ ਪਹਿਲਾਂ/ਬਾਅਦ ਦਾ ਵੇਰਵਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਬਦਲਾਅ ਜਟਿਲ ਹੈ (ਜਿਵੇਂ permissions), ਤਾਂ ਪਹਿਲਾਂ ਮਨੁੱਖੀ ਸਾਰ ਦਿਖਾਓ ("Added Billing Admin role to Jordan"), ਫਿਰ ਉਪਲੱਬਧ ਹੋਵੇ ਤਾਂ ਵਿਸਥਾਰ ਲਈ ਖੋਲ੍ਹਣ ਦਿਓ।

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

ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਪ੍ਰਭਾਵ ਸਮਝਾਓ, ਨਾ ਕਿ ਐਰਰ ਕੋਡਾਂ ਵਿੱਚ। "409 conflict" ਦੀ ਜਗ੍ਹਾ ਦੱਸੋ: "ਇਸ ਨਾਲ ਇਸ ਵਰਕਸਪੇਸ ਦੇ ਸਾਰੇ ਯੂਜ਼ਰ ਸਾਈਨ ਆਉਟ ਹੋ ਜਾਣਗੇ ਅਤੇ ਨਵਾਂ ਲੌਗਇਨ ਲੋੜੇਗਾ." ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਪ੍ਰਭਾਵ ਪਹਿਲਾਂ ਰੱਖੋ।

ਕੁਝ ਛੋਟੇ ਪੈਟਰਨ ਜੋ ਦੁਹਰਾਈ ਜਾਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਰੋਕਦੇ ਹਨ ਬਿਨਾਂ ਭੀੜ ਵਧਾਏ:

• ਸਿਰਫ਼ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਸੀਮਿਤ ਰੂਪ ਵਿੱਚ ਮਦਦਗਾਰ ਟੈਕਸਟ ਦਿਖਾਓ, ਕੰਟਰੋਲ ਦੇ ਕੋਲ।
• ਸੇਵ ਕਰਨ ਤੋਂ ਬਾਅਦ ਬਦਲੇ ਫੀਲਡ ਨੂੰ ਸੰਖੇਪ ਵਾਰ ਹਾਈਲਾਈਟ ਕਰੋ।
• ਖਤਰਨਾਕ ਬਦਲਾਵਾਂ ਲਈ "What happens next" ਦੀ ਇੱਕ ਛੋਟੀ ਲਾਈਨ ਦਿਖਾਓ।
• ਆਡਿਟ ਵਿਊ ਵਿੱਚ, ਓਪਰੇਟਰਾਂ ਨੂੰ support ਟਿਕਟਾਂ ਲਈ ਸਾਦਾ ਬਦਲਾਅ ਸਾਰ ਕਾਪੀ ਕਰਨ ਦਿਓ।

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

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਣ: ਯੂਜ਼ਰ ਐਕਸੈਸ ਅਤੇ permissions ਸਕ੍ਰੀਨ

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

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

ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਫੌਲਟ ਕਾਰਵਾਈਆਂ ਦਾ ਸੈੱਟ ਅਕਸਰ ਇਹ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ: resend invite, send password reset, unlock account, reset MFA, ਅਤੇ view login history।

Permissions ਰਾਹ ਵਿੱਚ ਰੁਕਾਵਟ ਬਣਾਉਂਦੇ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਕੋਲੈਪਸਡ ਪੈਨਲ ਵਿੱਚ ਰੱਖੋ ਜਿਸ 'ਤੇ ਸਧਾਰਨ ਲੇਬਲ ਹੋਵੇ: "Permissions and roles (advanced)"। ਪਾਵਰਫੁਲ ਕੰਟਰੋਲ ਮੌਜੂਦ ਹਨ, ਪਰ ਉਹ ਸੁਰੱਖਿਅਤ ਅਤੇ ਆਮ ਕਾਰਵਾਈਆਂ ਨਾਲ ਮੁਕਾਬਲਾ ਨਹੀਂ ਕਰਨਗੇ।

ਜਦੋਂ ਓਪਰੇਟਰ ਪੈਨਲ ਖੋਲ੍ਹਦਾ ਹੈ, ਸਕ੍ਰੀਨ "fix access" ਤੋਂ "change authority" ਵੱਲ ਝੁਕਦੀ ਹੈ। ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਭੂਮਿਕਾ ਅਤੇ ਮੁੱਖ permissions ਨੂੰ ਰੀਡ-ਓਨਲੀ ਰੂਪ ਵਿੱਚ ਦਿਖਾਓ। ਫਿਰ ਕਿਸੇ ਵੀ ਕੰਟਰੋਲ ਨੂੰ ਇੰਟਰਐਕਟਿਵ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ Explicitly "Edit permissions" 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਦੀ ਲੋੜ ਕਰੋ।

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

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

ਕਾਰਵਾਈ ਤੋਂ ਬਾਅਦ, ਕੇਵਲ "Saved" ਨਾ ਦਿਖਾਓ। ਇੱਕ after-action ਰਸੀਦ ਦਿਖਾਓ: ਕੀ ਬਦਲਿਆ, ਕਿਸ ਨੇ ਬਦਲਿਆ, ਕਦੋਂ ਅਤੇ ਕਿਉਂ। ਜੇ ਨੀਤੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਤਾਂ "Revert this change" ਵਿਕਲਪ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਪਹਿਲੀ ਭੂਮਿਕਾ ਨੂੰ ਠੀਕ ਤੌਰ 'ਤੇ ਵਾਪਸ ਕਰ ਸਕੇ।

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

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਟ੍ਰੈਪ ਜਿਨ੍ਹਾਂ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ

ਕ੍ਰਮਿਕ ਪ੍ਰਗਟਾਵਾ ਤਦ ਤੱਕ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਜਦ ਤੱਕ ਲੋਕ ਉਹ ਚੀਜ਼ਾਂ ਲੱਭ ਨਾ ਸਕਣ, ਜੋ ਉਹ ਵੇਖਦੇ ਹਨ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਟਰੱਸਟ ਨਾ ਕਰ ਸਕਣ, ਅਤੇ ਗਲਤ ਹੋਣ 'ਤੇ ਵਾਪਸੀ ਨਹੀਂ ਹੋ ਸਕੇ।

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

ਦੂਜਾ ਫੰਦਾ "Advanced" ਨੂੰ ਇਕ ਕੱਚੜਦਾਨ ਬਣਾਉਣਾ ਹੈ। ਜਦ ਹਰ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ ਉਸ ਇਕ ਪੈਨਲ ਵਿੱਚ ਪਾਈ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਉਹ ਪੈਨਲ ਲੰਮਾ ਤੇ ਅਤਿਆਚਾਰੀ ਹੋ ਜਾਂਦਾ ਹੈ। ਟਾਸਕ ਅਤੇ ਖਤਰੇ ਅਨੁਸਾਰ ਗਰੁੱਪ ਕਰੋ। "Data retention" ਅਤੇ "API keys" ਦੋਹਾਂ advanced ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਇੱਕੋ ਹੀ ਢੇਰ ਵਿੱਚ ਨਹੀਂ ਰਹਿਣੇ।

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

ਆਮ ਨਾਕਾਮੀ ਦੇ ਪੈਟਰਨ:

• ਕੋਈ signposting ਨਹੀਂ: ਮਹੱਤਵਪੂਰਨ ਵਿਕਲਪ ਉਸ ਵੇਲੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦ ਤੱਕ ਕੋਈ ਪਹਿਲਾਂ ਹੀ ਰਾਹ ਨਹੀਂ ਜਾਣਦਾ।
• "Advanced" ਇਕ ਡੰਪਿੰਗ ground: ਕੋਈ ਸ਼੍ਰੇਣੀ, ਕ੍ਰਮ ਜਾਂ ਪ੍ਰਭਾਵ ਨੋਟ ਨਹੀਂ।
• ਮੋਡਲ ਓਵਰਲੋਡ: ਬਹੁਤ ਸਾਰੇ ਪੋਪਅੱਪ ਅਤੇ ਘੱਟ ਸੰਦਰਭ।
• ਚੇਤਾਵਨੀ-ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨ: ਡਰਾਉਣੀ ਟੈਕਸਟ ਦੀ ਥਾਂ ਸੁਰੱਖਿਅਤ ਫਲੋ (ਪ੍ਰੀਵਿਊ, ਡਿਫੌਲਟ, ਸਕੋਪਡ permissions)।
• ਪੁਸ਼ਟੀਕਰਨ ਥਕਾਵਟ: ਹਰ ਚੀਜ਼ ਪੁੱਛਦੀ ਹੈ "Are you sure?" ਤਾਂ ਲੋਕ ਕਲਿੱਕ ਕਰ ਰਹੇ ਹਨ।

ਡਰਾਉਣੀਆਂ ਚੇਤਾਵਨੀਆਂ ਸੁਰੱਖਿਆ ਨਹੀਂ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਡਿਜ਼ਾਈਨ ਬਿਹਤਰ ਡਿਫੌਲਟ, ਸਪਸ਼ਟ ਸਕੋਪ (ਕੀ ਬਦਲੇਗਾ, ਕਿੱਥੇ, ਅਤੇ ਕਿਸ ਲਈ), ਅਤੇ ਸੇਵ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਤੀਜਾ ਦਿਖਾਉਂਦੇ ਪ੍ਰੀਵਿਊਜ਼ ਹੋਦੇ ਹਨ।

ਹਰ ਚੀਜ਼ ਨੂੰ ਪੁષ્ટੀ ਦੀ ਲੋੜ ਬਣਾਉਣਾ ਵੀ ਬਚਣਾ। ਸਿਰਫ਼ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀਕਰਨ ਰੱਖੋ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਨਾਲ ਰਿਕਵਰੀ (undo, snapshots, rollback) ਸ਼ਾਮਿਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਐਡਮਿਨ ਟੂਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਰਕ-ਗ੍ਰੇਅਰਲਜ਼ ਨੂੰ ਵਹਿਮੀ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਵਿੱਚ ਨਿਰਮਾਣ ਕਰੋ ਬਜਾਏ ਕਿ ਬਾਅਦ ਵਿੱਚ ਚੇਤਾਵਨੀਆਂ ਜੋੜਨ।

ਤੇਜ਼ ਚੈੱਕਸ ਅਤੇ ਅਗਲੇ ਪ੍ਰੈਕਟਿਕਲ ਕਦਮ

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

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

5 ਮਿੰਟ ਚੈਕਲਿਸਟ

ਸਕ੍ਰੀਨ ਨੂੰ ਇਕ ਵਾਸਤਵਿਕ ਓਪਰੇਟਰ ਵਾਂਗ ਕਰ ਕੇ ਦੇਖੋ ਅਤੇ ਇਹ ਜाँचੋ:

• ਡਿਫੌਲਟ ਨਜ਼ਾਰਾ ਟਾ੍ਰ: ਸਿਖਦੀਆਂ ਤਿੰਨ ਸਭ ਤੋਂ ਉਪਰਲੇ ਟਾਸਕਾਂ ਨੂੰ support ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਸਕ੍ਰੋਲ ਕਰਨ ਦੇ।
• ਕੀ rare ਜਾਂ risky ਕੰਟਰੋਲ intentional reveal ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ ("Advanced", "More actions", ਵੱਖਰਾ ਟੈਬ, ਜਾਂ ਵੱਖਰਾ ਫਲੋ)?
• ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਸਪਸ਼ਟ ਲੇਬਲ, ਵਿਜ਼ੂਅਲ ਵੱਖਰਾ ਅਤੇ ਮਜ਼ਬੂਤ ਪੁਸ਼ਟੀ ਮੰਗਦੀਆਂ ਹਨ?
• ਹਰ ਬਦਲਾਅ ਸਪਸ਼ਟ-ਭਾਸ਼ਾ ਸੰਖੇਪ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਵਾਪਸੀ ਦਾ ਤਰੀਕਾ ਹੈ?
• ਭੂਮਿਕਾਵਾਂ ਅਤੇ permissions ਅਸਲ ਓਪਰੇਟਰ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਆਰਗ ਚਾਰਟ ਟਾਇਟਲ ਨਾਲ?

ਜੇ ਤੁਸੀਂ ਇੱਕ ਵੀ ਆਈਟਮ 'ਤੇ ਨਾਕਾਮ ਰਹਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ progressive disclosure ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ ਉਮੀਦਵਾਰ ਲੱਭ ਲਿਆ ਹੈ।

ਪ੍ਰੈਕਟਿਕਲ ਅਗਲੇ ਕਦਮ

ਇੱਕ ਗਲਤੀ-ਮਾਗਣ ਵਾਲੇ ਫਲੋ ਨੂੰ ਚੁਣੋ ਅਤੇ ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਅ ਨਾਲ ਉਸਨੂੰ ਸੁਧਾਰੋ:

1. ਸਿਖੋ ਕਿ ਟਾਪ-ਤਿੰਨ ਓਪਰੇਟਰ ਟਾਸਕ ਕੀ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਡਿਫੌਲਟ ਰਾਹ ਬਣਾਓ।

2. Advanced ਜਾਂ risky ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਰਾਦਾ ਨਾਲ ਲੇਬਲ ਕਰੋ (ਉਦਾਹਰਣ: "Reset user MFA (disrupts login)" ਦੀ ਥਾਂ "Reset")。

3. ਜਿੱਥੇ ਨੁਕਸਾਨ ਰੋਕਣ ਲਈ ਲੋੜ ਹੋਵੇ, ਉਥੇ ਹੀ friction ਜੋੜੋ: ਵੱਖਰੀ ਥਾਂ, ਪ੍ਰੀਵਿਊ, ਅਤੇ ਅਪਰਿਵਰਤਨੀ ਕਾਰਵਾਈਆਂ ਲਈ typed confirmations।

4. ਮਲਟੀ-ਚੇਂਜ ਫਾਰਮਾਂ ਲਈ ਸੰਖੇਪ ਸਮੀਖਿਆ ਕਦਮ ਜੋੜੋ: "ਤੁਸੀਂ ਇਹ ਬਦਲਣ ਵਾਲੇ ਹੋ: role, access scope, ਅਤੇ billing tier."。

5. ਰਿਕਵਰੀ ਜੋੜੋ: ਸਧਾਰਨ ਬਦਲਾਅ ਲਈ undo, config ਬੰਡਲਾਂ ਲਈ rollback, ਅਤੇ ਇਕ ਆਡਿਟ ਨੋਟ ਜੋ ਓਪਰੇਟਰ ਸਮਝ ਸਕੇ।

ਇੱਕ ਛੋਟਾ ਪਰ ਪਰਖਣਯੋਗ ਟੈਸਟ: ਨਵੇਂ ਸਾਥੀ ਨੂੰ ਪੁੱਛੋ ਕਿ ਬਿਨਾਂ ਖਾਤਾ delete ਕੀਤੇ ਕਿਸੇ ਦੀ ਐਕਸੇਸ ਹਟਾਉਣ ਦਾ ਤਰੀਕਾ ਦੱਸੋ। ਜੇ ਉਹ ਹੇਜ਼ੀਟੇਟ ਕਰਦਾ ਹੈ, ਗਲਤ ਬਟਨ ਦਬਾਉਂਦਾ ਹੈ, ਜਾਂ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ, ਤਾਂ UI ਅਜੇ ਵੀ ਲੋਕਾਂ ਤੋਂ ਬਹੁਤ ਸੋਚਵਾਂਗਾ ਮੰਗ ਰਿਹਾ ਹੈ।

ਤੇਜ਼ੀ ਨਾਲ ਹੋਏ ਬਿਨਾਂ ਚੀਜ਼ਾਂ ਤੋੜਣ ਲਈ, ਫਲੋ ਦੀ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ ਅਤੇ ਤੰਗ ਲੂਪਾਂ ਵਿੱਚ ਇਤਰੇਟ ਕਰੋ। Koder.ai ਵਿੱਚ, planning mode ਕਦਮ ਅਤੇ edge cases ਨੂੰ ਨਕਸ਼ਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ snapshots/rollback ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਰਜਨ ਟੈਸਟ ਕਰਨ ਦਿੰਦੇ ਹਨ।