पर्सोना और टास्क-फ्लो सोच: Alan Cooper की सरल विधि

क्यों फीचर सूचियाँ अच्छी स्क्रीन में नहीं बदलतीं

एक लंबी फीचर सूची प्रगति जैसा महसूस कराती है। आप उस पर इशारा कर सकते हैं और कह सकते हैं, “हमें पता है हम क्या बना रहे हैं।” फिर जब आप पहली स्क्रीन स्केच करने की कोशिश करते हैं तो महसूस होता है कि वह सूची यह नहीं बताती कि उपयोगकर्ता अभी क्या कर रहा है, वह क्या पूरा करने की कोशिश कर रहा है, या ऐप को पहले क्या दिखाना चाहिए।

फीचर सूचियाँ प्राथमिकताओं को छिपाती हैं। “Notifications,” “search,” “profiles,” और “settings” सब महत्वपूर्ण लगते हैं, इसलिए हर चीज़ एक ही स्तर पर आ जाती है। वे इरादे भी छिपाते हैं। लोग सुबह उठकर “filters” या “admin roles” नहीं चाहते। वे अपॉइंटमेंट बुक करना चाहते हैं, पैसे लेना चाहते हैं, डिलीवरी ट्रैक करना चाहते हैं, या परिवार के साथ फ़ोटो शेयर करना चाहते हैं।

इसीलिए फीचर सूची बनाम उपयोगकर्ता लक्ष्य सिर्फ़ एक योजना-विवाद नहीं है। यह स्क्रीन बदल देता है। अगर लक्ष्य है “शुक्रवार के लिए बाल काटने का अपॉइंटमेंट बुक करना,” तो पहली स्क्रीन को टाइम स्लॉट्स और एक स्पष्ट अगला कदम चाहिए, न कि दस फीचर्स का मेन्यू।

फीचर सूचियाँ टीमों को UI बहसों में बहुत जल्दी खींच लाती हैं। लोग बटन की जगह, टैब नाम, डार्क मोड, और कितने सेटिंग्स पेज होने चाहिए पर बहस करते हैं। वे विकल्प ठोस लगते हैं, पर वे अनुमान होते हैं—उससे पहले कि आप यह तय कर लें कि ऐप किस काम में किसी की मदद करेगा।

एक बेहतर शुरुआत सरल है: एक असली उपयोगकर्ता चुनें, एक काम चुनें जिसे वे एक बार में पूरा करना चाहते हैं, और उन सबसे छोटे चरणों का नक़्शा बनाएं जो उन्हें पूरा करने तक ले जाएँ। एक बार जब आप ऐसा कर लेते हैं, स्क्रीन स्वाभाविक रूप से उभरने लगती हैं। हर स्क्रीन अपनी जगह कमाती है क्योंकि वह फ्लो के किसी कदम का समर्थन करती है।

Alan Cooper का मूल विचार: फीचर्स के बजाय लक्ष्यों के इर्द-गिर्द डिज़ाइन करें

Alan Cooper ने एक बदलाव को लोकप्रिय किया जो आज भी प्रासंगिक है: सॉफ़्टवेयर को फीचर्स के ढेर की तरह न समझें, बल्कि उसे एक इंटरैक्शन की तरह देखें। मुद्दा यह नहीं है कि आपका ऐप क्या कर सकता है। मुद्दा यह है कि एक व्यक्ति क्या पूरा करने की कोशिश कर रहा है, और क्या ऐप उसे न्यूनतम घर्षण के साथ वह काम करने में मदद करता है।

यह मानसिकता आज कई लोग Alan Cooper इंटरैक्शन डिज़ाइन कहकर संदर्भित करते हैं। इरादा और क्रम पर ध्यान दें। अगर आप यात्रा को स्पष्ट रूप से वर्णित कर सकते हैं, तो स्क्रीन लगभग अपने आप डिज़ाइन हो जाती हैं। अगर आप नहीं कर सकते, तो लंबी फीचर सूची आपकी मदद नहीं करेगी—यह अक्सर अव्यवस्था पैदा करती है क्योंकि हर फीचर निर्णय, बटन और एज केस जोड़ता है।

