यूजर-सेंटर्ड डिज़ाइन: Difference between revisions

From Vigyanwiki
No edit summary
 
(17 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" />
'''यूजर-सेंटर्ड डिज़ाइन''' (यूसीडी) या यूजर-ड्रिवेन डेवलपमेंट (यूडीडी) प्रोसेस का फ्रेमवर्क है (इंटरफ़ेस या टेक्नोलॉजी तक सीमित नहीं) जिसमें [[प्रयोज्य|यूजएबिलिटी]] गोल, यूजर विशेषताएँ, [[पर्यावरण (सिस्टम)|एनवायरनमेंट (सिस्टम)]], टास्क और किसी [[उत्पाद (व्यवसाय)|प्रोडक्ट (व्यवसाय)]] का वर्कफ़्लो इंक्लूड होता है। [[डिज़ाइन प्रक्रिया|डिज़ाइन प्रोसेस]] के प्रत्येक स्टेज में सर्विस या प्रोसेस पर ब्रॉड ध्यान दिया जाता है। ये टेस्टिंग रिक्वायरमेंट्स, प्री-प्रोडक्शन मॉडल और पोस्ट प्रोडक्शन की प्रोसेस के प्रत्येक स्टेज के समय एक्चुअल यूजर्स के साथ या उनके बिना कंडक्ट किए जाते हैं, जो प्रूफ के सर्कल को पूर्ण करते हैं और यह सुनिश्चित करते हैं कि डेवलपमेंट यूजर को फोकस के केंद्र के रूप में आगे बढ़ाता है।<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 में यूजर-सेंटर्ड सिस्टम डिज़ाइन: ह्यूमन-कंप्यूटर इंटरैक्शन ऑन न्यू पर्सपेक्टिव पुस्तक के प्रकाशन के परिणामस्वरूप यह कॉन्सेप्ट व्यापक रूप से लोकप्रिय हो गया।<ref>Norman, D. A. (1986). ''User-Centered System Design: New Perspectives on Human-Computer Interaction''.</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>{{rp|p.5 onwards}} नॉर्मन अपने पूर्व विचारों को याद करके विस्तार से बताता है कि उसे जो अत्यधिक रिडक्टिव लगा था।
पश्चात की पुस्तक, [[भावनात्मक डिज़ाइन|इमोशनल डिज़ाइन]] में,<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> इसे [[सह डिजाइन]] भी कहा जाता है।
* [[सहकारी डिजाइन|कोऑपरेटिव डिजाइन]]: डिजाइनरों और यूजर्स को इक्वल फुटिंग पर इंक्लूड करना है। यह आईटी आर्टिफैक्ट्स के डिजाइन की स्कैंडिनेवियाई ट्रेडिशन है और यह 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>
* [[सहभागी डिज़ाइन|पार्टिसिपेटरी डिज़ाइन]] (पीडी), इसी कॉन्सेप्ट के लिए उत्तरी अमेरिकी शब्द, कोऑपरेटिव डिज़ाइन से प्रेरित, यूजर्स की पार्टिसिपेशन पर फोकस करता है। 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>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 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 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> क्लीयरली लेबल्ड सेक्शन, पेज नंबर, [[रंग कोडिंग|कलर कोडिंग]], आदि)। नेविगेशनल एलिमेंट्स डॉक्यूमेंट की [[शैली|जेनर]] के अनुरूप होने चाहिए। '[[चंकिंग (मनोविज्ञान)|चंकिंग (फिलॉसफी)]]' उपयोगी स्ट्रेटेजी है जिसमें इनफार्मेशन को छोटे-छोटे पीसेस में ब्रेक करना इंक्लूड है जिन्हें किसी प्रकार के मीनिंगफुल आर्डर या [[पदानुक्रम|हायरार्की]] में ऑर्गनाइज्ड किया जा सकता है। डॉक्यूमेंट को [[स्किमिंग (पढ़ना)|स्किम (रीड)]] करने की क्षमता यूजर्स को रीड के अतिरिक्त स्कैन करके अपनी इंफॉर्मेशन के पीसेस को फाइंड करने की अनुमति देती है। इसके लिए प्रायः [[ बोल्ड अक्षरों |बोल्ड लेटर्स]] और [[इटैलिक प्रकार|इटैलिक]] शब्दों का उपयोग किया जाता है।


