यूजर-सेंटर्ड डिज़ाइन: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
{{See also|यूजर-सेंटर्ड डिज़ाइन}} | {{See also|यूजर-सेंटर्ड डिज़ाइन}} | ||
'''यूजर-सेंटर्ड डिज़ाइन''' (यूसीडी) या यूजर- | '''यूजर-सेंटर्ड डिज़ाइन''' (यूसीडी) या यूजर-ड्रिवेन डेवलपमेंट (यूडीडी) प्रोसेस का फ्रेमवर्क है (इंटरफ़ेस या टेक्नोलॉजी तक सीमित नहीं) जिसमें [[प्रयोज्य|यूजएबिलिटी]] गोल, यूजर विशेषताएँ, [[पर्यावरण (सिस्टम)|एनवायरनमेंट (सिस्टम)]], टास्क और किसी [[उत्पाद (व्यवसाय)|प्रोडक्ट (व्यवसाय)]] का वर्कफ़्लो इंक्लूड होता है। [[डिज़ाइन प्रक्रिया|डिज़ाइन प्रोसेस]] के प्रत्येक स्टेज में सर्विस या प्रोसेस पर ब्रॉड ध्यान दिया जाता है। ये परीक्षण रिक्वायरमेंट्स, प्री-प्रोडक्शन मॉडल और पोस्ट प्रोडक्शन की प्रोसेस के प्रत्येक स्टेज के समय एक्चुअल यूजर्स के साथ या उनके बिना कंडक्ट किए जाते हैं, जो प्रूफ के सर्कल को पूर्ण करते हैं और यह सुनिश्चित करते हैं कि डेवलपमेंट यूजर को फोकस के केंद्र के रूप में आगे बढ़ाता है।<ref>{{cite web|url=http://uiaccess.com/accessucd/|title=Cover – Just Ask: Integrating Accessibility Throughout Design|website=uiaccess.com}}</ref><ref name="w3.org">{{cite web|url=https://www.w3.org/WAI/redesign/ucd|title=उपयोगकर्ता केंद्रित डिज़ाइन प्रक्रिया (यूसीडी) पर नोट्स|website=www.w3.org}}</ref> इस प्रकार का परीक्षण<ref>{{cite book|last1=Rubin|first1=Jeffrey|last2=Chisnell|first2=Dana|title=Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests|date=10 March 2011|publisher=John Wiley & Sons|isbn=978-1-118-08040-5|url=https://books.google.com/books?id=l_e1MmVzMb0C&q=Jeffrey+Rubin,+Handbook+of+Usability+Testing:+How+to+Plan,+Design,+and+Conduct+Effective+Tests,|language=en}}</ref> आवश्यक है क्योंकि किसी प्रोडक्ट के डिज़ाइनरों के लिए सर्वप्रथम उनके डिज़ाइन [[अनुभव|अनुभवों]] को सरलता से समझना कठिन होता है कि प्रत्येक यूजर का लर्निंग कर्व कैसा दिख सकता है। यूजर-सेंटर्ड डिज़ाइन यूजर की अंडरस्टैंडिंग, उनकी डिमांड, प्राथमिकताओं और अनुभवों पर आधारित होता है और जब इसका उपयोग किया जाता है, तो यह प्रोडक्ट की यूजफुलनेस और यूजएबिलिटी में इनक्रीस के लिए जाना जाता है क्योंकि यह यूजर को सेटिस्फेक्शन प्रदान करता है।<ref>{{Cite web|url=http://www.cse.chalmers.se/research/group/idc/ituniv/kurser/09/hcd/literatures/Vredenburg%202002.pdf|title=उपयोगकर्ता-केंद्रित डिज़ाइन अभ्यास का एक सर्वेक्षण|last1=Vredenburg|first1=Karel|last2=Mao|first2=Ji-Ye|year=2002|last3=Smith|first3=Paul|last4=Carey|first4=Tom}}</ref>अन्य प्रोडक्ट डिज़ाइन फिलॉसफीस से मुख्य अंतर यह है कि यूजर-सेंटर्ड डिज़ाइन प्रोडक्ट को ऑप्टिमाइज़ करने का प्रयास करता है कि यूजर प्रोडक्ट का उपयोग कैसे कर सकते हैं, या कैसे करना चाहते हैं जिससे यूजर्स को प्रोडक्ट को एकमोडेट करने के लिए अपने बिहेवियर और एक्सपेक्टेशन को परिवर्तित करने के लिए विवश न होना पड़े। इस प्रकार यूजर दो को-सेंट्रिक सर्कल्स के केंद्र में स्टैंड करते हैं। इनर सर्कल में प्रोडक्ट का कॉन्टेक्स्ट, विकसित करने के उद्देश्य और वह एनवायरनमेंट इंक्लूड है जिसमें यह रन करेगा। आउटर सर्कल में टास्क डिटेल, टास्क ऑर्गेनाइजेशन और टास्कफलो का अधिक विस्तृत विवरण इंक्लूड है।<ref name="w3.org" /> | ||
== इतिहास == | == इतिहास == | ||
यूजर-सेंटर्ड डिज़ाइन शब्द 1977 में रॉब क्लिंग द्वारा दिया गया था<ref>{{Cite journal|last=Kling|first=Rob|date=1977|title=उपयोगकर्ता-केंद्रित सॉफ़्टवेयर डिज़ाइन का संगठनात्मक संदर्भ|url=https://www.jstor.org/stable/249021|journal=MIS Quarterly|volume=1|issue=4|pages=41–52|doi=10.2307/249021|jstor=249021|issn=0276-7783}}</ref> और पश्चात में कैलिफोर्निया विश्वविद्यालय, सैन डिएगो में डोनाल्ड ए. नॉर्मन की अनुसंधान प्रयोगशाला में स्वीकार किया गया। 1986 में यूजर-सेंटर्ड सिस्टम डिज़ाइन | यूजर-सेंटर्ड डिज़ाइन शब्द 1977 में रॉब क्लिंग द्वारा दिया गया था<ref>{{Cite journal|last=Kling|first=Rob|date=1977|title=उपयोगकर्ता-केंद्रित सॉफ़्टवेयर डिज़ाइन का संगठनात्मक संदर्भ|url=https://www.jstor.org/stable/249021|journal=MIS Quarterly|volume=1|issue=4|pages=41–52|doi=10.2307/249021|jstor=249021|issn=0276-7783}}</ref> और पश्चात में कैलिफोर्निया विश्वविद्यालय, सैन डिएगो में डोनाल्ड ए. नॉर्मन की अनुसंधान प्रयोगशाला में स्वीकार किया गया। 1986 में यूजर-सेंटर्ड सिस्टम डिज़ाइन ह्यूमन-कंप्यूटर इंटरैक्शन ऑन न्यू पर्सपेक्टिव पुस्तक के प्रकाशन के परिणामस्वरूप यह कॉन्सेप्ट ब्रॉड रूप से लोकप्रिय हो गया।<ref>Norman, D. A. (1986). ''User-Centered System Design: New Perspectives on Human-Computer Interaction''.</ref> इस कॉन्सेप्ट को नॉर्मन की पुस्तक [[रोजमरहा की चीजों के डिज़ाइन|दी डिजाइन ऑफ एवरीडे थिंग्स]] (मूल रूप से द साइकोलॉजी ऑफ एवरीडे थिंग्स कहा जाता है) में और अधिक स्वीकृति मिली। इस पुस्तक में, नॉर्मन उदाहरणों के माध्यम से 'गुड' और 'बैड' डिज़ाइन की फिलॉसफी का वर्णन करते हैं। वह हमारे एवरीडे लाइफ में डिजाइन के महत्व और बैड डिजाइन के कारण होने वाली एरेर के परिणामों को प्रदर्शित करता है। | ||
दोनों पुस्तकों में उचित प्रकार से डिज़ाइन किए गए प्रोडक्टों के निर्माण के सिद्धांत | दोनों पुस्तकों में उचित प्रकार से डिज़ाइन किए गए प्रोडक्टों के निर्माण के सिद्धांत इंक्लूड हैं। उनकी विशेषता एस्थेटिक्स जैसे सेकेंडरी इश्यूज के अतिरिक्त यूजर की नीड पर आधारित होती हैं। इनमें से मेन हाइलाइट्स हैं: | ||
# टास्क | # टास्क के स्ट्रक्वेरिएबल को इस प्रकार सरल बनाना कि किसी भी मोमेंट पॉसिबल एक्शन इंट्यूटिव हों। | ||
# सिस्टम के कॉन्सेप्चुअल मॉडल, टास्क, टास्क के रिजल्ट्स और फीडबैक सहित थिंग्स को विजिबल बनाएं। | # सिस्टम के कॉन्सेप्चुअल मॉडल, टास्क, टास्क के रिजल्ट्स और फीडबैक सहित थिंग्स को विजिबल बनाएं। | ||
# इंटेंडेड रिजल्ट्स और आवश्यक एक्शन के मध्य राइट मैपिंग प्राप्त करना। | # इंटेंडेड रिजल्ट्स और आवश्यक एक्शन के मध्य राइट मैपिंग प्राप्त करना। | ||
# सिस्टम के कंस्ट्रेंट्स को एम्ब्रेस और एक्सप्लॉइट करना। | # सिस्टम के कंस्ट्रेंट्स को एम्ब्रेस और एक्सप्लॉइट करना। | ||
पश्चात की पुस्तक, [[भावनात्मक डिज़ाइन|इमोशनल डिज़ाइन]] में,<ref>{{cite web|url=http://www.jnd.org/dn.mss/CH00_Prolog.pdf|title=Don Norman (2003) Emotional Design, Prolog-- Three Teapots|website=jnd.org}}</ref> | पश्चात की पुस्तक, [[भावनात्मक डिज़ाइन|इमोशनल डिज़ाइन]] में,<ref>{{cite web|url=http://www.jnd.org/dn.mss/CH00_Prolog.pdf|title=Don Norman (2003) Emotional Design, Prolog-- Three Teapots|website=jnd.org}}</ref> नॉर्मन अपने पूर्व विचारों को याद करके विस्तार से बताता है जो उसे अत्यधिक रिडक्टिव लगा था। | ||
== मॉडल और अप्प्रोचेस == | == मॉडल और अप्प्रोचेस == | ||
उदाहरण के लिए, यूजर-सेंटर्ड डिज़ाइन प्रोसेस सॉफ़्टवेयर डिज़ाइनरों को अपने | उदाहरण के लिए, यूजर-सेंटर्ड डिज़ाइन प्रोसेस सॉफ़्टवेयर डिज़ाइनरों को अपने यूजर्स के लिए इंजीनियर्ड प्रोडक्ट के गोल को पूर्ण करने में सहायता कर सकती है। यूजर की रिक्वायरमेंट्स को प्रारम्भ से ही कंसीडर किया जाता है और पूर्ण प्रोडक्ट को सर्कल में इंक्लूड किया जाता है। इन रिक्वायरमेंट्स को इन्वेस्टिगेटिव मेथड्स के माध्यम से नोट और रिफाइन किया जाता है जिनमें एंथ्रोपोजेनिक स्टडी, कंटेक्सटुअल इन्वेस्टिगेटिव, प्रोटोटाइप परीक्षण, यूजएबिलिटी परीक्षण और अन्य विधियां इंक्लूड हैं। जनरेटिव मेथड्स का भी उपयोग किया जा सकता है जिनमें [[ कार्ड छँटाई |कार्ड सॉर्टिंग]], एफ़िनिटी डायग्राममिंग और पार्टिसिपेटरी डिज़ाइन सेशन इंक्लूड हैं। इसके अतिरिक्त, डिज़ाइन किए जा रहे प्रोडक्ट के समान यूजएबल प्रोडक्टों के विश्लेषण से यूजर की रिक्वायरमेंट्स का अनुमान लगाया जा सकता है। | ||
यूजर-सेंटर्ड डिज़ाइन निम्नलिखित मॉडलों से | यूजर-सेंटर्ड डिज़ाइन निम्नलिखित मॉडलों से इंस्पायर होता है: | ||
* [[सहकारी डिजाइन|कोऑपरेटिव डिजाइन]]: डिजाइनरों और | * [[सहकारी डिजाइन|कोऑपरेटिव डिजाइन]]: डिजाइनरों और यूजर्स को इक्वल फुटिंग पर इंक्लूड करना है। यह आईटी आर्टिफैक्ट्स के डिजाइन की स्कैंडिनेवियाई ट्रेडिशन है और यह 1970 से विकसित हो रही है।<ref>Greenbaum&Kyng (eds): Design At Work – Cooperative design of Computer Systems, Lawrence Erlbaum 1991</ref> इसे [[सह डिजाइन|को-डिजाइन]] भी कहा जाता है। | ||
* [[सहभागी डिज़ाइन|पार्टिसिपेटरी डिज़ाइन]] (पीडी), इसी कॉन्सेप्ट के लिए उत्तरी अमेरिकी शब्द, कोऑपरेटिव डिज़ाइन से प्रेरित, | * [[सहभागी डिज़ाइन|पार्टिसिपेटरी डिज़ाइन]] (पीडी), इसी कॉन्सेप्ट के लिए उत्तरी अमेरिकी शब्द, कोऑपरेटिव डिज़ाइन से प्रेरित, यूजर्स की पार्टिसिपेशन पर फोकस करता है। 1990 से, द्वि-वार्षिक पार्टिसिपेटरी डिज़ाइन सम्मेलन होता रहा है।<ref>Schuler & Namioka (1993). Participatory Design, Lawrence Erlbaum; and chapter 11 in ''Helander's Handbook of HCI'', Elsevier, 1997.</ref> | ||
* [[प्रासंगिक डिज़ाइन|कंटेक्सटुअल डिज़ाइन]], एक्चुअल कॉन्टेक्स्ट में | * [[प्रासंगिक डिज़ाइन|कंटेक्सटुअल डिज़ाइन]], एक्चुअल कॉन्टेक्स्ट में कस्टमर-सेंटर्ड डिज़ाइन, जिसमें पार्टिसिपेटरी डिज़ाइन के कुछ आइडियाज इंक्लूड हैं<ref>Beyer & Holtzblatt (1998). ''Contextual Design'', Kaufmann.</ref> | ||
यहां वे सिद्धांत दिए गए हैं जो यह सुनिश्चित करने में सहायता करते हैं कि डिज़ाइन यूजर-सेंटर्ड है:<ref>{{cite web|title=उपयोगकर्ता-केंद्रित डिज़ाइन मूल बातें|url=https://www.usability.gov/what-and-why/user-centered-design.html|website=www.usability.gov}}</ref> | यहां वे सिद्धांत दिए गए हैं जो यह सुनिश्चित करने में सहायता करते हैं कि डिज़ाइन यूजर-सेंटर्ड है:<ref>{{cite web|title=उपयोगकर्ता-केंद्रित डिज़ाइन मूल बातें|url=https://www.usability.gov/what-and-why/user-centered-design.html|website=www.usability.gov}}</ref> | ||
# डिज़ाइन | # डिज़ाइन यूजर्स, टास्क और एनवायरनमेंट की एक्सप्लिसिट अंडरस्टैंडिंग पर आधारित है। | ||
# यूजर डिज़ाइन और | # यूजर डिज़ाइन और डेवलपमेंट के समय इंक्लूड होते हैं।<ref>{{Cite journal|last1=Mathur|first1=Sunita|last2=Janaudis‐Ferreira|first2=Tania|last3=Hemphill|first3=Julia|last4=Cafazzo|first4=Joseph A.|last5=Hart|first5=Donna|last6=Holdsworth|first6=Sandra|last7=Lovas|first7=Mike|last8=Wickerson|first8=Lisa|date=2021-09-23|title=User‐centered design features for digital health applications to support physical activity behaviors in solid organ transplant recipients: A qualitative study|url=https://onlinelibrary.wiley.com/doi/10.1111/ctr.14472|journal=Clinical Transplantation|volume=35 |issue=12 |pages=e14472 |language=en|doi=10.1111/ctr.14472|pmid=34510558 |s2cid=237492723 |issn=0902-0063}}</ref> | ||
# डिज़ाइन यूजर-सेंटर्ड मूल्यांकन द्वारा ड्रिवेन और रिफाइन होता है। | # डिज़ाइन यूजर-सेंटर्ड मूल्यांकन द्वारा ड्रिवेन और रिफाइन होता है। | ||
# | # प्रोसेस इंटरैक्टिव है। | ||
# डिज़ाइन संपूर्ण यूजर एक्सपीरियंस को एड्रेस करता है। | # डिज़ाइन संपूर्ण यूजर एक्सपीरियंस को एड्रेस करता है। | ||
# डिज़ाइन टीम में मल्टीडिसीप्लिनरी स्किल और पर्सपेक्टिव | # डिज़ाइन टीम में मल्टीडिसीप्लिनरी स्किल और पर्सपेक्टिव इंक्लूड हैं। | ||
== यूजर-सेंटर्ड डिज़ाइन प्रोसेस == | == यूजर-सेंटर्ड डिज़ाइन प्रोसेस == | ||
यूजर-सेंटर्ड डिज़ाइन का गोल ऐसे प्रोडक्ट बनाना है जिनकी उपयोगिता बहुत अधिक हो। इसमें यह | यूजर-सेंटर्ड डिज़ाइन का गोल ऐसे प्रोडक्ट बनाना है जिनकी उपयोगिता बहुत अधिक हो। इसमें यह इंक्लूड है कि प्रोडक्ट अपने उपयोग, मेनेजेबिलिटी, एफ्फेक्टिवनेस्स के कॉन्टेक्स्ट में कितना सुविधाजनक है और प्रोडक्ट यूजर की रिक्वायरमेंट्स के अनुरूप कितना उचित है। यूजर-सेंटर्ड डिज़ाइन प्रोसेस के सामान्य फेज नीचे दिए गए हैं:<ref>{{cite web|title=उपयोगकर्ता केंद्रित डिज़ाइन प्रक्रिया (यूसीडी) पर नोट्स|url=https://www.w3.org/WAI/EO/2003/ucd|website=www.w3.org|access-date=30 March 2017}}</ref><ref>{{cite web|title=उपयोगकर्ता-केंद्रित डिज़ाइन मूल बातें|url=https://www.usability.gov/what-and-why/user-centered-design.html|website=www.usability.gov|access-date=30 March 2017}}</ref> | ||
# उपयोग का कॉन्टेक्स्ट स्पेसिफाई करें: | # उपयोग का कॉन्टेक्स्ट स्पेसिफाई करें: आइडेंटिफाई करें कि प्रोडक्ट के प्राइमरी यूजर कौन हैं, वे प्रोडक्ट का उपयोग क्यों करेंगे, उनकी आवश्यकताएं क्या हैं और वे किस एनवायरनमेंट में इसका उपयोग करेंगे। | ||
# आवश्यकताएं स्पेसिफाई करें: कॉन्टेक्स्ट स्पेसिफाई हो जाने के पश्चात, प्रोडक्ट की ग्रेनुलर रिक्वायरमेंट्स को आइडेंटिफाई करने का समय | # आवश्यकताएं स्पेसिफाई करें: कॉन्टेक्स्ट स्पेसिफाई हो जाने के पश्चात, प्रोडक्ट की ग्रेनुलर रिक्वायरमेंट्स को आइडेंटिफाई करने का समय होता है। यह महत्वपूर्ण स्टेज है जो डिजाइनरों को स्टोरीबोर्ड बनाने और प्रोडक्ट को सफल बनाने के लिए महत्वपूर्ण गोल सेट करने में और सुविधा प्रदान कर सकता है। | ||
# डिज़ाइन सोलूशन्स और | # डिज़ाइन सोलूशन्स और डेवलपमेंट: प्रोडक्ट गोल और रिक्वायरमेंट्स के आधार पर, प्रोडक्ट डिज़ाइन और डेवलपमेंट की इटरेटिव डिज़ाइन प्रोसेस प्रारम्भ करें। | ||
# प्रोडक्ट का मूल्यांकन करें: प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के प्रत्येक स्टेज में प्रोडक्ट के लिए | # प्रोडक्ट का मूल्यांकन करें: प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के प्रत्येक स्टेज में प्रोडक्ट के लिए यूजर्स का फीडबैक प्राप्त करने के लिए यूजएबिलिटी परीक्षण करते हैं। | ||
एबव स्टेजों में, प्रोडक्ट को और उत्तम बनाने के लिए उपरोक्त प्रोसेस | एबव स्टेजों में, प्रोडक्ट को और उत्तम बनाने के लिए उपरोक्त प्रोसेस रिपीट की जाती है। ये स्टेज जनरल अप्प्रोचेस और फैक्टर्स हैं जैसे डिज़ाइन गोल, टीम और उनकी टाईमलाईन, और वह एनवायरनमेंट जिसमें प्रोडक्ट विकसित किया गया है, किसी परियोजना और उनके क्रम के लिए उपयुक्त फेज निर्धारित करते हैं। आप या तो [[झरना मॉडल|वाटरफॉल मॉडल]], एजाइल मॉडल या किसी अन्य [[सॉफ्टवेयर इंजीनियरिंग]] प्रैक्टिस को फॉलो कर सकते हैं। | ||
== उद्देश्य == | == उद्देश्य == | ||
यूसीडी यूजर, उनके टास्क और उनके गोल्स के विषय में प्रश्न पूछता है, फिर | यूसीडी यूजर, उनके टास्क और उनके गोल्स के विषय में प्रश्न पूछता है, फिर डेवलपमेंट और डिजाइन के विषय में निर्णय लेने के लिए फाइंडिंग्स का उपयोग करता है। उदाहरण के लिए, किसी वेब साइट का यूसीडी निम्नलिखित प्रश्नों का उत्तर देना चाहता है: | ||
* वेबसाइट के यूजर कौन हैं? | * वेबसाइट के यूजर कौन हैं? | ||
* | * यूजर्स के कार्य और गोल क्या हैं? | ||
* वेबसाइट और समान वेबसाइटों के साथ | * वेबसाइट और समान वेबसाइटों के साथ यूजर्स का एक्सपीरियंस लेवल क्या है? | ||
* | * यूजर्स को वेबसाइट से किन टास्क की आवश्यकता है? | ||
* | * यूजर्स को किस [[जानकारी]] की आवश्यकता हो सकती है, और उन्हें इसकी किस रूप में आवश्यकता है? | ||
* यूजर क्या सोचते हैं कि वेबसाइट को कैसे कार्य करना चाहिए? | * यूजर क्या सोचते हैं कि वेबसाइट को कैसे कार्य करना चाहिए? | ||
* वे कौन से एक्सट्रीम एनवॉरमैंट्स हैं जिनमें वेबसाइट तक पहुंचा जा सकता है? | * वे कौन से एक्सट्रीम एनवॉरमैंट्स हैं जिनमें वेबसाइट तक पहुंचा जा सकता है? | ||
| Line 59: | Line 59: | ||
=== [[दृश्यता|विजिबिलिटी]] === | === [[दृश्यता|विजिबिलिटी]] === | ||
विजिबिलिटी यूजर को डॉक्यूमेंट का [[मानसिक मॉडल|मेंटल मॉडल]] बनाने में सहायता करती है। डॉक्यूमेंट का उपयोग करते समय मॉडल यूजर को उनके टास्क के इफेक्ट का अनुमान लगाने में सहायता करते हैं। महत्वपूर्ण एलिमेंट्स (जैसे कि वे जो [[ मार्गदर्शन |मार्गफिलॉसफीस]] में सहायता करते हैं) एम्फैटिक होने चाहिए। | विजिबिलिटी यूजर को डॉक्यूमेंट का [[मानसिक मॉडल|मेंटल मॉडल]] बनाने में सहायता करती है। डॉक्यूमेंट का उपयोग करते समय मॉडल यूजर को उनके टास्क के इफेक्ट का अनुमान लगाने में सहायता करते हैं। महत्वपूर्ण एलिमेंट्स (जैसे कि वे जो [[ मार्गदर्शन |मार्गफिलॉसफीस]] में सहायता करते हैं) एम्फैटिक होने चाहिए। यूजर्स को ग्लांस से यह बताने में सक्षम होना चाहिए कि वे डॉक्यूमेंट के साथ क्या कर सकते हैं और क्या नहीं कर सकते हैं। | ||
=== एक्सेसिबिलिटी === | === एक्सेसिबिलिटी === | ||
यूजर्स को पूर्ण डॉक्यूमेंट में जानकारी शीघ्र और सरलता से ढूंढने में सक्षम होना चाहिए, चाहे उसकी लेंथ कुछ भी हो। यूजर्स को इंफॉर्मेशन फाइंड करने के विभिन्न वेज़ ऑफर की जानी चाहिए (जैसे कि नेविगेशनल एलिमेंट्स, सर्च फ़ंक्शन, टेबल ऑफ कंटेंट्स,<ref>{{Cite book|last=Aaron|first=Scharf|url=http://worldcat.org/oclc/1086245904|title=A new beginning: primitivism and science in post-impressionist art; [and] Returnto nature|date=1976|publisher=Open University|isbn=0-335-05151-0|oclc=1086245904}}</ref> क्लीयरली लेबल्ड सेक्शन, पेज नंबर, [[रंग कोडिंग|कलर कोडिंग]], आदि)। नेविगेशनल एलिमेंट्स डॉक्यूमेंट की [[शैली|जेनर]] के अनुरूप होने चाहिए। '[[चंकिंग (मनोविज्ञान)|चंकिंग (फिलॉसफी)]]' उपयोगी स्ट्रेटेजी है जिसमें जानकारी को छोटे-छोटे पीसेस में ब्रेक करना इंक्लूड है जिन्हें किसी प्रकार के सार्थक क्रम या [[पदानुक्रम|हायरार्की]] में ऑर्गनाइज्ड किया जा सकता है। डॉक्यूमेंट को [[स्किमिंग (पढ़ना)|स्किम (रीड करना)]] करने की क्षमता यूजर्स को पढ़ने के अतिरिक्त स्कैन करके अपनी इंफॉर्मेशन के पीसेस ढूंढने की अनुमति देती है। इसके लिए प्रायः [[ बोल्ड अक्षरों ]]और [[इटैलिक प्रकार|इटैलिक]] शब्दों का उपयोग किया जाता है। | |||
=== लेजिबिलिटी === | === लेजिबिलिटी === | ||
| Line 74: | Line 74: | ||
=== पर्सोना === | === पर्सोना === | ||
यूसीडी प्रोसेस के समय, यूजर का रिप्रेसेंटिंग [[व्यक्तित्व (उपयोगकर्ता अनुभव)|पर्सोना (यूजर एक्सपीरियंस)]] बनाया जा सकता है। पर्सोना (यूजर एक्सपीरियंस) यूजर आर्चटाइप है जिसका उपयोग प्रोडक्ट सुविधाओं, नेविगेशन, इंटरैक्शन और यहां तक कि विज़ुअल डिज़ाइन के विषय में निर्णय लेने में सहायता के लिए किया जाता है। अधिकतर विषयों में, पर्सोना (यूजर एक्सपीरियंस) को एक्चुअल लोगों के साथ [[नृवंशविज्ञान|एंथ्रोपोजेनिक]] की सीरीज से संश्लेषित किया जाता है, फिर 1-2 पेज के विवरणों में कैप्वेरिएबल किया जाता है जिसमें बिहेवियर पैटर्न, गोल, स्किल, ऐटिटूड और एनवायरनमेंट | यूसीडी प्रोसेस के समय, यूजर का रिप्रेसेंटिंग [[व्यक्तित्व (उपयोगकर्ता अनुभव)|पर्सोना (यूजर एक्सपीरियंस)]] बनाया जा सकता है। पर्सोना (यूजर एक्सपीरियंस) यूजर आर्चटाइप है जिसका उपयोग प्रोडक्ट सुविधाओं, नेविगेशन, इंटरैक्शन और यहां तक कि विज़ुअल डिज़ाइन के विषय में निर्णय लेने में सहायता के लिए किया जाता है। अधिकतर विषयों में, पर्सोना (यूजर एक्सपीरियंस) को एक्चुअल लोगों के साथ [[नृवंशविज्ञान|एंथ्रोपोजेनिक]] की सीरीज से संश्लेषित किया जाता है, फिर 1-2 पेज के विवरणों में कैप्वेरिएबल किया जाता है जिसमें बिहेवियर पैटर्न, गोल, स्किल, ऐटिटूड और एनवायरनमेंट इंक्लूड होते हैं, जिसमें कुछ फ्रिक्शनल पर्सनल डिटेल होते हैं। पर्सोना को लाइफ दे।<ref>{{Cite web|title = अपने व्यक्तित्व को परिपूर्ण बनाना|url = http://www.frankouru.com/journal/2001/08/perfecting_your_personas|website = www.cooper.com|access-date = 2016-01-06}}</ref>प्रत्येक प्रोडक्ट के लिए, या कभी-कभी किसी प्रोडक्ट के अंदर टूल्स के प्रत्येक सेट के लिए, पर्सोनाों का छोटा सेट होता है, जिनमें डिज़ाइन के लिए प्राइमरी फोकस होता है। ऐसा भी होता है जिसे [[द्वितीयक व्यक्तित्व|सेकेंडरी पर्सोना]] कहा जाता है, जहां कैरेक्टर डिजाइन का मेन गोल नहीं होता है, किन्तु उनकी जरूरतों को पूर्ण किया जाना चाहिए और यदि संभव हो तो प्रॉब्लमओं का सॉल्यूशन किया जाना चाहिए। वे फरदर संभावित प्रॉब्लमओं और कठिनाइयों का सॉल्यूशन करने में सहायता करने के लिए इंक्लूड हैं, प्राइमरी व्यक्ति उनके सॉल्यूशन से संतुष्ट होशेयर्ड अंडरस्टैंडिंगइस में एंटी पर्सोना भी है, जो वह कैरेक्टर है जिसके लिए डिज़ाइन विशेष रूप से नहीं बनाया गया है। | ||
पर्सोना इस अर्थ में उपयोगी हैं कि वे यूजर समूह की सामान्य शेयर्ड अंडरस्टैंडिंग बनाते हैं जिसके आधार पर डिज़ाइन प्रोसेस बनाई जाती है। इसके अतिरिक्त, वे यूजर को क्या चाहिए और कौन से फ़ंक्शन जोड़ना और रखना अच्छा लगता है, इसका कॉन्टेक्स्ट प्रदान करके डिज़ाइन संबंधी विचारों को प्राथमिकता देने में सहायता करते हैं। वे डाइवर्सिफाइड और स्कैटर्ड यूजर समूह को ह्यूमन फेस और एक्सिस्टेंस भी प्रदान कर सकते हैं, और | पर्सोना इस अर्थ में उपयोगी हैं कि वे यूजर समूह की सामान्य शेयर्ड अंडरस्टैंडिंग बनाते हैं जिसके आधार पर डिज़ाइन प्रोसेस बनाई जाती है। इसके अतिरिक्त, वे यूजर को क्या चाहिए और कौन से फ़ंक्शन जोड़ना और रखना अच्छा लगता है, इसका कॉन्टेक्स्ट प्रदान करके डिज़ाइन संबंधी विचारों को प्राथमिकता देने में सहायता करते हैं। वे डाइवर्सिफाइड और स्कैटर्ड यूजर समूह को ह्यूमन फेस और एक्सिस्टेंस भी प्रदान कर सकते हैं, और यूजर्स के कॉन्टेक्स्ट में कुछ सहानुभूति पैदा करने और भावनाओं को जोड़ने में सहायता कर सकते हैं। चूंकि पर्सोना कलेक्टेड डेटा से प्राइमरी स्टेकहोल्डर ग्रुप की सामान्यीकृत परसेप्शन है, इसलिए विशेषताएँ ब्रॉड और टिपिकल हो सकती हैं, या एवरेज जो की अधिक हो सकती हैं। कभी-कभी, पर्सोना में स्टीरियोटाइपिकल प्रॉपर्टीज भी हो सकती हैं, जो पूर्ण डिजाइन प्रोसेस को हर्ट कर सकते हैं। डेटा के सेट या व्यक्तियों की विस्तृत सीरीज को कॉन्टेक्स्टित करने के अतिरिक्त, पर्सोना डिज़ाइनरों द्वारा सूचित डिज़ाइन निर्णय लेने के लिए उपयोग किया जाने वाला उपयोगी टूल सकता है। | ||
यूजर परीक्षण और चेंजिंग एनवायरनमेंट के आधार पर, किसी प्रोडक्ट के यूसीडी के माध्यम से पर्सोना (यूजर एक्सपीरियंस) को भी संशोधित किया जा सकता है। यह पर्सोना (यूजर एक्सपीरियंस) का उपयोग करने का आइडियल वे नहीं है, किन्तु इसे वर्जित भी नहीं किया जाना चाहिए, विशेषकर जब यह स्पष्ट हो जाता है कि डिज़ाइन प्रारम्भ होने के पश्चात से किसी प्रोडक्ट के | यूजर परीक्षण और चेंजिंग एनवायरनमेंट के आधार पर, किसी प्रोडक्ट के यूसीडी के माध्यम से पर्सोना (यूजर एक्सपीरियंस) को भी संशोधित किया जा सकता है। यह पर्सोना (यूजर एक्सपीरियंस) का उपयोग करने का आइडियल वे नहीं है, किन्तु इसे वर्जित भी नहीं किया जाना चाहिए, विशेषकर जब यह स्पष्ट हो जाता है कि डिज़ाइन प्रारम्भ होने के पश्चात से किसी प्रोडक्ट के डेवलपमेंट के आसपास के वेरिएबल चेंज हो गए हैं और एवरीडे पर्सोना (यूजर एक्सपीरियंस) | पर्सोना नहीं हो सकते हैं चेंज हुई प्री सिचुएशन को बेस्ट प्रकार से पूर्ण करें। | ||
=== [[परिदृश्य|सिनेरियो]] === | === [[परिदृश्य|सिनेरियो]] === | ||
यूसीडी प्रोसेस में बनाया गया सिनेरियो के मेन कैरेक्टर के रूप में प्राइमरी स्टेकहोल्डर ग्रु के साथ रियल लाइफ या इवेंटओं के अनुक्रम के विषय में फ्रिक्शनल स्टोरी है। सामान्यतः, पर्सोना जो पूर्व बनाया गया था उसे इस स्टोरी के मेन कैरेक्टर के रूप में उपयोग किया जाता है। स्टोरी उन इवेंटओं के विषय में टिपिकल होनी चाहिए जो प्राइमरी स्टेकहोल्डर ग्रुप की प्रॉब्लमओं से संबंधित हों, और सामान्यतः मुख्य रिसर्च प्रश्न जिन पर डिज़ाइन प्रोसेस बनी होती है। ये किसी व्यक्ति के रियल लाइफ के विषय में साधारण स्टोरी बन सकती हैं, किन्तु इवेंटओं के छोटे विवरणों में | यूसीडी प्रोसेस में बनाया गया सिनेरियो के मेन कैरेक्टर के रूप में प्राइमरी स्टेकहोल्डर ग्रु के साथ रियल लाइफ या इवेंटओं के अनुक्रम के विषय में फ्रिक्शनल स्टोरी है। सामान्यतः, पर्सोना जो पूर्व बनाया गया था उसे इस स्टोरी के मेन कैरेक्टर के रूप में उपयोग किया जाता है। स्टोरी उन इवेंटओं के विषय में टिपिकल होनी चाहिए जो प्राइमरी स्टेकहोल्डर ग्रुप की प्रॉब्लमओं से संबंधित हों, और सामान्यतः मुख्य रिसर्च प्रश्न जिन पर डिज़ाइन प्रोसेस बनी होती है। ये किसी व्यक्ति के रियल लाइफ के विषय में साधारण स्टोरी बन सकती हैं, किन्तु इवेंटओं के छोटे विवरणों में यूजर्स के विषय में विवरण इंक्लूड होना चाहिए, और इसमें इमोशनल या फिजिकल विशेषताएं इंक्लूड हो सकती हैं। सबसे बेस्ट सिचुएशन हो सकती है, जहां मेन कैरेक्टर के लिए सब कुछ सबसे बेस्ट कार्य करता है, सबसे बैड सिचुएशन, जहां मेन कैरेक्टर अपने आस-पास सब कुछ रॉंग होने का अनुभव करता है, और एवरेज- सिचुएशन सिनेरियो, जो सामान्य लाइफ है व्यक्ति का, जहां रियल में कुछ भी विशेष या रियल में निराशाजनक नहीं होता है, और दिन यूं ही बीत जाता है। | ||
सिनेरियो सोशल कॉन्टेक्स्ट बनाते हैं जिसमें व्यक्ति | सिनेरियो सोशल कॉन्टेक्स्ट बनाते हैं जिसमें व्यक्ति इंक्लूड होते हैं, और कलेक्टेड डेटा से इनर विशेषताओं वाले कैरेक्टर की इमेजिनेशन करने के अतिरिक्त एक्चुअल फिजिकल वर्ल्ड भी बनाते हैं और कुछ नहीं; पर्सोना के एक्सिस्टेंस में अधिक एक्शन इंक्लूड है। किसी सिनेरियो को लोग अधिक इजली समझ पाते हैं, क्योंकि यह स्टोरी के रूप में होता है और इसका अनुसरण करना आसान होता है। फिर भी, व्यक्तियों की प्रकार, ये सिनेरियो रिसर्चेस और डिजाइनर द्वारा बनाई गई परसेप्शन हैं, और ऑर्गनाइज्ड डेटा के सेट से भी बनाए गए हैं। यह सुनिश्चित करना महत्वपूर्ण है कि सिनेरियो यथासंभव एक्चुअल विश्व सिनेरियो के करीब बनाए जाएं। फिर भी, कभी-कभी यह समझाना और सूचित करना मुश्किल हो सकता है कि लो लेवल फुटिंग के कार्य कैसे होते हैं, उदाहरण के लिए- कार्य करने से पूर्व किसी व्यक्ति की विचार प्रोसेस है। | ||
=== यूज केस === | === यूज केस === | ||
संक्षेप में, यूज केस व्यक्ति और वर्ल्ड के मध्य इंटरेक्शन का वर्णन करता है। प्रत्येक यूज केस ऐसी इवेंट का वर्णन करता है जो रियल लाइफ में थोड़े समय के लिए ऑक्कर हो सकती है, किन्तु इसमें एक्टर और वर्ल्ड के मध्य डिफिकल्ट विवरण और इंटरेक्शन | संक्षेप में, यूज केस व्यक्ति और वर्ल्ड के मध्य इंटरेक्शन का वर्णन करता है। प्रत्येक यूज केस ऐसी इवेंट का वर्णन करता है जो रियल लाइफ में थोड़े समय के लिए ऑक्कर हो सकती है, किन्तु इसमें एक्टर और वर्ल्ड के मध्य डिफिकल्ट विवरण और इंटरेक्शन इंक्लूड हो सकती है। इसे कारण और इफेक्ट योजना के रूप में कैरेक्टर के लिए अपने गोल को प्राप्त करने के लिए सरल स्टेजों की सीरीज के रूप में दर्शाया गया है। यूज केस सामान्यतः दो कॉलम वाले चार्ट के रूप में लिखे जाते हैं: पूर्व कॉलम में एक्टर का लेबल होता है, दूसरे कॉलम में वर्ल्ड का लेबल होता है, और प्रत्येक साइड द्वारा किए गए टास्क को संबंधित कॉलम में क्रम से लिखा जाता है। दर्शकों के सामने गिटार पर गाना प्रस्तुत करने के लिए यूज केस का [[उदाहरण]] निम्नलिखित है। | ||
{| class="wikitable" | {| class="wikitable" | ||
| Line 149: | Line 149: | ||
| | | | ||
|} | |} | ||
यूज केसेस उपयोगी हैं क्योंकि वे डिज़ाइन कार्य के उपयोगी फुटिंगों को आइडेंटिफाई करने में सहायता करते हैं। वे डिजाइनरों को एक्चुअल लो लेवल फुटिंग की प्रोसेसओं को देखने की अनुमति देते हैं जो निश्चित प्रॉब्लम में | यूज केसेस उपयोगी हैं क्योंकि वे डिज़ाइन कार्य के उपयोगी फुटिंगों को आइडेंटिफाई करने में सहायता करते हैं। वे डिजाइनरों को एक्चुअल लो लेवल फुटिंग की प्रोसेसओं को देखने की अनुमति देते हैं जो निश्चित प्रॉब्लम में इंक्लूड हैं, जिससे प्रॉब्लम को हैंडल करना इजी हो जाता है, क्योंकि यूजर द्वारा किए गए कुछ छोटे कदम और विवरण सामने आ जाते हैं। डिजाइनरों का कार्य इन छोटी-छोटी प्रॉब्लमओं पर विचार करना होना चाहिए जिससे फाइनल सॉल्यूशन तक पहुंच सकें। इसे कहने का दूसरा वे यह है कि यूज केसेस डिफिकल्ट टास्क को छोटे बिट्स में ब्रेक कर देते हैं, जहां ये बिट्स उपयोगी यूनिट्स हैं। प्रत्येक बिट छोटा कार्य पूर्ण करता है, जो फिर फाइनल बड़े कार्य का निर्माण करता है। कंप्यूटर पर कोड राइटिंग के प्रकार, बुनियादी छोटे पार्टों को लिखना और उन्हें कार्य पर लगाना और फिर बड़े और अधिक डिफिकल्ट कोड को समाप्त करने के लिए उन्हें एक साथ रखना सरल होता है। | ||
प्रथम सॉल्यूशन लेस रिस्की है क्योंकि यदि कोड में कुछ रॉंग होता है, तो प्रॉब्लम को छोटे बिट्स में देखना आसान होता है, क्योंकि प्रॉब्लम वाला सेगमेंट वह होगा जो कार्य नहीं करता है, जबकि पश्चात वाले सॉल्यूशन में, प्रोग्रामर को एरर फाइंड करने के लिए पूर्ण कोड को देखना पड़ सकता है, जो समय लेने वाला प्रूब होता है। यूसीडी में यूज केसेस लिखने के लिए भी यही लॉजिक होता है। अंत में, यूज केसेस उपयोगी और महत्वपूर्ण टास्क को बताते हैं जहां डिजाइनर अब देख सकते हैं कि कौन सा दूसरों की अपेक्षा अधिक महत्वपूर्ण है। लेखन यूज केसों की कुछ कमियों में यह फैक्ट | प्रथम सॉल्यूशन लेस रिस्की है क्योंकि यदि कोड में कुछ रॉंग होता है, तो प्रॉब्लम को छोटे बिट्स में देखना आसान होता है, क्योंकि प्रॉब्लम वाला सेगमेंट वह होगा जो कार्य नहीं करता है, जबकि पश्चात वाले सॉल्यूशन में, प्रोग्रामर को एरर फाइंड करने के लिए पूर्ण कोड को देखना पड़ सकता है, जो समय लेने वाला प्रूब होता है। यूसीडी में यूज केसेस लिखने के लिए भी यही लॉजिक होता है। अंत में, यूज केसेस उपयोगी और महत्वपूर्ण टास्क को बताते हैं जहां डिजाइनर अब देख सकते हैं कि कौन सा दूसरों की अपेक्षा अधिक महत्वपूर्ण है। लेखन यूज केसों की कुछ कमियों में यह फैक्ट इंक्लूड है कि एक्टर या वर्ल्ड द्वारा की गई प्रत्येक एक्शन में थोड़ा विवरण होता है, और यह छोटा सा एक्शन होती है। इससे संभवतः फरदर इमेजिनेशन और विभिन्न डिजाइनरों के एक्शन की अलग-अलग व्याख्या हो सकती है। | ||
साथ ही, इस प्रोसेस के समय, किसी टास्क को अत्यधिक सरल बनाना रियल में सरल होता है, क्योंकि किसी बड़े टास्क से प्राप्त छोटे टास्क में अभी भी मिस्ड छोटे टास्क भी | साथ ही, इस प्रोसेस के समय, किसी टास्क को अत्यधिक सरल बनाना रियल में सरल होता है, क्योंकि किसी बड़े टास्क से प्राप्त छोटे टास्क में अभी भी मिस्ड छोटे टास्क भी इंक्लूड हो सकते हैं। गिटार चुनने में यह सोचना इंक्लूड हो सकता है कि कौन सा गिटार लिया जाए, कौन सा गिटार यूजकिया जाए, और सबसे पूर्व यह सोचें कि गिटार कहाँ स्थित है। फिर इन टास्क को छोटे-छोटे टास्क में स्प्लिट किया जा सकता है, जैसे कि पूर्व यह सोचना कि गिटार का कौन सा कलर उस स्थान पर फिट होता है। टास्क को और भी छोटे टास्क में स्प्लिट किया जा सकता है, और यह डिजाइनर पर निर्भर है कि वह यह डेटरमाइन करे कि टास्क को स्प्लिट करने से रोकने के लिए उपयुक्त स्थान कौन सा है। टास्क को न केवल ओवरसिंपलीफाइड किया जा सकता है, बल्कि उन्हें पूर्ण प्रकार से छोड़ा भी जा सकता है, इस प्रकार डिज़ाइनर को यूज केसे को लिखते समय किसी इवेंट या एक्शन में इंक्लूड सभी विवरणों और सभी प्रमुख स्टेप्स के विषय में अवेयर होना चाहिए। | ||
== यह भी देखें == | == यह भी देखें == | ||
| Line 196: | Line 196: | ||
श्रेणी:यूजर-जनित सामग्री | श्रेणी:यूजर-जनित सामग्री | ||
श्रेणी:डिज़ाइन | श्रेणी:डिज़ाइन | ||
श्रेणी: | श्रेणी:यूजएबिलिटीता | ||
श्रेणी:टेक्निकल संचार | श्रेणी:टेक्निकल संचार | ||
[[Category: Machine Translated Page]] | [[Category: Machine Translated Page]] | ||
[[Category:Created On 17/08/2023]] | [[Category:Created On 17/08/2023]] | ||
Revision as of 17:08, 8 October 2023
यूजर-सेंटर्ड डिज़ाइन (यूसीडी) या यूजर-ड्रिवेन डेवलपमेंट (यूडीडी) प्रोसेस का फ्रेमवर्क है (इंटरफ़ेस या टेक्नोलॉजी तक सीमित नहीं) जिसमें यूजएबिलिटी गोल, यूजर विशेषताएँ, एनवायरनमेंट (सिस्टम), टास्क और किसी प्रोडक्ट (व्यवसाय) का वर्कफ़्लो इंक्लूड होता है। डिज़ाइन प्रोसेस के प्रत्येक स्टेज में सर्विस या प्रोसेस पर ब्रॉड ध्यान दिया जाता है। ये परीक्षण रिक्वायरमेंट्स, प्री-प्रोडक्शन मॉडल और पोस्ट प्रोडक्शन की प्रोसेस के प्रत्येक स्टेज के समय एक्चुअल यूजर्स के साथ या उनके बिना कंडक्ट किए जाते हैं, जो प्रूफ के सर्कल को पूर्ण करते हैं और यह सुनिश्चित करते हैं कि डेवलपमेंट यूजर को फोकस के केंद्र के रूप में आगे बढ़ाता है।[1][2] इस प्रकार का परीक्षण[3] आवश्यक है क्योंकि किसी प्रोडक्ट के डिज़ाइनरों के लिए सर्वप्रथम उनके डिज़ाइन अनुभवों को सरलता से समझना कठिन होता है कि प्रत्येक यूजर का लर्निंग कर्व कैसा दिख सकता है। यूजर-सेंटर्ड डिज़ाइन यूजर की अंडरस्टैंडिंग, उनकी डिमांड, प्राथमिकताओं और अनुभवों पर आधारित होता है और जब इसका उपयोग किया जाता है, तो यह प्रोडक्ट की यूजफुलनेस और यूजएबिलिटी में इनक्रीस के लिए जाना जाता है क्योंकि यह यूजर को सेटिस्फेक्शन प्रदान करता है।[4]अन्य प्रोडक्ट डिज़ाइन फिलॉसफीस से मुख्य अंतर यह है कि यूजर-सेंटर्ड डिज़ाइन प्रोडक्ट को ऑप्टिमाइज़ करने का प्रयास करता है कि यूजर प्रोडक्ट का उपयोग कैसे कर सकते हैं, या कैसे करना चाहते हैं जिससे यूजर्स को प्रोडक्ट को एकमोडेट करने के लिए अपने बिहेवियर और एक्सपेक्टेशन को परिवर्तित करने के लिए विवश न होना पड़े। इस प्रकार यूजर दो को-सेंट्रिक सर्कल्स के केंद्र में स्टैंड करते हैं। इनर सर्कल में प्रोडक्ट का कॉन्टेक्स्ट, विकसित करने के उद्देश्य और वह एनवायरनमेंट इंक्लूड है जिसमें यह रन करेगा। आउटर सर्कल में टास्क डिटेल, टास्क ऑर्गेनाइजेशन और टास्कफलो का अधिक विस्तृत विवरण इंक्लूड है।[2]
इतिहास
यूजर-सेंटर्ड डिज़ाइन शब्द 1977 में रॉब क्लिंग द्वारा दिया गया था[5] और पश्चात में कैलिफोर्निया विश्वविद्यालय, सैन डिएगो में डोनाल्ड ए. नॉर्मन की अनुसंधान प्रयोगशाला में स्वीकार किया गया। 1986 में यूजर-सेंटर्ड सिस्टम डिज़ाइन ह्यूमन-कंप्यूटर इंटरैक्शन ऑन न्यू पर्सपेक्टिव पुस्तक के प्रकाशन के परिणामस्वरूप यह कॉन्सेप्ट ब्रॉड रूप से लोकप्रिय हो गया।[6] इस कॉन्सेप्ट को नॉर्मन की पुस्तक दी डिजाइन ऑफ एवरीडे थिंग्स (मूल रूप से द साइकोलॉजी ऑफ एवरीडे थिंग्स कहा जाता है) में और अधिक स्वीकृति मिली। इस पुस्तक में, नॉर्मन उदाहरणों के माध्यम से 'गुड' और 'बैड' डिज़ाइन की फिलॉसफी का वर्णन करते हैं। वह हमारे एवरीडे लाइफ में डिजाइन के महत्व और बैड डिजाइन के कारण होने वाली एरेर के परिणामों को प्रदर्शित करता है।
दोनों पुस्तकों में उचित प्रकार से डिज़ाइन किए गए प्रोडक्टों के निर्माण के सिद्धांत इंक्लूड हैं। उनकी विशेषता एस्थेटिक्स जैसे सेकेंडरी इश्यूज के अतिरिक्त यूजर की नीड पर आधारित होती हैं। इनमें से मेन हाइलाइट्स हैं:
- टास्क के स्ट्रक्वेरिएबल को इस प्रकार सरल बनाना कि किसी भी मोमेंट पॉसिबल एक्शन इंट्यूटिव हों।
- सिस्टम के कॉन्सेप्चुअल मॉडल, टास्क, टास्क के रिजल्ट्स और फीडबैक सहित थिंग्स को विजिबल बनाएं।
- इंटेंडेड रिजल्ट्स और आवश्यक एक्शन के मध्य राइट मैपिंग प्राप्त करना।
- सिस्टम के कंस्ट्रेंट्स को एम्ब्रेस और एक्सप्लॉइट करना।
पश्चात की पुस्तक, इमोशनल डिज़ाइन में,[7] नॉर्मन अपने पूर्व विचारों को याद करके विस्तार से बताता है जो उसे अत्यधिक रिडक्टिव लगा था।
मॉडल और अप्प्रोचेस
उदाहरण के लिए, यूजर-सेंटर्ड डिज़ाइन प्रोसेस सॉफ़्टवेयर डिज़ाइनरों को अपने यूजर्स के लिए इंजीनियर्ड प्रोडक्ट के गोल को पूर्ण करने में सहायता कर सकती है। यूजर की रिक्वायरमेंट्स को प्रारम्भ से ही कंसीडर किया जाता है और पूर्ण प्रोडक्ट को सर्कल में इंक्लूड किया जाता है। इन रिक्वायरमेंट्स को इन्वेस्टिगेटिव मेथड्स के माध्यम से नोट और रिफाइन किया जाता है जिनमें एंथ्रोपोजेनिक स्टडी, कंटेक्सटुअल इन्वेस्टिगेटिव, प्रोटोटाइप परीक्षण, यूजएबिलिटी परीक्षण और अन्य विधियां इंक्लूड हैं। जनरेटिव मेथड्स का भी उपयोग किया जा सकता है जिनमें कार्ड सॉर्टिंग, एफ़िनिटी डायग्राममिंग और पार्टिसिपेटरी डिज़ाइन सेशन इंक्लूड हैं। इसके अतिरिक्त, डिज़ाइन किए जा रहे प्रोडक्ट के समान यूजएबल प्रोडक्टों के विश्लेषण से यूजर की रिक्वायरमेंट्स का अनुमान लगाया जा सकता है।
यूजर-सेंटर्ड डिज़ाइन निम्नलिखित मॉडलों से इंस्पायर होता है:
- कोऑपरेटिव डिजाइन: डिजाइनरों और यूजर्स को इक्वल फुटिंग पर इंक्लूड करना है। यह आईटी आर्टिफैक्ट्स के डिजाइन की स्कैंडिनेवियाई ट्रेडिशन है और यह 1970 से विकसित हो रही है।[8] इसे को-डिजाइन भी कहा जाता है।
- पार्टिसिपेटरी डिज़ाइन (पीडी), इसी कॉन्सेप्ट के लिए उत्तरी अमेरिकी शब्द, कोऑपरेटिव डिज़ाइन से प्रेरित, यूजर्स की पार्टिसिपेशन पर फोकस करता है। 1990 से, द्वि-वार्षिक पार्टिसिपेटरी डिज़ाइन सम्मेलन होता रहा है।[9]
- कंटेक्सटुअल डिज़ाइन, एक्चुअल कॉन्टेक्स्ट में कस्टमर-सेंटर्ड डिज़ाइन, जिसमें पार्टिसिपेटरी डिज़ाइन के कुछ आइडियाज इंक्लूड हैं[10]
यहां वे सिद्धांत दिए गए हैं जो यह सुनिश्चित करने में सहायता करते हैं कि डिज़ाइन यूजर-सेंटर्ड है:[11]
- डिज़ाइन यूजर्स, टास्क और एनवायरनमेंट की एक्सप्लिसिट अंडरस्टैंडिंग पर आधारित है।
- यूजर डिज़ाइन और डेवलपमेंट के समय इंक्लूड होते हैं।[12]
- डिज़ाइन यूजर-सेंटर्ड मूल्यांकन द्वारा ड्रिवेन और रिफाइन होता है।
- प्रोसेस इंटरैक्टिव है।
- डिज़ाइन संपूर्ण यूजर एक्सपीरियंस को एड्रेस करता है।
- डिज़ाइन टीम में मल्टीडिसीप्लिनरी स्किल और पर्सपेक्टिव इंक्लूड हैं।
यूजर-सेंटर्ड डिज़ाइन प्रोसेस
यूजर-सेंटर्ड डिज़ाइन का गोल ऐसे प्रोडक्ट बनाना है जिनकी उपयोगिता बहुत अधिक हो। इसमें यह इंक्लूड है कि प्रोडक्ट अपने उपयोग, मेनेजेबिलिटी, एफ्फेक्टिवनेस्स के कॉन्टेक्स्ट में कितना सुविधाजनक है और प्रोडक्ट यूजर की रिक्वायरमेंट्स के अनुरूप कितना उचित है। यूजर-सेंटर्ड डिज़ाइन प्रोसेस के सामान्य फेज नीचे दिए गए हैं:[13][14]
- उपयोग का कॉन्टेक्स्ट स्पेसिफाई करें: आइडेंटिफाई करें कि प्रोडक्ट के प्राइमरी यूजर कौन हैं, वे प्रोडक्ट का उपयोग क्यों करेंगे, उनकी आवश्यकताएं क्या हैं और वे किस एनवायरनमेंट में इसका उपयोग करेंगे।
- आवश्यकताएं स्पेसिफाई करें: कॉन्टेक्स्ट स्पेसिफाई हो जाने के पश्चात, प्रोडक्ट की ग्रेनुलर रिक्वायरमेंट्स को आइडेंटिफाई करने का समय होता है। यह महत्वपूर्ण स्टेज है जो डिजाइनरों को स्टोरीबोर्ड बनाने और प्रोडक्ट को सफल बनाने के लिए महत्वपूर्ण गोल सेट करने में और सुविधा प्रदान कर सकता है।
- डिज़ाइन सोलूशन्स और डेवलपमेंट: प्रोडक्ट गोल और रिक्वायरमेंट्स के आधार पर, प्रोडक्ट डिज़ाइन और डेवलपमेंट की इटरेटिव डिज़ाइन प्रोसेस प्रारम्भ करें।
- प्रोडक्ट का मूल्यांकन करें: प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के प्रत्येक स्टेज में प्रोडक्ट के लिए यूजर्स का फीडबैक प्राप्त करने के लिए यूजएबिलिटी परीक्षण करते हैं।
एबव स्टेजों में, प्रोडक्ट को और उत्तम बनाने के लिए उपरोक्त प्रोसेस रिपीट की जाती है। ये स्टेज जनरल अप्प्रोचेस और फैक्टर्स हैं जैसे डिज़ाइन गोल, टीम और उनकी टाईमलाईन, और वह एनवायरनमेंट जिसमें प्रोडक्ट विकसित किया गया है, किसी परियोजना और उनके क्रम के लिए उपयुक्त फेज निर्धारित करते हैं। आप या तो वाटरफॉल मॉडल, एजाइल मॉडल या किसी अन्य सॉफ्टवेयर इंजीनियरिंग प्रैक्टिस को फॉलो कर सकते हैं।
उद्देश्य
यूसीडी यूजर, उनके टास्क और उनके गोल्स के विषय में प्रश्न पूछता है, फिर डेवलपमेंट और डिजाइन के विषय में निर्णय लेने के लिए फाइंडिंग्स का उपयोग करता है। उदाहरण के लिए, किसी वेब साइट का यूसीडी निम्नलिखित प्रश्नों का उत्तर देना चाहता है:
- वेबसाइट के यूजर कौन हैं?
- यूजर्स के कार्य और गोल क्या हैं?
- वेबसाइट और समान वेबसाइटों के साथ यूजर्स का एक्सपीरियंस लेवल क्या है?
- यूजर्स को वेबसाइट से किन टास्क की आवश्यकता है?
- यूजर्स को किस जानकारी की आवश्यकता हो सकती है, और उन्हें इसकी किस रूप में आवश्यकता है?
- यूजर क्या सोचते हैं कि वेबसाइट को कैसे कार्य करना चाहिए?
- वे कौन से एक्सट्रीम एनवॉरमैंट्स हैं जिनमें वेबसाइट तक पहुंचा जा सकता है?
- क्या यूजर मल्टीटास्किंग है?
- क्या इंटरफ़ेस विभिन्न इनपुट मोड, जैसे टच, टच, जेस्वेरिएबल्स या ओरिएंटेशन का उपयोग करता है?
एलिमेंट्स
यूसीडी व्यूपॉइंट के उदाहरण के रूप में, किसी वेबसाइट के यूसीडी के आवश्यक एलिमेंट्स सामान्यतः विजिबिलिटी, एक्सेसिबिलिटी, लेजिबिलिटी और लैंग्वेज के विचार हैं।
विजिबिलिटी
विजिबिलिटी यूजर को डॉक्यूमेंट का मेंटल मॉडल बनाने में सहायता करती है। डॉक्यूमेंट का उपयोग करते समय मॉडल यूजर को उनके टास्क के इफेक्ट का अनुमान लगाने में सहायता करते हैं। महत्वपूर्ण एलिमेंट्स (जैसे कि वे जो मार्गफिलॉसफीस में सहायता करते हैं) एम्फैटिक होने चाहिए। यूजर्स को ग्लांस से यह बताने में सक्षम होना चाहिए कि वे डॉक्यूमेंट के साथ क्या कर सकते हैं और क्या नहीं कर सकते हैं।
एक्सेसिबिलिटी
यूजर्स को पूर्ण डॉक्यूमेंट में जानकारी शीघ्र और सरलता से ढूंढने में सक्षम होना चाहिए, चाहे उसकी लेंथ कुछ भी हो। यूजर्स को इंफॉर्मेशन फाइंड करने के विभिन्न वेज़ ऑफर की जानी चाहिए (जैसे कि नेविगेशनल एलिमेंट्स, सर्च फ़ंक्शन, टेबल ऑफ कंटेंट्स,[15] क्लीयरली लेबल्ड सेक्शन, पेज नंबर, कलर कोडिंग, आदि)। नेविगेशनल एलिमेंट्स डॉक्यूमेंट की जेनर के अनुरूप होने चाहिए। 'चंकिंग (फिलॉसफी)' उपयोगी स्ट्रेटेजी है जिसमें जानकारी को छोटे-छोटे पीसेस में ब्रेक करना इंक्लूड है जिन्हें किसी प्रकार के सार्थक क्रम या हायरार्की में ऑर्गनाइज्ड किया जा सकता है। डॉक्यूमेंट को स्किम (रीड करना) करने की क्षमता यूजर्स को पढ़ने के अतिरिक्त स्कैन करके अपनी इंफॉर्मेशन के पीसेस ढूंढने की अनुमति देती है। इसके लिए प्रायः बोल्ड अक्षरों और इटैलिक शब्दों का उपयोग किया जाता है।
लेजिबिलिटी
टेक्स्ट को रीड करना इजी होना चाहिए, रिटोरिकल सिचुएशन के विश्लेषण के माध्यम से, डिजाइनर को उपयोगी फ़ॉन्ट-फैमिली और फ़ॉन्ट जेनर निर्धारित करने में सक्षम होना चाहिए। ऑर्नामेंटल फ़ॉन्ट, सभी बड़े अक्षरों में टेक्स्ट, बड़े या छोटे मुख्य पार्ट वाले टेक्स्ट को रीड करना कठिन हो सकता है और इससे बचना चाहिए। टेक्स्ट-हैवी सिनेरियो में उपयोग किए जाने पर टेक्स्ट-कलर और बोल्डिंग सहायक हो सकते हैं। टेक्स्ट और हाई फिगर ग्राउंड कंट्रास्ट (दृष्टि) लेजिबिलिटी बढ़ाता है। लाइट बैकग्राउंड पर डार्क टेक्स्ट सबसे अधिक लीगल है।
लैंग्वेज
रिटोरिकल सिचुएशन के आधार पर, कुछ प्रकार की लैंग्वेजओं की आवश्यकता होती है। छोटे वाक्य सहायक होते हैं, जैसे वेल-रिटेन टेक्स्ट स्पष्टीकरण और बल्क-टेक्स्ट सिचुएशन में उपयोग किए जाते हैं। जब तक सिचुएशन की आवश्यकता न हो, जारगन या हैवी टेक्निकल शब्दों का प्रयोग नहीं किया जाना चाहिए। कई लेखक एक्टिव वॉइस, वर्ब्स (नाउन स्ट्रिंग्स या नॉमिनल (लैंग्वेज साइंस) के अतिरिक्त) और सरल वाक्य संरचना का उपयोग करना चूज करेंगे।
एनालिसिस टूल्स
ऐसे कई टूल्स हैं जिनका उपयोग यूजर-सेंटर्ड डिज़ाइन के एनालिसिस में किया जाता है, मुख्य रूप से: पर्सोना, सिनेरियो और आवश्यक उपयोग के केसेस है।
पर्सोना
यूसीडी प्रोसेस के समय, यूजर का रिप्रेसेंटिंग पर्सोना (यूजर एक्सपीरियंस) बनाया जा सकता है। पर्सोना (यूजर एक्सपीरियंस) यूजर आर्चटाइप है जिसका उपयोग प्रोडक्ट सुविधाओं, नेविगेशन, इंटरैक्शन और यहां तक कि विज़ुअल डिज़ाइन के विषय में निर्णय लेने में सहायता के लिए किया जाता है। अधिकतर विषयों में, पर्सोना (यूजर एक्सपीरियंस) को एक्चुअल लोगों के साथ एंथ्रोपोजेनिक की सीरीज से संश्लेषित किया जाता है, फिर 1-2 पेज के विवरणों में कैप्वेरिएबल किया जाता है जिसमें बिहेवियर पैटर्न, गोल, स्किल, ऐटिटूड और एनवायरनमेंट इंक्लूड होते हैं, जिसमें कुछ फ्रिक्शनल पर्सनल डिटेल होते हैं। पर्सोना को लाइफ दे।[16]प्रत्येक प्रोडक्ट के लिए, या कभी-कभी किसी प्रोडक्ट के अंदर टूल्स के प्रत्येक सेट के लिए, पर्सोनाों का छोटा सेट होता है, जिनमें डिज़ाइन के लिए प्राइमरी फोकस होता है। ऐसा भी होता है जिसे सेकेंडरी पर्सोना कहा जाता है, जहां कैरेक्टर डिजाइन का मेन गोल नहीं होता है, किन्तु उनकी जरूरतों को पूर्ण किया जाना चाहिए और यदि संभव हो तो प्रॉब्लमओं का सॉल्यूशन किया जाना चाहिए। वे फरदर संभावित प्रॉब्लमओं और कठिनाइयों का सॉल्यूशन करने में सहायता करने के लिए इंक्लूड हैं, प्राइमरी व्यक्ति उनके सॉल्यूशन से संतुष्ट होशेयर्ड अंडरस्टैंडिंगइस में एंटी पर्सोना भी है, जो वह कैरेक्टर है जिसके लिए डिज़ाइन विशेष रूप से नहीं बनाया गया है।
पर्सोना इस अर्थ में उपयोगी हैं कि वे यूजर समूह की सामान्य शेयर्ड अंडरस्टैंडिंग बनाते हैं जिसके आधार पर डिज़ाइन प्रोसेस बनाई जाती है। इसके अतिरिक्त, वे यूजर को क्या चाहिए और कौन से फ़ंक्शन जोड़ना और रखना अच्छा लगता है, इसका कॉन्टेक्स्ट प्रदान करके डिज़ाइन संबंधी विचारों को प्राथमिकता देने में सहायता करते हैं। वे डाइवर्सिफाइड और स्कैटर्ड यूजर समूह को ह्यूमन फेस और एक्सिस्टेंस भी प्रदान कर सकते हैं, और यूजर्स के कॉन्टेक्स्ट में कुछ सहानुभूति पैदा करने और भावनाओं को जोड़ने में सहायता कर सकते हैं। चूंकि पर्सोना कलेक्टेड डेटा से प्राइमरी स्टेकहोल्डर ग्रुप की सामान्यीकृत परसेप्शन है, इसलिए विशेषताएँ ब्रॉड और टिपिकल हो सकती हैं, या एवरेज जो की अधिक हो सकती हैं। कभी-कभी, पर्सोना में स्टीरियोटाइपिकल प्रॉपर्टीज भी हो सकती हैं, जो पूर्ण डिजाइन प्रोसेस को हर्ट कर सकते हैं। डेटा के सेट या व्यक्तियों की विस्तृत सीरीज को कॉन्टेक्स्टित करने के अतिरिक्त, पर्सोना डिज़ाइनरों द्वारा सूचित डिज़ाइन निर्णय लेने के लिए उपयोग किया जाने वाला उपयोगी टूल सकता है।
यूजर परीक्षण और चेंजिंग एनवायरनमेंट के आधार पर, किसी प्रोडक्ट के यूसीडी के माध्यम से पर्सोना (यूजर एक्सपीरियंस) को भी संशोधित किया जा सकता है। यह पर्सोना (यूजर एक्सपीरियंस) का उपयोग करने का आइडियल वे नहीं है, किन्तु इसे वर्जित भी नहीं किया जाना चाहिए, विशेषकर जब यह स्पष्ट हो जाता है कि डिज़ाइन प्रारम्भ होने के पश्चात से किसी प्रोडक्ट के डेवलपमेंट के आसपास के वेरिएबल चेंज हो गए हैं और एवरीडे पर्सोना (यूजर एक्सपीरियंस) | पर्सोना नहीं हो सकते हैं चेंज हुई प्री सिचुएशन को बेस्ट प्रकार से पूर्ण करें।
सिनेरियो
यूसीडी प्रोसेस में बनाया गया सिनेरियो के मेन कैरेक्टर के रूप में प्राइमरी स्टेकहोल्डर ग्रु के साथ रियल लाइफ या इवेंटओं के अनुक्रम के विषय में फ्रिक्शनल स्टोरी है। सामान्यतः, पर्सोना जो पूर्व बनाया गया था उसे इस स्टोरी के मेन कैरेक्टर के रूप में उपयोग किया जाता है। स्टोरी उन इवेंटओं के विषय में टिपिकल होनी चाहिए जो प्राइमरी स्टेकहोल्डर ग्रुप की प्रॉब्लमओं से संबंधित हों, और सामान्यतः मुख्य रिसर्च प्रश्न जिन पर डिज़ाइन प्रोसेस बनी होती है। ये किसी व्यक्ति के रियल लाइफ के विषय में साधारण स्टोरी बन सकती हैं, किन्तु इवेंटओं के छोटे विवरणों में यूजर्स के विषय में विवरण इंक्लूड होना चाहिए, और इसमें इमोशनल या फिजिकल विशेषताएं इंक्लूड हो सकती हैं। सबसे बेस्ट सिचुएशन हो सकती है, जहां मेन कैरेक्टर के लिए सब कुछ सबसे बेस्ट कार्य करता है, सबसे बैड सिचुएशन, जहां मेन कैरेक्टर अपने आस-पास सब कुछ रॉंग होने का अनुभव करता है, और एवरेज- सिचुएशन सिनेरियो, जो सामान्य लाइफ है व्यक्ति का, जहां रियल में कुछ भी विशेष या रियल में निराशाजनक नहीं होता है, और दिन यूं ही बीत जाता है।
सिनेरियो सोशल कॉन्टेक्स्ट बनाते हैं जिसमें व्यक्ति इंक्लूड होते हैं, और कलेक्टेड डेटा से इनर विशेषताओं वाले कैरेक्टर की इमेजिनेशन करने के अतिरिक्त एक्चुअल फिजिकल वर्ल्ड भी बनाते हैं और कुछ नहीं; पर्सोना के एक्सिस्टेंस में अधिक एक्शन इंक्लूड है। किसी सिनेरियो को लोग अधिक इजली समझ पाते हैं, क्योंकि यह स्टोरी के रूप में होता है और इसका अनुसरण करना आसान होता है। फिर भी, व्यक्तियों की प्रकार, ये सिनेरियो रिसर्चेस और डिजाइनर द्वारा बनाई गई परसेप्शन हैं, और ऑर्गनाइज्ड डेटा के सेट से भी बनाए गए हैं। यह सुनिश्चित करना महत्वपूर्ण है कि सिनेरियो यथासंभव एक्चुअल विश्व सिनेरियो के करीब बनाए जाएं। फिर भी, कभी-कभी यह समझाना और सूचित करना मुश्किल हो सकता है कि लो लेवल फुटिंग के कार्य कैसे होते हैं, उदाहरण के लिए- कार्य करने से पूर्व किसी व्यक्ति की विचार प्रोसेस है।
यूज केस
संक्षेप में, यूज केस व्यक्ति और वर्ल्ड के मध्य इंटरेक्शन का वर्णन करता है। प्रत्येक यूज केस ऐसी इवेंट का वर्णन करता है जो रियल लाइफ में थोड़े समय के लिए ऑक्कर हो सकती है, किन्तु इसमें एक्टर और वर्ल्ड के मध्य डिफिकल्ट विवरण और इंटरेक्शन इंक्लूड हो सकती है। इसे कारण और इफेक्ट योजना के रूप में कैरेक्टर के लिए अपने गोल को प्राप्त करने के लिए सरल स्टेजों की सीरीज के रूप में दर्शाया गया है। यूज केस सामान्यतः दो कॉलम वाले चार्ट के रूप में लिखे जाते हैं: पूर्व कॉलम में एक्टर का लेबल होता है, दूसरे कॉलम में वर्ल्ड का लेबल होता है, और प्रत्येक साइड द्वारा किए गए टास्क को संबंधित कॉलम में क्रम से लिखा जाता है। दर्शकों के सामने गिटार पर गाना प्रस्तुत करने के लिए यूज केस का उदाहरण निम्नलिखित है।
| एक्टर | वर्ल्ड |
|---|---|
| बजाने के लिए संगीत चुनें | |
| गिटार उठाओ | |
| डिस्प्ले शीट संगीत | |
| गिटार का उपयोग करके शीट संगीत पर प्रत्येक नोट का प्रदर्शन करें | |
| ध्वनि का उपयोग करके दर्शकों तक नोट पहुँचाएँ | |
| दर्शक कलाकार को प्रतिएक्शन प्रदान करते हैं | |
| प्रदर्शन का आकलन करें और दर्शकों की प्रतिएक्शन के आधार पर आवश्यकतानुसार समायोजन करें | |
| आवश्यक समायोजन के साथ पूरा गाना | |
| दर्शकों की तालियाँ |
एक्टर और वर्ल्ड के मध्य की इंटरेक्शन ऐसा कार्य है जिसे एवरीडे लाइफ में देखा जा सकता है, और हम इसे सामान्य रूप से लेते हैं और संगीत के टुकड़े को प्रस्तुत करने जैसे कार्य के लिए होने वाली छोटी-छोटी बातों के विषय में एक्सिस्टेंस के लिए अधिक नहीं सोचते हैं। यह इस फैक्ट के समान है कि अपनी मदरलैंग्वेज बोलते समय, हम व्याकरण और शब्दों को कैसे वाक्यांशबद्ध करें, इसके विषय में बहुत अधिक नहीं सोचते हैं; वे बस बाहर आ जाते हैं क्योंकि हम उन्हें कहने के इतने आदी हो गए हैं। इस विषय में एक्टर और वर्ल्ड, विशेष रूप से, प्राइमरी स्टेकहोल्डर (यूजर) और वर्ल्ड के मध्य की गतिविधियों के विषय में विस्तार से सोचा जाना चाहिए, और इसलिए यह समझने के लिए यूज केसेस बनाए जाते हैं कि ये छोटी इंटरेक्शन कैसे होती हैं।
आवश्यक यूज केस विशेष प्रकार का यूज केस है, जिसे एब्सट्रैक्ट यूज केस भी कहा जाता है। आवश्यक यूज केसेस प्रॉब्लम के एसेंस का वर्णन करते हैं, और प्रॉब्लम की नेचर से ही संबंधित होते हैं। आवश्यक यूज केसेस लिखते समय, असंबद्ध विवरणों के विषय में कोई परसेप्शन नहीं बनाई जानी चाहिए। इसके अतिरिक्त, उस गोल तक पहुंचने के लिए विषय के गोल्स को प्रोसेस और इम्प्लीमेंटेशन से सेपरेट किया जाना चाहिए। नीचे उदाहरण के समान गोल के साथ आवश्यक यूज केसेस का उदाहरण दिया गया है।
| एक्टर | वर्ल्ड |
|---|---|
| प्रदर्शन के लिए शीट संगीत चुनें | |
| आवश्यक संसाधन एकत्रित करता है | |
| संसाधनों तक पहुंच प्रदान करता है | |
| टुकड़े को क्रमिक रूप से निष्पादित करता है | |
| प्रदर्शन को संप्रेषित और व्याख्या करना | |
| प्रतिएक्शन प्रदान करता है | |
| प्रदर्शन पूरा करता है |
यूज केसेस उपयोगी हैं क्योंकि वे डिज़ाइन कार्य के उपयोगी फुटिंगों को आइडेंटिफाई करने में सहायता करते हैं। वे डिजाइनरों को एक्चुअल लो लेवल फुटिंग की प्रोसेसओं को देखने की अनुमति देते हैं जो निश्चित प्रॉब्लम में इंक्लूड हैं, जिससे प्रॉब्लम को हैंडल करना इजी हो जाता है, क्योंकि यूजर द्वारा किए गए कुछ छोटे कदम और विवरण सामने आ जाते हैं। डिजाइनरों का कार्य इन छोटी-छोटी प्रॉब्लमओं पर विचार करना होना चाहिए जिससे फाइनल सॉल्यूशन तक पहुंच सकें। इसे कहने का दूसरा वे यह है कि यूज केसेस डिफिकल्ट टास्क को छोटे बिट्स में ब्रेक कर देते हैं, जहां ये बिट्स उपयोगी यूनिट्स हैं। प्रत्येक बिट छोटा कार्य पूर्ण करता है, जो फिर फाइनल बड़े कार्य का निर्माण करता है। कंप्यूटर पर कोड राइटिंग के प्रकार, बुनियादी छोटे पार्टों को लिखना और उन्हें कार्य पर लगाना और फिर बड़े और अधिक डिफिकल्ट कोड को समाप्त करने के लिए उन्हें एक साथ रखना सरल होता है।
प्रथम सॉल्यूशन लेस रिस्की है क्योंकि यदि कोड में कुछ रॉंग होता है, तो प्रॉब्लम को छोटे बिट्स में देखना आसान होता है, क्योंकि प्रॉब्लम वाला सेगमेंट वह होगा जो कार्य नहीं करता है, जबकि पश्चात वाले सॉल्यूशन में, प्रोग्रामर को एरर फाइंड करने के लिए पूर्ण कोड को देखना पड़ सकता है, जो समय लेने वाला प्रूब होता है। यूसीडी में यूज केसेस लिखने के लिए भी यही लॉजिक होता है। अंत में, यूज केसेस उपयोगी और महत्वपूर्ण टास्क को बताते हैं जहां डिजाइनर अब देख सकते हैं कि कौन सा दूसरों की अपेक्षा अधिक महत्वपूर्ण है। लेखन यूज केसों की कुछ कमियों में यह फैक्ट इंक्लूड है कि एक्टर या वर्ल्ड द्वारा की गई प्रत्येक एक्शन में थोड़ा विवरण होता है, और यह छोटा सा एक्शन होती है। इससे संभवतः फरदर इमेजिनेशन और विभिन्न डिजाइनरों के एक्शन की अलग-अलग व्याख्या हो सकती है।
साथ ही, इस प्रोसेस के समय, किसी टास्क को अत्यधिक सरल बनाना रियल में सरल होता है, क्योंकि किसी बड़े टास्क से प्राप्त छोटे टास्क में अभी भी मिस्ड छोटे टास्क भी इंक्लूड हो सकते हैं। गिटार चुनने में यह सोचना इंक्लूड हो सकता है कि कौन सा गिटार लिया जाए, कौन सा गिटार यूजकिया जाए, और सबसे पूर्व यह सोचें कि गिटार कहाँ स्थित है। फिर इन टास्क को छोटे-छोटे टास्क में स्प्लिट किया जा सकता है, जैसे कि पूर्व यह सोचना कि गिटार का कौन सा कलर उस स्थान पर फिट होता है। टास्क को और भी छोटे टास्क में स्प्लिट किया जा सकता है, और यह डिजाइनर पर निर्भर है कि वह यह डेटरमाइन करे कि टास्क को स्प्लिट करने से रोकने के लिए उपयुक्त स्थान कौन सा है। टास्क को न केवल ओवरसिंपलीफाइड किया जा सकता है, बल्कि उन्हें पूर्ण प्रकार से छोड़ा भी जा सकता है, इस प्रकार डिज़ाइनर को यूज केसे को लिखते समय किसी इवेंट या एक्शन में इंक्लूड सभी विवरणों और सभी प्रमुख स्टेप्स के विषय में अवेयर होना चाहिए।
यह भी देखें
- एक्शन रिसर्च
- एक्टिविटी-सेंटर्ड डिज़ाइन
- अटेंटिव यूजर इंटरफेस
- चीफ एक्सपीरियंस ऑफिसर (सीएक्सओ)
- कंटेंट बेस्ड यूजएबिलिटी टेस्टिंग
- कंटेक्सटुअल इन्क्वायरी
- डिज़ाइन थिंकिंग
- एम्पथेटिक डिज़ाइन
- ह्यूमन सेंटर्ड कंप्यूटिंग
- ह्यूमन सेंटर्ड सिस्टम
- ह्यूमन सेंटर्ड डिज़ाइन
- ह्यूमन एक्सपीरियंस डिज़ाइन
- इनफार्मेशन आर्किटेक्चर
- इंटरेक्शन डिज़ाइन
- मेटा-डिज़ाइन
- पेपर प्रोटोटाइप
- पार्टिसिपेटरी डिज़ाइन
- प्रोसेस सेंटर्ड डिज़ाइन
- थानाटोसेंसिटिविटी
- ट्रांसजेनरेशनल डिज़ाइन
- यूबीक्विटॉस कंप्यूटिंग
- यूजएबिलिटी
- वर्ल्ड यूजएबिलिटी डे
कॉन्टेक्स्ट
- ↑ "Cover – Just Ask: Integrating Accessibility Throughout Design". uiaccess.com.
- ↑ 2.0 2.1 "उपयोगकर्ता केंद्रित डिज़ाइन प्रक्रिया (यूसीडी) पर नोट्स". www.w3.org.
- ↑ Rubin, Jeffrey; Chisnell, Dana (10 March 2011). Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests (in English). John Wiley & Sons. ISBN 978-1-118-08040-5.
- ↑ Vredenburg, Karel; Mao, Ji-Ye; Smith, Paul; Carey, Tom (2002). "उपयोगकर्ता-केंद्रित डिज़ाइन अभ्यास का एक सर्वेक्षण" (PDF).
- ↑ Kling, Rob (1977). "उपयोगकर्ता-केंद्रित सॉफ़्टवेयर डिज़ाइन का संगठनात्मक संदर्भ". MIS Quarterly. 1 (4): 41–52. doi:10.2307/249021. ISSN 0276-7783. JSTOR 249021.
- ↑ Norman, D. A. (1986). User-Centered System Design: New Perspectives on Human-Computer Interaction.
- ↑ "Don Norman (2003) Emotional Design, Prolog-- Three Teapots" (PDF). jnd.org.
- ↑ Greenbaum&Kyng (eds): Design At Work – Cooperative design of Computer Systems, Lawrence Erlbaum 1991
- ↑ Schuler & Namioka (1993). Participatory Design, Lawrence Erlbaum; and chapter 11 in Helander's Handbook of HCI, Elsevier, 1997.
- ↑ Beyer & Holtzblatt (1998). Contextual Design, Kaufmann.
- ↑ "उपयोगकर्ता-केंद्रित डिज़ाइन मूल बातें". www.usability.gov.
- ↑ Mathur, Sunita; Janaudis‐Ferreira, Tania; Hemphill, Julia; Cafazzo, Joseph A.; Hart, Donna; Holdsworth, Sandra; Lovas, Mike; Wickerson, Lisa (2021-09-23). "User‐centered design features for digital health applications to support physical activity behaviors in solid organ transplant recipients: A qualitative study". Clinical Transplantation (in English). 35 (12): e14472. doi:10.1111/ctr.14472. ISSN 0902-0063. PMID 34510558. S2CID 237492723.
- ↑ "उपयोगकर्ता केंद्रित डिज़ाइन प्रक्रिया (यूसीडी) पर नोट्स". www.w3.org. Retrieved 30 March 2017.
- ↑ "उपयोगकर्ता-केंद्रित डिज़ाइन मूल बातें". www.usability.gov. Retrieved 30 March 2017.
- ↑ Aaron, Scharf (1976). A new beginning: primitivism and science in post-impressionist art; [and] Returnto nature. Open University. ISBN 0-335-05151-0. OCLC 1086245904.
- ↑ "अपने व्यक्तित्व को परिपूर्ण बनाना". www.cooper.com. Retrieved 2016-01-06.
अग्रिम पठन
- ISO 13407:1999 Human-centred design processes for interactive systems
- ISO 9241-210:2010 Ergonomics of human-system interaction -- Part 210: Human-centred design for interactive systems
वीडियो
- human_centered_design?langage=en ह्यूमन सेंटर्ड डिज़ाइन, आईडीईओ के डेविड केली
- यूजर सेंटर्ड डिज़ाइन, डॉन नॉर्मन
श्रेणी:ह्यूमन-कंप्यूटर संपर्क श्रेणी:यूजर-जनित सामग्री श्रेणी:डिज़ाइन श्रेणी:यूजएबिलिटीता श्रेणी:टेक्निकल संचार
