पेमेंट और पते का फ़ॉर्म इस्तेमाल करने के सबसे सही तरीके

अपने उपयोगकर्ताओं को पते और पेमेंट के फ़ॉर्म जल्दी और आसानी से भरने में मदद करके, कन्वर्ज़न बढ़ाएं.

अच्छी तरह से डिज़ाइन किए गए फ़ॉर्म, उपयोगकर्ताओं की मदद करते हैं और कन्वर्ज़न रेट बढ़ाते हैं. एक छोटे से सुधार से काफ़ी फ़र्क़ पड़ सकता है!

यहां पेमेंट के एक आसान तरीके का उदाहरण दिया गया है, जिसमें सभी सबसे सही तरीकों के बारे में बताया गया है:

यहां पते के लिए बनाए गए एक आसान फ़ॉर्म का उदाहरण दिया गया है. इसमें सभी सबसे सही तरीके दिखाए गए हैं:

चेकलिस्ट

काम का एचटीएमएल इस्तेमाल करना

जॉब के लिए बनाए गए एलिमेंट और एट्रिब्यूट का इस्तेमाल करें:

  • <form>, <input>, <label>, और <button>
  • type, autocomplete, और inputmode

इन सुविधाओं की मदद से, ब्राउज़र में पहले से मौजूद सुविधाएं चालू की जा सकती हैं, सुलभता को बेहतर बनाया जा सकता है, और आपके मार्कअप को बेहतर बनाया जा सकता है.

एचटीएमएल एलिमेंट का इस्तेमाल सही तरीके से करना

अपने फ़ॉर्म को <form> में डालें

हो सकता है कि आप अपने <input> एलिमेंट को <form> में रैप करने के बजाय, डेटा सबमिशन को पूरी तरह से JavaScript के ज़रिए मैनेज करना चाहें.

ऐसा न करें!

एचटीएमएल <form> की मदद से, आपको सभी आधुनिक ब्राउज़र में पहले से मौजूद सुविधाओं का बेहतरीन सेट ऐक्सेस करने की सुविधा मिलती है. साथ ही, इससे आपकी साइट को स्क्रीन रीडर और अन्य सहायक डिवाइसों के लिए ऐक्सेस किया जा सकता है. <form> की मदद से, JavaScript के सीमित वर्शन के साथ काम करने वाले पुराने ब्राउज़र के लिए बुनियादी फ़ंक्शन बनाना भी आसान हो जाता है. साथ ही, कोड में गड़बड़ी होने पर भी फ़ॉर्म सबमिट करने की सुविधा चालू की जा सकती है. यह सुविधा उन कुछ उपयोगकर्ताओं के लिए भी उपलब्ध है जो JavaScript को बंद कर देते हैं.

अगर आपके पास उपयोगकर्ता के इनपुट के लिए एक से ज़्यादा पेज कॉम्पोनेंट हैं, तो पक्का करें कि हर कॉम्पोनेंट को उसके अपने <form> एलिमेंट में डाला गया हो. उदाहरण के लिए, अगर आपके पास एक ही पेज पर खोज और साइन-अप है, तो हर एक को अपने <form> में डालें.

एलिमेंट को लेबल करने के लिए <label> का इस्तेमाल करना

<input>, <select> या <textarea> को लेबल करने के लिए, <label> का इस्तेमाल करें.

लेबल के for एट्रिब्यूट को इनपुट के id एट्रिब्यूट की वैल्यू के बराबर वैल्यू देकर, किसी लेबल को इनपुट से जोड़ें.

<label for="address-line1">Address line 1</label>
<input id="address-line1" …>

एक इनपुट के लिए एक लेबल का इस्तेमाल करें: एक ही लेबल से कई इनपुट को लेबल करने की कोशिश न करें. यह तरीका, ब्राउज़र और स्क्रीन रीडर के लिए सबसे अच्छा है. किसी लेबल पर टैप या क्लिक करने से, फ़ोकस उससे जुड़े इनपुट पर चला जाता है. साथ ही, जब लेबल या लेबल के इनपुट पर फ़ोकस जाता है, तो स्क्रीन रीडर लेबल टेक्स्ट को पढ़कर सुनाते हैं.

बटनों को मददगार बनाना

