ISPystem में डिज़ाइन प्रक्रियाएँ। एक विचारधारा का परिचय कैसे दें, एक विभाग का निर्माण करें और जीवित रहें

एक रीडिज़ाइन की कहानी जिसने ISPystem में विकास के दृष्टिकोण को बदल दिया।



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

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

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

डेवलपर्स प्रोटोटाइप से मिलते हैं

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

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

यूएक्स विभाग डिजाइनरों और फ्रंट-रेंडरर्स की एक टीम के रूप में

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

हम डेवलपर्स को क्या देते हैं

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

परिणामस्वरूप, हम दो प्रकार की कलाकृतियों के साथ डेवलपर्स की आपूर्ति करते हैं:

• ज़ेपलिन में एक डिजाइन प्रणाली क्या बन जाएगी (या पहले से ही अंजीर में),
• उत्पाद प्रोटोटाइप, HTML के रूप में TK के लिए वैकल्पिक Axure से उत्पन्न।

इसी समय, यूएक्स डिजाइनर डेवलपर्स और परीक्षकों को यह बताने के लिए हमेशा तैयार है कि उसे क्या और कैसे काम करना चाहिए और देखना चाहिए।

डिजाइनरों के साथ हाथापाई

फरवरी 2017 में, हमने समय सीमा का पूर्वानुमान लगाने की सटीकता में सुधार करने का निर्णय लिया और स्क्रैम को लागू करने का प्रयास किया। हमारे स्क्रम की जटिलता यह है कि टीम के सदस्य दक्षताओं और संस्कृति के मामले में बहुत अलग हैं। डिजाइनर प्रोग्रामर की तरह नहीं हैं: हम अपने कार्यों की योजना अलग तरह से बनाते हैं, हमारे पास अलग-अलग दृष्टिकोण हैं जो एक अच्छा परिणाम माना जाता है।

हमने इस प्रक्रिया को कैसे बनाया:

• डिजाइनरों आगे स्प्रिंट;
• एक प्रोटोटाइप बैकलॉग है, सामान्य शब्दों में काम किया गया है, जिसमें आप देख सकते हैं कि पूरा उत्पाद कैसा होना चाहिए;
• स्प्रिंट की योजना बनाते समय, डिजाइनर उस उत्पाद के हिस्से के प्रोटोटाइप और मॉक-अप प्रदान करते हैं जो स्प्रिंट में किए जाने की योजना है। ये प्रोटोटाइप यूएक्स डिजाइनर द्वारा विस्तृत और वर्णित हैं, जहां डेवलपर्स अपने कार्यों को निर्धारित और विघटित कर सकते हैं;
• नियोजन के समय, यूएक्स डिजाइनर सक्रिय रूप से डेवलपर्स और परीक्षकों को सलाह देता है कि क्या और कैसे काम करना चाहिए;
• योजना के समय, उत्पाद प्रबंधक को UX डिजाइनर को यह बताना होगा कि उत्पाद का कौन सा भाग अगले स्प्रिंट में किए जाने की योजना है ताकि यूएक्स डिजाइनर अपने काम की योजना बना सके।

डेवलपर्स ने जल्दी से एक यूएक्स डिजाइनर के मूल्य का एहसास किया, जिसे जल्दी से संबोधित किया जा सकता है जब यह स्पष्ट नहीं है कि क्या और कैसे काम करना चाहिए। संघर्ष अभी भी होता है, लेकिन स्क्रम अभ्यास, टीम वर्क और सामान्य लक्ष्य उन्हें दूर करने में मदद करते हैं।

परीक्षक को इससे क्या लेना-देना है?

प्रक्रियाओं में परीक्षक की भूमिका बहुत महत्वपूर्ण थी। यह वह व्यक्ति है जो सबसे अच्छी तरह से उत्पाद की कार्यक्षमता जानता है। परीक्षक यूएक्स डिजाइनर के प्रोटोटाइप को देखने वाला पहला व्यक्ति था और प्रोटोटाइप अनुपालन और कार्यक्षमता के संदर्भ में जल्दी प्रतिक्रिया देता है। अनुमोदित प्रोटोटाइप परीक्षक के लिए ज्ञान का एक स्रोत बन जाता है कि उत्पाद को कैसे काम करना चाहिए। दोनों पक्ष निकट सहयोग में रुचि रखते थे।

नतीजतन, समय पर टीम ने आईएसपीसिस्टम व्यक्तिगत खाते का नया इंटरफ़ेस जारी किया। हमने सीखा कि फ्रंट-एंड और डिजाइनरों की एक टीम के रूप में UX विभाग के काम की भविष्यवाणी करने के लिए, स्क्रैम पर कैसे काम किया जाए। और 2017 की गर्मियों तक, उन्हें एक नई समस्या का सामना करना पड़ा।

बिलमैनगर एक लचीला उत्पाद है। और यह डिजाइनर के लिए एक समस्या है

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

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

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

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

UX डिजाइनरों के विभाग

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

इस संदर्भ में, UX विभाग को उत्पाद टीमों में से एक होना बंद हो जाना चाहिए। BILLmanager 6 बीटा के क्लाइंट भाग के रिलीज़ होने के बाद, UX विभाग का अधिकांश हिस्सा BILLmanager टीम का हिस्सा बन गया और अब वास्तु समस्याओं और क्लाइंट भाग के मोबाइल संस्करण को हल करने में लगा हुआ है। उसी समय, हमने एक यूएक्स विभाग के गठन पर काम शुरू किया जो सभी उत्पादों के साथ एक साथ काम कर सकता था।

हर उत्पाद टीम के लिए UX डिजाइनर। डिजाइन कॉम्पिटीशन सेंटर

ISPystem के चार जटिल उत्पाद हैं। हमने सुनिश्चित किया कि प्रत्येक टीम का अपना UX डिज़ाइनर हो। यह वह व्यक्ति है जो अपने उत्पाद के डिजाइन के लिए जिम्मेदार है। उनकी जिम्मेदारियों में स्प्रिंट प्लानिंग के लिए प्रोटोटाइप तैयार करना और यह नियंत्रित करना शामिल है कि डेवलपर्स के लिए आवश्यक सब कुछ पिक्सेलपरफेक्ट संस्करण में है। वह अपनी टीम के लिए कंपनी की डिज़ाइन नीति का संवाहक है। उनका एक कार्य यह सुनिश्चित करना है कि विकास का परिणाम एक उत्पाद है जो डिजाइन से मेल खाता है।

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