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