Cooper का व्यावहारिक टूलकिट दो हिस्सों में है:

• पर्सोना (कौन): किसी विशिष्ट प्रकार के उपयोगकर्ता को चुनें और उन्हें इतना वास्तविक बनाएँ कि आप अनुमान लगा सकें वे क्या करेंगे।
• टास्क फ्लो (कैसे): उन सबसे कम चरणों का नक़्शा बनाएं जो उस पर्सोना को इरादे से परिणाम तक ले जाएँ।

एक फ्लो आपको उन सवालों का जवाब देने के लिए मजबूर करता है जिनसे फीचर सूची बचती है: क्या ट्रिगर है, “सक्सेस” कैसा दिखता है, उपयोगकर्ता को अभी कौन सा निर्णय लेना है, और हर चरण में वास्तव में किन जानकारियों की ज़रूरत है।

अगर आप चैट-आधारित vibe-coding प्लेटफ़ॉर्म जैसे Koder.ai के साथ बिल्ड करने की योजना बना रहे हैं, तब भी आपको वह स्पष्टता चाहिए। वरना आप बहुत सी स्क्रीन जनरेट करेंगे जो संभाव्य दिखती हैं पर एक संतोषजनक शुरू से अंत तक के अनुभव में जुड़ी नहीं होतीं।

पर्सोना: पहले किस एक असली उपयोगकर्ता के लिए डिज़ाइन करें

पर्सोना उस व्यक्ति का संक्षिप्त, भरोसेमंद विवरण है जिसके लिए आप सबसे पहले डिजाइन कर रहे हैं। यह किसी की पूरी जीवनी नहीं है—बस उतनी जानकारी कि आप बार-बार “यह निर्भर करता है” न कहें।

शुरुआत लक्ष्यों और संदर्भ से करें, जनसांख्यिकीय से नहीं। वही “व्यस्त माता-पिता” उपकरण और परिस्थिति के हिसाब से अलग व्यवहार करते हैं। अच्छे पर्सोनास प्रोडक्ट डिज़ाइन के लिए उन बाधाओं को ठोस बनाते हैं ताकि आपकी स्क्रीन का उद्देश्य स्पष्ट रहे।

अगर आपका पर्सोना बहुत अस्पष्ट है, तो आप उसे महसूस करेंगे। वह “हर किसी” जैसा लगने लगेगा, यह ज्यादातर जनसांख्यिकी बन जाएगा, यह प्राथमिकताओं की सूची बन जाएगा बिना स्पष्ट लक्ष्य के, और यह समझा नहीं पाएगा कि यह व्यक्ति आज ऐप क्यों उपयोग करेगा।

पर्सोना को हल्का रखें। कुछ पंक्तियाँ पर्याप्त हैं:

• कौन है (भूमिका),
• कब और कहाँ ऐप इस्तेमाल करते हैं (संदर्भ),
• उनका मुख्य लक्ष्य (सपाट भाषा में),
• आज उन्हें क्या धीमा करता है (दर्द बिंदु),
• “सक्सेस” कैसा दिखता है (सरल, परखने योग्य जीत)।

उदाहरण: “मिना, एक डेंटल रिसेप्शनिस्ट, मरीजों के बीच में अपने फोन का उपयोग करती है। उसका लक्ष्य अगली सुबह के अपॉइंटमेंट्स जल्दी पुष्टि करना है। उसकी दिक्कत जवाब न मिलने वाली लोगों का पीछा करना है। सफलता है एक मिनट से कम में रिमाइंडर भेजना और स्पष्ट ‘confirmed’ स्टेटस देखना। ”

एक और नियम: पर्सोना डिज़ाइन टूल है, आदर्श ग्राहक प्रोफ़ाइल नहीं। आपके पास बाद में कई ऑडियंस हो सकती हैं, पर अभी एक प्राथमिक पर्सोना चाहिए। जब लोग किसी स्क्रीन पर बहस करें, तो उसे फिर से Mina की ओर ले आएँ: क्या यह उसे उसके असली संदर्भ में लक्ष्य पहुँचाने में मदद करता है, या यह सिर्फ एक और फ़ीचर है?

टास्क फ्लो: जिन चरणों की मायने रखती है उनका नक़्शा बनाइए

