खरीदारों को जोड़ने से पहले खरीदने दें
जहाँ ऑर्डर डिलीवर करने के लिए अकाउंट आवश्यक नहीं है, वहाँ अतिथि चेकआउट (guest checkout) को स्पष्ट डिफ़ॉल्ट बनाएं। Google के फ़ॉर्म मार्गदर्शन यह तरीका सुझाते हैं। रिटर्निंग कस्टमर के लिए साइन-इन को एक दृश्य द्वितीयक मार्ग बनाकर रखें, और पुष्टि के बाद ऑर्डर इतिहास जैसे ठोस लाभ के साथ अकाउंट बनाने का विकल्प दें। यदि कोई विनियमित उत्पाद, सदस्यता, या फ्रॉड नीति लॉगिन मांगती है, तो फ़ॉर्म शुरू होने से पहले उस आवश्यकता को समझाएँ।
जब नीति अनुमति देती है तो नया खरीदार पासवर्ड बनाए बिना भुगतान तक पहुँच सके।
भुगतान से पहले टोल की तरह नहीं, बल्कि ऑर्डर के बाद अकाउंट बनाने का निमंत्रण दें।
फ़ील्ड घटाएँ पर डिलीवरी अस्पष्ट न बनें
केवल वही जानकारी माँगें जो पूर्ति, भुगतान, कर, या आवश्यक संचार को बदलती है। मानक कंट्रोल्स, दृश्य लेबल, स्थिर name और id मान, और उपयुक्त autocomplete टोकन का उपयोग करें। जब बिलिंग शिपिंग से मेल खाती हो तो डिफ़ॉल्ट रूप से इसे मैच कर दें, और अलग पता चुनना आसान बनाएं। W3C कहता है कि एक ही प्रक्रिया में पहले से भरी जानकारी को ऑटो-पॉप्युलेट या चुनने के लिए उपलब्ध किया जाना चाहिए, सिवाय सीमित मामलों के जैसे सुरक्षा या अमान्य डेटा।
हर इनपुट का एक परिचालन उद्देश्य दें; अगर कोई उद्देश्य नहीं है तो उसे हटाएँ या स्थगित करें।
केवल गायब होने वाले सहायक टेक्स्ट को एकमात्र लेबल के रूप में न रखें; प्रविष्टि के दौरान एक दृश्य लेबल बनाए रखें।
त्रुटियों को रिकवरी-पाथ में बदलें
साधारण स्थानीय समस्याओं को एंट्री के दौरान या फ़ील्ड छोड़ने पर वैलिडेट करें, बिना हर कीस्ट्रोक को बाधित किए। सरल सुधार मार्गदर्शन का उपयोग करें और त्रुटि के बाद सुरक्षित गैर-संवेदनशील प्रविष्टियों को बनाए रखें। विफल सबमिशन के बाद, फ़ॉर्म से पहले लिंक्ड त्रुटि सारांश दिखाएँ और हर फ़ील्ड पर मेल खाती संदेश प्रदर्शित करें। W3C अनुशंसा करता है कि प्रत्येक सारांश आइटम कंट्रोल की पहचान करे, समस्या का वर्णन करे, और सुधार समझाये। भुगतान डेटा को URLs, लॉग्स, और त्रुटि कॉपी से बाहर रखें।
‘अमान्य इनपुट’ कहने के बजाय बताएं क्या गलत है और इसे कैसे ठीक करें।
फोकस को रिकवरी पॉइंट पर ले जाएँ और सहायक तकनीक के लिए डायनामिक फीडबैक की घोषणा करें।
भुगतान विकल्प दें बिना पेमेंट-पेज नियंत्रण कमजोर किए
ऐसे भुगतान तरीके दिखाएँ जिन्हें व्यवसाय अधिकृत, रिफ़ंड, मिलान, और सपोर्ट कर सकता है। प्रत्येक विधि को स्पष्ट नाम दें और प्रतिज्ञा से पहले महत्वपूर्ण शर्तों का खुलासा करें। सफल खरीद, अस्वीकृत भुगतान, और रिफ़ंड या रद्द करने के मार्ग का परीक्षण करें। PCI SSC का ई-स्किमिंग पर मार्गदर्शन भुगतान-पेज स्क्रिप्ट्स, इंटीग्रिटी चेकिंग, और टैम्पर डिटेक्शन पर केंद्रित है। किसी टैग, विजेट, प्रयोग, iframe, या कार्ड कंट्रोल को जोड़ने से पहले प्रदाता और एक योग्य सुरक्षा या PCI समीक्षक को शामिल करें; यह लेख अनुपालन निष्कर्ष नहीं है।
उन पृष्ठों के लिए अनुमोदित अस्सेट्स और ओनरों का एक इन्वेंटरी रखें जो भुगतान को प्रभावित कर सकते हैं।
एक दृश्य रूप से छोटा बदलाव ब्राउज़र-एक्सीक्यूटेड भुगतान-पेज कोड को बदल सकता है।
मोबाइल और पहुँच योग्य पथ को सामान्य पथ बनाएं
तंग व्यूपोर्ट पर ऑन-स्क्रीन कीबोर्ड खुला होने पर टेस्ट करें। उपयुक्त इनपुट प्रकारों और जहाँ उपयोगी हो inputmode का उपयोग करें ताकि वर्चुअल कीबोर्ड का सुझाव मिल सके; MDN नोट करता है कि inputmode स्वयं इनपुट को वैलिडेट नहीं करता। कार्ड नंबर के लिए, Google टेक्स्ट इनपुट के साथ न्यूमेरिक inputmode की सिफारिश करता है न कि number कंट्रोल। दृश्य संबद्ध लेबल, तार्किक कीबोर्ड फोकस, और त्रुटियों तथा चयन के लिए रंग के साथ-साथ टेक्स्ट प्रदान करें। केवल ऑटोमेटेड स्कैन यह स्थापित नहीं कर सकते कि चेकआउट सभी सहायक तकनीकों के साथ काम करता है।
Tab, Shift+Tab, Enter, Space, और Escape से फ्लो पूरा करें जहाँ प्रासंगिक हो।
सहेजा गया ब्राउज़र पता और कार्ड डेटा टेस्ट करें, जिसमें अलग बिलिंग पता भी शामिल हो।
लागत, डिलीवरी और प्रतिबद्धता दृश्यमान रखें
भुगतान पर आइटम्स, मात्रा नियंत्रण, डिस्काउंट, डिलीवरी विकल्प, अब तक के चार्ज, और कुल राशि उपलब्ध रखें। जब शिपिंग, कर, या आवर्ती शुल्क बाद की जानकारी पर निर्भर हो, तो बताएं क्या अनुमानित है और जब ज्ञात हों तुरंत सारांश अपडेट करें। ऑर्डर क्रिया को वित्तीय प्रतिबद्धता के अनुरूप मिलाएँ, जैसे ‘Pay and place order’। खरीदारों को आइटम, पता, या डिलीवरी विकल्प संशोधित करने दें बिना चेकआउट छोड़ने के।
सारांश को पठनीय और हर भुगतान चरण पर अद्यतन योग्य रखें।
बताएँ कि शिपिंग, कर, डिस्काउंट, या आवर्ती शुल्क कब अंतिम होते हैं।
निरंतरता परिवर्त के रूप में प्रयोग करें
एक लिखित परिकल्पना के खिलाफ एक अर्थपूर्ण चीज़ बदलें, जैसे पुष्टि के बाद अकाउंट बनाना। रिलीज़ से पहले ऑडियंस, कंप्लेशन माप, और गार्डरेइल्स को परिभाषित करें। गार्डरेइल्स में भुगतान त्रुटियाँ, विफल सबमिशन, सपोर्ट संपर्क, रिफंड, पहुँचनीयता रिग्रेशन, और परफ़ॉर्मेंस समस्याएँ शामिल हो सकती हैं। खरीद पथ और निर्भरताओं को परखने के लिए SIU (Status Is UP) का उपयोग करें, एक रोलबैक दस्तावेज़ बनाएं, और यदि कोई गार्डरेल टूटे तो अंतिम ज्ञात-सही संस्करण वापस बहाल करें। एक कन्वर्ज़न परिणाम सुरक्षा, पहुँचनीयता, कानूनी अनुपालन, या सार्वभौमिक उपयुक्तता का प्रमाण नहीं है।
पहले वर्तमान चरण पूरा होने, त्रुटि श्रेणियों, और तकनीकी व्यवहार को रिकॉर्ड करें।
निर्धारित करें कौन सा विफलता पैटर्न रिलीज़ को रोकने या उलटने का कारण बनेगा।