उपयोगकर्ताओं को यह चुनने की अनुमति कैसे दें कि कोई AI उनसे कब और कितनी बार संपर्क करे

एक स्पष्ट, वैकल्पिक ऑप्ट-इन के साथ शुरुआत करें

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

U.S. Web Design System केवल उन्हीं चैनलों के लिए संपर्क प्राथमिकताएं एकत्र करने की सलाह देता है जिन्हें कोई सेवा वास्तव में समर्थन दे सकती है, और कहता है कि जब संभव हो तो संपर्क के लिए शर्तों और अपेक्षित समय-सीमा की व्याख्या करें। किसी AI उत्पाद पर लागू होने पर, इसका अर्थ केवल वास्तविक डिलीवरी विकल्प दिखाना और यह बताना है कि प्रत्येक विकल्प किस उद्देश्य के लिए है। किसी असंबंधित सुविधा का उपयोग करने के लिए सूचना (नोटिफिकेशन) प्राथमिकता को शर्त न बनाएं। USWDS: Contact preferences

ऑप्ट-इन को एक ऐसे विकल्प के रूप में मानें जिस पर उपयोगकर्ता पुनर्विचार कर सकता है। Apple का नोटिफिकेशन मार्गदर्शन नोटिफिकेशन प्रकारों के लिए स्पष्ट ऑप्ट-इन या ऑप्ट-आउट और ऐप के भीतर नोटिफिकेशन सेटिंग्स प्रबंधित करने का एक तरीका सुझाता है। कोई उत्पाद ऐप के स्वयं के शेड्यूल को समझने के लिए असंबंधित डिवाइस सेटिंग्स को खोजने के लिए मजबूर करने के बजाय, वर्तमान विकल्पों को संक्षेप में प्रस्तुत करने वाले एक सेटिंग्स पृष्ठ के साथ उस सिद्धांत का पालन कर सकता है। Apple: Managing notifications

शेड्यूल को ठोस और स्पष्ट बनाएं

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

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

समय क्षेत्रों (टाइम ज़ोन) के बारे में सटीक रहें। शेड्यूल को किसी नामित स्थान या डिवाइस के वर्तमान स्थानीय समय क्षेत्र के साथ लेबल करें, और उपयोगकर्ताओं को बताएं कि जब वे यात्रा करते हैं तो शेड्यूल उनके अनुसार बदलता है या मूल ज़ोन पर ही स्थिर रहता है। जब डेलाइट-सेविंग नियम या सरकारी टाइम-ज़ोन नियम बदलते हैं, तो केवल UTC ऑफ़सेट भ्रामक हो सकता है। IANA का टाइम-ज़ोन डेटाबेस स्थानों के नियमों को रिकॉर्ड करता है और राजनीतिक निकायों द्वारा किए गए परिवर्तनों को दर्शाने के लिए अपडेट किया जाता है, जिसमें ऑफ़सेट और डेलाइट-सेविंग नियमों में बदलाव शामिल हैं। IANA: Time Zone Database

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

संदेश के प्रकारों और चैनलों को अलग करें

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

यह पृथक्करण प्लेटफ़ॉर्म नियंत्रणों के भी अनुकूल है। आधुनिक संस्करणों पर Android को नोटिफिकेशन को चैनलों में असाइन करने की आवश्यकता होती है, और उपयोगकर्ता चैनल के व्यवहार को बदल सकते हैं; Android का मार्गदर्शन ऐसे चैनलों की सिफ़ारिश करता है जो लोगों को प्राप्त होने वाले नोटिफिकेशन्स को कस्टमाइज़ करने देते हैं। ऐप चैनलों को ऐसे नाम दे सकता है जिन्हें लोग पहचानते हैं, जैसे कि "शेड्यूल किए गए रिमाइंडर", और यह बता सकता है कि प्रत्येक में क्या शामिल है। Android Developers: Create and manage notification channels

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

पॉज़, फिर से शुरू करने और ऑफ़ करने के नियंत्रण आसान पहुंच में रखें

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

