एक सॉफ्टवेयर हाउस में UX/UI डिज़ाइनर के रूप में अपने काम के पहले साल के दौरान मैंने 11 चीज़ें सीखीं

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

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

यहाँ कुछ समस्याएँ हैं जिनका सामना मैंने UX/UI डिज़ाइन में अपने पहले वर्ष के दौरान किया:

1. एमवीपी और केपीआई

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

2. व्यावसायिक आवश्यकताएं, आवश्यकताओं को इकट्ठा करना, ग्राहक के साथ उनकी पुष्टि करना, पुष्टि करना

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

3. समय का अनुमान लगाना - कम या ज्यादा आंकना

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

4. पतवार, पाल और जहाज - आत्मनिर्भरता

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

5. यूएक्स स्टेज पर रिसर्च, या यूँ कहें कि इसकी कमी

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

6. दस्तावेज़ीकरण निर्माण

क्लाइंट को सत्यापित करने के लिए यह वास्तव में काम का एक टुकड़ा है। UX प्रलेखन बनाने के लिए, मैंने दस्तावेज़ीकरण तैयार करने पर ऑटेंटिका के विस्तृत लेख का उपयोग किया (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/पॉलिश में)।

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

7. कार्यप्रणाली? क्या वे मौजूद हैं? (नहीं)

अधिकांश सॉफ्टवेयर हाउस ग्राहक के लिए एक व्यक्तिगत दृष्टिकोण के साथ, पुनरावृत्त रूप से काम करने का प्रयास करते हैं। ऐसी स्थितियों में पुस्तक प्रक्रियाओं की योजना बनाना मुश्किल है, खासकर जब से बोर्ड-टू-बोर्ड अनुसंधान शायद ही कभी किया जाता है क्योंकि "कोई समय नहीं है" या आप केवल एक डिजाइनर के रूप में काम करते हैं। अंततः, डिजाइन पद्धति फुर्तीली पर आधारित है, लेकिन चौखटे एक-दूसरे से काफी मिलती-जुलती हैं और इसे डिस्कवर, डिफाइन, डिजाइन, डेवलप और डिलीवर / डिप्लॉय चरणों में विभाजित किया जा सकता है (जैसे कि डबल डायमंड से एक चरण के साथ विस्तारित 5D) .

8. ग्राहक को समझना

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

9. डेवलपर्स के साथ काम करना

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

10. एपीआई, जेएसओएन, एलडीएपी, ऑर्केस्ट्रेटर्स और अन्य अजीब शब्द

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

11. स्प्रिंट, प्रोजेक्ट डेली, स्प्रिंट प्लानिंग और रेट्रो (कल्पना) में काम करना

वे मूल्यवान बैठकें हैं जो परियोजना में क्या हो रहा है, इस पर पूर्ण नियंत्रण देती हैं। परियोजना प्रबंधक यहां महत्वपूर्ण हैं, जरूरत पड़ने पर हस्तक्षेप करते हैं (उदाहरण के लिए, जब ग्राहक व्यवस्था बदलने की कोशिश करता है), साथ ही स्क्रम मास्टर्स अगर हम फुर्तीले काम कर रहे हैं (लगभग सभी परियोजनाएं)।

जैसा कि आप देख सकते हैं, आईटी में शामिल होने पर मुझे यह बहुत कुछ पता चला। मुझे आशा है कि आप उन्हें दिलचस्प पाएंगे और शायद यह सूची उन लोगों के लिए मददगार होगी जो अपने UX/UI करियर पर विचार कर रहे हैं या यहां तक ​​कि इस उद्योग में काम करने वाले लोगों के लिए भी!