ह्यूरिस्टिक इवैल्यूएशन: Difference between revisions
(Created page with "{{Use dmy dates|date=September 2017}} {{about|usability evaluation|a list of Heuristic analysis topics ranging from application of heuristics to antivirus software|Heuristic a...") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Use dmy dates|date=September 2017}} | {{Use dmy dates|date=September 2017}} | ||
{{about| | {{about|प्रयोज्यता मूल्यांकन|अनुमानी विश्लेषण विषयों की एक सूची जिसमें अनुमान के अनुप्रयोग से लेकर एंटीवायरस सॉफ़्टवेयर तक शामिल हैं|अनुमानी विश्लेषण}} | ||
अनुमानी मूल्यांकन कंप्यूटर सॉफ़्टवेयर के लिए | '''अनुमानी मूल्यांकन''' कंप्यूटर सॉफ़्टवेयर के लिए [[प्रयोज्य]] निरीक्षण विधि है जो उपयोगकर्ता इंटरफ़ेस डिज़ाइन में प्रयोज्य समस्याओं की पहचान करने में मदद करता है। इसमें विशेष रूप से मूल्यांकनकर्ता शामिल हैं जो इंटरफ़ेस की जांच करते हैं और मान्यता प्राप्त प्रयोज्य सिद्धांतों ("ह्यूरिस्टिक्स") के साथ इसके अनुपालन का मूल्यांकन करते हैं। इन मूल्यांकन विधियों को अब नए मीडिया क्षेत्र में व्यापक रूप से सिखाया और अभ्यास किया जाता है, जहां उपयोगकर्ता इंटरफ़ेस अक्सर बजट पर कम समय में डिज़ाइन किए जाते हैं जो अन्य प्रकार के इंटरफ़ेस परीक्षण के लिए उपलब्ध धनराशि को सीमित कर सकते हैं। | ||
==परिचय== | ==परिचय== | ||
अनुमानी मूल्यांकन का मुख्य लक्ष्य उपयोगकर्ता इंटरफ़ेस के डिज़ाइन से जुड़ी किसी भी समस्या की पहचान करना है। उपयोगिता सलाहकार रॉल्फ मोलिच और जैकब नीलसन ने उपयोगिता इंजीनियरिंग के बारे में शिक्षण और परामर्श में कई वर्षों के अनुभव के आधार पर इस पद्धति को विकसित किया। अनुमानी मूल्यांकन मानव-कंप्यूटर इंटरैक्शन के क्षेत्र में प्रयोज्य निरीक्षण के सबसे अनौपचारिक तरीकों<ref name="multiple">Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1–5 April), 249–256</ref> में से एक है। प्रयोज्य डिजाइन अनुमानों के कई सेट हैं; वे परस्पर अनन्य नहीं हैं और यूजर इंटरफेस डिजाइन के कई समान पहलुओं को कवर करते हैं। अक्सर, खोजी गई प्रयोज्य समस्याओं को उपयोगकर्ता के प्रदर्शन या स्वीकृति पर उनके अनुमानित प्रभाव के अनुसार अक्सर संख्यात्मक पैमाने पर वर्गीकृत किया जाता है। अक्सर अनुमानी मूल्यांकन उपयोग के मामलों (सामान्य उपयोगकर्ता कार्यों) के संदर्भ में किया जाता है, ताकि डेवलपर्स को इस बात पर फीडबैक दिया जा सके कि इंटरफ़ेस किस हद तक इच्छित उपयोगकर्ताओं की आवश्यकताओं और प्राथमिकताओं के साथ संगत हो सकता है। | |||
अनुमानी मूल्यांकन की सरलता | अनुमानी मूल्यांकन की सरलता डिज़ाइन के शुरुआती चरणों में और उपयोगकर्ता-आधारित परीक्षण से पहले फायदेमंद होती है। यह प्रयोज्यता निरीक्षण पद्धति उपयोगकर्ताओं पर निर्भर नहीं करती है जो भर्ती, शेड्यूलिंग मुद्दों, मूल्यांकन करने के लिए जगह और प्रतिभागी समय के भुगतान की आवश्यकता के कारण बोझिल हो सकती है। प्रकाशित मूल रिपोर्ट में, नीलसन ने कहा कि चार प्रयोगों से पता चला है कि व्यक्तिगत मूल्यांकनकर्ता अनुमानी मूल्यांकन करने में "ज्यादातर काफी खराब" थे और सुझाव दिया कि एक स्वीकार्य समीक्षा तैयार करने और उसे पूरा करने के लिए, एकत्रित परिणामों के साथ कई मूल्यांकनकर्ताओं की आवश्यकता थी। अधिकांश अनुमानी मूल्यांकन कुछ ही दिनों में पूरे किए जा सकते हैं। आवश्यक समय कलाकृति के आकार, उसकी जटिलता, समीक्षा के उद्देश्य, समीक्षा में उत्पन्न होने वाले प्रयोज्य मुद्दों की प्रकृति और समीक्षकों की क्षमता के आधार पर भिन्न होता है। उपयोगकर्ता परीक्षण से पहले अनुमानी मूल्यांकन का उपयोग अक्सर मूल्यांकन में शामिल किए जाने वाले क्षेत्रों की पहचान करने के लिए या उपयोगकर्ता-आधारित मूल्यांकन से पहले कथित डिज़ाइन मुद्दों को खत्म करने के लिए किया जाता है। | ||
यद्यपि अनुमानी मूल्यांकन कम समय में कई प्रमुख प्रयोज्य मुद्दों को | यद्यपि अनुमानी मूल्यांकन कम समय में कई प्रमुख प्रयोज्य मुद्दों को साक्ष्य कर सकता है, एक आलोचना जो अक्सर की जाती है वह यह है कि परिणाम विशेषज्ञ समीक्षक (समीक्षकों) के ज्ञान से अत्यधिक प्रभावित होते हैं। इस "एकतरफा" समीक्षा में बार-बार सॉफ्टवेयर प्रदर्शन परीक्षण की तुलना में अलग-अलग परिणाम मिलते हैं, प्रत्येक प्रकार का परीक्षण समस्याओं के एक अलग सेट को साक्ष्य करता है। | ||
== कार्यप्रणाली == | == कार्यप्रणाली == | ||
Revision as of 17:38, 6 August 2023
अनुमानी मूल्यांकन कंप्यूटर सॉफ़्टवेयर के लिए प्रयोज्य निरीक्षण विधि है जो उपयोगकर्ता इंटरफ़ेस डिज़ाइन में प्रयोज्य समस्याओं की पहचान करने में मदद करता है। इसमें विशेष रूप से मूल्यांकनकर्ता शामिल हैं जो इंटरफ़ेस की जांच करते हैं और मान्यता प्राप्त प्रयोज्य सिद्धांतों ("ह्यूरिस्टिक्स") के साथ इसके अनुपालन का मूल्यांकन करते हैं। इन मूल्यांकन विधियों को अब नए मीडिया क्षेत्र में व्यापक रूप से सिखाया और अभ्यास किया जाता है, जहां उपयोगकर्ता इंटरफ़ेस अक्सर बजट पर कम समय में डिज़ाइन किए जाते हैं जो अन्य प्रकार के इंटरफ़ेस परीक्षण के लिए उपलब्ध धनराशि को सीमित कर सकते हैं।
परिचय
अनुमानी मूल्यांकन का मुख्य लक्ष्य उपयोगकर्ता इंटरफ़ेस के डिज़ाइन से जुड़ी किसी भी समस्या की पहचान करना है। उपयोगिता सलाहकार रॉल्फ मोलिच और जैकब नीलसन ने उपयोगिता इंजीनियरिंग के बारे में शिक्षण और परामर्श में कई वर्षों के अनुभव के आधार पर इस पद्धति को विकसित किया। अनुमानी मूल्यांकन मानव-कंप्यूटर इंटरैक्शन के क्षेत्र में प्रयोज्य निरीक्षण के सबसे अनौपचारिक तरीकों[1] में से एक है। प्रयोज्य डिजाइन अनुमानों के कई सेट हैं; वे परस्पर अनन्य नहीं हैं और यूजर इंटरफेस डिजाइन के कई समान पहलुओं को कवर करते हैं। अक्सर, खोजी गई प्रयोज्य समस्याओं को उपयोगकर्ता के प्रदर्शन या स्वीकृति पर उनके अनुमानित प्रभाव के अनुसार अक्सर संख्यात्मक पैमाने पर वर्गीकृत किया जाता है। अक्सर अनुमानी मूल्यांकन उपयोग के मामलों (सामान्य उपयोगकर्ता कार्यों) के संदर्भ में किया जाता है, ताकि डेवलपर्स को इस बात पर फीडबैक दिया जा सके कि इंटरफ़ेस किस हद तक इच्छित उपयोगकर्ताओं की आवश्यकताओं और प्राथमिकताओं के साथ संगत हो सकता है।
अनुमानी मूल्यांकन की सरलता डिज़ाइन के शुरुआती चरणों में और उपयोगकर्ता-आधारित परीक्षण से पहले फायदेमंद होती है। यह प्रयोज्यता निरीक्षण पद्धति उपयोगकर्ताओं पर निर्भर नहीं करती है जो भर्ती, शेड्यूलिंग मुद्दों, मूल्यांकन करने के लिए जगह और प्रतिभागी समय के भुगतान की आवश्यकता के कारण बोझिल हो सकती है। प्रकाशित मूल रिपोर्ट में, नीलसन ने कहा कि चार प्रयोगों से पता चला है कि व्यक्तिगत मूल्यांकनकर्ता अनुमानी मूल्यांकन करने में "ज्यादातर काफी खराब" थे और सुझाव दिया कि एक स्वीकार्य समीक्षा तैयार करने और उसे पूरा करने के लिए, एकत्रित परिणामों के साथ कई मूल्यांकनकर्ताओं की आवश्यकता थी। अधिकांश अनुमानी मूल्यांकन कुछ ही दिनों में पूरे किए जा सकते हैं। आवश्यक समय कलाकृति के आकार, उसकी जटिलता, समीक्षा के उद्देश्य, समीक्षा में उत्पन्न होने वाले प्रयोज्य मुद्दों की प्रकृति और समीक्षकों की क्षमता के आधार पर भिन्न होता है। उपयोगकर्ता परीक्षण से पहले अनुमानी मूल्यांकन का उपयोग अक्सर मूल्यांकन में शामिल किए जाने वाले क्षेत्रों की पहचान करने के लिए या उपयोगकर्ता-आधारित मूल्यांकन से पहले कथित डिज़ाइन मुद्दों को खत्म करने के लिए किया जाता है।
यद्यपि अनुमानी मूल्यांकन कम समय में कई प्रमुख प्रयोज्य मुद्दों को साक्ष्य कर सकता है, एक आलोचना जो अक्सर की जाती है वह यह है कि परिणाम विशेषज्ञ समीक्षक (समीक्षकों) के ज्ञान से अत्यधिक प्रभावित होते हैं। इस "एकतरफा" समीक्षा में बार-बार सॉफ्टवेयर प्रदर्शन परीक्षण की तुलना में अलग-अलग परिणाम मिलते हैं, प्रत्येक प्रकार का परीक्षण समस्याओं के एक अलग सेट को साक्ष्य करता है।
कार्यप्रणाली
अनुमानी मूल्यांकन परियोजना के दायरे और प्रकार के आधार पर विभिन्न तरीकों से आयोजित किया जाता है। एक सामान्य नियम के रूप में, पूर्वाग्रह को कम करने और मूल्यांकन के भीतर निष्कर्षों को अधिकतम करने के लिए शोध ढांचे शामिल हैं। अनुमानी मूल्यांकन के विभिन्न पक्ष और विपक्ष हैं। इसका बहुत कुछ संसाधनों की मात्रा और उपयोगकर्ता के पास इसके लिए समय पर निर्भर करता है।
पेशेवर: क्योंकि मूल्यांकनकर्ता जिन मानदंडों से गुजरता है उनकी एक बहुत विस्तृत सूची है, यह एक बहुत विस्तृत प्रक्रिया है और उन क्षेत्रों पर अच्छी प्रतिक्रिया प्रदान करती है जिनमें सुधार किया जा सकता है। इसके अलावा, चूंकि यह कई लोगों द्वारा किया जाता है, इसलिए डिज़ाइनर कई दृष्टिकोणों से प्रतिक्रिया प्राप्त कर सकता है। चूंकि यह अपेक्षाकृत सरल प्रक्रिया है, इसलिए मूल्यांकन को व्यवस्थित करने और इसे क्रियान्वित करने से संबंधित नैतिक और तार्किक चिंताएं कम हैं।
विपक्ष: चूंकि मानदंडों का एक विशिष्ट सेट है, मूल्यांकन केवल उतना ही अच्छा होगा जितना इसका मूल्यांकन करने वाले लोग। इससे इस मूल्यांकन को संचालित करने के लिए पर्याप्त रूप से योग्य विशेषज्ञों और लोगों को खोजने का एक और मुद्दा सामने आता है। हालाँकि, यदि आपके पास विशेषज्ञों और योग्य मूल्यांकनकर्ताओं के करीबी संसाधन हैं, तो यह कोई समस्या नहीं होगी। इसके अलावा, क्योंकि मूल्यांकन केवल व्यक्तिगत अवलोकन हैं, परिणामों में कोई ठोस डेटा नहीं है - डिजाइनर को बस इन विचारों को ध्यान में रखते हुए सभी जानकारी और मूल्यांकन लेना होगा।
मूल्यांकनकर्ताओं की संख्या
नीलसन के अनुसार, तीन से पांच मूल्यांकनकर्ताओं की सिफारिश की जाती है[2] एक अध्ययन के भीतर. पांच से अधिक मूल्यांकनकर्ताओं के होने से जरूरी नहीं कि अंतर्दृष्टि की मात्रा में वृद्धि हो, और इससे समग्र मूल्यांकन में लाभ की तुलना में अधिक लागत जुड़ सकती है।
व्यक्तिगत और समूह प्रक्रिया
समूह पुष्टिकरण पूर्वाग्रह को कम करने के लिए परिणामों को एकत्रित करने से पहले अनुमानी मूल्यांकन व्यक्तिगत रूप से शुरू होना चाहिए।[2]अंतर्दृष्टि संचय करने के लिए समूह चर्चा में प्रवेश करने से पहले मूल्यांकनकर्ता को स्वतंत्र रूप से प्रोटोटाइप की जांच करनी चाहिए।
प्रेक्षक ट्रेड-ऑफ़
मूल्यांकन सत्र में एक पर्यवेक्षक को जोड़ते समय लागत और लाभ जुड़े होते हैं।[2] पर्यवेक्षक के बिना एक सत्र में, मूल्यांकनकर्ताओं को उत्पाद/प्रोटोटाइप के साथ बातचीत करते समय एक लिखित रिपोर्ट के भीतर अपनी व्यक्तिगत टिप्पणियों को औपचारिक बनाने की आवश्यकता होगी। इस विकल्प के लिए मूल्यांकनकर्ताओं को अधिक समय और प्रयास की आवश्यकता होगी, और इससे अध्ययन के संचालकों को व्यक्तिगत रिपोर्ट की व्याख्या करने के लिए अतिरिक्त समय की भी आवश्यकता होगी। हालाँकि, यह विकल्प कम महंगा है क्योंकि यह पर्यवेक्षकों को काम पर रखने से जुड़ी ओवरहेड लागत को कम करता है।
एक पर्यवेक्षक के साथ, मूल्यांकनकर्ता मौखिक रूप से अपना विश्लेषण प्रदान कर सकते हैं जबकि पर्यवेक्षक मूल्यांकनकर्ताओं के निष्कर्षों को प्रतिलेखित और व्याख्या कर सकते हैं। यह विकल्प मूल्यांकनकर्ताओं के कार्यभार की मात्रा और एकाधिक मूल्यांकनकर्ताओं के निष्कर्षों की व्याख्या करने के लिए आवश्यक समय को कम करता है।
नीलसन का अनुमान
जैकब नील्सन (प्रयोज्यता सलाहकार) के अनुमान संभवतः उपयोगकर्ता इंटरफ़ेस डिज़ाइन के लिए सबसे अधिक उपयोग किए जाने वाले प्रयोज्य अनुमान हैं। अनुमान का प्रारंभिक संस्करण 1989-1990 में प्रकाशित नीलसन और रॉल्फ मोलिच के दो पत्रों में छपा।[3][4] नील्सन ने 1994 में एक अद्यतन सेट प्रकाशित किया,[5] और आज भी उपयोग में आने वाला अंतिम सेट 2005 में प्रकाशित हुआ था:[6] # सिस्टम स्थिति की दृश्यता:
सिस्टम को उचित समय के भीतर उचित फीडबैक के माध्यम से उपयोगकर्ताओं को हमेशा सूचित रखना चाहिए कि क्या हो रहा है।
- सिस्टम और वास्तविक दुनिया के बीच मिलान:
सिस्टम को उपयोगकर्ता की भाषा बोलनी चाहिए, जिसमें सिस्टम-उन्मुख शब्दों के बजाय उपयोगकर्ता से परिचित शब्द, वाक्यांश और अवधारणाएं शामिल होनी चाहिए। वास्तविक दुनिया की परंपराओं का पालन करें, जिससे जानकारी प्राकृतिक और तार्किक क्रम में प्रदर्शित हो। - उपयोगकर्ता नियंत्रण और स्वतंत्रता:
उपयोगकर्ता अक्सर गलती से सिस्टम फ़ंक्शन चुनते हैं और उन्हें विस्तारित संवाद से गुजरने के बिना अवांछित स्थिति को छोड़ने के लिए स्पष्ट रूप से चिह्नित आपातकालीन निकास की आवश्यकता होगी। पूर्ववत करें और पुनः करें का समर्थन करें. - संगति और मानक:
उपयोगकर्ताओं को आश्चर्य नहीं होना चाहिए कि क्या अलग-अलग शब्दों, स्थितियों या कार्यों का मतलब एक ही है। मंच परंपराओं का पालन करें. - त्रुटि निवारण:
अच्छे त्रुटि संदेशों से भी बेहतर एक सावधानीपूर्वक डिज़ाइन है जो किसी समस्या को पहली बार में उत्पन्न होने से रोकता है। या तो त्रुटि-प्रवण स्थितियों को समाप्त करें या उनकी जांच करें और उपयोगकर्ताओं को कार्रवाई करने से पहले एक पुष्टिकरण विकल्प प्रदान करें। - रिकॉल के बजाय पहचान:
ऑब्जेक्ट्स, क्रियाओं और विकल्पों को दृश्यमान बनाकर उपयोगकर्ता की मेमोरी लोड को कम करें। उपयोगकर्ता को संवाद के एक भाग से दूसरे भाग की जानकारी याद रखने की आवश्यकता नहीं होनी चाहिए। सिस्टम के उपयोग के निर्देश जब भी उपयुक्त हों, दृश्यमान या आसानी से पुनर्प्राप्त किए जाने योग्य होने चाहिए। - उपयोग की लचीलापन और दक्षता:
त्वरक - नौसिखिया उपयोगकर्ता द्वारा अनदेखा - अक्सर विशेषज्ञ उपयोगकर्ता के लिए बातचीत को तेज कर सकता है ताकि सिस्टम अनुभवहीन और अनुभवी दोनों उपयोगकर्ताओं को पूरा कर सके। उपयोगकर्ताओं को बार-बार होने वाली कार्रवाइयों को अनुकूलित करने की अनुमति दें। - सौंदर्यपरक और प्रगतिशील प्रकटीकरण:
संवादों में ऐसी जानकारी नहीं होनी चाहिए जो अप्रासंगिक हो या जिसकी शायद ही कभी आवश्यकता हो। किसी संवाद में सूचना की प्रत्येक अतिरिक्त इकाई सूचना की प्रासंगिक इकाइयों के साथ प्रतिस्पर्धा करती है और उनकी सापेक्ष दृश्यता कम कर देती है। - उपयोगकर्ताओं को त्रुटियों को पहचानने, निदान करने और उनसे उबरने में सहायता करें:
त्रुटि संदेशों को सरल भाषा (कोई कोड नहीं) में व्यक्त किया जाना चाहिए, समस्या को सटीक रूप से इंगित करना चाहिए, और रचनात्मक रूप से समाधान सुझाना चाहिए। - सहायता और दस्तावेज़ीकरण:
भले ही यह बेहतर है कि सिस्टम का उपयोग दस्तावेज़ीकरण के बिना किया जा सकता है, सहायता और दस्तावेज़ीकरण प्रदान करना आवश्यक हो सकता है। ऐसी किसी भी जानकारी को खोजना आसान होना चाहिए, उपयोगकर्ता के कार्य पर ध्यान केंद्रित होना चाहिए, उठाए जाने वाले ठोस कदमों की सूची होनी चाहिए और बहुत बड़ी नहीं होनी चाहिए।
गेरहार्ट-पॉवल्स के संज्ञानात्मक इंजीनियरिंग सिद्धांत
यद्यपि नीलसन को अनुमानी मूल्यांकन में विशेषज्ञ और क्षेत्र का नेता माना जाता है, जिल गेरहार्ड-पॉवल्स ने मानव-कंप्यूटर प्रदर्शन को बढ़ाने के लिए संज्ञानात्मक इंजीनियरिंग सिद्धांतों का एक सेट विकसित किया है।[7] ये अनुमान, या सिद्धांत, नील्सन के अनुमान के समान हैं लेकिन मूल्यांकन के लिए अधिक समग्र दृष्टिकोण अपनाते हैं। गेरहार्ड पॉवल्स के सिद्धांत[8] नीचे सूचीबद्ध हैं.
- अवांछित कार्यभार को स्वचालित करें:
उच्च-स्तरीय कार्यों के लिए संज्ञानात्मक संसाधनों को मुक्त करने के लिए मानसिक गणना, अनुमान, तुलना और किसी भी अनावश्यक सोच को हटा दें। - अनिश्चितता कम करें:
निर्णय समय और त्रुटि को कम करने के लिए डेटा को ऐसे तरीके से प्रदर्शित करें जो स्पष्ट और स्पष्ट हो। - फ़्यूज़ डेटा:
संज्ञानात्मक भार को कम करने के लिए निचले स्तर के डेटा को उच्च स्तर के योग में एक साथ लाएँ। - व्याख्या के लिए सार्थक सहायता के साथ नई जानकारी प्रस्तुत करें:
नई जानकारी परिचित ढांचे (जैसे, स्कीमा, रूपक, रोजमर्रा की शर्तें) के भीतर प्रस्तुत की जानी चाहिए ताकि जानकारी को अवशोषित करना आसान हो। - ऐसे नामों का उपयोग करें जो अवधारणात्मक रूप से फ़ंक्शन से संबंधित हों:
प्रदर्शन नाम और लेबल संदर्भ-निर्भर होने चाहिए, जिससे स्मरण और पहचान में सुधार होगा। - डेटा को लगातार सार्थक तरीकों से समूहित करें:
एक स्क्रीन के भीतर, डेटा को तार्किक रूप से समूहीकृत किया जाना चाहिए; सभी स्क्रीनों पर, इसे लगातार समूहीकृत किया जाना चाहिए। इससे जानकारी खोजने का समय कम हो जाएगा. - डेटा-संचालित कार्यों को सीमित करें:
उदाहरण के लिए, कच्चे डेटा को आत्मसात करने में लगने वाले समय को कम करने के लिए रंग और ग्राफिक्स का उपयोग करें। - डिस्प्ले में केवल वही जानकारी शामिल करें जिसकी किसी निश्चित समय में उपयोगकर्ता को आवश्यकता हो:
बाहरी जानकारी को बाहर रखें जो वर्तमान कार्यों के लिए प्रासंगिक नहीं है ताकि उपयोगकर्ता महत्वपूर्ण डेटा पर ध्यान केंद्रित कर सके। - उपयुक्त होने पर डेटा की एकाधिक कोडिंग प्रदान करें:
संज्ञानात्मक लचीलेपन को बढ़ावा देने और उपयोगकर्ता की प्राथमिकताओं को संतुष्ट करने के लिए सिस्टम को अलग-अलग प्रारूपों और/या विवरण के स्तरों में डेटा प्रदान करना चाहिए। - विवेकपूर्ण अतिरेक का अभ्यास करें:
सिद्धांत 10 पहले दो लेखकों द्वारा सिद्धांत 6 और 8 के बीच संभावित संघर्ष को हल करने के लिए तैयार किया गया था, अर्थात, सुसंगत होने के लिए, कभी-कभी एक निश्चित समय में आवश्यकता से अधिक जानकारी शामिल करना आवश्यक होता है।
श्नाइडरमैन के इंटरफ़ेस डिज़ाइन के आठ सुनहरे नियम
नील्सन से कुछ साल पहले बेन श्नाइडरमैन की पुस्तक प्रकाशित हुई थी, डिज़ाइनिंग द यूजर इंटरफ़ेस: स्ट्रैटेजीज़ फॉर इफेक्टिव ह्यूमन-कंप्यूटर इंटरेक्शन (1986) ने आठ गोल्डन रूल्स की उनकी लोकप्रिय सूची को कवर किया था।[9][10]
- स्थिरता के लिए प्रयास करें:
समान स्थितियों में कार्यों के लगातार अनुक्रम की आवश्यकता होनी चाहिए... - बार-बार आने वाले उपयोगकर्ताओं को शॉर्टकट का उपयोग करने में सक्षम करें:
जैसे-जैसे उपयोग की आवृत्ति बढ़ती है, वैसे-वैसे उपयोगकर्ता की इंटरैक्शन की संख्या कम करने की इच्छा भी बढ़ती है... - जानकारीपूर्ण फीडबैक प्रदान करें:
प्रत्येक ऑपरेटर कार्रवाई के लिए, कुछ सिस्टम फीडबैक होना चाहिए... - समापन के लिए संवाद डिज़ाइन करें:
क्रियाओं के अनुक्रम को आरंभ, मध्य और अंत के साथ समूहों में व्यवस्थित किया जाना चाहिए... - सरल त्रुटि प्रबंधन की पेशकश करें:
जहां तक संभव हो, सिस्टम को डिज़ाइन करें ताकि उपयोगकर्ता कोई गंभीर त्रुटि न कर सके... - कार्यों को आसानी से उलटने की अनुमति दें:
यह सुविधा चिंता से राहत देती है, क्योंकि उपयोगकर्ता जानता है कि त्रुटियों को पूर्ववत किया जा सकता है... - नियंत्रण के आंतरिक नियंत्रण का समर्थन करें:
अनुभवी ऑपरेटर दृढ़ता से यह महसूस करना चाहते हैं कि वे सिस्टम के प्रभारी हैं और सिस्टम उनके कार्यों का जवाब देता है। उपयोगकर्ताओं को उत्तरदाताओं के बजाय कार्यों का आरंभकर्ता बनाने के लिए सिस्टम डिज़ाइन करें। - अल्पकालिक मेमोरी लोड को कम करें:
अल्पकालिक मेमोरी में मानव सूचना प्रसंस्करण की सीमा के लिए आवश्यक है कि डिस्प्ले को सरल रखा जाए, एकाधिक पेज डिस्प्ले को समेकित किया जाए, विंडो-मोशन आवृत्ति को कम किया जाए, और कोड, निमोनिक्स और क्रियाओं के अनुक्रम के लिए पर्याप्त प्रशिक्षण समय आवंटित किया जाए।
वेन्स्चेंक और बार्कर वर्गीकरण
2000 में, सुसान वेई आप चेन के हैं और डीन बार्कर[11] निम्नलिखित बीस प्रकारों में कई प्रमुख प्रदाताओं द्वारा उपयोग किए जाने वाले अनुमानों और दिशानिर्देशों का वर्गीकरण बनाया गया:[12]
- उपयोगकर्ता नियंत्रण:
इंटरफ़ेस उपयोगकर्ता को यह समझने की अनुमति देगा कि वे नियंत्रण में हैं और उचित नियंत्रण की अनुमति देगा। - मानवीय सीमाएँ:
इंटरफ़ेस उपयोगकर्ता की संज्ञानात्मक, दृश्य, श्रवण, स्पर्श या मोटर सीमाओं को अधिभारित नहीं करेगा। - मॉडल इंटीग्रिटी:
इंटरफ़ेस व्यक्तिगत कार्यों को किसी भी मोडैलिटी (मानव-कंप्यूटर इंटरैक्शन) के भीतर फिट करेगा: श्रवण, दृश्य, या मोटर/काइनेस्टेटिक। - आवास:
इंटरफ़ेस प्रत्येक उपयोगकर्ता समूह के काम करने और सोचने के तरीके में फिट होगा। - भाषाई स्पष्टता:
इंटरफ़ेस यथासंभव कुशलता से संचार करेगा। - सौंदर्य संबंधी अखंडता:
इंटरफ़ेस में एक आकर्षक और उपयुक्त डिज़ाइन होगा। - सरलता:
इंटरफ़ेस तत्वों को सरलता से प्रस्तुत करेगा। - पूर्वानुमेयता:
इंटरफ़ेस इस तरह से व्यवहार करेगा कि उपयोगकर्ता सटीक भविष्यवाणी कर सकें कि आगे क्या होगा। - व्याख्या:
इंटरफ़ेस इस बारे में उचित अनुमान लगाएगा कि उपयोगकर्ता क्या करने का प्रयास कर रहा है। - सटीकता:
इंटरफ़ेस त्रुटियों से मुक्त होगा। - तकनीकी स्पष्टता:
इंटरफ़ेस में उच्चतम संभव निष्ठा होगी। - लचीलापन:
इंटरफ़ेस उपयोगकर्ता को कस्टम उपयोग के लिए डिज़ाइन को समायोजित करने की अनुमति देगा। - पूर्ति:
इंटरफ़ेस एक संतोषजनक उपयोगकर्ता अनुभव प्रदान करेगा। - सांस्कृतिक औचित्य:
इंटरफ़ेस उपयोगकर्ता के सामाजिक रीति-रिवाजों और अपेक्षाओं से मेल खाएगा। - उपयुक्त गति:
इंटरफ़ेस उपयोगकर्ता के लिए उपयुक्त गति पर काम करेगा। - संगति:
इंटरफ़ेस सुसंगत होगा। - उपयोगकर्ता सहायता:
इंटरफ़ेस आवश्यकता या अनुरोध के अनुसार अतिरिक्त सहायता प्रदान करेगा। - परिशुद्धता:
इंटरफ़ेस उपयोगकर्ताओं को सटीक रूप से कार्य करने की अनुमति देगा। - क्षमा:
इंटरफ़ेस कार्यों को पुनर्प्राप्ति योग्य बना देगा। - जवाबदेही:
इंटरफ़ेस उपयोगकर्ताओं को उनके कार्यों के परिणामों और इंटरफ़ेस की स्थिति के बारे में सूचित करेगा।
डोमेन या संस्कृति-विशिष्ट अनुमानी मूल्यांकन
एक विशिष्ट डोमेन और संस्कृति वाले एप्लिकेशन के लिए, ऊपर उल्लिखित अनुमान संभावित प्रयोज्य समस्याओं की पहचान नहीं करते हैं।[13] अनुमानों की ये सीमाएँ इसलिए उत्पन्न होती हैं क्योंकि ये अनुमान किसी एप्लिकेशन के डोमेन और संस्कृति-विशिष्ट विशेषताओं पर विचार करने में असमर्थ हैं। इसके परिणामस्वरूप डोमेन-विशिष्ट या संस्कृति-विशिष्ट अनुमानी मूल्यांकन की शुरूआत होती है।[14]
यह भी देखें
- प्रयोज्य निरीक्षण
- प्रगतिशील खुलासा
- संज्ञानात्मक पूर्वाग्रह
- संज्ञानात्मक आयाम, नोटेशन, यूजर इंटरफेस और प्रोग्रामिंग भाषाओं के डिजाइन के मूल्यांकन के लिए एक रूपरेखा
संदर्भ
- ↑ Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1–5 April), 249–256
- ↑ 2.0 2.1 2.2 Experience, World Leaders in Research-Based User. "Heuristic Evaluation: How-To: Article by Jakob Nielsen". Nielsen Norman Group (in English). Retrieved 3 December 2021.
{{cite web}}:|first=has generic name (help) - ↑ Nielsen, J.; Molich, R. (1989). "प्रयोज्य इंजीनियरिंग के आधार पर यूजर इंटरफेस डिजाइन सिखाना". ACM SIGCHI Bulletin. 21 (1): 45–48. doi:10.1145/67880.67885. ISSN 0736-6906. S2CID 41663689. Retrieved 25 May 2022.
- ↑ Molich, Rolf; Nielsen, Jakob (1990). "मानव-कंप्यूटर संवाद में सुधार". Communications of the ACM. 33 (3): 338–348. doi:10.1145/77481.77486. ISSN 0001-0782. S2CID 11462820. Retrieved 4 February 2022.
- ↑ Nielsen, Jakob (1994). प्रयोज्य अनुमानों की व्याख्यात्मक शक्ति को बढ़ाना. the SIGCHI conference. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Celebrating Interdependence - CHI '94. Boston, Massachusetts, United States: ACM Press. pp. 152–158. doi:10.1145/191666.191729. ISBN 978-0-89791-650-9. Retrieved 25 May 2022.
- ↑ Nielsen, Jakob (2005), Ten usability heuristics (PDF), S2CID 59788005
- ↑ Gerhardt-Powals, Jill (1996). "Cognitive engineering principles for enhancing human – computer performance". International Journal of Human-Computer Interaction. 8 (2): 189–211. doi:10.1080/10447319609526147.
- ↑ Heuristic Evaluation – Usability Methods – What is a heuristic evaluation? Archived 28 June 2013 at the Wayback Machine Usability.gov
- ↑ Shneiderman (1998, p. 75); as cited in: "Eight Golden Rules of Interface Design". at www.cs.umd.edu.
- ↑ Malviya, Kartik (20 November 2020). "8 Golden Rules of Interface Design". Medium (in English). UX Planet. Retrieved 2 March 2021.
{{cite web}}: CS1 maint: url-status (link) - ↑ Weinschenk, S and Barker,D. (2000) Designing Effective Speech Interfaces. Wiley.
- ↑ Jeff Sauro. "What's the difference between a Heuristic Evaluation and a Cognitive Walkthrough?". MeasuringUsability.com.
- ↑ Nizamani, Sehrish; Khoumbati, Khalil; Nizamani, Sarwat; Memon, Shahzad; Nizamani, Saad; Laghari, Gulsher (20 March 2021). "डोमेन और संस्कृति-उन्मुख अनुमान निर्माण और सत्यापन के लिए एक पद्धति". Behaviour & Information Technology. 41 (8): 1769–1795. doi:10.1080/0144929X.2021.1903080. ISSN 0144-929X. S2CID 233682515.
- ↑ Nizamani, Sehrish; Nizamani, Saad; Basir, Nazish; Memon, Muhammad; Nizamani, Sarwat; Memon, Shahzad (5 April 2021). "पाकिस्तान के विश्वविद्यालयों की वेबसाइटों का डोमेन और संस्कृति-विशिष्ट अनुमानी मूल्यांकन". University of Sindh Journal of Information and Communication Technology (in English). 5 (1): 45–51. ISSN 2523-1235.
अग्रिम पठन
- Dix, Alan; Finlay, Janet; Abowd, Gregory D.; Beale, Russell (1993). Human-computer interaction (3 ed.). Harlow, England: Pearson Education. p. 324. ISBN 9780134372112.
- Nielsen, Jakob; Mack, Robert L. (1994). Usability Inspection Methods (1 ed.). Wiley. ISBN 978-0471018773.
- Cooper, Alan; Reimann, Robert (2003). About Face 2.0: The Essentials of Interaction Design (2 ed.). Wiley. ISBN 978-0764526411.
- Hvannberg, Ebba Thora; Law, Effie Lai-Chong; Lárusdóttir, Marta Kristín (March 2007). "Heuristic evaluation: Comparing ways of finding and reporting usability problems". Interacting with Computers. 19 (2): 225–240. doi:10.1016/j.intcom.2006.10.001. hdl:20.500.11850/6665.
- Gerhardt‐Powals, Jill (23 September 2009). "Cognitive engineering principles for enhancing human‐computer performance". International Journal of Human–Computer Interaction. 8 (2): 189–211. doi:10.1080/10447319609526147.
- Garrett, Jesse James (2010). The Elements of User Experience: User-Centered Design for the Web. Voices That Matter (2 ed.). Pearson Education. ISBN 9780321624642.
बाहरी संबंध
- A list of Nielsen Norman's Heuristic Evaluation Articles & Videos – Including fundamental points, methodologies and benefits.
- Heuristic Evaluation at Usability.gov Archived 28 June 2013 at the Wayback Machine
