डिजाइन कार्यप्रणाली का विश्लेषण: त्रुटियों, स्थितियों और उनसे उपयोगी निष्कर्ष

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

मैं पिछले दो वर्षों में इन त्रुटियों और निष्कर्षों की समीक्षा के साथ शुरू करूंगा। मुझे उम्मीद है कि यह आपके लिए उपयोगी होगा। अलग-अलग, मुझे आपके व्यक्तिगत अनुभव से प्रतिक्रिया मिलने की उम्मीद है।

जानकारी एकत्र करने के चरण में जितना संभव हो उतना क्लाइंट से बात करें

मैंने साझा (और आंशिक रूप से अब साझा) यह राय दी कि ग्राहक की परियोजना अक्सर औसत दर्जे के या अप्रस्तुत लोगों के नेतृत्व में होती है, लेकिन इसका मतलब यह नहीं है कि आपको उनसे बात करने की आवश्यकता नहीं है। किसी को भी ग्राहक के व्यवसाय / परियोजना के बारे में अधिक जानकारी नहीं है; यहां तक ​​कि अगर वह एक बाज़ारिया है जो अपने दर्शकों को "25-50 वर्ष, पुरुषों" के रूप में वर्णित करता है।

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

ग्राहक को सूचना संग्रह की पूर्णता और गुणवत्ता के लिए जिम्मेदारी सौंपे

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

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

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

मार्केटिंग, पोजिशनिंग क्लाइंट की एकमात्र जिम्मेदारी है

मुझे विश्वास था कि मैं क्लाइंट को स्थिति के बारे में कुछ बता सकता हूं, और यह अच्छा होगा। हां, मैं बता सकता हूं, लेकिन अक्सर यह: क) ग्राहक द्वारा स्वीकार नहीं किया जाता है, क्योंकि वह "सबसे अच्छा जानता है"; ख) मूर्खता, क्योंकि ग्राहक वास्तव में बेहतर जानता है।

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

ग्राहक को असुविधाजनक / कठिन स्थिति में रखें

जानकारी एकत्र करने के चरण में, असुविधाजनक (यहां तक ​​कि थोपा हुआ) सवाल बेहद प्रभावी साबित हुए। उदाहरण के लिए:

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

यह आश्चर्यजनक है कि इस समय ग्राहक का सिर कितनी अच्छी तरह काम करना शुरू कर देता है। मुझे शर्म आ रही है और मैं जल्दी से सब कुछ ठीक करना चाहता हूं?

स्केच की जरूरत!

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

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

• एक मसौदे की तरह देखें और इस तरह सोचने का मामूली कारण न दें कि यह एक डिजाइन है;
• स्पष्ट रूप से तर्क और सामग्री को प्रतिबिंबित करें, वास्तविक सामग्री के साथ, लोरेम इप्सम नहीं!

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

रेखाचित्रों में तर्क को देखें, नहीं

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

• उस पर ग्राहक को फोकस करें, और लोगो और लिंक के रंग के आकार पर नहीं;
• स्केचिंग के लिए समय कम करें;
• ग्राहक और डिजाइनर के लिए अधिकतम जानकारी लाने के लिए;
• डिज़ाइनर और इंटरफ़ेस समाधान में डिज़ाइनर को एक निश्चित स्वतंत्रता दें।

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

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

रेखाचित्रों के बाद तर्क का वर्णन करें

हां, मैं सोचता था कि मुझे पूरे तर्क का वर्णन करने की आवश्यकता है, और फिर इसके रेखाचित्र बनाएं। अब मुझे एहसास हुआ कि ये प्रक्रियाएं समानांतर में चल रही हैं, और पहले मुख्य बिंदुओं (अवधारणा, सामान्य संरचना) की पहचान करना बेहतर है, रेखाचित्रों के विवरण पर काम करें और फिर यह सब वर्णन करें।

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

रेखाचित्रों का परीक्षण करें

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

साथ में डिजाइनिंग बेस्ट है

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

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

ग्राहक जानकारी लेना

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

यह सभी के समय और तंत्रिकाओं को बचाएगा, सही निर्णयों को समझने और सहमत होने की उच्च संभावना के साथ। यदि आप ऐसा नहीं करते हैं, तो आप फिर से डिजाइन करेंगे, लेकिन डिजाइन बनाने के स्तर पर या इससे भी बदतर, प्रोग्रामिंग। कम पैसा, समय और प्रतिष्ठा , क्योंकि यह आप ही हैं जो दोष देते हैं।

ग्राहक को तकनीकी जानकारी के साथ लोड न करें

तकनीकी विवरणों को मानव-पठनीय बनाने का प्रयास करें। इसके बजाय "सीएमएस में निम्नलिखित क्षेत्रों के साथ" समाचार "इकाई के संपादन के लिए कार्यक्षमता शामिल है: 1) शीर्षक, 2) विवरण ..." लिखिए "नियंत्रण कक्ष को समाचार के शीर्षक और सामग्री को संपादित करने की अनुमति देनी चाहिए"। इस तरह आप अधिक समझ और कम जलन हासिल करेंगे; शब्द "desription" और "शीर्षक" बिल्कुल भी आपके व्यावसायिकता को नहीं दिखाते हैं, जैसा कि कई लोग सोचते हैं, लेकिन बस क्रोध करते हैं।

महिलाओं पर अत्याचार न करें

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

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

सुनिश्चित करें कि ग्राहक समाधान लागू करने में सक्षम है।

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

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

सामग्री बनाने के लिए सिफारिशें दें

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

एक बार में दो से अधिक प्रोजेक्ट न करें

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

काम करने के लिए "समान" प्रोजेक्ट लें, लेकिन एक ही समय में नहीं

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

ग्राहक-डिजाइनर के लिए निर्णायक "नहीं!"

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

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

निष्कर्ष

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

अगले लेख में, मैं एक अवधारणा (वेबसाइट या सेवा) बनाने के लिए एक त्वरित और प्रभावी तरीका पेश करूंगा। मैं जानबूझकर जानकारी इकट्ठा करने के चरण को छोड़ देता हूं, क्योंकि लगभग सब कुछ इसके बारे में कहा जाता है: habrahabr.ru/company/kelnik/blog/155003 ।