कोई लेख पाठक की समस्या का समाधान करता है या नहीं, इसका परीक्षण कैसे करें

एक पाठक, एक उद्देश्य और एक प्रत्यक्ष कार्य से शुरुआत करें

गद्य की समीक्षा करने से पहले ऑडिट का शुरुआती विवरण लिखें:

पाठक: [व्यक्ति का विशिष्ट प्रकार]। उद्देश्य: [वे क्या समझना या तय करना चाहते हैं]। कार्य: पढ़ने के बाद, वे किसी अनकहे चरण या स्रोत की आवश्यकता के बिना [प्रत्यक्ष कार्रवाई] कर सकते हैं।

उदाहरण के लिए:

पाठक: एक व्यावहारिक वेब लेख की समीक्षा करने वाला संपादक। उद्देश्य: यह निर्धारित करना कि क्या ड्राफ्ट अपने लक्षित पाठक की मदद करता है। कार्य: कम्प्लीशन-पाथ (पूर्णता-मार्ग) ऑडिट लागू करना और कारणों के साथ प्रकाशित करने, संशोधित करने या अस्वीकार करने का निर्णय दर्ज करना।

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

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

GOV.UK सामग्री और प्रकाशन मार्गदर्शन उपयोगकर्ता की आवश्यकताओं की पहचान करने और उनके इर्द-गिर्द सामग्री की योजना बनाने की सिफारिश करता है। इसी तरह Google के अपने स्व-मूल्यांकन प्रश्न पूछते हैं कि क्या लक्षित दर्शकों को सामग्री उपयोगी लगेगी, क्या पाठक अपने लक्ष्य को प्राप्त करने के लिए पर्याप्त सीखेंगे, और क्या वे एक संतोषजनक अनुभव के साथ जाएंगे (Google Search Central)। ये उपयोगी संकेत हैं, लेकिन संपादक को अभी भी उन्हें एक ठोस पूर्णता परीक्षण में बदलने की आवश्यकता है।

लेखन का मूल्यांकन करने से पहले पूर्णता-मार्ग (कम्प्लीशन पाथ) का खाका बनाएं

कार्य पूरा करने के लिए पाठक को क्रमबद्ध रूप से जो कदम उठाने चाहिए, उन्हें सूचीबद्ध करें। इसमें निर्णय, गणना, इनपुट्स, जांच और हैंडऑफ़ शामिल करें—न कि केवल लेख के शीर्षक।

एक व्यावहारिक खाका इस तरह दिख सकता है:

फिर प्रत्येक चरण को कवर्ड (शामिल), आंशिक रूप से कवर्ड, या मिसिंग (छूटा हुआ) के रूप में चिह्नित करें। "कवर्ड" का अर्थ है कि पाठक लेख के आधार पर कार्रवाई कर सकता है, केवल यह नहीं कि विषय का उल्लेख किया गया है।

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

एक उपयोगी ऑडिट तालिका है:

यह तालिका बताती है कि क्या ड्राफ्ट एक उपकरण के रूप में पूर्ण है। यह किसी संपादक को छूटी हुई पूर्वापेक्षित शर्त को नज़रअंदाज़ करते हुए केवल एक बेहतरीन प्रस्तावना की सराहना करने से भी रोकता है।

छूटे हुए इनपुट्स, मान्यताओं और रुकने की स्थितियों की जाँच करें

कई व्यावहारिक लेख पहले निर्देश से पहले ही विफल हो जाते हैं क्योंकि वे ऐसे ज्ञान, एक्सेस या स्थितियों को मान लेते हैं जो पाठक के पास नहीं हैं। चार प्रश्न पूछकर प्रत्येक चरण का ऑडिट करें:

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

आवश्यक इनपुट्स को वैकल्पिक सुधारों से अलग करें। एक पाठक यह बताने में सक्षम होना चाहिए कि कोई वस्तु आगे बढ़ने के लिए आवश्यक है या केवल मददगार। पूर्वापेक्षाओं को प्रक्रिया से पहले रखें, जहां वे व्यर्थ के प्रयास को रोक सकती हैं।

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

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

साक्ष्य कवरेज का परीक्षण करें, न कि उद्धरणों की सजावट का

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

चार कॉलम वाली एक क्लेम लेज़र बनाएं: दावा, प्रभावित पाठक का निर्णय, प्रयुक्त साक्ष्य, और शब्दों की दृढ़ता। अंतिम कॉलम महत्वपूर्ण है। साक्ष्य "कर सकता है," "आमतौर पर," या "आवश्यक है" का समर्थन कर सकता है, लेकिन स्वतः "हमेशा," "सर्वश्रेष्ठ," या "निश्चित" का नहीं। स्रोत से शर्तों और सीमाओं को बनाए रखें।