टास्क फ्लो वह सबसे छोटा चरणों का सेट है जो किसी व्यक्ति को एक स्पष्ट लक्ष्य तक पहुँचाता है। यह साइटमैप नहीं है, न ही फीचर सूची, और न ही पूरा जर्नी मैप। यह “मैं X करना चाहता हूँ” से “X पूरा हो गया” तक का एक रास्ता है।

एक अच्छा फ्लो ट्रिगर से शुरू होता है और सक्सेस स्टेट पर समाप्त होता है। ट्रिगर वह है जो उपयोगकर्ता को शुरू करता है: एक ज़रूरत, एक संदेश, एक बटन, या कोई समस्या। सक्सेस स्टेट यह है कि “किया हुआ” साधारण भाषा में कैसा दिखता है: “अपॉइंटमेंट बुक और कन्फ़र्म किया गया”, “इनवॉइस भेजा गया”, या “पासवर्ड बदला और मैं साइन इन हूँ।” अगर आप दोनों को एक-एक वाक्य में नहीं बता सकते, तो फ्लो अभी भी धुंधला है।

शुरूआत, अंत, और बीच के निर्णय

अधिकांश फ्लो सरल होते हैं जब तक कोई निर्णय सामने न आ जाए। निर्णय वे फोर्क हैं जो आगे क्या होगा बदल देते हैं, जैसे “क्या आपके पास पहले से अकाउंट है?” या “क्या यह आइटम स्टॉक में है?” उन फोर्क्स को पहले से उजागर करने से आप एक परफेक्ट हैप्पी पाथ डिज़ाइन करने से बचते हैं जो असली दुनिया आने पर टूट जाता है।

एक फ्लो को ज़्यादा सोचे बिना आकार देने के लिए पाँच सवालों के उत्तर दें:

• टास्क क्या शुरू करता है?
• एकल सफलता पल क्या है?
• कौन सी जानकारी आवश्यक है (और क्या वैकल्पिक है)?
• कौन से निर्णय पथ बदल सकते हैं?
• क्या गलत हो सकता है, और गलत होने पर उपयोगकर्ता को क्या दिखना चाहिए?

जहाँ उपयोगकर्ताओं को आश्वासन चाहिए

लोग तब टास्क छोड़ देते हैं जब उन्हें अनिश्चितता महसूस होती है। आपका फ्लो उन क्षणों को चिह्नित करे जहाँ आश्वासन जरूरी है: प्रोग्रेस, स्टेटस, कन्फ़र्मेशन, और स्पष्ट एरर।

सरल उदाहरण है “पासवर्ड रीसेट करें।” ट्रिगर: “मैं लॉग इन नहीं कर पा रहा हूँ।” सक्सेस: “मैं अपने अकाउंट में वापस हूँ।” निर्णय: “क्या आपके पास ईमेल एक्सेस है?” आश्वासन के बिंदु: “ईमेल भेजा गया”, “लिंक एक्सपायर हो गया”, “पासवर्ड बदला गया”, “आप साइन इन हैं।” एक बार ये लिख दिए जाएँ, स्क्रीनें स्पष्ट हो जाती हैं क्योंकि हर स्टेप के लिए एक जगह और एक संदेश चाहिए जो संदेह मिटा दे।

एक हल्की विधि: अस्पष्ट आइडिया से स्पष्ट पहला फ्लो तक

अधिकांश ऐप आइडियाज़ संज्ञाओं का ढेर होते हैं: डैशबोर्ड, चैट, कैलेंडर, पेमेंट्स। स्पष्टता की तेज़ राह है आइडिया को एक प्रॉमिस, एक व्यक्ति, और कुछ चरणों के अनुक्रम में ज़बरदस्ती ढालना।

एक वाक्य से शुरू करें जिसे आप फ्रंट पेज पर रख सकते हैं। इसे इतना विशिष्ट बनाइए कि कोई सहमति या असहमति जताए। उदाहरण: “फ्रीलांस डिज़ाइनरों को 2 मिनट से कम में एक साफ़ इनवॉइस भेज कर और कार्ड पेमेंट लेकर तेज़ी से पैसे मिलने में मदद करें।”