बटन के लिए, <button> का इस्तेमाल करें! <input type="submit"> का भी इस्तेमाल किया जा सकता है. हालांकि, बटन के तौर पर div या किसी दूसरे एलिमेंट का इस्तेमाल न करें. बटन एलिमेंट, ऐक्सेस करने के लिए आसान तरीका, पहले से मौजूद फ़ॉर्म सबमिशन की सुविधा देते हैं. साथ ही, इन्हें आसानी से स्टाइल किया जा सकता है.

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

उपयोगकर्ता के टैप या क्लिक करने के बाद, सबमिट बटन को बंद करें. ऐसा खास तौर पर तब करें, जब उपयोगकर्ता पेमेंट कर रहा हो या ऑर्डर दे रहा हो. कई उपयोगकर्ता, बटन ठीक से काम करने के बावजूद उन पर बार-बार क्लिक करते हैं. इससे चेकआउट में गड़बड़ी हो सकती है और सर्वर पर लोड बढ़ सकता है.

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

एचटीएमएल एट्रिब्यूट का ज़्यादा से ज़्यादा फ़ायदा पाना

उपयोगकर्ताओं के लिए डेटा डालना आसान बनाएं

मोबाइल पर सही कीबोर्ड उपलब्ध कराने के लिए, सही इनपुट type एट्रिब्यूट का इस्तेमाल करें. साथ ही, ब्राउज़र में पहले से मौजूद बुनियादी पुष्टि करने की सुविधा को चालू करें.

उदाहरण के लिए, ईमेल पतों के लिए type="email" और फ़ोन नंबर के लिए type="tel" इस्तेमाल करें.

Android फ़ोन के दो स्क्रीनशॉट, जिनमें एक कीबोर्ड दिखाया गया है, जिससे ईमेल पता डालने (type=email का इस्तेमाल करके) और टेलीफ़ोन नंबर (type=tel) डाला जा सकता है.
ईमेल और टेलीफ़ोन के लिए सही कीबोर्ड.

तारीखों के लिए, कस्टम select एलिमेंट का इस्तेमाल करने से बचें. अगर इन्हें सही तरीके से लागू नहीं किया जाता है, तो जानकारी ऑटोमैटिक भरने की सुविधा काम नहीं करती. साथ ही, ये पुराने ब्राउज़र पर काम नहीं करते. जन्म के साल जैसे नंबर के लिए, select के बजाय input एलिमेंट का इस्तेमाल करें. ऐसा इसलिए, क्योंकि लंबी ड्रॉप-डाउन सूची से चुनने के बजाय, मैन्युअल तौर पर अंक डालना आसान हो सकता है और इसमें गड़बड़ी होने की संभावना कम होती है. खास तौर पर, मोबाइल पर. inputmode="numeric" का इस्तेमाल करके, पक्का करें कि मोबाइल पर सही कीबोर्ड दिख रहा हो. साथ ही, टेक्स्ट या प्लेसहोल्डर के साथ पुष्टि करने और फ़ॉर्मैट करने के सुझाव जोड़ें, ताकि उपयोगकर्ता सही फ़ॉर्मैट में डेटा डाल सके.

ऐक्सेस को बेहतर बनाने और उपयोगकर्ताओं को डेटा फिर से डालने से बचाने के लिए, ऑटोकंप्लीट की सुविधा का इस्तेमाल करना

सही autocomplete वैल्यू का इस्तेमाल करने पर, ब्राउज़र डेटा को सुरक्षित तरीके से सेव करके और input, select, और textarea वैल्यू को ऑटोमैटिक तरीके से भरकर, उपयोगकर्ताओं की मदद कर सकते हैं. यह खास तौर पर मोबाइल पर ज़रूरी है. साथ ही, फ़ॉर्म छोड़ने की दरों को कम करने के लिए भी ज़रूरी है. अपने-आप पूरा होने की सुविधा से, सुलभता के कई फ़ायदे भी मिलते हैं.

अगर फ़ॉर्म फ़ील्ड के लिए सही ऑटोकंप्लीट वैल्यू उपलब्ध है, तो आपको उसका इस्तेमाल करना चाहिए. MDN वेब दस्तावेज़ों में वैल्यू की पूरी सूची होती है. साथ ही, इन्हें सही तरीके से इस्तेमाल करने के बारे में पूरी जानकारी दी जाती है.

स्थिर वैल्यू

बिलिंग पता

डिफ़ॉल्ट रूप से, बिलिंग पता और डिलीवरी पता एक ही रखें. बिलिंग पते को फ़ॉर्म में दिखाने के बजाय, बिलिंग पते में बदलाव करने के लिए लिंक दें. इसके अलावा, summary और details एलिमेंट का इस्तेमाल करें. इससे, विज़ुअल में गड़बड़ी नहीं होगी.

