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

From Vigyanwiki
No edit summary
No edit summary
Line 3: Line 3:
{{See also|Human-centered design}}
{{See also|Human-centered design}}


'''यूजर-सेंटर्ड डिज़ाइन''' (यूसीडी) या यूजर-संचालित विकास (यूडीडी) प्रक्रिया का फ्रेमवर्क है (इंटरफ़ेस या टेक्नोलॉजी तक सीमित नहीं) जिसमें [[प्रयोज्य|यूएसएबिलिटी]] लक्ष्य, यूजर विशेषताएँ, [[पर्यावरण (सिस्टम)]], कार्य और किसी [[उत्पाद (व्यवसाय)|प्रोडक्ट (व्यवसाय)]] का वर्कफ़्लो सम्मिलित होता है। [[डिज़ाइन प्रक्रिया]] के प्रत्येक चरण में सर्विस या प्रक्रिया पर व्यापक ध्यान दिया जाता है। ये परीक्षण आवश्यकताओं, प्री-प्रोडक्शन मॉडल और प्रोडक्शन के पश्चात की प्रक्रिया के प्रत्येक चरण के समय एक्चुअल यूजरओं के साथ/बिना आयोजित किए जाते हैं, जो प्रूफ के सर्कल को पूर्ण करते हैं और यह सुनिश्चित करते हैं कि विकास यूजर को फोकस के केंद्र के रूप में आगे बढ़ाता है।<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" />


== इतिहास ==
== इतिहास ==
Line 19: Line 19:
== मॉडल और दृष्टिकोण ==
== मॉडल और दृष्टिकोण ==


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


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


== यूजर-सेंटर्ड डिज़ाइन प्रक्रिया ==
== यूजर-सेंटर्ड डिज़ाइन प्रक्रिया ==
यूजर-सेंटर्ड डिज़ाइन का लक्ष्य ऐसे प्रोडक्ट बनाना है जिनकी उपयोगिता बहुत अधिक हो। इसमें यह सम्मिलित है कि प्रोडक्ट अपने उपयोग, प्रबंधनीयता, प्रभावशीलता के कॉन्टेक्स्ट में कितना सुविधाजनक है और प्रोडक्ट यूजर की आवश्यकताओं के अनुरूप कितना अच्छा है। यूजर-सेंटर्ड डिज़ाइन प्रक्रिया के सामान्य चरण नीचे दिए गए हैं:<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>
# उपयोग का कॉन्टेक्स्ट निर्दिष्ट करें: पहचानें कि प्रोडक्ट के प्राथमिक यूजर कौन हैं, वे प्रोडक्ट का उपयोग क्यों करेंगे, उनकी आवश्यकताएं क्या हैं और वे किस वातावरण में इसका उपयोग करेंगे।
# उपयोग का कॉन्टेक्स्ट निर्दिष्ट करें: पहचानें कि प्रोडक्ट के प्राथमिक यूजर कौन हैं, वे प्रोडक्ट का उपयोग क्यों करेंगे, उनकी आवश्यकताएं क्या हैं और वे किस वातावरण में इसका उपयोग करेंगे।
# आवश्यकताएं निर्दिष्ट करें: एक बार कॉन्टेक्स्ट निर्दिष्ट हो जाने के पश्चात, प्रोडक्ट की विस्तृत आवश्यकताओं की पहचान करने का समय आ गया है। यह एक महत्वपूर्ण चरण है जो डिजाइनरों को स्टोरीबोर्ड बनाने और प्रोडक्ट को सफल बनाने के लिए महत्वपूर्ण लक्ष्य निर्धारित करने में और सुविधा प्रदान कर सकता है।
# आवश्यकताएं निर्दिष्ट करें: एक बार कॉन्टेक्स्ट निर्दिष्ट हो जाने के पश्चात, प्रोडक्ट की विस्तृत रिक्वायरमेंट्स की पहचान करने का समय आ गया है। यह एक महत्वपूर्ण स्टेज है जो डिजाइनरों को स्टोरीबोर्ड बनाने और प्रोडक्ट को सफल बनाने के लिए महत्वपूर्ण गोल निर्धारित करने में और सुविधा प्रदान कर सकता है।
# डिज़ाइन समाधान और विकास बनाएं: प्रोडक्ट लक्ष्यों और आवश्यकताओं के आधार पर, प्रोडक्ट डिज़ाइन और विकास की एक पुनरावृत्त डिज़ाइन प्रक्रिया शुरू करें।
# डिज़ाइन समाधान और विकास बनाएं: प्रोडक्ट गोलों और रिक्वायरमेंट्स के आधार पर, प्रोडक्ट डिज़ाइन और विकास की एक पुनरावृत्त डिज़ाइन प्रक्रिया शुरू करें।
# प्रोडक्ट का मूल्यांकन करें: प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के हर चरण में प्रोडक्ट के लिए यूजरओं की प्रतिक्रिया प्राप्त करने के लिए यूएसएबिलिटी परीक्षण करते हैं।
# प्रोडक्ट का मूल्यांकन करें: प्रोडक्ट डिजाइनर यूजर-सेंटर्ड डिज़ाइन के हर स्टेज में प्रोडक्ट के लिए यूजरओं की प्रतिक्रिया प्राप्त करने के लिए यूएसएबिलिटी परीक्षण करते हैं।
अगले चरणों में, प्रोडक्ट को और बेहतर बनाने के लिए उपरोक्त प्रक्रिया दोहराई जाती है। ये चरण सामान्य दृष्टिकोण और कारक हैं जैसे डिज़ाइन लक्ष्य, टीम और उनकी समयरेखा, और वह वातावरण जिसमें प्रोडक्ट विकसित किया गया है, किसी परियोजना और उनके क्रम के लिए उपयुक्त चरण निर्धारित करते हैं। आप या तो [[झरना मॉडल]], एजाइल प्रबंधन मॉडल या किसी अन्य [[सॉफ्टवेयर इंजीनियरिंग]] अभ्यास का पालन कर सकते हैं।
अगले स्टेजों में, प्रोडक्ट को और बेहतर बनाने के लिए उपरोक्त प्रक्रिया दोहराई जाती है। ये स्टेज सामान्य दृष्टिकोण और कारक हैं जैसे डिज़ाइन गोल, टीम और उनकी समयरेखा, और वह वातावरण जिसमें प्रोडक्ट विकसित किया गया है, किसी परियोजना और उनके क्रम के लिए उपयुक्त स्टेज निर्धारित करते हैं। आप या तो [[झरना मॉडल]], एजाइल प्रबंधन मॉडल या किसी अन्य [[सॉफ्टवेयर इंजीनियरिंग]] अभ्यास का पालन कर सकते हैं।


