03 ਮਈ 2025·8 ਮਿੰਟ
ਇਰਾਦੇ ਤੋਂ ਐਪ: ਜਦੋਂ AI UI, ਸਟੇਟ ਅਤੇ APIs ਬਣਾਉਂਦਾ ਹੈ
ਇੱਕ ਕਹਾਣੀ ਕਿ ਕਿਵੇਂ ਇੱਕ ਮੋਬਾਈਲ ਐਪ ਦਾ ਵਿਚਾਰ ਕਾਰਜਯੋਗ ਉਤਪਾਦ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜਦੋਂ AI UI ਬਣਾਂਦਾ, ਸਟੇਟ ਸੰਭਾਲਦਾ ਅਤੇ ਬੈਕਐਂਡ ਸਰਵਿਸਾਂ ਨੂੰ ਅੰਤ ਤੱਕ ਜੋੜਦਾ ਹੈ।
ਇੱਕ ਕਹਾਣੀ ਕਿ ਕਿਵੇਂ ਇੱਕ ਮੋਬਾਈਲ ਐਪ ਦਾ ਵਿਚਾਰ ਕਾਰਜਯੋਗ ਉਤਪਾਦ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜਦੋਂ AI UI ਬਣਾਂਦਾ, ਸਟੇਟ ਸੰਭਾਲਦਾ ਅਤੇ ਬੈਕਐਂਡ ਸਰਵਿਸਾਂ ਨੂੰ ਅੰਤ ਤੱਕ ਜੋੜਦਾ ਹੈ।
ਇੱਕ ਫਾਊਂਡਰ ਇੱਕ ਹੋਰ ਤਿਮਾਹੀ ਖਤਮ ਹੋਣ ਵਾਲੀ ਦੌੜ ਤੋਂ ਬਾਅਦ ਝੁਕ ਕੇ ਕਹਿੰਦਾ ਹੈ: “Field reps ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਿਜ਼ਿਟ ਲੌਗ ਕਰਨ ਅਤੇ follow-ups ਸੈੱਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੋ, ਤਾਂ ਜੋ ਕੋਈ ਚੀਜ਼ ਸੁਲਝਣ ਤੋਂ ਬਿਨਾਂ ਰਹਿ ਨਾ ਜਾਵੇ ਅਤੇ प्रशासनਿਕ ਕੰਮ ਵਧੇ ਨਾ।”
ਉਹ ਇਕ ਵਾਕ ਅਸਲੀ ਉਪਭੋਗਤਾ ਸਮੱਸਿਆ ਰੱਖਦਾ ਹੈ: ਨੋਟ ਆਖ਼ਿਰ ਵਿੱਚ ਲਿਖੇ ਜਾਂਦੇ ਹਨ (ਜਾਂ ਕਦੇ ਨਹੀਂ), follow-ups ਮੁੱਕਦੇ ਹਨ, ਅਤੇ ਆਮਦਨੀ ਚੁਪਚਾਪ ਫੁੱਟਦੀ ਹੈ।
ਇਹ AI-ਸਹਾਇਤ ਬਿਲਡ ਦਾ ਵਾਅਦਾ ਹੈ: ਤੁਸੀਂ ਇਰਾਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਕੰਮ ਕਰਨ ਯੋਗ ਮੋਬਾਈਲ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲਦਾ ਹੈ—ਹਰ ਸਕ੍ਰੀਨ, ਸਟੇਟ ਅਪਡੇਟ ਅਤੇ API ਕਾਲ ਨੂੰ scratch ਤੋਂ ਹੱਥ ਨਾਲ ਜੋੜਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਨਾ ਕੋਈ “ਜਾਦੂ”, ਨਾ ਤੁਰੰਤ ਪਰਫੈਕਸ਼ਨ, ਪਰ ਵਿਚਾਰ ਤੋਂ ਕਿਸੇ ਐਸੇ ਚੀਜ਼ ਤੱਕ ਦੀ ਛੋਟੀ ਰਾਹ ਜੋ ਤੁਸੀਂ ਫੋਨ 'ਤੇ ਚਲਾ ਸਕੋ ਅਤੇ ਕਿਸੇ ਦੇ ਹੱਥ ਵਿੱਚ ਦੇ ਸਕੋ।
ਇਹ ਭਾਗ (ਅਤੇ ਹੇਠਾਂ ਦੀ ਕਹਾਣੀ) ਕੋਈ ਤਕਨੀਕੀ ਟਿਊਟੋਰਿਯਲ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਕਹਾਣੀ ਹੈ ਜਿਸ ਵਿੱਚ ਵਿਆਵਹਾਰਿਕ ਸਿੱਖਣ-ਬਿੰਦੂ ਹਨ: ਕੀ ਕਹਿਣਾ ਹੈ, ਕੀ ਜਲਦੀ ਫੈਸਲਾ ਕਰਨਾ ਹੈ, ਅਤੇ ਕੀ ਖੁੱਲ੍ਹਾ ਛੱਡਣਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਅਸਲੀ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਫਲੋ ਟੈਸਟ ਨਹੀਂ ਕਰ ਲੈਂਦੇ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਰਾਦਾ ਉਹ ਨਤੀਜਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਕਿਸੇ ਨਿਰਧਾਰਤ ਦਰਸ਼ਕ ਲਈ, ਅਤੇ ਸਪੱਸ਼ਟ ਪਾਬੰਦੀਆਂ ਦੇ ਅੰਦਰ।
ਚੰਗਾ ਇਰਾਦਾ ਫੀਚਰ ਲਿਸਟ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਉਹ ਵਾਕ ਹੈ ਜੋ ਹਰ ਇੱਕ ਨੂੰ—ਇਨਸਾਨਾਂ ਅਤੇ AI ਦੋਹਾਂ—ਬਤਾਉਂਦਾ ਹੈ ਕਿ ਸਫਲਤਾ ਕਿਵੇਂ ਦਿੱਖਦੀ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਇਰਾਦੇ 'ਤੇ ਸਪੱਸ਼ਟ ਹੋ, ਤਤਕਾਲ ਤੁਸੀਂ ਇੱਕ ਐਸੇ MVP ਨੂੰ ਲਕੜੀ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਸਿਰਫ਼ clickable ਸਕ੍ਰੀਨਾਂ ਤੋਂ ਵੱਧ ਹੋਵੇ। ਲਕੜੀ ਹੈ ਇੱਕ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਐਪ ਜਿਸਦੇ ਅਸਲੀ ਫਲੋ ਅਤੇ ਅਸਲੀ ਡੇਟਾ ਹਨ: ਉਪਭੋਗਤਾ ਸਾਈਨ ਇਨ ਕਰ ਸਕਦੇ ਹਨ, ਅੱਜ ਦੇ accounts ਵੇਖ ਸਕਦੇ ਹਨ, ਇਕ ਵਿਜ਼ਿਟ ਲੌਗ ਕਰ ਸਕਦੇ ਹਨ, ਨੋਟ/ਫੋਟੋ ਜੁੜ ਸਕਦੇ ਹਨ, ਅਗਲਾ ਕਦਮ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਆਮ exceptions ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹਨ।
ਜੋ ਕੁਝ ਵੀ ਆਉਂਦਾ ਹੈ—ਰਿਕਵਾਇਰਮੈਂਟਸ, ਜਾਣਕਾਰੀ ਆਰਕੀਟੈਕਚਰ, UI, ਸਟੇਟ, ਬੈਕਐਂਡ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਦੁਹਰਾਈ—ਉਹ ਸਾਰਾ ਉਸ ਇਕ ਵਾਕ ਦੀ ਸੇਵਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
Maya ਇਸ ਪ੍ਰਾਜੈਕਟ ਦੀ PM ਅਤੇ ਅਣਜਾਣ ਫ਼ਾਊਂਡਰ ਹੈ। ਉਹ ਮੋਬਾਈਲ ਐਪ ਨੂੰ ਦੁਬਾਰਾ ਖੋਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਹੀ—ਉਹ ਤੱਕ ਇੱਕ ਤਿਮਾਹੀ ਦੀ ਡੈਡਲਾਈਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਐਪ ਸ਼ਿਪ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ ਤਾਂ ਜੋ ਮੌਕਾ ਖਤਮ ਨਾ ਹੋ ਜਾਏ।
“ਟੀਮ” ਇੱਕ ਕੈਲੰਡਰ ਆਮੰਤਰਣ ਵਿੱਚ ਆ ਸਕਦੀ ਹੈ: Maya, ਇੱਕ ਡਿਜ਼ਾਇਨਰ ਜੋ ਹਫ਼ਤੇ ਵਿੱਚ ਕੁਝ ਘੰਟੇ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਇੰਜੀਨੀਅਰ ਜੋ ਪਹਿਲਾਂ ਹੀ ਦੋ ਹੋਰ ਐਪ ਰੱਖ ਰਿਹਾ ਹੈ। 40-ਪੰਨਿਆਂ ਦੀ ਸਪੈਸ ਲਿਖਣ, ਫ੍ਰੇਮਵਰਕ ਬਾਰੇ ਬਹਿਸ ਕਰਨ, ਜਾਂ ਇਕ ਮਹੀਨੇ ਦੇ ਵਰਕਸ਼ਾਪ ਕਰਨ ਦਾ ਸਮਾਂ ਨਹੀਂ। ਫਿਰ ਵੀ ਉਮੀਦਾਂ ਹਕੀਕਤੀਆਂ ਹਨ: ਲੀਡਰਸ਼ਿਪ ਕੁਝ ਉਪਯੋਗੀ ਚਾਹੁੰਦੀ ਹੈ, ਡੈਮੋ ਨਹੀਂ।
Maya ਦੀਆਂ ਸ਼ੁਰੂਆਤੀ ਚੀਜ਼ਾਂ ਸਧਾਰਨ ਹਨ:
ਉਸਦੀ ਨੋਟਾਂ ਵਿੱਚ ਇੱਕ ਅਹੰਕਾਰਪੂਰਨ ਵਾਕ ਵੀ ਹੈ: “ਜੇ ਯੂਜ਼ਰ ਮੁੱਖ ਟਾਸਕ ਨੂੰ ਫੋਨ 'ਤੇ ਦੋ ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਅਸੀਂ ਸਹੀ ਚੀਜ਼ ਨਹੀਂ ਬਣਾਈ।”
ਇਸ MVP ਲਈ, “ਪੂਰਾ” ਇੱਕ ਇਕਲ ਉਪਭੋਗਤਾ ਯਾਤਰਾ ਹੈ ਜੋ end-to-end ਕੰਮ ਕਰਦੀ ਹੈ:
ਕੋਈ fancy dashboards ਨਹੀਂ। ਕੋਈ ਲੁਕਿਆ ਹੋਇਆ ਮੇਨੂ ਨਹੀਂ। ਕੋਈ “ਬਾਅਦ ਵਿੱਚ polish ਕਰਾਂਗੇ” ਸਕ੍ਰੀਨ ਜੋ ਫਲੋ ਨੂੰ ਰੋਕਦੇ ਹਨ, ਨਹੀਂ।
ਐਪ ਨੂੰ ਇੱਕ ਮੌਜੂਦਾ ਬੈਕਐਂਡ ਨਾਲ ਜੁੜਨਾ ਪਏਗਾ—APIs ਜੋ ਮੋਬਾਈਲ ਲਈ ਬਣਾਏ ਨਹੀਂ ਗਏ ਸਨ ਅਤੇ ਜਿਨ੍ਹਾਂ ਦੀ ਡੋਕਯੂਮੈਂਟੇਸ਼ਨ ਅਸਮਾਨ ਗੁਣਵੱਤਾ ਦੀ ਹੋ ਸਕਦੀ ਹੈ। ਬਜਟ ਸੀਮਤ ਹੈ, ਇਸ ਲਈ ਹਰ ਨਵੀਂ ਸਕ੍ਰੀਨ ਨੂੰ ਆਪਣੀ ਜ਼ਰੂਰਤ ਸਾਬਤ ਕਰਨੀ ਪਏਗੀ।
ਕੁਝ ਗਾਰਡਰੇਲ ਗੈਰ-ਸੰਭਵ ਹਨ: ਆਡਿਟ ਲਾਗ, ਜ਼ਰੂਰੀ ਸਮਝੌਤਾ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ, ਅਤੇ ਡਿਵਾਈਸ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਸਾਦਗੀ ਨਾਲ ਸਟੋਰ ਨਾ ਕੀਤਾ ਜਾਵੇ।
ਅਤੇ ਇੱਥੇ ਟੈਨਸ਼ਨ ਹੈ: Maya ਕੋਲ ਦੱਸ ਵਧੀਆ ਵਿਚਾਰ ਹਨ ਅਤੇ ਸ਼ਾਇਦ ਦੱਸ ਕੰਮ ਦਿਨ। ਹਰ ਘੰਟਾ ਜੋ ਵਿਕਲਪਾਂ 'ਤੇ ਬਹਿਸ ਕਰਕੇ ਲੰਮੀ ਹੁੰਦੀ ਹੈ, ਉਹ ਘੰਟਾ ਮੁੱਖ ਯਾਤਰਾ ਕਿਸੇ ਦੇ ਹੱਥ ਵਿੱਚ ਪਹੁੰਚਾਉਣ ਤੋਂ ਘਟਦਾ ਹੈ।
ਲਕਸ਼ ਹੈ ਇੱਕ ਪਰਫੈਕਟ ਸਪੈਸ ਲਿਖਣਾ ਨਹੀਂ। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਟੈਸਟ ਕਰਨ ਯੋਗ ਸਪੱਸ਼ਟਤਾ 'ਤੇ ਪਹੁੰਚਣਾ ਹੈ—ਅਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਕਿਸ ਲਈ, ਅਤੇ ਕਿਵੇਂ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਅਸੀਂ ਸਫਲ ਹੋਏ।
ਤੁਸੀਂ ਇੱਕ ਗੁੰਝਲਦਾਰ ਵਾਕ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ:
“I want an app that helps our field reps log visits and follow up.”
ਫਿਰ ਤੁਸੀਂ AI ਨੂੰ ਇਸ ਨੂੰ ਤਿੱਖਾ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਹੋ:
Prompt: “Rewrite this as a problem statement and add 3 success metrics. Keep it short.”
AI output (ਸੋਧਿਆ):
Problem statement: Field reps follow-ups ਗੁਆਉਂਦੇ ਹਨ ਕਿਉਂਕਿ visit notes ਅਤੇ next steps ਦੇਰੀ ਨਾਲ (ਜਾਂ ਨਹੀਂ) ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ missed revenue ਅਤੇ ਗੈਰ-ਇਨਸਾਨੀ customer experience ਹੁੰਦੀ ਹੈ.
Success metrics:
ਹੁਣ ਸਾਡੇ ਕੋਲ ਇੱਕ ਲਕਸ਼ ਹੈ ਜਿਸ ਦੀ ਟੀਮ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੀ ਹੈ, ਸਿਰਫ਼ ਫੀਚਰ ਦੀ ਇੱਛਾ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ vibe-coding ਵਰਕਫਲੋ ਵਰਤ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ Koder.ai ਵਿੱਚ, ਜਿੱਥੇ ਤੁਸੀਂ ਉਤਪਾਦ ਨੂੰ ਚੈਟ ਵਿੱਚ ਵੇਰਵਾ ਕਰਦੇ ਹੋ ਅਤੇ ਇਥਰ-ਇਟਰੇਟਿਵ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਐਪ ਜਨਰੇਟ ਕਰਦੇ ਹੋ), ਇਹ ਉਹ ਸਮਾਂ ਹੈ ਜਿਸ ਦੀ ਸਫਲਤਾ ਵਾਪਸੀ ਦਿੰਦੀ ਹੈ: ਇੱਕ ਤਿੱਖਾ ਇਰਾਦਾ + ਮੈਟਰਿਕਸ “ਸਰੋਤ-ਸੱਚ” ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਸਿਸਟਮ ਅਗਲੇ ਪੈਰਾਗ੍ਰਾਫਾਂ ਲਈ ਵਰਤਦਾ ਹੈ।
ਅਗਲਾ, ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਟਾਸਕ ਬਾਹਰ ਕਢੋ:
User roles:
Top tasks:
ਉਹਨਾਂ ਨੂੰ ਕੁਝ ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼ ਵਿੱਚ ਬਦਲੋ acceptance criteria ਨਾਲ:
ਪਹਿਲੀ ਰਿਲੀਜ਼ ਨੂੰ ਬਚਾਉਣ ਲਈ:
ਹਰ ਫੈਸਲੇ ਨੂੰ ਇੱਕ ਫਲੋ ਨਾਲ ਜੋੜੋ:
Open app → “Log Visit” → customer ਚੁਣੋ → note/photo ਜੋੜੋ → next step + due date ਚੁਣੋ → save → follow-ups “Today” ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।
ਜੇ ਕੋਈ ਬੇਨਤੀ ਇਸ ਫਲੋ ਨੂੰ ਸਹਿਯੋਗ ਨਹੀਂ ਕਰਦੀ, ਉਹ ਅਗਲੀ ਰਿਲੀਜ਼ ਲਈ ਰਹਿ ਜਾਂਦੀ ਹੈ।
ਜਦੋਂ “ਨਾਰਥ-ਸਟਾਰ” ਫਲੋ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ, AI ਇਸ ਨੂੰ ਇੱਕ ਜਾਣਕਾਰੀ ਆਰਕੀਟੈਕਚਰ (IA) ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਹਰ ਕੋਈ ਪੜ੍ਹ ਸਕਦਾ ਹੈ—ਬਿਨਾਂ ਤੁਰਦੇ ਹੋਏ ਵਾਇਰਫਰੇਮ ਜਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ।
ਜ਼ਿਆਦਾਤਰ MVP ਲਈ, ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਸਕ੍ਰੀਨਾਂ ਦੀ ਸੈਟ ਚਾਹੀਦੀ ਹੈ ਜੋ ਪ੍ਰਾਇਮਰੀ ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰਦੀ ਹੈ। AI ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸੁਝਾਅ ਦੇਵੇਗਾ (ਤੇ ਤੁਸੀਂ ਸੋਧ ਸਕਦੇ ਹੋ):
ਉਹ ਸੂਚੀ ਲਕੜੀ ਬਣ ਜਾਂਦੀ ਹੈ। ਜੋ ਕੁਝ ਇਸ ਤੋਂ ਬਾਹਰ ਹੈ ਉਹ ਬਾਅਦ ਦੀ ਰਿਲੀਜ਼ ਜਾਂ “ਸੈਕੰਡਰੀ ਫਲੋ” ਹੈ।
ਨਮੂਨੇ ਬਾਰੇ ਅਦਾਂ-ਪ੍ਰਦਾਂ ਕਰਨ ਦੀ ਬਜਾਏ, IA ਨੈਵੀਗੇਸ਼ਨ ਨੂੰ ਸਾਜ਼ੇ ਸਾਕੀ ਵਿੱਚ ਕਹਿੰਦੀ ਹੈ:
ਜੇ onboarding ਹੋਵੇ, IA ਇਸ ਨੂੰ ਕਿੱਥੇ ਸ਼ੁਰੂ ਅਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ ("Onboarding Home 'ਤੇ ਖਤਮ ਹੁੰਦੀ ਹੈ") ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀ ਹੈ।
ਹਰ ਸਕ੍ਰੀਨ ਨੂੰ ਇੱਕ ਹਲਕੀ outline ਮਿਲਦੀ ਹੈ:
Empty states ਅਕਸਰ ਥਾਂ ਹਨ ਜਿੱਥੇ ਐਪ ਟੁੱਟੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ onları ਇਰਾਦੇ ਨਾਲ ਡ੍ਰਾਫਟ ਕਰੋ (ਉਦਾਹਰਣ: “No visits logged today yet” ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਅਗਲਾ ਕਦਮ)।
IA ਸ਼ੁਰੂ ਵਿੱਚ condition views ਨੂੰ ਨਿਸ਼ਾਨਜ਼ੀ ਕਰਦਾ ਹੈ: “Managers ਇੱਕ ਵਾਧੂ tab ਵੇਖਦੇ ਹਨ,” ਜਾਂ “ਸਿਰਫ Ops account details edit ਕਰ ਸਕਦੇ ਹਨ।” ਇਹ permissions ਅਤੇ ਸਟੇਟ ਨੂੰ ਇੰਪਲੀਮੈਂਟ ਕਰਨ ਵੇਲੇ ਆਉਣ ਵਾਲੀਆਂ ਹੈਰਾਨੀਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਆਉਟਪੁੱਟ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਪੰਨਾ ਫਲੋ + per-screen bullets ਹੁੰਦਾ ਹੈ—ਕੋਈ ਗੈਰ-ਟੈਕਨੀਕਲ stakeholder ਤੇਜ਼ੀ ਨਾਲ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ: ਕਿਹੜੀਆਂ ਸਕ੍ਰੀਨਾਂ ਹਨ, ਕਿਵੇਂ ਤੁਰਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਡੇਟਾ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਫਲੋ ਸਹਿਮਤ ਹੋ ਜਾਂਦੀ ਹੈ, AI ਹਰ ਕਦਮ ਨੂੰ “ਸਕ੍ਰੀਨ ਠੇਕਾ” ਵਜੋਂ ਲੈ ਕੇ ਪਹਿਲਾ-ਪਾਸ ਵਾਇਰਫਰੇਮ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ: ਉਪਭੋਗਤਾ ਨੂੰ ਕੀ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਗਲੇ ਕੀ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਜਾਂ ਦਿਖਣੀ ਚਾਹੀਦੀ ਹੈ।
ਆਉਟਪੁੱਟ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਖਰਾਬ ਹੁੰਦਾ ਹੈ—ਗ੍ਰੇਸਕੇਲ ਬਲਾਕਾਂ ਨਾਲ ਲੇਬਲਾਂ—ਪਰ ਇਹ ਪਹਿਲਾਂ ਹੀ ਸਮੱਗਰੀ ਦੀ ਜ਼ਰੂਰਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣਿਆ ਹੁੰਦਾ ਹੈ। ਜੇ ਕਦਮ ਵਿਚ ਤੁਲਨਾ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ grid ਜਾਂ card layout ਪਾਉਗੇ। ਜੇ ਇਹ ਤਰੱਕੀ ਬਾਰੇ ਹੈ ਤਾਂ ਇੱਕ ਸਪੱਸ਼ਟ primary action ਅਤੇ ਇਕ ਹਲਕੀ summary ਦਿਖੇਗੀ।
ਕੰਪੋਨੈਂਟ ਚੋਣਾਂ ਬੇਰੁਕ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹ ਕੰਮ-ਚਾਲ ਨਾਲ ਚੁਣੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:
AI ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਫੈਸਲੇ ਉਹਨਾਂ ਕਿਰਿਆਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਕਰਦਾ ਹੈ ਜੋ ਇਰਾਦੇ ਵਿੱਚ ਹਨ: browse, choose, edit, confirm।
ਇਸ ਮੰਚ 'ਤੇ ਵੀ, ਚੰਗੇ ਜਨਰੇਟਰ ਕੁਝ ਬੁਨਿਆਦੀ ਪਾਬੰਦੀਆਂ ਲਗਾਉਂਦੇ ਹਨ ਤਾਂ ਕਿ ਸਕ੍ਰੀਨ “AI-ਜੈਸੀ” ਨਾ ਲੱਗਣ:
ਕਾਪੀ ਡ੍ਰਾਫਟ UI ਨਾਲ ਨਾਲ ਆਉਂਦੇ ਹਨ। “Submit” ਦੀ ਥਾਂ ਬਟਨ “Save visit” ਜਾਂ “Schedule follow-up” ਬਣ ਜਾਂਦੇ ਹਨ, ਜੋ ਉਪਭੋਗਤਾ ਦੇ ਕੰਮ-ਬਣਾਉਣ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ।
ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇੱਕ ਪੋਲ-ਓਨਰ, ਡਿਜ਼ਾਇਨਰ, ਜਾਂ ਮਾਰਕੀਟਰ ਦਖਲ ਦਿੰਦਾ ਹੈ—ਨਾ ਕਿ ਹਰ ਚੀਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਡਰਾਅ ਕਰਨ ਲਈ, ਪਰ ਰੂਪ-ਭਾਵ ਅਤੇ ਸਪੱਸ਼ਟਤਾ ਨੂੰ ਸੁਧਾਰਨ ਲਈ:
ਤੁਸੀਂ ਸਿਰਫ਼ ਤਸਵੀਰਾਂ ਤੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦੇ। ਹandoff ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ clickable prototype (tap-through ਸਕ੍ਰੀਨ feedback ਲਈ) ਜਾਂ generated screen code ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਟੀਮ build-test ਲੂਪ ਵਿੱਚ ਇਟਰੇਟ ਕਰ ਸਕਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਇਹ ਮੰਚ ਆਮ ਤੌਰ 'ਤੇ ਜਲਦ ਹੀ ٹھوس ਹੋ ਜਾਂਦਾ ਹੈ: UI ਕੰਮ ਕਰਨ ਵਾਲੇ ਐਪ ਦਾ ਹਿੱਸਾ ਹੋ ਕੇ ਜਨਰੇਟ ਹੁੰਦੀ ਹੈ (web ਵਿੱਚ React, backend Go ਅਤੇ PostgreSQL, ਅਤੇ mobile ਵਿੱਚ Flutter), ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਹੀ ਥਾਂ 'ਤੇ ਅਸਲੀ ਸਕ੍ਰੀਨਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ ਜਦੋਂ ਕਿ flow doc ਤੁਹਾਡਾ ਗਾਰਡਰੇਲ ਰਹਿੰਦਾ ਹੈ।
UI ਸਕੈਚ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਅਗਲਾ ਸਵਾਲ ਸਧਾਰਨ ਹੈ: ਐਪ ਨੂੰ ਕੀ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਸ ਨੂੰ ਕਿਸ ਗੱਲ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ? ਉਹ “ਯਾਦ” ਸਟੇਟ ਹੈ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਇੱਕ ਸਕ੍ਰੀਨ ਤੁਹਾਨੂੰ ਨਾਮ ਨਾਲ ਸੁਆਗਤ ਕਰ ਸਕਦੀ, ਇੱਕ ਗਿਣਤੀ ਰੱਖ ਸਕਦੀ, ਅਧੂਰਾ ਫਾਰਮ ਬਚਾ ਸਕਦੀ, ਜਾਂ ਨਤੀਜੇ ਤੁਹਾਡੀ ਪਸੰਦ ਮੁਤਾਬਕ ਸਰਟ ਕਰਕੇ ਦਿਖਾ ਸਕਦੀ ਹੈ।
AI ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟਾ ਸੈਟ ਸਟੇਟ ਆਬਜੈਕਟ define ਕਰਕੇ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਜੋ ਪੂਰੇ ਐਪ ਵਿੱਚ ਚੱਲਦੇ ਹਨ:
ਕੀਂ ਚੀਜ਼ consistency ਹੈ: ਉਹੀ ਆਬਜੈਕਟ (ਅਤੇ ਨਾਮ) ਹਰ ਸਕ੍ਰੀਨ ਨੂੰ ਪਾਵਰ ਦਿੰਦੇ ਹਨ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਛੂੰਹਦੇ ਹਨ, ਨਾ ਕਿ ਹਰ ਸਕ੍ਰੀਨ ਆਪਣਾ ਛੋਟਾ-мਾਡਲ ਬਣਾਏ।
ਫਾਰਮ ਸਿਰਫ਼ ਇਨਪੁੱਟ ਨਹੀਂ—ਉਹ ਨਿਯਮ ਹਨ ਜੋ ਦਿੱਖਦੇ ਹਨ। AI validation patterns ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ:
ਹਰ async ਕਾਰਵਾਈ (sign in, fetch items, save a visit) ਲਈ, ਐਪ ਸਧਾਰਨ ਅਵਸਥਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ:
ਜੇ ਇਹ ਨਮੂਨੇ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਲਗਾਤਾਰ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਜਦੋਂ ਅਸਲੀ ਉਪਭੋਗਤਾ ਅਣਛੁਆਂ ਤਰੀਕਿਆਂ ਨਾਲ ਟੈਪ ਕਰਦੇ ਹਨ, ਐਪ ਇਕਸਾਰ ਅਤੇ ਘੱਟ ਨਾਜ਼ੁਕ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ।
ਫਲੋ ਤਦ ਹੀ ਅਸਲੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਪੜ੍ਹਦਾ ਅਤੇ ਲਿਖਦਾ ਹੈ ਅਸਲੀ ਡੇਟਾ। ਜਦੋਂ ਸਕ੍ਰੀਨ ਅਤੇ ਸਟੇਟ ਨਿਯਮ ਬਣ ਜਾਂਦੇ ਹਨ, AI ਇਹ ਤੈਅ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਜੋ ਕਰ ਰਿਹਾ ਹੈ ਉਹ ਬੈਕਐਂਡ ਨੂੰ ਕੀ ਸਹਿਯੋਗ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ—ਫਿਰ ਓਹ ਵਾਇਰਿੰਗ ਜਨਰੇਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਐਪ ਪ੍ਰੋਟੋਟਾਈਪ ਨਾ ਰਹਿ ਕੇ ਉਤਪਾਦ ਬਣ ਜਾਵੇ।
ਇੱਕ ਆਮ ਯਾਤਰਾ ਤੋਂ, ਬੈਕਐਂਡ ਰਿਕਵਾਇਰਮੈਂਟ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਦਰਜਿਆਂ ਵਿੱਚ ਪੈਂਦੇ ਹਨ:
AI ਇਹਨਾਂ ਨੂੰ ਸਿੱਧਾ UI ਇਰਾਦੇ ਤੋਂ ਖਿੱਚ ਸਕਦਾ ਹੈ। “Save” ਬਟਨ mutation imply ਕਰਦਾ ਹੈ। ਇਕ list screen paginated fetch imply ਕਰਦੀ ਹੈ। ਇੱਕ filter chip query parameters imply ਕਰਦਾ ਹੈ।
Endpoints ਅਲੱਗ-ਅਲੱਗ ਬਣਾਉਣ ਦੀ ਥਾਂ, mapping ਸਕ੍ਰੀਨ ਇੰਟਰੈਕਸ਼ਨਾਂ ਤੋਂ ਨਿਕਲਦੀ ਹੈ:
POST /visitsGET /accounts?cursor=...PATCH /visits/:idPATCH /followups/:idਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਬੈਕਐਂਡ ਹੈ, AI ਉਸ ਦੇ ਅਨੁਕੂਲ ਹੋ ਜਾਵੇਗਾ: REST endpoints, GraphQL operations, Firebase/Firestore collections, ਜਾਂ ਕੋਈ custom internal API. ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਨਹੀਂ, ਇਹ UI ਦੀ ਲੋੜ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੋਇਆ ਇੱਕ ਪਤਲਾ ਸਰਵਿਸ ਲੇਅਰ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ (ਅਤੇ ਕੁਝ ਵੀ ਵਾਧੂ ਨਹੀਂ)।
###Schemas ਅਨੁਮਾਨ—ਫਿਰ ਪੁਸ਼ਟੀ
AI UI ਕਾਪੀ ਅਤੇ ਸਟੇਟ ਤੋਂ models ਸੁਝਾਅ ਦੇਵੇਗਾ:
Visit { id, accountId, notes, nextStep, dueAt, createdAt }ਪਰ ਇੱਕ ਮਨੁੱਖ ਫ਼ਿਰ ਵੀ ਸੱਚ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ: ਕਿਹੜੇ ਫੀਲਡ required ਹਨ, ਕੀ nullable ਹੈ, ਕੀ index ਦੀ ਲੋੜ ਹੈ, ਅਤੇ permissions ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਉਹ ਛੋਟੀ ਸਮੀਖਿਆ “ਲਗਭਗ ਠੀਕ” ਡੇਟਾ ਮਾਡਲ ਨੂੰ ਉਤਪਾਦ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਤਦ ਹੀ ਪੂਰੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ failure paths ਨੂੰ ਪਹਿਲੀ ਕਲਾਸ ਸਮਝਿਆ ਜਾਵੇ:
ਇਹ ਥਾਂ ਹੈ ਜਿੱਥੇ AI ਉਹ ਬੋਰਿੰਗ ਹਿੱਸੇ ਤੇਜ਼ੀ ਨਾਲ ਕਰ ਦਿੰਦਾ ਹੈ—consistent request wrappers, typed models, ਅਤੇ predictable error states—ਜਿਵੇਂ ਕਿ ਟੀਮ correctness ਅਤੇ business rules 'ਤੇ ਧਿਆਨ ਰੱਖਦੀ ਹੈ।
ਪਹਿਲਾ “ਅਸਲੀ” ਟੈਸਟ ਦਰਸਾਬਤ ਨਹੀਂ ਹੈ—ਇੱਕ ਬਿਲਡ ਅਸਲੀ ਫੋਨ 'ਤੇ, ਕਿਸੇ ਦੇ ਹੱਥ ਵਿੱਚ, imperfect Wi‑Fi 'ਤੇ। ਉਥੇ ਜਲਦੀ ਕ੍ਰੈਕਸ ਦਿੱਖਦੇ ਹਨ।
ਅਕਸਰ ਸਿਰਲੇਖ ਫੀਚਰ ਨਹੀਂ ਟੁੱਟਦੇ। ਇਹ seams ਹੁੰਦੇ ਹਨ:
ਇਹ ਉਪਯੋਗੀ ਨਾਕਾਮੀ ਹੈ। ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪ ਅਸਲ ਵਿੱਚ ਕਿਸ 'ਤੇ ਨਿਰਭਰ ਹੈ।
ਜਦੋਂ ਕੁਝ ਟੁਟਦਾ ਹੈ, AI ਸਭ ਤੋਂ ਵੱਧ ਮਦਦਗਾਰ ਇੱਕ cross-layer ਡਿਟੈਕਟਿਵ ਵਾਂਗ ਹੈ। UI, ਸਟੇਟ, ਅਤੇ APIs ਵਿੱਚ ਅਲੱਗ-ਅਲੱਗ ਮੁੱਦੇ ਖੋਜਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇਸਨੂੰ end-to-end ਰਾਹ ਦੀ ਟ੍ਰੇਸ ਪੁੱਛ ਸਕਦੇ ਹੋ:
profile.photoUrl ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, backend avatar_url ਵਾਪਸ ਕਰਦਾ ਹੈ।ਕਿਉਂਕਿ AI ਕੋਲ flow, screen map, ਅਤੇ data contracts ਸੰਦਰਭ ਵਿੱਚ ਹੁੰਦੇ ਹਨ, ਇਹ ਇੱਕ ਇੱਕ-ਲਾਈਨ ਫਿਕਸ ਸੁਝਾ ਸਕਦਾ ਹੈ ਜੋ ਸਾਰੇ ਸਹੀ ਥਾਵਾਂ 'ਤੇ ਛੂਹਦਾ ਹੈ—ਇੱਕ ਫੀਲਡ ਦਾ ਨਾਮ ਬਦਲੋ, fallback state ਜੋੜੋ, ਅਤੇ endpoint response adjust ਕਰੋ।
ਹਰ ਟੈਸਟ ਬਿਲਡ ਨੂੰ ਇਹ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: “ਕੀ ਅਸੀਂ ਮੈਟਰਿਕ ਵੱਲ ਨਜ਼ਦੀਕ ਹੋ ਰਹੇ ਹਾਂ?” ਕੁਝ ਘਟਨਾਵਾਂ ਜੋ ਤੁਹਾਡੇ success criteria ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ ਜੋੜੋ, ਉਦਾਹਰਣ ਲਈ:
signup_started → signup_completedfirst_action_completed (ਤੁਹਾਡੀ activation ਘਟਨਾ)error_shown ਇੱਕ reason code ਨਾਲ (timeout, validation, permission)ਹੁਣ ਫੀਡਬੈਕ ਸਿਰਫ਼ ਰਾਏ ਨਹੀਂ—ਇੱਕ ਮਾਪਯੋਗ funnel ਹੈ।
ਸਿਧਾ rhythm ਕੰਮ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ: ਰੋਜ਼ਾਨਾ ਬਿਲਡ + 20-ਮਿੰਟ ਸਮੀਖਿਆ। ਹਰ ਚੱਕਰ ਇੱਕ ਜਾਂ ਦੋ fixes ਚੁਣਦਾ ਹੈ, ਅਤੇ UI, state, ਅਤੇ endpoints ਨੂੰ ਇਕੱਠੇ ਅਪਡੇਟ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ “ਅਧ-ਠੀਕ” ਫੀਚਰ ਰੋਕਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ—ਜਿੱਥੇ ਸਕ੍ਰੀਨ ਠੀਕ ਦਿਖਦੀ ਹੈ, ਪਰ ਐਪ ਅਸਲੀ-ਦੁਨੀਆ ਸਮੇਂ, ਗੁੰਮ ਡੇਟਾ, ਜਾਂ ਵਿਛੇੜੇ permissions ਤੋਂ ਬਚ ਨਹੀਂ ਪਾਂਦਾ।
ਜਦੋਂ happy path ਕੰਮ ਕਰਨ ਲੱਗ ਜਾਂਦੀ ਹੈ, ਐਪ ਨੂੰ ਅਸਲੀ ਜੀਵਨ ਸਹਿਯੋਗ ਕਰਨਾ ਪਏਗਾ: tunnels, low battery mode, missing permissions, ਅਤੇ ਅਣਪੇਖੇ ਡੇਟਾ। ਇਹ ਥਾਂ ਹੈ ਜਿੱਥੇ AI “ਟੁੱਟਣਾ ਨਹੀਂ” ਨੂੰ ਤਜ਼ਕਰਾ ਕਰਨ ਯੋਗ ਵਿਹਾਰਾਂ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਟੀਮ ਸਮੀਖਿਆ ਸਕਦੀ ਹੈ।
ਹੁਣੇ ਹੀ ਹਰ ਕਾਰਵਾਈ ਨੂੰ offline-safe ਜਾਂ connection-required ਦੇ ਨਾਲ ਲੇਬਲ ਕਰੋ। ਉਦਾਹਰਣ ਲਈ, ਪਹਿਲਾਂ ਲੋਡ ਕੀਤੇ accounts ਬ੍ਰਾਉਜ਼ ਕਰਨਾ, drafts edit ਕਰਨਾ, ਅਤੇ cached history ਵੇਖਣਾ offline 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। ਪੂਰੇ dataset ਨੂੰ search ਕਰਨਾ, changes sync ਕਰਨਾ, ਅਤੇ personalized recommendations ਲੋਡ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ connection ਲੋੜਦਾ ਹੈ।
ਇੱਕ ਵਧੀਆ ਡਿਫਾਲਟ ਹੈ: cache ਤੋਂ ਪੜ੍ਹੋ, outbox ਵਿੱਚ ਲਿਖੋ। UI ਨੂੰ ਸਪੱਸ਼ਟ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਦੋਂ ਇਕ ਬਦਲਾਅ “Saved locally” ਹੈ ਅਤੇ ਕਦੋਂ “Synced” ਹੈ, ਅਤੇ connectivity ਵਾਪਸ ਆਉਣ 'ਤੇ ਸਧਾਰਨ “Try again” ਦੇ ਸਮੀਕਰਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ।
Permissions ਨੂੰ ਉਸ ਵੇਲੇ ਪੁੱਛੋ ਜੋ ਉਹ ਅਰਥ ਰੱਖਦੇ ਹਨ:
ਮੁੱਖ ਗੱਲ ਹੈ ਨਰਮ ਵਿਕਲਪ, ਨਾ ਕਿ dead ends।
AI ਤੇਜ਼ੀ ਨਾਲ edge cases ਗਿਣਾ ਸਕਦਾ ਹੈ, ਪਰ ਟੀਮ ਹੇਠਾਂ ਦਿੱਤੇ product stance ਨੂੰ ਚੁਣਦੀ ਹੈ:
Security ਬੁਨਿਆਦੀ: tokens platform ਦੇ secure storage ਵਿੱਚ ਰੱਖੋ, least-privilege scopes ਵਰਤੋਂ, ਅਤੇ safe defaults ਨਾਲ ਭੇਜੋ (verbose logs ਨਾ, “remember me” encryption ਬਿਨਾਂ ਨਾ)।
Accessibility checks: contrast, minimum tap targets, dynamic text support, ਅਤੇ meaningful screen reader labels—ਖਾਸ ਕਰਕੇ icon-only ਬਟਨਾਂ ਅਤੇ custom components ਲਈ—ਸੰਭਾਲੋ।
Shipping ਉਹ ਹੈ ਜਿੱਥੇ ਇੱਕ ਵਾਅਦਾ prototype ਤੋਂ ਅਸਲੀ ਉਤਪਾਦ ਬਣ ਜਾਂਦਾ ਹੈ—ਜਾਂ ਚੁੱਪਚਾਪ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ AI UI, ਸਟੇਟ ਨਿਯਮ, ਅਤੇ API ਵਾਇਰਿੰਗ ਜਨਰੇਟ ਕਰ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ, ਲਕਸ਼ ਹੁੰਦਾ ਹੈ ਉਸ ਕੰਮਕਾਜੀ ਬਿਲਡ ਨੂੰ ਉਨ੍ਹਾਂ ਰਿਵਿਊਅਰਾਂ (ਅਤੇ ਗਾਹਕਾਂ) ਲਈ ਇੰਸਟਾਲ ਕਰਨਯੋਗ ਬਣਾਉਣਾ।
ਰਿਲੀਜ਼ ਨੂੰ ਇੱਕ ਛੋਟੀ ਚੈਕਲਿਸਟ ਮੰਨੋ, ਨ ਕਿ ਇੱਕ ਹੀਰੋਈਕ ਦੌੜ।
ਭਾਵੇਂ MVP ਸਧਾਰਨ ਹੋਵੇ, metadata ਦੀ ਮਹੱਤਤਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਮੀਦ ਸੈਟ ਕਰਦਾ ਹੈ।
ਲਾਂਚ ਨੂੰ ਇੱਕ ਪ੍ਰਯੋਗ ਵਾਂਗ ਤਿਆਰ ਕਰੋ।
ਪਹਿਲਾਂ internal testing ਵਰਤੋਂ, ਫਿਰ staged release (ਜਾਂ phased rollout) ਲਗਾਓ ਤਾਂ ਕਿ ਬਲਾਸਟ ਰੇਡੀਓ ਘੱਟ ਰਹੇ। crash rate, onboarding completion, ਅਤੇ ਮੁੱਖ action conversion ਨਿਗਰਾਨੀ ਕਰੋ।
Rollback triggers ਪਹਿਲਾਂ ਤੋਂ define ਕਰੋ—ਉਦਾਹਰਣ: crash-free sessions ਇਕ ਪੱਧਰ ਤੋਂ ਹੇਠਾਂ ਜਾਉ, sign-in failures spike ਹੋਣ, ਜਾਂ primary funnel step rate ਤੇਜ਼ੀ ਨਾਲ ਘਟੇ।
ਜੇ ਤੁਹਾਡਾ build system snapshots ਅਤੇ quick rollback (ਉਦਾਹਰਨ ਲਈ, Koder.ai snapshots/rollback ਜਿਵੇਂ features ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ) ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ “undo” ਨੂੰ shipping ਦਾ ਇੱਕ ਨਾਰਮਲ ਹਿੱਸਾ ਮੰਨ ਸਕਦੇ ਹੋ—ਡਰਾਉਣ ਵਾਲੀ ਚੀਜ਼ ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ ਆਪਣੀ MVP ਚੈਕਲਿਸਟ ਨੂੰ ਇੱਕ ਦੁਹਰਾਇ ਯੋਗ release pipeline ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, pricing ਜਾਂ contact ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੇਖੋ।
ਜਦ AI ਸਕ੍ਰੀਨਾਂ, ਸਟੇਟ, ਅਤੇ API ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਦਾ ਡਰਾਫਟ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਕੰਮ ਗੁੰਮ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਸਥਾਨ ਬਦਲਦਾ ਹੈ। ਟੀਮਾਂ ਇਰਾਦੇ ਨੂੰ ਬੋਇਲਰਪਲੇਟ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ 'ਤੇ ਘੱਟ ਸਮਾਂ ਲਗਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਫੈਸਲੇ ਕਰਨ 'ਤੇ ਲਗਦੀਆਂ ਹਨ ਕਿ ਕੀ ਬਣਾਉਣਾ ਹੈ, ਕਿਸ ਲਈ, ਅਤੇ ਕਿਸ ਮਿਆਰ ਤੇ।
AI ਇੱਕ ਵਾਰੀ ਫਲੋ ਸਪੱਸ਼ਟ ਹੋਣ 'ਤੇ ਪਾਰ-ਲੈਅਰ ਕੌਹਿਰ ਨੂੰ ਸੰਗਤ ਰੱਖਣ ਵਿੱਚ ਖਾਸ ਤੌਰ 'ਤੇ ਮਜ਼ਬੂਤ ਹੈ।
AI ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹੈ; ਫ਼ੈਸਲਾ ਮਨੁੱਖ ਕਰਦਾ ਹੈ।
ਰਫ਼ਤਾਰ ਤਦই ਮਦਦ ਕਰਦੀ ਹੈ ਜਦ ਕੋਡ ਪੜ੍ਹਨਯੋਗ ਰਹੇ।
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾ ਵਰਜਨ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਪ੍ਰਯੋਗਿਕ maintainability ਖੋਲ੍ਹਣ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ source code export ਕਰ ਸਕਦੇ ਹੋ: ਤੁਸੀਂ “ਤੇਜ਼ ਜਨਰੇਸ਼ਨ” ਤੋਂ “ਟੀਮ-ਮਲਕੀਅਤ ਕੋਡਬੇਸ” ਵਿੱਚ ਬਿਨਾਂ ਮੁੜ-ਲਿਖੇ ਸਵਿੱਚ ਕਰ ਸਕਦੇ ਹੋ।
MVP ਸ਼ਿਪ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਅਗਲੀਆਂ ਦੁਹਰਾਈਆਂ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ (startup time, list rendering), ਵਿਆਕਤੀਕਰਨ (saved preferences, smarter defaults), ਅਤੇ ਗਹਿਰੇ ਆਟੋਮੇਸ਼ਨ (test generation, analytics instrumentation) 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੀਆਂ ਹਨ।
ਹੋਰ ਉਦਾਹਰਣਾਂ ਅਤੇ ਸੰਬੰਧਤ ਪੜ੍ਹਾਈ ਲਈ, blog ਦੇਖੋ।
ਇਰਾਦਾ ਇੱਕ ਇਕ-ਵਾਕੀ ਵਿਆਖਿਆ ਹੈ ਜੋ ਸਾਫ਼ ਕਰਦੀ ਹੈ:
ਇਹ ਫੀਚਰ ਲਿਸਟ ਨਹੀਂ; ਇਹ ਸਫਲਤਾ ਦੀ ਪਰਿਭਾਸ਼ਾ ਹੈ ਜੋ UI, ਸਟੇਟ ਅਤੇ APIs ਨੂੰ ਇਕਸਾਰ ਰੱਖਦੀ ਹੈ।
ਇੱਕ ਚੰਗਾ ਇਰਾਦਾ ਬਿਆਨ ਵਿਸ਼ੇਸ਼ ਅਤੇ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹੁੰਦਾ ਹੈ। ਇਹ ਰਚਨਾ ਵਰਤੋ:
ਉਦਾਹਰਣ: “Help small clinic managers confirm appointments automatically so no-shows drop without adding admin work.”
“Shippable” ਦਾ ਮਤਲਬ ਹੈ ਐਪ ਇੱਕ ਮੁੱਖ ਯਾਤਰਾ ਨੂੰ ਅਸਲੀ ਡੇਟਾ ਨਾਲ ਮੁਕੰਮਲ ਕਰਦਾ ਹੈ:
ਜੇ ਉਪਭੋਗਤਾ ਮੁੱਖ ਕਾਰਜ ਫੋਨ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਪੂਰਾ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਤਿਆਰ ਨਹੀਂ ਹੈ।
AI ਤੋਂ ਪੁੱਛੋ ਕਿ ਤੁਹਾਡੇ ਵਿਚਾਰ ਨੂੰ ਲਿਖੇ:
ਫਿਰ ਨਤੀਜੇ ਨੂੰ ਆਪਣੇ ਡੋਮੇਨ ਹਕੀਕਤ ਨਾਲ ਸੋਧੋ—ਖ਼ਾਸ ਕਰਕੇ ਨੰਬਰ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਾਰਜਾਂ ਨਾ ਕਿ ਸਰਗਰਮੀ ਮਾਪੋ।
ਕੇਂਦਰਿਤ ਰਹੋ:
Acceptance criteria ਨੂੰ ਦ੍ਰਿਸ਼ਯਮਾਨ ਰੱਖੋ (ਜਿਵੇਂ “saved timestamp,” “next step required OR note required”) ਤਾਂ ਕਿ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ QA ਤੇਜ਼ੀ ਨਾਲ validate ਕਰ ਸਕਣ।
ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ ਉਹ ਸਭ ਕੁਝ ਕੱਟੋ ਜੋ ਨਾਰਥ-ਸਟਾਰ ਫਲੋ ਨੂੰ ਸਹਿਯੋਗ ਨਹੀਂ ਦਿੰਦਾ। ਆਮ MVPੋਂ ਵਿੱਚ ਛੱਡੇ ਜਾਣ ਵਾਲੇ ਚੀਜ਼ਾਂ:
ਇੱਕ explicit “out of scope” ਸੂਚੀ ਲਿਖੋ ਤਾਂ ਕਿ stakeholder ਜਾਣਨ ਕਿ ਕੀ ਜੀਅਨ-ਕਾਰਨ ਤੌਰ 'ਤੇ ਮੁਲਤਵੀ ਕੀਤਾ ਗਿਆ ਹੈ।
3–7 ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਪ੍ਰਾਇਮਰੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਪੂਰਾ ਕਰਦੀਆਂ ਹਨ:
ਨੈਵੀਗੇਸ਼ਨ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (tabs vs. stack) ਅਤੇ empty states ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਕਿ ਜਦੋਂ ਡੇਟਾ ਨਾ ਹੋਵੇ ਤਾਂ ਐਪ ਟੁੱਟੀ ਭਾਵ ਨਾ ਦੇਵੇ।
ਸਟੇਟ ਉਹ ਹੈ ਜੋ ਐਪ ਨੂੰ ਯਾਦ ਰੱਖਣਾ ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਮ MVP ਸਟੇਟ ਆਬਜੈਕਟ:
ਸਕ੍ਰੀਨਾਂ ਤੋਂ ਵਪਸੀ ਕੰਮ ਕਰੋ:
GET /items (ਅਕਸਰ paginated)POST ਜਾਂ PATCHDELETEAI schemas ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ required fields, permissions, ਅਤੇ naming mismatches (ਜਿਵੇਂ vs. ) ਦੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਪਹਿਲਾਂ ਕਿ ਉਹ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਸਥਿਰ ਹੋਣ।
ਹਰੇਕ ਕਿਰਿਆ ਨੂੰ ਲੇਬਲ ਕਰੋ ਕਿ ਉਹ offline-safe ਹੈ ਜਾਂ connection-required। ਇੱਕ ਕਾਰਗਰ ਡਿਫਾਲਟ:
Permissions ਨੂੰ ਲੋੜ ਦੇ ਸਮੇਂ 'ਤੇ ਪੁੱਛੋ (camera ਜਦੋਂ ਕਿ "Add photo" ਉੱਪਰ ਟੈਪ), ਅਤੇ fallback ਦਿਓ (manual entry, in-app reminders) ਨਾ ਕਿ dead ends।
ਐਸਿੰਕ ਲਈ ਸਾਧਾਰਣ ਅਵਸਥਾਵਾਂ ਸਥਿਰ ਕਰੋ: loading → success → failure, ਅਤੇ ਨਾਕਾਮੀ 'ਤੇ ਉਪਭੋਗਤਾ ਦੀ ਇਨਪੁਟ ਰੱਖੋ।
photoUrlavatar_url