उपयोगकर्ताओं की वास्तविक ज़रूरतों से लेख का विषय कैसे चुनें
एक स्वतंत्र वेबसाइट संपादक के लिए, किसी उपयोगी लेख के विषय की शुरुआत पाठक द्वारा किसी विशिष्ट कार्य को पूरा करने के प्रयास से होती है—न कि किसी व्यापक कीवर्ड या अस्पष्ट विषय से। यह विधि देखे गए प्रश्नों को एक परिभाषित उपयोगकर्ता, एक मुख्य उद्देश्य और एक पेज निर्णय में बदल देती है: नया लेख बनाएं, मौजूदा लेख को अपडेट करें, या विषय को अस्वीकार करें। यह बार-बार सामने आने वाली सार्वजनिक ज़रूरतों को खाता-विशिष्ट सहायता अनुरोधों और डुप्लिकेट विचारों से अलग करने के लिए एक साक्ष्य लेज़र (evidence ledger) का उपयोग करती है।
विषय के शीर्षक से नहीं, पाठक के कार्य से शुरुआत करें
प्रस्तावित आवश्यकता को तीन भागों में लिखें:
एक [विशिष्ट पाठक] के रूप में, मुझे [कुछ करने या निर्णय लेने] की आवश्यकता है, ताकि मैं [एक उपयोगी परिणाम प्राप्त] कर सकूँ।
यह संरचना GOV.UK की उपयोगकर्ता-ज़रूरत पद्धति से ली गई है, जो उपयोगकर्ता, क्रिया और उस क्रिया के कारण की पहचान करने की सिफारिश करती है। इसका मार्गदर्शन संपादकों को “समझना” जैसी अस्पष्ट क्रियाओं के प्रति सतर्क रहने की चेतावनी भी देता है, जब तक कि किसी परिभाषित कार्य के लिए समझना आवश्यक न हो (GOV.UK: Identify user needs)।
उदाहरण के लिए, “शुरुआती फ़ोटोग्राफ़ी” एक विषय है, अभी कोई लेख कार्य नहीं है। बेहतर विकल्प ये हो सकते हैं:
दूसरा संस्करण अधिक संकीर्ण है क्योंकि यह ऑडियंस, एक क्रिया और एक निर्णय को निर्दिष्ट करता है। यह आपको कार्यक्षेत्र (scope) के लिए एक परीक्षण भी प्रदान करता है: जो जानकारी पाठक को वह निर्णय लेने में मदद नहीं करती, वह संभवतः कहीं और होनी चाहिए।
प्रति लेख एक मुख्य उद्देश्य रखें। किसी टूल को चुनने का तरीका पूछने वाला प्रश्न, उस टूल का उपयोग करने का तरीका पूछने वाला प्रश्न, और यह पूछने वाला प्रश्न कि क्या वह टूल उपयुक्त है, आपस में संबंधित हो सकते हैं, लेकिन उनके लिए अलग-अलग पूर्वापेक्षाएँ और परिणाम आवश्यक हो सकते हैं। उन्हें बहुत जल्दी एक साथ जोड़ने से एक ऐसा पेज बनता है जिसका शीर्षक तो व्यापक होता है लेकिन वह प्रत्येक कार्य के लिए अधूरा रह जाता है।
साक्ष्य लेज़र में साक्ष्य एकत्र करें
कोई प्रश्न केवल एक संकेत (lead) होता है, अपने आप में कोई विषय नहीं। यह तय करने के लिए पर्याप्त संदर्भ रिकॉर्ड करें कि क्या यह किसी सार्वजनिक जानकारी की आवश्यकता का प्रतिनिधित्व करता है। एक साधारण स्प्रेडशीट पर्याप्त है; GOV.UK विशेष रूप से उपयोगकर्ता की ज़रूरतों और स्वीकृति मानदंडों के साथ-साथ सहायक साक्ष्य रिकॉर्ड करने की सिफारिश करता है (GOV.UK: Identify user needs)।
देखे गए प्रत्येक प्रश्न या निकटता से संबंधित प्रश्नों के समूह के लिए एक पंक्ति का उपयोग करें:
एक ही प्रश्न को कई चैनलों पर कॉपी किए जाने के कारण उसकी आवृत्ति (frequency) को बढ़ाकर न आँकें। मूल आवश्यकता को एक बार रिकॉर्ड करें और उन चैनलों पर ध्यान दें जहां यह दिखाई दिया। इसके विपरीत, किसी ज़रूरत को केवल इसलिए खारिज न करें क्योंकि वह केवल कुछ ही बार सामने आई है, यदि प्रत्येक उदाहरण एक ही अनसुलझे कार्य को दर्शाता है और उत्तर व्यापक सार्वजनिक ऑडियंस के काम आ सकता है।
एक उपयोगी लेज़र साक्ष्य और व्याख्या के बीच अंतर करता है। “चार पाठकों ने पूछा कि क्या पहले अभ्यास के लिए विशेष उपकरण की आवश्यकता होती है” एक साक्ष्य है। “पाठक एक कम लागत वाली शुरुआती गाइड चाहते हैं” एक व्याख्या है। दोनों को रखें, लेकिन उन पर अलग-अलग लेबल लगाएं।
सार्वजनिक ज़रूरतों को केवल-सहायता (support-only) प्रश्नों से अलग करें
मुख्य संपादकीय प्रश्न केवल यह नहीं है, “क्या किसी ने यह पूछा था?” बल्कि यह है, “क्या कोई सामान्य पेज पाठकों के एक सार्थक समूह को वही कार्य पूरा करने में मदद कर सकता है?” Digital.gov का सरल-भाषा मार्गदर्शन इस अवलोकन से शुरू होता है कि लोग विभिन्न कार्य करने के लिए वेबसाइटों पर आते हैं और ऑडियंस तथा उन्हें क्या पूरा करने की आवश्यकता है, इसके इर्द-गिर्द सामग्री व्यवस्थित करने की सिफारिश करता है (Digital.gov: Principles of plain language)।
लेज़र में प्रत्येक विकल्प को वर्गीकृत करें:
एक आवर्ती सार्वजनिक आवश्यकता:
जब प्रश्न का कोई स्थिर, सामान्य उत्तर हो और वही कार्य विभिन्न लोगों, चैनलों या स्थितियों में दिखाई दे, तो लेख बनाएं या अपडेट करें। उदाहरणों में स्पष्ट रूप से वर्णित विकल्पों में से चुनना, किसी सामान्य प्रक्रिया की तैयारी करना, या व्यापक रूप से देखी जाने वाली समस्या का निदान करना शामिल है। लेख में अपनी ऑडियंस और सीमाओं का उल्लेख होना चाहिए ताकि पाठक यह पहचान सकें कि यह उन पर लागू होता है या नहीं।
एक केवल-सहायता आवश्यकता:
एक केवल-सहायता प्रश्न निजी खाता डेटा, किसी व्यक्तिगत ऑर्डर, व्यक्तिगत कॉन्फ़िगरेशन, या ऐसी किसी कार्रवाई पर निर्भर करता है जिसे केवल एक ऑपरेटर ही कर सकता है। यह सहायता निर्देश या संपर्क मार्ग को उचित ठहरा सकता है, लेकिन आवश्यक रूप से एक सामान्य संपादकीय लेख को नहीं। “मेरे खाते को यह संदेश क्यों मिला?” को एक सार्वभौमिक व्याख्या में न बदलें, जब उत्तर ऐसी जानकारी पर निर्भर करता हो जो अन्य पाठकों के लिए उपलब्ध नहीं है।
यदि कोई दोहराया जाने वाला सामान्य कार्य है, तो आप अभी भी एक सार्वजनिक सहयोगी पेज प्रकाशित कर सकते हैं, जैसे कि यह समझाना कि संदेश श्रेणी का क्या अर्थ है और सहायता टीम से संपर्क करने से पहले पाठक को क्या जानकारी एकत्र करनी चाहिए। निजी समाधान को लेख से बाहर रखें।
एक डुप्लिकेट आवश्यकता:
एक डुप्लिकेट वह वास्तविक प्रश्न है जिसका उत्तर मौजूदा पेज पहले से ही विस्तार के सही स्तर पर और उसी ऑडियंस के लिए देता है। सही कार्रवाई मौजूदा पेज की शुरुआत, उदाहरणों, नेविगेशन या छूटी हुई शर्त में सुधार करना हो सकती है। एक नया URL बिना कोई अलग कार्य जोड़े ध्यान भटकाएगा।
पूरी साइट की सूची (inventory) के बिना, कोई संपादक ईमानदारी से यह दावा नहीं कर सकता कि कोई डुप्लिकेट मौजूद नहीं है। व्यावहारिक प्रतिक्रिया यह है कि ज्ञात प्रासंगिक पेजों का निरीक्षण करें, यदि आवश्यक हो तो इन्वेंट्री जांच को अधूरा चिह्नित करें, और नए लेख को एकमात्र उत्तर के रूप में प्रस्तुत करने से बचें।
शीर्षक सौंपने से पहले एक निर्णय गेट (decision gate) का उपयोग करें
विकल्प को पाँच गेट्स से गुज़ारें। “नहीं” का अर्थ हमेशा विचार को समाप्त करना नहीं होता; यह आपको बताता है कि किस प्रकार के कार्य की आवश्यकता है।
परिणाम का उपयोग संपादकीय गेट के रूप में करें:
यह गेट स्रोतों के दो सिद्धांतों से निर्मित एक संपादकीय निष्कर्ष है: सामग्री को एक परिभाषित ऑडियंस और कार्य की पूर्ति करनी चाहिए, और प्रकाशक को आवश्यकता के लिए साक्ष्य बनाए रखना चाहिए। यह निर्णय लेने में एक सहायता है, कोई सर्च-इंजन फॉर्मूला नहीं।
चयनित आवश्यकता को एक उपयोगी लेख सारांश (article brief) में बदलें
एक बार जब कोई विषय गेट पार कर ले, तो परिष्कृत शब्दों को चुनने से पहले सारांश लिखें। इसमें शामिल करें:
उदाहरण विषय के लिए, एक स्वीकृति चेकलिस्ट यह हो सकती है: पाठक एक सामान्य प्रश्न को उपयोगकर्ता कथन में बदल सकता है; केंद्रीय कार्य की पहचान कर सकता है; साक्ष्य को सार्वजनिक, केवल-सहायता, या डुप्लिकेट के रूप में वर्गीकृत कर सकता है; और बनाना, अपडेट करना, रोकना, या अस्वीकार करना चुन सकता है। यह GOV.UK के स्वीकृति मानदंडों के तर्क का अनुसरण करता है, जो वर्णन करते हैं कि उपयोगकर्ता की आवश्यकता पूरी होने के लिए क्या सत्य होना चाहिए (GOV.UK: Identify user needs)।
शीर्षक को नियंत्रित करने के लिए सारांश का उपयोग करें। “उपयोगकर्ताओं की वास्तविक ज़रूरतों से लेख का विषय कैसे चुनें” उन संपादकों के लिए उपयुक्त है जिन्हें एक पुनरावृत्ति योग्य चयन पद्धति की आवश्यकता है। “सर्वश्रेष्ठ कंटेंट विषय कैसे खोजें” अधिक व्यापक होगा और एक असमर्थित रैंकिंग या गुणवत्ता निर्णय को दर्शाएगा। Google का अपना मार्गदर्शन पूछता है कि क्या किसी साइट की कोई लक्षित ऑडियंस है, क्या कंटेंट पाठकों को उनके लक्ष्य को प्राप्त करने में मदद करती है, और क्या कंटेंट मुख्य रूप से खोज विज़िट आकर्षित करने के बजाय लोगों के लिए बनाई गई है (Google Search Central: Creating helpful, reliable, people-first content)। ये प्रश्न एक सटीक संपादकीय कार्य के मूल्य को सुदृढ़ करते हैं, लेकिन वे ट्रैफ़िक या रैंकिंग का आश्वासन नहीं देते हैं।
लेख को उत्तर देने योग्य, पठनीय और रखरखाव योग्य बनाएं
एक वास्तविक ज़रूरत से भी कमज़ोर पेज बन सकता है यदि ड्राफ्ट पाठक को उत्तर खुद समझने पर मजबूर करता है। सीधा उत्तर शुरुआत के पास रखें, फिर उन शर्तों की व्याख्या करें जो इसे बदलती हैं। जहाँ स्पष्ट हो वहाँ लेज़र से पाठक की शब्दावली का उपयोग करें, लेकिन आंतरिक संपादकीय शब्दों जैसे कि “केवल-सहायता” और “डुप्लिकेट” को परिभाषित करें।
लेख को ढीले-ढाले संबंधित कीवर्ड की सूची के बजाय निर्णयों और कार्यों के इर्द-गिर्द व्यवस्थित करें। Digital.gov ऑडियंस के लिए लिखने, जानकारी व्यवस्थित करने, संक्षिप्त और सरल भाषा का उपयोग करने और अनावश्यक शब्दाडंबर से बचने की सिफारिश करता है (Digital.gov: Principles of plain language)। एक संपादकीय पद्धति के लिए, इसका अर्थ है लेज़र फ़ील्ड, निर्णय गेट और कम से कम एक कार्यशील उदाहरण दिखाना—न कि केवल संपादकों को “अपनी ऑडियंस को समझने” की सलाह देना।
स्वीकृति से पहले, प्रत्येक परिणामी कथन की जाँच करें:
यदि अंतिम प्रश्न का उत्तर 'नहीं' है क्योंकि इन्वेंट्री अधूरी है, तो उस सीमा को रिकॉर्ड करें। बिना किसी आधार के यह दावा करने की तुलना में कि विषय नया है, एक ईमानदार “साइट-इन्वेंट्री समीक्षा की आवश्यकता है” अधिक उपयोगी है।
सामान्य प्रश्न
किसी विषय के मान्य होने से पहले कितने प्रश्नों की आवश्यकता होती है?
इसकी कोई सार्वभौमिक संख्या नहीं है। पुनरावृत्ति एक उपयोगी साक्ष्य है, लेकिन किसी मनमाने मानदंड की तुलना में कार्य की समानता और सार्वजनिक प्रयोज्यता अधिक मायने रखती है। एक अच्छी तरह से प्रलेखित आवर्ती कार्य कई असंबंधित प्रश्नों की तुलना में अधिक मजबूत हो सकता है।
क्या प्रत्येक सहायता प्रश्न को एक FAQ बनना चाहिए?
नहीं। यदि उत्तर निजी खाते या लेन-देन के विवरण पर निर्भर करता है, तो समाधान को सहायता टीम के पास भेजें। एक सामान्य लेख केवल तभी प्रकाशित करें जब वह व्यक्तिगत जानकारी को उजागर किए या उसका अनुमान लगाए बिना एक दोहराए जाने वाले सार्वजनिक कार्य की व्याख्या करता हो।
क्या होगा यदि कीवर्ड व्यापक है लेकिन आवश्यकता संकीर्ण है?
लेख को संकीर्ण रखें। एक व्यापक लेबल एक आंतरिक खोज शब्द के रूप में उपयोगी हो सकता है, लेकिन शीर्षक, शुरुआत और स्वीकृति मानदंडों को विशिष्ट पाठक कार्य का वर्णन करना चाहिए।
संपादक को किसी विषय को कब अस्वीकार करना चाहिए?
इसे तब अस्वीकार करें या रोकें जब साक्ष्य से पता चले कि कोई आवर्ती सार्वजनिक कार्य नहीं है, उत्तर सत्यापित नहीं किया जा सकता है, एक प्रासंगिक पेज पहले से ही उस उद्देश्य को पूरा करता है, या प्रस्तावित लेख के लिए ऐसी स्थितियाँ गढ़ने की आवश्यकता होगी जिन्हें संपादक स्थापित नहीं कर सकता है। किसी विषय को अस्वीकार करना एक वैध संपादकीय निर्णय है जब यह किसी गलत या अनावश्यक पेज को रोकता है।