ऐप ऑनबोर्डिंग डिज़ाइन जो उपयोगकर्ताओं को वापस लाता है

लोग डेमो के बाद ऐप क्यों बंद कर देते हैं

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

यह वही जगह है जहाँ कई प्रोडक्ट लोगों को खो देते हैं। असली परीक्षा गाइडेड वॉकथ्रू नहीं है। यह पहला शांत सत्र है, जब उपयोगकर्ता के पास कोई गाइड नहीं, कोई तालियाँ नहीं, और अनुमान लगाने की सहनशीलता नहीं रहती।

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

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

पहला टास्क भी उतना ही महत्वपूर्ण है। अगर ऐप बहुत ज़्यादा सेटअप, बहुत पढ़ना, या कई निर्णय माँगता है, तो यह काम की तरह लगने लगता है इससे पहले कि उपयोगकर्ता को स्पष्ट परिणाम मिले। अक्सर वहां ही वापसी घट जाती है।

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

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

उपयोगकर्ताओं को पहले पाँच मिनट में क्या चाहिए

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

एक सरल वाक्य अक्सर पूरे टूर से बेहतर काम करता है। "चैट करके अपने विचार को काम करने वाले ऐप में बदलें" लोगों को परिणाम दिखाता है, फीचर-लिस्ट नहीं। वे सफलता की कल्पना कर सकते हैं, और इससे पहले क्लिक के बाद छोड़ने की संभावना कम हो जाती है।

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

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

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

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

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

पहले सत्र की योजना कैसे बनाएं

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

स्क्रीन डिज़ाइन करने से पहले पहले सत्र का लक्ष्य चुनें। यदि आपका ऐप कई काम करता है, तो वह काम चुनिए जो समझने में आसान और पूरा करने में तेज़ हो। एक बजटिंग ऐप किसी को एक खर्च जोड़ने का मार्ग दिखा सकता है। एक टीम ऐप उन्हें एक साझा टास्क बनाने में मदद कर सकता है। पहला सत्र छोटा, स्पष्ट और पूरा महसूस होना चाहिए।

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

पहली क्रिया को उस जगह रखें जहाँ वह नजरअंदाज़ न हो सके। स्क्रीन को तुरंत एक सवाल का जवाब देना चाहिए: अब मुझे क्या करना है? मुख्य बटन या इनपुट को केंद्र में रखें, अतिरिक्त विकल्प घटाएँ, और अगला कदम स्पष्ट बनाइए। उदाहरण के लिए, Koder.ai जैसे प्रोडक्ट-बिल्डिंग टूल में बेहतर पहला सत्र उपयोगकर्ता से एक सरल ऐप आइडिया बताने और पहला ड्राफ्ट जेनरेट करने के लिए कहना होगा, न कि डिप्लॉयमेंट विकल्पों के बारे में सोचवाना।

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

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

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

खाली स्टेट्स को एक क्रिया की ओर इशारा कराएं

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

सादा भाषा से शुरू करें। "No data found" जैसी अस्पष्ट लाइन के बजाय कहें कि यह क्षेत्र किसके लिए है: "आपकी प्रोजेक्ट में अभी टास्क नहीं हैं" या "आपने अभी तक पहला पेज नहीं जोड़ा है।" इससे लोगों को स्क्रीन समझने में मदद मिलती है बिना अनुमान लगाए।

फिर उन्हें एक मुख्य क्रिया दीजिए। तीन बटन नहीं। प्रतिस्पर्धी विकल्पों की एक पंक्ति नहीं। एक बटन ही अक्सर काफ़ी होता है, जैसे "Create first task" या "Add your first page." शुरुआती हिचक अक्सर ड्रॉप-ऑफ में बदल जाती है, इसलिए स्पष्टता विविधता से ज़्यादा मायने रखती है।

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

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

Koder.ai जैसे प्लेटफ़ॉर्म पर, नया उपयोगकर्ता एक फ्रेश प्रोजेक्ट खोल सकता है और खाली वर्कस्पेस देख सकता है। एक बेहतर संदेश होगा: "आपके ऐप में अभी स्क्रीन नहीं हैं। एक स्क्रीन से शुरुआत करें और बाद में एडिट करें।" मुख्य बटन कह सकता है "Create first screen," और पास में एक साधारण बेसिक लेआउट प्रीव्यू दिखाइए।

एक जल्दी से चेक करें:

• स्क्रीन पर क्या आता है, उसका नाम बताइए।
• एक स्पष्ट अगली क्रिया ऑफ़र करें।
• क्लिक के बाद परिणाम दिखाएँ या उसका वर्णन करें।