== उद्देश्य ==
== उद्देश्य ==


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


=== व्यक्तित्व ===
=== व्यक्तित्व ===
यूसीडी प्रक्रिया के समय, यूजर का प्रतिनिधित्व करने वाला एक [[व्यक्तित्व (उपयोगकर्ता अनुभव)|व्यक्तित्व (यूजर अनुभव)]] बनाया जा सकता है। पर्सोना (यूजर अनुभव) एक यूजर आदर्श है जिसका उपयोग प्रोडक्ट सुविधाओं, नेविगेशन, इंटरैक्शन और यहां तक ​​कि विज़ुअल डिज़ाइन के बारे में निर्णय लेने में सहायता के लिए किया जाता है। ज्यादातर मामलों में, पर्सोना (यूजर अनुभव) को एक्चुअल लोगों के साथ [[नृवंशविज्ञान]] साक्षात्कार की एक श्रृंखला से संश्लेषित किया जाता है, फिर 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>
प्रत्येक प्रोडक्ट के लिए, या कभी-कभी किसी प्रोडक्ट के भीतर उपकरणों के प्रत्येक सेट के लिए, व्यक्तित्वों का एक छोटा सा सेट होता है, जिनमें से एक डिज़ाइन के लिए प्राथमिक फोकस होता है। ऐसा भी होता है जिसे [[द्वितीयक व्यक्तित्व]] कहा जाता है, जहां चरित्र डिजाइन का मुख्य लक्ष्य नहीं होता है, लेकिन उनकी जरूरतों को पूर्ण किया जाना चाहिए और यदि संभव हो तो समस्याओं का समाधान किया जाना चाहिए। वे आगे की संभावित समस्याओं और कठिनाइयों का समाधान करने में मदद करने के लिए मौजूद हैं, भले ही प्राथमिक व्यक्ति उनके समाधान से संतुष्ट हो। इसमें एक विरोधी व्यक्तित्व भी है, जो वह चरित्र है जिसके लिए डिज़ाइन विशेष रूप से नहीं बनाया गया है।
प्रत्येक प्रोडक्ट के लिए, या कभी-कभी किसी प्रोडक्ट के भीतर उपकरणों के प्रत्येक सेट के लिए, व्यक्तित्वों का एक छोटा सा सेट होता है, जिनमें से एक डिज़ाइन के लिए प्राथमिक फोकस होता है। ऐसा भी होता है जिसे [[द्वितीयक व्यक्तित्व]] कहा जाता है, जहां चरित्र डिजाइन का मुख्य गोल नहीं होता है, लेकिन उनकी जरूरतों को पूर्ण किया जाना चाहिए और यदि संभव हो तो समस्याओं का समाधान किया जाना चाहिए। वे आगे की संभावित समस्याओं और कठिनाइयों का समाधान करने में मदद करने के लिए मौजूद हैं, भले ही प्राथमिक व्यक्ति उनके समाधान से संतुष्ट हो। इसमें एक विरोधी व्यक्तित्व भी है, जो वह चरित्र है जिसके लिए डिज़ाइन विशेष रूप से नहीं बनाया गया है।


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


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


