अगर प्रोजेक्ट में कोई डिज़ाइनर नहीं हैं, तो क्या डेवलपर को UI मॉकअप करना चाहिए?


57

मैं एक छोटी सी टीम के साथ काम कर रहा हूं जो एक मालिकाना वेब एप्लिकेशन बनाता है और UX एक प्राथमिकता नहीं है क्योंकि हमारे अपने लोग इसे संचालित करने वाले होंगे, लेकिन हम उनके काम को आसान बनाने की कोशिश करते हैं।

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

मेरे सहकर्मियों में से एक का कहना है कि यह बहुत जरूरी है और ऐसा करना मेरा काम नहीं है।


51
यदि आपके पास डिजाइनर नहीं हैं, और इसके डेवलपर्स काम नहीं करते हैं, तो यह कौन करने वाला है? चौकीदार, शायद?
ग्रैंडमास्टरबी

10
आप निश्चित रूप से कर सकते हैं, शायद आपको करना चाहिए, लेकिन यह असामान्य से बहुत दूर है और निश्चित रूप से "पूर्ववर्ती" नहीं है क्योंकि आपका अत्यधिक नाटकीय सहकर्मी इसे डालता है। स्थिति और वातावरण के आधार पर, आप बेहतर तरीके से किसी ऐसे उत्पाद के बजाय जानबूझकर किसी न किसी तरह से मॉकअप कर सकते हैं। इसके लिए Balsamiq एक अच्छा उपकरण है, जैसा कि आप केवल कागज या व्हाइटबोर्ड पर अपना मॉकअप बना रहे हैं।
जो बेल्डर

3
मुझे लगता है कि आप वास्तव में "मॉकअप?" एक "मॉक" कुछ और है
रॉबर्ट हार्वे

23
उपयोगकर्ता अनुभव डिजाइन चीजों को सुंदर बनाने से परे जाता है। प्रोग्रामर्स को इससे बहुत जुड़ना चाहिए।
जेएफओ

2
आपकी सहकर्मियों की प्रतिक्रिया क्या है? यह बहुत आम है
क्लॉडिउ क्रैन्गा

जवाबों:


74

मैं बहुत बार ऐसी परियोजनाओं में काम करता हूं, और उत्तर एक शानदार हां है, और जितनी जल्दी हो सके।

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

  • मामले के विशेषज्ञों को इस बात का आभास दें कि जानकारी कैसे प्रस्तुत की जा सकती है।
  • समस्या और सूचना संरचनाओं के बारे में मेरी वर्तमान समझ दिखाएं।

दुर्लभ मामलों में कुछ प्रमाण होना भी अच्छा था कि मैंने वास्तव में जो हम पर सहमति व्यक्त की है ...


16
और ईमानदारी से, यह कोड लिखना इतना आसान है यदि आपके पास कम से कम नैपकिन स्केच आपके सामने बैठा है।
कैथी

9
बिंदु 2) बहुत महत्वपूर्ण है अगर व्यवसाय तुच्छ नहीं है!
बिगस्टोन

4
जैसा कि किसी ने UX को 3 साल के लिए काम किया था, बस लोगों (डेवलपर्स, क्लाइंट्स, एंड यूजर्स) के बारे में बात करने के लिए एक स्केच होना अविश्वसनीय रूप से उपयोगी और महत्वपूर्ण है। यह आपको सड़क के नीचे बहुत समय बचाएगा जब आपको साइट को पूरी तरह से फिर से करने की आवश्यकता नहीं है क्योंकि कोई निराश हो गया है!
ग्नोमेजोन

39

Mockups शानदार हैं और ऐसा कोई कारण नहीं है कि एक देव उन्हें नहीं करना चाहिए। (यह तब भी हो सकता है जब आप यूआई लेआउट के किसी न किसी मसौदे को तब भी कर सकते हैं जब आपके पास प्रोजेक्ट पर यूआई डिजाइनर हों।)

