यूजर-सेंटर्ड डिज़ाइन: Difference between revisions
No edit summary |
m (24 revisions imported from alpha:यूजर-सेंटर्ड_डिज़ाइन) |
||
| (14 intermediate revisions by 3 users not shown) | |||
| 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> और पश्चात में कैलिफोर्निया | यूजर-सेंटर्ड डिज़ाइन शब्द 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> | ||
# उपयोग का कॉन्टेक्स्ट स्पेसिफाई करें | # '''उपयोग का कॉन्टेक्स्ट स्पेसिफाई करना:''' आइडेंटिफाई करें कि प्रोडक्ट के प्राइमरी यूजर कौन हैं, वे प्रोडक्ट का उपयोग क्यों करेंगे, उनकी आवश्यकताएं क्या हैं और वे किस एनवायरनमेंट में इसका उपयोग करेंगे। | ||
# | # '''आवश्यकताएँ निर्दिष्ट करना:''' कॉन्टेक्स्ट स्पेसिफाई हो जाने के पश्चात, प्रोडक्ट की ग्रेनुलर रिक्वायरमेंट्स को आइडेंटिफाई करने का समय होता है। यह महत्वपूर्ण स्टेज है जो डिजाइनरों को स्टोरीबोर्ड बनाने और प्रोडक्ट को सफल बनाने के लिए महत्वपूर्ण गोल सेट करने में और सुविधा प्रदान कर सकता है। | ||
# डिज़ाइन सोलूशन्स और | # '''डिज़ाइन सोलूशन्स और डेवलपमेंट:''' प्रोडक्ट गोल और रिक्वायरमेंट्स के आधार पर, प्रोडक्ट डिज़ाइन और डेवलपमेंट की इटरेटिव डिज़ाइन प्रोसेस प्रारम्भ करना। | ||
# प्रोडक्ट का मूल्यांकन | # '''प्रोडक्ट का मूल्यांकन''' '''करना''': प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के प्रत्येक स्टेज में प्रोडक्ट के लिए यूजर्स का फीडबैक प्राप्त करने के लिए यूजएबिलिटी टेस्टिंग करते हैं। | ||
एबव स्टेजों में, प्रोडक्ट को और उत्तम बनाने के लिए उपरोक्त | एबव स्टेजों में, प्रोडक्ट को और उत्तम बनाने के लिए उपरोक्त प्रोसेस रिपीट किया जाता है। ये स्टेज जनरल अप्प्रोचेस और फैक्टर्स हैं जैसे डिज़ाइन गोल, टीम और उनकी टाईमलाईन, और वह एनवायरनमेंट जिसमें प्रोडक्ट विकसित किया गया है, किसी परियोजना और उनके क्रम के लिए उपयुक्त फेज निर्धारित करते हैं। आप या तो [[झरना मॉडल|वाटरफॉल मॉडल]], एजाइल मॉडल या किसी अन्य [[सॉफ्टवेयर इंजीनियरिंग]] प्रैक्टिस को फॉलो कर सकते हैं। | ||
== उद्देश्य == | == उद्देश्य == | ||
यूसीडी यूजर, उनके टास्क और | यूसीडी यूजर, उनके टास्क और गोल्स के विषय में प्रश्न पूछता है, फिर डेवलपमेंट और डिजाइन के विषय में निर्णय लेने के लिए फाइंडिंग्स का उपयोग करता है। उदाहरण के लिए, किसी वेब साइट का यूसीडी निम्नलिखित प्रश्नों का उत्तर देना चाहता है: | ||
* वेबसाइट के यूजर कौन हैं? | * वेबसाइट के यूजर कौन हैं? | ||
* | * यूजर्स के कार्य और गोल क्या हैं? | ||
* वेबसाइट और समान वेबसाइटों के साथ | * वेबसाइट और समान वेबसाइटों के साथ यूजर्स का एक्सपीरियंस लेवल क्या है? | ||
* | * यूजर्स को वेबसाइट से किन टास्क की आवश्यकता है? | ||
* | * यूजर्स को किस इनफार्मेशन की आवश्यकता हो सकती है, और उन्हें इसकी किस फॉर्म में आवश्यकता है? | ||
* यूजर क्या सोचते हैं कि वेबसाइट को कैसे कार्य करना चाहिए? | * यूजर क्या सोचते हैं कि वेबसाइट को कैसे कार्य करना चाहिए? | ||
* वे कौन से एक्सट्रीम एनवॉरमैंट्स हैं जिनमें वेबसाइट तक | * वे कौन से एक्सट्रीम एनवॉरमैंट्स हैं जिनमें वेबसाइट तक एक्सेस किया जा सकता है? | ||
* क्या यूजर मल्टीटास्किंग है? | * क्या यूजर मल्टीटास्किंग है? | ||
* क्या इंटरफ़ेस विभिन्न इनपुट मोड, जैसे टच, | * क्या इंटरफ़ेस विभिन्न इनपुट मोड, जैसे टच, स्पीच, जेस्चर या ओरिएंटेशन का उपयोग करता है? | ||
== एलिमेंट्स == | == एलिमेंट्स == | ||
यूसीडी व्यूपॉइंट के उदाहरण के रूप में, किसी वेबसाइट के यूसीडी के आवश्यक एलिमेंट्स सामान्यतः विजिबिलिटी, एक्सेसिबिलिटी, लेजिबिलिटी और लैंग्वेज | यूसीडी व्यूपॉइंट के उदाहरण के रूप में, किसी वेबसाइट के यूसीडी के आवश्यक एलिमेंट्स सामान्यतः विजिबिलिटी, एक्सेसिबिलिटी, लेजिबिलिटी और लैंग्वेज का कन्सिडरेशन हैं। | ||
=== [[दृश्यता|विजिबिलिटी]] === | === [[दृश्यता|विजिबिलिटी]] === | ||
विजिबिलिटी यूजर को डॉक्यूमेंट का [[मानसिक मॉडल|मेंटल मॉडल]] बनाने में सहायता करती है। डॉक्यूमेंट का उपयोग करते समय मॉडल यूजर को उनके टास्क के इफेक्ट का अनुमान लगाने में सहायता करते हैं। महत्वपूर्ण एलिमेंट्स (जैसे कि वे जो [[ मार्गदर्शन |मार्गफिलॉसफीस]] में सहायता करते हैं) एम्फैटिक होने चाहिए। | विजिबिलिटी यूजर को डॉक्यूमेंट का [[मानसिक मॉडल|मेंटल मॉडल]] बनाने में सहायता करती है। डॉक्यूमेंट का उपयोग करते समय मॉडल यूजर को उनके टास्क के इफेक्ट का अनुमान लगाने में सहायता करते हैं। महत्वपूर्ण एलिमेंट्स (जैसे कि वे जो [[ मार्गदर्शन |मार्गफिलॉसफीस]] में सहायता करते हैं) एम्फैटिक होने चाहिए। यूजर्स को सिंगल ग्लांस से यह बताने में सक्षम होना चाहिए कि वे डॉक्यूमेंट के साथ क्या कर सकते हैं और क्या नहीं कर सकते हैं। | ||
=== एक्सेसिबिलिटी === | === एक्सेसिबिलिटी === | ||
यूजर्स को डॉक्यूमेंट में इनफार्मेशन को शीघ्रता और सरलता से फाइंड करने में सक्षम होना चाहिए, रिगार्डलेस उसकी लेंथ कुछ भी हो। यूजर्स को इंफॉर्मेशन फाइंड करने के विभिन्न वेज़ ऑफर किया जाना चाहिए (जैसे कि नेविगेशनल एलिमेंट्स, सर्च फ़ंक्शन, टेबल ऑफ कंटेंट्स,<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> क्लीयरली लेबल्ड सेक्शन, पेज नंबर, [[रंग कोडिंग|कलर कोडिंग]], आदि)। नेविगेशनल एलिमेंट्स डॉक्यूमेंट की [[शैली|जेनर]] के अनुरूप होने चाहिए। '[[चंकिंग (मनोविज्ञान)|चंकिंग (फिलॉसफी)]]' उपयोगी स्ट्रेटेजी है जिसमें इनफार्मेशन को छोटे-छोटे पीसेस में ब्रेक करना इंक्लूड है जिन्हें किसी प्रकार के मीनिंगफुल आर्डर या [[पदानुक्रम|हायरार्की]] में ऑर्गनाइज्ड किया जा सकता है। डॉक्यूमेंट को [[स्किमिंग (पढ़ना)|स्किम (रीड)]] करने की क्षमता यूजर्स को रीड के अतिरिक्त स्कैन करके अपनी इंफॉर्मेशन के पीसेस को फाइंड करने की अनुमति देती है। इसके लिए प्रायः [[ बोल्ड अक्षरों |बोल्ड लेटर्स]] और [[इटैलिक प्रकार|इटैलिक]] शब्दों का उपयोग किया जाता है। | |||
=== लेजिबिलिटी === | === लेजिबिलिटी === | ||
टेक्स्ट को रीड करना इजी होना चाहिए, रिटोरिकल सिचुएशन के विश्लेषण के माध्यम से, डिजाइनर को उपयोगी [[फ़ॉन्ट]]-फैमिली और फ़ॉन्ट जेनर | टेक्स्ट को रीड करना इजी होना चाहिए, रिटोरिकल सिचुएशन के विश्लेषण के माध्यम से, डिजाइनर को उपयोगी [[फ़ॉन्ट]]-फैमिली और फ़ॉन्ट जेनर डेटरमाइन करने में सक्षम होना चाहिए। ऑर्नामेंटल फ़ॉन्ट, सभी [[बड़े अक्षर|कैपिटल लेटर्स]] में टेक्स्ट, बड़े या छोटे मेन पार्ट वाले टेक्स्ट को रीड करना कठिन हो सकता है और इससे बचना चाहिए। टेक्स्ट-हैवी सिनेरियो में उपयोग किए जाने पर टेक्स्ट-कलर और बोल्डिंग सहायक हो सकते हैं। टेक्स्ट और हाई फिगर ग्राउंड [[कंट्रास्ट (दृष्टि)]] लेजिबिलिटी बढ़ाता है। लाइट बैकग्राउंड पर डार्क टेक्स्ट सबसे अधिक लीगल है। | ||
=== लैंग्वेज === | === लैंग्वेज === | ||
रिटोरिकल सिचुएशन के आधार पर, कुछ प्रकार की लैंग्वेजओं की आवश्यकता होती है। छोटे वाक्य सहायक होते हैं, जैसे वेल-रिटेन टेक्स्ट | रिटोरिकल सिचुएशन के आधार पर, कुछ प्रकार की लैंग्वेजओं की आवश्यकता होती है। छोटे वाक्य सहायक होते हैं, जैसे वेल-रिटेन टेक्स्ट एक्सप्लेनेशन और बल्क-टेक्स्ट सिचुएशन में उपयोग किए जाते हैं। जब तक सिचुएशन की आवश्यकता न हो, [[शब्दजाल|जारगन]] या हैवी टेक्निकल शब्दों का प्रयोग नहीं किया जाना चाहिए। कई लेखक [[सक्रिय आवाज|एक्टिव वॉइस]], वर्ब्स ([[संज्ञा वाक्यांश|नाउन स्ट्रिंग्स]] या [[नाममात्र (भाषाविज्ञान)|नॉमिनल (लैंग्वेज साइंस)]] के अतिरिक्त) और सिंपल सेंटेंस स्ट्रक्चर का उपयोग करना चूज करते है। | ||
== एनालिसिस टूल्स == | == एनालिसिस टूल्स == | ||
ऐसे कई टूल्स हैं जिनका उपयोग यूजर-सेंटर्ड डिज़ाइन के एनालिसिस में किया जाता है, मुख्य रूप से: पर्सोना, सिनेरियो और | ऐसे कई टूल्स हैं जिनका उपयोग यूजर-सेंटर्ड डिज़ाइन के एनालिसिस में किया जाता है, मुख्य रूप से: पर्सोना, सिनेरियो और एसेंशियल यूज केस है। | ||
=== पर्सोना === | === पर्सोना === | ||
यूसीडी | यूसीडी प्रोसेस के समय, यूजर का [[व्यक्तित्व (उपयोगकर्ता अनुभव)|पर्सोना (यूजर एक्सपीरियंस)]] रिप्रेसेंटिंग बनाया जा सकता है। पर्सोना (यूजर एक्सपीरियंस) यूजर आर्चटाइप है जिसका उपयोग प्रोडक्ट सुविधाओं, नेविगेशन, इंटरैक्शन और यहां तक कि विज़ुअल डिज़ाइन के विषय में निर्णय लेने में सहायता के लिए किया जाता है। अधिकतर विषयों में, पर्सोना (यूजर एक्सपीरियंस) को रियल लोगों के साथ [[नृवंशविज्ञान|एंथ्रोपोजेनिक]] की सीरीज से सिंथेसाइज किया जाता है, फिर 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" | ||
|- | |- | ||
! | ! एक्टर | ||
! | ! वर्ल्ड | ||
|- | |- | ||
| | | प्ले करने के लिए म्यूजिक का चयन करना | ||
| | | | ||
|- | |- | ||
| | | गिटार उठाए | ||
| | | | ||
|- | |- | ||
| | | | ||
| | | डिस्प्ले शीट म्यूजिक | ||
|- | |- | ||
| | | गिटार का उपयोग करके शीट म्यूजिक पर प्रत्येक नोट का परफॉरमेंस करना | ||
| | | | ||
|- | |- | ||
| | | | ||
| | | साउंड का उपयोग करके ऑडियंस तक नोट पहुँचाएँ | ||
|- | |- | ||
| | | | ||
| | | ऑडियंस परफ़ॉर्मर को फीडबैक प्रदान करते हैं | ||
|- | |- | ||
| | | परफॉरमेंस का आकलन करना और ऑडियंस के फीडबैक के आधार पर एडजस्ट करें | ||
| | | | ||
|- | |- | ||
| | | रिक्वायर्ड एडजस्टमेंट के साथ पूर्ण म्यूजिक | ||
| | | | ||
|- | |- | ||
| | | | ||
| | | ऑडियंस अप्लॉज़ | ||
|} | |} | ||
एक्टर और वर्ल्ड के मध्य की इंटरेक्शन ऐसा कार्य है जिसे एवरीडे लाइफ में देखा जा सकता है, और हम इसे सामान्य रूप से लेते हैं और म्यूजिक के पार्ट्स को प्रस्तुत करने जैसे कार्य के लिए होने वाली छोटी-छोटी बातों के विषय में एक्सिस्टेंस के लिए अधिक नहीं सोचते हैं। यह इस फैक्ट के समान है कि अपनी मदरलैंग्वेज बोलते समय, हम ग्रामर और वर्ड्स को कैसे फ्रेस करें, इसके विषय में अधिक नहीं सोचते हैं; वे बस बाहर आ जाते हैं क्योंकि हम उन्हें कहने के इतने अकस्टोमेड हो गए हैं। इस विषय में एक्टर और वर्ल्ड, विशेष रूप से, प्राइमरी स्टेकहोल्डर (यूजर) और वर्ल्ड के मध्य की गतिविधियों के विषय में विस्तार से सोचा जाना चाहिए, और इसलिए यह समझने के लिए यूज केसेस बनाए जाते हैं कि ये छोटी इंटरेक्शन कैसे होती हैं। | |||
आवश्यक यूज केस विशेष प्रकार का यूज केस है, जिसे एब्सट्रैक्ट यूज केस भी कहा जाता है। आवश्यक यूज केसेस प्रॉब्लम के एसेंस का वर्णन करते हैं, और प्रॉब्लम नेचर से ही संबंधित होते हैं। आवश्यक यूज केसेस लिखते समय, असंबद्ध विवरणों के विषय में कोई परसेप्शन नहीं बनाई जानी चाहिए। इसके अतिरिक्त, उस गोल तक पहुंचने के लिए विषय के गोल्स को प्रोसेस और इम्प्लीमेंटेशन से सेपरेट किया जाना चाहिए। नीचे उदाहरण के समान गोल के साथ आवश्यक यूज केसेस का उदाहरण दिया गया है। | |||
{| class="wikitable" | {| class="wikitable" | ||
! | ! एक्टर | ||
! | ! वर्ल्ड | ||
|- | |- | ||
| | | पर्फोर्मस के लिए शीट म्यूजिक का चयन करें | ||
| | | | ||
|- | |- | ||
| | | नेसेसरी रिसोर्सेज एकत्रित करता है | ||
| | | | ||
|- | |- | ||
| | | | ||
| | | रिसोर्सेज तक पहुंच प्रदान करता है | ||
|- | |- | ||
| | | पर्फोर्मस पीस सेक़ुएनसली | ||
| | | | ||
|- | |- | ||
| | | | ||
| | | पर्फोर्मस को इंटरपेट और कन्वे करना | ||
|- | |- | ||
| | | | ||
| | | फीडबैक प्रदान करता है | ||
|- | |- | ||
| | | पर्फोर्मस पूर्ण करता है | ||
| | | | ||
|} | |} | ||
यूज केसेस उपयोगी हैं क्योंकि वे डिज़ाइन कार्य के उपयोगी फुटिंगों को आइडेंटिफाई करने में सहायता करते हैं। वे डिजाइनरों को एक्चुअल लो लेवल फुटिंग की प्रोसेस को देखने की अनुमति देते हैं जो निश्चित प्रॉब्लम में इंक्लूड हैं, जिससे प्रॉब्लम को हैंडल करना इजी हो जाता है, क्योंकि यूजर द्वारा किए गए कुछ छोटे फेज और विवरण सामने आ जाते हैं। डिजाइनरों का कार्य इन छोटी-छोटी प्रॉब्लम्स पर विचार करना चाहिए जिससे फाइनल सॉल्यूशन तक पहुंच सकें। इसे कहने का दूसरा वे यह है कि यूज केसेस डिफिकल्ट टास्क को छोटे बिट्स में ब्रेक कर देते हैं, जहां ये बिट्स उपयोगी यूनिट्स हैं। प्रत्येक बिट छोटा कार्य पूर्ण करता है, जो फिर फाइनल बड़े कार्य का निर्माण करता है। कंप्यूटर पर कोड राइटिंग के प्रकार, बेसिक छोटे पार्टों को राइट करना और उन्हें कार्य पर लगाना और फिर बड़े और अधिक डिफिकल्ट कोड को समाप्त करने के लिए उन्हें एक साथ रखना सरल होता है। | |||
प्रथम सॉल्यूशन लेस रिस्की है क्योंकि यदि कोड में कुछ रॉंग होता है, तो प्रॉब्लम को छोटे बिट्स में देखना सरल होता है, क्योंकि प्रॉब्लम वाला सेगमेंट वह होगा जो कार्य नहीं करता है, जबकि पश्चात वाले सॉल्यूशन में, प्रोग्रामर को एरर फाइंड करने के लिए पूर्ण कोड को देखना पड़ सकता है, जो समय लेने वाला प्रूब होता है। यूसीडी में यूज केसेस राइट करने के लिए भी यही लॉजिक होता है। अंत में, यूज केसेस उपयोगी और महत्वपूर्ण टास्क को बताते हैं जहां डिजाइनर अब देख सकते हैं कि कौन सा दूसरों की अपेक्षा अधिक महत्वपूर्ण है। लेखन यूज केसों की कुछ कमियों में यह फैक्ट इंक्लूड है कि एक्टर या वर्ल्ड द्वारा की गई प्रत्येक एक्शन में थोड़ा विवरण होता है, और यह छोटा सा एक्शन होता है। इससे संभवतः फरदर इमेजिनेशन और विभिन्न डिजाइनरों के एक्शन की भिन्न-भिन्न व्याख्या हो सकती है। | |||
साथ ही, इस | साथ ही, इस प्रोसेस के समय, किसी टास्क को अत्यधिक सरल बनाना रियल में सरल होता है, क्योंकि किसी बड़े टास्क से प्राप्त छोटे टास्क में अभी भी मिस्ड छोटे टास्क भी इंक्लूड हो सकते हैं। गिटार के चयन में यह सोचना इंक्लूड हो सकता है कि कौन सा गिटार लिया जाए, कौन सा गिटार यूज किया जाए, और सबसे पूर्व यह सोचें कि गिटार कहाँ स्थित है। फिर इन टास्क को छोटे-छोटे टास्क में स्प्लिट किया जा सकता है, जैसे कि पूर्व यह सोचना कि गिटार का कौन सा कलर उस स्थान पर फिट होता है। टास्क को और भी छोटे टास्क में स्प्लिट किया जा सकता है, और यह डिजाइनर पर निर्भर है कि वह यह डेटरमाइन करे कि टास्क को स्प्लिट करने से रोकने के लिए उपयुक्त स्थान कौन सा है। टास्क को न केवल ओवर सिंपलीफाइड किया जा सकता है, अन्यथा उन्हें पूर्ण प्रकार से लेफ्ट भी किया जा सकता है, इस प्रकार डिज़ाइनर को यूज केसे को लिखते समय किसी इवेंट या एक्शन में इंक्लूड सभी विवरणों और सभी प्रमुख स्टेप्स के विषय में अवेयर होना चाहिए। | ||
== यह भी देखें == | == यह भी देखें == | ||
{{div col|colwidth=20em}} | {{div col|colwidth=20em}} | ||
* [[ | * [[एक्शन रिसर्च]] | ||
* [[ | * [[एक्टिविटी-सेंटर्ड डिज़ाइन]] | ||
* | * अटेंटिव यूजर इंटरफेस | ||
* [[ | * [[चीफ एक्सपीरियंस ऑफिसर]] (सीएक्सओ) | ||
* [[ | * [[कंटेंट बेस्ड यूजएबिलिटी टेस्टिंग]] | ||
* | * कंटेक्सटुअल इन्क्वायरी | ||
* [[ | * [[डिज़ाइन थिंकिंग]] | ||
* [[ | * [[एम्पथेटिक डिज़ाइन]] | ||
* [[ | * [[ह्यूमन सेंटर्ड कंप्यूटिंग]] | ||
* | *ह्यूमन सेंटर्ड सिस्टम | ||
* [[ | * [[ह्यूमन सेंटर्ड डिज़ाइन]] | ||
* | *ह्यूमन एक्सपीरियंस डिज़ाइन | ||
* [[ | * [[इनफार्मेशन आर्किटेक्चर]] | ||
* [[ | * [[इंटरेक्शन डिज़ाइन]] | ||
* [[मेटा-डिज़ाइन]] | * [[मेटा-डिज़ाइन]] | ||
* [[ | * [[पेपर प्रोटोटाइप]] | ||
* | * पार्टिसिपेटरी डिज़ाइन | ||
* [[ | * [[प्रोसेस सेंटर्ड डिज़ाइन]] | ||
* [[ | * [[थानाटोसेंसिटिविटी]] | ||
* [[ट्रांसजेनरेशनल डिज़ाइन]] | * [[ट्रांसजेनरेशनल डिज़ाइन]] | ||
* [[ | * [[यूबीक्विटॉस कंप्यूटिंग]] | ||
* | * यूजएबिलिटी | ||
*[[ | *[[वर्ल्ड यूजएबिलिटी डे]] | ||
{{div col end}} | {{div col end}} | ||
| Line 193: | Line 197: | ||
* [https://www.youtube.com/watch?v=Wl2LkzIkacM यूजर सेंटर्ड डिज़ाइन, डॉन नॉर्मन] | * [https://www.youtube.com/watch?v=Wl2LkzIkacM यूजर सेंटर्ड डिज़ाइन, डॉन नॉर्मन] | ||
[[Category:Articles with hatnote templates targeting a nonexistent page]] | |||
[[Category: | |||
[[Category:Created On 17/08/2023]] | [[Category:Created On 17/08/2023]] | ||
[[Category:Machine Translated Page]] | |||
[[Category:Pages with script errors]] | |||
[[Category:Short description with empty Wikidata description]] | |||
[[Category:Template documentation pages|Short description/doc]] | |||
[[Category:Templates Vigyan Ready]] | |||
[[Category:Templates that add a tracking category]] | |||
[[Category:Templates that generate short descriptions]] | |||
[[Category:Templates using TemplateData]] | |||
[[Category:Vigyan Ready]] | |||
Latest revision as of 07:28, 16 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
