🧖🏼 ⛳️ 🧙🏿 हमने एक मोबाइल एप्लिकेशन कैसे बनाया है जिसमें एक डिजाइनर की आवश्यकता नहीं है 🚺 🌱 👩🏻‍🎓

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

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

आज, मैं, परियोजना डिजाइनर तैमूर, आपको बताएगा कि हमने मोबाइल एप्लिकेशन को कैसे पुन: डिज़ाइन किया और हमारी डिज़ाइन प्रणाली कैसे दिखाई दी।

यह सब कैसे शुरू हुआ

जब मैं पहली बार परियोजना के लिए आया था, तो आवेदन इस तरह से देखा गया था:

और इससे पहले यह आम तौर पर इस तरह था:

इसमें मुझे क्या सूट नहीं किया:

1. आवेदन का पैमाना नहीं था। प्रारंभ में, हमारे पास 2 मुद्राएँ (EUR और USD) और 2 कार्ड (समान मुद्राओं के लिए) थे। वे दोनों नेत्रहीन और तार्किक रूप से सख्ती से जुड़े हुए थे। डॉलर अनुभाग एक डॉलर कार्ड और इतने पर है। फिर आरयूबी जोड़ा गया और पूरा लेआउट "गो" शुरू हुआ। नए तत्वों को जोड़ने के लिए बैसाखी का उपयोग करना पड़ा। EPayments में मुद्राओं की सूची का विस्तार करने की योजना है और हमें यह पता लगाने की आवश्यकता है कि क्लाइंट के लिए दर्द के बिना उन्हें कैसे जोड़ा जाए। सभी स्क्रीन पर व्यवहार अनुमानित होना चाहिए। यदि एक स्क्रीन पर मुद्राओं की सूची को एक विशिष्ट व्यवहार पैटर्न द्वारा संसाधित किया गया था, तो दूसरी स्क्रीन पर मुद्राओं के साथ काम करने का पैटर्न दोहराया जाना चाहिए।

2. आउटडेटेड डिज़ाइन। आवेदन बहुत "कचरा" और कठिन लग रहा था, मैं अधिक हवा और कम अनावश्यक तत्व चाहता था। अगर हमें 5 मिनट के बाद ही आंखों में दर्द होना शुरू हो जाए तो हमें ग्रैडिएंट्स और "प्रीटीनेस" की आवश्यकता क्यों है?

3. डिजाइन में अंतर। IOS और Android के लिए, मूल रूप से 2 अलग-अलग एप्लिकेशन थे। यदि कोई व्यक्ति एक OS से दूसरे में स्विच करता है, तो उसने सभी संचित उपयोगकर्ता अनुभव खो दिए हैं। सैमसंग का मालिक iPhone के मालिक को ऑपरेशन करने का तरीका नहीं बता सकता था।

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

एक उज्जवल भविष्य डिजाइनिंग

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

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

मैं सबसे सरल सादृश्य की तलाश कर रहा था और महसूस किया कि हमें एक विंडो कंस्ट्रक्टर की आवश्यकता है। हमारे पास नियंत्रण (पीछे, आगे, खाता चयन, विवरण दर्ज करना) और उनके साथ काम करने के नियम (रंग, इंडेंट, तत्व आकार) हैं। डिज़ाइनर में, विश्लेषकों और मोबाइल कार्यकर्ता "मेरे सामने" आने के बिना नए सर्विस कार्ड और मोडल विंडो स्वयं बना सकते हैं।

यह विचार करना महत्वपूर्ण था कि उत्पाद चौड़ाई में विकसित हो रहा है। आज हमारे पास 3 मुद्राएं हैं, एक वर्ष में 33 हो सकते हैं। आज हम पैसे ट्रांसफर करने के लिए 15 तरीके देते हैं, कल यह 115 हो जाएगा। आवेदन में पूरी तरह से नई इकाइयां दिखाई दे सकती हैं: वर्चुअल कार्ड, स्टॉक खरीद या अन्य सेवाएं।

सीमाओं के बंधन को त्यागें

समस्या : परियोजना में तत्वों की बढ़ती संख्या है - मुद्राएं, हस्तांतरण के तरीके, और इसी तरह। कई तत्वों को क्षैतिज रूप से व्यवस्थित किया जाता है, जितना अधिक होगा, इसका उपयोग करने में उतना ही असुविधाजनक होगा।

समाधान : अग्रिम में विस्तार के लिए प्रदान करें, तत्वों की सुविधाजनक स्थिति चुनें।

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

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

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

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

ठीक है, समस्या हल हो गई है, अगले एक पर जाएं।

हम मतभेदों को अतीत में रखते हैं

समस्या : iOS और Android ऐप्स एक जैसे नहीं हैं। उनका डिज़ाइन पुराना है, इंटरफ़ेस में बहुत सारे अतिरिक्त तत्व हैं। क्लाइंट के लिए ध्यान केंद्रित करना कठिन है, वह जल्दी थक जाता है।
समाधान : दिशानिर्देशों के अनुसार आवेदन करें, लेकिन एकीकृत डिजाइन के साथ। ग्रेडिएंट से साफ, प्रयोज्य पर काम करें।

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

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

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

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

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

पहले तो रेटिंग थोड़ी कम हुई, फिर वापस 4.6 पर लौट आई। हमने कुछ महत्वपूर्ण टिप्पणियां कीं और समीक्षाएँ अच्छी और फिर से अच्छी हो गईं। इस क्षण से, आप iOS के लिए आवेदन कर सकते हैं।

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

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

हम सरकार की बागडोर देते हैं

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

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

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

तत्वों को देखें, सभी में कुछ समान है:
• शीर्षासन करना
• "वापस"
• छोटी बूंद
विवरण दर्ज करने के लिए लाइन
• "अगला"

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

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

संक्षेप में देना

मुझे जो अच्छा लगा, मैंने किया। आवेदन अधिक सुंदर हो गया है, इसे ग्राहकों द्वारा सराहा गया। मोर्चों और लामबंदियों के लिए काम करना आसान हो गया है।

हम अभी तक पूरी तरह से मैट्रिक्स का उपयोग नहीं कर रहे हैं जो दिखाते हैं कि उपयोगकर्ता का व्यवहार कैसे बदल गया है। इसलिए अब हम केवल ग्राहक रेटिंग और समीक्षाओं के आधार पर निर्णय ले सकते हैं। रेटिंग वही रही - Google Play पर 4.6, AppStore पर 4.8। अधिकांश नकारात्मक समीक्षा सत्यापन प्रक्रिया से संबंधित हैं, यह ग्राहकों को लंबे समय तक लगता है। और सकारात्मक में, ऐप की अक्सर प्रशंसा की जाती है।

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

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

नौकरी की तलाश है?

हम सेंट पीटर्सबर्ग में एक कार्यालय में काम करने के लिए कर्मचारियों की तलाश कर रहे हैं। यदि आप फिनटेक में रुचि रखते हैं, तो हम आपकी प्रतीक्षा कर रहे हैं। नीचे आपको hh.ru के संबंधित पृष्ठों के रिक्त स्थान और लिंक मिलेंगे।

हमने एक मोबाइल एप्लिकेशन कैसे बनाया है जिसमें एक डिजाइनर की आवश्यकता नहीं है