मुझे लगता है कि आप वास्तविक स्क्रीन की तरह दिखने वाले नकली नहीं बनाते हैं। यदि आप इन्हें अंतिम उपयोगकर्ताओं के साथ साझा करते हैं जो अक्सर उन चीजों पर ध्यान केंद्रित करते हैं जो रंगों और विषयों की तरह नहीं हैं। जो मैं करता हूं वह आप या तो कागज या व्हाइटबोर्ड स्केच पर तैयार किए गए हैं। या यदि आप उनकी तरह कंप्यूटर का उपयोग कुछ में चाहते पेंसिल परियोजना या Visio ( यहाँ एक जोनाथन Abbett कि handdrawn देखने से कुछ Visio स्टेंसिल कर रहे हैं।)


6
आप हाथ से ओवरले, डायलॉग आदि भी बना सकते हैं, उन्हें कैंची से काट सकते हैं, और हाथ से खींची गई मुख्य स्क्रीन के ऊपर रख सकते हैं, जब उपयोगकर्ता हाथ से खींचे गए बटन को छूता है। बहुत जल्दी यह बताने के लिए कि वे क्या सहज हैं, कितने बटन आप वास्तव में जरूरत के लिए जा रहे हैं, और इसी तरह।
रेमकोगर्लिच

यह सिर्फ पागल बात है ... वास्तव में स्टोरीबोर्डिंग कर रही है। इन नए लोगों के लिए पुराने स्कूल का रास्ता: पी
मैथ्यू Whited

1
"वास्तविक स्क्रीन की तरह दिखने वाले मॉकअप न करें" एक बहुत गहरा अंतर्दृष्टि है।
एंड्रयू मायर्स

1
मुझे एक किस्सा याद है कि उपयोगकर्ता किसी प्रोजेक्ट के पूरा होने का अंदाजा लगाते हैं कि उनके द्वारा प्रस्तुत किए गए स्क्रीनशॉट को कैसे पॉलिश किया जाता है। ऐसे गैर-तकनीकी उपयोगकर्ताओं के लिए जो प्रस्तुति और कार्यक्षमता के बीच अंतर नहीं करते हैं, "यह नहीं किया जाता है" संवाद करने के लिए एक स्केच रखना बहुत महत्वपूर्ण है।
मैथ्यू एम।

1
@ और ... यह उन चीजों में से एक है, जो मैंने एक्सेस और वीबी में ऐप का मजाक उड़ाते हुए वापस सीखा था। आप किसी ऐसे व्यक्ति को दिखाते हैं जो एक स्क्रीनशॉट की तरह दिखता है और वे उम्मीद करते हैं कि आप इसे शिप कर सकते हैं :)
मैथ्यू Whited

11

हाँ बिल्कुल।

किसी और को यह न बताएं कि आपको अपना काम कैसे करना है। और आप सही हैं, यह आपके डेटा मॉडल के लिए UML करना बहुत पसंद है। आपको एक डेवलपर मानते हुए, आपका काम गुणवत्ता सॉफ्टवेयर वितरित करना है। अगर मॉकअप आपको ऐसा करने में मदद करता है, तो यह आपकी नौकरी का हिस्सा है।

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


बेशक, जैसा कि आप कहते हैं कि मैं कम निष्ठा के बारे में बात कर रहा हूँ। मैं व्यक्तिगत रूप से एक सुपर लाइटवेट समाधान के रूप में और सहयोगियों के बीच आसान साझेदारी के लिए draw.io का उपयोग करता हूं।
कॉन्स्टेंटाइन

10

"एक नई स्क्रीन" डिजाइन करते समय, आप एक उपयोगकर्ता और / या अपने सहयोगियों के साथ पहले यूआई के मोटे विचार पर चर्चा करना चाहते हैं। आप किसी उपयोगकर्ता के साथ "कोड में" या "यूएमएल में" पर चर्चा नहीं कर सकते, यह बस काम नहीं करता है (यह प्रोग्रामर के बीच भी काम नहीं करेगा)। और आपको उम्मीद करनी चाहिए कि आपको अपने पहले दो या तीन स्केच को फेंकने की ज़रूरत है, या कम से कम यूआई तत्वों को भारी रूप से पुनर्व्यवस्थित करें।

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


5

