ਦਿਨ-ਇੱਕ ਤੋਂ ਬਣੇ ਐਪਾਂ ਲਈ ਨਾਮਕਰਨ ਦੇ ਨਿਯਮ

ਨਾਮਕਰਨ ਕਿਵੇਂ ਤੇਜ਼ੀ ਨਾਲ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ

ਨਾਮਕਰਨ ਦੀਆਂ ਮੁਸ਼ਕਿਲਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਵੱਡੇ ਫੈਸਲੇ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਛੋਟੀ-ਛੋਟੀ ਸ਼ੌਰਟਕੱਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ।

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

ਇਹ ਗੱਲ ਚੈਟ-ਆਧਾਰਿਤ ਉਤਪਾਦਾਂ ਵਿੱਚ ਅਕਸਰ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਲੋਕ ਸਮਾਂ ਦੇ ਨਾਲ ਇਕੋ ਚੀਜ਼ ਨੂੰ ਥੋੜ੍ਹੇ ਬਦਲ ਕੇ ਵਰਣਨ ਕਰਦੇ ਹਨ। ਸੋਮਵਾਰ ਨੂੰ ਇੱਕ ਫਾਉਂਡਰ ਇੱਕ ਭੂਮਿਕਾ ਨੂੰ "manager" ਕਹਿੰਦਾ ਹੈ। ਬੁੱਧਵਾਰ ਨੂੰ ਇੱਕ ਸਾਥੀ "admin" ਵਿਊ ਚਾਹੁੰਦਾ ਹੈ। ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ, ਕੋਈ "team lead" ਜੋੜ ਦਿੰਦਾ ਹੈ। ਜੇ ਕੋਈ ਇਕ ਲੇਬਲ ਚੁਣਨ ਲਈ ਨਹੀਂ ਰੁਕਦਾ, ਤਾਂ ਐਪ ਇੱਕ ਸੰਕਲਪ ਨੂੰ ਕਈ ਵਰਜਨਾਂ ਵਿੱਚ ਵੰਡਣ ਲੱਗਦੀ ਹੈ।

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

ਛੋਟੀ ਟੀਮਾਂ ਇਸਨੂੰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਮਹਿਸੂਸ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਵਿਅਕਤੀ ਹਣੇ ਵੀ ਯਾਦ ਰੱਖ ਸਕਦਾ ਹੈ ਕਿ "approved", "published", ਅਤੇ "live" ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਮਤਲਬ ਦੇਣਾ ਸੀ। ਨਵਾਂ ਸਾਥੀ ਨਹੀਂ ਜਾਣਦਾ। ਉਸਨੂੰ ਇਹ ਅਨੁਮਾਨ ਲਾਉਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਹਰ ਸ਼ਬਦ ਦਾ ਕੀ ਅਰਥ ਹੈ, ਇਹ ਕਿੱਥੇ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਕੀ ਇੱਕ ਲੇਬਲ ਬਦਲਣ ਨਾਲ ਦੂਜੇ ਵੀ ਬਦਲ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

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

ਹੁਣ ਸਾਦੇ ਬਦਲਾਅ ਵੀ ਪਹਿਲਾਂ ਨਾਲੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦੇ ਹਨ। ਇੱਕ ਬਟਨ ਦਾ ਨਾਂ ਬਦਲਣ ਦੀ ਬੇਨਤੀ ਇਕ ਵੱਡੀ ਬਦਲੀ ਬਣ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਬਟਨ ਟੈਕਸਟ ਇੱਕ ਸਥਿਤੀ, ਇੱਕ ਵਰਕਫਲੋ ਕਦਮ, ਅਤੇ ਇੱਕ ਰਿਪੋਰਟ ਫਿਲਟਰ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ।

Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਵਿੱਚ, ਜਿੱਥੇ ਟੀਮਾਂ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਰਾਹੀਂ ਐਪ ਸ਼ੇਪ ਕਰਦੀਆਂ ਹਨ, ਸ਼ਬਦਾਂ ਦੇ ਖਲਾਂ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੇ ਹਨ। ਸਾਫ਼ ਲੇਬਲ ਇਸ ਗੱਲ ਨੂੰ ਆਸਾਨ ਕਰਦੇ ਹਨ ਕਿ ਬਦਲਾਅ ਮੰਗਦੇ ਸਮੇਂ ਅਣਚਾਹੇ ਡੁਪਲਿਕੇਟ ਨਾ ਬਣਨ।

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

ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਦਾ ਨਾਮ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਉਹ ਸ਼ਬਦ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਪਭੋਗਤਾ ਹਰ ਰੋਜ਼ ਵੇਖਣਗੇ, ਉਨ੍ਹਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।

