मोबाइल लॉगिन और साइनअप डिज़ाइन: खाता बनाने का चरण स्पष्ट बनाएँ

वह समय चुनें जब खाता उपयोगी बनता है

व्यक्ति जिस काम के लिए आया है, उससे शुरुआत करें। यदि मुख्य अनुभव बिना खाते के काम कर सकता है, तो पहले देखने दें और साइन-इन तब माँगें जब वह सहेजी प्राथमिकताओं, कई डिवाइस पर पहुँच, सहयोग या लेनदेन वाली सुविधा तक पहुँचे। Apple की Human Interface Guidelines जहाँ संभव हो साइन-इन टालने और खाता आवश्यक होने पर उसका लाभ बताने की सलाह देती हैं।

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

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

साइन-इन विकल्प स्पष्ट और पहचानने योग्य बनाएँ

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

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

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

फ़ॉर्म केंद्रित और लोगों के टूल के अनुकूल रखें

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

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

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

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

गलतियों, खाता वापस पाने और अगली बार आने के लिए डिज़ाइन करें

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

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

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

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

खाता फ़्लो की व्यावहारिक समीक्षा

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

• जहाँ खाता अनिवार्य नहीं है, क्या लोग साइन-इन से पहले उत्पाद से उपयोगी लाभ पा सकते हैं?
• क्या स्क्रीन बताती है कि खाता क्यों चाहिए और कौन-सी जानकारी आवश्यक है?
• क्या व्यक्ति साइनअप, साइन-इन, दूसरे तरीकों और खाता वापस पाने के बीच अंतर समझ सकता है?
• क्या फ़ील्ड लेबल दिखाई देते हैं और ऑटोफ़िल व पेस्ट से क्रेडेंशियल भरे जा सकते हैं?
• क्या त्रुटियाँ पाठ में समस्या बताती हैं, उपयोगी इनपुट सुरक्षित रखती हैं और अगला कदम सुझाती हैं?
• सफलता के बाद क्या व्यक्ति अपने शुरू किए काम पर लौटता है?