चेकआउट पेज का उदाहरण, जिसमें बिलिंग पता बदलने का लिंक दिखाया गया है.
बिलिंग की समीक्षा करने के लिए लिंक जोड़ें.

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

<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

सही डेटा डालने में उपयोगकर्ताओं की मदद करना

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

स्वीकार किए जा सकने वाले वैल्यू बताने के लिए, एलिमेंट को बनाने में कंस्ट्रेंट एट्रिब्यूट जोड़े जा सकते हैं. इन वैल्यू में min, max, और pattern शामिल हैं. एलिमेंट की मान्यता की स्थिति, अपने-आप सेट हो जाती है. यह इस बात पर निर्भर करता है कि एलिमेंट की वैल्यू मान्य है या नहीं. :valid और :invalid सीएसएस स्यूडो-क्लास भी इसी तरह सेट होती हैं. इनका इस्तेमाल, मान्य या अमान्य वैल्यू वाले एलिमेंट को स्टाइल करने के लिए किया जा सकता है.

उदाहरण के लिए, नीचे दिए गए एचटीएमएल में, जन्म का साल 1900 से 2020 के बीच का होना चाहिए. type="number" का इस्तेमाल करने से, इनपुट वैल्यू सिर्फ़ संख्या तक सीमित होती हैं. यह min और max की बताई गई रेंज में आती है. अगर किसी ऐसे नंबर को डालने की कोशिश की जाती है जो तय सीमा से बाहर है, तो इनपुट को अमान्य के तौर पर सेट कर दिया जाएगा.

नीचे दिए गए उदाहरण में, pattern="[\d ]{10,30}" का इस्तेमाल करके यह पक्का किया गया है कि पेमेंट कार्ड नंबर मान्य है. साथ ही, इसमें स्पेस की अनुमति दी गई है:

मॉडर्न ब्राउज़र, टाइप email या url वाले इनपुट के लिए बुनियादी पुष्टि भी करते हैं.

फ़ॉर्म सबमिट करने पर, ब्राउज़र अपने-आप उन फ़ील्ड पर फ़ोकस सेट कर देते हैं जिनमें समस्या है या ज़रूरी वैल्यू मौजूद नहीं हैं. JavaScript की ज़रूरत नहीं है!

डेस्कटॉप पर Chrome में साइन-इन फ़ॉर्म का स्क्रीनशॉट, जिसमें ब्राउज़र का प्रॉम्प्ट और अमान्य ईमेल वैल्यू पर फ़ोकस किया गया है.
ब्राउज़र में पहले से मौजूद बुनियादी पुष्टि करने की सुविधा.

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

उपयोगकर्ता डेटा डालते समय और फ़ॉर्म सबमिट करते समय, पुष्टि को ज़्यादा बेहतर बनाने के लिए, आपको JavaScript का भी इस्तेमाल करना चाहिए. Constraint Validation API का इस्तेमाल करें. यह काफ़ी लोकप्रिय है. इसकी मदद से, ब्राउज़र के पहले से मौजूद यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, पसंद के मुताबिक पुष्टि की सुविधा जोड़ी जा सकती है. इससे फ़ोकस सेट करने और प्रॉम्प्ट दिखाने में मदद मिलती है.

इस बारे में ज़्यादा जानने के लिए, रीयल-टाइम की जटिल पुष्टि के लिए JavaScript का इस्तेमाल करना लेख पढ़ें.

ज़रूरी डेटा खोने से बचने के लिए उपयोगकर्ताओं की मदद करें

ज़रूरी वैल्यू के लिए, इनपुट के तौर पर required एट्रिब्यूट का इस्तेमाल करें.

फ़ॉर्म सबमिट करने पर, आधुनिक ब्राउज़र अपने-आप प्रॉम्प्ट करते हैं और required उन फ़ील्ड पर फ़ोकस सेट करते हैं जिनमें डेटा मौजूद नहीं है. साथ ही, ज़रूरी फ़ील्ड को हाइलाइट करने के लिए, :required स्यूडो-क्लास का इस्तेमाल किया जा सकता है. इसके लिए, JavaScript की ज़रूरत नहीं है!