ਵਰਕਫਲੋ ਸ਼ਬਦ ਪਹਿਲਾਂ ਆਉਂਦੇ ਹਨ

ਸਥਿਤੀਆਂ ਨੂੰ ਜਲ्दी ਨਾਂ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਸੂਚੀਆਂ, ਰਿਪੋਰਟਾਂ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਚੁਣੋ, ਜਿਵੇਂ Draft, Active, ਅਤੇ Closed, ਫਿਰ ਹਰ ਇੱਕ ਦਾ ਮਤਲਬ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਜੇ ਇੱਕ ਵਿਅਕਤੀ "Closed" ਕਹਿੰਦਾ, ਦੂਜਾ "Completed" ਅਤੇ ਤੀਜਾ "Done" ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਅਸਮੰਜਸਪਦ ਮਹਿਸੂਸ ਹੋਣ ਲੱਗਦਾ ਹੈ।

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

ਕਾਰਵਾਈਆਂ ਵੀ ਇਤਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। Create, Approve, Assign, Archive, ਅਤੇ Delete ਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ ਚੁਣੋ ਕਿਉਂਕਿ ਇਹ ਉਮੀਦ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ। ਉਦਾਹਰਣ ਲਈ Archive ਅਤੇ Deleteਾਈਕੋ ਹੀ ਅਰਥ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ ਜੇਕਰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਨਹੀਂ ਕਿ ਲੋਕ ਗਲਤੀ ਨਾਲ ਡੇਟਾ ਗੁਆ ਸਕਣ।

ਆਪਣੇ ਮੁੱਖ ਕਿ਼ਯਾਮਤੀ ਵਸਤੂਆਂ ਦੇ ਨਾਮ ਰੱਖੋ

ਤੁਹਾਡੇ ਕੋਰ ਰਿਕਾਰਡਾਂ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਥਿਰ ਨਾਂ ਚਾਹੀਦੇ ਹਨ। ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਐਪ ਕਿਸਨੂੰ ਟਰੈਕ ਕਰਦਾ ਹੈ: orders, leads, accounts, requests, projects, ਜਾਂ ਹੋਰ ਕੁਝ। ਇੱਕੋ ਰਿਕਾਰਡ ਲਈ ਦੋ ਸ਼ਬਦ ਵਰਤਣ ਤੋਂ ਬਚੋ, ਜਿਵੇਂ ਇੱਕ ਮੀਨੂ 'Customer' ਅਤੇ ਦੂਜੇ ਵਿੱਚ 'Account', ਜੇਕਰ ਉਹ ਸੱਚਮੁੱਚ ਵੱਖਰੇ ਅਰਥ ਨਹੀਂ ਰੱਖਦੇ।

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

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

ਨਾਮਕਰਨ ਸਿਸਟਮ ਲਈ ਸਧਾਰਨ ਨਿਯਮ

ਇੱਕ ਨਾਮਕਰਨ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸ਼ਾਨਦਾਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਸਨੂੰ ਸਿਰਫ਼ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਮੁਢਲਾ ਨਿਯਮ ਸਧਾਰਨ ਹੈ: ਇੱਕ ਸੰਕਲਪ, ਇੱਕ ਲੇਬਲ. ਜੇ ਇੱਕ ਸਕਰੀਨ "client" ਕਹਿੰਦੀ ਹੈ, ਦੂਜੀ "customer" ਅਤੇ ਇੱਕ ਪ੍ਰਾਂਪਟ ਬਾਅਦ ਵਿੱਚ "account holder" ਕਹਿੰਦਾ ਹੈ, ਤਾੰ ਲੋਕ ਸ਼ਬਦਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ।