इन नियंत्रणों को नोटिफिकेशन सेटिंग्स स्क्रीन से और जहां व्यावहारिक हो, किसी नोटिफिकेशन एक्शन या सीधे सेटिंग्स लिंक से उपलब्ध कराएं। Android नोटिफिकेशन्स में एक्शन्स का समर्थन करता है और उपयोगकर्ताओं को भविष्य के नोटिफिकेशन्स को प्रबंधित करने के लिए सिस्टम-स्तरीय तरीके देता है; इसके नियंत्रण डिवाइस और Android संस्करण के अनुसार भिन्न होते हैं। इसलिए, पूरा शेड्यूल दिखाने और उत्पाद-स्तरीय प्राथमिकताओं को बदलने के लिए एक इन-ऐप रास्ता उपयोगी बना रहता है। Android Developers: Notifications

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

एक ऐसी आवृत्ति सीमा निर्धारित करें जिसे सिस्टम लागू कर सके

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

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

प्लेटफ़ॉर्म डिलीवरी किसी उत्पाद के भेजने के निर्णय के समान नहीं है। Firebase Cloud Messaging का कहना है कि संदेश आमतौर पर तुरंत डिलीवर किए जाते हैं, लेकिन कोई डिवाइस अनुपलब्ध हो सकता है या डिलीवरी में देरी हो सकती है; यह सेवा किसी संदेश को संग्रहीत कर सकती है और उसके कॉन्फ़िगर किए गए जीवनकाल के भीतर बाद में डिलीवरी का प्रयास कर सकती है। इसका मतलब है कि किसी उत्पाद को यह वादा नहीं करना चाहिए कि प्रत्येक नोटिफिकेशन एक सटीक मिनट पर दिखाई देगा। यह बताए गए विंडो के भीतर भेजने को शेड्यूल करने का वादा कर सकता है, साथ ही यह समझा सकता है कि डिवाइस और प्लेटफ़ॉर्म की स्थितियां इसके दिखने के समय को प्रभावित कर सकती हैं। Firebase: Set the lifespan of a message

यह अंतर आवृत्ति को भी प्रभावित करता है। यदि कोई नोटिफिकेशन कतार (क्यू) में था और देर से आता है, तो सिस्टम को यह जांचना चाहिए कि क्या उपयोगकर्ता ने उस श्रेणी को रोक दिया है या बंद कर दिया है, और क्या इसे भेजने से वर्तमान सीमा पार हो जाएगी। एक सच्चा डिज़ाइन पुराने कतारबद्ध संदेशों को रद्द कर देता है या दबा देता है जब उपयोगकर्ता की नवीनतम पसंद उन्हें अयोग्य बना देती है।

डिज़ाइन के लिए एक सरल निर्णय क्रम

सेटिंग्स को उपयोगकर्ता द्वारा समझे जाने योग्य वादे में बदलने के लिए इस क्रम का उपयोग करें:

उन संदेश प्रकारों के नाम बताएं जिन्हें उत्पाद वास्तव में भेज सकता है, और प्रत्येक वैकल्पिक श्रेणी को समझने योग्य बनाएं।

उपयोगकर्ता से प्रत्येक वांछित श्रेणी और डिलीवरी चैनल के लिए ऑप्ट-इन करने को कहें। वैकल्पिक संपर्क को पहले से चयनित (प्री-सेलेक्ट) न रखें।

उपयोगकर्ता को दिन, समय या विंडो और अधिकतम आवृत्ति चुनने दें। बताएं कि क्या सीमा समग्र है या प्रति श्रेणी।

समय क्षेत्र प्रदर्शित करें और बताएं कि जब डिवाइस का ज़ोन बदलता है तो क्या शेड्यूल उपयोगकर्ता का अनुसरण करता है।

पॉज़, फिर से शुरू करने और ऑफ़ करने के नियंत्रण दृश्यमान बनाएं, फिर वर्तमान स्थिति और अगले योग्य संपर्क का समय दिखाएं।

डिलीवरी से पहले, शेड्यूल, सीमा, पॉज़ स्थिति और श्रेणी प्राथमिकता की दोबारा जांच करें। डिवाइस डिलीवरी को संभावित रूप से विलंबित मानें, और उत्पाद के वादे को उन शर्तों में वर्णित करें जिन्हें वह नियंत्रित कर सकता है।

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

इस विषय को आगे पढ़ें