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