उपयोगकर्ता फ़ीडबैक को अपने अगले प्रॉम्प्ट में बदलना: तीन तरीके जिनसे लोग इसे गलत करते हैं

आप कुछ शिप करते हैं, लोग इसका इस्तेमाल शुरू करते हैं, और एक हफ्ते के भीतर मैसेज आना शुरू हो जाते हैं। एक-सितारा रिव्यू जिसमें लिखा है "भ्रमित करने वाला।" एक DM जिसमें लिखा है "क्या यह X भी कर सकता है।" एक सपोर्ट टिकट जो असल में किसी ऐसे बटन के बारे में भड़ास है जो किसी को नहीं मिला। यह अच्छी समस्या है — इसका मतलब है कि लोगों को इतनी परवाह है कि वे आपको कुछ गड़बड़ होने के बारे में बता रहे हैं। लेकिन यही वह पल भी है जब ज़्यादातर बिल्डर्स चुपचाप चीज़ों को और बिगाड़ना शुरू कर देते हैं, क्योंकि फीडबैक के एक टुकड़े को प्रॉम्प्ट में बदलना सरल लगता है, और यह लगभग कभी नहीं होता।

मैंने कई बिल्ड्स को लॉन्च के बाद बेहतर होने की बजाय बदतर होते देखा है, और इसकी वजह शायद ही कभी खराब फीडबैक होती है। यह इस बात पर निर्भर करता है कि मैसेज पढ़ने और अगला प्रॉम्प्ट टाइप करने के बीच क्या हुआ। तीन पैटर्न बार-बार सामने आते हैं।

गलती एक: उन्होंने जो टाइप किया, ठीक वही बना देना

एक यूज़र कहता है "काश हेडर में डार्क मोड टॉगल होता।" तो आप बिल्ड चैट खोलते हैं और टाइप करते हैं: "हेडर में डार्क मोड टॉगल जोड़ो।" बिल्डर ऐसा कर देता है। टिकट बंद, है ना?

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

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

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

गलती दो: चुप रहना, फिर सब कुछ एक साथ उड़ेल देना

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

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

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

गलती तीन: सबसे तेज़ आवाज़ को रोडमैप तय करने देना

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

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

सही प्रॉम्प्ट वास्तव में कैसा दिखता है

फिक्स कोई प्रोसेस डायग्राम नहीं है, यह एक आदत है: बिल्ड चैट को छूने से पहले मैसेज पढ़ें, फिर सोचें कि उसके पीछे असल में क्या है। जब डार्क-मोड वाला यूज़र आता है, तो अंतर्निहित ज़रूरत आमतौर पर होती है "रात में आंखों पर दबाव कम करना", और सस्ता, बेहतर जवाब अक्सर होता है "OS-लेवल कलर स्कीम सेटिंग का सम्मान करें" — एक लाइन, कोई नया UI सरफ़ेस नहीं, कोई टॉगल मेंटेन नहीं करना। जब एक हफ्ते में पांच टिकट आएं, तो कुछ भी लिखने से पहले पैटर्न देखें: अगर उनमें से तीन असल में एक ही कन्फ्यूज़न को तीन अलग तरीकों से बता रहे हैं, तो वह एक प्रॉम्प्ट है, तीन नहीं।

तेज़ी से आगे बढ़ने की चाहत में भी बदलावों को सिंगल-पर्पज़ रखें। "चेकआउट एरर ठीक करें जहां गेस्ट यूज़र्स रीफ्रेश पर अपनी कार्ट खो देते हैं" ऐसा प्रॉम्प्ट है जिसे आप एक ही पास में वेरिफाई कर सकते हैं और गलत होने पर साफ़-साफ़ रोलबैक कर सकते हैं। इससे छह हफ्ते बाद भी एक ऐसा वर्ज़न कार्ड मिलता है जिसका मतलब हो, न कि सिर्फ़ "various fixes" लिखा एक चेंजलॉग एंट्री।

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

इसका मतलब यह नहीं कि उन यूज़र्स को नज़रअंदाज़ करें जो आपको लिखने का समय निकालते हैं। इसका मतलब है कि "किसने सबसे हाल ही में और सबसे प्रभावशाली ढंग से लिखा" को यह तय करने का एल्गोरिदम न बनने दें कि आगे क्या बनेगा। मैसेज बातचीत की शुरुआत है, टिकट नहीं। किसी ने जो कहा उससे यह तय करना कि आप बिल्डर से असल में क्या मांग रहे हैं — यह अनुवाद हर बार आपको ही करना है।