जांचें और दोहराएं

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

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

अपना डायलॉग बॉक्स आज़माने के लिए, किसी ऐसे व्यक्ति को खोजें जो आपके प्रोजेक्ट से जुड़ा हुआ न हो. डिज़ाइन प्रक्रिया के दौरान सुझाव पाने से उपयोगिता से जुड़ी समस्याएं सामने आती हैं. साथ ही, आपको पहले से खुद सुधार करने का मौका मिलता है. कोड की सिर्फ़ एक लाइन लिखने से पहले, बातचीत के अनुभव पर उपयोगिता की जांच करना ज़रूरी है. हमारा सुझाव है कि आप ऑज़ (WOZ) के तेज़ और गंदे विज़र्ड की मदद से प्रयोग करें. इससे आपको यह पता चलेगा कि आप सही पाथ पर हैं या नहीं.

Oz of Oz प्रयोग का इस्तेमाल करें

इसे क्यों कहा गया? विज़र्ड ऑफ़ ऑज़ (WOZ) के प्रयोगों को अपना नाम 'द विज़र्ड ऑफ़ ऑज़' रखा गया. उन्होंने इस आइडिया को हवाला दिया कि यहां एक आदमी है, जो पर्दा उठा रहा है.

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

आपको ऐसा क्यों करना चाहिए? WOZ प्रोटोटाइप का एक सबसे बड़ा फ़ायदा यह है कि आपको डिज़ाइन किए बिना ही उसे टेस्ट करने की सुविधा मिल जाएगी. वॉइस टेस्ट के लिए, WOZ प्रयोग प्रोटोटाइप करने की सबसे कम क्षमता वाले प्रॉडक्ट (MVP) हैं. इन्हें आसानी से चलाया जा सकता है और इनके लिए ज़्यादा मेहनत नहीं करनी पड़ती. प्रोटोटाइप का डिज़ाइन इतना आसान हो सकता है कि वह बनाने के लिए इस्तेमाल की जाने वाली चीज़ों को दिखा सकता है. हो सकता है कि यह एक ऐसा काम करने वाला मॉडल हो (जो मौजूदा प्रॉडक्ट का कलेक्शन हो) जो कुछ टास्क कर सकता हो, लेकिन सभी टास्क नहीं कर सकता. बेशक, आपका प्रोटोटाइप जितना असली होगा, आपका सुझाव उतना ही बेहतर होगा. सोच-समझकर प्लान चुनें: आपके पास कितना समय है? क्या इसके लिए 'हकीकत' का प्रोटोटाइप इस्तेमाल करना चाहिए?


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

ऐप्लिकेशन की जांच के लिए तीन तरीके अपनाए जा सकते हैं:
जो कॉन्टेंट आपके पास है उसे इस्तेमाल करें. आपको सिर्फ़ सैंपल डायलॉग की ज़रूरत है (जो आपको इस समय पहले से ही होने चाहिए). बस किसी ऐसे व्यक्ति को ढूंढें जो आपके प्रोजेक्ट से अनजान हो (जैसे, परिवार, दोस्त, सहकर्मी) और उसे आपके साथ भूमिका निभाने के लिए कह सकता है—आप अपने पर्सोना की लाइनें पढ़ेंगे और देखेंगे कि वे उपयोगकर्ता के तौर पर कैसी प्रतिक्रिया देते हैं. अगर कोई उपयोगकर्ता “ स्क्रिप्ट से अलग” कहता है, तो उसके शब्दों में बदलाव करें.

ज़्यादा बेहतर अनुभव देने के लिए, Google Developers Console पर कार्रवाइयां सेक्शन में टीटीएस सिम्युलेटर का इस्तेमाल करके पर्सोना के संकेत चलाएं और पर्सोना की भूमिका को सिम्युलेट करें. मांग पर ऑडियो चलाने के लिए, इसे डाउनलोड करें.

इस वर्शन के लिए चार चीज़ें ज़रूरी हैं:

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

अपने ऐक्शन ग्रीटिंग मैसेज का ऑडियो चलाकर, विज़र्ड को बातचीत शुरू करने के लिए कहें. उदाहरण के लिए, "Google I/O से जुड़ी सभी चीज़ों के लिए, लॉन्चपैड पर आपका स्वागत है. फ़िलहाल, त्योहार चल रहा है. क्या आप भाग्यशाली मौजूदगी वाले लोगों में से एक हैं?" फिर विज़र्ड उपयोगकर्ता के जवाब में तब तक इंतज़ार करेगा, जब तक कि “हां” या “नहीं” के समानार्थी के रूप में जवाब मिल जाए. उपयोगकर्ता के जवाब देने के बाद, यह तय करने के लिए कि अगला गेम खेलने के लिए क्या संकेत देना है, उसे तुरंत ऊंची लेवल फ़्लो देखनी होगी, फिर सही ऑडियो फ़ाइल को ढूंढना और चलाना होगा.

बेशक, एक बार अपनी कार्रवाई बनाना शुरू कर देने के बाद, आपको Google Developers Console पर कार्रवाइयां में कार्रवाइयां सिम्युलेटर का उपयोग करके अक्सर उसका परीक्षण करना चाहिए. अपने दोस्तों, परिवार के सदस्यों या साथियों को भी इसकी जांच करने के लिए कहें!

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

इससे आपको क्या सीखने को मिलेगा?

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

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

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

कार्रवाइयों को टेस्ट करने का तरीका

अच्छी क्वालिटी के सॉफ़्टवेयर बनाने और उपयोगकर्ता की संतुष्टि के लिए, बेहतर जांच ज़रूरी है.

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

Google I/O 2018 में अपनी कार्रवाइयों की जांच करने के दौरान, आइलिन एल्टीक और निक फ़ेलकर