हर ज़रूरी फ़ील्ड के लेबल में तारे का निशान जोड़ें. साथ ही, फ़ॉर्म की शुरुआत में एक नोट जोड़ें, ताकि यह बताया जा सके कि तारे का क्या मतलब है.

चेकआउट की प्रोसेस को आसान बनाना

मोबाइल कॉमर्स के अंतर का ध्यान रखें!

मान लें कि आपके उपयोगकर्ताओं का थका हुआ बजट है. इसे खत्म करने पर, आपके उपयोगकर्ता आपके ऐप्लिकेशन को छोड़ देंगे.

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

सबसे ज़्यादा, उपयोगकर्ता ऐसे फ़ॉर्म को छोड़ देते हैं जो लंबे, जटिल, और जिनमें दिशा-निर्देश न हों. ऐसा खास तौर पर तब होता है, जब उपयोगकर्ता छोटी स्क्रीन का इस्तेमाल कर रहे हों, उनका ध्यान भटक रहा हो या वे जल्दी में हों. ज़्यादा से ज़्यादा डेटा का अनुरोध न करें.

लॉग इन किए बिना खरीदारी करने की सुविधा को डिफ़ॉल्ट के तौर पर सेट करना

ऑनलाइन स्टोर के लिए, फ़ॉर्म में आने वाली समस्याओं को कम करने का सबसे आसान तरीका यह है कि मेहमान के तौर पर चेकआउट करने की सुविधा को डिफ़ॉल्ट रूप से सेट किया जाए. खरीदारी करने से पहले, उपयोगकर्ताओं को खाता बनाने के लिए मजबूर न करें. बिना खाता बनाए चेकआउट करने की सुविधा न देने को, शॉपिंग कार्ट छोड़ने की मुख्य वजह माना जाता है.

चेकआउट के दौरान, शॉपिंग कार्ट छोड़ने की वजहें.
baymard.com/checkout-usability
से लिया गया

चेकआउट के बाद, खाते में साइन अप करने का विकल्प दिया जा सकता है. इस समय, आपके पास खाता सेट अप करने के लिए ज़रूरी ज़्यादातर डेटा पहले से मौजूद होता है. इसलिए, उपयोगकर्ता के लिए खाता बनाना आसान और तेज़ हो जाता है.

चेकआउट की प्रोग्रेस दिखाना

अपनी प्रोग्रेस के बारे में बताकर और यह बताकर कि आगे क्या किया जाना चाहिए, आप अपनी चेकआउट प्रोसेस को कम जटिल बना सकते हैं. नीचे दिए गए वीडियो में दिखाया गया है कि यूनाइटेड किंगडम के खुदरा दुकानदार johnlewis.com ने ऐसा कैसे किया.

चेकआउट की प्रोग्रेस दिखाएं.

आपको अपनी दिलचस्पी बनाए रखनी होगी! पेमेंट के हर चरण के लिए, पेज की हेडिंग और बटन की ऐसी वैल्यू का इस्तेमाल करें जिनसे यह साफ़ तौर पर पता चलता हो कि अब क्या करना है और चेकआउट का अगला चरण क्या है.

फ़ॉर्म के बटनों को ऐसे नाम दें जिनसे पता चलता हो कि आगे क्या करना है.

मोबाइल कीबोर्ड के लिए बटन का लेबल सेट करने के लिए, फ़ॉर्म इनपुट पर enterkeyhint एट्रिब्यूट का इस्तेमाल करें. उदाहरण के लिए, कई पेजों वाले फ़ॉर्म में enterkeyhint="previous" और enterkeyhint="next" का इस्तेमाल करें. साथ ही, फ़ॉर्म में आखिरी इनपुट के लिए enterkeyhint="done" और खोज इनपुट के लिए enterkeyhint="search" का इस्तेमाल करें.

Android पर मौजूद पते के फ़ॉर्म के दो स्क्रीनशॉट, जिनमें दिखाया गया है कि enterkeyhint इनपुट एट्रिब्यूट, Enter बटन के आइकॉन को कैसे बदलता है.
Android पर मुख्य बटन डालें: 'आगे बढ़ें' और 'हो गया'.

enterkeyhint एट्रिब्यूट, Android और iOS पर काम करता है. इस बारे में ज़्यादा जानने के लिए, enterkeyhint के बारे में जानकारी देखें.

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

ध्यान भटकाने वाली चीज़ों को हटाना

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

