सक्रिय (प्रोएक्टिव) AI संदेश बनाने से पहले, “ना” को सुनें
यदि आप किसी ऐसे AI फ़ीचर पर विचार कर रहे हैं जो अपने आप बातचीत शुरू करता है, तो पहले यह पता लगाएं कि लोग कब कुछ भी नहीं सुनना पसंद करेंगे। संभावित उपयोगकर्ताओं को शोध साक्षात्कार (रिसर्च इंटरव्यू) में शामिल होने के लिए आमंत्रित करें, उन सामान्य पलों के बारे में पूछें जब बिना मांगा गया संदेश अवांछित होगा, और एक प्रतिवर्ती (रिवर्सिबल) प्रोटोटाइप के माध्यम से संदेश की अवधारणाओं का परीक्षण करें। स्पष्ट “मुझसे संपर्क न करें” को दूर करने योग्य आपत्ति के बजाय समझने और सम्मान करने योग्य उत्पाद आवश्यकता के रूप में मानें। इसका लक्ष्य यह जानना है कि लोग किस प्रकार के संपर्क का, यदि कोई हो तो, स्वागत करना चुनते हैं।
फ़ीचर के पीछे के प्रश्न से शुरुआत करें
AI को “अधिक सक्रिय (प्रोएक्टिव)” बनाने का प्रस्ताव कई अलग-अलग विचारों को छिपा सकता है: एक अनुस्मारक (रिमाइंडर), एक सुझाव, एक हालचाल पूछना, या किसी दिनचर्या से जुड़ा संदेश। ये सभी अलग-अलग अनुभव हैं। भर्ती करने से पहले, प्रस्तावित विशिष्ट व्यवहार को सरल भाषा में लिखें: कौन सी बात संदेश को ट्रिगर कर सकती है, उसमें क्या कहा जा सकता है, और व्यक्ति इसे कहाँ देखेगा। यह प्रतिभागियों को यह नाटक किए बिना प्रतिक्रिया देने के लिए कुछ ठोस प्रदान करता है कि फ़ीचर पहले से मौजूद है।
शोध के प्रश्न को खुला रखें। उदाहरण के लिए: “किन स्थितियों में, यदि कोई हो, आप इस तरह का संदेश चाहेंगे, और आप इसे कब प्राप्त नहीं करना पसंद करेंगे?” केवल यह पूछने से बचें कि क्या किसी को यह विचार पसंद है या वे कितनी बार संदेश चाहते हैं। एक व्यापक सकारात्मक उत्तर महत्वपूर्ण सीमाओं को छिपा सकता है: उदाहरण के लिए, कोई खाना बनाते समय कभी-कभार आने वाले नोट का स्वागत कर सकता है, और काम, यात्रा या अन्य लोगों के साथ समय बिताने के दौरान शांति चाहता है। ये खोज के लिए संकेत हैं, उपयोगकर्ता क्या कहेंगे इस बारे में दावे नहीं।
उन लोगों को शामिल करें जो आपके द्वारा डिज़ाइन किए जा रहे अनुभव के वास्तविक या संभावित उपयोगकर्ता हैं, और उनके भाग लेने के लिए सहमत होने से पहले आमंत्रण को स्पष्ट करें। GOV.UK का उपयोगकर्ता-शोध मार्गदर्शन उद्देश्य और गतिविधि को स्पष्ट करने, भागीदारी को स्वैच्छिक बनाने, और किसी भी समय रुकने या हटने की क्षमता को स्पष्ट रखने की सिफारिश करता है। यह लोगों को पहले से जानकारी देने की भी सिफारिश करता है ताकि वे तैयारी कर सकें और यह तय कर सकें कि वे भाग लेने में सहज हैं या नहीं (Getting informed consent for user research; Finding participants for user research)।
केवल प्राथमिकताओं के बारे में नहीं, बल्कि स्थितियों के बारे में पूछें
एक छोटे साक्षात्कार में, हाल के, सामान्य उदाहरणों से शुरुआत करें। पूछें कि लोग पहले से ही किस तरह के डिजिटल संदेशों पर ध्यान देते हैं, वे कब उनका स्वागत करते हैं, और जब वे उन्हें अनदेखा या खारिज करते हैं तो क्या हो रहा होता है। फिर संदर्भ का पता लगाएं: दिन का समय, वे क्या कर रहे हैं, क्या उन्होंने कोई गतिविधि शुरू की है, और क्या कोई अन्य व्यक्ति पास में है। प्रतिभागियों से किसी अमूर्त आदर्श की भविष्यवाणी करने के लिए कहने के बजाय चर्चा को प्रत्यक्ष दिनचर्या और विकल्पों पर केंद्रित रखें।
उपयोगी तटस्थ संकेतों में शामिल हैं: “मुझे हाल ही के उस समय के बारे में बताएं जब आप व्यस्त थे और किसी ऐप ने आपसे संपर्क किया,” “उस पल में इस तरह के संदेश को क्या उपयोगी बनाएगा?” और “क्या ऐसा कोई समय है जब आप चाहेंगे कि यह फ़ीचर शांत रहे?” इसके बाद पूछें “वह स्थिति अलग कैसे है?” प्रतिभागी को सीमा निर्धारित करने का अवसर दें। उन कारणों से चुप्पी को न भरें जो उन्होंने नहीं दिए हैं या “हाँ” को पसंदीदा उत्तर के रूप में प्रस्तुत न करें।
संपर्क के प्रकारों के बारे में अलग से पूछें। कोई व्यक्ति किसी फ़ीचर का उपयोग करते समय इन-ऐप संक्षिप्त सुझाव के लिए तैयार हो सकता है, लेकिन ऐप बंद होने पर आने वाले पुश अलर्ट के लिए नहीं। वे केवल किसी विशेष गतिविधि को चुनने के बाद ही कोई संदेश चाह सकते हैं, या बिल्कुल भी कोई बिन मांगा संदेश नहीं चाह सकते हैं। Apple का नोटिफिकेशन दस्तावेज़ इससे संबंधित एक उत्पाद भेद करता है: यह ऐसे संदर्भ में सूचना (नोटिफिकेशन) की अनुमति मांगने की सलाह देता है जहाँ उद्देश्य समझ में आता हो, और सूचनाओं को संभावित रूप से बाधा डालने वाले के रूप में वर्णित करता है (Asking permission to use notifications)। वह प्लेटफ़ॉर्म मार्गदर्शन यह स्थापित नहीं करता है कि आपके उपयोगकर्ता क्या पसंद करते हैं; साक्षात्कारों को उनकी अपनी शर्तों और स्थितियों को सामने लाना चाहिए।
शोध के आमंत्रण को वास्तव में वैकल्पिक बनाएं
भाग लेने का आमंत्रण अध्ययन किए जा रहे सक्रिय फ़ीचर जैसा नहीं होना चाहिए। स्पष्ट रूप से बताएं कि यह सत्र एक शोध है, प्रतिभागी से क्या करने के लिए कहा जाएगा, आप क्या जानकारी एकत्र करेंगे, और निष्कर्षों का उपयोग कैसे किया जाएगा। सहमति सीधे मांगें। सामान्य अनुभव तक पहुंच खोए बिना अस्वीकार करना आसान बनाएं। व्यक्तिगत जानकारी एकत्र करने पर GOV.UK का मार्गदर्शन एक सीधा, विशिष्ट विकल्प चुनने की सलाह देता है और कहता है कि इनकार करने से सेवा के उपयोग में बाधा नहीं आनी चाहिए (Collecting personal information from users)।
नोट्स लेने या रिकॉर्डिंग करने से पहले, उन विकल्पों की व्याख्या करें और विशिष्ट संग्रह पद्धति के लिए सहमति प्राप्त करें। एक प्रतिभागी साक्षात्कार के लिए सहमत हो सकता है लेकिन रिकॉर्डिंग से इनकार कर सकता है। स्पष्ट करें कि वे किसी प्रश्न को छोड़ सकते हैं, रुक सकते हैं या समाप्त कर सकते हैं। GOV.UK मार्गदर्शन नोट्स या रिकॉर्डिंग से पहले सूचित सहमति प्राप्त करने और उनका उपयोग केवल उसी के लिए करने की सिफारिश करता है जिसके लिए सहमति दी गई थी (Taking notes and recording user research sessions)।
अंत में, पूछें कि क्या प्रतिभागी दर्ज की गई जानकारी से सहज है और उन्हें याद दिलाएं कि यदि वे अपनी पसंद पर पुनर्विचार करना चाहते हैं तो अनुवर्ती कार्रवाई (फॉलो अप) कैसे करें। नोट्स को डिज़ाइन प्रश्न पर केंद्रित रखें; ऐसी व्यक्तिगत जानकारी एकत्र करने से बचें जिसकी आवश्यकता नहीं है। बताएं कि शोध टीम प्रतिभागियों को किसी फ़ीचर को स्वीकार करने के लिए मनाने के बजाय संपर्क प्राथमिकताओं के बारे में सीख रही है।
एक प्रतिवर्ती (रिवर्सिबल) प्रोटोटाइप के साथ विचार का परीक्षण करें
साक्षात्कारों के बाद, उभरती हुई स्थितियों को संदेश अवधारणाओं के एक छोटे सेट में बदलें। सामान्य गतिविधियों से जुड़े तटस्थ उदाहरणों का उपयोग करें, और शब्दों के साथ-साथ ट्रिगर और वितरण संदर्भ भी दिखाएं। एक संदेश केवल एक वाक्य नहीं है: प्रतिभागियों को यह जानने की आवश्यकता है कि क्या यह सक्रिय उपयोग के दौरान आता है, बाद में दिखाई देता है, या उत्पाद के बाहर उन तक पहुँचता है। अवधारणा को स्पष्ट रूप से एक प्रोटोटाइप के रूप में लेबल करें ताकि लोग इसे कोई लाइव फ़ीचर समझने की भूल न करें।
प्रतिभागियों को एक प्रतिवर्ती विकल्प आज़माने दें जैसे कि “मुझे यह उदाहरण दिखाएं,” “इस गतिविधि के लिए इसे आज़माएं,” या “कोई सक्रिय संदेश नहीं।” यदि प्रोटोटाइप किसी सूचना का अनुकरण करता है, तो दिखाएं कि परीक्षण को कैसे रोका जाए और पुष्टि करें कि रोकना काम करता है। परीक्षण के हिस्से के रूप में तब तक वास्तविक संदेश न भेजें जब तक कि लोगों ने जानबूझकर उस विशिष्ट परीक्षण को न चुना हो। परीक्षण को इतना छोटा रखें कि प्रतिभागी किसी स्थायी सेटिंग के लिए प्रतिबद्ध हुए बिना अनुभव का आकलन कर सकें।
प्रतिक्रियाओं के साथ-साथ कार्रवाइयों पर भी नज़र रखें: क्या लोग उदाहरण को सक्षम करना चुनते हैं, इसे खारिज करते हैं, प्रस्तावित संदर्भ को बदलते हैं, या इसे बंद कर देते हैं? पूछें कि उन्होंने प्रत्येक नियंत्रण से क्या करने की अपेक्षा की थी। यह एक व्यावहारिक शोध पद्धति है, इस बात का प्रमाण नहीं कि कोई एक नियंत्रण हर उत्पाद के अनुकूल होगा। मुख्य परीक्षण यह है कि क्या प्रतिभागी विकल्प को समझ सकते हैं और बिना किसी बाधा के इसे वापस उलट (रिवर्स कर) सकते हैं।
इनकारों को कार्रवाई योग्य सीमाओं के रूप में दर्ज करें
“ना” कहने के अलग-अलग अर्थ हो सकते हैं। एक प्रतिभागी किसी एक समय, एक संदेश प्रकार, एक गतिविधि, या सभी सक्रिय संपर्कों को अस्वीकार कर सकता है। सीमा को उनके शब्दों में और उसके आस-पास की परिस्थितियों को दर्ज करें। एक उपयोगी संश्लेषण निष्कर्षों को स्थिति और पसंद के आधार पर समूहित करता है: किसी चुनी गई गतिविधि में स्वागत किया गया, केवल एक सीमित संदर्भ में स्वीकार्य, या स्पष्ट रूप से अवांछित। कभी-कभार आने वाले संदेशों की व्यापक प्राथमिकता के तहत इसे दबाने के बजाय “कोई संपर्क नहीं” को एक अलग निष्कर्ष के रूप में दृश्यमान रखें।
लोगों ने जो कहा उसे अपनी व्याख्या से अलग रखें। उदाहरण के लिए: “प्रतिभागी ने सक्रिय सत्र के बाहर किसी भी संदेश के लिए मना किया” एक अवलोकन है; “केवल-सत्र विकल्प की आवश्यकता हो सकती है” एक डिज़ाइन निष्कर्ष है। अनिश्चितता को भी दर्ज करें। एक साक्षात्कार एक संभावित सीमा की पहचान कर सकता है, लेकिन यह स्थापित नहीं कर सकता कि वह प्राथमिकता पूरे दर्शकों में कितनी सामान्य है।
यह तय करने के लिए निष्कर्षों का उपयोग करें कि क्या फ़ीचर को आगे बढ़ाया जाना चाहिए और डिज़ाइन में कौन से विकल्प दिखने चाहिए। यदि लोग सार्थक नो-कॉन्टैक्ट स्थितियों का वर्णन करते हैं, तो उन्हें अवधारणा में शामिल करें और उनका फिर से परीक्षण करें। यदि प्रतिभागी कोई सक्रिय संपर्क नहीं चुनते हैं, तो उस परिणाम को प्रोटोटाइप और शोध सारांश में बनाए रखें। सुनने का उद्देश्य यह है कि उपयोगकर्ताओं के इनकार से डिज़ाइन में बदलाव लाया जा सके।
पहले शोध दौर के लिए एक व्यावहारिक क्रम
एक प्रस्तावित सक्रिय व्यवहार का वर्णन करें, जिसमें उसका ट्रिगर, संदेश और वितरण संदर्भ शामिल हो।
एक स्पष्ट, वैकल्पिक शोध आमंत्रण के साथ संभावित उपयोगकर्ताओं को आमंत्रित करें; सत्र का विवरण पहले से साझा करें।
हाल के संदेशों और उन विशिष्ट स्थितियों के बारे में पूछें जहाँ संपर्क का स्वागत है, सीमित है या अवांछित है।
स्पष्ट विकल्पों के साथ एक स्पष्ट रूप से लेबल किया गया प्रोटोटाइप प्रस्तुत करें, जिसमें कोई सक्रिय संपर्क न होना भी शामिल है।
प्रतिभागियों को अपनी पसंद को उलटने (रिवर्स करने) दें, और देखें कि क्या नियंत्रण उनकी अपेक्षाओं से मेल खाते हैं।
प्रत्यक्ष अवलोकनों को डिज़ाइन के निष्कर्षों से अलग संश्लेषित करें; स्पष्ट ऑफ़ विकल्पों को अगली अवधारणा में ले जाएं।
यह क्रम एक टीम को यह जानने में मदद करता है कि क्या किसी धारणा के आधार पर निर्माण करने से पहले अनुभव में सक्रिय संपर्क का कोई स्थान है या नहीं। साक्षात्कार उन स्थितियों को उजागर करते हैं जिनका लोग वर्णन करते हैं; प्रतिवर्ती प्रोटोटाइप उन्हें एक ठोस विकल्प पर प्रतिक्रिया देने की अनुमति देते हैं। दोनों मिलकर “ना” को उपयोगी डिज़ाइन इनपुट बनाते हैं और लोगों को शांति चुनने का एक वास्तविक तरीका देते हैं।