टोन शांत और सटीक रखें। उद्देश्य चालाक नहीं लगना है, उद्देश्य लोगों को आगे बढ़ाने में मदद करना है।

ऐसे फर्स्ट-रन टास्क चुनें जिन्हें लोग जल्दी पूरा कर सकें

सबसे अच्छे फर्स्ट-रन टास्क एक साधारण बात करते हैं: वे किसी को जल्दी छोटी जीत दिलाते हैं। लोग तब रुकते हैं जब उन्हें प्रगति दिखती है, न कि जब उनसे पहले सब कुछ सीखने को कहा जाए।

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

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

पहले-रन टास्क का सरल परीक्षण यह है:

• क्या नया उपयोगकर्ता इसे तीन मिनट से कम में पूरा कर सकता है?
• क्या यह कुछ वास्तविक बनाता है, सिर्फ़ एक चेकबॉक्स नहीं?
• क्या परिणाम अगला कदम आसान करेगा?
• क्या एडवांस्ड विकल्प बाद में हो सकते हैं?

नकली ट्रेनिंग टास्क अक्सर मदद से ज़्यादा नुकसान करते हैं। अगर कोई नकली डेमो में क्लिक करके सैंपल डेटा भरता है जिसे वे कभी उपयोग नहीं करेंगे, तो प्रयास व्यर्थ लगता है। असली प्रगति, भले ही छोटी हो, बेहतर है।

उदाहरण के लिए, Koder.ai पर एक मज़बूत पहला टास्क है "एक प्रॉम्प्ट से अपनी पहली सरल ऐप स्क्रीन बनाएं" बजाए इसके कि उपयोगकर्ता से पूरा वर्कस्पेस सेटअप करवाया जाए। उपयोगकर्ता को तेज़ी से वास्तविक आउटपुट मिलता है। कस्टम डोमेन, डिप्लॉयमेंट सेटिंग्स या टीम वर्कफ़्लो जैसे विकल्प पहले परिणाम बनने के बाद आ सकते हैं।

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

तेज़ टास्क आत्मविश्वास बनाते हैं। आत्मविश्वास दूसरे सत्र की दिशा देता है, और वहीं प्रोडक्ट अपनाना शुरू होता है।

संदेह घटाने वाली कॉपी और फीडबैक का उपयोग करें

अच्छी ऑनबोर्डिंग छोटे-छोटे हिचकियों को दूर करती है। जब लोग रुककर सोचते हैं, "यदि मैं इस पर टैप करूँ तो क्या होगा?" या "क्या यह काम हुआ?" तो गति तेज़ी से घटती है।

समाधान आमतौर पर सरल होता है। स्पष्ट शब्दों का उपयोग करें, अपेक्षाएँ सेट करें, और ऐसा फीडबैक दें जो अगला सवाल उठने से पहले उसका जवाब दे दे।

बताइए आगे क्या होगा

बटन को सिस्टम एक्शन के बजाय परिणाम बताना चाहिए। "Create my workspace" जैसा लेबल "Continue" से स्पष्ट है। "Generate landing page" "Run" से बेहतर है। जब लेबल उनके चाहने वाले परिणाम से मिले तो उपयोगकर्ता सुरक्षित महसूस करते हैं।

यह नियम प्रोडक्ट भाषा पर भी लागू होता है। आंतरिक शब्द आपके टीम के लिए ठीक हो सकते हैं, लेकिन नए उपयोगकर्ताओं के लिए वे संदेह पैदा करते हैं। अगर टूल कहता है "Initialize project context," तो कई लोग रुक जाएंगे। "Set up your app" आसान है। Koder.ai पर "Build your first screen" किसी नए उपयोगकर्ता के लिए उस लेबल से ज़्यादा स्पष्ट होगा जो मॉडल या एजेंट से जुड़ा हो।

समय के संकेत भी मदद करते हैं। अगर किसी कदम में लगभग 10 सेकंड लगते हैं, तो बताइए। अगर किसी सेटअप टास्क में लगभग दो मिनट लगते हैं, तो उसे शुरू करने से पहले बताइए। इससे तनाव कम होता है और ऐप अधिक ईमानदार लगता है।

पहले-रन कॉपी का एक सरल चेक:

• बटन में परिणाम का नाम लें।
• टीम जार्गन के बजाय रोज़मर्रा के शब्दों का प्रयोग करें।
• उपयोगकर्ताओं को बताइए आम तौर पर कितना समय लगेगा।
• यह भी बताइए कि उसके बाद वे क्या कर सकते हैं।