=== अभिगम्यता ===
=== लेजिबिलिटी ===
यूजरओं को पूर्ण दस्तावेज़ में जानकारी जल्दी और आसानी से ढूंढने में सक्षम होना चाहिए, चाहे उसकी लंबाई कुछ भी हो। यूजरओं को जानकारी खोजने के विभिन्न तरीकों की पेशकश की जानी चाहिए (जैसे कि नेविगेशनल तत्व, खोज फ़ंक्शन, सामग्री की तालिका,<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>प्रत्येक प्रोडक्ट के लिए, या कभी-कभी किसी प्रोडक्ट के अंदर टूल्स के प्रत्येक सेट के लिए, पर्सोनाों का छोटा सेट होता है, जिनमें डिज़ाइन के लिए प्राइमरी फोकस होता है। ऐसा भी होता है जिसे [[द्वितीयक व्यक्तित्व|सेकेंडरी पर्सोना]] कहा जाता है, जहां कैरेक्टर डिजाइन का मेन गोल नहीं होता है, किन्तु उनकी आवश्यकता को पूर्ण किया जाना चाहिए और यदि संभव हो तो प्रॉब्लम्स का सॉल्यूशन किया जाना चाहिए। वे फरदर संभावित प्रॉब्लम्स और डिफीकल्टीज का सॉल्यूशन करने में सहायता करने के लिए इंक्लूड हैं, चूंकि प्राइमरी पर्सन उनके सॉल्यूशन से संतुष्ट हो। शेयर्ड अंडरस्टैंडिंगइस में एंटी पर्सोना भी है, जो वह कैरेक्टर है जिसके लिए डिज़ाइन विशेष रूप से नहीं बनाया गया है।
यूसीडी प्रक्रिया के समय, यूजर का प्रतिनिधित्व करने वाला एक [[व्यक्तित्व (उपयोगकर्ता अनुभव)|व्यक्तित्व (यूजर अनुभव)]] बनाया जा सकता है। पर्सोना (यूजर अनुभव) एक यूजर आदर्श है जिसका उपयोग प्रोडक्ट सुविधाओं, नेविगेशन, इंटरैक्शन और यहां तक ​​कि विज़ुअल डिज़ाइन के बारे में निर्णय लेने में सहायता के लिए किया जाता है। ज्यादातर मामलों में, पर्सोना (यूजर अनुभव) को एक्चुअल लोगों के साथ [[नृवंशविज्ञान]] साक्षात्कार की एक श्रृंखला से संश्लेषित किया जाता है, फिर 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"
|-
|-
! Actor
! एक्टर
! World
! वर्ल्ड
|-
|-
| choose music to play
| प्ले करने के लिए म्यूजिक का चयन करना
|
|
|-
|-
| pick up guitar
| गिटार उठाए
|
|
|-
|-
|
|
| display sheet music
| डिस्प्ले शीट म्यूजिक
|-
|-
| perform each note on sheet music using guitar
| गिटार का उपयोग करके शीट म्यूजिक पर प्रत्येक नोट का परफॉरमेंस करना
|
|
|-
|-
|
|
| convey note to audience using sound
| साउंड का उपयोग करके ऑडियंस तक नोट पहुँचाएँ
|-
|-
|
|
| audience provides feedback to performer
| ऑडियंस परफ़ॉर्मर को फीडबैक प्रदान करते हैं
|-
|-
| assess performance and adjust as needed based on audience feedback
| परफॉरमेंस का आकलन करना और ऑडियंस के फीडबैक के आधार पर एडजस्ट करें
|
|
|-
|-
| complete song with required adjustments
| रिक्वायर्ड एडजस्टमेंट के साथ पूर्ण म्यूजिक
|
|
|-
|-
|
|
| audience applause
| ऑडियंस अप्लॉज़
|}
|}
अभिनेता और दुनिया के मध्य की बातचीत एक ऐसा कार्य है जिसे रोजमर्रा की जिंदगी में देखा जा सकता है, और हम इसे सामान्य रूप से लेते हैं और संगीत के एक टुकड़े को प्रस्तुत करने जैसे कार्य के लिए होने वाली छोटी-छोटी बातों के बारे में बहुत अधिक नहीं सोचते हैं। अस्तित्व के लिए। यह इस तथ्य के समान है कि अपनी मातृभाषा बोलते समय, हम व्याकरण और शब्दों को कैसे वाक्यांशबद्ध करें, इसके बारे में बहुत अधिक नहीं सोचते हैं; वे बस बाहर आ जाते हैं क्योंकि हम उन्हें कहने के इतने आदी हो गए हैं। इस मामले में एक अभिनेता और दुनिया, विशेष रूप से, प्राथमिक हितधारक (यूजर) और दुनिया के मध्य की गतिविधियों के बारे में विस्तार से सोचा जाना चाहिए, और इसलिए यह समझने के लिए उपयोग के मामले बनाए जाते हैं कि ये छोटी बातचीत कैसे होती हैं।
एक्टर और वर्ल्ड के मध्य की इंटरेक्शन ऐसा कार्य है जिसे एवरीडे लाइफ में देखा जा सकता है, और हम इसे सामान्य रूप से लेते हैं और म्यूजिक के पार्ट्स को प्रस्तुत करने जैसे कार्य के लिए होने वाली छोटी-छोटी बातों के विषय में एक्सिस्टेंस के लिए अधिक नहीं सोचते हैं। यह इस फैक्ट के समान है कि अपनी मदरलैंग्वेज बोलते समय, हम ग्रामर और वर्ड्स को कैसे फ्रेस करें, इसके विषय में अधिक नहीं सोचते हैं; वे बस बाहर आ जाते हैं क्योंकि हम उन्हें कहने के इतने अकस्टोमेड हो गए हैं। इस विषय में एक्टर और वर्ल्ड, विशेष रूप से, प्राइमरी स्टेकहोल्डर (यूजर) और वर्ल्ड के मध्य की गतिविधियों के विषय में विस्तार से सोचा जाना चाहिए, और इसलिए यह समझने के लिए यूज केसेस बनाए जाते हैं कि ये छोटी इंटरेक्शन कैसे होती हैं।


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