ਉਹ ਸ਼ਬਦ ਚੁਣੋ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਆਮ ਗੱਲਬਾਤ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੀ ਹੈ। ਛੋਟੇ, ਪਰਿਚਿਤ ਲੇਬਲ ਯਾਦ ਰੱਖਣ ਵਿੱਚ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਦੁਹਰਾਉਣ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੇ ਹਨ। "Approved" "administratively validated" ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ। "Manager" ਕਿਸੇ ਚੁਸਤ ਟਾਈਟਲ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਸਮਝਾਉਣ ਲਈ ਕਹਿਣਾ ਪਏ।

ਕਾਰਵਾਈਆਂ ਦੇ ਨਾਮ ਸਾਫ਼ ਕਿਰਿਆਵਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਬਟਨ ਅਤੇ ਮੀਨੂ ਆਈਟਮ ਉਹਨਾਂ ਸਮੇਂ ਵਿਚ ਸਰਬੋਤਮ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਉਪਭੋਗਤਾ ਨੂੰ ਸਪਸ਼ਟ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਹੋਵੇਗਾ: "Create invoice", "Send reminder", "Archive project". ਇਹ GENERATED ਐਪ ਪ੍ਰਾਂਪਟਸ ਵਿੱਚ ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ "Handle" ਜਾਂ "Process" ਵਰਗੇ ਅਸਪਸ਼ਟ ਲੇਬਲਾਂ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਭੁੱਲ-ਭਰਮ ਵਾਲੇ ਅਪਡੇਟ ਆ ਸਕਦੇ ਹਨ।

ਸੰਖਿਆ ਸਟਾਈਲ ਨਾਲ ਵੀ ਇਕਸਾਰ ਰਹੋ। ਸਿੰਗੁਲਰ ਜਾਂ ਪਲੂਰਲ ਇੱਕ ਵਾਰੀ ਚੁਣੋ ਅਤੇ ਪਕੜੇ ਰਹੋ। ਜੇ ਮੇਨੂ 'Orders' ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਇਕ ਥਾਂ 'Order list' ਅਤੇ ਦੂਜੀ 'My order' ਨਾ ਕਰੋ ਜੇਕਰ ਸਪਸ਼ਟ ਕਾਰਨ ਨਾ ਹੋਵੇ।

ਆਖ਼ਰੀ ਨਿਯਮ ਸਭ ਤੋਂ ਵੱਡਾ ਹੈ ਜਿਹਨੂੰ ਟੀਮਾਂ ਅਕਸਰ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ: ਮਹੱਤਵਪੂਰਨ ਸ਼ਬਦਾਂ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਹਰ ਮੁੱਖ ਸ਼ਬਦ ਲਈ ਇੱਕ ਛੋਟੀ ਲਾਈਨ ਲਿਖੋ। ਇੱਕ ਲੀਡ ਕਿਹੜੀ ਗਿਣਤੀ ਹੈ? ਇੱਕ ਆਈਟਮ ਕਦੋਂ "closed" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ? ਇੱਕ ਰਿਵਿਊਅਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ? ਨਵਾਂ ਸਾਥੀ ਸੈਕੰਡਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਾ ਸਮਝ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ Koder.ai ਜਾਂ ਕਿਸੇ ਹੋਰ ਚੈਟ-ਅਧਾਰਿਤ ਟੂਲ ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਇਹ ਨਿਯਮ ਪ੍ਰਾਂਪਟਸ ਨੂੰ ਹੋਰ ਸਥਿਰ ਬਣਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਲੇਬਲ ਇਕਸਾਰ ਰਹਿੰਦੇ ਹਨ, ਐਪ ਵਧਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਅਤੇ ਟੀਮ ਘੱਟ ਸਮਾਂ ਸਪਸ਼ਟੀਕਰਨ 'ਤੇ ਖਰਚ ਕਰਦੀ ਹੈ।

ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਨਿਯਮ ਕਿਵੇਂ ਲਗਾਓ

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

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

