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