5.8

View in English

5.8 डिज़ाइन शोध और उपयोगिता परीक्षण

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

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

सिफ़ारिशें

जनरेटिव शोध को मूल्यांकनात्मक शोध से अलग करें

यह स्पष्ट रहें कि आप कौन सा प्रश्न पूछ रहे हैं, क्योंकि तरीके अलग-अलग होते हैं। जनरेटिव (या डिस्कवरी) शोध खुला-आधारित होता है और समाधान होने से पहले समस्या के दायरे को खोजता है: लोग वास्तव में क्या हासिल करने की कोशिश कर रहे हैं? वर्तमान अनुभव कहाँ दुखता है? वे किस चीज़ के इर्द-गिर्द काम करते हैं? मूल्यांकनात्मक शोध किसी विशिष्ट डिज़ाइन को किसी कार्य के विरुद्ध परखता है: क्या लोग इसे पूरा कर सकते हैं, और वे कहाँ लड़खड़ाते हैं? इन दोनों को मिला देना दोनों को बर्बाद करता है। जब आप अभी भी समस्या को नहीं समझते हों तब एक कसकर स्क्रिप्ट किया गया usability testing सत्र चलाना आपको गलत प्रश्न के चमकदार उत्तर देता है, जबकि जब आपको किसी चेकआउट फ़्लो को मान्य करना हो तब एक असंरचित बातचीत आपको अंदाज़ा लगाने पर छोड़ देती है। पहले शोध प्रश्न को नाम दें, फिर तरीका चुनें, और जनरेटिव निष्कर्षों को उत्पाद खोज (अध्याय 10.14) में फ़ीड करें जहाँ रोडमैप वास्तव में आकार लेता है।

तरीके को प्रश्न से मिलाएँ

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

उपयोगिता परीक्षण जल्दी, अक्सर, और छोटे स्तर पर चलाएँ

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

ऐसे कार्य और प्रश्न लिखें जो गवाह को दिशा न दिखाएँ

आपका अध्ययन केवल उतना ही भरोसेमंद है जितना आपका प्रोटोकॉल, और इसे बर्बाद करने का सबसे तेज़ तरीका है उस उत्तर का संकेत दे देना जिसकी आप उम्मीद करते हैं। प्रतिभागियों को यथार्थवादी लक्ष्य दें, निर्देश नहीं: “आपने अभी-अभी घर बदला है और आपको अपना पता अपडेट करना है” कहें, न कि “एडिट प्रोफ़ाइल बटन पर क्लिक करें और अपना पता बदलें।” भविष्य के इरादों के बजाय अतीत के व्यवहार के बारे में पूछें, क्योंकि “क्या आप इसका उपयोग करेंगे?” लगातार विनम्र झूठ पैदा करता है जबकि “मुझे बताएँ कि आपने पिछली बार यह कब किया था” तथ्य पैदा करता है। ऐसे प्रश्नों से बचें जो अपने ही निष्कर्ष को मान लेते हैं, और confirmation bias के प्रति सतर्क रहें, यह वह मानवीय प्रवृत्ति है जिसमें हम उस सबूत को नोटिस और याद रखते हैं जो पहले से हमारे विश्वास का समर्थन करता है। जिस शोधकर्ता ने डिज़ाइन लिखा है उसे चुपचाप प्रतिभागियों को सफलता की ओर कोच नहीं करना चाहिए, और देख रही टीम को यह चर्चा करने से पहले कि इसका क्या अर्थ है, यह रिकॉर्ड करना चाहिए कि क्या हुआ। जब आप कार्यों के डिज़ाइन और संचार को उत्पाद के डिज़ाइन (अध्याय 5.4) से अलग करते हैं, तो आपको साफ़ संकेत मिलता है।

ऐसे प्रतिभागी भर्ती करें जो वास्तव में आपके उपयोगकर्ताओं का प्रतिनिधित्व करते हों

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

निष्कर्षों को केवल रिपोर्ट नहीं, बल्कि निर्णयों में संश्लेषित करें

कच्चे अवलोकन अंतर्दृष्टि नहीं हैं। संश्लेषण का काम सत्र नोट्स के ढेर को कुछ गिने-चुने निर्णयों में बदलना है जिन पर टीम कार्रवाई कर सके। एफ़िनिटी मैपिंग, व्यक्तिगत अवलोकनों को विषयों में समूहित करना (affinity diagram के पीछे का अभ्यास), सत्रों में पैटर्न को दृश्यमान बनाने के लिए मानक कदम है। साक्षात्कार-भारी अध्ययनों के लिए, एक हल्का thematic analysis आपको इस बारे में ईमानदार रखता है कि कौन से विषय वास्तव में डेटा द्वारा समर्थित हैं। स्थायी पैटर्न को अध्याय 5.1 के साझा मॉडलों में शामिल करें (साक्ष्य-आधारित पर्सोना और जर्नी मैप) ताकि अंतर्दृष्टि वाष्पित होने के बजाय संयोजित (compound) हो। अच्छे संश्लेषण की कसौटी सरल है: क्या कोई निर्णय बदला? एक अध्ययन जो एक खूबसूरत डेक बनाता है और रोडमैप की कोई मद नहीं बदलता, वह तमाशा था। हर अध्ययन को निष्कर्षों की एक छोटी, क्रमबद्ध सूची और हरेक के लिए एक अनुशंसित कार्रवाई के साथ समाप्त करें।

गुणात्मक शोध को एनालिटिक्स और प्रयोग के साथ त्रिकोणित करें

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

रिसर्च ऑपरेशंस बनाएँ ताकि शोध बड़े पैमाने पर चल सके

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

समझौते: लाभ और हानि

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

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

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

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

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

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

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

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

