UX की बुनियादी बातें

यूएक्स डिज़ाइन की बुनियादी बातों के बारे में सिलसिलेवार निर्देश.

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

यह गाइड, डिज़ाइन स्प्रिंट की प्रोसेस पर आधारित है. Google की कई टीमें, समस्याओं को हल करने और चुनौतियों से निपटने के लिए इस प्रोसेस का इस्तेमाल करती हैं. जैसे, सेल्फ़ ड्राइविंग कार और प्रोजेक्ट लून.

डबल डायमंड

यह फ़्लो, UX सर्कल में डबल डायमंड के नाम से मशहूर है. इसे ब्रिटिश डिज़ाइन काउंसिल ने लोकप्रिय बनाया है. इसमें आपकी टीम, रिसर्च के ज़रिए किसी आइडिया को समझने के लिए अलग-अलग दिशाओं में काम करती है. इसके बाद, समस्या को तय करने के लिए एक साथ आती है. फिर, अलग-अलग दिशाओं में काम करके, आइडिया को स्केच करती है और उसे शेयर करती है. इसके बाद, आगे बढ़ने का सबसे सही तरीका तय करती है, टेस्ट करती है, और पुष्टि करती है.

प्रोजेक्ट के चरणों में ये शामिल हैं: समझना, तय करना, अलग-अलग आइडिया पर काम करना, फ़ैसला लेना, प्रोटोटाइप बनाना, और पुष्टि करना.
ब्रिटिश डिज़ाइन काउंसिल ने 'डबल डायमंड' डिज़ाइन प्रोसेस मॉडल को पेश किया था. इसमें किसी प्रोजेक्ट के ये चरण शामिल होते हैं; समझना, तय करना, अलग-अलग आइडिया पर काम करना, फ़ैसला लेना, प्रोटोटाइप बनाना, और पुष्टि करना.

माहौल बनाना

सबसे पहले, आपको जिस समस्या का समाधान करना है उसे पहचानें और उसे एक प्रस्ताव की तरह लिखें. खुद से पूछें, “मुझे असल में किस समस्या का समाधान करना है?”. समस्या का स्टेटमेंट, प्रोजेक्ट के लिए सेट किया गया ब्रीफ़ होता है. इसमें आपका लक्ष्य शामिल होता है.

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

ये कुछ ऐसे प्रॉडक्ट के उदाहरण हैं जिन पर मैंने पहले काम किया है;

  • पैरों के पंजे मुड़े होने की समस्या से पीड़ित मरीज़ों के इलाज और फ़ॉलो-अप केयर को मैनेज करने के लिए, एक सिस्टम डिज़ाइन करें.

  • एक ऐसा ऐप्लिकेशन बनाएं जो मुश्किल वित्तीय सिस्टम को आसान बनाए और उन्हें ज़रूरी चीज़ों तक सीमित करे.

  • ब्रैंड की पहचान को बनाए रखते हुए, अलग-अलग प्लैटफ़ॉर्म के लिए एक जैसा मोबाइल ऐप्लिकेशन डिज़ाइन करें.

चैलेंज स्टेटमेंट को अपडेट करना

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

  • इस साल की पहली तिमाही में लॉन्च करने के लिए, एक ऐसा सिस्टम डिज़ाइन करें जिससे दो साल से कम उम्र के बच्चों के पैरों के पंजे मुड़े होने की समस्या का इलाज और फ़ॉलो-अप केयर को मैनेज किया जा सके.
  • जुलाई 2017 में लॉन्च किया गया, फ़ाइनेंस से जुड़ा एक आसान ऐप्लिकेशन बनाएं. इसकी मदद से, फ़ाइनेंस की दुनिया के बारे में पहले से जानकारी न होने पर भी, सिर्फ़ एक बटन पर टैप करके शेयर खरीदे और बेचे जा सकते हैं.
  • इस साल के आखिर तक, एक ऐसी डिज़ाइन गाइड तैयार करें जिसे कई प्लैटफ़ॉर्म पर इस्तेमाल किया जा सके. साथ ही, हर प्लैटफ़ॉर्म पर कंपनी के ब्रैंड को असरदार तरीके से पेश किया जा सके.