सक्सेस संदेश सिर्फ जश्न मनाने से कहीं ज़्यादा होना चाहिए। कॉन्फेट्टी मज़ेदार हो सकता है, लेकिन यह असली सवाल का जवाब नहीं देता: "क्या बदला?" एक बेहतर संदेश विशिष्ट होता है: "आपका प्रोजेक्ट तैयार है। अब आप होमपेज एडिट कर सकते हैं और जब चाहें प्रकाशित कर सकते हैं।" यह भरोसा और दिशा दोनों देता है।

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

अच्छा फेलियर फीडबैक तीन हिस्सा होना चाहिए:

• क्या गलत हुआ।
• इसे कैसे ठीक करें।
• ठीक करने के बाद क्या होगा।

इस तरह का फीडबैक लोगों को चलते रहने में मदद करता है। और जब पहला सत्र स्पष्ट और रिकवर करने योग्य लगे, तो वे दूसरे सत्र के लिए लौटने की अधिक संभावना रखते हैं।

साइन-अप से दूसरी विजिट तक का एक सरल उदाहरण

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

यहीं ऐप ऑनबोर्डिंग डिज़ाइन अपनी कीमत बताता है। स्क्रीन को उन्हें पूरा प्रोडक्ट सिखाने की ज़रूरत नहीं है। इसे उन्हें एक छोटा काम पूरा करने में मदद करनी चाहिए जो मायने रखता है।

पहली विजिट

साइन-अप के बाद फाउंडर खाली कॉन्टैक्ट पेज पर उतरता है। खाली टेबल और विकल्पों से भरे मेन्यू की बजाय पेज एक स्पष्ट क्रिया दिखाता है: Add your first contact.

बटन के नीचे एक छोटी लाइन बताती है कि यह क्यों मायने रखता है: एक लीड जोड़कर आप फॉलो-अप और डील ट्रैक कर सकते हैं। वह छोटा सा संदर्भ खाली स्टेट को अगले कदम में बदल देता है।

फाउंडर नाम, कंपनी और ईमेल जोड़ता है। फॉर्म छोटा रहता है, इसलिए टास्क पूरा करना आसान महसूस होता है। सेव करते ही ऐप एक उपयोगी सुझाव देता है: कल के लिए एक फॉलो-अप रिमाइंडर सेट करें।

यह इसलिए काम करता है क्योंकि पहली क्रिया दूसरी क्रिया बनाती है। फाउंडर बेतरतीब रूप से एक्सप्लोर नहीं कर रहा। वह वास्तविक परिणाम की ओर बढ़ रहा है: लीड को याद रखना।

दूसरी विजिट

जब वे अगले दिन लौटते हैं, तो उन्हें वही खाली-स्टाइल डैशबोर्ड या सामान्य वेलकम संदेश नहीं दिखना चाहिए। उन्हें अधूरा काम दिखना चाहिए।

ऐप एक सरल प्रॉम्प्ट के साथ खुल सकता है जैसे: आज Sarah Chen के लिए 1 फॉलो-अप देय है। अब फाउंडर को पता है कहाँ क्लिक करना है और डेमो पल के बाद भी ऐप क्यों मायने रखता है।

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

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

यहाँ कुछ भी चमकदार नहीं है। पर यह तेज़ी से उपयोगी लगता है, और वही प्रोडक्ट अपनाने में टिकने में मदद करता है।

बार-बार उपयोग कम करने वाली सामान्य गलतियाँ

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

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

खाली स्टेट्स का अक्सर गलत उपयोग होता है। कई प्रोडक्ट उन्हें सजावट की तरह इस्तेमाल करते हैं—एक दोस्ताना इलस्ट्रेशन और अस्पष्ट टेक्स्ट—पर कोई स्पष्ट क्रिया नहीं। एक बेहतर खाली स्टेट एक सवाल का जवाब देता है: अगला क्या करना है?

टीमें कहाँ गलत होती हैं

कुछ टीमें गलत पल का जश्न मनाती हैं। साइन-अप की पुष्टि आंतरिक रूप से अच्छा लगता है, पर उपयोगकर्ता के लिए इसका बहुत कम मतलब होता है। असली मील का पत्थर पहली वैल्यू है: पहला पूरा किया गया टास्क, पहला जनरेट किया गया रिज़ल्ट, पहला सेव्ड प्रोजेक्ट, या पहला उपयोगी आउटकम।

यह उन प्रोडक्ट्स में और भी मायने रखता है जहाँ लोग किसी लक्ष्य के साथ आते हैं—जैसे एक साधारण ऐप बनाना या किसी विचार की परख करना। Koder.ai में, रोमांचक पल खाते बनाने का नहीं है। यह है एक साधारण भाषा वाले प्रॉम्प्ट से काम करता पहला स्क्रीन, फीचर या प्रोटोटाइप मिलना।