मूल या प्राथमिक स्रोतों को प्राथमिकता दें जब वे स्वयं उस विषय का दस्तावेजीकरण करते हैं। उदाहरण के लिए, WCAG 2.2 रीडिंग लेवल का W3C स्पष्टीकरण बताता है कि जब निर्दिष्ट पठन मांग पार हो जाती है, तो जटिल पाठ का अधिक आसानी से समझा जाने वाला संस्करण या पूरक सामग्री होनी चाहिए। एक संपादक जटिलता की जांच को उचित ठहराने के लिए उस स्रोत का उपयोग कर सकता है, जबकि इस असमर्थित निष्कर्ष से बच सकता है कि एक ही पठनीयता स्कोर हर लेख को सुलभ बनाता है।

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

कार्य पूर्णता के हिस्से के रूप में उपयोगिता और पठनीयता की समीक्षा करें

एक पठनीय लेख केवल सुखद ही नहीं होता; यह किसी निर्देश को खोजने, समझने और लागू करने के लिए आवश्यक प्रयास को कम करता है। उपयोग के बिंदु पर ड्राफ्ट की समीक्षा करें:

W3C मार्गदर्शन बताता है कि छोटे, सामान्य शब्दों और छोटे वाक्यों को समझना आम तौर पर आसान होता है, साथ ही यह भी ध्यान दिया गया है कि जटिल विषय वस्तु किसी विशेषज्ञ दर्शक वर्ग के लिए उपयुक्त हो सकती है। इसका मतलब यह है कि संपादन में आवश्यक सटीकता को हटाए बिना परिहार्य कठिनाई को कम किया जाना चाहिए। ऐसी किसी शर्त को सरलीकृत करके न हटाएं जो परिणाम को बदलती हो।

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

लेख को एक बार सरसरी तौर पर पढ़ने वाले (स्किमर) के रूप में और एक बार उस पर अमल करने वाले (डूअर) के रूप में पढ़ें। स्किमर को वादा किए गए परिणाम, पूर्वापेक्षाओं और उत्तर तक पहुंचने के मार्ग की पहचान करने में सक्षम होना चाहिए। डूअर को लेखक के इच्छित क्रम का पुनर्निर्माण किए बिना चरणों का पालन करने में सक्षम होना चाहिए।

प्रकाशन से पहले पाठक परीक्षण चलाएं

प्रकाशन से पहले की सबसे मजबूत जांच एक ऐसे व्यक्ति के साथ एक छोटा कार्य परीक्षण है जो लक्षित पाठक जैसा दिखता है लेकिन उसने ड्राफ्ट नहीं लिखा है। उन्हें कार्य विवरण और लेख दें। उनसे स्वतंत्र रूप से काम करने के लिए कहें, और केवल यह बताने के लिए कहें कि वे कहाँ देख रहे हैं या उन्हें क्या चाहिए—यह नहीं कि उन्हें लेख पसंद है या नहीं।

निरीक्षण करें कि क्या वे:

सटीक घर्षण बिंदुओं (फ़्रिक्शन पॉइंट्स) को रिकॉर्ड करें: एक छूटा हुआ फ़ील्ड, अस्पष्ट लेबल, छोड़ी गई शर्त, अस्पष्टीकृत परिणाम या बाहरी निर्भरता। किसी पाठक के सफल अनुमान को इस बात का प्रमाण न मानें कि लेख स्पष्ट है। पूछें, "लेख में ऐसी कौन सी बात थी जिसने आपको ऐसा करने के लिए कहा?" यदि उत्तर है "मुझे पहले से ही पता था," तो ड्राफ्ट में अभी भी कोई कमी हो सकती है।

परीक्षण के बाद, प्रत्येक समस्या को अवरोधक (ब्लॉकिंग), धीमा करने वाली या कॉस्मेटिक के रूप में वर्गीकृत करें। पहले ब्लॉकिंग समस्याओं को ठीक करें: छूटी हुई पूर्वापेक्षाएँ, असुरक्षित अस्पष्टता, गलत क्रम और अनुपस्थित अपवाद मार्ग। फिर परिवर्तित मार्ग का पुनः परीक्षण करें। एक पाठक परीक्षण सार्वभौमिक उपयोगिता स्थापित नहीं करता है, लेकिन यह उजागर कर सकता है कि क्या बताया गया कार्य लेखक के अलावा किसी अन्य व्यक्ति द्वारा प्राप्त करने योग्य है।

बाद में एनालिटिक्स का उपयोग करें और उनकी सावधानीपूर्वक व्याख्या करें

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

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

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

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