जरुरी नहीं। कम से कम दो कारण हैं कि मॉकअप का कम उपयोग हो सकता है।

सबसे पहले, अगर आपके द्वारा किए जा रहे कामों के बारे में अच्छी तरह से स्थापित उद्योग अभ्यास हैं, तो आप बस आगे बढ़ सकते हैं और ठीक वैसा ही कर सकते हैं। आप यूआई डिजाइन की कला को आगे नहीं बढ़ाएंगे, लेकिन यह भी ठीक है।

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

एक मामूली लचीले वेब फ्रेमवर्क के साथ, "सिर्फ एक और UI स्क्रीन के लिए, पिछले N स्क्रीन की तरह", आप काम के प्रोटोटाइप के साथ शुरू कर सकते हैं और जाते ही पुन: व्यवस्थित कर सकते हैं। जब भी आप कुछ करने जा रहे हैं, तो मॉकअप और सहकर्मियों के साथ चर्चा करें।


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

@MatthewWhited क्या आप यूआई पर चर्चा करने के लिए आने पर छोटी चीजों के बारे में शिकायत करते हैं या क्या आप उनके बारे में शिकायत करते हैं जब आप अपने थैस्क को पूरा करने के लिए उत्पाद का उपयोग करने का प्रस्ताव देते हैं? मैं बल्कि उम्मीद करता हूं कि बाद का मामला अधिक रचनात्मक होगा, और यह 1 के स्थापित आधार के साथ एक इन-हाउस वेब एप्लिकेशन को अच्छी तरह से उधार देता है
यूजीन रियाबत्सेव

3

हमेशा!

मैं एक छोटी कंपनी के लिए काम करता हूं, और मैं केवल "सॉफ्ट" आईटी व्यक्ति हूं। मैं सभी आवश्यकताओं, डिजाइन, कोडिंग, परीक्षण (हालांकि कोई हमेशा मेरे परीक्षण को मान्य करता है), डेटाबेस डिजाइन आदि करता हूं।

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

यह आपकी कोडिंग में भी आपकी मदद करता है। यह आपको यह सोचने का मौका देता है कि आपको क्या करने की आवश्यकता है, इसे पूरा करने का सबसे कुशल तरीका है, और किसी भी बाधाएं जो रास्ते में हो सकती हैं।

उदाहरण के लिए, आप पा सकते हैं कि "सरल" रिपोर्ट जिसे आपको बनाने की आवश्यकता है, वह आपके द्वारा पहले सोचा गया कठिन है क्योंकि आप टेबल xyz पर कुछ तारीख कैप्चर नहीं कर रहे हैं। यह आपके क्षितिज को भी विस्तृत करता है और आपकी टीम, वरिष्ठों को दिखाता है, या भविष्य के संभावित कैरियर के अवसरों के लिए भी इस्तेमाल किया जा सकता है जो आप नंगे न्यूनतम से अधिक करते हैं और "यह मेरा काम नहीं है" के बॉक्स से बाहर निकल सकते हैं (<--- गंभीरता से, वह आदमी नहीं है, हम सभी उससे नफरत करते हैं) या यह आपको अतिरिक्त सीखने का मौका देता है।


2

आइए इसे और सामान्य तरीके से देखें:

  • क्या ड्राफ्ट एक अच्छा विचार है?
  • ड्राफ्ट किसको बनाना चाहिए?

क्या ड्राफ्ट एक अच्छा विचार है?

ड्राफ्ट बनाना मुख्य रूप से 2 लाभ प्रदान करता है। सबसे पहले, यह फ़ोकस प्रदान करता है, जिससे वास्तविक कार्य में गति होती है। दूसरा, यह काम की दिशा पर चर्चा करने से पहले काम को इतना सरल बना देता है।

ड्राफ्ट बनाने का नकारात्मक पक्ष यह है कि यह समय का उपयोग करता है। 2 घंटे बिताने का कोई मतलब नहीं है कि किसी चीज़ के लिए विस्तृत मसौदा तैयार करने में 4 घंटे लगते हैं।

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

ड्राफ्ट किसको बनाना चाहिए?