एक और रिपीट-यूज़ किलर है टास्क पूरा होने के बाद अगला कदम छुपा देना। उपयोगकर्ता एक क्रिया पूरा करते हैं, सफलता संदेश देखते हैं और फिर कहीं ठहर जाते हैं। अच्छी ऑनबोर्डिंग गति बनाये रखती है।

एक सरल समीक्षा यह पकड़ने में मदद करती है:

• क्या उपयोगकर्ता पूर्ण सेटअप से पहले एक असली परिणाम पा सकते हैं?
• क्या मदद मुख्य काम के रास्ते से हटकर नहीं बैठी है?
• क्या हर खाली स्क्रीन एक स्पष्ट क्रिया की ओर इशारा करती है?
• क्या सफलता पंजीकरण नहीं बल्कि मूल्य से जुड़ी है?
• एक जीत के बाद अगला उपयोगी कदम क्या स्पष्ट है?

यदि किसी का जवाब नहीं है, तो आम तौर पर रिपीट उपयोग घटेगा। लोग मजबूत पहले सत्र के बाद लौटते हैं, लेकिन केवल तब जब प्रोडक्ट उन्हें लगातार बताता रहे कि आगे क्या करना है।

शिप करने से पहले तेज़ जाँचें

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

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

लॉन्च से पहले शॉर्ट चेकलिस्ट

इसे अंतिम पास के रूप में उपयोग करें:

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

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

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

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

समय के साथ ऑनबोर्डिंग में सुधार करें

ऑनबोर्डिंग का पहला संस्करण भी एक अनुमान ही होता है, भले ही वह अच्छा क्यों न हो। अगली अहम चीज़ यह देखना है कि असली लोग साइन-अप के बाद क्या करते हैं, खासकर पहले सत्र में और दूसरे दिन जब वे वापस आते हैं।

उन बिंदुओं से शुरू करें जहाँ लोग रुकते, निकल जाते, या वही क्रिया बार-बार करते हैं। यदि कई उपयोगकर्ता ऐप खोलते हैं, चारों ओर देखते हैं और पहली उपयोगी टास्क पूरा नहीं करते, तो समस्या आम तौर पर प्रेरणा नहीं होती। यह भ्रम, कमजोर मार्गदर्शन, या बहुत जल्दी बहुत सारे विकल्प होते हैं।

एक साधारण रिव्यू रिद्म मदद करता है:

• पहले पाँच मिनट में उपयोगकर्ता कहाँ रुक रहे हैं देखें।
• पहले सत्र की पूर्णता की तुलना दिन-दूसरे वापसी दर से करें।
• सपोर्ट या सेल्स से आने वाले सामान्य सवाल नोट करें।
• उन स्क्रीन पर ध्यान दें जहाँ लोग बहुत देर तक कुछ नहीं करते।

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

खाली स्टेट्स को भी साफ़ करने की ज़रूरत होती है। यदि उपयोगकर्ता बार-बार वही सवाल पूछते हैं, तो स्क्रीन शायद अपना काम नहीं कर रही। उसे फिर से लिखिए ताकि अगला कदम स्पष्ट हो। "No projects yet" के बजाय कहिए अब क्या करना है और उपयोगकर्ता उसे करने के बाद क्या पाएगा।

यदि आप Koder.ai के साथ बना रहे हैं, तो स्क्रीन जेनरेट करने से पहले ऑनबोर्डिंग प्लान करना मददगार है। इसका प्लानिंग मोड पहले-रन पाथ को साधारण भाषा में मैप करने में उपयोगी है: उपयोगकर्ता पहले क्या देखता है, अगला क्या करना चाहिए, और शुरुआती जीत क्या गिनी जाएगी। इससे UI बनने से पहले अतिरिक्त कदमों को पकड़ना आसान होता है।

परीक्षण तब भी आसान होता है जब परिवर्तन का जोखिम कम हो। Koder.ai में स्नैपशॉट्स और रोलबैक आपको छोटा चेकलिस्ट, अलग खाली स्टेट, या नया पहला टास्क बिना पुराने काम खोए आज़माने देते हैं। इससे ऑनबोर्डिंग प्रयोग तेज़ी से प्रबंधनीय बनते हैं।

एक स्वस्थ ऑनबोर्डिंग प्रक्रिया कभी पूरी तरह समाप्त नहीं होती। व्यवहार देखें, एक बदलाव करें, परिणाम नापें, और वही संस्करण रखें जो लोगों को तेजी से मूल्य तक पहुँचाने में मदद करे।