ग्राहक यात्रा मानचित्र के साथ उद्देश्य गुणवत्ता स्कोर परीक्षण

हैलो, खाबरोवस्क नागरिकों!

मैं पेशे से एक विश्लेषक हूं, मैं 10 साल से सिस्टम और लेखन आवश्यकताओं को डिजाइन कर रहा हूं। मैं UX / UI के परीक्षण के दृष्टिकोण पर चर्चा करने का प्रस्ताव करता हूं।

संगरोध से पहले, मैं एक स्थिति में भाग गया: मुझे एक हवाई जहाज का टिकट खरीदना था। लगभग 30 मिनट मैं वायुहीन अंतरिक्ष में चला गया: जब मैंने सभी क्षेत्रों को भर दिया (हालांकि सेवा में एक प्रोफ़ाइल है), तो मैंने एक बार नहीं सब कुछ डबल-चेक किया, फिर ध्यान से सभी भुगतान किए गए विकल्पों को हटा दिया।
IMHO, यह अमानवीय है।

क्यों नहीं मेरे डेटा को याद रखें और इसे स्थानापन्न करें? अतिरिक्त विकल्प क्यों लगाए - वफादारी कम कर देता है?

मुझे लगता है कि मैं असहज और समझ से बाहर UX / UI पर केवल एक ही नाराज नहीं हूं। प्रश्न: "इसका इलाज कैसे किया जाता है?"



अब तक, मैं इस निष्कर्ष पर आया था कि एक समाधान सिस्टम गुणवत्ता संकेतकों का एक व्यवस्थित और स्वतंत्र परीक्षण हो सकता है। जिनके बारे में संस्थान और पाठ्यपुस्तकों में बात की जाती है: एर्गोनॉमिक्स, सुविधा, समझ, कार्य निष्पादन की गति।

आमतौर पर, गुणवत्ता परीक्षण निम्न के लिए आता है:

• टीम समय पर कार्यक्षमता बनाने के लिए अपनी पूरी ताकत से दौड़ती है और कोई भी यूएक्स / यूआई के बारे में नहीं सोचता है
• UX / UI को केवल लेआउट के अनुपालन के लिए जांचा जाता है
• UX / UI परीक्षण परीक्षक के स्वाद और व्यक्तिगत मूल्यांकन के लिए किया जाता है। हां, इसे सामान्य नियमों (उदाहरण के लिए, कूपर की पुस्तकों "ऑन इंटरफेस") से सही ठहराया जा सकता है, लेकिन कस्टम और बी 2 बी सिस्टम में अक्सर गैर-तुच्छ समाधान होते हैं। टीम सुंदर के बारे में स्वाद और विचारों में भिन्न हो सकती है। नतीजतन, यह राय के मतभेदों के कारण असंवैधानिक विवादों की ओर जाता है। उनमें सबसे मजबूत जीत है।

तब मैंने सोचा था कि उत्पादों में आवश्यकताओं को इकट्ठा करते समय एक समान कहानी होती है। ऐसा होता है कि निर्माता अपने दर्द के लिए निर्णय लेते हैं और सोचते हैं कि वे अंतिम उपयोगकर्ताओं की जरूरतों को बंद कर देंगे। वास्तविकता को मैप करने के लिए, एक कस्टमर जर्नी मैप के तरीके हैं।

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

इस सिद्धांत और UX / UI पर जांच क्यों नहीं?

परीक्षण एल्गोरिथ्म:

1) एक परीक्षण नीति पर निर्णय लें।

• परीक्षण के लिए उपयोगकर्ता स्क्रिप्ट का सेट
• परीक्षण किए गए गुणवत्ता संकेतक: सुविधा, एर्गोनॉमिक्स, समझ, आदि।

2)

3 से 5 उत्तरदाताओं का परीक्षण करने के लिए उत्तरदाताओं का पता लगाएं । यह अंतिम उपयोगकर्ता या किसी अन्य टीम के सदस्य हो सकते हैं। मुख्य बात विकास टीम से स्वतंत्रता है।

3) एक अध्ययन का संचालन करें। प्रत्येक प्रतिवादी के साथ

चक्र दोहराएं
> उपयोगकर्ता कार्ड टेम्पलेट लिया गया है।
> प्रतिवादी को कार्य और एक चल प्रणाली / प्रोटोटाइप / लेआउट का परिचय दिया जाता है
> उत्तरदाता के कदम, उसकी प्रतिक्रिया, एक कदम के लिए समय - यह सब टेम्पलेट 4
अंत में दर्ज किया गया है



) डेटा एकत्र करें।

चूंकि एक मैप टेम्प्लेट एक राय है, इसलिए आपको उत्तरदाताओं का प्रतिच्छेदन ढूंढना होगा। प्रत्येक परिदृश्य के लिए, एक गैप मैप मैट्रिक्स संकलित किया जाता है (सीजेएम की सर्वोत्तम परंपराओं में)।

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

5) समस्याओं की एक सूची बनाएं।

मैंने इसे GrowthPointsList नाम दिया है।



डेटा को समस्याओं की सूची में संक्षेपित किया गया है + उत्तरदाताओं की अपेक्षाएं कि सिस्टम कैसे व्यवहार करेगा। आप स्क्रिप्ट के पारित होने पर प्रभाव के स्तर को निर्दिष्ट कर सकते हैं:

1. स्क्रिप्ट पूरी करने में असमर्थ
2. नेगेटिव लेकिन स्क्रिप्ट पास हुई
3. कुछ उत्तरदाताओं के पास एक नकारात्मक था, लेकिन वे स्क्रिप्ट के माध्यम से प्राप्त करने में कामयाब रहे।

इस प्रकार, लेआउट के चरण में विकास से पहले भी, लेआउट का परीक्षण करना और कम लागत पर समस्याओं को समाप्त करना संभव है। परीक्षण का परिणाम उचित है और प्रतिभागियों और ग्राहक के बीच विवाद का कारण नहीं बनता है।

मुझे लगता है कि अनुप्रयोगों की दुनिया इस प्रकार अंतिम उपयोगकर्ताओं के लिए सुविधा और सरलता की ओर बदल सकती है।

टेलीग्राम चैनल - tlgg.ru/@analyst_way (विश्लेषक पथ)