क्षेत्र लेंस

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

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

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

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

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

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

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

  • स्तर 1, आरंभ (Initiate): शोध तदर्थ या अनुपस्थित है, और निर्णय राय और वरिष्ठता पर टिके हैं। उपयोगिता परीक्षण, यदि होता भी है, तो लॉन्च से पहले जो भी उपलब्ध हो उसके साथ एक प्रतिक्रियाशील एकबारगी कार्य है, और निष्कर्ष शायद ही कुछ बदलते हैं।
  • स्तर 2, विकास (Develop): कुछ टीमें उपयोगिता परीक्षण और कभी-कभार साक्षात्कार चलाती हैं, लेकिन भर्ती सुविधाजनक है, प्रोटोकॉल अनौपचारिक हैं, और अंतर्दृष्टियाँ बिखरे हुए डेक में रहती हैं। अभ्यास स्क्वाड-दर-स्क्वाड व्यापक रूप से अलग होता है, और शोध एक ऐसा चरण है जो शेड्यूल दबाव में कट जाता है।
  • स्तर 3, मानकीकरण (Standardize): जनरेटिव और मूल्यांकनात्मक शोध दस्तावेज़ीकृत हैं और टीमों में निरंतर चलते हैं, एक साझा प्रक्रिया के ज़रिए प्राथमिकता को फ़ीड करते हैं। भर्ती वास्तविक खंडों को लक्षित करती है जिसमें विकलांग और कठिनाई से पहुँच योग्य उपयोगकर्ता शामिल हैं, एक खोजने योग्य अंतर्दृष्टि भंडार मौजूद है, संश्लेषण क्रमबद्ध निर्णय पैदा करता है, और रिसर्च ऑपरेशंस पूरे संगठन में कैडेंस, टेम्पलेट, और प्रतिभागियों का प्रबंधन करते हैं।
  • स्तर 4, प्रबंधन (Manage): शोध कार्यक्रम को बेसलाइन के विरुद्ध मापा जाता है। टीमें उपयोगकर्ता खंडों के कवरेज, कार्य सफलता और पूर्णता दरों, अंतर्दृष्टि से शिप किए गए बदलाव तक के समय, और सहायता आयतन, प्रशिक्षण समय, और त्रुटि व पुनःकार्य दरों पर डाउनस्ट्रीम प्रभाव को ट्रैक करती हैं, और जब कोई मीट्रिक फिसलता है तो कार्रवाई को ट्रिगर करने वाली सीमाएँ तय करती हैं। भंडार का पुनः उपयोग और अध्ययन की गुणवत्ता निगरानी की जाती है, ताकि नेता उस रिटर्न को देख सकें जो शोध पैदा करता है, बजाय इसे मान लेने के।
  • स्तर 5, ऑर्केस्ट्रेशन (Orchestrate): शोध एनालिटिक्स और प्रयोग के साथ एक निरंतर, त्रिकोणित लूप है, जो अंतर्दृष्टि से शिप किए गए बदलाव से मापे गए प्रभाव तक बंद होता है, और यह पूरे संगठन में उत्पाद रणनीति और जोखिम योजना के साथ एकीकृत है। लोकतांत्रिक शोध गार्डरेल के भीतर सुरक्षित रूप से चलता है, निष्कर्ष उत्पाद और उसके उपयोगकर्ताओं के बदलने के साथ संयोजित और अनुकूलित होते हैं, और शोध प्रदर्शनात्मक रूप से रणनीति को आकार देता है, केवल स्क्रीन को नहीं।

चर्चा के लिए विचार

  1. किसी निर्माण के प्रति प्रतिबद्ध होने से पहले कितनी खोज “पर्याप्त” है, और यह कहने का अधिकार किसके पास है कि आपने पर्याप्त सीख लिया है?
  2. जब एनालिटिक्स और साक्षात्कार आपको उसी फ़ीचर के बारे में विपरीत कहानियाँ बताते हैं, तो टीम को कैसे तय करना चाहिए कि किस पर कार्रवाई करनी है?
  3. जिम्मेदारी से शोध को लोकतांत्रिक बनाने और अप्रशिक्षित उत्साह को बड़े पैमाने पर पूर्वाग्रहपूर्ण अध्ययन पैदा करने देने के बीच की रेखा कहाँ है?
  4. आप किसी ऐसे अध्ययन पर रिटर्न कैसे मापते हैं जिसका मूल्य एक ऐसी गलती है जो आपने इसलिए कभी नहीं की और जिसकी ओर आप कभी इशारा नहीं कर सकते?
  5. संकट में या असुरक्षित परिस्थितियों में लोगों के साथ उनके बोझ को बढ़ाए बिना शोध करने का नैतिक तरीका क्या है?
  6. क्या अनिवार्य उपयोगकर्ता शोध, जैसा कि सरकारी सेवा मानकों में होता है, एक ऐसा द्वार होना चाहिए जो लॉन्च को रोक सके, और इसे कौन लागू करता है?

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

  • Erika Hall, Just Enough Research
  • Steve Krug, Rocket Surgery Made Easy
  • Jakob Nielsen, Usability Engineering
  • Mike Kuniavsky, Observing the User Experience
  • Steve Portigal, Interviewing Users
  • Tomer Sharon, Validating Product Ideas: Through Lean User Research
  • Hugh Beyer and Karen Holtzblatt, Contextual Design
  • Donna Spencer, Card Sorting: Designing Usable Categories
  • Kathy Baxter, Catherine Courage, and Kelly Caine, Understanding Your Users
  • Kate Towsey, Research That Scales: The Research Operations Handbook
  • Nielsen Norman Group, उपयोगिता परीक्षण, नमूना आकार, और शोध तरीकों पर लेख
  • UK Government Digital Service, Service Manual: उपयोगकर्ता शोध मार्गदर्शन