चुनौती का स्टेटमेंट पूरा होने के बाद, उसे किसी ऐसी जगह पर दिखाएं जहां वह आसानी से दिख सके. इससे आपको काम करते समय उसे देखने में आसानी होगी. आपको बार-बार इसे देखना होगा. साथ ही, हो सकता है कि आपको पूरे प्रोजेक्ट के दौरान इसे अपडेट करना पड़े या इसमें बदलाव करना पड़े.

समस्या की पुष्टि करना

अगला चरण, चुनौती पर रिसर्च करना और समस्या के बारे में जानना है. आपको यह पता लगाना होगा कि समस्या के बारे में आपकी टीम की समझ सही है या नहीं. अक्सर हम समस्याओं को अपने नज़रिए से देखते हैं, जो कि खतरनाक है. ऐसा इसलिए, क्योंकि हममें से ज़्यादातर लोग टेक के जानकार उपयोगकर्ता हैं और असल में उपयोगकर्ताओं की संख्या बहुत कम है. हम मुखर अल्पसंख्यक हैं और हमें यह सोचने के लिए मूर्ख बनाया जा सकता है कि कुछ वास्तव में एक समस्या है जब यह नहीं है.

चैलेंज की पुष्टि करने के लिए, डेटा इकट्ठा करने के कई तरीके हैं. हर तरीका आपकी टीम और इस बात पर निर्भर करता है कि आपके पास उपयोगकर्ताओं का ऐक्सेस है या नहीं. इसका मकसद, समस्या को बेहतर तरीके से समझना है.

स्टेकहोल्डर के साथ इंटरनल इंटरव्यू

स्टेकहोल्डर के साथ इंटरव्यू करने से, किसी कंपनी या टीम के बारे में अहम जानकारी मिल सकती है.
स्टेकहोल्डर के इंटरव्यू से, किसी कंपनी या टीम के बारे में अहम जानकारी मिल सकती है.

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

एक चेतावनी है. पुष्टि करने के इस तरीके को सबसे कम पसंद किया जाता है, क्योंकि इससे टीम के बीच चर्चा और साथ मिलकर काम करने में रुकावट आती है. इससे संगठन में एक अलग माहौल बन सकता है. हालांकि, इससे क्लाइंट और डिज़ाइन से जुड़ी चुनौतियों के बारे में कुछ अच्छी जानकारी मिल सकती है, जो शायद आपको न मिल पाती.

लाइटनिंग टॉक

लाइटनिंग टॉक, कुछ मिनटों की एक छोटी सी प्रज़ेंटेशन होती है.
लाइटनिंग टॉक, कुछ मिनटों का एक छोटा प्रज़ेंटेशन होता है.

यह इंटरनल इंटरव्यू की तरह ही है, लेकिन इस बार आपको हर स्टेकहोल्डर को एक ही रूम में लाना होगा. इसके बाद, इनमें से पांच या छह स्टेकहोल्डर (मार्केटिंग, सेल्स, डिज़ाइन, खाते, रिसर्च वगैरह) को चुनें, ताकि वे अपने नज़रिए से समस्या पर बात कर सकें. हर स्टेकहोल्डर को ज़्यादा से ज़्यादा 10 मिनट का समय दें. उन्हें अपने प्रज़ेंटेशन में ये विषय शामिल करने चाहिए:

  • कारोबार के लक्ष्य
  • उनके नज़रिए से प्रोजेक्ट की चुनौतियां (ये तकनीकी, रिसर्च इकट्ठा करने, डिज़ाइन बनाने वगैरह से जुड़ी हो सकती हैं…)
  • उपयोगकर्ताओं पर की गई रिसर्च का डेटा, जो फ़िलहाल आपके पास है

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

उपयोगकर्ता के इंटरव्यू

उपयोगकर्ताओं के इंटरव्यू, किसी भी टास्क में आने वाली समस्याओं के बारे में जानने का एक बेहतरीन तरीका है.
उपयोगकर्ताओं के इंटरव्यू, किसी भी टास्क में उनकी समस्याओं के बारे में जानने का एक बेहतरीन तरीका है.