फिर वर्ज़न-वन के लिए एक प्राथमिक पर्सोना चुनें। “हर कोई” नहीं, “छोटे व्यवसाय” नहीं। किसी व्यक्ति का चुनाव करें जिसे आप सामान्य मंगलवार की सोच कर चित्रित कर सकें। अगर आप तीन अलग लोगों के लिए एक साथ डिज़ाइन करेंगे तो आप अतिरिक्त स्क्रीन जोड़ देंगे जो किसी के भी काम नहीं आतीं।

अगला, पहले डिज़ाइन करने के लिए एक लक्ष्य चुनें—आम तौर पर वह जो मुख्य वैल्यू बनाता है। “संगठित महसूस करना” अस्पष्ट है। “एक इनवॉइस भेजना और देखने की पुष्टि करना कि इसे देखा गया” स्पष्ट है।

एक दोहराने योग्य प्रक्रिया इस तरह दिखती है:

1. एक-वाक्य वादा लिखें (कौन + परिणाम + समय/प्रयास)।
2. प्राथमिक पर्सोना और एक मुख्य प्रतिबंध परिभाषित करें (समय, डिवाइस, कौशल)।
3. हैप्पी पाथ को छोटे क्रियाओं में लिखें (choose, enter, review, confirm, pay)।
4. 2–3 वास्तविक विफलता क्षण जोड़ें ताकि फ्लो टूटे नहीं।

केवल जब फ्लो एक पन्ने पर फिट हो तब फीचर सूची लिखें। इसे छोटा और प्राथमिकता-युक्त रखें: वे कुछ फीचर्स जो कदमों को संभव बनाते हैं, और विफलताओं से उबरने के लिए न्यूनतम आवश्यक चीज़ें।

अगर आप Koder.ai जैसे बिल्ड टूल का उपयोग कर रहे हैं, तो यही वह जगह है जहाँ प्लानिंग मोड मदद करता है। वादा, पर्सोना और फ्लो को एक जगह पेस्ट करें और टीम को स्क्रीन और कोड के बनने से पहले संरेखित रखें।

UI पर ज़्यादा सोचे बिना फ्लो को स्क्रीन और क्रियाओं में बदलना

एक टास्क फ्लो इरादों का क्रम है। अब हर स्टेप को या तो एक स्क्रीन में बदलें जहाँ उपयोगकर्ता आएगा, या एक सिंगल एक्शन जहाँ वे मौजूदा स्क्रीन पर कुछ करेंगे।

साफ़-साफ़ रखें: एक स्टेप = एक स्पष्ट परिणाम। अगर किसी स्टेप के दो परिणाम हैं, तो आम तौर पर वह दो स्टेप होते हैं।

स्क्रीन को उद्देश्य के नाम दें, लेआउट के हिस्सों के नाम नहीं। “Pick time” बेहतर है बजाय “Calendar screen.” “Confirm details” बेहतर है बजाय “Form page.” उद्देश्य-नाम आपको यह याद दिलाते हैं कि स्क्रीन क्या करानी चाहिए, न कि कैसे दिखनी चाहिए।

जब आप फ्लो को स्क्रीन में बदलें, तो हर स्टेप के लिए तीन चीज़ें तय करें: उपयोगकर्ता को क्या देखना चाहिए, उन्हें क्या चुनना चाहिए, और उन्हें क्या दर्ज करना चाहिए। फिर अगला स्पष्ट एक्शन चुनें (अक्सर एक प्राथमिक बटन)। जो भी चीज़ उन्हें उस स्टेप को पूरा करने में मदद नहीं करती, उसे हटा दें।

नेविगेशन नीरस होना चाहिए। हर स्क्रीन का जवाब होना चाहिए: “अगला क्या करूँ?” अगर किसी को अगला कदम समझने के लिए मेन्यू चाहिए, तो स्क्रीन बहुत कुछ करने की कोशिश कर रही है।

साथ ही बुनियादी स्टेट्स को नोट्स के रूप में पकड़ लें, न कि पूरे डिज़ाइन के रूप में: लोडिंग, खाली, सफलता, त्रुटि, और कब मुख्य क्रिया डिसेबल होनी चाहिए। आप चाहते हैं कि टीम इन स्टेट्स को निर्माण के दौरान याद रखे, न कि रंगों पर दिनों-दिन बहस करे।

