यूजर-सेंटर्ड डिज़ाइन: Difference between revisions
No edit summary |
No edit summary |
||
Line 6: | Line 6: | ||
== इतिहास == | == इतिहास == | ||
यूजर-सेंटर्ड डिज़ाइन शब्द 1977 में रॉब क्लिंग द्वारा | यूजर-सेंटर्ड डिज़ाइन शब्द 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}} नॉर्मन अपने पूर्व विचारों को याद करके विस्तार से बताता है कि उसे जो अत्यधिक रिडक्टिव लगा था। | ||
== मॉडल और | == मॉडल और अप्प्रोचेस == | ||
उदाहरण के लिए, यूजर-सेंटर्ड डिज़ाइन प्रक्रिया सॉफ़्टवेयर डिज़ाइनरों को अपने यूजरओं के लिए इंजीनियर किए गए प्रोडक्ट के गोल को पूर्ण करने में | उदाहरण के लिए, यूजर-सेंटर्ड डिज़ाइन प्रक्रिया सॉफ़्टवेयर डिज़ाइनरों को अपने यूजरओं के लिए इंजीनियर किए गए प्रोडक्ट के गोल को पूर्ण करने में सहायता कर सकती है। यूजर की रिक्वायरमेंट्स पर प्रारम्भ से ही विचार किया जाता है और पूर्ण प्रोडक्ट को सर्कल में सम्मिलित किया जाता है। इन रिक्वायरमेंट्स को इन्वेस्टिगेटिव मेथड्स के माध्यम से नोट और रिफाइन किया जाता है जिनमें नृवंशविज्ञान अध्ययन, प्रासंगिक इन्वेस्टिगेटिव, प्रोटोटाइप परीक्षण, यूएसएबिलिटी परीक्षण और अन्य विधियां सम्मिलित हैं। जनरेटिव मेथड्स का भी उपयोग किया जा सकता है जिनमें [[ कार्ड छँटाई |कार्ड छँटाई]] , एफ़िनिटी आरेख और भागीदारी डिज़ाइन सत्र सम्मिलित हैं। इसके अतिरिक्त, डिज़ाइन किए जा रहे प्रोडक्ट के समान उपयोग योग्य प्रोडक्टों के सावधानीपूर्वक विश्लेषण से यूजर की रिक्वायरमेंट्स का अनुमान लगाया जा सकता है। | ||
यूजर-सेंटर्ड डिज़ाइन निम्नलिखित मॉडलों से प्रेरणा लेता है: | यूजर-सेंटर्ड डिज़ाइन निम्नलिखित मॉडलों से प्रेरणा लेता है: | ||
Line 25: | Line 25: | ||
* [[सहभागी डिज़ाइन]] (पीडी), इसी कॉन्सेप्ट के लिए एक उत्तरी अमेरिकी शब्द, सहकारी डिज़ाइन से प्रेरित, यूजरओं की भागीदारी पर ध्यान सेंटर्ड करता है। 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 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> | ||
# डिज़ाइन यूजर-सेंटर्ड मूल्यांकन द्वारा संचालित और | # डिज़ाइन यूजर-सेंटर्ड मूल्यांकन द्वारा संचालित और रिफाइन होता है। | ||
# प्रक्रिया पुनरावर्ती है. | # प्रक्रिया पुनरावर्ती है. | ||
# डिज़ाइन संपूर्ण यूजर अनुभव को संबोधित करता है। | # डिज़ाइन संपूर्ण यूजर अनुभव को संबोधित करता है। | ||
Line 37: | Line 37: | ||
# उपयोग का कॉन्टेक्स्ट निर्दिष्ट करें: पहचानें कि प्रोडक्ट के प्राथमिक यूजर कौन हैं, वे प्रोडक्ट का उपयोग क्यों करेंगे, उनकी आवश्यकताएं क्या हैं और वे किस वातावरण में इसका उपयोग करेंगे। | # उपयोग का कॉन्टेक्स्ट निर्दिष्ट करें: पहचानें कि प्रोडक्ट के प्राथमिक यूजर कौन हैं, वे प्रोडक्ट का उपयोग क्यों करेंगे, उनकी आवश्यकताएं क्या हैं और वे किस वातावरण में इसका उपयोग करेंगे। | ||
# आवश्यकताएं निर्दिष्ट करें: एक बार कॉन्टेक्स्ट निर्दिष्ट हो जाने के पश्चात, प्रोडक्ट की विस्तृत रिक्वायरमेंट्स की पहचान करने का समय आ गया है। यह एक महत्वपूर्ण स्टेज है जो डिजाइनरों को स्टोरीबोर्ड बनाने और प्रोडक्ट को सफल बनाने के लिए महत्वपूर्ण गोल निर्धारित करने में और सुविधा प्रदान कर सकता है। | # आवश्यकताएं निर्दिष्ट करें: एक बार कॉन्टेक्स्ट निर्दिष्ट हो जाने के पश्चात, प्रोडक्ट की विस्तृत रिक्वायरमेंट्स की पहचान करने का समय आ गया है। यह एक महत्वपूर्ण स्टेज है जो डिजाइनरों को स्टोरीबोर्ड बनाने और प्रोडक्ट को सफल बनाने के लिए महत्वपूर्ण गोल निर्धारित करने में और सुविधा प्रदान कर सकता है। | ||
# डिज़ाइन समाधान और विकास बनाएं: प्रोडक्ट गोलों और रिक्वायरमेंट्स के आधार पर, प्रोडक्ट डिज़ाइन और विकास की एक पुनरावृत्त डिज़ाइन प्रक्रिया | # डिज़ाइन समाधान और विकास बनाएं: प्रोडक्ट गोलों और रिक्वायरमेंट्स के आधार पर, प्रोडक्ट डिज़ाइन और विकास की एक पुनरावृत्त डिज़ाइन प्रक्रिया प्रारम्भ करें। | ||
# प्रोडक्ट का मूल्यांकन करें: प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के हर स्टेज में प्रोडक्ट के लिए यूजरओं की प्रतिक्रिया प्राप्त करने के लिए यूएसएबिलिटी परीक्षण करते हैं। | # प्रोडक्ट का मूल्यांकन करें: प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के हर स्टेज में प्रोडक्ट के लिए यूजरओं की प्रतिक्रिया प्राप्त करने के लिए यूएसएबिलिटी परीक्षण करते हैं। | ||
अगले स्टेजों में, प्रोडक्ट को और बेहतर बनाने के लिए उपरोक्त प्रक्रिया दोहराई जाती है। ये स्टेज सामान्य दृष्टिकोण और कारक हैं जैसे डिज़ाइन गोल, टीम और उनकी समयरेखा, और वह वातावरण जिसमें प्रोडक्ट विकसित किया गया है, किसी परियोजना और उनके क्रम के लिए उपयुक्त स्टेज निर्धारित करते हैं। आप या तो [[झरना मॉडल]], एजाइल प्रबंधन मॉडल या किसी अन्य [[सॉफ्टवेयर इंजीनियरिंग]] अभ्यास का पालन कर सकते हैं। | अगले स्टेजों में, प्रोडक्ट को और बेहतर बनाने के लिए उपरोक्त प्रक्रिया दोहराई जाती है। ये स्टेज सामान्य दृष्टिकोण और कारक हैं जैसे डिज़ाइन गोल, टीम और उनकी समयरेखा, और वह वातावरण जिसमें प्रोडक्ट विकसित किया गया है, किसी परियोजना और उनके क्रम के लिए उपयुक्त स्टेज निर्धारित करते हैं। आप या तो [[झरना मॉडल]], एजाइल प्रबंधन मॉडल या किसी अन्य [[सॉफ्टवेयर इंजीनियरिंग]] अभ्यास का पालन कर सकते हैं। | ||
Line 43: | Line 43: | ||
== उद्देश्य == | == उद्देश्य == | ||
यूसीडी अंतिम-यूजर और उनके | यूसीडी अंतिम-यूजर और उनके टास्क और गोलों के बारे में प्रश्न पूछता है, फिर विकास और डिजाइन के बारे में निर्णय लेने के लिए निष्कर्षों का उपयोग करता है। | ||
उदाहरण के लिए, किसी वेब साइट का यूसीडी निम्नलिखित प्रश्नों का उत्तर देना चाहता है: | उदाहरण के लिए, किसी वेब साइट का यूसीडी निम्नलिखित प्रश्नों का उत्तर देना चाहता है: | ||
* वेबसाइट के यूजर कौन हैं? | * वेबसाइट के यूजर कौन हैं? | ||
* यूजरओं के कार्य और गोल क्या हैं? | * यूजरओं के कार्य और गोल क्या हैं? | ||
* वेबसाइट और समान वेबसाइटों के साथ यूजरओं के अनुभव का स्तर क्या है? | * वेबसाइट और समान वेबसाइटों के साथ यूजरओं के अनुभव का स्तर क्या है? | ||
* यूजरओं को वेबसाइट से किन | * यूजरओं को वेबसाइट से किन टास्क की आवश्यकता है? | ||
* यूजरओं को किस [[जानकारी]] की आवश्यकता हो सकती है, और उन्हें इसकी किस रूप में आवश्यकता है? | * यूजरओं को किस [[जानकारी]] की आवश्यकता हो सकती है, और उन्हें इसकी किस रूप में आवश्यकता है? | ||
* यूजर क्या सोचते हैं कि वेबसाइट को कैसे काम करना चाहिए? | * यूजर क्या सोचते हैं कि वेबसाइट को कैसे काम करना चाहिए? | ||
Line 60: | Line 60: | ||
=== [[दृश्यता]] === | === [[दृश्यता]] === | ||
दृश्यता यूजर को दस्तावेज़ का [[मानसिक मॉडल]] बनाने में | दृश्यता यूजर को दस्तावेज़ का [[मानसिक मॉडल]] बनाने में सहायता करती है। दस्तावेज़ का उपयोग करते समय मॉडल यूजर को उनके टास्क के प्रभाव का अनुमान लगाने में सहायता करते हैं। महत्वपूर्ण तत्व (जैसे कि वे जो [[ मार्गदर्शन | मार्गफिलॉसफीस]] में सहायता करते हैं) सशक्त होने चाहिए। यूजरओं को एक नज़र से यह बताने में सक्षम होना चाहिए कि वे दस्तावेज़ के साथ क्या कर सकते हैं और क्या नहीं। | ||
=== अभिगम्यता === | === अभिगम्यता === | ||
यूजरओं को | यूजरओं को पूर्ण दस्तावेज़ में जानकारी जल्दी और आसानी से ढूंढने में सक्षम होना चाहिए, चाहे उसकी लंबाई कुछ भी हो। यूजरओं को जानकारी खोजने के विभिन्न तरीकों की पेशकश की जानी चाहिए (जैसे कि नेविगेशनल तत्व, खोज फ़ंक्शन, सामग्री की तालिका,<ref>{{Cite book|last=Aaron|first=Scharf|url=http://worldcat.org/oclc/1086245904|title=A new beginning: primitivism and science in post-impressionist art; [and] Returnto nature|date=1976|publisher=Open University|isbn=0-335-05151-0|oclc=1086245904}}</ref> स्पष्ट रूप से लेबल किए गए अनुभाग, पृष्ठ संख्या, [[रंग कोडिंग]], आदि)। नेविगेशनल तत्व दस्तावेज़ की [[शैली]] के अनुरूप होने चाहिए। '[[चंकिंग (मनोविज्ञान)|चंकिंग (फिलॉसफी)]]' एक उपयोगी रणनीति है जिसमें जानकारी को छोटे-छोटे टुकड़ों में तोड़ना सम्मिलित है जिन्हें किसी प्रकार के सार्थक क्रम या [[पदानुक्रम]] में व्यवस्थित किया जा सकता है। दस्तावेज़ को [[स्किमिंग (पढ़ना)]]पढ़ने) की क्षमता यूजरओं को पढ़ने के बजाय स्कैन करके अपनी जानकारी का टुकड़ा ढूंढने की अनुमति देती है। इसके लिए अक्सर [[ बोल्ड अक्षरों ]] और [[इटैलिक प्रकार]] के शब्दों का उपयोग किया जाता है। | ||
=== सुपाठ्यता === | === सुपाठ्यता === | ||
पाठ को पढ़ना आसान होना चाहिए: अलंकारिक स्थिति के विश्लेषण के माध्यम से, डिजाइनर को एक उपयोगी [[फ़ॉन्ट]]-परिवार और फ़ॉन्ट शैली निर्धारित करने में सक्षम होना चाहिए। सजावटी फ़ॉन्ट, सभी [[बड़े अक्षर]]ों में पाठ, बड़े या छोटे मुख्य भाग वाले पाठ को पढ़ना कठिन हो सकता है और इससे बचना चाहिए। टेक्स्ट-भारी परिदृश्यों में उपयोग किए जाने पर टेक्स्ट-रंग और बोल्डिंग सहायक हो सकते हैं। पाठ और पृष्ठभूमि के | पाठ को पढ़ना आसान होना चाहिए: अलंकारिक स्थिति के विश्लेषण के माध्यम से, डिजाइनर को एक उपयोगी [[फ़ॉन्ट]]-परिवार और फ़ॉन्ट शैली निर्धारित करने में सक्षम होना चाहिए। सजावटी फ़ॉन्ट, सभी [[बड़े अक्षर]]ों में पाठ, बड़े या छोटे मुख्य भाग वाले पाठ को पढ़ना कठिन हो सकता है और इससे बचना चाहिए। टेक्स्ट-भारी परिदृश्यों में उपयोग किए जाने पर टेक्स्ट-रंग और बोल्डिंग सहायक हो सकते हैं। पाठ और पृष्ठभूमि के मध्य उच्च आकृति-जमीन [[कंट्रास्ट (दृष्टि)]] सुपाठ्यता बढ़ाता है। हल्के पृष्ठभूमि पर गहरा पाठ सबसे अधिक सुपाठ्य है। | ||
=== भाषा === | === भाषा === | ||
अलंकारिक स्थिति के आधार पर, कुछ प्रकार की भाषाओं की आवश्यकता होती है। छोटे वाक्य सहायक होते हैं, जैसे अच्छी | अलंकारिक स्थिति के आधार पर, कुछ प्रकार की भाषाओं की आवश्यकता होती है। छोटे वाक्य सहायक होते हैं, जैसे अच्छी प्रकार से लिखे गए पाठ स्पष्टीकरण और समान थोक-पाठ स्थितियों में उपयोग किए जाते हैं। जब तक स्थिति की आवश्यकता न हो, [[शब्दजाल]] या भारी तकनीकी शब्दों का प्रयोग नहीं किया जाना चाहिए। कई लेखक [[सक्रिय आवाज]]़, क्रिया ([[संज्ञा वाक्यांश]] या [[नाममात्र (भाषाविज्ञान)]] के बजाय) और एक सरल वाक्य संरचना का उपयोग करना चुनेंगे। | ||
== विश्लेषण उपकरण == | == विश्लेषण उपकरण == | ||
Line 76: | Line 76: | ||
=== व्यक्तित्व === | === व्यक्तित्व === | ||
यूसीडी प्रक्रिया के समय, यूजर का प्रतिनिधित्व करने वाला एक [[व्यक्तित्व (उपयोगकर्ता अनुभव)|व्यक्तित्व (यूजर अनुभव)]] बनाया जा सकता है। पर्सोना (यूजर अनुभव) एक यूजर आदर्श है जिसका उपयोग प्रोडक्ट सुविधाओं, नेविगेशन, इंटरैक्शन और यहां तक कि विज़ुअल डिज़ाइन के बारे में निर्णय लेने में सहायता के लिए किया जाता है। ज्यादातर मामलों में, पर्सोना (यूजर अनुभव) को एक्चुअल लोगों के साथ [[नृवंशविज्ञान]] साक्षात्कार की एक श्रृंखला से संश्लेषित किया जाता है, फिर 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" | ||
Line 122: | Line 122: | ||
| audience applause | | audience applause | ||
|} | |} | ||
अभिनेता और दुनिया के | अभिनेता और दुनिया के मध्य की बातचीत एक ऐसा कार्य है जिसे रोजमर्रा की जिंदगी में देखा जा सकता है, और हम इसे सामान्य रूप से लेते हैं और संगीत के एक टुकड़े को प्रस्तुत करने जैसे कार्य के लिए होने वाली छोटी-छोटी बातों के बारे में बहुत अधिक नहीं सोचते हैं। अस्तित्व के लिए। यह इस तथ्य के समान है कि अपनी मातृभाषा बोलते समय, हम व्याकरण और शब्दों को कैसे वाक्यांशबद्ध करें, इसके बारे में बहुत अधिक नहीं सोचते हैं; वे बस बाहर आ जाते हैं क्योंकि हम उन्हें कहने के इतने आदी हो गए हैं। इस मामले में एक अभिनेता और दुनिया, विशेष रूप से, प्राथमिक हितधारक (यूजर) और दुनिया के मध्य की गतिविधियों के बारे में विस्तार से सोचा जाना चाहिए, और इसलिए यह समझने के लिए उपयोग के मामले बनाए जाते हैं कि ये छोटी बातचीत कैसे होती हैं। | ||
एक आवश्यक उपयोग मामला एक विशेष प्रकार का उपयोग मामला है, जिसे अमूर्त उपयोग मामला भी कहा जाता है। आवश्यक उपयोग के मामले समस्या के सार का वर्णन करते हैं, और समस्या की प्रकृति से ही संबंधित होते हैं। आवश्यक उपयोग के मामले लिखते समय, असंबद्ध विवरणों के बारे में कोई धारणा नहीं बनाई जानी चाहिए। इसके | एक आवश्यक उपयोग मामला एक विशेष प्रकार का उपयोग मामला है, जिसे अमूर्त उपयोग मामला भी कहा जाता है। आवश्यक उपयोग के मामले समस्या के सार का वर्णन करते हैं, और समस्या की प्रकृति से ही संबंधित होते हैं। आवश्यक उपयोग के मामले लिखते समय, असंबद्ध विवरणों के बारे में कोई धारणा नहीं बनाई जानी चाहिए। इसके अतिरिक्त, उस विशेष गोल तक पहुंचने के लिए विषय के गोलों को प्रक्रिया और कार्यान्वयन से अलग किया जाना चाहिए। नीचे पिछले उदाहरण के समान गोल के साथ एक आवश्यक उपयोग के मामले का एक उदाहरण दिया गया है। | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 151: | Line 151: | ||
| | | | ||
|} | |} | ||
उपयोग के मामले उपयोगी हैं क्योंकि वे डिज़ाइन कार्य के उपयोगी स्तरों की पहचान करने में | उपयोग के मामले उपयोगी हैं क्योंकि वे डिज़ाइन कार्य के उपयोगी स्तरों की पहचान करने में सहायता करते हैं। वे डिजाइनरों को एक्चुअल निम्न स्तर की प्रक्रियाओं को देखने की अनुमति देते हैं जो एक निश्चित समस्या में सम्मिलित हैं, जिससे समस्या को संभालना आसान हो जाता है, क्योंकि यूजर द्वारा किए गए कुछ छोटे कदम और विवरण सामने आ जाते हैं। डिजाइनरों का काम इन छोटी-छोटी समस्याओं पर विचार करना होना चाहिए जिससे अंतिम समाधान तक पहुंच सकें जो कारगर हो। इसे कहने का दूसरा तरीका यह है कि उपयोग के मामले जटिल टास्क को छोटे बिट्स में तोड़ देते हैं, जहां ये बिट्स उपयोगी इकाइयां हैं। प्रत्येक बिट एक छोटा कार्य पूर्ण करता है, जो फिर अंतिम बड़े कार्य का निर्माण करता है। कंप्यूटर पर कोड लिखने की प्रकार, पूर्ण कोड को प्रारम्भ से ही निपटाने के बजाय, बुनियादी छोटे भागों को लिखना और पूर्व उन्हें काम पर लगाना और फिर बड़े और अधिक जटिल कोड को समाप्त करने के लिए उन्हें एक साथ रखना आसान होता है। | ||
पहला समाधान कम जोखिम भरा है क्योंकि यदि कोड में कुछ गलत होता है, तो समस्या को छोटे बिट्स में देखना आसान होता है, क्योंकि समस्या वाला खंड वह होगा जो काम नहीं करता है, जबकि पश्चात वाले समाधान में, प्रोग्रामर को एक त्रुटि खोजने के लिए | पहला समाधान कम जोखिम भरा है क्योंकि यदि कोड में कुछ गलत होता है, तो समस्या को छोटे बिट्स में देखना आसान होता है, क्योंकि समस्या वाला खंड वह होगा जो काम नहीं करता है, जबकि पश्चात वाले समाधान में, प्रोग्रामर को एक त्रुटि खोजने के लिए पूर्ण कोड को देखना पड़ सकता है, जो समय लेने वाला साबित होता है। यूसीडी में उपयोग के मामले लिखने के लिए भी यही तर्क लागू होता है। अंत में, उपयोग के मामले उपयोगी और महत्वपूर्ण टास्क को बताते हैं जहां डिजाइनर अब देख सकते हैं कि कौन सा दूसरों की तुलना में अधिक महत्वपूर्ण है। लेखन उपयोग के मामलों की कुछ कमियों में यह तथ्य सम्मिलित है कि अभिनेता या दुनिया द्वारा की गई प्रत्येक क्रिया में थोड़ा विवरण होता है, और यह बस एक छोटी सी क्रिया होती है। इससे संभवतः आगे की कल्पना और विभिन्न डिजाइनरों की कार्रवाई की अलग-अलग व्याख्या हो सकती है। | ||
साथ ही, इस प्रक्रिया के समय, किसी कार्य को अत्यधिक सरल बनाना वास्तव में आसान होता है, क्योंकि किसी बड़े कार्य से प्राप्त छोटे कार्य में अभी भी छूटे हुए छोटे कार्य भी सम्मिलित हो सकते हैं। गिटार चुनने में यह सोचना सम्मिलित हो सकता है कि कौन सा गिटार उठाया जाए, कौन सा गिटार इस्तेमाल किया जाए, और सबसे | साथ ही, इस प्रक्रिया के समय, किसी कार्य को अत्यधिक सरल बनाना वास्तव में आसान होता है, क्योंकि किसी बड़े कार्य से प्राप्त छोटे कार्य में अभी भी छूटे हुए छोटे कार्य भी सम्मिलित हो सकते हैं। गिटार चुनने में यह सोचना सम्मिलित हो सकता है कि कौन सा गिटार उठाया जाए, कौन सा गिटार इस्तेमाल किया जाए, और सबसे पूर्व यह सोचें कि गिटार कहाँ स्थित है। फिर इन टास्क को छोटे-छोटे टास्क में विभाजित किया जा सकता है, जैसे कि पूर्व यह सोचना कि गिटार का कौन सा रंग उस स्थान पर फिट बैठता है, और अन्य संबंधित विवरण। टास्क को और भी छोटे टास्क में विभाजित किया जा सकता है, और यह डिजाइनर पर निर्भर है कि वह यह निर्धारित करे कि टास्क को विभाजित करने से रोकने के लिए उपयुक्त स्थान कौन सा है। टास्क को न केवल अत्यधिक सरलीकृत किया जा सकता है, बल्कि उन्हें पूरी प्रकार से छोड़ा भी जा सकता है, इस प्रकार डिज़ाइनर को उपयोग के मामलों को लिखते समय किसी घटना या कार्रवाई में सम्मिलित सभी विवरणों और सभी प्रमुख स्टेजों के बारे में पता होना चाहिए। | ||
== यह भी देखें == | == यह भी देखें == |
Revision as of 23:49, 7 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 ह्यूमन सेंटर्ड डिज़ाइन, आईडीईओ के डेविड केली
- यूजर सेंटर्ड डिज़ाइन, डॉन नॉर्मन
श्रेणी:ह्यूमन-कंप्यूटर संपर्क श्रेणी:यूजर-जनित सामग्री श्रेणी:डिज़ाइन श्रेणी:यूएसएबिलिटीता श्रेणी:तकनीकी संचार