ਫਿਰ ਹਰ ਆਈਟਮ ਦੀਆਂ ਸਥਿਤੀਆਂ ਦਾ ਨਾਮ ਰੱਖੋ। ਇੱਕ ਡੀਲ ਇੱਕ ਸਕਰੀਨ 'ਤੇ "Open", ਦੂਜੀ 'ਤੇ "Active" ਅਤੇ ਇੱਕ ਪ੍ਰਾਂਪਟ ਵਿੱਚ "In progress" ਨਾ ਹੋਵੇ ਜੇਕਰ ਉਹੀ ਮਤਲਬ ਹੋਵੇ। ਜੇ ਉਹੀ ਮਤਲਬ ਹੈ, ਇੱਕ ਚੁਣੋ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ।

ਭੂਮਿਕਾਵਾਂ ਲਈ ਵੀ ਉਹੀ ਅਨੁਸ਼ਾਸਨ ਲਗੂ ਕਰੋ। ਆਮ ਸ਼ਬਦ ਵਰਤੋ ਜੋ ਲੋਕ ਪਹਿਲਾਂ ਹੀ ਸਮਝਦੇ ਹਨ, ਜਿਵੇਂ Admin, Manager, Agent, ਜਾਂ Customer. ਨਿਰਾਲੇ ਟਾਈਟਲ ਸ਼ੁਰੂ ਵਿੱਚ ਰੁਚਿਕਰ ਲੱਗ ਸਕਦੇ ਹਨ ਪਰ ਹਨਡਆਫ਼ ਦੌਰਾਨ ਅਧਿਕਾਰ ਵਿਆਖਿਆ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਬਣ ਜਾਂਦੇ ਹਨ।

ਕਾਰਵਾਈਆਂ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਅਸਮੰਜਸ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਚੁਪਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ "create" ਕਰਨਗੇ ਜਾਂ "add", "archive" ਜਾਂ "close", "assign" ਜਾਂ "send". ਬਟਨ ਟੈਕਸਟ, ਮੀਨੂ ਲੇਬਲ ਅਤੇ ਪ੍ਰਾਂਪਟਸ ਇੱਕੋ ਕਿਰਿਆਵਾਂ ਵਰਤਣ ਤਾਂ ਲੋਕ ਜਾਣ ਜਾਣ ਕਿ ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ।

ਇੱਕ ਸਧਾਰਨ ਪਹਿਲੇ ਦਿਨ ਦਾ ਸੈਟਅਪ ਇਹ ਹੋ ਸਕਦਾ ਹੈ:

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

ਇਹ ਨਿਯਮ ਸਾਰੀ ਟੀਮ ਦੇਖ ਸਕਣ ਵਾਲੀ ਇੱਕ ਸਾਂਝੀ ਥਾਂ 'ਤੇ ਰੱਖੋ। ਇੱਕ ਸਫ਼ਾ ਹੀ ਕਾਫੀ ਹੈ ਜੇ ਉਹ ਆਈਟਮ ਨਾਂ, ਮਨਜ਼ੂਰ ਸਥਿਤੀਆਂ, ਰੋਲ ਅਤੇ ਕਾਰਵਾਈਆਂ ਦਿਖਾ ਦੇਵੇ। ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਇਹ ਯੋਜਨਾ ਨੋਟਸ ਵਿੱਚ ਮੁੱਖ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਰਹਿ ਸਕਦੀ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਅਗਲਾ ਪ੍ਰਾਂਪਟ ਲਿਖਣਾ ਆਸਾਨ ਹੋਵੇਗਾ, ਨਵਾਂ ਸਾਥੀ ਘੱਟ ਅਨੁਮਾਨ ਕਰੇਗਾ, ਅਤੇ ਐਪ ਕਮੀ ਘੱਟ ਨਾਲ ਵਧੇਗੀ।

ਇੱਕ ਛੋਟੀ ਟੀਮ ਐਪ ਤੋਂ ਹਕੀਕਤੀ ਉਦਾਹਰਣ

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

ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਨਿਰਦੋਸ਼ ਲੱਗਦਾ ਹੈ। ਫਿਰ ਟੀਮ ਇੱਕ ਸਧਾਰਣ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ: "ਸਾਡੇ ਕੋਲ ਕਿੰਨੇ open tickets ਨੇ?" ਕਿਸੇ ਹੋਰ ਨੇ ਪੁੱਛਿਆ, "ਕੀ ਤੁਸੀਂ ਉਹ requests ਕਹਿ ਰਹੇ ਹੋ ਜੋ review ਦੀ ਉਡੀਕ ਵਿੱਚ ਹਨ, ਜਾਂ ਸਾਰੇ pending ਕੰਮ?" ਇੱਕ ਲੇਬਲ ਦੋ ਮਤਲਬਾਂ ਵਿੱਚ ਵੰਡ ਗਿਆ।

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

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