Koder.ai जैसे टूल आपकी फ्लो टेक्स्ट से स्क्रीन ड्राफ्ट करने में मदद कर सकते हैं, पर स्पष्टता फिर भी आपसे आती है: उद्देश्य, आवश्यक जानकारी, और अगला एक्शन।

उदाहरण: “एक बुकिंग ऐप” को संगठित स्क्रीन सेट में बदलना

मान लीजिए आप एक साधारण ऐप चाहते हैं जिससे लोग लोकल क्लास (योगा, ट्यूशन, हेरकट) बुक कर सकें। एक फीचर सूची कह सकती है “search, calendar, payments, reminders.” यह अभी भी नहीं बताती कि पहली स्क्रीन क्या है, या किसी ने “Book” पर टैप करने के बाद क्या होता है।

एक पर्सोना से शुरू करें: Sam, एक व्यस्त माता-पिता, फोन पर पार्किंग लॉट में खड़ा है और 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-सेकंड लक्ष्य को वास्तविक बनाइए।

सामान्य जालें जो फ्लो को तोड़ देती हैं

फ्लो आमतौर पर एक ही कारण से टूटते हैं: आप भीड़ के लिए डिज़ाइन कर रहे हैं, न कि एक व्यक्ति के लिए। जब पर्सोना “हर कोई” बन जाता है, हर निर्णय समझौता बन जाता है। एक उपयोगकर्ता गति चाहता है, दूसरा मार्गदर्शन, तीसरा पूरा नियंत्रण। परिणाम एक ऐसा फ्लो है जो सबको संतुष्ट नहीं करता।

इसे ठीक करने का तरीका है पर्सोना को संकुचित करना जब तक विकल्प स्पष्ट न हो जाएँ। न कि “व्यस्त प्रोफेशनल्स,” बल्कि “एक रिसेप्शनिस्ट जो फोन कॉल के बीच अपॉइंटमेंट बुक करती है,” या “एक माता-पिता जो बच्चे के बाल कटवाने के लिए क्रैक्ड फोन स्क्रीन पर बुक करता है।” जब आप उनके दिन का चित्र बना सकते हैं, तब आप तय कर सकते हैं क्या काटना है।

एक और विफलता मोड है वह जहाँ आप उस चीज़ से शुरू करते हैं जिसे आप स्टोर कर सकते हैं बजाय उस के जिसे कोई करना चाहता है। अगर आपकी पहली ड्राफ्ट डेटाबेस फ़ील्ड्स और आंतरिक एडमिन स्टेप्स पर आधारित है, तो प्रोडक्ट लंबे फॉर्म्स में बदल जाता है और मुख्य टास्क दब जाता है। लोग “फ़ील्ड्स भरना” नहीं चाहते; वे बुकिंग कन्फ़र्म करना, भुगतान करना, रिमाइंडर पाना चाहते हैं।

तीसरा जाल है “एक्स्ट्रा पहले” सोच। सेटिंग्स, प्रेफ़रेंसेज़, रोल्स, टैग्स और कस्टमाइज़ेशन सूचीबद्ध करना आसान है, इसलिए वे जल्दी घुस आते हैं। पर अगर कोर टास्क कमजोर है, एक्स्ट्रा बस और रास्ते और भ्रम जोड़ते हैं।

अगर आप Koder.ai से स्क्रीन तेज़ी से जेनरेट कर रहे हैं, वही जोखिम लागू होता है: गति तब ही उपयोगी है जब आप फ्लो को सच्चा रखें—एक पर्सोना, एक लक्ष्य, हर स्क्रीन पर एक स्पष्ट अगला कदम।

बिल्ड शुरू करने से पहले त्वरित चेकलिस्ट

डिज़ाइन टूल खोलने या कोडिंग शुरू करने से पहले एक पास कर लें कि आपका आइडिया वास्तव में स्क्रीन में बदल सकता है जिन्हें लोग पूरा कर सकें।