मोबाइल पर दो स्क्रीनशॉट, जिनमें johnlewis.com पर चेकआउट की प्रोग्रेस दिख रही है. खोज, नेविगेशन, और ध्यान भटकाने वाली अन्य चीज़ें हटा दी जाती हैं.
चेकआउट के लिए, खोज, नेविगेशन, और ध्यान भटकाने वाली अन्य चीज़ों को हटा दिया गया है.

यात्रा पर फ़ोकस बनाए रखें. इस समय, उपयोगकर्ताओं को कुछ और करने के लिए लुभाने का समय नहीं है!

मोबाइल पर चेकआउट पेज का स्क्रीनशॉट, जिसमें फ़्री स्टिकर के लिए ध्यान भटकाने वाला प्रमोशन दिखाया गया है.
खरीदारी पूरी करने के दौरान, खरीदारों का ध्यान न भटाएं.

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

चेकआउट पेज पर &#39;ऑर्डर की समीक्षा करें&#39; सेक्शन का स्क्रीनशॉट, जिसमें टेक्स्ट को सामान्य टेक्स्ट में दिखाया गया है. साथ ही, डिलीवरी का पता, पेमेंट का तरीका, और बिलिंग पता बदलने के लिंक भी नहीं दिख रहे हैं.
वह डेटा छिपाएं जिसे खरीदारों को नहीं देखना है.

नाम और पता आसानी से डालें

सिर्फ़ उस डेटा के लिए अनुरोध करें जिसकी आपको ज़रूरत है

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

एक ही नाम का इस्तेमाल करना

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

खास तौर पर, अगर आपके पास ऐसा न करने की कोई अच्छी वजह नहीं है, तो किसी प्रीफ़िक्स या टाइटल (जैसे, श्रीमती, डॉ. या लॉर्ड) के लिए अलग से इनपुट जोड़ने की ज़रूरत नहीं है. उपयोगकर्ता चाहें, तो अपने नाम के साथ यह कोड टाइप कर सकते हैं. साथ ही, honorific-prefix फ़िलहाल ज़्यादातर ब्राउज़र में ऑटोमैटिक भरने की सुविधा काम नहीं करती. इसलिए, नाम के प्रीफ़िक्स या टाइटल के लिए फ़ील्ड जोड़ने पर, ज़्यादातर उपयोगकर्ताओं के लिए पते के फ़ॉर्म में जानकारी अपने-आप भरने की सुविधा काम नहीं करेगी.

नाम की जानकारी अपने-आप भरने की सुविधा चालू करना

पूरे नाम के लिए name का इस्तेमाल करें:

<input autocomplete="name" ...>

अगर आपके पास नाम के हिस्सों को अलग करने की कोई सही वजह है, तो अपने-आप भरने की सुविधा के लिए सही वैल्यू का इस्तेमाल करें:

  • honorific-prefix
  • given-name
  • nickname
  • additional-name-initial
  • additional-name
  • family-name
  • honorific-suffix

अंतरराष्ट्रीय नामों की अनुमति दें

हो सकता है कि आप नाम के इनपुट की पुष्टि करना चाहें या नाम के डेटा के लिए इस्तेमाल किए जा सकने वाले वर्णों पर पाबंदी लगाना चाहें. हालांकि, आपको अक्षरों के लिए ज़्यादा से ज़्यादा विकल्प देने चाहिए. यह सुनना अच्छा नहीं लगता कि आपका नाम "अमान्य" है!

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

यह न करें
<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>
यह करें
<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>
सिर्फ़ लैटिन लेटर मैचिंग की तुलना में यूनिकोड लेटर मैचिंग.

अलग-अलग पते के फ़ॉर्मैट की अनुमति दें

पते का फ़ॉर्म डिज़ाइन करते समय, ध्यान रखें कि पते के अलग-अलग फ़ॉर्मैट होते हैं. यहां तक कि एक ही देश में भी पते के फ़ॉर्मैट अलग-अलग हो सकते हैं. "सामान्य" पतों के बारे में कोई अनुमान न लगाएं. (अगर आपको इस बात पर भरोसा नहीं है, तो यूनाइटेड किंगडम के पतों की खास बातें! देखें!)

पते के फ़ॉर्म को ज़रूरत के हिसाब से बनाना

उपयोगकर्ताओं को ऐसे फ़ॉर्म फ़ील्ड में पता डालने के लिए मजबूर न करें जो फ़िट नहीं होते.