यहाँ एक विस्तृत उत्तर की आवश्यकता नहीं है: यदि आप एक मसौदा बनाने से लाभान्वित होते हैं, तो आप एक मसौदा तैयार करते हैं। यदि आप किसी अन्य व्यक्ति को आपके लिए एक मसौदा बनाने से लाभान्वित करते हैं, तो किसी और को आपके लिए एक मसौदा बनाने के लिए कहें।


रचना काल की तुलना करने के महत्व पर वास्तव में अच्छा बिंदु। केवल ड्राफ्ट बनाने के लिए आवश्यक समय को दोगुना करने का कोई मतलब नहीं है।
कोन्स्टेंटाइन

-2

आपका कोलीग बिलकुल सही है। आंतरिक अनुप्रयोगों में आम तौर पर एक पूर्वनिर्धारित रूप होता है। इसके अलावा इस तरह के अनुप्रयोगों के लिए, उपयोगकर्ताओं को अत्याधुनिक यूआई की तलाश नहीं है। वे चाहते हैं कि कुछ काम करता है और उपयोग करने के लिए यथोचित आसान है। जब तक आप यूआई को मौलिक रूप से बदलने की योजना नहीं बनाते हैं (जो मैं आंतरिक अनुप्रयोगों के लिए .... के खिलाफ दृढ़ता से सलाह दूंगा), बस मौजूदा स्वरूप का पालन करें और महसूस करें। मॉक-अप महान हैं, लेकिन आपके मामले में, केवल आपके दर्द को बढ़ाएगा।


1
मॉकअप अत्याधुनिक यूआई के निर्माण के लिए नहीं है, वे स्क्रीन के लेआउट और व्यवहार का मजाक उड़ा रहे हैं। वास्तव में ज्यादातर मामलों में, वे वास्तव में सुंदर नहीं हैं। मैं अभी सहमत नहीं हूँ
किरेन जॉनस्टोन

3
मुझे लगता है कि मैं विकसित कर रहा था एक विशेष आंतरिक अनुप्रयोग के लिए उपयोगी होने के लिए मॉकअप। इस विचार को डिज़ाइन को देखने या एक नए UI प्रतिमान का आविष्कार नहीं करना था (जैसा कि आप कहते हैं, इसकी आवश्यकता नहीं थी), लेकिन उन उपयोगकर्ताओं को चिढ़ाने के लिए जो आवश्यकताएं हैं, क्योंकि एक यूआई आपको चर्चा करने के लिए कुछ ठोस देता है।
जेम्स_पिक

@KierenJohnstone मैं आपसे पूरी तरह सहमत हूँ। हालाँकि वह खुद कहते हैं कि "UX बहुत प्राथमिकता नहीं है"। जब तक वह टीम का एक वरिष्ठ सदस्य नहीं है, उसके पुरस्कार प्रयासों (मॉक-अप बनाने) से मेल नहीं खाएंगे। नकली अप महान हैं। लेकिन उसकी स्थिति में नहीं।
क्षितिज उपाध्याय

मैं सहमत नहीं हूं - इस स्थिति में मॉकअप वास्तव में उपयोगी है - ज्यादातर स्थितियों में - यह देखने के लिए कि ऐप कैसे काम करेगा, अगर यह समझ में आता है, और यदि डेवलपर द्वारा आवश्यकता को समझा जाता है - तो महंगा हिस्सा होने से पहले (कोड लिखना)
कीरेन जॉनस्टोन

1
हमारी टीम लगभग 3 लोग हैं। एक वरिष्ठ सदस्य / टीम लीडर है, और मैं और एक अन्य लड़का है, जिन्हें प्रोजेक्ट पर काम करने के लिए अनुबंधित किया गया है। मसौदा मुख्य रूप से टीम के नेता के साथ नई स्क्रीन पर चर्चा करने के लिए किया गया था। इसके अलावा कोई पूर्वनिर्धारित लुक नहीं था क्योंकि नई स्क्रीन के पूरे बिंदु को मौजूदा एक को सुधारना था जो उपयोग करने के लिए एक दर्द था, इसलिए सब कुछ फिर से करना पड़ा।
कोन्स्टेंटाइन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.