आपको प्राथमिक पर्सोना का लक्ष्य एक वाक्य में स्पष्ट समाप्ति रेखा के साथ कहने में सक्षम होना चाहिए: “शनिवार को 11 बजे के लिए हेयरकट बुक करें और एक कन्फ़र्मेशन पाएं।” हैप्पी पाथ एक पन्ने पर फिट होना चाहिए। अगर यह फैलता है, तो आपने शायद दो टास्क मिला दिए हैं या कई पर्सोनास के लिए हल ढूँढ रहे हैं।

जाँचें कि हर स्क्रीन का नाम उद्देश्य के अनुसार है और इसे किसी फ्लो स्टेप से जोड़ा गया है (उद्देश्य विजेट्स से बेहतर है)। निर्णय और कन्फ़र्मेशन स्पष्ट बनाएं, न कि निहित। अगर उपयोगकर्ता को कुछ चुनना है, तो विकल्प दिखाइए। अगर कुछ महत्वपूर्ण हुआ है, तो कन्फ़र्मेशन या स्पष्ट एरर दिखाइए।

फिर जो भी टास्क को आगे नहीं बढ़ाता काट दीजिए। अगर कोई स्क्रीन उपयोगकर्ता को निर्णय लेने, जानकारी दर्ज करने, भुगतान करने, या कन्फ़र्म करने में मदद नहीं करती, तो वह अक्सर पहले वर्ज़न के लिए शोर है।

फ़्लो को ज़ोर से पढ़िए जैसे कहानी: “मैं X चाहता हूँ, मैं A करता हूँ, फिर B, फिर मैं कन्फ़र्म करता हूँ, फिर मैं पूरा हूँ।” जहाँ भी आप अटकते हैं, वही डिज़ाइन की समस्या है।

अगर आप Koder.ai का उपयोग करते हैं, यह एक मजबूत प्रॉम्प्ट स्टार्ट है: एक-वाक्य लक्ष्य और हैप्पी-पाथ स्टेप्स पेस्ट करें, फिर न्यूनतम स्क्रीन और क्रियाएँ माँगे।

अगले कदम: पहला वर्ज़न प्लान करें और बिल्ड की ओर बढ़ें

वह एकल फ्लो चुनें जो सबसे अच्छा साबित करे कि आपका पर्सोना अपना लक्ष्य पहुँच सकता है। इसे अपनी रीढ़ की हड्डी मानें। जब तक यह end-to-end काम नहीं करता, बाकी सब वैकल्पिक है।

उस फ्लो को एक छोटी बिल्ड योजना में बदलें: उन कुछ स्क्रीन का सेट जिन्हें पर्सोना विज़िट करेगा, हर एक पर लिया जाने वाला एक्शन, सिस्टम को कितनी न्यूनतम जानकारी चाहिए, कुछ फेल्यर केस जिन्हें संभालना ज़रूरी है, और वह सक्सेस स्टेट जो “पूरा” की पुष्टि करे।

अब तय करें क्या काटना है। काटना अपने आप में न्यूनतम होने के लिए नहीं है; यह एक मुख्य लक्ष्य को सहज बनाने के बारे में है। अगर कोई फ़ीचर पर्सोना को आज फ्लो पूरा करने में मदद नहीं करता, तो उसे “बाद में” भेज दें।

योजना को सत्यापित करें खुद करके। पर्सोना विवरण पढ़ें, फिर स्टेप्स को उस व्यक्ति की तरह चलाएँ। गायब जानकारी तुरंत दिख जाएगी: तिथि कहाँ से आई? मैं अपना चुनाव कैसे बदलूँ? अगर मैंने गलती की तो क्या होगा?

अगर आप तेज़ी से आगे बढ़ना चाहते हैं, तो Koder.ai के प्लानिंग मोड का उपयोग करें ताकि आप चैट में पर्सोना और फ्लो पर iterate कर सकें इससे पहले कि आप स्क्रीन जेनरेट करें। एक बार बिल्ड शुरू होने पर, स्नैपशॉट और रोलबैक जैसे फीचर्स आपको साहस के साथ टेस्ट करने और अगर कोई छोटा बदलाव रास्ता तोड़े तो तेज़ी से वापस आने में मदद कर सकते हैं।