उपयोगकर्ता की यात्रा, समस्याओं, और फ़्लो के बारे में जानने का यह शायद सबसे अच्छा तरीका है. कम से कम पांच उपयोगकर्ताओं के इंटरव्यू लें. अगर आपके पास ज़्यादा उपयोगकर्ताओं का ऐक्सेस है, तो ज़्यादा इंटरव्यू लें. आपको उनसे इस तरह के सवाल पूछने चाहिए:

  • वे किसी मौजूदा टास्क को कैसे पूरा करते हैं? उदाहरण के लिए, मान लें कि आपको ऊपर दिए गए फ़ाइनेंस ऐप्लिकेशन के लिए समस्या हल करनी है, तो उनसे पूछा जा सकता है कि “फ़िलहाल, शेयर और स्टॉक कैसे खरीदे जाते हैं?”
  • उन्हें इस फ़्लो के बारे में क्या पसंद है?
  • उन्हें इस फ़्लो के बारे में क्या पसंद नहीं है?
  • उपयोगकर्ता फ़िलहाल, इससे मिलते-जुलते कौनसे प्रॉडक्ट इस्तेमाल करता है?
    • उन्हें क्या पसंद है?
    • उन्हें क्या पसंद नहीं है?
  • अगर उनके पास कोई जादुई छड़ी होती और वे इस प्रोसेस में कोई एक बदलाव कर पाते, तो वह क्या होता?

इंटरव्यू का मकसद, उपयोगकर्ता से उसकी समस्याओं के बारे में जानना है. यह आपके लिए चर्चा का विषय नहीं है. इसलिए, आपको जितना हो सके उतना शांत रहना चाहिए. यह बात तब भी लागू होती है, जब कोई उपयोगकर्ता बोलना बंद कर दे. हमेशा कुछ देर इंतज़ार करें, क्योंकि हो सकता है कि वह अपने विचारों को इकट्ठा कर रहा हो. आपको यह जानकर हैरानी होगी कि कुछ सेकंड के लिए रुकने के बाद, कोई व्यक्ति कितनी देर तक बोलता रहेगा.

इंटरव्यू के दौरान नोट लें. अगर हो सके, तो बातचीत को रिकॉर्ड करें, ताकि कोई भी जानकारी छूट न जाए. इसका मकसद, इकट्ठा की गई उपयोगकर्ता की अहम जानकारी की तुलना, समस्या से करना है. क्या वे अलाइन हैं? क्या आपको कुछ ऐसा पता चला जिससे आपको अपनी समस्या के बारे में बताने वाले स्टेटमेंट को अपडेट करने में मदद मिले?

एथनोग्राफ़िक फ़ील्ड रिसर्च

उपयोगकर्ताओं को उनके सामान्य माहौल में देखना, यह समझने का एक शानदार तरीका है कि वे अपनी समस्याओं को कैसे हल करते हैं.
उपयोगकर्ताओं को उनके सामान्य माहौल में देखने से, यह समझने में मदद मिलती है कि वे अपनी समस्याओं को कैसे हल करते हैं.

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

इस तकनीक में आम तौर पर, लंबे समय तक काम करना पड़ता है. साथ ही, प्रोजेक्ट के इस हिस्से को लीड करने के लिए एक रिसर्चर की ज़रूरत होती है. हालांकि, यह शायद सबसे अहम है, क्योंकि इसमें आपको लोगों के उस ग्रुप को देखने का मौका मिलता है जिसकी स्टडी उनके नैचुरल एनवायरमेंट में की जा रही है.

सभी जानकारी को एक साथ इकट्ठा करना

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

जब आपको काफ़ी सुझाव और अहम जानकारी मिल जाए, तो उस जानकारी का इस्तेमाल करके प्रोजेक्ट मैप बनाएं.

प्रोजेक्ट मैप