उदाहरण के लिए, घर का नंबर और सड़क का नाम अलग-अलग इनपुट में शामिल न करें. ऐसा इसलिए, क्योंकि कई पते इस फ़ॉर्मैट का इस्तेमाल नहीं करते और अधूरा डेटा, ब्राउज़र की ऑटोमैटिक भरने की सुविधा में रुकावट डाल सकता है.

खास तौर पर, required पते के फ़ील्ड में सावधानी बरतें. उदाहरण के लिए, यूनाइटेड किंगडम के बड़े शहरों के पतों में काउंटी नहीं होती, लेकिन कई साइटें अब भी उपयोगकर्ताओं को काउंटी डालने के लिए मजबूर करती हैं.

पते की दो लाइन का इस्तेमाल करके, पते के कई फ़ॉर्मैट के लिए काम किया जा सकता है.

<input autocomplete="address-line-1" id="address-line1" ...>
<input autocomplete="address-line-2" id="address-line2" ...>

मैच करने के लिए लेबल जोड़ें:

<label for="address-line-1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line-1" id="address-line1" ...>

<label for="address-line-2">
Address line 2 (optional)
</label>
<input autocomplete="address-line-2" id="address-line2" ...>

इसे आज़माने के लिए, यहां एम्बेड किए गए डेमो को रीमिक्स करें और उसमें बदलाव करें.

पते के लिए एक टेक्स्टएरिया का इस्तेमाल करें

पतों के लिए सबसे आसान विकल्प, एक textarea देना है.

textarea तरीका, पते के किसी भी फ़ॉर्मैट के साथ काम करता है. साथ ही, यह काटने और चिपकाने के लिए बहुत अच्छा है. हालांकि, ध्यान रखें कि यह आपके डेटा की ज़रूरतों के हिसाब से काम न करे. साथ ही, अगर उपयोगकर्ताओं ने पहले सिर्फ़ address-line1 और address-line2 वाले फ़ॉर्म का इस्तेमाल किया है, तो हो सकता है कि वे ऑटोमैटिक भरने की सुविधा का इस्तेमाल न कर पाएं.

टेक्स्टएरिया के लिए, अपने-आप भरने की सुविधा की वैल्यू के तौर पर street-address का इस्तेमाल करें.

यहां एक फ़ॉर्म का उदाहरण दिया गया है, जिसमें पते के लिए एक textarea का इस्तेमाल किया गया है:

पते के फ़ॉर्म को अंतरराष्ट्रीय और स्थानीय भाषा के हिसाब से बनाना

पते वाले फ़ॉर्म के लिए, अंतरराष्ट्रीय और स्थानीय भाषाओं का इस्तेमाल करना ज़रूरी है. यह इस बात पर निर्भर करता है कि आपके उपयोगकर्ता कहां से हैं.

ध्यान रखें कि पते के हिस्सों के नाम और पते के फ़ॉर्मैट भी अलग-अलग होते हैं. भले ही, उनकी भाषा एक ही हो.

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

ऐसा फ़ॉर्म भरना परेशानी भरा या मुश्किल हो सकता है जो आपके पते के हिसाब से न हो या जिसमें आपके हिसाब से शब्द न इस्तेमाल किए गए हों.

आपकी साइट के लिए, अलग-अलग भाषाओं के लिए पते के फ़ॉर्म को पसंद के मुताबिक बनाना ज़रूरी हो सकता है. हालांकि, ऊपर बताई गई तकनीकों का इस्तेमाल करके, फ़ॉर्म को ज़्यादा से ज़्यादा आसान बनाने के लिए, ऐसा करना ज़रूरी नहीं है. अगर आपने पते के फ़ॉर्म को स्थानीय भाषा में नहीं बनाया है, तो पते के अलग-अलग फ़ॉर्मैट के हिसाब से काम करने के लिए, इन बातों का ध्यान रखें: * पते के हिस्सों के बारे में ज़्यादा जानकारी देने से बचें. जैसे, गली का नाम या घर का नंबर बताना. * जहां हो सके, फ़ील्ड को required न बनाएं. उदाहरण के लिए, कई देशों के पतों में डाक कोड नहीं होता. साथ ही, ग्रामीण इलाकों के पतों में सड़क या गली का नाम नहीं हो सकता. * इन्क्लूसिव नामिंग का इस्तेमाल करें: 'देश' नहीं 'देश/क्षेत्र'; 'ZIP' नहीं 'ZIP/postal code'.