ਇੱਕ ਛੋਟੀ ਨਾਮਕਰਨ ਸ਼ੀਟ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਠੀਕ ਕਰ ਦਿੰਦੀ ਹੈ ਜਿੰਨੀ ਟੀਮਾਂ ਸੋਚਦੀਆਂ ਹਨ। ਇਹ ਰੁੱਚਕ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੀ। ਇਹ ਸਿਰਫ਼ ਮੁੱਖ ਸ਼ਬਦ ਇਕ ਵਾਰੀ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਉਦਾਹਰਣ ਨਾਮਕਰਨ ਸ਼ੀਟ

• Request: ਐਪ ਵਿੱਚ ਮੁੱਖ ਵਰਕ ਆਈਟਮ
• Pending: ਸਬਮਿਟ ਕੀਤਾ ਗਿਆ ਪਰ ਅਜੇ ਜਾਂਚ ਨਹੀਂ ਹੋ ਰਿਹਾ
• In Review: ਮੈਨੇਜਰ ਦੁਆਰਾ ਵਰਤਮਾਨ ਵਿੱਚ ਜਾਂਚ ਕੀਤਾ ਜਾ ਰਿਹਾ
• Reviewer: ਸਹੀਤਾ ਅਤੇ ਪੂਰਨਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲਾ
• Approver: ਆਖ਼ਰੀ ਹਾਂ ਜਾਂ ਨਾ ਦੇਣ ਵਾਲਾ

ਇਹ ਨਾਂ ਇੱਕ ਵਾਰੀ ਸੈਟ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਭਵਿੱਖੀ ਪ੍ਰਾਂਪਟਸ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। "Add a ticket stage for approval" ਕਹਿਣ ਦੀ ਬਜਾਏ ਟੀਮ ਕਹਿ ਸਕਦੀ ਹੈ, "Move a request from In Review to Approved when the approver confirms it." ਇਸ ਨਾਲ ਅਨੁਮਾਨ ਨਿਕਲ ਜਾਂਦਾ ਹੈ।

ਅਗਲਾ ਹੈਂਡਆਫ਼ ਵੀ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਨਵਾਂ ਵਿਅਕਤੀ ਪੰਜ ਲਾਈਨਾਂ ਪੜ੍ਹ ਕੇ ਸਮਝ ਸਕਦਾ ਹੈ ਕਿ ਐਪ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਬਿਹਤਰ ਨਾਂ ਭਵਿੱਖੀ ਪ੍ਰਾਂਪਟਸ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਦੇ ਹਨ

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

ਇਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਐਪ ਨਾਮਕਰਨ ਨਿਯਮ ਫਾਇਦਾ ਪਾਉਂਦੇ ਹਨ। ਇੱਕ ਪ੍ਰਾਂਪਟ ਜਿਵੇਂ ਕਿ "show manager-only actions for Approved requests" ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਸ਼ਬਦ ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਅਰਥ ਹੈ।

ਉਸ ਸਾਂਝੀ ਵੋਕੈਬਿਊਲਰੀ ਦੇ ਬਗੈਰ, ਪ੍ਰਾਂਪਟ ਤੇਜ਼ੀ ਨਾਲ ਲੰਮੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਸਰੁਕਾਰੀ ਨੋਟਾਂ ਜਿਹੀਆਂ ਸ਼ਰਤਾਂ ਜੋੜਨੀਆਂ ਪੈਂਦੀਆਂ ਹਨ, ਜਿਵੇਂ "manager means the team lead, not the account owner" ਜਾਂ "approved is the final state, not reviewed." ਇਹ ਛੋਟੇ ਸੁਧਾਰ ਕੰਮ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੰਦੇ ਹਨ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਗਲਤ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੇ ਹੋਰ ਮੌਕੇ ਦਿੰਦੇ ਹਨ।

