नॉन-डिज़ाइनर्स के लिए फॉर्म डिज़ाइन: लोग बीच में क्यों छोड़ देते हैं और इसे कैसे ठीक करें

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

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

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

लोग फॉर्म बीच में क्यों छोड़ देते हैं?

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

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

एक फॉर्म में कितनी फ़ील्ड्स होनी चाहिए?

जितनी कम हो सके, उतनी ही। फॉर्म छोड़े जाने की समस्या का सबसे बड़ा इलाज है फ़ील्ड्स को हटाना—उन्हें छोटा नहीं करना, उनका क्रम नहीं बदलना। बस उन्हें हटा देना।

एक दोस्त ने अपने क्लीनिंग बिज़नेस के लिए एक बुकिंग टूल बनाया। पहले वर्शन के फॉर्म में ग्यारह फ़ील्ड्स थीं: नाम, ईमेल, फोन, पता, स्क्वेयर फुटेज, बेडरूम्स की संख्या, बाथरूम्स की संख्या, पालतू जानवर, पसंदीदा तारीख, पसंदीदा समय, और “और कुछ।” लगभग किसी ने भी इसे पूरा नहीं किया। हमने इसे घटाकर तीन कर दिया—नाम, फोन, और “आपके लिए कौन-सा समय ठीक रहेगा?”—और बाकी सवाल उस कन्फर्मेशन कॉल में पूछने दिए जो वह वैसे भी करती थीं। बुकिंग्स तुरंत बढ़ गईं। बाकी आठ फ़ील्ड्स जानकारी इकट्ठा नहीं कर रही थीं; वे लोगों को उनका लीड मिलने से पहले ही डरा कर भगा रही थीं।

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

फॉर्म फ़ील्ड्स किस क्रम में होनी चाहिए?

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

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

फॉर्म की कौन-सी फ़ील्ड्स अनिवार्य होनी चाहिए?

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

अगर कोई फ़ील्ड वैकल्पिक हो सकती है, तो उसे वैकल्पिक बना दें। वह फोन नंबर जो आप “पाना पसंद करेंगे,” उस इंसान से ज़्यादा कीमती नहीं है जो उसे देना नहीं चाहता और इसकी बजाय फॉर्म छोड़कर चला जाता है।

फॉर्म वैलिडेशन एरर कैसे काम करने चाहिए?

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

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

फॉर्म को मोबाइल-फ्रेंडली कैसे बनाएं?

फोन पर दो चीज़ें सबसे ज़्यादा मायने रखती हैं, और फोन आलसी फॉर्म्स को माफ नहीं करते। पहला, सही कीबोर्ड माँगें: ईमेल फ़ील्ड पर वह कीबोर्ड आना चाहिए जिसमें @ चिन्ह हो, फोन फ़ील्ड पर नंबर पैड आना चाहिए। आपका बिल्डर यह सेट कर सकता है, और इससे टाइप करना एक झंझट से बदलकर सिर्फ़ एक टैप बन जाता है। दूसरा, तारीख के लिए एक असली डेट पिकर इस्तेमाल करें, बजाय इसके कि किसी को अंगूठों से “06/21/2026” टाइप करना पड़े—एक कैलेंडर जिसे टैप किया जाए, वह तेज़ होता है और कभी गलत फॉर्मेट में तारीख नहीं देता।

खुद यह करके देखें: अपने ऐप का फॉर्म अपने फोन पर खोलें और इसे ऐसे भरें जैसे आप जल्दी में एक अजनबी हों। रुकावटें करीब दस सेकंड में सामने आ जाएँगी।

फॉर्म सबमिट करने के बाद क्या होना चाहिए?

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

अपने बिल्डर से कैसे कहें

अगर आप स्पष्ट हों, तो इसमें से ज़्यादातर आप सीधे अपने AI बिल्डर को सौंप सकते हैं:

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

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

शिप करने से पहले फॉर्म को कैसे टेस्ट करें?

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