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