इंटरफ़ेस एकीकरण: ई-कॉमर्स परियोजनाओं का अनुभव

2012 की शुरुआत में, ई-कॉमर्स लाइन को मेल.रू ग्रुप में पुनर्गठित किया गया था, और हमारी सेवाओं को अपडेट करने के कार्य के साथ हमारा सामना हुआ। अद्यतन के हिस्से के रूप में, सभी परियोजनाओं के इंटरफेस को एक एकल भाजक में लाया गया था। इस पोस्ट में मैं बात करूँगा कि अभ्यास में एकीकरण क्या देता है, और बड़े पैमाने पर परियोजनाओं के साथ काम करते समय कौन से तरीके लागत को कम करने में मदद कर सकते हैं।

इनपुट डेटा

Mail.Ru Group के ई-कॉमर्स व्यवसाय में Goods, Money, Real Estate और Travel शामिल हैं। उनके अलावा, वर्ष के दौरान हमने नए उत्पादों पर काम किया - बुनियादी सेवाओं के उपग्रह। परिणाम नई परियोजनाओं एयरलाइन, वित्त और मरम्मत का उद्भव था।

हमारा मुख्य काम थोड़े समय में एक बुनियादी इंटरफ़ेस तैयार करना था, जिसे बाद में बेहतर और परिमार्जित किया जा सकता है।



डिजाइन विभाग के संसाधनों पर इनपुट डेटा निम्नानुसार थे: कर्मचारियों पर दो लोग और फ्रीलांस विशेषज्ञों को आकर्षित करने की क्षमता। व्यवहार में, इसका मतलब यह था कि काम का हिस्सा बाहरी ठेकेदारों पर होगा और बहुत सारे संचार होंगे।

संसाधनों और समय के आधार पर, आगे के काम के लिए एक रणनीति को परिभाषित किया गया था - सभी परियोजनाओं के इंटरफेस का एकीकरण। चूंकि Mail.Ru Group में इतने बड़े पैमाने पर एकीकरण पहले था, ऐसे समाधान के लिए एक स्पष्ट औचित्य आवश्यक था।

एकीकरण क्यों आवश्यक है?

विकास लागत लाभ

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



बचत न केवल उत्पादन लागत का मौद्रिक समतुल्य है। सबसे महत्वपूर्ण कारक वह समय है जिसके दौरान तैयार उत्पाद को बाजार में लाना संभव है। समय की बचत करने से न केवल वास्तविक काम को कम करने में मदद मिलती है, बल्कि टीम के भीतर संगठनात्मक प्रक्रियाओं को कम करने और फ्रीलांस विशेषज्ञों के साथ काम करने में भी मदद मिलती है।

आर्थिक लाभ का समर्थन किया

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

इसी तरह की परियोजनाओं की समस्याएं भी समान हैं। प्रयोज्य अध्ययन करते समय, कुछ परिणाम अन्य परियोजनाओं को प्रेषित किए जा सकते हैं। इसी तरह, सफल रूपांतरण-बढ़ाने वाले समाधान क्रॉस-कटिंग हो सकते हैं।

एकीकरण के प्रकार

एकीकरण को दो घटकों में विभाजित किया जा सकता है: कार्यात्मक और दृश्य।

कार्यात्मक एकीकरण ग्रिड, नेविगेशन, निर्माण के तर्क और खोज रूपों और अन्य मॉड्यूल के संचालन के एक सामान्य हर में कमी का अर्थ है।

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



एकीकरण के दो घटकों के अलग-अलग उद्देश्य और कार्यान्वयन के विभिन्न क्षेत्र हैं।

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

लेकिन दृश्य एकीकरण सिर्फ हिमशैल के टिप है। अधिकांश एकीकरण कार्य कार्यात्मक घटक पर पड़ता है।



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

इन दोनों प्रकार के एकीकरण को एक साथ करने की आवश्यकता नहीं है। उनमें से प्रत्येक को अलग-अलग उपयोग किया जा सकता है, कार्य के आधार पर।