{| class="wikitable"
{| class="wikitable"
! Actor
! एक्टर
! World
! वर्ल्ड
|-
|-
| choose sheet music to perform
| पर्फोर्मस के लिए शीट म्यूजिक का चयन करें
|
|
|-
|-
| gathers necessary resources
| नेसेसरी रिसोर्सेज एकत्रित करता है
|
|
|-
|-
|
|
| provides access to resources
| रिसोर्सेज तक पहुंच प्रदान करता है
|-
|-
| performs piece sequentially
| पर्फोर्मस पीस सेक़ुएनसली
|
|
|-
|-
|
|
| convey and interprets performance
| पर्फोर्मस को इंटरपेट और कन्वे करना
|-
|-
|
|
| provides feedback
| फीडबैक प्रदान करता है
|-
|-
| completes performance
| पर्फोर्मस पूर्ण करता है
|
|
|}
|}
उपयोग के मामले उपयोगी हैं क्योंकि वे डिज़ाइन कार्य के उपयोगी स्तरों की पहचान करने में सहायता करते हैं। वे डिजाइनरों को एक्चुअल निम्न स्तर की प्रक्रियाओं को देखने की अनुमति देते हैं जो एक निश्चित समस्या में सम्मिलित हैं, जिससे समस्या को संभालना आसान हो जाता है, क्योंकि यूजर द्वारा किए गए कुछ छोटे कदम और विवरण सामने आ जाते हैं। डिजाइनरों का काम इन छोटी-छोटी समस्याओं पर विचार करना होना चाहिए जिससे अंतिम समाधान तक पहुंच सकें जो कारगर हो। इसे कहने का दूसरा तरीका यह है कि उपयोग के मामले जटिल टास्क को छोटे बिट्स में तोड़ देते हैं, जहां ये बिट्स उपयोगी इकाइयां हैं। प्रत्येक बिट एक छोटा कार्य पूर्ण करता है, जो फिर अंतिम बड़े कार्य का निर्माण करता है। कंप्यूटर पर कोड लिखने की प्रकार, पूर्ण कोड को प्रारम्भ से ही निपटाने के बजाय, बुनियादी छोटे भागों को लिखना और पूर्व उन्हें काम पर लगाना और फिर बड़े और अधिक जटिल कोड को समाप्त करने के लिए उन्हें एक साथ रखना आसान होता है।
यूज केसेस उपयोगी हैं क्योंकि वे डिज़ाइन कार्य के उपयोगी फुटिंगों को आइडेंटिफाई करने में सहायता करते हैं। वे डिजाइनरों को एक्चुअल लो लेवल फुटिंग की प्रोसेस को देखने की अनुमति देते हैं जो निश्चित प्रॉब्लम में इंक्लूड हैं, जिससे प्रॉब्लम को हैंडल करना इजी हो जाता है, क्योंकि यूजर द्वारा किए गए कुछ छोटे फेज और विवरण सामने आ जाते हैं। डिजाइनरों का कार्य इन छोटी-छोटी प्रॉब्लम्स पर विचार करना चाहिए जिससे फाइनल सॉल्यूशन तक पहुंच सकें। इसे कहने का दूसरा वे यह है कि यूज केसेस डिफिकल्ट टास्क को छोटे बिट्स में ब्रेक कर देते हैं, जहां ये बिट्स उपयोगी यूनिट्स हैं। प्रत्येक बिट छोटा कार्य पूर्ण करता है, जो फिर फाइनल बड़े कार्य का निर्माण करता है। कंप्यूटर पर कोड राइटिंग के प्रकार, बेसिक छोटे पार्टों को राइट करना और उन्हें कार्य पर लगाना और फिर बड़े और अधिक डिफिकल्ट कोड को समाप्त करने के लिए उन्हें एक साथ रखना सरल होता है।


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


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