जिस समस्या को हल करने की कोशिश की जा रही है उसमें आम तौर पर अलग-अलग तरह के लोग (या खिलाड़ी) शामिल होते हैं. इनमें से हर व्यक्ति की प्रोजेक्ट के फ़्लो में हिस्सेदारी होती है. अपनी सीख के आधार पर, आपको संभावित खिलाड़ियों की सूची बनानी होगी. यह कोई उपयोगकर्ता या स्टेकहोल्डर हो सकता है. जैसे, “पैरों के पंजे मुड़े होने की समस्या का इलाज करने वाला डॉक्टर”, “पैरों के पंजे मुड़े होने की समस्या से पीड़ित मरीज़”, “मरीज़ की देखभाल करने वाला व्यक्ति” वगैरह… हर प्लेयर का नाम, कागज़ की शीट पर बाईं ओर लिखें. अगर आपके पास व्हाइटबोर्ड है, तो उस पर लिखें. दाईं ओर, हर खिलाड़ी के गोल लिखें.

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

प्रोजेक्ट मैप, किसी फ़्लो में हर उपयोगकर्ता या खिलाड़ी के लिए मुख्य चरणों को प्लॉट करते हैं.
प्रोजेक्ट मैप, फ़्लो में हर उपयोगकर्ता या खिलाड़ी के लिए मुख्य चरणों को प्लॉट करते हैं.

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

वायरफ़्रेमिंग और स्टोरीबोर्डिंग

Crazy 8s

इसके लिए, मेरा सुझाव है कि आप क्रेज़ी 8s नाम का तरीका अपनाएं. इसमें काग़ज़ के एक टुकड़े को दो बार मोड़कर आठ पैनल बनाए जाते हैं. इसके बाद, हर पैनल में एक आइडिया बनाएं. यह आइडिया, अब तक सीखी गई बातों पर आधारित होना चाहिए. सभी आठ पैनल भरने के लिए, आइडिया सोचने के लिए खुद को दस मिनट दें. अगर आपने खुद को 20 मिनट से ज़्यादा का समय दिया, तो हो सकता है कि आप काम को टालने लगें, कॉफ़ी बनाने लगें, ईमेल देखने लगें, अपनी टीम के साथ सामान्य बातचीत करने लगें, और काम करने से बचने लगें. इस चरण में, आपको जल्द से जल्द काम पूरा करने की भावना पैदा करनी होगी. इससे आपको तेज़ी से और ज़्यादा असरदार तरीके से काम करने में मदद मिलेगी.

अगर आप किसी टीम के साथ काम कर रहे हैं, तो टीम के सभी सदस्यों को भी ऐसा करने के लिए कहें. इस प्रोसेस से आपका दिमाग़ तेज़ी से काम करने लगेगा और आप चैलेंज के बारे में सोचने लगेंगे. आम तौर पर, स्केच एक इंटरफ़ेस डिज़ाइन वायरफ़्रेम होगा.

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

क्रेज़ी 8s, अपने सभी आइडिया को एक ही पेज पर लाने का एक शानदार तरीका है.
क्रेज़ी एट्स, अपने सभी आइडिया को एक पेज पर लाने का बेहतरीन तरीका है.
अब आपको अपनी सीख के आधार पर, एक बेहतर डिज़ाइन तैयार करना होगा.
अब आपको अपनी सीख के आधार पर, पूरी जानकारी वाला डिज़ाइन बनाना होगा.

अपने डिज़ाइन को बेहतर बनाना

वोटिंग के बाद, सबसे ज़्यादा वोट पाने वाले आइडिया को चुनें और उसे फ़ाइनल करें. अपने सहकर्मियों से मिले आइडिया भी इस्तेमाल किए जा सकते हैं. इस टास्क को पूरा करने के लिए, खुद को 10 मिनट और दें. इसके बाद, अपनी टीम को फिर से आइडिया दिखाएं और पहले की तरह वोट करें.

आइडिया का स्टोरीबोर्ड बनाएं

स्टोरीबोर्ड में, अपने स्केच और आइडिया को एक व्यवस्थित फ़्लो में शामिल किया जाता है.
स्टोरीबोर्ड में, अपने स्केच और आइडिया को एक साथ जोड़कर, उन्हें एक सिलसिलेवार फ़्लो में दिखाया जाता है.

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

