👩🏻‍🍳 🙂 🈹 ऑनलाइन स्टोर में डिस्काउंट कार्ड स्वीकार करने के लिए विज़िटर का व्यवहार डिजाइन करना 🌗 👈🏼 👩🏾‍🤝‍👩🏼

अब मेरे पास एक ग्राहक है ( मैंने पहले ही इसका उल्लेख किया है ) जो यूक्रेन में एक नया बोनस सिस्टम लाना चाहता है। धीरे-धीरे, यह एक भुगतान में विकसित होता है। योजनाएं अत्यधिक महत्वाकांक्षी हैं, और सब कुछ घुटने पर किया जाता है। क्लाइंट के पास बहुत पैसा है, लेकिन वह एक पुराने स्कूल का आदमी है और मक्खी पर सब कुछ करने के लिए इस्तेमाल किया जाता है। यह आईटी के लिए विशेष रूप से सच है।

परिणामस्वरूप, संभावित स्वामी द्वारा कार्ड को सक्रिय करने की प्रक्रिया का परीक्षण करते समय बहुत सारी समस्याएं उत्पन्न हुईं। संक्षेप में - एक कदम वापसी के साथ 3 कदम, आगे लॉगिन के लिए 2 कदम, एक असुविधाजनक पासवर्ड की असुविधाजनक प्रविष्टि। नतीजतन, अनुमानित दक्षता अधिकतम 10% है। यह सब आगंतुक व्यवहार के लिए डिजाइन की कमी का परिणाम है।

मुझे यह बताने के लिए अनुबंधित किया गया था कि "एक कार्ड नंबर दर्ज करने के लिए खिड़की और एक आगंतुक के साथ बोनस को जमा करने का तर्क" काम करता है। वर्तमान में पूरी संरचना जिस तरह से काम कर रही है (मैं सिस्टम का नाम लेने से डरता हूं)।

मैंने इसे "विज़िटर व्यवहार को डिज़ाइन करना" करार दिया, इसे तीन भागों में विभाजित किया: एक कार्ड ऑपरेटर द्वारा कार्ड + पंजीकरण के बिना एक आगंतुक, एक कार्ड के लिए एक आगंतुक क्रेडिट बोनस, एक आगंतुक एक कार्ड के साथ भुगतान करता है।

सिद्धांत रूप में, यह सब एक दस्तावेज में होना चाहिए था, क्योंकि यह सब एक स्क्रिप्ट प्रक्रिया का विवरण है। लेकिन लॉजिक्स का संघ अध्ययन के लिए बहुत बोझिल और असुविधाजनक हो जाएगा, खासकर आईटी से दूर के लोगों के लिए।

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

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

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

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

पूरी प्रक्रिया का वर्णन करने का कोई मतलब नहीं है। आप इस योजना को देख सकते हैं जिसके द्वारा मैंने इस लिंक पर तर्क दिया, यहां व्यवहार के तीन परिदृश्यों में से सबसे सरल है, लेकिन यह संरचनात्मक रूप से स्पष्ट है कि बाकी कैसे किया गया था।

मैं उन महत्वपूर्ण बिंदुओं का वर्णन करूंगा जो प्रक्रिया के डिजाइन के माध्यम से सामने आए थे।

इंटरफ़ेस की उपस्थिति बदलें

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

"नो कार्ड; यू लाइक इट फ़्री!" जैसा लिंक;
लघु वर्णनात्मक पाठ;
समर्थन टेलीफोन नंबर;
कार्डधारक सत्यापन के लिए नया इनपुट क्षेत्र (उस पर और अधिक);
कार्डधारक के सत्यापन के बाद जारी किया गया पाठ।

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

इसके अलावा, इस तरह के एक trifle पूर्व निर्धारित कार्ड अंकों के रूप में: 9800000000000 (फिर तीन अंकों की संख्या बदल रहा है)।

कार्डधारक मान्यता

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

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

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

एसएमएस के माध्यम से सत्यापन होगा, आगंतुक को एसएमएस से कोड दर्ज करना होगा। ऐसा लगता है कि सब कुछ सरल है, "यह सौ बार किया।" वास्तव में, कई बिंदु हैं जिन पर विचार करने की आवश्यकता है:

एसएमएस नहीं आया, आगंतुक क्या करें? यह वह जगह है जहां एक समर्थन सेवा संख्या की आवश्यकता दिखाई देती है।
एसएमएस आया, लेकिन एक अन्य व्यक्ति (उन्हें इनपुट या किसी के लिए गालियां दी गईं), यह सोचने के लिए आवश्यक है कि सत्यापन संख्या के अलावा, एसएमएस में क्या होना चाहिए, ताकि लोग अपने पैसे के बारे में चिंता न करें।

जब मैंने ग्राहक के प्रतिनिधि को काम सौंप दिया, तो कार्ड धारक को मान्य करने की आवश्यकता पर हमारा विवाद था, बशर्ते कि ग्राहक केवल बोनस खाते में पैसा जमा करना चाहता हो। ऐसा लगता है, यहाँ मान्यता क्यों है? कोई किसी और के खाते में पैसा जमा नहीं करना चाहता।

मैंने सत्यापन पर जोर दिया, मेरे तर्क थे:

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

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

मेरी मासूमियत के ग्राहक प्रतिनिधि को समझाने में मुझे एक घंटे का समय लगा।

खाते में बोनस की राशि की पुष्टि

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

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

बोनस आरक्षण समारोह

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

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

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

बचाव प्रबंधक

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

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

परिणाम

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

मुझे एहसास है कि मेरी शर्तों और दृष्टिकोण में लामरिज़्म का हिस्सा है, लेकिन मुझे लगता है कि सामान्य तौर पर यह परिणाम को बहुत प्रभावित नहीं करता है।

ऑनलाइन स्टोर के मालिकों के लिए, मैंने कुछ बिंदुओं की एक चेकलिस्ट पोस्ट की है जो किसी भी तृतीय-पक्ष स्क्रिप्ट को जोड़ने या किसी क्लब सिस्टम के साथ एक समझौते में प्रवेश करते समय भूल जाते हैं:

अनुबंध की जांच करें ताकि यह स्पष्ट रूप से इंगित किया जाए कि स्टोर से प्राप्त धन (ग्राहक धन) के लिए कौन जिम्मेदार है;
अनुबंध की समाप्ति के साथ अनुभाग को ध्यान से पढ़ें। किसका बकाया है और क्या होगा;
अगर स्टोर लॉग आउट हो जाता है, तो सावधानी से सोचें? मेरे ग्राहक के मामले में, स्टोर में एक तरह की सेवा के रूप में, सिस्टम के उपयोग के लिए भुगतान करने का अवसर है। कार्यक्रम को समाप्त करना आपके ग्राहकों के लिए एक दर्दनाक प्रक्रिया होगी;
किसी सिस्टम को वापस करने की प्रक्रिया को जानें। दिनांक, कमीशन इत्यादि।
प्रस्तावित स्क्रिप्ट की उपयोगिता और इंटरफ़ेस का सावधानीपूर्वक अध्ययन करें। भविष्य का रूपांतरण बहुत दृढ़ता से इस पर निर्भर कर सकता है।