एक अच्छा उदाहरण व्हाइट-लेबल प्रोजेक्ट्स हैं। सेवा प्रदाता एक कार्यात्मक रूप से एकीकृत उत्पाद प्रदान करता है, जिसका इंटरफ़ेस ग्राहक अपने ब्रांड के लिए या, दूसरे शब्दों में, नेत्रहीन एकीकृत कर सकता है।

तरीकों

समस्या के लिए एक बार का दृष्टिकोण

पहला तरीका मानता है कि काम की शुरुआत में, सभी परियोजनाओं के लिए एनालिटिक्स किया जाता है, कार्यात्मक और व्यावसायिक आवश्यकताओं का गठन होता है, जिस पर सभी उत्पादों के लिए एक एकल समाधान प्रस्तावित होता है।

प्लस विधि:
- एक आम तस्वीर और प्रोजेक्ट एनालिटिक्स की उपस्थिति

विपक्ष:
- इस तरह के समाधान के निर्माण में बहुत समय और प्रयास की आवश्यकता हो सकती है
- त्रुटि की उच्च लागत

यह विधि छोटी परियोजनाओं पर सबसे अच्छा काम करती है, जब उत्पाद के विकास के दौरान एनालिटिक्स के परिणाम पुराने होने का समय नहीं होता है, और त्रुटि की कीमत परियोजना की मात्रा के अनुपात में घट जाती है।



"विकासवादी" दृष्टिकोण

दूसरी विधि का सार यह है कि काम एक उत्पाद से शुरू होता है। कार्य परिदृश्य और दृश्य शैलियों को धीरे-धीरे काम किया जा रहा है, नियमों और तत्वों का एक न्यूनतम सेट बनाया गया है, जो बाद में अन्य परियोजनाओं पर लागू होता है।

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

समाधान के लाभ:
- "बात करना" शुरू करने के लिए, आपको एक जटिल प्रणाली की आवश्यकता नहीं है, आप इसे अभी और अभी कर सकते हैं
- त्रुटि की कम कीमत, इसका सुधार श्रम-गहन नहीं होगा
- बनाई गई प्रणाली की अधिकतम लचीलापन, आप हमेशा चयनित पाठ्यक्रम को दर्द रहित रूप से समायोजित कर सकते हैं

कम:
- पूर्ण विश्लेषण की कमी
लेकिन यह कमी स्पष्ट रूप से परिभाषित इंटरफ़ेस विकास रणनीति द्वारा सुचारू है।

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

रणनीति

हम एक न्यूनतर, हल्के डिजाइन पर भरोसा करते हैं, जहां मुख्य बात एक सरल और सहज ज्ञान युक्त अंतरफलक यांत्रिकी है। एक न्यूनतम समाधान उत्पाद पर बेचा जा रहा है और अंततः उपभोक्ता पर केंद्रित है। ई-कॉमर्स परियोजनाओं के लिए, अंतिम कार्रवाई पर उपयोगकर्ता का ध्यान महत्वपूर्ण है, रूपांतरण में, खरीद की संख्या या अन्य लेनदेन जो परियोजनाओं को राजस्व लाते हैं।



इसके अलावा, यह समाधान अधिक टिकाऊ है। हमने 2012 के प्रारंभ में रीडिज़ाइन शुरू किया, और हमने जो दिशा चुनी है वह अभी भी प्रासंगिक है, जिसमें विंडोज 8 यूआई और तथाकथित फ्लैट-डिज़ाइन के आगमन के बाद भी शामिल है।



यदि हम इंटरफ़ेस के यांत्रिकी के बारे में बात करते हैं, तो सरल समाधान बेहतर काम करते हैं, और वे बाद में सुधार करने में आसान होते हैं।

वैसे, बहुत से लोग यह विश्वास करने की गलती करते हैं कि न्यूनतर डिजाइन बनाने में कम समय लगता है। वास्तव में, एक सरल या ग्राफिक्स-लोड किए गए इंटरफ़ेस को बनाने में बिताए समय की मात्रा में कोई अंतर नहीं है।

