31 ਦਸੰ 2025·8 ਮਿੰਟ
ਪਰਸੋਨਾ ਅਤੇ ਟਾਸਕ-ਫਲੋ ਸੋਚ: Alan Cooper ਦੀ ਸਧਾਰਣ ਵਿਧੀ
Alan Cooper ਦੀ ਪ੍ਰੇਰਣਾ ਨਾਲ ਪਰਸੋਨਾ ਅਤੇ ਟਾਸਕ-ਫਲੋ ਸੋਚ ਸਿੱਖੋ — ਧੁੰਦਲੇ ਐਪ-ਵਿਚਾਰਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਸਕ੍ਰੀਨਾਂ, ਕਾਰਵਾਈਆਂ ਅਤੇ ਤਰਜੀਹਾਂ ਵਿੱਚ ਬਦਲਣ ਲਈ।
ਕਿਉਂ ਫੀਚਰ ਲਿਸਟਾਂ ਚੰਗੀਆਂ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦੀਆਂ
ਲੰਬੀ ਫੀਚਰ ਸੂਚੀ ਤਰੱਕੀ ਵਰਗੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ ਇਸਤੇ ਨੁਕਤਾ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਕਹਿ ਸਕਦੇ ਹੋ, “ਸਾਨੂੰ ਪਤਾ ਹੈ ਕਿ ਅਸੀਂ ਕੀ ਬਣਾ ਰਹੇ ਹਾਂ।” ਫਿਰ ਤੁਸੀਂ ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਦਾ ਸਕੈਚ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਅਹਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਲਿਸਟ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਯੂਜ਼ਰ ਇਸ ਵੇਲੇ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਉਹ ਕੀ ਮੁਕੰਮਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਜਾਂ ਐਪ ਪਹਿਲਾਂ ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ।
ਫੀਚਰ ਲਿਸਟ ਤਰਜੀਹਾਂ ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ। “Notifications,” “search,” “profiles,” ਅਤੇ “settings” ਸਭ ਮਹੱਤਵਪੂਰਨ ਲੱਗਦੇ ਹਨ, ਇਸ ਲਈ ਸਾਰੀ ਚੀਜ਼ ਇੱਕੋ ਸਤਰ ਉੱਤੇ ਆ ਜਾਂਦੀ ਹੈ। ਇਹ ਇਰਾਦਾ ਵੀ ਛੁਪਾਉਂਦੀਆਂ ਹਨ। ਲੋਕ “filters” ਜਾਂ “admin roles” ਚਾਹੁੰਦੇ ਹੋਏ ਜਾਗਦੇ ਨਹੀਂ। ਉਹ ਇੱਕ ਨਿਯੁਕਤੀ ਬੁੱਕ ਕਰਨਾ, ਪੈਸਾ ਲੈਣਾ, ਡਿਲਿਵਰੀ ਟਰੈਕ ਕਰਨੀ ਜਾਂ ਪਰਿਵਾਰ ਨਾਲ ਫੋਟੋ ਸਾਂਝੀ ਕਰਨੀ ਚਾਹੁੰਦੇ ਹਨ।
ਇਸ ਲਈ ਫੀਚਰ ਲਿਸਟ ਬਨਾਮ ਉਪਭੋਗਤਾ ਦੇ ਲਕਸ਼ ક્યાં ਸਿਰਫ ਯੋਜਨਾ-ਵਿਵਾਦ ਨਹੀਂ ਹੈ। ਇਹ ਸਕ੍ਰੀਨਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜੇ ਲਕਸ਼ “ਸ਼ੁੱਕਰਵਾਰ ਲਈ ਹੇਅਰਕਟ ਬੁੱਕ ਕਰੋ” ਹੈ, ਤਾਂ ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਨੂੰ ਸਮਾਂ-ਸਲਾਟ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ اگਲਾ ਕਦਮ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਦਸ ਫੀਚਰਾਂ ਵਾਲਾ ਮੇਨੂ।
ਫੀਚਰ ਲਿਸਟ ਟੀਮਾਂ ਨੂੰ UI 'ਤੇ ਬਹੁਤ ਜਲਦੀ ਬਹਿਸ ਵਿੱਚ ਖਿੱਚ ਲੈਂਦੀ ਹੈ। ਲੋਕ ਬਟਨ ਦੀ ਪੋਜ਼ੀਸ਼ਨ, ਟੈਬ ਨਾਮ, ਡਾਰਕ ਮੋਡ ਅਤੇ settings ਪੇਜਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਤਕਰਾਉਂਦੇ ਹਨ। ਇਹ ਚੋਣਾਂ ਠੋਸ ਲੱਗਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਅਜਿਹੇ ਅਨੁਮਾਨ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਐਪ ਦੀ ਉਸ ਨੌਕਰੀ 'ਤੇ ਸਹਿਮਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਲੈ ਰਹੇ ਹੋ ਜਿਸ ਵਿੱਚ ਇਹ ਕਿਸੇ ਦੀ ਮਦਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਵਧੀਆ ਸ਼ੁਰੂਆਤ ਸਾਦਾ ਹੈ: ਇੱਕ ਅਸਲੀ ਯੂਜ਼ਰ ਚੁਣੋ, ਉਹ ਇੱਕ ਕੰਮ ਚੁਣੋ ਜੋ ਉਹ ਇਕ ਹੀ ਬੈਠਕ ਵਿੱਚ ਮੁਕੰਮਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਕਦਮਾਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਮੁਕੰਮਲ ਤੌਰ 'ਤੇ ਪਹੁੰਚਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਸਕ੍ਰੀਨਾਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਉभरਦੀਆਂ ਹਨ। ਹਰ ਸਕ੍ਰੀਨ ਆਪਣੀ ਜਗ੍ਹਾ ਹਾਸਲ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਫਲੋ ਦੇ ਇੱਕ ਕਦਮ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦੀ ਹੈ।
Alan Cooper ਦਾ ਮੁੱਖ ਵਿਚਾਰ: ਫੀਚਰਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਨਹੀਂ, ਲਕਸ਼ਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਡਿਜ਼ਾਇਨ ਕਰੋ
Alan Cooper ਨੇ ਇੱਕ ਬਦਲਾਅ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ ਜੋ ਅਜੇ ਵੀ ਸਹੀ ਹੈ: ਸਾਫਟਵੇਅਰ ਨੂੰ ਫੀਚਰਾਂ ਦੇ ਢੇਰ ਵਜੋਂ ਨਹੀਂ ਸੋਚੋ, ਸਗੋਂ ਇਕ ਇੰਟਰੈਕਸ਼ਨ ਵਜੋਂ ਸੋਚੋ। ਮਕਸਦ ਇਹ ਨਹੀਂ ਕਿ ਤੁਹਾਡੀ ਐਪ ਕੀ ਕਰ ਸਕਦੀ ਹੈ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਕੀ ਖਤਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਕੀ ਐਪ ਉਸਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਰੁਕਾਵਟ ਨਾਲ ਇਹ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।
ਇਹ ਮਨੋਭਾਵ ਅਕਸਰ Alan Cooper ਇੰਟਰੈਕਸ਼ਨ ਡਿਜ਼ਾਇਨ ਦੇ ਤਹਿਤ ਆਉਂਦਾ ਹੈ: ਇਰਾਦਾ ਅਤੇ ਕ੍ਰਮ 'ਤੱਪ' ਤੇ ਧਿਆਨ ਦਿਓ। ਜੇ ਤੁਸੀਂ ਯਾਤਰਾ ਨੂੰ ਸਪੱਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਸਕ੍ਰੀਨਾਂ ਲਗਭਗ ਖੁਦ ਹੀ ਡਿਜ਼ਾਇਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਨਹੀਂ, ਤਾਂ ਲੰਬੀ ਫੀਚਰ ਲਿਸਟ ਤੁਹਾਨੂੰ ਬਚਾਉਣ ਵਾਲੀ ਨਹੀਂ — ਇਹ ਅਕਸਰ ਗੁੰਝਲ ਪੈਦਾ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਹਰ ਫੀਚਰ ਹੋਰ ਫੈਸਲੇ, ਬਟਨ ਅਤੇ ਐਜ ਕੇਸ ਜੋੜਦਾ ਹੈ।
Cooper ਦਾ ਪ੍ਰੈਕਟਿਕਲ ਟੂਲਕਿਟ ਦੋ ਹਿੱਸਿਆਂ 'ਚ ਹੈ:
- Personas (ਕੌਣ): ਇੱਕ ਖਾਸ ਕਿਸਮ ਦੇ ਯੂਜ਼ਰ ਨੂੰ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਇੰਨਾ ਅਸਲ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਭਵਿੱਖਬਾਣੀ ਕਰ ਸਕੋ ਕਿ ਉਹ ਕੀ ਕਰੇਗਾ।
- Task flows (ਕਿਵੇਂ): ਉਸ ਪਰਸੋਨਾ ਨੂੰ ਇਰਾਦੇ ਤੋਂ ਨਤੀਜੇ ਤੱਕ ਲੈਣ ਵਾਲੇ ਸਭ ਤੋਂ ਘੱਟ ਕਦਮਾਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ।
ਇੱਕ ਫਲੋ ਤੁਹਾਨੂੰ ਉਹ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੀ ਹੈ ਜੋ ਫੀਚਰ ਲਿਸਟ ਵਿਚੋਂ ਟਲਦੇ ਹਨ: ਕਿਹੜਾ ਚੀਜ਼ ਟਾਸਕ ਨੂੰ ਟ੍ਰਿੱਗਰ ਕਰਦੀ ਹੈ, “ਸਫਲਤਾ” ਕਿਵੇਂ ਦਿਖਦੀ ਹੈ, ਯੂਜ਼ਰ ਨੂੰ ਇਸ ਵੇਲੇ ਕੀ ਫੈਸਲਾ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਹਰ ਕਦਮ 'ਤੇ ਤੁਹਾਨੂੰ ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਦੀ ਸਚਮੁਚ ਲੋੜ ਹੈ।
ਭਾਵੇਂ ਤੁਸੀਂ ਚੈਟ-ਅਧਾਰਿਤ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ ਇਹ ਸਪੱਸ਼ਟਤਾ ਚਾਹੀਦੀ ਹੈ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸਕ੍ਰੀਨਾਂ ਜਨਰੇਟ ਕਰੋਗੇ ਜੋ ਮਜਬੂਤ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਇੱਕ ਸੰਤੁਸ਼ਟਿ ਦਾਇਕ ਸ਼ੁਰੂ-ਅੰਤ ਅਨੁਭਵ ਵਿੱਚ ਨਹੀਂ ਜੁੜਦੀਆਂ।
Personas: ਪਹਿਲਾਂ ਲਈ ਇੱਕ ਅਸਲੀ ਯੂਜ਼ਰ ਚੁਣੋ
ਇੱਕ ਪਰਸੋਨਾ ਉਸ ਵਿਅਕਤੀ ਦਾ ਇੱਕ ਛੋਟਾ, ਵਿਸ਼ਵਾਸਯੋਗ ਵਰਣਨ ਹੈ ਜਿਸ ਲਈ ਤੁਸੀਂ ਪਹਿਲਾਂ ਡਿਜ਼ਾਇਨ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਪੂਰਾ ਜੀਵਨਚਰਿਤ੍ਰ ਨਹੀਂ। ਇਹ ਓਹਨਾ ਹੀ ਵੇਰਵਿਆਂ ਨੂੰ ਦਿੰਦਾ ਹੈ ਜਿੰਨਾ ਕਿ ਫੈਸਲੇ ਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਹੈ ਨਾ ਕਿ ਲਗਾਤਾਰ “ਇਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ” ਕਹਿਣਾ ਪਵੇ।
ਲਕਸ਼ ਅਤੇ ਸੰਦਰਭ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਡੈਮੋਗ੍ਰਾਫਿਕਸ ਨਾਲ ਨਹੀਂ। ਉਹੀ “ਬਿਜੀ ਮਾਪੇ” ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਇਸਤੇ ਨਿਰਭਰ ਕਰਕੇ ਕਿ ਉਹ ਕਿੱਥੇ ਹਨ, ਕਿਹੜਾ ਡਿਵਾਈਸ ਹੈ, ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਕਿੰਨਾ ਦਬਾਅ ਹੈ। ਚੰਗੇ ਪਰਸੋਨਾ ਉਤਪਾਦ ਡਿਜ਼ਾਇਨ ਲਈ ਇਹ ਸੀਮਾਵਾਂ ਸਪੱਸ਼ਟ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਤੁਹਾਡੀਆਂ ਸਕ੍ਰੀਨਾਂ ਦਾ ਇੱਕ ਸਪੱਸ਼ਟ ਉਦੇਸ਼ ਹੋਵੇ।
ਜੇ ਤੁਹਾਡਾ ਪਰਸੋਨਾ ਜ਼ਿਆਦਾ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਸਨੂੰ ਮਹਿਸੂਸ ਕਰੋਗੇ। ਇਹ “ਹਰ ਕੋਈ” ਵਰਗਾ ਲੱਗਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਹ ਜ਼ਿਆਦਾਤਰ ਡੈਮੋਗ੍ਰਾਫਿਕਸ ਬਣ ਜਾਦਾ ਹੈ, ਇਹ ਪਸੰਦ-ਨਾਪਸੰਦ ਦੀ ਸੂਚੀ ਬਣਾਂਦਾ ਹੈ ਬਿਨਾਂ ਕਿਸੇ ਸਪੱਸ਼ਟ ਲਕਸ਼ ਦੇ, ਅਤੇ ਇਹ ਸਮਝਾ ਨਹੀਂ ਸਕਦਾ ਕਿ ਇਹ ਵਿਅਕਤੀ ਆਜ ਐਪ ਕਿਉਂ ਵਰਤੇਗਾ।
ਪਰਸੋਨਾ ਨੂੰ ਹਲਕਾ ਰੱਖੋ। ਕੁਝ ਲਾਈਨਾਂ ਕਾਫੀ ਹੁੰਦੀਆਂ ਹਨ:
- ਉਹ ਕੌਣ ਹੈ (ਰੋਲ),
- ਉਹ ਐਪ ਕਦੋਂ ਅਤੇ ਕਿੱਥੇ ਵਰਤਦਾ ਹੈ (ਸੰਦਰਭ),
- ਉਹਦਾ ਸਿਰਫ਼ ਮੁੱਖ ਲਕਸ਼ (ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ),
- ਅੱਜ ਉਸਨੂੰ ਕੀ ਰੋਕਦਾ ਹੈ (ਦਰਦ ਬਿੰਦੂ),
- “ਸਫਲਤਾ” ਕਿਹੜੀ ਦਿਖਦੀ ਹੈ (ਇੱਕ ਸਧਾਰਨ, ਟੈਸਟ ਕਰਨ ਯੋਗ ਜਿੱਤ)।
ਉਦਾਹਰਨ: “Mina, ਇੱਕ ਡੈਂਟਲ ਰਿਸੈਪਸ਼ਨਿਸਟ, ਮਰੀਜ਼ਾਂ ਦੇ ਵਿਚਕਾਰ ਆਪਣੇ ਫੋਨ 'ਤੇ ਵਰਤੀ ਕਰਦੀ ਹੈ। ਉਸਦਾ ਮੁੱਖ ਲਕਸ਼ ਕੱਲ੍ਹ ਦੀਆਂ ਨਿਯੁਕਤੀਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰਨ ਦਾ ਹੈ। ਉਸਦੀ ਰੁਕਾਵਟ ਲੋਕਾਂ ਨੂੰ ਪੁੱਛਣ ਵਿੱਚ ਸਮਾਂ ਗੁਆਂਊਣਾ ਹੈ। ਸਫਲਤਾ ਇੱਕ ਰਿਮਾਈੰਡਰ ਭੇਜਣਾ ਅਤੇ ਇੱਕ ਸਾਫ਼ ‘confirmed’ ਸਥਿਤੀ ਨੂੰ ਇਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਦੇਖਣਾ ਹੈ।”
ਇੱਕ ਹੋਰ ਨਿਯਮ: ਪਰਸੋਨਾ ਇੱਕ ਡਿਜ਼ਾਇਨ ਟੂਲ ਹੈ, ਆਈਡੀਆਲ ਕਸਟਮਰ ਪ੍ਰੋਫਾਈਲ ਨਹੀਂ। ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਦਰਸ਼ਕ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਹੁਣ ਇੱਕ ਪ੍ਰਾਥਮਿਕ ਪਰਸੋਨਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਲੋਕ ਕਿਸੇ ਸਕ੍ਰੀਨ ਬਾਰੇ ਬਹਿਸ ਕਰਦੇ ਹਨ, ਤਾਂ ਗੱਲ ਨੂੰ Mina ਵੱਲ ਲੈ ਜਾਓ: ਕੀ ਇਹ ਉਸਨੂੰ ਉਸਦੇ ਸੱਚੇ ਸੰਦਰਭ 'ਚ ਉਸਦਾ ਲਕਸ਼ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਜਾਂ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਹੋਰ ਫੀਚਰ ਹੈ?
ਟਾਸਕ ਫਲੋ: ਉਹ ਕਦਮ ਨਕਸ਼ਾ ਬਣਾਓ ਜੋ ਮਿਆਨ ਰੱਖਦੇ ਹਨ
ਇੱਕ ਟਾਸਕ ਫਲੋ ਉਹ ਘੱਟੋ-ਘੱਟ ਕਦਮਾਂ ਦਾ ਸੈੱਟ ਹੈ ਜੋ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਲਕ਼ਸ਼ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਸਾਈਟਮੈਪ, ਫੀਚਰ ਲਿਸਟ ਜਾਂ ਪੂਰੇ ਜਰਨੀ ਮੈਪ ਨਾ ਸਮਝੋ। ਇਹ “ਮੈਂ X ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ” ਤੋਂ “X ਮੁਕੰਮਲ ਹੋ ਗਿਆ” ਤੱਕ ਇਕ ਰਸਤਾ ਹੈ।
ਇੱਕ ਵਧੀਆ ਫਲੋ ਇੱਕ ਟ੍ਰਿੱਗਰ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਫਲਤਾ ਸਥਿਤੀ 'ਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ। ਟ੍ਰਿੱਗਰ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਾਉਂਦਾ ਹੈ: ਇੱਕ ਲੋੜ, ਇੱਕ ਸੁਨੇਹਾ, ਇੱਕ ਬਟਨ, ਜਾਂ ਇੱਕ ਸਮੱਸਿਆ। ਸਫਲਤਾ ਸਥਿਤੀ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਹੈ: “ਨਿਯੁਕਤੀ ਬੁੱਕ ਹੋ ਗਈ ਅਤੇ ਪੁਸ਼ਟੀ ਹੋ ਗਈ,” “ਇਨਵਾਇਸ ਭੇਜ ਦਿੱਤਾ ਗਿਆ,” ਜਾਂ “ਪਾਸਵਰਡ ਬਦਲ ਗਿਆ ਅਤੇ ਮੈਂ ਸਾਇਨ ਇਨ ਹਾਂ।” ਜੇ ਤੁਸੀਂ ਦੋਹਾਂ ਨੂੰ ਇੱਕ-ਇੱਕ ਵਾਕ ਵਿੱਚ ਵਰਣਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਫਲੋ ਅਜੇ ਭੇਦਭਰੇ ਪਾਸੇ ਹੈ।
ਸ਼ੁਰੂ, ਅੰਤ, ਅਤੇ ਦਰਮਿਆਨੀ ਫੈਸਲੇ
ਜ਼ਿਆਦਾਤਰ ਫਲੋ ਸਧਾਰਨ ਹੁੰਦੇ ਹਨ ਜਦ ਤੱਕ ਕਿਸੇ ਫੈਸਲੇ ਨੇ ਰਾਹ 'ਚ ਨਹੀਂ ਆਉਂਦਾ। ਫੈਸਲੇ ਉਹ ਫੋਰਕ ਹਨ ਜੋ ਅੱਗੇ ਕੀ ਹੁੰਦਾ ਹੈ ਬਦਲ ਦਿੰਦੇ ਹਨ, ਜਿਵੇਂ “ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਇੱਕ ਖਾਤਾ ਹੈ?” ਜਾਂ “ਕੀ ਇਹ ਆਈਟਮ ਸਟਾਕ ਵਿੱਚ ਹੈ?” ਇਹ ਫੋਰਕ ਪਹਿਲਾਂ ਹੀ ਕਾਲ ਆਉਣ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਪرفੈਕਟ ਹੈਪੀ ਪਾਥ ਤਿਆਰ ਕਰਨ ਤੋਂ ਬਚਾ ਲੈਂਦੇ ਹੋ ਜੋ ਅਸਲ ਜਿੰਦਗੀ ਦੇ ਸਮਨੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
ਫਲੋ ਨੂੰ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਸੋਚੇ-ਵਿਚਾਰੇ ਸੰਵਾਰਣ ਲਈ ਪੰਜ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ:
- ਟਾਸਕ ਕੀ ਚੀਜ਼ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ?
- ਇਕੱਲਾ ਸਫਲਤਾ ਮੋਮੈਂਟ ਕੀ ਹੈ?
- ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਲਾਜ਼ਮੀ ਹੈ (ਅਤੇ ਕਿਹੜੀ ਵਿਕਲਪਿਕ)?
- ਕਿਹੜੇ ਫੈਸਲੇ ਰਸਤੇ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ?
- ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਇਹ ਹੋਵੇ ਤਾਂ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਦੇਖਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ?
ਜਿੱਥੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਭਰੋਸਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ
ਲੋਕ ਅਣਿਸ਼ਚਿਤ ਮਹਿਸੂਸ ਕਰਨ 'ਤੇ ਕਾਰਵਾਈ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਤੁਹਾਡਾ ਫਲੋ ਉਹ ਮੁਹੱਈਆ ਸਥਾਨ ਚਿੰਨ੍ਹਤ ਕਰੇ ਜਿੱਥੇ ਭਰੋਸੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਪ੍ਰਗਟਿ, ਸਥਿਤੀ, ਪੁਸ਼ਟੀ ਅਤੇ ਸਪੱਸ਼ਟ ਐਰਰ।
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ “ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਕਰੋ” ਹੈ। ਟ੍ਰਿੱਗਰ: “ਮੈਂ ਲੌਗ ਇਨ ਨਹੀਂ ਕਰ ਸਕਦਾ।” ਸਫਲਤਾ: “ਮੈਂ ਫਿਰ ਆਪਣੇ ਖਾਤੇ ਵਿੱਚ ਵਾਪਸ ਹਾਂ।” ਫੈਸਲਾ: “ਕੀ ਤੁਹਾਨੂੰ ਈਮੇਲ ਤੱਕ ਪਹੁੰਚ ਹੈ?” ਭਰੋਸੇ ਦੇ ਅੰਕ: “ਈਮੇਲ ਭੇਜ ਦਿੱਤੀ ਗਈ,” “ਲਿੰਕ ਮਿਆਦ ਲੰਘ ਗਈ,” “ਪਾਸਵਰਡ ਬਦਲ ਗਿਆ,” “ਤੁਸੀਂ ਸਾਇਨ ਇਨ ਹੋ।” ਜਦੋਂ ਇਹ ਸਾਰੇ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਸਕ੍ਰੀਨਾਂ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਹਰ ਕਦਮ ਲਈ ਇੱਕ ਥਾਂ ਅਤੇ ਇੱਕ ਸੁਨੇਹਾ ਚਾਹੀਦਾ ਹੁੰਦਾ ਹੈ ਜੋ ਸੰਦੇਹ ਦੂਰ ਕਰਦਾ ਹੈ।
ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਤਰੀਕਾ: ਧੁੰਦਲੇ ਵਿਚਾਰ ਤੋਂ ਸਪਸ਼ਟ ਪਹਿਲਾ ਫਲੋ
ਕ੍ਰੈਡਿਟ ਅਤੇ ਰੈਫਰਲ ਨਾਲ ਬਚਤ ਕਰੋ
Jo ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ ਸਾਂਝਾ ਕਰਕੇ ਜਾਂ ਦੋਸਤਾਂ ਨੂੰ ਰੋਕ ਕੇ ਕ੍ਰੈਡਿਟ ਜਿੱਤੋ।
ਜ਼ਿਆਦਾਤਰ ਐਪ-ਵਿਚਾਰ ਨਾਊਅਮ-ਸਭਨਾਂ ਦੇ ਢੇਰ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: ਡੈਸ਼ਬੋਰਡ, ਚੈਟ, ਕੈਲੰਡਰ, ਭੁਗਤਾਨ। ਤੁਰੰਤ ਰਸਤਾ ਇਹ ਹੈ ਕਿ ਵਿਚਾਰ ਨੂੰ ਇੱਕ ਵਾਅਦੇ, ਇੱਕ ਵਿਅਕਤੀ ਅਤੇ ਕਦਮਾਂ ਦੀ ਲੜੀ ਵਿੱਚ ਫੋਰਸ ਕੀਤਾ ਜਾਵੇ।
ਇੱਕ ਵਾਕ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਫਰੰਟ ਪੇਜ 'ਤੇ ਜਾਣ ਸਕੇ। ਇਹ ਐਨਾ ਖਾਸ ਹੋਵੇ ਕਿ ਕੋਈ ਮਨਾਉਣ ਯੋਗ ਹੋ ਜਾਵੇ। ਉਦਾਹਰਨ: “ਆਜ਼ਾਦ ਡਿਜ਼ਾਈਨਰਾਂ ਨੂੰ 2 ਮਿੰਟ ਵਿੱਚ ਸਾਫ ਇਨਵਾਇਸ ਭੇਜਣ ਅਤੇ ਕਾਰਡ ਭੁਗਤਾਨ ਲੈਣ ਵਿੱਚ ਮਦਦ ਕਰੋ ਤਾਂ ਕਿ ਉਹ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਪੈਸਾ ਪ੍ਰਾਪਤ ਕਰਨ।”
ਫਿਰ ਵਰਜ਼ਨ ਇੱਕ ਲਈ ਇੱਕ ਮੁੱਖ ਪਰਸੋਨਾ ਚੁਣੋ। “ਹਰ ਕੋਈ ਨਹੀਂ,” “ਛੋਟੇ ਵਪਾਰ” ਨਹੀਂ। ਇੱਕ ਆਦਮੀ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਇੱਕ ਆਮ ਮੰਗਲਵਾਰ ਨੂੰ ਸੋਚ ਸਕੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਰ ਵਿੱਚ ਤਿੰਨ ਲੋਕਾਂ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਐਸੇ ਵਾਧੂ ਸਕ੍ਰੀਨਾਂ ਜੋੜੋਗੇ ਜੋ ਕਿਸੇ ਦੀ ਵੀ ਮਦਦ ਨਹੀਂ ਕਰਦੀਆਂ।
ਅਗਲਾ, ਪਹਿਲਾਂ ਇੱਕ ਲਕਸ਼ ਚੁਣੋ ਜੋ ਪ੍ਰਧਾਨ ਮੁੱਲ ਬਣਾਉਂਦਾ ਹੈ। “ਆਪਣੇ ਆਪ ਨੂੰ ਸੁਚੱਜਾ ਮਹਿਸੂਸ ਕਰੋ” ਧੁੰਦਲਾ ਹੈ। “ਇਨਵਾਇਸ ਭੇਜੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਵੇਖਿਆ ਗਿਆ” ਸਪੱਸ਼ਟ ਹੈ।
ਇੱਕ ਦੁਹਰਾਊ ਯੋਜਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦੀ ਹੈ:
- ਇੱਕ-ਵਾਕ ਦਾ ਵਾਅਦਾ ਲਿਖੋ (ਕੌਣ + ਨਤੀਜਾ + ਸਮਾਂ/ਮਿਹਨਤ)।
- ਪ੍ਰਾਥਮਿਕ ਪਰਸੋਨਾ ਅਤੇ ਇੱਕ ਮੁੱਖ ਪਾਬੰਦੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਸਮਾਂ, ਡਿਵਾਈਸ, ਕੁਸ਼ਲਤਾ)।
- ਹੈਪੀ ਪਾਥ ਦਾ ਖਰਾਕੀ ਵਰਜਨ ਕਿਰਿਆ-ਸ਼ਬਦਾਂ ਵਿਚ ਖਾਕਾ ਤਿਆਰ ਕਰੋ (choose, enter, review, confirm, pay)।
- 2-3 ਹਕੀਕਤੀ ਨਾਕਾਮੀਆਂ ਜੋੜੋ ਤਾਂ ਜੋ ਫਲੋ ਟੁੱਟੇ ਨਹੀਂ।
ਫਲੋ ਇੱਕ ਸਫੇ 'ਤੇ ਫਿੱਟ ਹੋਣ ਤੱਕ ਹੀ ਫੀਚਰ लਿਸਟ ਲਿਖੋ। ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ ਤਰਜੀਹੀ ਰੱਖੋ: ਕੁਝ ਫੀਚਰ ਜੋ ਕਦਮਾਂ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ, ਨਾਲ ਹੀ ਉਹ ਘੱਟੋ-ਘੱਟ ਚੀਜ਼ ਜੋ ਫੇਲ੍ਹਾਂ ਤੋਂ ਬਚਣ ਲਈ ਲਾਜ਼ਮੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਬਿਲਡ ਟੂਲ ਜਿਵੇਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪਲੈਨਿੰਗ ਮੋਡ ਮਦਦ ਕਰਦਾ ਹੈ। ਵਾਅਦਾ, ਪਰਸੋਨਾ ਅਤੇ ਫਲੋ ਨੂੰ ਇੱਕ ਥਾਂ ਪੇਸਟ ਕਰੋ ਅਤੇ ਟੀਮ ਨੂੰ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਕੋਡ ਤੋਂ ਪਹਿਲਾਂ ਸਧਾਰਿਤ ਰੱਖੋ।
UI 'ਤੇ ਜ਼ਿਆਦਾ ਸੋਚ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਫਲੋ ਨੂੰ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਬਦਲੋ
ਟਾਸਕ ਫਲੋ ਇਕ ਇਰਾਦਿਆਂ ਦੀ ਲੜੀ ਹੈ। ਹੁਣ ਹਰ ਕਦਮ ਨੂੰ ਜਾਂ ਤਾਂ ਇੱਕ ਸਕ੍ਰੀਨ ਵਿੱਚ ਬਦਲੋ ਜਿੱਥੇ ਯੂਜ਼ਰ ਆਉਂਦਾ ਹੈ, ਜਾਂ ਮੌਜੂਦ ਸਕ੍ਰੀਨ ਉੱਤੇ ਇੱਕ ਇਕੱਲੀ ਕਾਰਵਾਈ ਬਣਾਓ।
ਇਹ ਸਿੱਧਾ ਰੱਖੋ: ਇੱਕ ਕਦਮ = ਇੱਕ ਸਪੱਸ਼ਟ ਨਤੀਜਾ। ਜੇ ਇੱਕ ਕਦਮ ਦੇ ਦੋ ਨਤੀਜੇ ਹਨ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਦੋ ਕਦਮ ਹਨ।
ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਮਕਸਦ ਦੇ ਨਾਮ ਦਿਓ, ਲੇਆਉਟ ਦੇ ਹਿੱਸਿਆਂ ਦੇ ਨਹੀਂ। “Pick time” “Calendar screen” ਨਾਲੋ ਵਧੀਆ ਹੈ। “Confirm details” “Form page” ਨਾਲੋਂ ਵਧੀਆ ਹੈ। ਮਕਸਦ-ਨਾਮ ਤੁਹਾਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਨਾ ਕਿ ਇਹ ਕਿ ਇਹ ਕਿਵੇਂ ਦਿਸੇਗਾ।
ਫਲੋ ਨੂੰ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਬਦਲਦਿਆਂ, ਹਰ ਕਦਮ ਲਈ ਤਿੰਨ ਚੀਜ਼ਾਂ ਫੈਸਲ ਕਰੋ: ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਹਨੂੰ ਕੀ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹਨੂੰ ਕੀ ਦਰਜ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਅਗਲਾ ਸਪੱਸ਼ਟ ਕਾਰਵਾਈ ਚੁਣੋ (ਅਮੂਮਨ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਬਟਨ)। ਜੋ ਕੁਝ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਉਸ ਕਦਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦਾ, ਉਹ ਹਟਾਓ।
ਨੈਵੀਗੇਸ਼ਨ ਨਿਰਾਸ਼ਜਨਕ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਹਰ ਸਕ੍ਰੀਨ ਦਾ ਉੱਤਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: “ਮੈਂ ਅਗਲੇ ਕੀ ਕਰਾਂ?” ਜੇ ਕਿਸੇ ਨੂੰ اگਲਾ ਕਦਮ ਪਤਾ ਕਰਨ ਲਈ ਮੇਨੂ ਦੀ ਲੋੜ ਪਏ, ਤਾਂ ਸਕ੍ਰੀਨ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੁਝ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ।
ਸਾਥ ਹੀ साधਾਰਨ ਰਾਜਾਂ ਨੂੰ ਨੋਟਸ ਵਜੋਂ ਕੈਪਚਰ ਕਰੋ, ਨਾ ਕਿ ਪੂਰੇ ਡਿਜ਼ਾਈਨ: ਲੋਡਿੰਗ, ਖਾਲੀ, ਸਫਲਤਾ, ਗਲਤੀ, ਅਤੇ ਕਦੋਂ ਮੁੱਖ ਕਾਰਵਾਈ ਨੂੰ ਅਯੋਗ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਸੀਂ ਟੀਮ ਨੂੰ ਇਹ ස්ਟੇਟ ਯਾਦ ਰੱਖਾਉਣੀ ਹੈ ਨਾ ਕਿ ਰੰਗਾਂ 'ਤੇ ਦਿਨ ਖਰਚ ਕਰਨੇ।
Koder.ai ਵਰਗੇ ਟੂਲ ਤੁਹਾਡੇ ਫਲੋ ਟੈਕਸਟ ਤੋਂ ਸਕ੍ਰੀਨਾਂ ਦਾ ਡਰਾਫਟ ਬਣਾ ਸਕਦੇ ਹਨ, ਪਰ ਸਪੱਸ਼ਟਤਾ ਫਿਰ ਵੀ ਤੁਹਾਡੇ ਕੋਲ ਹੀ ਹੋਵੇਗੀ: ਮਕਸਦ, ਲਾਜ਼ਮੀ ਜਾਣਕਾਰੀ, ਅਤੇ اگਲਾ ਕਾਰਵਾਈ।
ਉਦਾਹਰਨ: “ਬੁਕਿੰਗ ਐਪ” ਨੂੰ ਸੁਚੱਜੀਆਂ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਬਦਲਣਾ
ਅਸਲੀ ਡੈਮੋ ਸਾਂਝਾ ਕਰੋ
ਆਪਣਾ ਪਹਿਲਾ ਫਲੋ ਕਲੀਨ ਡੈਮੋ ਅਤੇ ਫੀਡਬੈਕ ਲਈ ਕਸਟਮ ਡੋਮੇਨ 'ਤੇ ਰੱਖੋ।
ਕਲਪਨਾ ਕਰੋ ਤੁਸੀਂ ਇਕ ਸਧਾਰਣ ਐਪ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਲੋਕਾਂ ਨੂੰ ਇੱਕ ਸਥਾਨਕ ਕਲਾਸ (ਯੋਗਾ, ਟਿਊਸ਼ਨ, ਹੇਅਰਕਟ) ਬੁੱਕ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਂਦੀ ਹੈ। ਇੱਕ ਫੀਚਰ ਲਿਸਟ ਇਹ ਕਹ ਸਕਦੀ ਹੈ “search, calendar, payments, reminders.” ਪਰ ਇਹ ਹਾਲੇ ਵੀ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਪਹਿਲਾ ਸਕ੍ਰੀਨ ਕੀ ਹੋਵੇਗਾ, ਜਾਂ ਕਿਸੇ ਨੇ “Book” 'ਤੇ ਟੈਪ ਕੀਤਾ ਤਾਂ ਅੱਗੇ ਕੀ ਹੁੰਦਾ।
ਇੱਕ ਪਰਸੋਨਾ ਚੁਣੋ: Sam, ਇੱਕ ਬਿਜੀ ਮਾਪਾ ਜੋ parking lot ਵਿੱਚ ਫੋਨ 'ਤੇ 60 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਇੱਕ ਸਲਾਟ ਬੁੱਕ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। Sam ਖਾਤਾ ਬਣਾਉਣਾ, 20 ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨੀ ਜਾਂ ਲੰਬੀ ਵਰਨਨ ਪੜ੍ਹਨਾ ਨਹੀਂ ਚਾਹੁੰਦਾ।
ਹੁਣ ਹੈਪੀ ਪਾਥ ਨੂੰ ਇੱਕ ਛੋਟੇ ਕਹਾਣੀ ਵਜੋਂ ਲਿਖੋ: Sam ਐਪ ਖੋਲ੍ਹਦਾ ਹੈ, ਠੀਕ ਕਲਾਸ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਦਾ ਹੈ, ਸਮਾਂ ਚੁਣਦਾ ਹੈ, ਨਾਮ ਦਰਜ ਕਰਦਾ ਹੈ, ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਪੁਸ਼ਟੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।
ਦੋ ਐਜ ਕੇਸ ਜੋੜੋ: ਜਦੋਂ Sam ਸਮਾਂ 'ਤੇ ਟੈਪ ਕਰਦਾ ਹੈ ਕਲਾਸ ਸੇਲ ਆਉਟ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਭੁਗਤਾਨ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਉਸ ਫਲੋ ਤੋਂ ਨਿਕਲਦੀਆਂ ਸਕ੍ਰੀਨਾਂ ਸਿੱਧੀਆਂ ਹਨ:
- Find a class: ਨੇੜੇ/ਅਗਲੇ ਵਿਕਲਪ, ਸਧਾਰਨ ਦਿਨ/ਸਮਾਂ ਫਿਲਟਰ ਅਤੇ ਸਪਸ਼ਟ ਕਾਰਡ (ਸਿਰਲੇਖ, ਸ਼ੁਰੂ ਸਮਾਂ, ਕੀਮਤ, ਬਾਕੀ ਸਪੇਸ)।
- Class details: ਅਗਲੇ ਉਪਲੱਬਧ ਸਮੇਂ ਪਹਿਲਾਂ, ਮਿਆਦ ਅਤੇ ਸਥਾਨ ਵਰਗੀਆਂ ਮੁਢਲੀ ਜਾਣਕਾਰੀਆਂ, ਅਤੇ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਕਾਰਵਾਈ: ਸਮਾਂ ਚੁਣੋ।
- Pick a time: ਉਪਲੱਬਧ ਸਲਾਟ, ਸਪਸ਼ਟ sold-out ਲੇਬਲ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਤਾਰੀਖ ਬਦਲਣ ਦਾ ਤਰੀਕਾ।
- Your details: ਇੱਕ ਜਾਂ ਦੋ ਫੀਲਡ (ਨਾਮ, ਸ਼ਾਇਦ ਫੋਨ/ਈਮੇਲ ਰਸੀਦ ਲਈ) ਅਤੇ ਅਗਲੇ 'ਤੇ ਜਾਓ ਬਟਨ।
- Payment: ਕੁੱਲ ਕੀਮਤ, ਭੁਗਤਾਨ ਢੰਗ, ਅਤੇ ਇੱਕ ਇਕੱਲਾ ਪੇ-ਕਾਰਵਾਈ।
- Confirmation: ਬੁਕਿੰਗ ਵਿਵਰਣ ਅਤੇ ਇੱਕ اگਲਾ ਕਦਮ (ਕੈਲੰਡਰ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ ਜਾਂ ਬੁਕਿੰਗ ਵੇਖੋ)।
ਜਦੋਂ “sold out” ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਮਾਂ ਪਿਕਰ ਦੇ ਅੰਦਰ ਹੱਲ ਕਰੋ: ਸਪਸ਼ਟ ਭਾਸ਼ਾ 'ਚ ਸਮਝਾਓ, ਨਜ਼ਦੀਕੀ ਹੋਰ ਸਲਾਟ ਸੁਝਾਓ, ਅਤੇ Sam ਨੂੰ ਇੱਕੋ ਸਕ੍ਰੀਨ 'ਤੇ ਰੱਖੋ। ਜਦੋਂ ਭੁਗਤਾਨ ਫੇਲ ਹੋਵੇ, ਦਰਜ ਕੀਤੀ ਜਾਣਕਾਰੀ ਸੰਭਾਲ ਕੇ ਰੱਖੋ, ਨਾਰਮਲ ਭਾਸ਼ਾ 'ਚ ਦੱਸੋ ਕਿ ਕੀ ਹੋਇਆ, ਅਤੇ “ਪੁਨਰ-ਕੋਸ਼ਿਸ਼ ਕਰੋ” ਅਤੇ “ਕੋਈ ਹੋਰ ਢੰਗ ਵਰਤੋ” ਦੇ ਵਿਕਲਪ ਦਿਓ।
ਜੇ ਤੁਸੀਂ ਇਹ Koder.ai ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਫਲੋ ਟੈਕਸਟ ਤੋਂ ਸਕ੍ਰੀਨਾਂ ਜਨਰੇਟ ਕਰਨ ਲਈ ਕਹਿ ਸਕਦੇ ਹੋ, ਫਿਰ ਸ਼ਬਦਬੰਧੀ ਅਤੇ ਫੀਲਡਾਂ ਨੂੰ ਤੱਕ ਤੱਕ ਕਰਕੇ 60-ਸਕਿੰਟ ਵਾਲਾ ਲਕਸ਼ ਅਸਲੀ ਮਹਿਸੂਸ ਹੋਵੇ।
ਫਲੋ ਨੂੰ ਟੂਟਣ ਵਾਲੀਆਂ ਆਮ ਖਾਮੀਆਂ
ਫਲੋ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕਾਰਨ ਕਰਕੇ ਟੁੱਟਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਭੀੜ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰ ਰਹੇ ਹੋ, ਨਾ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਲਈ। ਜਦੋਂ ਪਰਸੋਨਾ “ਹਰ ਕੋਈ” ਹੁੰਦਾ ਹੈ, ਤਾਂ ਹਰ ਫੈਸਲਾ ਇੱਕ ਸਮਝੋਤੇ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਯੂਜ਼ਰ ਗਤੀ ਚਾਹੁੰਦਾ ਹੈ, ਦੂਜਾ ਰਾਹ-ਨਿਰਦੇਸ਼, ਤੀਜਾ ਪੂਰਾ ਕੰਟਰੋਲ। ਨਤੀਜਾ ਇੱਕ ਫਲੋ ਜੋ ਸਭ ਨੂੰ ਪੱਸੰਦ ਨਹੀਂ ਆਉਂਦਾ।
ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਪਰਸੋਨਾ ਨੂੰ ਤਿੰਨ-ਨੂੰ ਘਟਾ ਕੇ ਤੰਗ ਕਰੋ ਜਦ ਤਕ ਚੋਣਾਂ ਸਪਸ਼ਟ ਨਾ ਹੋ ਜਾਣ। ਨਾ “ਬਿਜੀ ਪੇਸ਼ੇਵਰ,” ਪਰ “ਫੋਨ 'ਤੇ ਮਰੀਜ਼ਾਂ ਦੇ ਵਿਚਕਾਰ ਕੰਮ ਕਰਨ ਵਾਲੀ ਰਿਸੈਪਸ਼ਨਿਸਟ,” ਜਾਂ “ਟੁੱਟੇ ਸਕਰੀਨ ਵਾਲਾ ਇੱਕ ਮਾਪਾ ਜੋ ਬੱਚੇ ਲਈ ਹੇਅਰਕਟ ਬੁੱਕ ਕਰ ਰਿਹਾ ਹੈ।” ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦਾ ਦਿਨ ਸੌਚ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਨਿਰਣਾਇ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਕੱਢਣਾ ਹੈ।
ਇਕ ਹੋਰ ਫੇਲ੍ਹ ਮੋਡ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਜੋ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਨਾ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਜੇ ਪਹਿਲਾ ਡਰਾਫਟ ਡੇਟਾਬੇਸ ਫੀਲਡ ਅਤੇ ਆੰਤਰੀਕ ਐਡਮਿਨ ਕਦਮਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੈ, ਤਾਂ ਉਤਪਾਦ ਲੰਬੀਆਂ ਫਾਰਮਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮੁੱਖ ਟਾਸਕ ਦਫਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਲੋਕ “ਖੇਤਰ ਭਰਨ” ਲਈ ਜਾਗਦੇ ਨਹੀਂ; ਉਹ ਇੱਕ ਬੁਕਿੰਗ ਪੁਸ਼ਟੀ ਕਰਨਾ, ਭੁਗਤਾਨ ਕਰਨਾ, ਜਾਂ ਰਿਮਾਈੰਡਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ।
ਤੀਜਾ ਫੰਦਰ “ਐਕਸਟਰਾ ਪਹਿਲਾਂ” ਸੋਚਣਾ ਹੈ। settings, preferences, roles, tags, ਅਤੇ customization ਆਸਾਨੀ ਨਾਲ ਸੂਚੀ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਜਲਦੀ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੇ ਹਨ। ਪਰ ਜੇ ਕੋਰ ਟਾਸਕ ਹਲਕਾ ਹੈ, ਤਾਂ ਐਕਸਟਰਾ ਸਿਰਫ ਹੋਰ ਰਸਤੇ ਅਤੇ ਗਲਬਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਜਲਦੀ ਸਕ੍ਰੀਨਾਂ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹੀ ਖਤਰਾ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਤੇਜ਼ੀ ਤਦ ਤੇ ਕਾਮਯਾਬ ਹੁੰਦੀ ਹੈ ਜਦ ਤੁਹਾਡਾ ਫਲੋ ਸਚਮੁਚ ਇਮਾਨਦਾਰ ਹੋ — ਇੱਕ ਪਰਸੋਨਾ, ਇੱਕ ਲਕਸ਼, ਅਤੇ ਹਰ ਸਕ੍ਰੀਨ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ اگਲਾ ਕਦਮ।
ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼-ਚੈੱਕਲਿਸਟ
ਉਹ ਸਕ੍ਰੀਨਾਂ ਪਾਉ ਜੋ ਜੁੜਦੀਆਂ ਹਨ
Koder.ai ਤੋਂ ਪੁੱਛੋ ਕਿ ਤੁਹਾਡੇ ਟਾਸਕ-ਫਲੋ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਘੱਟੋ-ਘੱਟ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਕਾਰਵਾਈਆਂ ਕੀ ਹਨ।
ਡਿਜ਼ਾਈਨ ਟੂਲ ਖੋਲ੍ਹਣ ਜਾਂ ਕੋਡਿੰਗ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਕ ਪਾਸ ਕਰੋ ਤਾਂ ਕਿ ਯਕੀਨ ਹੋਵੇ ਕਿ ਤੁਹਾਰਾ ਵਿਚਾਰ ਵਾਸਤਵ ਵਿੱਚ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਬਦੱਲ ਸਕਦਾ ਹੈ।
ਤੁਸੀਂ ਪ੍ਰਾਥਮਿਕ ਪਰਸੋਨਾ ਦਾ ਲਕਸ਼ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਾਫ਼-ਸਪਸ਼ਟ ਫਿਨਿਸ਼ ਲਾਈਨ ਦੇ ਸਕਦੇ ਹੋ: “ਸ਼ਨੀਚਰਵਾਰ ਲਈ 11am 'ਤੇ ਹੇਅਰਕਟ ਬੁੱਕ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਪ੍ਰਾਪਤ ਕਰੋ।” ਹੈਪੀ ਪਾਥ ਇੱਕ ਸਫੇ 'ਤੇ ਫਿੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਇਹ ਫੈਲਦਾ ਹੈ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਦੋ ਟਾਸਕ ਮਿਲਾ ਦਿੱਤੇ ਹਨ ਜਾਂ ਇੱਕ ਹੀ ਵਾਰੀ ਲਈ ਅਨੇਕ ਪਰਸੋਨਾ ਦਾ ਹੱਲ ਕਰ ਰਹੇ ਹੋ।
ਜਾਂਚੋ ਕਿ ਹਰ ਸਕ੍ਰੀਨ ਮਕਸਦ ਦੇ ਨਾਮ ਨਾਲ ਨਾਂਕਾਇਆ ਗਿਆ ਹੈ ਅਤੇ ਫਲੋ ਕਦਮ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ (ਮਕਸਦ ਵਿਜਟਸ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ)। ਫੈਸਲੇ ਅਤੇ ਪੁਸ਼ਟੀਆਂ ਸਪੱਸ਼ਟ ਹੋਣ, ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਨਿਰੂਪਤ। ਜੇ ਯੂਜ਼ਰ ਨੂੰ ਚੋਣ ਕਰਨੀ ਹੈ, ਤਾਂ ਚੋਣ ਦਿਖਾਓ। ਜੇ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਹੋਇਆ, ਤਾਂ ਪੁਸ਼ਟੀ ਜਾਂ ਸਪਸ਼ਟ ਗਲਤੀ ਦਿਖਾਓ।
ਫਿਰ ਉਹ ਸਭ ਕੁਝ ਕੱਟੋ ਜੋ ਟਾਸਕ ਨੂੰ ਅੱਗੇ ਨਹੀਂ ਵਧਾਉਂਦਾ। ਜੇ ਇੱਕ ਸਕ੍ਰੀਨ ਯੂਜ਼ਰ ਨੂੰ ਫੈਸਲਾ ਕਰਨ, ਜਾਣਕਾਰੀ ਦਰਜ ਕਰਨ, ਭੁਗਤਾਨ ਕਰਨ ਜਾਂ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ نہیں ਕਰਦੀ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਪਹਿਲੀ ਸੰਸਕਰਣ ਲਈ ਸ਼ੋਰ ਹੈ।
ਫਲੋ ਨੂੰ ਅਲੌਣ-ਅਲੌਣ ਪੜ੍ਹੋ ਜਿਵੇਂ ਇੱਕ ਕਹਾਣੀ: “ਮੈਂ X ਚਾਹੁੰਦਾ ਹਾਂ, ਮੈਂ A ਕਰਦਾ ਹਾਂ, ਫਿਰ B, ਫਿਰ ਮੈਂ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹਾਂ, ਫਿਰ ਮੈਂ ਹੋ ਗਿਆ।” ਜਿੱਥੇ ਵੀ ਤੁਸੀਂ ਹਿਚਕਿਚਾਉਂਦੇ ਹੋ, ਉਹੀ ਡਿਜ਼ਾਇਨ ਸਮੱਸਿਆ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਪਲੈਨਿੰਗ ਮੋਡ ਨੂੰ ਵਰਤੋ ਤਾਂ ਜੋ ਚੈਟ ਵਿੱਚ ਪਰਸੋਨਾ ਅਤੇ ਫਲੋ 'ਤੇ ਦੋਹਰਾਈ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਸਕ੍ਰੀਨਾਂ ਜਨਰੇਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਦਲਾਅਾਂ ਨੂੰ ਪਰਖਣ ਅਤੇ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਵਾਪਸ ਲੈਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਅਗਲੇ ਕਦਮ: ਪਹਿਲੀ ਸੰਸਕਰਣ ਯੋਜਨਾ ਬਣਾਓ ਅਤੇ ਬਿਲਡ ਵੱਲ ਵਧੋ
ਉਹ ਇਕਲੌਤਾ ਫਲੋ ਚੁਣੋ ਜੋ ਸਭ ਤੋਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਰੂਪ ਵਿੱਚ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਪਰਸੋਨਾ ਆਪਣਾ ਲਕਸ਼ ਪਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਆਪਣੀ ਰੀੜ ਦੀ ਹੱਡੀ ਵਜੋਂ ਲਓ। ਬਾਕੀ ਸਭ ਕੁਝ ਵਿਕਲਪਿਕ ਹੈ ਜਦ ਤੱਕ ਇਹ ਅੰਤ-ਤੱਕ ਕੰਮ ਨਾ ਕਰੇ।
ਉਸ ਫਲੋ ਨੂੰ ਇੱਕ ਛੋਟੀ ਬਿਲਡ ਯੋਜਨਾ ਵਿੱਚ ਬਦਲੋ: ਉਹ ਕੁਝ ਸਕ੍ਰੀਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਪਰਸੋਨਾ ਜਾਵੇਗਾ, ਹਰ ਇੱਕ 'ਤੇ ਉਹ ਕਾਰਵਾਈਆਂ ਜੋ ਉਹ ਲੈਂਦਾ ਹੈ, ਸਿਸਟਮ ਨੂੰ ਜੋ ਘੱਟੋ-ਘੱਟ ਡੇਟਾ ਚਾਹੀਦਾ ਹੈ, ਕੁਝ ਫੇਲ੍ਹ ਕੇਸ ਜੋ ਤੁਹਾਨੂੰ ਸੰਭਾਲਣੇ ਹਨ, ਅਤੇ ਸਫਲਤਾ ਦੀ ਸਥਿਤੀ ਜੋ “ਮੁਕੰਮਲ” ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ।
ਹੁਣ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਕੱਟਣਾ ਹੈ। ਕੱਟਣਾ ਖਾਲੀ ਨපੁੰਸਕਪੂਰਕਤਾ ਲਈ ਨਹੀਂ, ਇਹ ਇੱਕ ਮੁੱਖ ਲਕਸ਼ ਨੂੰ ਬੇਹਤਰੀਨ ਤਰੀਕੇ ਨਾਲ ਨਿਰਵਿਘਨ ਬਣਾਉਣ ਲਈ ਹੈ। ਜੇ ਇੱਕ ਫੀਚਰ ਉਸ ਪਰਸੋਨਾ ਨੂੰ ਅੱਜ ਫਲੋ ਮੁਕੰਮਲ ਕਰਨ ਵਿੱਚ ਸਹਾਇਕ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਹ “ਬਾਦ ਵਿੱਚ” ਜਾਂਦਾ ਹੈ।
ਯੋਜਨਾ ਨੂੰ ਪਰਖੋ: ਪਰਸੋਨਾ ਵਰਣਨ ਪੜ੍ਹੋ, ਫਿਰ ਕਦਮਾਂ ਰਾਹੀਂ ਉਸਦੀ ਤਰ੍ਹਾਂ ਚੱਲੋ। ਜਦੋਂ ਕਮੀ ਹੋਵੇ, ਉਹ ਜਲਦੀ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ: ਤਾਰੀਖ ਕਿੱਥੋਂ ਆਈ? ਮੈਂ ਆਪਣੀ ਚੋਣ ਕਿਵੇਂ ਬਦਲ ਸਕਦਾ ਹਾਂ? ਜੇ ਮੈਂ ਗਲਤੀ ਕਰਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਪਲੈਨਿੰਗ ਮੋਡ ਵਰਤ ਕੇ ਚੈਟ ਵਿੱਚ ਪਰਸੋਨਾ ਅਤੇ ਫਲੋ 'ਤੇ ਦੁਹਰਾਓ, ਫਿਰ ਸਕ੍ਰੀਨਾਂ ਜਨਰੇਟ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰੋ, snapshot ਅਤੇ rollback ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੁਹਾਨੂੰ ਟੈਸਟ ਕਰਨ ਅਤੇ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਸੁਰਤਲਾਪੂਰਵਕ ਪਿੱਛੇ ਮੁੜਣ ਦੀ ਆਜ਼ਾਦੀ ਦੇਣਗੀਆਂ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
Why doesn’t a detailed feature list help me design the first screen?
ਇੱਕ ਫੀਚਰ ਲਿਸਟ ਤੁਹਾਨੂੰ ਕੀ ਮੌਜੂਦ ਹੈ ਦੱਸਦੀ ਹੈ, ਨਾ ਕਿ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਹੁੰਦਾ ਹੈ. ਇਹ ਤਰਜੀਹਾਂ ਨੂੰ ਸਮਾਨ ਕਰ ਦਿੰਦੀ ਹੈ (ਸਾਰੀ ਚੀਜ਼ ਮਹੱਤਵਪੂਰਨ ਲੱਗਦੀ ਹੈ) ਅਤੇ ਉਪਭੋਗਤਾ ਦੀ ਨੀਅਤ ਨੂੰ ਛੁپا ਲੈਂਦੀ ਹੈ.
شروع ਕਰੋ ਇੱਕ ਉਪਭੋਗਤਾ ਲਕਸ਼ ਨਾਲ ਜਿਵੇਂ “ਸ਼ੁੱਕਰਵਾਰ ਲਈ ਕਲਾਸ ਬੁੱਕ ਕਰੋ” ਅਤੇ ਪਹਿਲਾ ਸਕ੍ਰੀਨ ਸਪੱਸ਼ਟ ਹੋ ਜਾਏਗਾ: ਅਗਲੇ ਉਪਲੱਬਧ ਸਮਿਆਂ ਨੂੰ ਦਿਖਾਓ ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ اگਲਾ ਕਦਮ ਦਿਖਾਓ, ਨਾ ਕਿ ਫੀਚਰਾਂ ਦਾ ਮੇਨੂ।
What is a persona (and what is it not)?
ਇੱਕ ਪਰਸੋਨਾ ਉਹ ਮੁੱਖ ਉਪਭੋਗਤਾ ਦਾ ਇੱਕ ਛੋਟਾ, ਵਿਸ਼ਵਾਸਯੋਗ ਵਰਣਨ ਹੈ ਜਿਸ ਲਈ ਤੁਸੀਂ ਪਹਿਲਾਂ ਡਿਜ਼ਾਇਨ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਡੈਮੋਗ੍ਰਾਫਿਕ ਪ੍ਰੋਫਾਈਲ ਨਹੀਂ ਹੈ.
ਸ਼ਾਮਿਲ ਕਰੋ:
- ਰੋਲ
- ਵਰਤੋਂ ਦਾ ਸੰਦਰਭ (ਕਿੱਥੇ/ਕਦੋਂ/ਕਿਹੜਾ ਡਿਵਾਈਸ)
- ਮੁੱਖ ਲਕਸ਼
- ਅੱਜ ਦੀ ਮੁੱਖ ਰੁਕਾਵਟ
- ਇੱਕ ਸਧਾਰਨ “ਸਫਲਤਾ” ਦੀ ਪਰਿਭਾਸ਼ਾ
How do I write a persona that actually helps decisions?
ਹਲਕਾ ਰੱਖੋ ਅਤੇ ਲਕਸ਼-ਚਲਿਤ ਬਣਾਓ। 3–5 ਲਾਈਨਾਂ ਲਿਖੋ ਜੋ ਡਿਜ਼ਾਇਨ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਵਿੱਚ ਫੈਸਲੇ ਕਰਨ ਲਈ ਵਰਤੀਆਂ ਜਾ ਸਕਣ।
ਉਦਾਹਰਨ ਸਾਂਚਾ:
- “ਨਾਮ, ਰੋਲ”
- “ਕਦੋਂ/ਕਿੱਥੇ ਐਪ ਵਰਤਦਾ ਹੈ”
- “ਸਪਸ਼ਟ ਲਕਸ਼”
- “ਦਰਦ ਬਿੰਦੂ”
- “ਸਫਲਤਾ ਹੈ…”
What exactly is a task flow?
ਇੱਕ ਟਾਸਕ ਫਲੋ ਉਹ ਛੋਟਾ ਸੈੱਟ ਕਦਮ ਹੈ ਜੋ ਕਿਸੇ ਪਰਸੋਨਾ ਨੂੰ ਇਰਾਦੇ ਤੋਂ ਸਪਸ਼ਟ ਸਫਲਤਾ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ। ਇਹ ਇਕ ਰਸਤਾ ਹੈ, ਤੁਹਾਡੇ ਪੂਰੇ ਉਤਪਾਦ ਦਾ ਨਕਸ਼ਾ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ ਟ੍ਰਿੱਗਰ (“ਉਹ ਕਿਉਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ”) ਅਤੇ ਸਫਲਤਾ ਸਥਿਤੀ (“ਕਿੱਥੇ ‘ਕੰਮ ਮੁੱਕ ਗਿਆ’ ਦਾ ਮਤਲਬ”) ਨੂੰ ਇੱਕ-ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਬਿਆਨ ਕਰ ਸਕਦੇ, ਤਾਂ ਫਲੋ ਅਜੇ ਧੁੰਦਲਾ ਹੈ।
How do I map a happy path without ignoring real-world problems?
ਖੁਸ਼ੀ ਦਾ ਰਸਤਾ ਛੋਟੇ ਕਿਰਿਆ-ਸ਼ਬਦਾਂ (choose, enter, review, confirm) ਵਜੋਂ ਲਿਖੋ, ਫਿਰ ਕੁਝ ਅਸਲੀ-ਦੁਨੀਆਂ ਟੁੱਟਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਜੋੜੋ.
ਇੱਕ ਵਾਸਤਵਿਕ ਘੱਟੋ-ਘੱਟ:
- 1 ਟ੍ਰਿੱਗਰ
- 1 ਸਫਲਤਾ ਮੁਹੂਰ
- 2–3 ਫੈਸਲੇ ਜਾਂ ਫੇਲ੍ਹ ਕੇਸ (sold out, payment fails, no internet)
ਇਹ ਤੁਹਾਡੀਆਂ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਕਾਗਜ਼-ਉੱਤੇ ਬਿਹਤਰ ਦੀ ਬਜਾਏ ਭਰੋਸੇਯੋਗ ਰੱਖਦਾ ਹੈ।
How do I convert a flow into screens without getting stuck on UI details?
ਹਰ ਕਦਮ ਨੂੰ ਜਾਂ ਤਾਂ:
- ਇੱਕ ਸਕ੍ਰੀਨ ਬਣਾਓ ਜਿਸ ਤੇ ਯੂਜ਼ਰ ਆਉਂਦਾ ਹੈ, ਜਾਂ
- ਇੱਕ ਇਕੱਲੀ ਕਾਰਵਾਈ ਜੋ ਮੌਜੂਦ ਸਕ੍ਰੀਨ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ
ਹਰ ਕਦਮ ਲਈ ਸੋਚੋ:
- ਉਹਨਾਂ ਨੂੰ ਕੀ ਵੇਖਣਾ ਜਰੂਰੀ ਹੈ
- ਉਹਨਾਂ ਨੂੰ ਕੀ ਚੁਣਣਾ ਹੈ
- ਉਹਨਾਂ ਨੂੰ ਕੀ ਦਰਜ ਕਰਨਾ ਹੈ
ਫਿਰ ਇੱਕ ਸਪੱਸ਼ਟ اگਲਾ ਕਾਰਵਾਈ ਦਿਓ (ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਬਟਨ)।
How should I name screens so the design stays goal-focused?
ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਮਕਸਦ ਦੇ ਨਾਮ ਦਿਓ, ਲੇਆਉਟ ਦੇ ਹਿੱਸਿਆਂ ਦੇ ਨਹੀਂ.
ਵਧੀਆ:
- “Pick time”
- “Confirm details”
- “Payment”
- “Confirmation”
ਇਹਨਾਂ ਨਾਲ ਤੁਸੀਂ ਸਕ੍ਰੀਨ ਦੇ ਕੰਮ 'ਤੇ ਧਿਆਨ ਰੱਖਦੇ ਹੋ, ਨਾ ਕਿ ਇਸ ਦੇ ਦਿੱਖ 'ਤੇ।
Where do I need confirmations and reassurance in a flow?
ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਕੀ ਹੋਇਆ ਜਾਂ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ। ਫਲੋ 'ਚ ਉਹ ਮੋੜ ਚਿੰਨ੍ਹਤ ਕਰੋ ਜਿੱਥੇ ਸਹਿਮਤੀ ਦੀ ਲੋੜ ਹੈ:
ਆਮ ਸਹਿਮਤੀ ਮੋਮੈਂਟ:
- ਲੋਡਿੰਗ ਸਥਿਤੀਆਂ
- ਖਾਲੀ ਸਥਿਤੀਆਂ
- ਸਪਸ਼ਟ ਪੁਸ਼ਟੀ (“Booked and confirmed”)
- ਸਧਾਰਨ-ਭਾਸ਼ਾ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਬਹਾਲੀ ਵਿਕਲਪ (“Try again” / “Use another method”)
What goes wrong when I try to design for multiple user types at once?
ਜਦੋਂ ਤੁਸੀਂ “ਹਰ ਕਿਸੇ” ਲਈ ਡਿਜ਼ਾਇਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਵੱਖ-ਵੱਖ ਲੋੜਾਂ ਲਈ ਵਾਧੂ ਕਦਮ ਜੁੜ ਜਾਂਦੇ ਹਨ: ਗਤੀ ਬਨਾਮ ਰਾਹ-ਨਿਰਦੇਸ਼ ਬਨਾਮ ਪੂਰਨ ਕੰਟਰੋਲ. ਫਲੋ ਬਲੋਟ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਖੁਸ਼ ਨਹੀਂ ਹੁੰਦਾ.
ਪਹਿਲੇ ਸੰਸਕਰਣ ਲਈ ਇੱਕ ਪ੍ਰਾਥਮਿਕ ਪਰਸੋਨਾ ਚੁਣੋ। ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਉਪਭੋਗਤਾਵਾਂ ਸਹਾਇਤਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
How can Koder.ai help without generating a bunch of disconnected screens?
Koder.ai ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਵਰਤੋਂ ਕਿ ਪਹਿਲਾਂ ਤੁਸੀਂ ਵਾਅਦਾ, ਪਰਸੋਨਾ, ਅਤੇ ਫਲੋ ਲਿਖ ਲਿਆ ਹੋਵੇ। ਉਨ੍ਹਾਂ ਨੂੰ ਪੇਸਟ ਕਰੋ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁੱਛੋ.
ਇੱਕ ਚੰਗਾ ਵਰਕਫਲੋ:
- ਪਲੈਨਿੰਗ ਮੋਡ ਵਿਚ ਫਲੋ ਟੈਕਸਟ ਨੂੰ ਨਿੱਖਾਰੋ
- ਉਸ ਫਲੋ ਤੋਂ ਸਕ੍ਰੀਨਾਂ ਜਨਰੇਟ ਕਰੋ
- ਤੇਜ਼ੀ ਨਾਲ ਦੁਹਰਾਓ, ਅਤੇ ਜਦੋਂ “ਛੋਟੀ ਸੋਧ” ਰਸਤੇ ਨੂੰ ਤੋੜੇ ਤਾਂ ਸਨੇਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਵਰਤੋ
Koder.ai ਤੇਜ਼ੀ ਨਾਲ ਨਤੀਜੇ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਅਨੁਭਵ ਨੂੰ ਏਂਡ-ਟੂ-ਏਂਡ ਜੋੜਿਆ ਰੱਖਣ ਲਈ ਫਲੋ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।