प्रोटोटाइप बनाना

प्रोटोटाइप बनाने का मतलब, कोड का सही पीस बनाना नहीं है. इसका मतलब है कि कुछ ऐसा बनाना जिस पर लोग भरोसा कर सकें. प्रोटोटाइप बनाने के लिए इस्तेमाल किए जाने वाले टूल, हर व्यक्ति के लिए अलग-अलग होते हैं. कुछ लोगों को Keynote या Powerpoint पसंद है, क्योंकि इनमें डिज़ाइन की बारीकियों के बजाय, फ़्लो पर ध्यान देना पड़ता है. आपको Balsamiq, Marvel या Framer जैसे टूल सीखने में समय लगाना चाहिए. इनसे आपको व्यवहार से जुड़े ज़्यादा कंट्रोल मिल सकते हैं. आप जो भी टूल इस्तेमाल करें, पक्का करें कि वह ऐसा हो जो आपको फ़्लो पर फ़ोकस करने में मदद करे और असली लगे. आपको प्रोटोटाइप को असल लोगों पर टेस्ट करना होगा. इसलिए, यह जितना हो सके उतना भरोसेमंद होना चाहिए. हालांकि, इसे बनाने में हफ़्तों का समय नहीं लगना चाहिए.

प्रोटोटाइप इतने असली होने चाहिए कि उन पर भरोसा किया जा सके
प्रोटोटाइप ऐसे होने चाहिए जो असली लगें और उन पर भरोसा किया जा सके.

प्रोटोटाइप बनाने के लिए, समय और असलियत के बीच संतुलन बनाना ज़रूरी है. इसलिए, ध्यान रखें कि आप किसी भी तरफ़ ज़्यादा न झुकें. दोनों ही मामलों में, आपका समय बर्बाद हो सकता है.

अपने डिज़ाइन की उपयोगिता की जांच करना

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

स्टोरीबोर्ड में, आपके सभी स्केच और आइडिया को एक साथ जोड़कर एक पूरा फ़्लो बनाया जाता है.
स्टोरीबोर्ड में, आपके सभी स्केच और आइडिया को एक साथ जोड़कर एक पूरा फ़्लो बनाया जाता है.

इन सवालों पर गौर करें

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

आपको यह पता लगाना होगा:

  • उन्हें प्रोटोटाइप के बारे में क्या पसंद आया?
  • उन्हें प्रोटोटाइप में क्या पसंद नहीं आया?
  • समस्याएं क्या हैं?
    • कोई फ़्लो क्यों काम कर रहा है
    • कोई फ़्लो काम क्यों नहीं कर रहा है
  • उन्हें क्या बेहतर करना है?
  • क्या डिज़ाइन/फ़्लो उनकी ज़रूरतों के मुताबिक है?

डिज़ाइन की समीक्षा करना और टेस्टिंग का एक और राउंड

आपके पास सुझावों के साथ एक प्रोटोटाइप है. अब समय आ गया है कि आप अपने डिज़ाइन में बदलाव करें. साथ ही, यह विश्लेषण करें कि क्या काम आया और क्या नहीं. एकदम नया वायरफ़्रेम स्टोरीबोर्ड बनाने और नया प्रोटोटाइप बनाने से न डरें. नए सिरे से शुरुआत करने से, पुराने प्रोटोटाइप में बदलाव करने की तुलना में बेहतर फ़्लो बनाया जा सकता है. इसे लेकर ज़्यादा परेशान न हों, क्योंकि यह सिर्फ़ एक प्रोटोटाइप है.

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

कुछ नया बनाना सीखें!

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

मैं इस बात पर ज़ोर नहीं दे सकता कि किसी ऐसे काम पर बहुत ज़्यादा समय, ऊर्जा, और मेहनत लगाने से पहले, उसके बारे में ज़्यादा से ज़्यादा जानकारी हासिल करना कितना ज़रूरी है जो शायद सही समाधान न हो.

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