ਸਾਫ਼ ਨਾਂ ਉਸ ਵੇਲੇ ਵੀ ਮਦਦ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸਕਰੀਨ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹੋ। ਜੇ ਐਪ ਹਮੇਸ਼ਾ Draft, In Review, ਅਤੇ Published ਵਰਤਦਾ ਹੈ, ਤਾੰ ਅਗਲੀ ਵਰਜਨ ਉਹਨਾਂ ਲੇਬਲਾਂ ਨੂੰ ਰੱਖਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਹੁੰਦੀ ਹੈ। ਜੇ ਇੱਕ ਸਕਰੀਨ 'Pending' ਦਿਖਾਉਂਦੀ ਅਤੇ ਦੂਜੀ 'Waiting for approval', ਤਾਂ ਬਿਲਡਰ ਉਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਥਿਤੀ ਸਮਝ ਸਕਦਾ ਹੈ ਅਤੇ ਉਸ ਗੁੰਝਲ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣਾਉਂਦਾ ਹੈ।

ਇੱਕ ਨਾਮਕਰਨ ਪ੍ਰਣਾਲੀ ਸਧਾਰਨ ਰਾਉਂਡਾਂ ਨੂੰ ਵੀ ਘਟਾਉਂਦੀ ਹੈ। "staff" ਨੂੰ "agent" ਵਿੱਚ, "done" ਨੂੰ "resolved" ਵਿੱਚ, ਅਤੇ "submit" ਨੂੰ "send request" ਵਿੱਚ ਵੱਖ-ਵੱਖ ਪਾਸਿਆਂ 'ਤੇ ਠੀਕ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਉਹਨਾਂ ਮੌਜੂਦ ਸ਼ਬਦਾਂ 'ਤੇ ਅਧਾਰਿਤ ਨਿਰਮਾਣ ਕਰ ਸਕਦੇ ਹੋ।

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

ਉਦਾਹਰਨ ਲਈ, ਜੇ ਇੱਕ ਸਪੋਰਟ ਐਪ Customer, Agent, ਅਤੇ Admin ਰੋਲਾਂ ਅਤੇ New, Assigned, Waiting on Customer, ਅਤੇ Closed ਸਥਿਤੀਆਂ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਬਾਅਦ ਦੀਆਂ ਡੈਸ਼ਬੋਰਡ, ਫਿਲਟਰ, ਜਾਂ ਮੋਬਾਈਲ ਵਰਜਨ ਦੀਆਂ ਮੰਗਾਂ ਵਿਆਖਿਆ ਕਰਨ ਵਿੱਚ ਕਾਫ਼ੀ ਆਸਾਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। Koder.ai ਵਰਗੇ ਚੈਟ-ਅਧਾਰਿਤ ਬਿਲਡਰਾਂ ਵਿੱਚ ਸਥਿਰ ਭਾਸ਼ਾ ਪਲੇਟਫਾਰਮ ਨੂੰ ਘੱਟ ਗਲਤ ਸਮਝਣ ਦੇ ਮੌਕੇ ਦਿੰਦੀ ਹੈ।

ਆਮ ਗਲਤੀਆਂ ਜਿਹਨਾਂ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਇਹ ਅਕਸਰ ਸੁਮੇਲ ਸ਼ਬਦਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜੋ ਨਿਰਦੋਸ਼ ਲੱਗਦੇ ਹਨ। ਇੱਕ ਸਾਥੀ "approved" ਲਿਖਦਾ ਹੈ, ਦੂਜਾ "accepted", ਤੇ ਤੀਜਾ "confirmed". ਹਰ ਲੇਬਲ ਆਪਣੇ ਆਪ ਵਿੱਚ ਠੀਕ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕਠੇ ਉਹ ਫਿਲਟਰਾਂ, ਰਿਪੋਰਟਾਂ ਅਤੇ ਹੈਂਡਆਫ਼ ਨੂੰ ਔਖਾ ਕਰ ਦਿੰਦੇ ਹਨ।