{| class="wikitable"
{| class="wikitable"
Line 124: Line 124:
अभिनेता और दुनिया के बीच की बातचीत एक ऐसा कार्य है जिसे रोजमर्रा की जिंदगी में देखा जा सकता है, और हम इसे सामान्य रूप से लेते हैं और संगीत के एक टुकड़े को प्रस्तुत करने जैसे कार्य के लिए होने वाली छोटी-छोटी बातों के बारे में बहुत अधिक नहीं सोचते हैं। अस्तित्व के लिए। यह इस तथ्य के समान है कि अपनी मातृभाषा बोलते समय, हम व्याकरण और शब्दों को कैसे वाक्यांशबद्ध करें, इसके बारे में बहुत अधिक नहीं सोचते हैं; वे बस बाहर आ जाते हैं क्योंकि हम उन्हें कहने के इतने आदी हो गए हैं। इस मामले में एक अभिनेता और दुनिया, विशेष रूप से, प्राथमिक हितधारक (यूजर) और दुनिया के बीच की गतिविधियों के बारे में विस्तार से सोचा जाना चाहिए, और इसलिए यह समझने के लिए उपयोग के मामले बनाए जाते हैं कि ये छोटी बातचीत कैसे होती हैं।
अभिनेता और दुनिया के बीच की बातचीत एक ऐसा कार्य है जिसे रोजमर्रा की जिंदगी में देखा जा सकता है, और हम इसे सामान्य रूप से लेते हैं और संगीत के एक टुकड़े को प्रस्तुत करने जैसे कार्य के लिए होने वाली छोटी-छोटी बातों के बारे में बहुत अधिक नहीं सोचते हैं। अस्तित्व के लिए। यह इस तथ्य के समान है कि अपनी मातृभाषा बोलते समय, हम व्याकरण और शब्दों को कैसे वाक्यांशबद्ध करें, इसके बारे में बहुत अधिक नहीं सोचते हैं; वे बस बाहर आ जाते हैं क्योंकि हम उन्हें कहने के इतने आदी हो गए हैं। इस मामले में एक अभिनेता और दुनिया, विशेष रूप से, प्राथमिक हितधारक (यूजर) और दुनिया के बीच की गतिविधियों के बारे में विस्तार से सोचा जाना चाहिए, और इसलिए यह समझने के लिए उपयोग के मामले बनाए जाते हैं कि ये छोटी बातचीत कैसे होती हैं।


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


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


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


== यह भी देखें ==
== यह भी देखें ==

Revision as of 21:24, 7 October 2023

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

इतिहास

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

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

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

पश्चात की किताब, भावनात्मक डिज़ाइन में,[7]: p.5 onwards  नॉर्मन अपने पहले के कुछ विचारों की ओर लौटकर विस्तार से बताता है कि उसे जो कुछ अत्यधिक घटिया लगा था।

मॉडल और दृष्टिकोण

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

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

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

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

  1. डिज़ाइन यूजरओं, कार्यों और वातावरण की स्पष्ट समझ पर आधारित है।
  2. यूजर डिज़ाइन और विकास के समय सम्मिलित होते हैं।[12]
  3. डिज़ाइन यूजर-सेंटर्ड मूल्यांकन द्वारा संचालित और परिष्कृत होता है।
  4. प्रक्रिया पुनरावर्ती है.
  5. डिज़ाइन संपूर्ण यूजर अनुभव को संबोधित करता है।
  6. डिज़ाइन टीम में बहु-विषयक कौशल और दृष्टिकोण सम्मिलित हैं।

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

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

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

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

उद्देश्य

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

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

तत्व

यूसीडी दृष्टिकोण के उदाहरण के रूप में, किसी वेबसाइट के यूसीडी के आवश्यक तत्व आमतौर पर दृश्यता, पहुंच, सुपाठ्यता और भाषा के विचार हैं।

दृश्यता

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

अभिगम्यता

यूजरओं को पूरे दस्तावेज़ में जानकारी जल्दी और आसानी से ढूंढने में सक्षम होना चाहिए, चाहे उसकी लंबाई कुछ भी हो। यूजरओं को जानकारी खोजने के विभिन्न तरीकों की पेशकश की जानी चाहिए (जैसे कि नेविगेशनल तत्व, खोज फ़ंक्शन, सामग्री की तालिका,[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

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

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

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

यह भी देखें

कॉन्टेक्स्ट

  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.

अग्रिम पठन

वीडियो

श्रेणी:मानव-कंप्यूटर संपर्क श्रेणी:यूजर-जनित सामग्री श्रेणी:डिज़ाइन श्रेणी:यूएसएबिलिटीता श्रेणी:तकनीकी संचार