इसे सुविधाजनक बनाएं! ऊपर दिए गए पते के फ़ॉर्म के आसान उदाहरण को कई स्थानीय भाषाओं के लिए 'काफ़ी अच्छा' तरीके से काम करने के लिए बदला जा सकता है.

पिन कोड पता न खोजें

कुछ वेबसाइटें, पिन कोड या पिन कोड के आधार पर पते खोजने के लिए किसी सेवा का इस्तेमाल करती हैं. कुछ मामलों में, ऐसा करना सही हो सकता है. हालांकि, आपको इसके संभावित नुकसानों के बारे में पता होना चाहिए.

पिन कोड के हिसाब से पता सुझाने की सुविधा सभी देशों में काम नहीं करती. साथ ही, कुछ इलाकों में पिन कोड में संभावित पतों की संख्या ज़्यादा हो सकती है.

पिन या पिन कोड में कई पते शामिल हो सकते हैं!

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

नाम डालने के बाद, एक टैप (एक क्लिक) से पता डाला जा सकता है.

पेमेंट फ़ॉर्म को आसान बनाना

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

उपयोगकर्ताओं को पेमेंट का डेटा दोबारा डालने से बचाना

पक्का करें कि आपने पेमेंट कार्ड के फ़ॉर्म में autocomplete की सही वैल्यू सबमिट की हों. जैसे, पेमेंट कार्ड का नंबर, कार्ड पर मौजूद नाम, समयसीमा खत्म होने का महीना और साल:

  • cc-number
  • cc-name
  • cc-exp-month
  • cc-exp-year

इससे ब्राउज़र, उपयोगकर्ताओं की मदद कर पाते हैं. ऐसा वे पेमेंट कार्ड की जानकारी को सुरक्षित तरीके से सेव करके और फ़ॉर्म का डेटा सही तरीके से डालकर करते हैं. अपने-आप जानकारी भरने की सुविधा के बिना, हो सकता है कि उपयोगकर्ता अपने क्रेडिट/डेबिट कार्ड की जानकारी का रिकॉर्ड अपने पास रखें या अपने डिवाइस पर क्रेडिट/डेबिट कार्ड का डेटा असुरक्षित तरीके से सेव करें.

पेमेंट कार्ड की तारीखों के लिए कस्टम एलिमेंट का इस्तेमाल करने से बचें

अगर ठीक से डिज़ाइन नहीं किया गया है, तो कस्टम एलिमेंट ऑटोमैटिक भरने की सुविधा को बंद करके, पेमेंट प्रोसेस में रुकावट डाल सकते हैं. ऐसा हो सकता है कि ये एलिमेंट पुराने ब्राउज़र पर काम न करें. अगर पेमेंट कार्ड की अन्य सभी जानकारी अपने-आप भरने की सुविधा से उपलब्ध है, लेकिन उपयोगकर्ता को समयसीमा की तारीख देखने के लिए अपना पेमेंट कार्ड ढूंढना पड़ता है, तो हो सकता है कि आपका कोई बिक्री न हो. ऐसा इसलिए होता है, क्योंकि कस्टम एलिमेंट के लिए अपने-आप भरने की सुविधा काम नहीं करती. इसके बजाय, स्टैंडर्ड एचटीएमएल एलिमेंट का इस्तेमाल करें और उन्हें अपनी पसंद के मुताबिक स्टाइल करें.

पेमेंट फ़ॉर्म का स्क्रीनशॉट, जिसमें कार्ड की समयसीमा खत्म होने की तारीख के लिए कस्टम एलिमेंट दिखाए गए हैं. इनकी वजह से, ऑटोमैटिक भरने की सुविधा काम नहीं करती.
समयसीमा खत्म होने की तारीख को छोड़कर, सभी फ़ील्ड को ऑटोकंप्लीट की सुविधा से भर दिया गया है!

पेमेंट कार्ड और फ़ोन नंबर के लिए एक ही इनपुट का इस्तेमाल करना

पेमेंट कार्ड और फ़ोन नंबर के लिए, एक ही इनपुट का इस्तेमाल करें: नंबर को अलग-अलग हिस्सों में न बांटें. इससे उपयोगकर्ताओं के लिए डेटा डालना आसान हो जाता है, पुष्टि करना आसान हो जाता है, और ब्राउज़र अपने-आप भरने की सुविधा चालू कर पाते हैं. पिन और बैंक कोड जैसे अन्य अंकों वाले डेटा के लिए भी ऐसा करें.

