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

मुझे नहीं पता कि मैं अभी तक क्या कर रहा हूं …

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

ऐसे में आपको जितना हो सके उतना लचीला होना होगा। हालाँकि, अपने निर्णयों का दस्तावेजीकरण करें यदि आप नहीं चाहते कि सफल निर्णय "काला जादू" बने रहें और असफल निर्णय एक अज्ञात संयोग के रूप में बने रहें।

मेरा मतलब सिर्फ निर्णय को लिखना नहीं है, लेकिन आप (या अन्य) वहां कैसे पहुंचे। तर्क, आदि। हाँ, यह कभी-कभी कठिन हो सकता है। खासकर जब निर्णय सहज (आंत लग रहा था) था। हालांकि, अगर आप खुद से और दूसरों से सवाल करना सीखते हैं, तो आप अंततः विचार के स्रोत को समझना शुरू कर सकते हैं।

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

मैंने इसे पहले कहीं देखा है …

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

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

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

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

" यदि यह प्रलेखित नहीं है, तो यह मौजूद नहीं है "

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

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

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

डिजाइन पुस्तकालय ≠ डिजाइन प्रणाली

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

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

कुछ ऐसा ही, लेकिन थोड़ा अलग....

मेरी राय में, सबसे कठिन काम तब होता है जब उपयोगकर्ता छोटे बदलावों का अनुरोध करते हैं। काफी छोटे परिवर्तन:

• शीर्षलेखों में आइकनों का उपयोग करने की क्षमता जोड़ें।
• सूची में ब्लॉकों का क्रम बदलें।
• 2 के बजाय 3 बटन दिखाएं (एक घटक द्वारा परिभाषित)।

• अन्य घटकों के साथ दृष्टिकोण की संगति।
• कोड और डिजाइन घटकों (फिग्मा, स्केच, आदि) में कार्यान्वयन की जटिलता।

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

कार्यान्वयन की जटिलता

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

हम नौकर हैं, तानाशाह नहीं

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

• संभावना में लचीलेपन की कमी
• समाधान के विकास में देरी (समाधान की जटिलता और इसके रखरखाव के कारण)
• अन्य घटकों या समझौतों में व्यापक परिवर्तन की आवश्यकता
स्टीवर्डिंग डिजाइन सिस्टम योगदान

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

"नहीं" कहने के सभी कारण केवल यह सुनिश्चित करने के लिए हैं कि हम वह उत्पाद बनाते हैं जिसकी उपयोगकर्ताओं को आवश्यकता है, न कि वह जिसे वे चाहते हैं।

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

पढ़ने के लिए धन्यवाद! आइये संपर्क में रहते हैं! लिंक्डइन पर मेरे साथ जुड़ें और अधिक डिजाइन-संबंधित सामग्री के लिए ड्रिबल पर और यहां माध्यम पर मेरा अनुसरण करें ।