क्रियात्मक एकीकरण

ग्रिड, नेविगेशन, खोज फ़ॉर्म, इंटरफ़ेस मॉड्यूल

मॉड्यूलर ग्रिड

हम मान सकते हैं कि एक बार एक मॉड्यूलर ग्रिड डिजाइन करने का एक तरीका है। यह उसी प्रकार की जानकारी वाली परियोजनाओं के लिए अच्छी तरह से अनुकूल है।

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

प्रत्येक परियोजना के लिए, हमने इस परियोजना पर प्रमुख प्रकार की जानकारी के आधार पर ग्रिड के व्यवहार का निर्धारण किया।

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



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



नेविगेशन और खोज मॉड्यूल

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

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



हमने कुछ सरल स्क्रिप्ट और नियम बनाए जो हम सभी परियोजनाओं पर काम करते थे।

नियम १
पहला और दूसरा स्तर नेविगेशन पोर्टल हेडिंग के तहत ऊपर स्थित है

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



नियम २
बड़े खोज फॉर्म बाएं कॉलम में स्थित हैं।

इन्हें लघु और पूर्ण दोनों में प्रदर्शित किया जा सकता है। ऊर्ध्वाधर व्यवस्था से खोज मापदंडों की संख्या को स्वतंत्र रूप से बदलना संभव हो जाता है, जिससे यह सहज और एंड-टू-एंड हो जाता है। यह महत्वपूर्ण है, उदाहरण के लिए, प्रोजेक्ट्स गुड्स और रियल एस्टेट के लिए।



नियम ३
छोटे खोज रूपों को क्षैतिज रूप से व्यवस्थित किया जाता है

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



नियम ४
यदि कोई छोटा खोज फ़ॉर्म है, तो फ़िल्टरिंग दाईं ओर स्थित है

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

एक बार अपनाने के बाद, नियम समाधान और समन्वय खोजने में समय बचाते हैं।

मॉड्यूल

समय और संसाधनों को बचाने के लिए संघर्ष में मॉड्यूल की विरासत एक झटका है। मॉड्यूल टिप्पणियों को जोड़ने के लिए या तो एक साधारण पेजिनेटर हो सकता है या एक काफी चमकदार सिस्टम हो सकता है।

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



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

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

टेम्प्लेट पर काम की मात्रा भिन्न हो सकती है। उदाहरण के लिए, लेखों के एक ब्लॉक में न्यूनतम संशोधन की आवश्यकता होती है।



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

दृश्य एकीकरण

फ़ॉन्ट सिस्टम, ग्राफिक्स, सरल इंटरफ़ेस तत्व

स्टाइलिंग तत्व

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

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

इंटरफ़ेस तत्व

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



प्रतीक और चित्र

दृश्य एकीकरण के लिए सबसे शक्तिशाली उपकरण बुनियादी ग्राफिक तत्वों, माउस और चित्रों की एकल शैली है।



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

एकीकरण के परिणाम

रीडिज़ाइन से पहले परियोजनाओं का प्रकार


रिडिजाइन के बाद प्रोजेक्ट्स का प्रकार



मोबाइल प्रोजेक्ट

क्या किया गया है?

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

मनोरंजक अंकगणित

एक वेब परियोजना की औसत अवधि 2.5 महीने है
डिजाइन प्रक्रिया में प्रतिभागियों की अधिकतम संख्या - 4 लोग
एक परियोजना के लिए लेआउट की औसत संख्या 60 है
मोबाइल प्रोजेक्ट बनाने की औसत अवधि 1 महीने है
एक आवेदन के लिए स्क्रीन की औसत संख्या - 22

निष्कर्ष

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

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

यदि आपके पास छोटी या बड़ी परियोजनाओं को एकीकृत करने का अनुभव है, तो मैं आपको टिप्पणियों में साझा करने के लिए आमंत्रित करता हूं।

किरिल गोलशीव,
ई-कॉमर्स डिज़ाइन टीम लीडर