== यह भी देखें ==
== यह भी देखें ==
{{div col|colwidth=20em}}
{{div col|colwidth=20em}}
* [[कार्रवाई पर शोध]]
* [[एक्शन रिसर्च]]
* [[गतिविधि-केंद्रित डिज़ाइन]]
* [[एक्टिविटी-सेंटर्ड डिज़ाइन]]
* चौकस यूजर इंटरफेस
* अटेंटिव यूजर इंटरफेस
* [[मुख्य अनुभव अधिकारी]] (सीएक्सओ)
* [[चीफ एक्सपीरियंस ऑफिसर]] (सीएक्सओ)
* [[घटक-आधारित प्रयोज्य परीक्षण]]
* [[कंटेंट बेस्ड यूजएबिलिटी टेस्टिंग]]
* प्रासंगिक पूछताछ
* कंटेक्सटुअल इन्क्वायरी
* [[सोच को आकार दें]]
* [[डिज़ाइन थिंकिंग]]
* [[सहानुभूतिपूर्ण डिज़ाइन]]
* [[एम्पथेटिक डिज़ाइन]]
* [[मानव-केंद्रित कंप्यूटिंग]]
* [[ह्यूमन सेंटर्ड कंप्यूटिंग]]
* माइक कूली (इंजीनियर)#मानव-केंद्रित प्रणालियाँ|मानव-केंद्रित प्रणालियाँ
*ह्यूमन सेंटर्ड सिस्टम
* [[मानव-केंद्रित डिज़ाइन]]
* [[ह्यूमन सेंटर्ड डिज़ाइन]]
*मानव अनुभव डिज़ाइन
*ह्यूमन एक्सपीरियंस डिज़ाइन
* [[सूचना आर्किटेक्चर]]
* [[इनफार्मेशन आर्किटेक्चर]]
* [[पारस्परिक प्रभाव वाली डिज़ाइन]]
* [[इंटरेक्शन डिज़ाइन]]
* [[मेटा-डिज़ाइन]]
* [[मेटा-डिज़ाइन]]
* [[कागज़ का प्रोटोटाइप]]
* [[पेपर प्रोटोटाइप]]
* सहभागी डिज़ाइन
* पार्टिसिपेटरी डिज़ाइन
* [[प्रक्रिया-केंद्रित डिज़ाइन]]
* [[प्रोसेस सेंटर्ड डिज़ाइन]]
* [[थानाटोसंवेदनशीलता]]
* [[थानाटोसेंसिटिविटी]]
* [[ट्रांसजेनरेशनल डिज़ाइन]]
* [[ट्रांसजेनरेशनल डिज़ाइन]]
* [[सर्वव्यापक कंप्यूटिंग]]
* [[यूबीक्विटॉस कंप्यूटिंग]]
* प्रयोज्यता
* यूजएबिलिटी
*[[विश्व उपयोगिता दिवस]]
*[[वर्ल्ड यूजएबिलिटी डे]]
{{div col end}}
{{div col end}}