पेमेंट फ़ॉर्म का स्क्रीनशॉट, जिसमें क्रेडिट कार्ड फ़ील्ड को चार इनपुट एलिमेंट में बांटा गया है.
क्रेडिट कार्ड नंबर के लिए, एक से ज़्यादा इनपुट का इस्तेमाल न करें.

सावधानी से पुष्टि करना

आपको रीयल टाइम में और फ़ॉर्म सबमिट करने से पहले, डेटा एंट्री की पुष्टि करनी चाहिए. इसका एक तरीका यह है कि आप पेमेंट कार्ड के इनपुट में pattern एट्रिब्यूट जोड़ें. अगर उपयोगकर्ता किसी अमान्य वैल्यू के साथ पेमेंट फ़ॉर्म सबमिट करने की कोशिश करता है, तो ब्राउज़र चेतावनी का मैसेज दिखाता है और इनपुट पर फ़ोकस करता है. इसके लिए, JavaScript की ज़रूरत नहीं है!

हालांकि, आपकी pattern रेगुलर एक्सप्रेशन, पेमेंट कार्ड की संख्या की लंबाई की रेंज को हैंडल करने के लिए ज़रूरत के मुताबिक होनी चाहिए: 14 (या शायद इससे कम) से 20 (या उससे ज़्यादा) अंक. पेमेंट कार्ड नंबर के स्ट्रक्चर के बारे में ज़्यादा जानने के लिए, LDAPwiki पर जाएं.

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

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

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

iPhone 7 और 11 पर, पेमेंट फ़ॉर्म, payment-form.glitch.me के स्क्रीनशॉट. &#39;पेमेंट पूरा करें&#39; बटन, iPhone 11 पर दिखता है, लेकिन iPhone 7 पर नहीं
iPhone 7 और iPhone 11 पर एक ही पेज.
छोटे मोबाइल व्यूपोर्ट के लिए पैडिंग कम करें, ताकि पेमेंट पूरा करें बटन छिपा न रहे.

आंकड़े और आरयूएम लागू करना

उपयोगिता और परफ़ॉर्मेंस की स्थानीय तौर पर जांच करना मददगार हो सकता है, लेकिन आपको असल डेटा की ज़रूरत है, ताकि आप यह अच्छी तरह समझ सकें कि उपयोगकर्ता आपके पेमेंट और पते के फ़ॉर्म का इस्तेमाल कैसे करते हैं.

इसके लिए, आपको आंकड़ों और असल उपयोगकर्ताओं की निगरानी करने वाला डेटा चाहिए. जैसे, असल उपयोगकर्ताओं का अनुभव कैसा रहा, जैसे कि चेकआउट पेजों को लोड होने में कितना समय लगता है या पेमेंट पूरा होने में कितना समय लगता है:

  • पेज के आंकड़े: फ़ॉर्म वाले हर पेज के लिए, पेज व्यू, बाउंस रेट, और एग्ज़िट.
  • इंटरैक्शन के आंकड़े: लक्ष्य फ़नल और इवेंट से पता चलता है कि उपयोगकर्ता आपके चेकआउट फ़्लो को कहां छोड़ते हैं और आपके फ़ॉर्म से इंटरैक्ट करते समय वे क्या कार्रवाइयां करते हैं.
  • वेबसाइट की परफ़ॉर्मेंस: उपयोगकर्ता के हिसाब से बनाई गई मेट्रिक से पता चलता है कि आपके चेकआउट पेज धीरे लोड हो रहे हैं या नहीं. अगर धीरे लोड हो रहे हैं, तो इसकी वजह क्या है.

पेज के आंकड़ों, इंटरैक्शन के आंकड़ों, और असल उपयोगकर्ता की परफ़ॉर्मेंस के मेज़रमेंट को सर्वर लॉग, कन्वर्ज़न डेटा, और A/B टेस्टिंग के साथ जोड़ने पर, ये खास तौर पर अहम हो जाते हैं. इससे आपको इन सवालों के जवाब मिल सकते हैं: क्या छूट वाले कोड से रेवेन्यू बढ़ता है या फ़ॉर्म लेआउट में बदलाव करने से कन्वर्ज़न बेहतर होते हैं.

इससे, आपको रणनीतियों को प्राथमिकता देने, बदलाव करने, और सफलता का इनाम देने के लिए एक ठोस आधार मिलता है.

सीखते रहें

Unस्प्लैश पर @rupixen की फ़ोटो.