ਹੋਰ ਇੱਕ ਆਮ ਗਲਤੀ ਅੰਦਰੂਨੀ ਸ਼ਲੈਂਗ ਨੂੰ ਉਤਪਾਦ ਵਿੱਚ ਛੱਡ ਦੇਣਾ ਹੈ। ਸਪੋਰਟ ਟੀਮ "save it to ops" ਜਾਂ "send it to tier two" ਕਹਿ ਸਕਦੀ ਹੈ, ਪਰ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਇਸਦਾ ਕੋਈ ਮਤਲਬ ਨਾਹੀ ਆਉਣ। ਅੰਦਰੂਨੀ ਸ਼ਾਰਟਹੈਂਡ ਨਿੱਜੀ ਨੋਟਸ ਲਈ ਠੀਕ ਹੈ, ਪਰ ਉਪਭੋਗਤਾ-ਸਮ੍ਹਣ ਵਾਲੇ ਲੇਬਲ ਸਧਾਰਨ ਅਤੇ ਸਪਸ਼ਟ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ।

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

ਭੂਮਿਕਾਵਾਂ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਮਿਲ ਜਾਂਦੀਆਂ ਹਨ। "Manager" ਇੱਕ ਅਸਲੀ ਨੌਕਰੀ-ਸਿਰਲੇਖ ਹੋ ਸਕਦਾ ਹੈ, ਜਦਕਿ "Admin" ਇੱਕ ਐਪ ਅਧਿਕਾਰ ਪੱਧਰ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਵਿਅਕਤੀ ਕੰਪਨੀ 'ਚ ਕੌਣ ਹੈ ਅਤੇ ਸਿਸਟਮ 'ਚ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਦੋਹਾਂ ਵਿੱਚ ਫ਼ਰਕ ਹੈ। ਜੇ ਇਹ ਸੋਚਾਂ ਮਿਲ ਜਾਣ, ਤਾਂ ਅਕਸੈੱਸ ਨਿਯਮ ਸਮਝਾਉਣਾ ਅਤੇ ਸੰਭਾਲਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਕਾਰਵਾਈਆਂ ਦੇ ਨਾਮਾਂ ਨੂੰ ਵੀ ਏਨੀ ਹੀ ਸਪਸ਼ਟਤਾ ਚਾਹੀਦੀ ਹੈ। "Process" ਲਿਖਿਆ ਬਟਨ ਬਹੁਤ ਘੱਟ ਦੱਸਦਾ ਹੈ। ਕਿਸ ਨੂੰ process ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ? ਸਪਸ਼ਟ ਕਿਰਿਆਵਾਂ ਜਿਵੇਂ "Approve invoice", "Assign lead", ਜਾਂ "Archive project" ਸੰਦੇਹ ਦੂਰ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।

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

ਇੱਕ ਤੇਜ਼ ਨਾਮਕਰਨ ਚੇਕਲਿਸਟ

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

ਲੇਬਲ ਲਾਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਸਧਾਰਨ ਸਵਾਲ ਪੁੱਛੋ:

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

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

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

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

ਆਪਣੀ ਟੀਮ ਲਈ ਅਗਲੇ ਕਦਮ

ਇੱਕ ਨਾਮਕਰਨ ਪ੍ਰਣਾਲੀ ਸਿਰਫ਼ ਤਦ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ सारी ਟੀਮ ਬਿਨਾਂ ਸੋਚੇ ਇਸਨੂੰ ਵਰਤ ਸਕੇ। ਸਭ ਤੋਂ ਆਸਾਨ ਅਗਲਾ ਕਦਮ ਇੱਕ ਛੋਟੀ ਸੰਦਰਭ ਪੇਜ਼ ਬਣਾਉਣਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਸਾਂਝੇ ਨਿਯਮ-ਕਿਤਾਬ ਵਜੋਂ ਰੱਖਣਾ। ਇਸਨੂੰ ਇਸ ਹੱਦ ਤੱਕ ਸادہ ਰੱਖੋ ਕਿ ਇੱਕ founder, designer, developer, ਜਾਂ ops ਸਾਥੀ ਦੋ ਮਿੰਟ ਵਿੱਚ ਪੜ੍ਹ ਕੇ ਸਮਝ ਸਕੇ।

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

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

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

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

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

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