ह्यूरिस्टिक इवैल्यूएशन: Difference between revisions
No edit summary |
|||
| Line 13: | Line 13: | ||
== कार्यप्रणाली == | == कार्यप्रणाली == | ||
प्रोजेक्ट के दायरे और प्रकार के आधार पर अनुमानी मूल्यांकन विभिन्न तरीकों से आयोजित किए जाते हैं। एक सामान्य नियम के रूप में, मूल्यांकन के भीतर पूर्वाग्रह को कम करने और निष्कर्षों को अधिकतम करने के लिए शोध ढाँचे शामिल होते हैं। अनुमानी मूल्यांकन के कई पक्ष और विपक्ष हैं। इसका बहुत कुछ संसाधनों की मात्रा और उपयोगकर्ता के पास इसके लिए उपलब्ध समय पर निर्भर करता है। | |||
पेशेवर: | पेशेवर: चूंकि मूल्यांकनकर्ता जिन मानदंडों से गुजरता है उनकी एक बहुत विस्तृत सूची है, यह एक बहुत विस्तृत प्रक्रिया है और उन क्षेत्रों पर अच्छी प्रतिक्रिया प्रदान करती है जिनमें सुधार किया जा सकता है। इसके अलावा, चूंकि यह कई लोगों द्वारा किया जाता है, इसलिए डिज़ाइनर को कई दृष्टिकोणों से प्रतिक्रिया मिल सकती है। चूंकि यह अपेक्षाकृत सरल प्रक्रिया है, इसलिए मूल्यांकन के आयोजन और इसे क्रियान्वित करने से संबंधित कम नैतिक और तार्किक चिंताएं हैं। | ||
विपक्ष: चूंकि मानदंडों का एक विशिष्ट सेट है, मूल्यांकन केवल उतना ही अच्छा होगा जितना इसका मूल्यांकन | विपक्ष: चूंकि मानदंडों का एक विशिष्ट सेट है, मूल्यांकन केवल उतना ही अच्छा होगा जितना लोग इसका मूल्यांकन करते हैं। इससे इस मूल्यांकन को संचालित करने के लिए पर्याप्त योग्य विशेषज्ञों और लोगों को ढूंढने का एक और मुद्दा सामने आता है। हालाँकि, यदि आपके पास विशेषज्ञों और योग्य मूल्यांकनकर्ताओं के करीबी संसाधन हैं, तो यह कोई समस्या नहीं होगी। इसके अलावा, क्योंकि मूल्यांकन केवल व्यक्तिगत अवलोकन होते हैं, परिणामों में कोई ठोस डेटा नहीं होता है - डिजाइनर को बस इन विचारों को ध्यान में रखते हुए सभी जानकारी और मूल्यांकन करना होता है। | ||
=== मूल्यांकनकर्ताओं की संख्या === | === मूल्यांकनकर्ताओं की संख्या === | ||
नीलसन के अनुसार, तीन से पांच मूल्यांकनकर्ताओं की | नीलसन के अनुसार, एक अध्ययन के भीतर तीन से पांच मूल्यांकनकर्ताओं की संस्तुति की जाती है।<ref name=":0">{{Cite web|last=Experience|first=World Leaders in Research-Based User|title=Heuristic Evaluation: How-To: Article by Jakob Nielsen|url=https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/|access-date=2021-12-03|website=Nielsen Norman Group|language=en}}</ref> पांच से अधिक मूल्यांकनकर्ताओं के होने से अंतर्दृष्टि की मात्रा में वृद्धि नहीं होती है, और इससे समग्र मूल्यांकन में लाभ की तुलना में अधिक लागत जुड़ सकती है। | ||
=== व्यक्तिगत और समूह प्रक्रिया === | === व्यक्तिगत और समूह प्रक्रिया === | ||
समूह पुष्टिकरण पूर्वाग्रह को कम करने के लिए परिणामों को | समूह पुष्टिकरण पूर्वाग्रह को कम करने के लिए परिणामों को एकत्र करने से पहले '''अनुमानी मूल्यांकन''' व्यक्तिगत रूप से शुरू होना चाहिए।<ref name=":0" /> अंतर्दृष्टि जमा करने के लिए समूह चर्चा में प्रवेश करने से पहले मूल्यांकनकर्ता को प्रोटोटाइप की स्वतंत्र रूप से जांच करनी चाहिए। | ||
=== | === पर्यवेक्षक ट्रेड-ऑफ़ === | ||
मूल्यांकन सत्र में एक पर्यवेक्षक को | किसी मूल्यांकन सत्र में एक पर्यवेक्षक को शामिल करते समय लागत और लाभ जुड़े होते हैं।<ref name=":0" /> | ||
एक पर्यवेक्षक के | एक पर्यवेक्षक के बिना एक सत्र में, मूल्यांकनकर्ताओं को उत्पाद/प्रोटोटाइप के साथ बातचीत करते समय एक लिखित रिपोर्ट के भीतर अपनी व्यक्तिगत टिप्पणियों को औपचारिक रूप देने की आवश्यकता होगी। इस विकल्प के लिए मूल्यांकनकर्ताओं को अधिक समय और प्रयास की आवश्यकता होगी, और इसके लिए अध्ययन के संचालकों को व्यक्तिगत रिपोर्ट की व्याख्या करने के लिए अतिरिक्त समय की भी आवश्यकता होगी। हालाँकि, यह विकल्प कम खर्चीला है क्योंकि यह पर्यवेक्षकों को काम पर रखने से जुड़ी ओवरहेड लागत को कम कर देता है। | ||
एक पर्यवेक्षक के साथ, मूल्यांकनकर्ता अपना विश्लेषण मौखिक रूप से प्रदान कर सकते हैं, जबकि पर्यवेक्षक मूल्यांकनकर्ताओं के निष्कर्षों को प्रतिलेखित और व्याख्या कर सकते हैं। यह विकल्प मूल्यांकनकर्ताओं पर कार्यभार की मात्रा और कई मूल्यांकनकर्ताओं के निष्कर्षों की व्याख्या करने के लिए आवश्यक समय को कम करता है। | |||
==नील्सन के अनुमान== | |||
# | |||
# | उपयोगकर्ता इंटरफ़ेस डिज़ाइन के लिए जैकब नीलसन का अनुमान शायद सबसे अधिक उपयोग किया जाने वाला प्रयोज्य अनुमान है। अनुमान का प्रारंभिक संस्करण नीलसन और [[रॉल्फ मोलिच]] द्वारा 1989-1990 में प्रकाशित दो पत्रों में छपा।<ref>{{Cite journal| doi = 10.1145/67880.67885| issn = 0736-6906| volume = 21| issue = 1| pages = 45–48| last1 = Nielsen| first1 = J.| last2 = Molich| first2 = R.| title = प्रयोज्य इंजीनियरिंग के आधार पर यूजर इंटरफेस डिजाइन सिखाना| journal = ACM SIGCHI Bulletin| accessdate = 2022-05-25| date = 1989| s2cid = 41663689| url = https://doi.org/10.1145/67880.67885}}</ref><ref>{{Cite journal| doi = 10.1145/77481.77486| issn = 0001-0782| volume = 33| issue = 3| pages = 338–348| last1 = Molich| first1 = Rolf| last2 = Nielsen| first2 = Jakob| title = मानव-कंप्यूटर संवाद में सुधार| journal = Communications of the ACM| accessdate = 2022-02-04| date = 1990| s2cid = 11462820| url = https://doi.org/10.1145/77481.77486}}</ref> नीलसन ने 1994 में एक अद्यतन सेट प्रकाशित किया,<ref>{{Cite conference| publisher = ACM Press| doi = 10.1145/191666.191729| isbn = 978-0-89791-650-9| conference = the SIGCHI conference| pages = 152–158| last = Nielsen| first = Jakob| title = प्रयोज्य अनुमानों की व्याख्यात्मक शक्ति को बढ़ाना| journal = Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Celebrating Interdependence - CHI '94| location = Boston, Massachusetts, United States| accessdate = 2022-05-25| date = 1994| url = http://portal.acm.org/citation.cfm?doid=191666.191729}}</ref> और आज भी उपयोग में आने वाला अंतिम सेट 2005 में प्रकाशित हुआ:<ref>{{Citation| last = Nielsen| first = Jakob| title = Ten usability heuristics| date = 2005| s2cid = 59788005| url = https://pdfs.semanticscholar.org/5f03/b251093aee730ab9772db2e1a8a7eb8522cb.pdf}}</ref> | ||
# | |||
# त्रुटि निवारण: | # '''प्रणाली स्थिति की दृश्यता:''' सिस्टम को उपयोगकर्ताओं को हमेशा उचित समय के भीतर उचित फीडबैक के माध्यम से क्या हो रहा है, इसके बारे में सूचित रखना चाहिए। | ||
# | # '''प्रणाली और वास्तविक दुनिया के बीच मिलान:''' सिस्टम को उपयोगकर्ता की भाषा बोलनी चाहिए, जिसमें सिस्टम-उन्मुख शब्दों के बजाय उपयोगकर्ता के परिचित शब्द, वाक्यांश और अवधारणाएं शामिल होनी चाहिए। वास्तविक दुनिया की परंपराओं का पालन करें, जिससे जानकारी प्राकृतिक और तार्किक क्रम में प्रदर्शित हो। | ||
# उपयोग | # '''उपयोक्ता नियंत्रण एवं स्वतंत्रता:''' उपयोगकर्ता अक्सर गलती से सिस्टम फ़ंक्शन चुनते हैं और उन्हें विस्तारित संवाद से गुजरने के बिना अवांछित स्थिति छोड़ने के लिए स्पष्ट रूप से चिह्नित "आपातकालीन निकास" की आवश्यकता होगी। पूर्ववत करें और फिर से करें का समर्थन करें. | ||
# | # '''निरंतरता और मानक:''' उपयोगकर्ताओं को यह आश्चर्य नहीं करना चाहिए कि क्या विभिन्न शब्दों, स्थितियों या कार्यों का मतलब एक ही है। प्लेटफ़ॉर्म परंपराओं का पालन करें. | ||
# उपयोगकर्ताओं को त्रुटियों को पहचानने, निदान करने और | # '''त्रुटि निवारण:''' अच्छे त्रुटि संदेशों से भी बेहतर एक सावधानीपूर्वक डिज़ाइन है जो किसी समस्या को पहली बार में होने से रोकता है। या तो त्रुटि-प्रवण स्थितियों को समाप्त करें या उनके लिए जाँच करें और कार्रवाई करने से पहले उपयोगकर्ताओं को एक पुष्टिकरण विकल्प प्रस्तुत करें। | ||
# सहायता और | # '''स्मरण के स्थान पर मान्यता:''' ऑब्जेक्ट, क्रियाएं और विकल्प दृश्यमान बनाकर उपयोगकर्ता की मेमोरी लोड को कम करें। उपयोगकर्ता को संवाद के एक भाग से दूसरे भाग की जानकारी याद रखने की ज़रूरत नहीं होनी चाहिए। सिस्टम के उपयोग के निर्देश जब भी उपयुक्त हों, दिखाई देने चाहिए या आसानी से पुनर्प्राप्त किए जाने योग्य होने चाहिए। | ||
# '''उपयोग का लचीलापन एवं दक्षता:''' एक्सेलेरेटर - नौसिखिया उपयोगकर्ता द्वारा अनदेखा - अक्सर विशेषज्ञ उपयोगकर्ता के लिए इंटरैक्शन को तेज कर सकता है ताकि सिस्टम अनुभवहीन और अनुभवी दोनों उपयोगकर्ताओं को पूरा कर सके। उपयोगकर्ताओं को बारंबार कार्रवाइयां अनुकूलित करने की अनुमति दें। | |||
# '''सौंदर्यात्मक और न्यूनतम डिज़ाइन:''' संवादों में ऐसी जानकारी नहीं होनी चाहिए जो अप्रासंगिक हो या जिसकी आवश्यकता शायद ही हो। किसी संवाद में सूचना की प्रत्येक अतिरिक्त इकाई सूचना की संबंधित इकाइयों के साथ प्रतिस्पर्धा करती है और उनकी सापेक्ष दृश्यता कम कर देती है। | |||
# '''उपयोगकर्ताओं को त्रुटियों को पहचानने, निदान करने और पुनर्प्राप्त करने में सहायता करें:''' त्रुटि संदेशों को सरल भाषा (कोई कोड नहीं) में व्यक्त किया जाना चाहिए, समस्या का सटीक संकेत देना चाहिए और रचनात्मक रूप से समाधान सुझाना चाहिए। | |||
# '''सहायता और डॉक्यूमेंट:''' यद्यपि यह बेहतर है कि सिस्टम का उपयोग दस्तावेज़ीकरण के बिना किया जा सके, फिर भी सहायता और दस्तावेज़ीकरण प्रदान करना आवश्यक हो सकता है। ऐसी कोई भी जानकारी खोजना आसान होनी चाहिए, उपयोगकर्ता के कार्य पर केंद्रित होनी चाहिए, किए जाने वाले ठोस कदमों की सूची होनी चाहिए और बहुत बड़ी नहीं होनी चाहिए। | |||
== गेरहार्ट-पॉवल्स के संज्ञानात्मक इंजीनियरिंग सिद्धांत == | == गेरहार्ट-पॉवल्स के संज्ञानात्मक इंजीनियरिंग सिद्धांत == | ||
Revision as of 17:51, 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