Line 195: 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: Machine Translated Page]]
[[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

See also: यूजर-सेंटर्ड डिज़ाइन

यूजर-सेंटर्ड डिज़ाइन (यूसीडी) या यूजर-ड्रिवेन डेवलपमेंट (यूडीडी) प्रोसेस का फ्रेमवर्क है (इंटरफ़ेस या टेक्नोलॉजी तक सीमित नहीं) जिसमें यूजएबिलिटी गोल, यूजर विशेषताएँ, एनवायरनमेंट (सिस्टम), टास्क और किसी प्रोडक्ट (व्यवसाय) का वर्कफ़्लो इंक्लूड होता है। डिज़ाइन प्रोसेस के प्रत्येक स्टेज में सर्विस या प्रोसेस पर ब्रॉड ध्यान दिया जाता है। ये टेस्टिंग रिक्वायरमेंट्स, प्री-प्रोडक्शन मॉडल और पोस्ट प्रोडक्शन की प्रोसेस के प्रत्येक स्टेज के समय एक्चुअल यूजर्स के साथ या उनके बिना कंडक्ट किए जाते हैं, जो प्रूफ के सर्कल को पूर्ण करते हैं और यह सुनिश्चित करते हैं कि डेवलपमेंट यूजर को फोकस के केंद्र के रूप में आगे बढ़ाता है।[1][2] इस प्रकार का टेस्टिंग[3] सिंथेसाइज है क्योंकि किसी प्रोडक्ट के डिज़ाइनरों के लिए सर्वप्रथम उनके डिज़ाइन अनुभवों को सरलता से समझना कठिन होता है कि प्रत्येक यूजर का लर्निंग कर्व कैसा दिख सकता है। यूजर-सेंटर्ड डिज़ाइन यूजर की अंडरस्टैंडिंग, उनकी डिमांड, प्राथमिकताओं और अनुभवों पर आधारित होता है और जब इसका उपयोग किया जाता है, तो यह प्रोडक्ट की यूजफुलनेस और यूजएबिलिटी में इनक्रीस के लिए जाना जाता है क्योंकि यह यूजर को सेटिस्फेक्शन प्रदान करता है।[4]

अन्य प्रोडक्ट डिज़ाइन फिलॉसफीस से मुख्य अंतर यह है कि यूजर-सेंटर्ड डिज़ाइन प्रोडक्ट को ऑप्टिमाइज़ करने का प्रयास करता है कि यूजर प्रोडक्ट का उपयोग कैसे कर सकते हैं, या कैसे करना चाहते हैं जिससे यूजर्स प्रोडक्ट को एकमोडेट करने के लिए अपने बिहेवियर और एक्सपेक्टेशन को परिवर्तित करने के लिए फोर्स्ड न किया जाना चाहिए। इस प्रकार यूजर दो को-सेंट्रिक सर्कल्स के केंद्र में स्टैंड करते हैं। इनर सर्कल में प्रोडक्ट का कॉन्टेक्स्ट, विकसित करने के उद्देश्य और वह एनवायरनमेंट इंक्लूड है जिसमें यह रन करेगा। आउटर सर्कल में टास्क डिटेल, टास्क ऑर्गेनाइजेशन और टास्कफलो का अधिक विस्तृत विवरण इंक्लूड है।[2]

इतिहास

यूजर-सेंटर्ड डिज़ाइन शब्द 1977 में रॉब क्लिंग द्वारा दिया गया था[5] और पश्चात में कैलिफोर्निया वर्ल्डविद्यालय, सैन डिएगो में डोनाल्ड ए. नॉर्मन की अनुसंधान प्रयोगशाला में स्वीकार किया गया। 1986 में यूजर-सेंटर्ड सिस्टम डिज़ाइन ह्यूमन-कंप्यूटर इंटरैक्शन ऑन न्यू पर्सपेक्टिव पुस्तक के प्रकाशन के परिणामस्वरूप यह कॉन्सेप्ट ब्रॉड रूप से लोकप्रिय हो गया।[6] इस कॉन्सेप्ट को नॉर्मन की पुस्तक दी डिजाइन ऑफ एवरीडे थिंग्स (मूल रूप से द साइकोलॉजी ऑफ एवरीडे थिंग्स कहा जाता है) में और अधिक स्वीकृति मिली। इस पुस्तक में, नॉर्मन उदाहरणों के माध्यम से 'गुड' और 'बैड' डिज़ाइन की फिलॉसफी का वर्णन करते हैं। वह हमारे एवरीडे लाइफ में डिजाइन के महत्व और बैड डिजाइन के कारण होने वाली एरेर के परिणामों को प्रदर्शित करता है।

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

  1. टास्क के स्ट्रक्वेरिएबल को इस प्रकार सरल बनाना कि किसी भी मोमेंट पॉसिबल एक्शन इंट्यूटिव हों।
  2. सिस्टम के कॉन्सेप्चुअल मॉडल, टास्क, टास्क के रिजल्ट्स और फीडबैक सहित थिंग्स को विजिबल बनाना।
  3. इंटेंडेड रिजल्ट्स और सिंथेसाइज एक्शन के मध्य राइट मैपिंग प्राप्त करना।
  4. सिस्टम के कंस्ट्रेंट्स को एम्ब्रेस और एक्सप्लॉइट करना।

पश्चात की पुस्तक, इमोशनल डिज़ाइन में,[7] नॉर्मन अपने पूर्व विचारों को याद करके विस्तार से बताता है जो उसे अत्यधिक रिडक्टिव लगा था।

मॉडल और अप्प्रोचेस

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

यूजर-सेंटर्ड डिज़ाइन निम्नलिखित मॉडलों से इंस्पायर होता है:

  • कोऑपरेटिव डिजाइन: डिजाइनरों और यूजर्स को इक्वल फुटिंग पर इंक्लूड करना है। यह आईटी आर्टिफैक्ट्स के डिजाइन की स्कैंडिनेवियाई ट्रेडिशन है और यह 1970 से विकसित हो रही है।[8] इसे को-डिजाइन भी कहा जाता है।
  • पार्टिसिपेटरी डिज़ाइन (पीडी), इसी कॉन्सेप्ट के लिए उत्तरी अमेरिकी शब्द, कोऑपरेटिव डिज़ाइन से प्रेरित, यूजर्स की पार्टिसिपेशन पर फोकस करता है। 1990 से, द्वि-वार्षिक पार्टिसिपेटरी डिज़ाइन सम्मेलन होता रहा है।[9]
  • कंटेक्सटुअल डिज़ाइन, एक्चुअल कॉन्टेक्स्ट में कस्टमर-सेंटर्ड डिज़ाइन, जिसमें पार्टिसिपेटरी डिज़ाइन के कुछ आइडियाज इंक्लूड हैं[10]

यहां वे सिद्धांत दिए गए हैं जो यह सुनिश्चित करने में सहायता करते हैं कि डिज़ाइन यूजर-सेंटर्ड है:[11]

  1. डिज़ाइन यूजर्स, टास्क और एनवायरनमेंट की एक्सप्लिसिट अंडरस्टैंडिंग पर आधारित है।
  2. यूजर डिज़ाइन और डेवलपमेंट के समय इंक्लूड होते हैं।[12]
  3. डिज़ाइन यूजर-सेंटर्ड मूल्यांकन द्वारा ड्रिवेन और रिफाइन होता है।
  4. प्रोसेस इंटरैक्टिव है।
  5. डिज़ाइन संपूर्ण यूजर एक्सपीरियंस को एड्रेस करता है।
  6. डिज़ाइन टीम में मल्टीडिसीप्लिनरी स्किल और पर्सपेक्टिव इंक्लूड हैं।

यूजर-सेंटर्ड डिज़ाइन प्रोसेस

यूजर-सेंटर्ड डिज़ाइन का गोल ऐसे प्रोडक्ट बनाना है जिनकी उपयोगिता अधिक हो। इसमें यह इंक्लूड है कि प्रोडक्ट अपने उपयोग, मेनेजेबिलिटी, एफ्फेक्टिवनेस्स के कॉन्टेक्स्ट में कितना सुविधाजनक है और प्रोडक्ट यूजर की रिक्वायरमेंट्स के अनुरूप कितना उचित है। यूजर-सेंटर्ड डिज़ाइन प्रोसेस के सामान्य फेज नीचे दिए गए हैं:[13][14]

  1. उपयोग का कॉन्टेक्स्ट स्पेसिफाई करना: आइडेंटिफाई करें कि प्रोडक्ट के प्राइमरी यूजर कौन हैं, वे प्रोडक्ट का उपयोग क्यों करेंगे, उनकी आवश्यकताएं क्या हैं और वे किस एनवायरनमेंट में इसका उपयोग करेंगे।
  2. आवश्यकताएँ निर्दिष्ट करना: कॉन्टेक्स्ट स्पेसिफाई हो जाने के पश्चात, प्रोडक्ट की ग्रेनुलर रिक्वायरमेंट्स को आइडेंटिफाई करने का समय होता है। यह महत्वपूर्ण स्टेज है जो डिजाइनरों को स्टोरीबोर्ड बनाने और प्रोडक्ट को सफल बनाने के लिए महत्वपूर्ण गोल सेट करने में और सुविधा प्रदान कर सकता है।
  3. डिज़ाइन सोलूशन्स और डेवलपमेंट: प्रोडक्ट गोल और रिक्वायरमेंट्स के आधार पर, प्रोडक्ट डिज़ाइन और डेवलपमेंट की इटरेटिव डिज़ाइन प्रोसेस प्रारम्भ करना।
  4. प्रोडक्ट का मूल्यांकन करना: प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के प्रत्येक स्टेज में प्रोडक्ट के लिए यूजर्स का फीडबैक प्राप्त करने के लिए यूजएबिलिटी टेस्टिंग करते हैं।

एबव स्टेजों में, प्रोडक्ट को और उत्तम बनाने के लिए उपरोक्त प्रोसेस रिपीट किया जाता है। ये स्टेज जनरल अप्प्रोचेस और फैक्टर्स हैं जैसे डिज़ाइन गोल, टीम और उनकी टाईमलाईन, और वह एनवायरनमेंट जिसमें प्रोडक्ट विकसित किया गया है, किसी परियोजना और उनके क्रम के लिए उपयुक्त फेज निर्धारित करते हैं। आप या तो वाटरफॉल मॉडल, एजाइल मॉडल या किसी अन्य सॉफ्टवेयर इंजीनियरिंग प्रैक्टिस को फॉलो कर सकते हैं।

उद्देश्य

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

  • वेबसाइट के यूजर कौन हैं?
  • यूजर्स के कार्य और गोल क्या हैं?
  • वेबसाइट और समान वेबसाइटों के साथ यूजर्स का एक्सपीरियंस लेवल क्या है?
  • यूजर्स को वेबसाइट से किन टास्क की आवश्यकता है?
  • यूजर्स को किस इनफार्मेशन की आवश्यकता हो सकती है, और उन्हें इसकी किस फॉर्म में आवश्यकता है?
  • यूजर क्या सोचते हैं कि वेबसाइट को कैसे कार्य करना चाहिए?
  • वे कौन से एक्सट्रीम एनवॉरमैंट्स हैं जिनमें वेबसाइट तक एक्सेस किया जा सकता है?
  • क्या यूजर मल्टीटास्किंग है?
  • क्या इंटरफ़ेस विभिन्न इनपुट मोड, जैसे टच, स्पीच, जेस्चर या ओरिएंटेशन का उपयोग करता है?

एलिमेंट्स

यूसीडी व्यूपॉइंट के उदाहरण के रूप में, किसी वेबसाइट के यूसीडी के आवश्यक एलिमेंट्स सामान्यतः विजिबिलिटी, एक्सेसिबिलिटी, लेजिबिलिटी और लैंग्वेज का कन्सिडरेशन हैं।

विजिबिलिटी

विजिबिलिटी यूजर को डॉक्यूमेंट का मेंटल मॉडल बनाने में सहायता करती है। डॉक्यूमेंट का उपयोग करते समय मॉडल यूजर को उनके टास्क के इफेक्ट का अनुमान लगाने में सहायता करते हैं। महत्वपूर्ण एलिमेंट्स (जैसे कि वे जो मार्गफिलॉसफीस में सहायता करते हैं) एम्फैटिक होने चाहिए। यूजर्स को सिंगल ग्लांस से यह बताने में सक्षम होना चाहिए कि वे डॉक्यूमेंट के साथ क्या कर सकते हैं और क्या नहीं कर सकते हैं।

एक्सेसिबिलिटी

यूजर्स को डॉक्यूमेंट में इनफार्मेशन को शीघ्रता और सरलता से फाइंड करने में सक्षम होना चाहिए, रिगार्डलेस उसकी लेंथ कुछ भी हो। यूजर्स को इंफॉर्मेशन फाइंड करने के विभिन्न वेज़ ऑफर किया जाना चाहिए (जैसे कि नेविगेशनल एलिमेंट्स, सर्च फ़ंक्शन, टेबल ऑफ कंटेंट्स,[15] क्लीयरली लेबल्ड सेक्शन, पेज नंबर, कलर कोडिंग, आदि)। नेविगेशनल एलिमेंट्स डॉक्यूमेंट की जेनर के अनुरूप होने चाहिए। 'चंकिंग (फिलॉसफी)' उपयोगी स्ट्रेटेजी है जिसमें इनफार्मेशन को छोटे-छोटे पीसेस में ब्रेक करना इंक्लूड है जिन्हें किसी प्रकार के मीनिंगफुल आर्डर या हायरार्की में ऑर्गनाइज्ड किया जा सकता है। डॉक्यूमेंट को स्किम (रीड) करने की क्षमता यूजर्स को रीड के अतिरिक्त स्कैन करके अपनी इंफॉर्मेशन के पीसेस को फाइंड करने की अनुमति देती है। इसके लिए प्रायः बोल्ड लेटर्स और इटैलिक शब्दों का उपयोग किया जाता है।

लेजिबिलिटी

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

लैंग्वेज

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

एनालिसिस टूल्स

ऐसे कई टूल्स हैं जिनका उपयोग यूजर-सेंटर्ड डिज़ाइन के एनालिसिस में किया जाता है, मुख्य रूप से: पर्सोना, सिनेरियो और एसेंशियल यूज केस है।

पर्सोना

यूसीडी प्रोसेस के समय, यूजर का पर्सोना (यूजर एक्सपीरियंस) रिप्रेसेंटिंग बनाया जा सकता है। पर्सोना (यूजर एक्सपीरियंस) यूजर आर्चटाइप है जिसका उपयोग प्रोडक्ट सुविधाओं, नेविगेशन, इंटरैक्शन और यहां तक ​​कि विज़ुअल डिज़ाइन के विषय में निर्णय लेने में सहायता के लिए किया जाता है। अधिकतर विषयों में, पर्सोना (यूजर एक्सपीरियंस) को रियल लोगों के साथ एंथ्रोपोजेनिक की सीरीज से सिंथेसाइज किया जाता है, फिर 1-2 पेज के विवरणों में कैप्चर किया जाता है जिसमें बिहेवियर पैटर्न, गोल, स्किल, ऐटिटूड और एनवायरनमेंट इंक्लूड होते हैं।

[16]प्रत्येक प्रोडक्ट के लिए, या कभी-कभी किसी प्रोडक्ट के अंदर टूल्स के प्रत्येक सेट के लिए, पर्सोनाों का छोटा सेट होता है, जिनमें डिज़ाइन के लिए प्राइमरी फोकस होता है। ऐसा भी होता है जिसे सेकेंडरी पर्सोना कहा जाता है, जहां कैरेक्टर डिजाइन का मेन गोल नहीं होता है, किन्तु उनकी आवश्यकता को पूर्ण किया जाना चाहिए और यदि संभव हो तो प्रॉब्लम्स का सॉल्यूशन किया जाना चाहिए। वे फरदर संभावित प्रॉब्लम्स और डिफीकल्टीज का सॉल्यूशन करने में सहायता करने के लिए इंक्लूड हैं, चूंकि प्राइमरी पर्सन उनके सॉल्यूशन से संतुष्ट हो। शेयर्ड अंडरस्टैंडिंगइस में एंटी पर्सोना भी है, जो वह कैरेक्टर है जिसके लिए डिज़ाइन विशेष रूप से नहीं बनाया गया है।

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

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

सिनेरियो

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

सिनेरियो सोशल कॉन्टेक्स्ट बनाते हैं जिसमें पर्सन इंक्लूड होते हैं, और कलेक्टेड डेटा से इनर विशेषताओं वाले कैरेक्टर की इमेजिनेशन करने के अतिरिक्त एक्चुअल फिजिकल वर्ल्ड भी बनाते हैं और कुछ नहीं; पर्सोना के एक्सिस्टेंस में अधिक एक्शन इंक्लूड है। किसी सिनेरियो को लोग अधिक इजली समझ पाते हैं, क्योंकि यह स्टोरी के रूप में होता है और इसका अनुसरण करना सरल होता है। फिर भी, पर्सोना के प्रकार, ये सिनेरियो रिसर्चेस और डिजाइनर द्वारा बनाई गई परसेप्शन हैं, और ये ऑर्गनाइज्ड डेटा के सेट से भी बनाए गए हैं। यह सुनिश्चित करना महत्वपूर्ण है कि सिनेरियो यथासंभव एक्चुअल वर्ल्ड सिनेरियो के क्लोज बनाए जाएं। फिर भी, कभी-कभी यह समझाना और सूचित करना डिफिकल्ट हो सकता है कि लो लेवल फुटिंग के कार्य कैसे होते हैं, उदाहरण के लिए कार्य करने से पूर्व किसी पर्सन की थॉट प्रोसेस है।

यूज केस

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

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

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

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

एक्टर वर्ल्ड
पर्फोर्मस के लिए शीट म्यूजिक का चयन करें
नेसेसरी रिसोर्सेज एकत्रित करता है
रिसोर्सेज तक पहुंच प्रदान करता है
पर्फोर्मस पीस सेक़ुएनसली
पर्फोर्मस को इंटरपेट और कन्वे करना
फीडबैक प्रदान करता है
पर्फोर्मस पूर्ण करता है

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

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

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

यह भी देखें

कॉन्टेक्स्ट

  1. ↑ "Cover – Just Ask: Integrating Accessibility Throughout Design". uiaccess.com.
  2. ↑ 2.0 2.1 "उपयोगकर्ता केंद्रित डिज़ाइन प्रक्रिया (यूसीडी) पर नोट्स". www.w3.org.
  3. ↑ 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.
  4. ↑ Vredenburg, Karel; Mao, Ji-Ye; Smith, Paul; Carey, Tom (2002). "उपयोगकर्ता-केंद्रित डिज़ाइन अभ्यास का एक सर्वेक्षण" (PDF).
  5. ↑ Kling, Rob (1977). "उपयोगकर्ता-केंद्रित सॉफ़्टवेयर डिज़ाइन का संगठनात्मक संदर्भ". MIS Quarterly. 1 (4): 41–52. doi:10.2307/249021. ISSN 0276-7783. JSTOR 249021.
  6. ↑ Norman, D. A. (1986). User-Centered System Design: New Perspectives on Human-Computer Interaction.
  7. ↑ "Don Norman (2003) Emotional Design, Prolog-- Three Teapots" (PDF). jnd.org.
  8. ↑ Greenbaum&Kyng (eds): Design At Work – Cooperative design of Computer Systems, Lawrence Erlbaum 1991
  9. ↑ Schuler & Namioka (1993). Participatory Design, Lawrence Erlbaum; and chapter 11 in Helander's Handbook of HCI, Elsevier, 1997.
  10. ↑ Beyer & Holtzblatt (1998). Contextual Design, Kaufmann.
  11. ↑ "उपयोगकर्ता-केंद्रित डिज़ाइन मूल बातें". www.usability.gov.
  12. ↑ 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.
  13. ↑ "उपयोगकर्ता केंद्रित डिज़ाइन प्रक्रिया (यूसीडी) पर नोट्स". www.w3.org. Retrieved 30 March 2017.
  14. ↑ "उपयोगकर्ता-केंद्रित डिज़ाइन मूल बातें". www.usability.gov. Retrieved 30 March 2017.
  15. ↑ 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.
  16. ↑ "अपने व्यक्तित्व को परिपूर्ण बनाना". www.cooper.com. Retrieved 2016-01-06.

अग्रिम पठन

वीडियो

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=यूजर-सेंटर्ड_डिज़ाइन&oldid=267921’