यूज़ेबिलिटी परीक्षण को महंगा और धीमा होने की अयोग्य प्रतिष्ठा है। जब लोग "उपयोगकर्ता अनुसंधान" सुनते हैं, तो वे एक तरफा दर्पण, क्लिपबोर्ड वाले मॉडरेटर, और दो सप्ताह की समयरेखा की कल्पना करते हैं। परीक्षण का वह संस्करण मौजूद है और इसके उपयोग हैं — लेकिन यह संस्करण नहीं है जो अधिकांश उत्पाद टीमों को अधिकांश समय की आवश्यकता है।
जो संस्करण अधिकांश टीमों को चाहिए वह सरल है: पाँच उपयोगकर्ता, एक Figma प्रोटोटाइप या स्टेजिंग वातावरण, एक वीडियो कॉल, और प्रति सत्र 45 मिनट। अच्छी तरह से किया गया, यह डिलीवर होने से पहले गंभीर यूज़ेबिलिटी समस्याओं की अधिकांश सतह करता है। लगातार किया गया — यहां तक कि प्रति स्प्रिंट एक बार — यह उत्पाद गुणवत्ता में एक यौगिक सुधार का उत्पादन करता है जो कोई भी पोस्ट-लॉन्च विश्लेषण दोहरा सकता है।
यहां बताया गया है कि इसे खरोंच से कैसे चलाएं।
पाँच प्रतिभागी अधिकांश यूज़ेबिलिटी परीक्षणों के लिए सही संख्या है। Jakob Nielsen के शोध ने स्थापित किया कि पाँच उपयोगकर्ता लगभग 85% यूज़ेबिलिटी समस्याओं को उजागर करते हैं, उसके बाद लाभ घटते हैं। डिज़ाइन प्रक्रिया में विभिन्न बिंदुओं पर पाँच उपयोगकर्ताओं के तीन सत्र पंद्रह के साथ एक सत्र से अधिक मूल्यवान हैं।
भर्ती के लिए मानदंड संख्या से अधिक महत्वपूर्ण हैं। पाँच लोगों के साथ एक यूज़ेबिलिटी परीक्षण जो आपके लक्ष्य उपयोगकर्ता से मेल खाते हैं वास्तविक समस्याओं को प्रकट करेगी। पंद्रह के साथ एक परीक्षण जो मेल नहीं खाते शोर उत्पन्न करेंगे। दो या तीन स्क्रीनिंग मानदंड परिभाषित करें — भूमिका, उपयोग का संदर्भ, तकनीकी आराम का स्तर — और उन्हें रखें।
अधिकांश टीमों के लिए सबसे तेज़ भर्ती मार्ग संपर्क अनुमति दी गई मौजूदा उपयोगकर्ताओं को ईमेल कर रहा है। एक मामूली प्रोत्साहन दें — 45 मिनट के सत्र के लिए £20 उपहार कार्ड पर्याप्त है। सत्रों को एक ही सप्ताह के भीतर शेड्यूल करने का लक्ष्य रखें; भर्ती और परीक्षण के बीच जितना लंबा अंतराल, उतना अधिक नो-शो दर।
सबसे आम स्क्रिप्टिंग गलती कार्यों को निर्देश के रूप में लिखना है: "सेटिंग पर क्लिक करें, फिर अधिसूचनाओं में नेविगेट करें, और अपनी पसंद को..." में बदलें। यह उपयोगकर्ता को बताता है कि क्या करना है, जिसका अर्थ है कि आप यह परीक्षण कर रहे हैं कि क्या वे निर्देशों का पालन कर सकते हैं, यह नहीं कि क्या इंटरफेस सहज है।
इसके बजाय कार्यों को परिदृश्य के रूप में लिखें: "कल्पना करें कि आप बहुत अधिक अधिसूचनाएं प्राप्त कर रहे हैं और आप केवल सतर्कताएं प्राप्त करना चाहते हैं जब कोई सीधे आपका उल्लेख करता है। दिखाएं कि आप क्या करेंगे।" यह उपयोगकर्ता को एक वास्तविक लक्ष्य देता है और आपको यह देखने देता है कि वे वास्तव में कैसे नेविगेट करते हैं — भ्रम के बिंदुओं सहित।
यूज़ेबिलिटी परीक्षण को संचालित करने का सबसे कठिन हिस्सा मदद करने की इच्छा का विरोध कर रहा है। जब एक उपयोगकर्ता भ्रमित होता है, तो हर प्रवृत्ति कहती है कि अंदर कूदो और उन्हें दिखाओ कि कहां क्लिक करना है। लेकिन भ्रम डेटा है। एक उपयोगकर्ता जो संघर्ष कर रहा है इंटरफेस के साथ कुछ गलत बता रहा है — और उस क्षण आप हस्तक्षेप करते हैं, आप संकेत खो देते हैं।
पूरे सत्र में उपयोगकर्ताओं से जोर से सोचने के लिए कहें: "जैसा कि आप चलते हैं, बस मुझे बताएं कि आप क्या देख रहे हैं और क्या सोच रहे हैं।" यह उनके मानसिक मॉडल के बारे में डेटा की एक सतत धारा का उत्पादन करता है। केवल त्रुटियों के लिए नहीं बल्कि संकोच को नोट करें — एक उपयोगकर्ता जो सही बटन पर क्लिक करने से पहले तीन सेकंड रुका हुआ है फिर भी एक डिजाइन समस्या प्रकट किया है, भले ही वे अंत में सफल रहे।
संश्लेषण चरण है जहां अधिकांश मूल्य बनाया जाता है — और जहां अधिकांश टीमें कोने काटती हैं। पाँच सत्रों से कच्ची नोट्स निष्कर्ष नहीं हैं। वे निष्कर्ष बन जाते हैं जब आप एक टीम के रूप में डिब्रीफ करते हैं, अवलोकन को विषय से समूहबद्ध करते हैं, और गंभीरता दर असाइन करते हैं।
सत्रों के समान दिन में डिब्रीफ करें, जबकि अवलोकन ताजे हों। तीन बाल्टियों में समस्याओं को समूहबद्ध करें: महत्वपूर्ण (उपयोगकर्ता कार्य पूरा नहीं कर सके), मध्यम (उपयोगकर्ता कार्य को महत्वपूर्ण कठिनाई या त्रुटि के साथ पूरा किया), और मामूली (घर्षण जो पूर्ण होने से नहीं रोका)। महत्वपूर्ण समस्याओं को डिलीवर होने से पहले तय करने की आवश्यकता है। मध्यम समस्याओं को अगली स्प्रिंट में प्राथमिकता दी जानी चाहिए। मामूली समस्याएं बैकलॉग में जाती हैं।
एक एकल पृष्ठ में निष्कर्ष लिखें: शीर्ष तीन महत्वपूर्ण समस्याएं, कम से कम दो प्रतिभागियों से सबूत, और प्रत्येक के लिए प्रस्तावित डिजाइन परिवर्तन। कुछ भी जिसे उससे अधिक जगह की आवश्यकता है एक अलग दस्तावेज़ में जाता है।