ਵਪਾਰਕ ਐਪ ਲਈ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸਕਰੀਨ: 12-ਸਕਰੀਨ ਬਲੂਪ੍ਰਿੰਟ

ਜ਼ਿਆਦਾਤਰ ਵਪਾਰਕ ਐਪ ਜਿੰਨੀ ਦੇਰ ਲੈਂਦੇ ਹਨ — ਉਹ ਕਿਉਂ\n\nਬਹੁਤ ਸਾਰੇ ਵਪਾਰਕ ਐਪ ਸਧਾਰਨ ਲੱਗਦੇ ਹਨ: “ਯੂਜ਼ਰ ਲੌਗਇਨ ਕਰਦੇ ਹਨ, ਰਿਕਾਰਡ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਰਿਪੋਰਟ ਨਿਕਾਸ ਕਰਦੇ ਹਨ।” ਅਸਲ ਸਮੱਸਿਆ ਉਸ ਮੁੱਖ ਵਿਚਾਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀਆਂ ਚੀਜ਼ਾਂ ਹੁੰਦੀ ਹੈ. ਟੀਮਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਬੁਨਿਆਦੀ ਸਕਰੀਨਾਂ ਹਰ ਵਾਰੀ ਫਿਰ ਤੋਂ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਹਰ ਵਾਰੀ ਥੋੜ੍ਹ੍ਹੀਆਂ ਵੱਖਰੀਆਂ ਚੋਣਾਂ ਕਰਦਿਆਂ.\n\nਝਟਪਟ ਰੁਕਾਵਟ ਅਕਸਰ ਦੁਹਰਾਵਟ ਤੋਂ ਆਉਂਦੀ ਹੈ. ਇੱਕ ਬੰਦਾ ਲੌਗਿਨ ਸਕਰੀਨ ਡਿਜ਼ਾਈਨ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਐਡਮਿਨ ਖੇਤਰ ਲਈ ਇੱਕ ਹੋਰ ਵਰਜਨ ਬਣਾਉਂਦਾ ਹੈ, ਤੇ ਤੀਜਾ “ਪਾਸਵਰਡ ਭੁੱਲ ਗਏ” ਫਲੋ ਜੋ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜੋੜਦਾ ਹੈ. ਇਹੀ ਗੱਲ ਸੈਟਿੰਗਸ, ਰੋਲ, ਬਿਲਿੰਗ, ਸਹਾਇਤਾ ਅਤੇ ਗਲਤੀ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨਾਲ ਵੀ ਹੁੰਦੀ ਹੈ. ਹਰ ਦੁਹਰਾਵਟ ਨਾਲ ਵਧੇਰੇ QA, ਹੋਰ ਐਜ ਕੇਸ ਤੇ ਛੋਟੀ UI ਵੱਖ-ਵੱਖਤਾ ਆਉਂਦੀ ਹੈ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਗੁੰਝਲਦਾਰ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ।\n\nਇਹ ਦੁਹਰਾਈ ਹੋਈ ਸਕਰੀਨਾਂ ਅਜਿਹੀਆਂ ਬੱਗਾਂ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਸ਼ੁਰੂ ਵਿੱਚ ਪਛਾਣਣ ਵਿੱਚ ਔਖੀਆਂ ਹੁੰਦੀਆਂ ਹਨ. ਇੱਕ permissions ਸਕਰੀਨ ਸ਼ਾਇਦ ਰੋਲ ਸੌਂਪਣ ਦੇਵੇ, ਪਰ “ਇੰਵਾਈਟ ਯੂਜ਼ਰ” ਸਕਰੀਨ ਇੱਕੋ ਨਿਯਮ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਭੁੱਲ ਸਕਦੀ ਹੈ. ਇੱਕ ਬਿਲਿੰਗ ਸਕਰੀਨ ਸੀਮਾਵਾਂ ਦਿਖਾ ਸਕਦੀ ਹੈ, ਪਰ ਇੱਕ ਅਪਲੋਡ ਫਾਰਮ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਉਪਭੋਗੀ ਕਿਉਂ ਕੈਪ 'ਤੇ ਪਹੁੰਚਿਆ। ਐਪ ਕੰਮ ਕਰਦੀ ਹੈ, ਪਰ ਗੰਦੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ.\n\nਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਸਕਰੀਨ ਬਲੂਪ੍ਰਿੰਟ ਇੱਕ ਸਾਂਝਾ ਸੈਟ ਹੈ ਉਹਨਾਂ ਡਿਫਾਲਟ ਸਕਰੀਨਾਂ ਦਾ ਜੋ ਜ਼ਿਆਦਾਤਰ ਵਪਾਰਕ ਐਪਾਂ ਨੂੰ ਚਾਹੀਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਸ ਵਿੱਚ ਸਪੱਠ ਬਿਹੇਵਿਯਰ ਅਤੇ ਸਮੱਗਰੀ ਨਿਯਮ ਹੋਣ। ਖਾਲੀ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਪ੍ਰਮਾਣਿਤ ਬਿਲਡਿੰਗ ਬਲੌਕ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਸੋਧ ਕਰਦੇ ਹੋ ਜੋ ਵਾਕਈ ਵਿਲੱਖਣ ਹੈ।\n\nਇਹ ਸਥਾਨਕ ਸਥਾਪਤ ਕਰਨ ਵਾਲੇ, ਛੋਟੀ ਟੀਮਾਂ ਅਤੇ ਪ੍ਰੋਡਕਟ ਮਾਲਕਾਂ ਲਈ ਹੈ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਕੰਨਿਆਂ ਨੂੰ ਕੰਟਰੋਲ ਕੀਤੇ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਚੈਟ-ਪਹਿਲਾ ਟੂਲ ਜਿਵੇਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਐਸਾ ਬਲੂਪ੍ਰਿੰਟ ਪ੍ਰੋਮਪਟ ਲਿਖਣਾ ਤੇ ਪੂਰੇ ਉਤਪਾਦ ਵਿੱਚ ਲਗਾਤਾਰ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨਾ ਆਸਾਨ ਕਰਦਾ ਹੈ।\n\n## ਇੱਕ ਸਕਰੀਨ ਨੂੰ ਅਸਲ ਵਿੱਚ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਬਣਾਉਂਦਾ ਕੀ ਹੈ\n\nਇੱਕ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਸਕਰੀਨ ਇੱਕ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਕੰਪੋਨੈਂਟ ਤੋਂ ਵੱਡੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਕੰਪੋਨੈਂਟ ਇੱਕ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ (ਬਟਨ, ਟੇਬਲ, ਮੋਡਲ)। ਇੱਕ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਸਕਰੀਨ ਇੱਕ ਪੂਰਾ ਪੇਜ ਹੁੰਦੀ ਹੈ ਜੋ ਕਈ ਐੱਪਾਂ ਵਿੱਚ ਇੱਕੋ ਕੰਮ ਸਮਾਧਾਨ ਕਰਦੀ ਹੈ, ਜਿਵੇਂ “ਯੂਜ਼ਰਾਂ ਦਾ ਪ੍ਰਬੰਧ” ਜਾਂ “ਬਿਲਿੰਗ।” ਇਸਦਾ ਇੱਕ ਸਪੱਠ ਉਦੇਸ਼, ਜਾਣਪਛਾਣ ਵਾਲਾ ਲੇਆਊਟ, ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।\n\nਸਕਰੀਨ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਬਣਾਉਣ ਲਈ, ਉਹ ਹਿੱਸੇ ਮਿਆਰਬੱਧ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲੋਕਾਂ ਨੂੰ ਮੁੜ ਸਿੱਖਣ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ:\n\n- ਲੇਆਊਟ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ (ਪੇਜ਼ ਟਾਈਟਲ, ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ, “ਵਾਪਸ” ਕਿੱਥੇ ਲੈਂਦਾ ਹੈ)\n- ਕਾਪੀ ਟੋਨ ਅਤੇ ਲੇਬਲ (ਛੋਟਾ, ਸਧਾਰਣ ਭਾਸ਼ਾ ਜੋ ਨਿਰੰਤਰ ਰਹੇ)\n- ਸਥਿਤੀਆਂ (ਲੋਡਿੰਗ, ਖਾਲੀ, ਸਫਲਤਾ, ਗਲਤੀ, ਅਤੇ “ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ”)\n\nਇਸੇ ਵੇਲੇ, ਬਦਲਣ ਵਾਲੇ ਹਿੱਸਿਆਂ ਨੂੰ ਲਚਕੀਲਾ ਰੱਖੋ। ਇੱਕ Settings ਸਕਰੀਨ ਇੱਕੋ ਢਾਂਚਾ ਸਾਂਝਾ ਕਰ ਸਕਦੀ ਹੈ ਪਰ ਫੀਲਡ ਉਤਪਾਦ ਅਨੁਸਾਰ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ। Roles ਸਕਰੀਨ ਇੱਕੋ ਪੈਟਰਨ ਰੱਖ ਸਕਦੀ ਹੈ (ਰੋਲ ਲਿਸਟ ਤੇ ਪਰਮੀਸ਼ਨ ਮੈਟ੍ਰਿਕਸ) ਪਰ ਅਸਲ ਪਰਮੀਸ਼ਨ ਡੋਮੇਨ ਦੇ ਅਨੁਸਾਰ ਬਦਲ ਜਾਂਦੇ ਹਨ। Billing ਵਿੱਚ ਵੱਖ-ਵੱਖ ਯੋਜਨਾਵਾਂ, ਯੂਸੇਜ ਸੀਮਾਵਾਂ, ਟੈਕਸ ਅਤੇ ਮੁਦਰਾਵਾਂ ਲਈ ਜਗ੍ਹਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਬ੍ਰੈਂਡਿੰਗ ਬਿਨਾਂ ਸਕਰੀਨ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ ਬਦਲੀ ਜਾ ਸਕਦੀ ਹੈ।\n\nਇਸੀ ਲਈ 12-ਸਕਰੀਨ ਬਲੂਪ੍ਰਿੰਟ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਹਰ ਸਕਰੀਨ ਇੱਕ ਵਾਰੀ ਵੇਰਵਾ ਦਿੰਦੇ ਹੋ, ਫਿਰ ਇੱਕ ਅਸਲ ਐਪ (ਜਿਵੇਂ ਇੱਕ ਛੋਟਾ CRM) ਵਿੱਚ ਸਿਰਫ ਫੀਲਡ, ਰੋਲ ਅਤੇ ਯੋਜਨਾ ਨਿਯਮ ਥੋੜ੍ਹ੍ਹੇ ਬਦਲ ਕੇ ਅਨੁਕੂਲ ਕਰ ਲੈਂਦੇ ਹੋ।\n\n## ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ 12 ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ ਸਕਰੀਨ\n\nਜੇ ਤੁਸੀਂ ਸਕਰੀਨਾਂ ਦਾ ਇੱਕ ਸੈਟ ਤਿਆਰ ਰੱਖਦੇ ਹੋ ਜੋ ਨਕਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਵੇ, ਨਵੇਂ ਉਤਪਾਦ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਖਾਲੀ ਪੰਨੇ ਵਾਂਗ ਨਹੀਂ ਮਹਿਸੂਸ ਹੁੰਦੇ। ਚਾਲ ਇਹ ਹੈ ਕਿ ਇਹ ਸਕਰੀਨਾਂ ਇਕ ਜੁੜੀ ਹੋਈ ਰਾਹ ਵਾਂਗ ਸੋਚੋ, ਵੱਖ-ਵੱਖ ਕੰਮ ਨਹੀਂ।\n\nਇੱਕ ਸਧਾਰਣ ਯਾਤਰਾ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀ ਹੈ: ਨਵਾਂ ਯੂਜ਼ਰ ਸਾਈਨ ਅਪ ਕਰਦਾ ਹੈ ਅਤੇ ਲੌਗ ਇਨ ਹੁੰਦਾ ਹੈ, ਇੱਕ ਛੋਟੀ ਓਨਬੋਰਡਿੰਗ ਪੂਰੀ ਕਰਦਾ ਹੈ, ਆਪਣਾ ਪ੍ਰੋਫਾਈਲ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਟੀਮਮੈਟਾਂ ਨੂੰ ਨਿਯੋਤਾ ਦਿੰਦਾ ਹੈ, ਰੋਲ ਸੈੱਟ ਕਰਦਾ ਹੈ, ਸੈਟਿੰਗਸ ਨੂੰ ਢੰਗ ਨਾਲ ਸਮਝਦਾ ਹੈ, ਫਿਰ (ਜੇ ਐਪ ਪੇਡ ਹੈ) ਯੋਜਨਾ ਚੁਣਦਾ ਅਤੇ ਯੂਸੇਜ ਵੇਖਦਾ ਹੈ। ਜਦੋਂ ਕੁਝ ਠੀਕ ਨਹੀਂ ਲੱਗਦਾ, ਉਹ ਆਡਿਟ ਲੋਗ ਜਾਂ ਸਹਾਇਤਾ ਖੋਲ੍ਹਦਾ ਹੈ।\n\n| Screen | ਐਮਵੀਪੀ? | ਕੰਮ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਡੇਟਾ |\n|---|---|---|\n| 1) Log in | Required | Email/username, password, session/token |\n| 2) Sign up | Required | Email, password, acceptance of terms flag |\n| 3) Password reset | Required | Email, reset token, new password |\n| 4) Onboarding (first run) | Required | Org/workspace name, default preferences |\n| 5) Profile | Required | Display name, email, optional avatar |\n| 6) Team members | Optional | User list, invite email, status (pending/active) |\n| 7) Roles and permissions | Optional | Role names, permission set, user-role mapping |\n| 8) Settings (app/org) | Required | Current settings values, save/update endpoint |\n| 9) Billing and plan | Optional (Required if paid) | Current plan, price, payment method status |\n| 10) Usage and limits | Optional (Required if limited) | Usage counters, limit thresholds, reset date |\n| 11) Audit log | Optional | Event list (who/what/when), basic filters |\n| 12) Help and support | Optional | FAQ items, contact method, ticket/message fields |\n\nਐਕ ਛੋਟੀ MVP ਵਿੱਚ ਵੀ, ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀਆਂ ਸਕਰੀਨਾਂ ਭੇਜੋਗੇ। ਜੇ ਤੁਸੀਂ ਮਲਟੀ-ਯੂਜ਼ਰ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ Team ਅਤੇ Roles ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਪੈਸਾ ਲੈਂਦੇ ਹੋ, ਤਾਂ Billing ਦੀ ਲੋੜ ਹੈ। ਜੇ ਤੁਸੀਂ ਕੈਪ ਲਾਗੂ ਕਰਦੇ ਹੋ, ਤਾਂ Usage ਦੀ ਲੋੜ ਹੈ। ਬਾਕੀ ਸਭ ਕੁਝ ਸਧਾਰਨ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵਧ ਸਕਦਾ ਹੈ।\n\n## Auth ਸਕਰੀਨ: ਲੌਗਿਨ, ਸਾਈਨ ਅਪ, ਪਾਸਵਰਡ ਰੀਸੈੱਟ\n\nAuth ਪਹਿਲਾ ਭਰੋਸੇ ਦਾ ਮੌਕਾ ਹੁੰਦਾ ਹੈ। ਜੇ ਇਹ ਗੁੰਝਲਦਾਰ ਜਾਂ ਅਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੋਵੇ, ਲੋਕ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਚਲੇ ਜਾਂਦੇ ਹਨ।\n\n### Login ਸਕਰੀਨ ਲਈ ਲਾਜ਼ਮੀ ਚੀਜ਼ਾਂ\n\nਪੇਜ਼ ਸਾਦਾ ਰੱਖੋ: email (ਜਾਂ username), password, ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਬਟਨ। ਕੁਝ ਛੋਟੇ ਸੁਧਾਰ ਜੋ ਸਹਾਇਤਾ ਟਿਕਟ ਘਟਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਭਰੇ ਹੋਏ ਇੰਟਰਫੇਸ ਦੇ ਸ਼ਾਮਲ ਕਰੋ।\n\nਜੇ ਤੁਸੀਂ ਕੁਝ ਹੀ ਅਤਿਰਿਕਤ ਚੀਜ਼ਾਂ ਜੋੜਦੇ ਹੋ, ਤਾਂ ਇਹਨਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ: “show password” ਟੌਗਲ, ਗਲਤ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਲਈ ਸਪੱਠ ਗਲਤੀ ਟੈਕਸਟ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਸੁਰੱਖਿਆ نوਟ ਜਿਵੇਂ “ਅਸੀਂ ਕਦੇ ਵੀ ਈਮੇਲ ਰਾਹੀਂ ਤੁਹਾਡਾ ਪਾਸਵਰਡ ਨਹੀਂ ਪੁੱਛਾਂਗੇ।” “Remember me” ਸਿਰਫ਼ ਉਹਨਾਂ ਐਪਾਂ ਲਈ ਵਰਤੋ ਜੋ ਅਕਸਰ ਨਿੱਜੀ ਡਿਵਾਇਸਾਂ ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। SSO ਸਿਰਫ਼ ਉਹੋਵਾਂ ਜੋ ਤੁਸੀਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਹਿਯੋਗ ਕਰ ਸਕਦੇ ਹੋ, ਜੋੜੋ।\n\nSign up ਨੂੰ ਤੁਹਾਡੇ ਬਿਜ਼ਨੈਸ ਮਾਡਲ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਨਰਲ ਉਤਪਾਦਾਂ ਲਈ ਖੁੱਲ੍ਹਾ ਸਾਈਨ ਅਪ ਈਮੇਲ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨੋਟ ਨਾਲ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ। ਟੀਮ ਟੂਲਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ邀ਤ-ਕੇਵਲ ਵਰਜਨ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਇੱਕ ਸਧਾਰਨ ਸੁਨੇਹਾ “ਆਪਣੇ ਐਡਮਿਨ ਤੋਂ ਨਿਯੋਤਾ ਮੰਗੋ” ਮੁਰਝਾਏ ਹੋਏ ਪੰਨੇ ਨਾਲੋਂ ਵਧੀਆ ਹੈ।\n\nPassword reset ਫਲੋ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਉਹ ਸੁਨੇਹੇ ਵਰਤੋ ਜੋ ਇਹ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰਦੇ ਕਿ ਈਮੇਲ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ, ਉਦਾਹਰਨ: “ਜੇ ਈਮੇਲ ਨਾਲ ਕੋਈ ਖਾਤਾ ਮਿਲਦਾ ਹੈ ਤਾਂ ਅਸੀਂ ਰੀਸੈੱਟ ਲਿੰਕ ਭੇਜ ਦਿੱਤਾ ਹੈ।” ਕਦਮ ਛੋਟੇ ਰੱਖੋ: ਬੇਨਤੀ, ਈਮੇਲ, ਨਵਾਂ ਪਾਸਵਰਡ, ਸਫਲਤਾ।\n\nਲਾਕਆਊਟ ਜਾਂ ਸੰਦੇਹਜਨਕ ਗਤੀਵਿਧੀ ਲਈ, ਮਦਦਗਾਰ ਅਤੇ ਸ਼ਾਂਤ ਟੋਨ ਵਰਤੋ। ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਬਾਅਦ, “15 ਮਿੰਟ ਬਾਅਦ ਫਿਰ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜਾਂ ਆਪਣਾ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਕਰੋ” ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਖਤਰਨਾਕ ਸਾਈਨ-ਇਨ ਪਾਇਆ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਵਰਿਫ਼ਿਕੇਸ਼ਨ ਕਦਮ ਦਿਖਾਓ ਅਤੇ ਇਕ ਵਾਕ ਵਿੱਚ ਸਮਝਾਓ ਕਿ ਕੀ ਹੋਇਆ।\n\n## ਓਨਬੋਰਡਿੰਗ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ\n\nਓਨਬੋਰਡਿੰਗ ਓਥੇ ਹੈ ਜਿੱਥੇ ਲੋਕ ਫ਼ੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਐਪ ਸਪਸ਼ਟ ਹੈ ਜਾਂ ਥਕਾਵਟ ਵਾਲਾ। ਪਹਿਲੀ ਵਰਤੋਂ ਛੋਟੀ ਰੱਖੋ: ਇੱਕ ਸੁਆਗਤ ਦਿਖਾਓ, ਸਿਰਫ਼ ਉਹੀ ਪੁੱਛੋ ਜੋ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ, ਅਤੇ ਜੇ ਕੋਈ ਕਦਮ ਵਿਕਲਪਿਕ ਹੈ ਤਾਂ “ਹੁਣ ਸਕਿਪ ਕਰੋ” ਵੱਖਰਾ ਰੱਖੋ। ਜੇ ਕੁਝ ਲਾਜ਼ਮੀ ਹੈ (ਜਿਵੇਂ ਸ਼ਰਤਾਂ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਨਾ ਜਾਂ ਵਰਕਸਪੇਸ ਚੁਣਨਾ), ਤਾਂ ਸਧਾਰਣ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੱਸੋ।\n\nਇੱਕ ਉਪਯੋਗ ਨਿਯਮ: “ਸ਼ੁਰੂ ਕਰਨਾ” ਅਤੇ “ਪੂਰਨ ਬਣਾਉਣਾ” ਨੂੰ ਵੱਖਰਾ ਕਰੋ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਸ਼ੁਰੂ ਕਰਨ ਦਿਓ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਪੂਰਨ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਆ ਜਾਵੇ।\n\n### ਪਹਿਲੀ-ਦਫ਼ਾ ਓਨਬੋਰਡਿੰਗ ਜੋ ਲੋਕਾਂ ਨੂੰ ਰੋਜ਼ ਨਹੀਂ ਕਰਦੀ\n\nਛੋਟੇ ਕਦਮਾਂ ਲਈ ਟਾਰਗੇਟ ਰੱਖੋ ਜੋ ਹਰ ਇੱਕ ਸਕਰੀਨ 'ਤੇ ਫਿੱਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਐਪਾਂ ਲਈ ਮਤਲਬ ਇਹ ਹੈ:\n\n- ਵਰਕਸਪੇਸ ਬਣਾਉਣ ਜਾਂ ਚੁਣੋ (ਜੇ ਐਪ ਮਲਟੀ-ਟੀਮ ਸਹਿਯੋਗ ਕਰਦੀ ਹੈ)\n- ਟਾਈਮਜ਼ੋਨ ਅਤੇ ਭਾਸ਼ਾ ਸੈੱਟ ਕਰੋ ਤਾਂ ਤਾਰੀਖ਼ਾਂ ਅਤੇ ਈਮੇਲ ਠੀਕ ਦਿਖਨ\n- ਈਮੇਲ ਪੁਸ਼ਟੀ ਜੇ ਇਹ ਸੁਰੱਖਿਆ ਜਾਂ ਨਿਯੋਤਿਆਂ ਲਈ ਜ਼ਰੂਰੀ ਹੋਵੇ\n- ਇਮਪੋਰਟ ਜਾਂ ਟੀਮਮੈਟ ਨਿਯੋਤੇ ਵਿਕਲਪਿਕ ਤੇ ਸਕਿੱਪਯੋਗ ਰੱਖੋ\n\n### ਉਹ ਪ੍ਰੋਫਾਈਲ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਵਰਤਦੇ ਹਨ\n\nਪ੍ਰੋਫਾਈਲ ਸਕਰੀਨ ਵਿਅਕਤੀਗਤ ਜਾਣਕਾਰੀ (ਨਾਮ, ਈਮੇਲ), ਅਵਤਾਰ, ਟਾਈਮਜ਼ੋਨ, ਅਤੇ ਭਾਸ਼ਾ ਕਵਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। “ਪਾਸਵਰਡ ਬਦਲੋ” ਅਤੇ “ਸੈਸ਼ਨ/ਡਿਵਾਈਸ” ਨੂੰ ਹੋਰ ਸੁਰੱਖਿਆ ਆਈਟਮਾਂ ਦੇ ਨੇੜੇ ਰੱਖੋ ਤਾਂ ਯੂਜ਼ਰ ਉਹਨਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਲੱਭ ਸਕਣ।\n\nਜੇ ਤੁਹਾਡਾ ਉਤਪਾਦ ਚੈਂਜ ਵਰਕਸਪੇਸ ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਟੌਪ ਬਾਰ ਵਿੱਚ ਇੱਕ ਸਪੱਠ ਟੀਮ ਸਵਿੱਚਰ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਜਾਂ ਸੈਟਿੰਗਸ ਵਿੱਚ ਵੀ ਰੱਖੋ। ਲੋਕਾਂ ਨੂੰ ਹਮੇਸ਼ਾਂ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾ ਦਾ ਮੌਜੂਦਾ ਸੰਦਰਭ ਕਿੱਥੇ ਹੈ ਅਤੇ ਕਿਵੇਂ ਸਵിച്ച് ਕਰਨਾ ਹੈ।\n\nਲੌਗਆਊਟ ਅਤੇ ਸੈਸ਼ਨ ਟਾਈਮਆਉਟ ਬਾਰੇ ਇਰਾਦੇਮੰਦ ਹੋਵੋ। ਲੌਗਆਊਟ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਯੂਜ਼ਰ ਉਮੀਦ ਕਰਦੇ ਹਨ (ਅਕਸਰ ਪ੍ਰੋਫਾਈਲ ਮੈਨੂ)। ਜਦੋਂ ਸੈਸ਼ਨ ਖਤਮ ਹੋ ਜਾਵੇ, ਤਾਂ ਸਮਝਾਓ ਕਿ ਕੀ ਹੋਇਆ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ। “ਤੁਹਾਨੂੰ ਗੈਰ-ਸਰਗਰਮੀ ਕਾਰਨ ਸਾਈਨ ਆਊਟ ਕੀਤਾ ਗਿਆ। ਕਿਰਪਾ ਕਰਕੇ ਮੁੜ ਲੌਗਇਨ ਕਰੋ।” ਸਾਇਲੈਂਟ ਰੀਡਾਇਰੈਕਟ ਨਾਲੋਂ ਇਹ ਬਿਹਤਰ ਹੈ।\n\n## ਰੋਲ, ਪਰਮੀਸ਼ਨ ਅਤੇ ਯੂਜ਼ਰ ਪ੍ਰਬੰਧਨ\n\nਕਈ “ਸੁਰੱਖਿਆ” ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਸਲ ਵਿੱਚ UI ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਲੋਕ ਨਹੀਂ ਦੇਖ ਸਕਦੇ ਕਿ ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਉਹ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ। ਇੱਕ ਦੁਬਾਰਾ ਵਰਤੋਂਯੋਗ roles-and-users ਖੇਤਰ ਇਸ ਅਨੁਮਾਨ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ ਅਤੇ ਲਗਭਗ ਹਰ ਕਿਸੇ ਟੀਮ ਐਪ ਵਿੱਚ ਫਿੱਟ ਹੋ ਜਾਂਦਾ ਹੈ।\n\nRoles ਸਕਰੀਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਇੱਕ ਸਧਾਰਣ ਰੋਲ ਲਿਸਟ ਦਿਖਾਉਂਦਾ ਹੈ (Owner, Admin, Member, Viewer) ਅਤੇ ਛੋਟਾ ਵੇਰਵਾ ਸਧਾਰਣ ਸ਼ਬਦਾਂ ਵਿੱਚ। ਇਸਨੂੰ permissions matrix ਨਾਲ ਜੋੜੋ ਜਿੱਥੇ rows ਕਾਰਵਾਈਆਂ ਹਨ (ਉਦਾਹਰਨ: “ریکارڈ ਵੇਖੋ”, “ਨਿਰਯਾਤ”, “ਬਿਲਿੰਗ ਪ੍ਰਬੰਧ”, “ਵਰਕਸਪੇਸ ਮਿਟਾਓ”) ਅਤੇ ਕਾਲਮ ਰੋਲ। ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ: ਚੈੱਕਮਾਰਕ ਵਰਤੋਂ, ਕਾਰਵਾਈਆਂ ਨੂੰ ਕੁਝ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਗੁਠ ਕਰੋ, ਅਤੇ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ ਛੋਟੇ ਟੂਲਟਿਪ ਰੱਖੋ।\n\nਯੂਜ਼ਰ ਪ੍ਰਬੰਧਨ ਨੂੰ ਇਨਬਾਕਸ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਡੇਟਾਬੇਸ ਟੇਬਲ ਵਾਂਗ ਨਹੀਂ। ਹਰ ਵਿਅਕਤੀ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ ਸਥਿਤੀ ਬੈਜ (Active, Invited, Pending approval, Suspended) ਅਤੇ ਤੇਜ਼ ਕਾਰਵਾਈਆਂ: ਈਮੇਲ ਨਾਲ ਨਿਯੋਤਾ ਭੇਜੋ ਰੋਲ ਦੇ ਨਾਲ, ਇਨਵਾਈਟ ਮੁੜ ਭੇਜੋ, ਰੋਲ ਬਦਲੋ (ਪੁਸ਼ਟੀ ਦੇ ਨਾਲ), ਯੂਜ਼ਰ ਹਟਾਓ (“ਉਨ੍ਹਾਂ ਦੇ ਡੇਟਾ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ?” ਲਿਖੋ), ਅਤੇ ਤੇਜ਼ ਨਿਗਰਾਨੀ ਲਈ “last active” ਤਾਰੀਖ਼।\n\nਜੇ ਤੁਹਾਨੂੰ ਐਕਸੈੱਸ ਬੇਨਤੀ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਇਸ ਨੂੰ ਹਲਕਾ ਰੱਖੋ: “Request access” ਬਟਨ, ਇੱਕ ਛੋਟਾ ਕਾਰਨ ਫੀਲਡ, ਅਤੇ ਐਡਮਿਨਾਂ ਲਈ approvals ਕਤਾਰ।\n\nਗਾਰਡਰੇਲ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਸਿਰਫ਼ Owners ਬਿੱਲਿੰਗ-ਸਬੰਧੀ ਪਰਮੀਸ਼ਨਾਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ, ਵਰਕਸਪੇਸ ਮਿਟਾ ਸਕਦੇ ਹਨ, ਜਾਂ ਮਾਲਕੀ ਹਵਾਲਾ ਕਰ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਕੋਈ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਪੱਸ਼ਟ ਕਾਰਨ ਦਿਖਾਓ ਅਤੇ ਠੀਕ ਰੋਲ (ਜਾਂ ਵਿਅਕਤੀ) ਕਿਹੜਾ ਕਰ ਸਕਦਾ ਹੈ, ਉਹ ਦਿਖਾਓ।\n\n## ਸੈਟਿੰਗਸ ਜੋ ਐਪ ਵਧਣ ਨਾਲ ਸੰਭਲਿਆਂ ਰਹਿਣ\n\nSettings ਸਕਰੀਨਾਂ ਅਕਸਰ ਇਕ ਜੰਕ ਡਰਾਅਰ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਇਸ ਦਾ ਹੱਲ ਇੱਕ settings ਹੱਬ ਹੈ ਜਿਸਦਾ ਇੱਕ ਥਿਰ ਲੇਆਊਟ ਹੋਵੇ: ਖੱਬੇ ਨੈਵੀਗੇਸ਼ਨ ਵਿੱਚ ਮੁਦਦੇ ਅਤੇ ਸੱਜੇ ਪੈਨਲ ਵਿੱਚ ਵੇਰਵੇ।\n\nਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਮਦਦ ਕਰਦਾ ਹੈ: ਜੇ ਕੋਈ ਚੀਜ਼ ਤੁਹਾਡਾ ਉਪਭੋਗੀ ਦੁਬਾਰਾ-ਦੁਬਾਰਾ ਬਦਲੇਗਾ, ਉਹ Settings ਵਿੱਚ ਹੋਈ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਇਹ ਪਹਿਲੀ ਵਾਰੀ ਦੀ ਸੈਟਅੱਪ ਦਾ ਹਿੱਸਾ ਹੈ, ਤਾਂ ਉਹ onboarding ਵਿੱਚ ਰੱਖੋ।\n\n### ਇੱਕ ਪੇਸ਼ਗੋਈਯੋਗ settings ਹੱਬ ਵਰਤੋਂ\n\nਮੇਨੂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਐਸਾ ਰੱਖੋ ਕਿ ਲੋਕਾਂ ਨੂੰ ਪਛਾਣ ਆਵੇ। ਜ਼ਿਆਦਾਤਰ ਵਪਾਰਕ ਐਪਾਂ ਲਈ ਥੋੜ੍ਹ੍ਹੇ ਵਰਗੀ ਸ਼੍ਰੇਣੀਆਂ ਬਹੁਤ ਕੁਝ ਕਵਰ ਕਰ ਲੈਂਦੀਆਂ ਹਨ: Profile and preferences, Notifications, Security, Organization (ਜਾਂ Workspace), ਅਤੇ Integrations (ਕੇਵਲ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਹਨ)।\n\nਮੁਢਲੀ ਚੀਜ਼ਾਂ ਨੂੰ ਚਤੁਰ ਨਾਮਾਂ ਹੇਠਾਂ ਨਹੀਂ ਛੁਪਾਓ। “Organization” “Workspace DNA” ਤੋਂ ਬਿਹਤਰ ਹੈ।\n\n### ਉਹ ਸੈਟਿੰਗਸ ਖੇਤਰ ਜੋ ਪਹਿਲੇ ਹੀ ਫਾਇਦਾ ਦਿੰਦੇ ਹਨ\n\nNotifications ਸਭ ਤੋਂ ਅਚ্ছে ਤਰੀਕੇ ਨਾਲ ਚੈਨਲ ਅਨੁਸਾਰ ਵੰਡੇ ਜਾਣ — email ਵਿਰੁੱਧ in-app — ਅਤੇ ਮਹੱਤਤਾ ਅਨੁਸਾਰ। ਗੈਰ-ਆਵਸ਼ਯਕ ਅੱਪਡੇਟਾਂ ਲਈ ਫ੍ਰਿਕਵੈਂਸੀ ਚੁਣਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿਓ, ਪਰ ਨਿੱਜੀ ਅਲਾਰਮਾਂ ਨੂੰ ਸਪੱਠ ਤੇ ਅਸਾਨ ਬਣਾਓ।\n\nSecurity ਸੈਟਿੰਗਾਂ ਹੈ ਜਿੱਥੇ ਭਰੋਸਾ ਜਿੱਤਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ 2FA ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਆਕਟਿਵ ਸੈਸ਼ਨ ਦੀ ਸੂਚੀ ਦਿਖਾਓ ਤਾਂ ਯੂਜ਼ਰ ਹੋਰ ਡਿਵਾਈਸਾਂ ਤੋਂ ਸਾਈਨ ਆਊਟ ਕਰ ਸਕਣ। ਜੇ ਤੁਹਾਡੀ ਦਰਸ਼ਕ ਸਮੁਦਾਇ ਸੱਝੇ ਕੰਪਿਊਟਰਾਂ ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ, “last active” ਅਤੇ ਡਿਵਾਈਸ ਜਾਣਕਾਰੀ ਮਦਦਗਾਰ ਹੁੰਦੀ ਹੈ।\n\nOrganization ਸੈਟਿੰਗਾਂ ਉਹ ਚੀਜ਼ਾਂ ਕਵਰ ਕਰਨ ਜਿੰਨ੍ਹਾਂ ਤੱਕ ਐਡਮਿਨ ਪਹਿਲਾਂ ਪਹੁੰਚਦਾ ਹੈ: org ਦਾ ਨਾਮ, ਬ੍ਰੈਂਡਿੰਗ ਮੁਢਲੀ ਗੱਲਾਂ (ਲੋਗੋ/ਰੰਗ), ਅਤੇ ਨਵੇਂ ਨਿਯੋਤਿਆਂ ਲਈ ਡੀਫ਼ੌਲਟ ਰੋਲ।\n\nਛੋਟੇ CRM ਵਿੱਚ, ਸੇਲਜ਼ ਰੈਪ ਨੋਟੀਫਿਕੇਸ਼ਨ ਫ੍ਰਿਕਵੈਂਸੀ ਅਤੇ ਟਾਈਮਜ਼ੋਨ ਬਦਲਦੇ ਹਨ, ਜਦਕਿ ਐਡਮਿਨ ਕੰਪਨੀ ਦਾ ਨਾਮ ਅਤੇ ਡੀਫ਼ੌਲਟ ਰੋਲ ਅਪਡੇਟ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਪੁਸ਼ਟਿਕ ਸਥਾਨਾਂ ਵਿੱਚ ਰੱਖਣਾ ਬਾਅਦ ਵਿਚ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਬਚਾਉਂਦਾ ਹੈ।\n\n## ਬਿਲਿੰਗ, ਯੋਜਨਾਵਾਂ ਅਤੇ ਯੂਸੇਜ ਸੀਮਾਵਾਂ\n\nਬਿਲਿੰਗ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਭਰੋਸਾ ਜੀਤਿਆ ਜਾਂ ਹਾਰਿਆ ਜਾਂਦਾ ਹੈ। ਲੋਕਾਂ ਨੂੰ ਪੈਸਾ ਦੇਣ ਵਿੱਚ ਪਰੈਸ਼ਾਨੀ ਨਹੀਂ ਹੁੰਦੀ, ਪਰ ਉਹ ਅਚਾਨਕ ਚਾਰਜਾਂ ਨੂੰ ਨਫ਼ਰਤ ਕਰਦੇ ਹਨ। ਬਿਲਿੰਗ ਨੂੰ ਇੱਕ ਛੋਟੀ ਲੜੀ ਸਕਰੀਨਾਂ ਵਜੋਂ ਚੀਜ਼ਾਂ ਦਿਓ ਜੋ ਹਮੇਸ਼ਾਂ ਇੱਕੋ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਂਦੀਆਂ ਹਨ।\n\nਇੱਕ ਬਿਲਿੰਗ ਓਵਰਵਿਊ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਨਿਰਭਯ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਏ: ਮੌਜੂਦਾ ਯੋਜਨਾ ਦਾ ਨਾਮ, ਨਵੀਨੀਕਰਨ ਤਾਰੀਖ, ਭੁਗਤਾਨ ਵਿਧੀ, ਇਨਵੌਇਸ ਇਤਿਹਾਸ, ਅਤੇ ਰਸੀਦਾਂ ਲਈ ਬਿਲਿੰਗ ਈਮੇਲ। “ਪੇਮੈਂਟ ਵਿਧੀ ਸੰਪਾਦਿਤ ਕਰੋ” ਸਪੱਸ਼ਟ ਰੱਖੋ।\n\nਫਿਰ Plan compare view ਜੋੜੋ। ਸੀਮਾਵਾਂ ਸਧਾਰਣ ਭਾਸ਼ਾ ਵਿੱਚ ਸਪੱਸ਼ਟ ਕਰੋ (ਸੀਟਾਂ, ਪ੍ਰੋਜੈਕਟ, ਸਟੋਰੇਜ, API ਕਾਲ, ਜੋ ਵੀ ਤੁਹਾਡੇ ਐਪ ਲਈ ਮੇਲ ਖਾਂਦਾ ਹੈ) ਅਤੇ ਸਪੱਸ਼ਟ ਦੱਸੋ ਕਿ ਕਿਸ ਵੇਲੇ ਕੋਈ ਸੀਮਾ ਪੂਰੀ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। “Fair use” ਵਰਗੇ ਅਨਿਸ਼ਚਿਤ ਲੇਬਲਾਂ ਤੋਂ ਬਚੋ।\n\nਇੱਕ ਵੱਖਰਾ Usage and limits ਸਕਰੀਨ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਕੁਝ ਮੀਟਰ ਅਤੇ ਸਪੱਸ਼ਟ ਸੁਨੇਹੇ ਜਦੋਂ ਉਪਭੋਗੀ ਨੂੰ ਰੋਕਿਆ ਜਾਣਾ ਹੈ ਉਹ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਐਕਸ਼ਨ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਸਧਾਰਨ ਰੱਖੋ: ਇੱਕ ਅਪਗ੍ਰੇਡ ਬਟਨ, ਅਤੇ ਨੋਟ ਕਿ ਸਿਰਫ਼ ਐਡਮਿਨ ਯੋਜਨਾ ਬਦਲ ਸਕਦੇ ਹਨ।\n\nਰੱਦ ਕਰਨ ਅਤੇ ਡਾਊਨਗ੍ਰੇਡ ਨੂੰ ਇੱਕ ਫਲੋ ਵਜੋਂ ਵਰਤੋਂ, ਨਾ ਕਿ ਇਕ ਬਟਨ। ਦੱਸੋ ਕਿ ਕੀ ਬਦਲੇਗਾ, ਪੁਸ਼ਟੀ ਦਾ ਇੱਕ ਕਦਮ ਜੋੜੋ, ਅਤੇ “ਬਿਲਿੰਗ ਬਦਲੀ” ਸੁਨੇਹਾ ਭੇਜੋ।\n\nਉਦਾਹਰਨ: ਇੱਕ 3-ਅਦਮੀ CRM Free 'ਤੇ 1 pipeline ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਸਕਦਾ ਹੈ ਅਤੇ Pro 'ਤੇ 5। ਜਦੋਂ ਟੀਮ pipeline #2 ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ, ਸੀਮਾ ਦਿਖਾਓ, ਇਹ ਵੀ ਦੱਸੋ ਕਿ ਉਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਅਪਗਰੇਡ ਮਾਰਗ ਦਿਖਾਓ ਨਾਂ ਕਿ ਇੱਕ ਖਾਲੀ ਆਖਿਰ।\n\n## ਆਡਿਟ, ਸਹਾਇਤਾ ਅਤੇ ਸਪੋਰਟ ਸਕਰੀਨ\n\nਆਡਿਟ, ਸਹਾਇਤਾ, ਅਤੇ ਸਪੋਰਟ ਨੂੰ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਸਕਰੀਨਾਂ ਵਾਂਗ ਉਸਤੋਂ ਬਰਤੋ, ਨਾ ਕਿ ਐਡ-ਓਨਸ। ਇਹ ਭਰੋਸਾ ਘਟਾਉਂਦੇ ਹਨ, ਸਹਾਇਤਾ ਥ੍ਰੇਡ ਛੋਟੇ ਕਰਦੇ ਹਨ, ਅਤੇ ਐਡਮਿਨ ਕੰਮ ਸ਼ਾਂਤ ਰੱਖਦੇ ਹਨ।\n\n### ਆਡਿਟ ਲੋਗ ਸਕਰੀਨ\n\nਇੱਕ ਆਡਿਟ ਲੋਗ ਤਿੰਨ ਸਵਾਲ ਜਲਦੀ ਜਵਾਬ ਦੇ: ਕਿਸ ਨੇ ਕੀ ਕੀਤਾ, ਕਦੋਂ ਕੀਤਾ, ਅਤੇ (ਜੇ ਤੁਸੀਂ ਟਰੈਕ ਕਰਦੇ ਹੋ) ਕਿੱਥੇ ਤੋਂ। ਉਹਨਾਂ ਘਟਨਾਵਾਂ ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਡੇਟਾ ਜਾਂ ਪਹੁੰਚ ਵਿੱਚ ਬਦਲਾਅ ਲਿਆਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਮਜ਼ਬੂਤ ਸ਼ੁਰੂਆਤੀ ਸੈਟ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਸਾਈਨ-ਇਨ ਗਤੀਵਿਧੀ, ਪਾਸਵਰਡ ਬਦਲਾਅ, ਰੋਲ ਜਾਂ ਪਰਮੀਸ਼ਨ ਬਦਲਾਅ, ਮੁੱਖ ਰਿਕਾਰਡਾਂ ਦੀ ਬਣਾਟ/ਅਪਡੇਟ/ਡਿਲੀਟ, ਬਿਲਿੰਗ ਘਟਨਾਵਾਂ (ਯੋਜਨਾ ਬਦਲ, ਭੁਗਤਾਨ ਫੇਲ), ਯੂਸੇਜ ਸੀਮਾ ਹਿੱਟ, ਅਤੇ ਨਿਰਯਾਤ।\n\nਉਸਨੂੰ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ: ਸਪੱਸ਼ਟ ਇਵੈਂਟ ਨਾਮ, ਕਰਤਾਰ, ਟਾਰਗਟ (ਰਿਕਾਰਡ), ਟਾਈਮਸਟੈਂਪ, ਅਤੇ ਛੋਟਾ ਡੀਟੇਲ ਡਰਾਅਰ। ਬੇਸਿਕ ਫਿਲਟਰ (ਤਾਰੀਖ਼ ਰੇਂਜ, ਯੂਜ਼ਰ, ইਵੈਂਟ ਟਾਈਪ) ਜੋੜੋ। ਨਿਰਯਾਤ ਲਈ CSV ਇੱਕਸਪੋਰਟ ਮੌਜੂਦ ਰੂਪਾਂ ਨਾਲ ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।\n\n### ਸਹਾਇਤਾ ਕੇਂਦਰ ਅਤੇ ਸਪੋਰਟ\n\nਤੁਹਾਡੀ ਸਹਾਇਤਾ ਸਕਰੀਨ ਨੂੰ ਭਾਵਨਾਤਮਕ ਦੌਰਾਨ ਵੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ FAQ ਸੂਚੀ, ਸੰਪਰਕ ਵਿਕਲਪ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਸਥਿਤੀ ਨੋਟ (ਮਾਲੂਮ ਮੁੱਦੇ ਜਾਂ ਨਿਯਤ ਰੱਖ-ਰਖਾਵ) ਸ਼ਾਮਲ ਕਰੋ। ਭਾਸ਼ਾ ਸਧਾਰਣ ਅਤੇ ਕਾਰਵਾਈ-ਕੇਂਦਰਤ ਰੱਖੋ।\n\n“ਸਮੱਸਿਆ ਰਿਪੋਰਟ ਕਰਨ” ਲਈ, ਉਹੀ ਜਾਣਕਾਰੀ ਮੰਗੋ ਜੋ ਸਹਾਇਤਾ ਨੂੰ ਹਮੇਸ਼ਾਂ ਚਾਹੀਦੀ ਹੈ: ਉਨ੍ਹਾਂ ਦੀ ਉਮੀਦ ਕੀ ਸੀ ਵਿਰੁੱਧ ਕੀ ਹੋਇਆ, ਦੁਹਰਾਉਣ ਦੇ ਕਦਮ, ਸਕਰੀਨਸ਼ਾਟ ਜਾਂ ਰਿਕਾਰਡਿੰਗ, ਡਿਵਾਈਸ/ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ ਐਪ ਵਰਜਨ, ਸਮਾਂ ਜਦੋਂ ਹੋਇਆ, ਅਤੇ ਕੋਈ ਗਲਤੀ ਸੁਨੇਹਾ। ਭੇਜਣ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਪੁਸ਼ਟੀ ਦਿਖਾਓ ਜੋ ਕਿ ਕੀ ਕੈਪਚਰ ਕੀਤਾ ਗਿਆ ਅਤੇ ਕਿਵੇਂ ਫਾਲੋਅਪ ਕਰਨਾ ਹੈ, ਸੁਮੇਰੇ ਕਰੇ।\n\n## ਗਲਤੀ, ਖਾਲੀ, ਅਤੇ ਲੋਡਿੰਗ ਸਥਿਤੀਆਂ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਛੱਡ ਸਕਦੇ\n\nਅਧਿਕাংশ ਟੀਮਾਂ ਗਲਤੀ ਅਤੇ ਖਾਲੀ ਸਕਰੀਨਾਂ ਬਾਰੇ ਆਖ਼ਿਰ ਵਿੱਚ ਸੋਚਦੀਆਂ ਹਨ, ਫਿਰ ਛੇਤੀ ਹੀ ਖੋਲ੍ਹਣ ਵਾਲੀਆਂ ਸਪੇਸਾਂ ਭਰਨੇ ਵਿੱਚ ਦਿਨ ਲਾਂਭੀ ਲਗ ਜਾਂਦੇ ਹਨ। ਇਹ ਸਥਿਤੀਆਂ ਸਾਂਝੇ ਢਾਂਚੇ ਵਾਂਗ ਸੋਚੋ ਅਤੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਘੱਟ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਦੇ ਨਾਲ ਬੈਟਰ ਸ਼ਿਪ ਕਰ ਸਕੋਗੇ।\n\n### ਉਹ ਗਲਤੀਆਂ ਜੋ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਵੇਖਣਗੇ\n\nਗਲੋਬਲ ਤੌਰ 'ਤੇ ਇੱਕ polite ਗਲਤੀ ਪੇਜ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਸਾਫ਼ ਦੱਸੋ ਕੀ ਹੋਇਆ, ਇੱਕ ਸਪੱਸ਼ਟ ਅਗਲਾ ਕਦਮ ਦਿਓ (Retry), ਅਤੇ ਸਹਾਇਤਾ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਦਾ ਤਰੀਕਾ ਦਿਓ। ਤਕਨੀਕੀ ਵੇਰਵੇ ਜਿਵੇਂ request IDs ਇਕ ਛੋਟੇ “ਹੋਰ ਵੇਰਵੇ” ਖੰਡ ਦੇ ਪਿੱਛੇ ਰੱਖੋ।\n\nਇਨਲਾਈਨ ਗਲਤੀਆਂ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜਿਸ ਫੀਲਡ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਉਸਦੇ ਨੇੜੇ ਸੁਨੇਹਾ ਰੱਖੋ, ਅਤੇ ਟੋਨ ਨਿ਩ਤਰ ਰੱਖੋ। “Email doesn’t look right” “Invalid input” ਨਾਲੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੀਕਰ ਫਾਰਮ ਸਬਮਿਟ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਪਭੋਗੀ ਦੁਆਰਾ ਟਾਈਪ ਕੀਤੀ ਗਈ ਕੰਟੈਂਟ ਰੱਖੋ ਅਤੇ ਪਹਿਲੀ ਸਮੱਸਿਆ ਨੂੰ ਹਾਈਲਾਈਟ ਕਰੋ।\n\n### ਖਾਲੀ, ਲੋਡਿੰਗ, ਅਤੇ ਆਫਲਾਈਨ ਸਥਿਤੀਆਂ\n\nਖਾਲੀ ਸਥਿਤੀਆਂ ਖਾਲੀ ਪੇਜ਼ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਉਤਰ ਦਿਦੀਆਂ ਹਨ: ਇਹ ਪੇਜ਼ ਲਈ ਕੀ ਹੈ, ਅਤੇ ਹੁਣ ਮੈਂ ਕੀ ਕਰ ਸਕਦਾ ਹਾਂ? ਉਦਾਹਰਨ: “ਹਾਲੇ ਕੋਈ ਇਨਵੌਇਸ ਨਹੀਂ। ਆਪਣਾ ਪਹਿਲਾ ਇਨਵੌਇਸ ਬਣਾਓ ਤਾਂ ਕਿ ਭੁਗਤਾਨ ਟਰੈਕ ਹੋ ਸਕੇ।” ਇੱਕ ਸਪੱਸ਼ਟ ਕਾਲ-ਟੂ-ਐਕਸ਼ਨ ਜੋੜੋ।\n\nਲੋਡਿੰਗ ਸਥਿਤੀਆਂ ਉਡੀਕ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹੋਣ। ਛੋਟੀ ਕਾਰਵਾਈਆਂ ਲਈ ਸਪਿਨਰ ਵਰਤੋ, ਅਤੇ ਵੱਡੇ ਪੇਜ਼ ਲੋਡ ਲਈ ਸਕੈਲਟਨ ਵਰਤੋਂ ਤਾਂ ਯੂਜ਼ਰ ਲੇਆਊਟ ਆ ਰਿਹਾ ਹੈ ਇਹ ਵੇਖ ਸਕੇ।\n\nਜੇ ਐਪ ਆਫਲਾਈਨ ਹੈ, ਤਾਂ ਸਪੱਸ਼ਟ ਦੱਸੋ, ਦਿਖਾਓ ਕੀ ਕਿੱਥੇ ਕੰਮ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ cached ਡੇਟਾ ਵੇਖਣਾ), ਅਤੇ ਨੈੱਟਵਰਕ ਵਾਪਸੀ 'ਤੇ ਪੁਸ਼ਟੀ ਦਿਖਾਓ।\n\n## ਇਸ ਬਲੂਪ੍ਰਿੰਟ ਨੂੰ ਨਵੇਂ ਬਿਲਡ ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵਰਤਣਾ (ਕਦਮ-ਦਰ-ਕਦਮ)\n\nਤੇਜ਼ੀ ਉਹ ਸਮੇਂ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲਾਂ común ਸਕਰੀਨਾਂ ਦਾ ਫੈਸਲਾ ਕਰ ਲੈਂਦੇ ਹੋ, ਡੋਮੇਨ ਵਿਸਥਾਰ ਵਿੱਚ ਖਿੱਚੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ। ਜਦੋਂ ਟੀਮਾਂ ਇਨ੍ਹਾਂ ਬੁਨਿਆਦੀ ਗੱਲਾਂ 'ਤੇ ਪਹਿਲਾਂ ਸਹਿਮਤ ਹੁੰਦੀਆਂ ਹਨ, ਪਹਿਲਾ ਯੂਜ਼ੋਗ ਵਰਜਨ ਹਫ਼ਤਿਆਂ ਪਹਿਲਾਂ ਦਿਸਦਾ ਹੈ।\n\n### ਇੱਕ ਸਧਾਰਣ 5-ਕਦਮ ਵਰਕਫਲੋ\n\n- ਸਕਰੀਨ ਇਨਵੈਂਟਰੀ ਅਤੇ ਰੋਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਲਿਸਟ ਕਰੋ ਕਿ ਕੌਣ ਐਪ ਵਰਤਦਾ ਹੈ (admin, manager, member, read-only, billing owner) ਅਤੇ ਹਰ ਵਿਅਕਤੀ ਦਿਨ ਇੱਕ ਤੇ ਕੀ ਕਰਨਾ ਹੈ।\n- 12-ਸਕਰੀਨ ਖਾਕਾ ਨਕਲ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਡੋਮੇਨ ਅਨੁਸਾਰ ਰੀਨੇਮ ਕਰੋ। “Users” ਨੂੰ “Agents”, “Projects” ਨੂੰ “Deals”, “Workspace” ਨੂੰ “Clinic” ਬਣਾਉ — ਅਤੇ ਆਦਿ। ਢਾਂਚਾ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਮੁੱਢਲੇ ਪਾਸੇ ਨੂੰ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਨਾ ਕਰੋ।\n- ਹਰ ਸਕਰੀਨ ਲਈ ਡੇਟਾ ਕੰਟਰੈਕਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਹਰ ਸਕਰੀਨ ਲਈ ਇਨਪੁਟ (ਫਾਰਮ, ਫਿਲਟਰ), ਆਊਟਪੁਟ (ਟੇਬਲ, ਕਾਰਡ), ਅਤੇ ਨਿਯਮ (ਲਾਜ਼ਮੀ ਫੀਲਡ, ਵੈਲੀਡੇਸ਼ਨ, ਰੋਲ ਅਨੁਸਾਰ ਦਿੱਖ) ਦੀ ਲਿਸਟ ਬਣਾਓ।\n- ਯੋਜਨਾ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਮੁੱਖ ਗਲਤੀ ਟੈਕਸਟ ਪਹਿਲਾਂ ਲਿਖੋ। ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੁਝ ਹਾਲਤਾਂ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ ਜਿਵੇਂ ਕਿਸੇ ਨੇ ਕੈਪ ਪਾਰ ਕੀਤਾ, ਅਨੁਮਤੀ ਨਾਹ ਹੋਵੇ, ਜਾਂ ਬਿਲਿੰਗ ਦੀ ਲੋੜ ਹੋਵੇ। ਸਪੱਸ਼ਟ ਸੁਨੇਹੇ ਅਤੇ ਅਗਲਾ ਕਦਮ (ਅਪਗ੍ਰੇਡ, ਅਕਸੈੱਸ ਦੀ ਮੰਗ, ਮੁੜ ਕੋਸ਼ਿਸ਼, ਸਪੋਰਟ ਸੰਪਰਕ) ਡਰਾਫਟ ਕਰੋ।\n- ਡੈਮੋ ਖਾਤੇ ਨਾਲ ਪੂਰੀ ਯਾਤਰਾ ਟੈਸਟ ਕਰੋ। ਰੋਲ-ਭਰਤੋੰ ਲਈ ਇੱਕ ਖਾਤਾ ਬਣਾਓ ਅਤੇ end-to-end ਕਲਿੱਕ ਕਰੋ: ਸਾਈਨ ਅਪ, ਓਨਬੋਰਡਿੰਗ, ਇੱਕ ਅਸਲੀ ਰਿਕਾਰਡ ਬਣਾਓ, ਯੂਜ਼ਰ ਨਿਯੋਤਾ, ਸੀਮਾ ਹਿੱਟ ਕਰੋ, ਆਡਿਟ/ਸਹਾਇਤਾ ਚੈੱਕ ਕਰੋ, ਅਤੇ ਇੱਕ ਗਲਤੀ ਤੋਂ ਵਾਪਸੀ ਕਰੋ।\n\nਉਦਾਹਰਨ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਛੋਟੇ CRM ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ “Sales Rep” ਡੈਮੋ ਯੂਜ਼ਰ ਬਣਾਓ ਜੋ ਸੰਪਰਕ ਜੋੜ ਸਕਦਾ ਹੈ ਪਰ ਡਾਟਾ ਨਿਰਯਾਤ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਯਕੀਨੀ ਬਣਾਓ UI ਦੱਸਦਾ ਹੈ ਕਿ ਨਿਰਯਾਤ ਕਿਉਂ ਰੋਕਿਆ ਗਿਆ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕਿਹੜਾ ਹੈ।\n\n## ਆਮ ਫੰਸੇ ਜਿਹੜੇ ਟੀਮਾਂ ਨੂੰ ਧੀਮੀ ਕਰਦੇ ਹਨ\n\nਜ਼ਿਆਦਾਤਰ ਦੇਰੀਆਂ ਮੁਸ਼ਕਲ ਕੋਡਿੰਗ ਤੋਂ ਨਹੀਂ ਆਉਂਦੀਆਂ। ਉਹ ਫੈਸਲਿਆਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਅਣਨਿਰਧਾਰਤ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਜਦ ਤੱਕ UI ਪਹਿਲਾਂ ਹੀ ਬਣ ਚੁੱਕੀ ਹੋਵੇ। ਜੇ ਇਹ ਬਲੂਪ੍ਰਿੰਟ ਸਮਾਂ ਬਚਾਉਣਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਕੁਝ ਸਮਝੌਤੇ ਕਰਨੇ ਪੈਣਗੇ।\n\nਟੀਮਾਂ ਅਕਸਰ ਇੱਕੋ ਹੀ ਖੱਡ ਵਿੱਚ ਪੈਂਦੀਆਂ ਹਨ:\n\n- ਸਕਰੀਨਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਪਹਿਲਾਂ, ਫਿਰ ਰੋਲ ਅਤੇ ਯੋਜਨਾ ਸੀਮਾਵਾਂ ਫਿਕਸ ਕਰਨਾ ਬਾਅਦ ਵਿੱਚ, ਜੋ ਰੀਵਰਕ ਕਰਨਾ ਪੈਦਾ ਹੈ ਜਦੋਂ ਪਹੁੰਚ ਨਿਯਮ ਬਦਲਦੇ ਹਨ ਜਾਂ ਫੀਚਰ ਪੇਡਵਾਲ ਕੀਤਾ ਜਾਣਾ ਹੈ।\n- ਮਹੱਤਵਪੂਰਨ ਸੈਟਿੰਗਸ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਪੇਜ਼ਾਂ 'ਤੇ ਫੈਲਾਉਣਾ, ਤਾਂ ਕੋਈ ਵੀ ਆਸਾਨੀ ਨਾਲ ਖੋਜ ਨਾ ਕਰ ਸਕੇ — ਨੋਟিফਿਕੇਸ਼ਨ, ਸੁਰੱਖਿਆ, ਜਾਂ ਡੇਟਾ ਨਿਰਯਾਤ ਵਰਗੀਆਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ।\n\n- ਬਹੁਤ ਸਾਰੇ ਰੋਲ ਬਣਾਉਣਾ ਜਿਨ੍ਹਾਂ ਦੇ ਨਾਮ ਅਸਪੱਸ਼ਟ (Owner, Super Admin, Admin+, Power User) ਹਨ, ਜਿਸ ਨਾਲ ਹਰ ਪਰਮੀਸ਼ਨ ਫੈਸਲੇ ਤੇ ਦਾਅਵੇ ਹੋ ਜਾਂਦੇ ਹਨ।\n\n- ਖਾਲੀ, ਲੋਡਿੰਗ, ਅਤੇ ਗਲਤੀ ਸਥਿਤੀਆਂ ਨੂੰ “ਬਾਅਦ” ਲਈ ਛੱਡ ਦੇਣਾ, ਫਿਰ ਇੱਕ ਐਸਾ ਉਤਪਾਦ ਭੇਜਨਾ ਜੋ ਡੇਟਾ ਨਾ ਹੋਣ 'ਤੇ ਜਾਂ ਬੇਨਤੀ ਫੇਲ ਹੋਣ 'ਤੇ ਟੁੱਟਿਆ ਹੋਇਆ ਦਿਖਦਾ ਹੈ।\n\n- ਐਡਮਿਨ ਕੰਟਰੋਲ ਅਤੇ ਐਂਡ-ਯੂਜ਼ਰ ਪਸੰਦਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣਾ, ਤਾਂ ਆਮ ਯੂਜ਼ਰ ਡਰਾਉਣੇ ਵਿਕਲਪ ਵੇਖਦੇ ਹਨ ਅਤੇ ਐਡਮਿਨ ਘੰਟਿਆਂ ਬਰਬਾਦ ਕਰਦੇ ਹਨ।\n\nਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਮਦਦ ਕਰਦਾ ਹੈ: ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਯੂਜ਼ਰ ਕੋਲ ਕੋਈ ਡੇਟਾ ਨਹੀਂ, ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ, ਇੰਟਰਨੈਟ ਨਹੀਂ, ਜਾਂ ਕੋਈ ਕਰੈਡਿਟ ਨਹੀਂ — ਪਹਿਲਾਂ।\n\nਉਦਾਹਰਨ: ਇੱਕ CRM ਵਿੱਚ, ਪਹਿਲਾਂ ਸਹਿਮਤ ਹੋ ਜਾਓ ਕਿ Sales ਸਿਰਫ਼ ਆਪਣੀਆਂ ਡੀਲਾਂ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹਨ, Managers ਟੀਮ ਰਿਪੋਰਟ ਵੇਖ ਸਕਦੇ ਹਨ, ਅਤੇ Owners ਬਿੱਲਿੰਗ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੇ ਹਨ। ਫਿਰ ਸੈਟਿੰਗਸ ਨੂੰ “ਮੇਰਾ ਪ੍ਰੋਫਾਈਲ” vs “ਵਰਕਸਪੇਸ ਐਡਮਿਨ” ਵਿੱਚ ਵੰਡੋ, ਅਤੇ ਤੁਹਾਡੇ ਬਿਲਿੰਗ ਸਕਰੀਨ ਸੀਮਾ ਸੁਨੇਹੇ ਸਪੱਸ਼ਟ ਦਿਖਾਉਣਗੀਆਂ ਨਾ ਕਿ ਹੈਰਾਨੀ ਵਾਲੀਆਂ ਗਲਤੀਆਂ।\n\nਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode 'ਚ ਇਹ ਨਿਯਮ ਲਿਖਣਾ ਪਹਿਲਾਂ ਹੀ ਜਨਰੇਟਿੰਗ ਸਕਰੀਨਾਂ ਦੇ ਸਮੇਂ ਰੀਵਰਕ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।\n\n## MVP-ਤਕ ਪੁਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ\n\nਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਨਵੇਂ ਗਾਹਕ ਵਾਂਗ ਇੱਕ ਤੇਜ਼ ਵਾਕ-ਥ੍ਰੂ ਕਰੋ। ਸਿਰਫ਼ UI ਜੋ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਤੇ ਕਲਿੱਕ ਕਰੋ। ਜੇ ਤੁਹਾਨੂੰ ਕਿਸੇ ਛੁਪੇ URL, ਡੇਟਾਬੇਸ ਟਿੱਕ, ਜਾਂ “ਐਡਮਿਨ ਨੂੰ ਪੁੱਛੋ” ਦੀ ਲੋੜ ਪਈ, ਤਾਂ ਤੁਹਾਡਾ MVP ਤਿਆਰ ਨਹੀਂ।\n\nਇਸ ਚੈੱਕਲਿਸਟ ਨਾਲ ਆਮ ਖਾਮੀਆਂ ਪੰਜਾਬ ਕਰੋ ਜੋ ਇਹ ਬਲੂਪ੍ਰਿੰਟ ਰੋਕਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ:\n\n- ਕੀ ਤੁਸੀਂ ਹਰ ਕੋਰ ਸਕਰੀਨ ਤੱਕ ਇੱਕ ਸਪੱਸ਼ਟ ਮਾਰਗ (ਮੇਨੂ, ਪ੍ਰੋਫਾਈਲ ਮੈਨੂ, ਜਾਂ ਇੱਕ obvious ਬਟਨ) ਰਾਹੀਂ ਪਹੁੰਚ ਸਕਦੇ ਹੋ, ਜਿਸ ਵਿੱਚ ਬਿਲਿੰਗ, ਸਹਾਇਤਾ ਅਤੇ ਆਡਿਟ ਵਰਗੀਆਂ “ਬੋਰੀਂ” ਸਕਰੀਨਾਂ ਵੀ ਸ਼ਾਮਲ ਹਨ?\n- ਕੀ ਸਾਰੇ ਫਾਰਮ ਹਕੀਕਤੀ ਉਤਪਾਦਾਂ ਵਾਂਗ ਵਰਤਦੇ ਹਨ: ਸਪੱਸ਼ਟ ਫੀਲਡ ਗਲਤੀਆਂ, ਸਫਲਤਾ ਪੁਸ਼ਟੀ, ਅਤੇ ਮਦਦਗਾਰ ਅਸਫਲਤਾ ਸੁਨੇਹਾ ਜੋ ਅਗਲਾ ਕਦਮ ਦੱਸਦਾ ਹੈ?\n- ਕੀ ਯੋਜਨਾ ਅਤੇ ਯੂਸੇਜ ਸੀਮਾਵਾਂ ਪਹਿਲਾਂ ਹੀ ਦਿੱਸਤੀਆਂ ਹਨ (ਅਪਗਰੇਡ ਪੇਜ਼, ਸੈਟਿੰਗਸ, ਅਤੇ ਕਾਰਵਾਈ ਦੇ ਨੇੜੇ), ਨਾ ਕਿ ਸਿਰਫ਼ ਉਹਨਾਂ ਸਮੇਂ ਜਦੋਂ ਉਪਭੋਗੀ ਰੁਕਦਾ ਹੈ?\n- ਕੀ ਐਡਮਿਨ-ਕੇਵਲ ਕਾਰਵਾਈਆਂ ਸਪੱਠ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲੇਬਲ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਅਤੇ ਪਰਮੀਸ਼ਨ ਨਾਲ ਸੁਰੱਖਿਅਤ ਹਨ (UI ਨੂੰ ਲੁਕਾਉਣਾ ਸੁਰੱਖਿਆ ਨਹੀਂ)?\n- ਕੀ ਤੁਹਾਡੇ ਕੋਲ مکمل unhappy paths ਹਨ: ਖਾਲੀ ਸਥਿਤੀਆਂ, ਲੋਡਿੰਗ ਸਥਿਤੀਆਂ, ਅਤੇ ਗਲਤੀ ਸਕਰੀਨਾਂ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਅੱਗੇ ਵਧਣ ਦਿੰਦੀਆਂ ਹਨ?\n\nਇੱਕ ਸਧਾਰਣ ਟੈਸਟ: ਨਵਾਂ ਖਾਤਾ ਬਣਾਓ, ਫਿਰ ਦੂਜਾ ਯੂਜ਼ਰ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਰੋਲ ਬਦਲੋ, ਅਤੇ ਡੇਟਾ ਨਿਰਯਾਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਸਭ ਕੁੱਝ ਬਿਨਾਂ ਗੁੰਝਲਦਾਰੀ ਦੇ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਪਰਮੀਸ਼ਨ ਸੰਭਵਤ: ਠੀਕ ਹਨ।\n\n## ਉਦਾਹਰਨ: 12 ਸਕਰੀਨਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਣ CRM ਐਪ 'ਤੇ ਲਾਗੂ ਕਰਨਾ\n\nਇੱਕ ਸਥਾਨਕ ਸੇਵਾਵਾਂ ਕੰਪਨੀ ਲਈ ਇਕ ਛੋਟਾ CRM ਸੋਚੋ। ਇਹ ਲੀਡ, ਸੰਪਰਕ, ਅਤੇ ਡੀਲ ਟਰੈਕ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਤਿੰਨ ਰੋਲ ਹਨ: Owner, Sales, ਅਤੇ Support.\n\nਦਿਨ 1 ਆਮ ਤੌਰ 'ਤੇ ਇੱਕੋ ਹੀ ਸਾਂਝੇ ਸਕਰੀਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਭਾਵੇਂ ਡੇਟਾ ਮਾਡਲ ਸਧਾਰਨ ਹੋਵੇ:\n\n- Auth: login, sign up, ਅਤੇ password reset ਤਾਂ ਨਵੇਂ ਕਰਮਚਾਰੀ ਬਿਨਾਂ ਐਡਮਿਨ ਮਦਦ ਦੇ ਅੰਦਰ ਆ ਸਕਣ।\n- Onboarding ਅਤੇ profile: ਇੱਕ ਛੋਟਾ “Company name ਅਤੇ timezone” ਕਦਮ, ਫਿਰ ਨਾਮ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਪਸੰਦਾਂ ਸੈੱਟ ਕਰਨ ਲਈ ਪ੍ਰੋਫਾਈਲ ਸਕਰੀਨ।\n- Users ਅਤੇ roles: ਯੂਜ਼ਰ ਨਿਯੋਤਾ ਭੇਜੋ, ਮੈਂਬਰ ਲਿਸਟ, ਅਤੇ ਰੋਲ ਐਡੀਟਰ (Owner ਬਿੱਲਿੰਗ ਅਤੇ ਰੋਲ ਦੀ ਸੰਭਾਲ ਕਰਦਾ, Sales ਡੀਲ ਸੋਧਦਾ, Support ਵੇਖਦਾ ਅਤੇ ਟਿੱਪਣੀ ਕਰਦਾ)।\n- Settings: ਕੰਪਨੀ ਸੈਟਿੰਗਸ (pipeline stages, email templates), ਅਤੇ ਨਿੱਜੀ ਸੈਟਿੰਗਸ (ਥੀਮ, ਨੋਟੀਫਿਕੇਸ਼ਨ)।\n- Billing ਅਤੇ limits: ਯੋਜਨਾਵਾਂ ਪੇਜ਼ ਅਤੇ ਇੱਕ ਯੂਸੇਜ ਸਕਰੀਨ ਜੋ ਸੀਟਾਂ ਅਤੇ ਸੰਪਰਕ ਗਿਣਤੀ ਦਿਖਾਉਂਦਾ ਹੈ।\n\nਇੱਕ ਹਕੀਕਤੀ ਯੋਜਨਾ ਨਿਯਮ: Pro ਯੋਜਨਾ 5 ਸੀਟਾਂ ਅਤੇ 2,000 ਸੰਪਰਕ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ Owner 6ਵਾਂ ਯੂਜ਼ਰ ਨਿਯੋਤਾ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਸਪੱਸ਼ਟ ਸੀਮਾ ਸਥਿਤੀ ਦਿਖਾਓ, vague ਗਲਤੀ ਨਹੀਂ:\n\n“Seat limit reached (5/5). Upgrade your plan or remove a member to invite Alex.”\n\nਆਮ ਗਲਤੀ ਵਾਲਾ ਮਾਮਲਾ: Sales ਇੱਕ ਸੰਪਰਕ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਪਰ Support ਕੋਲ ਉਸ ਸੰਪਰਕ ਨਾਲ ਜੁੜੇ 2 ਖੁਲੇ ਸਪੋਰਟ ਟਿਕਟ ਹਨ। ਕਾਰਵਾਈ ਨੂੰ ਰੋਕੋ ਅਤੇ ਅਗਲਾ ਕਦਮ ਦੱਸੋ:\n\n“Cannot delete contact. This contact is linked to 2 open support tickets. Close the tickets or reassign them, then try again.”\n\nਜੇ ਤੁਸੀਂ ਇਸ ਬਲੂਪ੍ਰਿੰਟ ਨੂੰ ਚੈਟ-ਅਧਾਰਿਤ ਬਿਲਡਰ ਨਾਲ ਲਾਗੂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਲਗਾਤਾਰਤਾ ਤੇਜ਼ੀ ਜਿੰਨੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। Koder.ai (koder.ai) ਵਿਬੇਧ, Planning Mode ਅਤੇ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਦੀ ਸਮਰਥਾ ਰੱਖਦਾ ਹੈ, ਜੋ ਕਿ ਇਨ੍ਹਾਂ ਸਕਰੀਨ ਪੈਟਰਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜੋੜਦਾ ਹੈ।