1. उद्देश्य: एक काम करने वाला उत्पाद जिसका लोग उपयोग करते हैं

इतना आसान लक्ष्य। हम प्रत्येक शब्द का विश्लेषण करेंगे, क्योंकि यह केवल इन शब्दों द्वारा तैयार नहीं है।

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

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

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

वैसे भी, शब्द वापस करने के लिए।

1. एक कार्यशील उत्पाद वह है जिसका उपयोग समस्याओं को हल करने के लिए किया जा सकता है। यह उत्पाद का उपयोग करके समस्या को हल करने की तकनीकी क्षमता के बारे में है।
2. उत्पाद एक तरह की संपूर्ण इकाई है, पूरी, उन अवयवों की मात्रा में, जिनका मूल्य अलग-अलग लिया गया है।
3. उपयोग - मांग और सुविधा की बात करता है।
4. लोग "ग्राहक", "उपयोगकर्ता", "कर्मचारी", आदि की तुलना में एक व्यापक अवधारणा हैं। लोगों के लिए काम करते समय, हम एर्गोनॉमिक्स और कुछ मानकों को ध्यान में रखते हैं।

मान लीजिए कि उत्पाद काम नहीं करता है। यहां सब कुछ स्पष्ट है: उनका उपयोग नहीं किया जाएगा (कम से कम उनके इच्छित उद्देश्य के लिए)।

या यह एक उत्पाद नहीं है: असमान घटकों का एक सेट जो किसी भी संकेत द्वारा परस्पर जुड़ा नहीं है (यह भी होता है)।

या कोई उत्पाद है, लेकिन वे इसका उपयोग नहीं करते हैं (बिल्कुल भी)। इसके अलावा एक विफलता, यह कोई भी हो सकता है: विपणन की कमी, असुविधाजनक, धीमा हो जाता है।

यदि लोग इसका उपयोग नहीं करते हैं ... तो, मैं मानता हूं, पूरी तरह से अलग डिजाइन सिद्धांत होंगे।

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

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

पुनश्च लिंक सूचीबद्ध तरीकों के विवरण के लिए, विकिपीडिया:

• चंचल (फुर्तीली) - लचीली विकास पद्धति
• स्क्रम (स्क्रेम) - चुस्त सॉफ्टवेयर विकास के लिए एक रूपरेखा (टीम वर्क)
• कंबन (कंबन) - उत्पादन और आपूर्ति के संगठन की एक प्रणाली, "बस समय में" के सिद्धांत को लागू करने की अनुमति देती है।

2. स्कैम टीम में डिजाइनर की भूमिका

अक्सर एक उत्पाद टीम में एक डिजाइनर की भूमिका अतिरंजित होती है क्योंकि वे परिणाम के बजाय प्रक्रियाओं और अनुक्रम (क्रियाओं) के संदर्भ में सोचते हैं।

(उद्देश्य की श्रेणियों द्वारा, परिणाम से सही ढंग से सोचने के लिए।)

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

"हम लेआउट के लिए इंतजार कर रहे हैं" - अगर यह लगता है, तो टीम में प्रक्रियाओं को सही ढंग से व्यवस्थित नहीं किया जाता है।

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

स्टार्टअप पर ध्यान दें - फेसबुक, Vkontakte, Odnoklassniki और Microsoft के साथ एक ही Apple: वे इंजीनियरिंग समाधान (वोज्नियाक, गेट्स) पर आधारित हैं, जो बाद में डिजाइनरों में शामिल हो गए। उन्होंने उद्देश्य के अनुसार उत्पादों का निर्माण किया।

सबसे पहले एक काम कर उत्पाद है।

(सुंदर, न्याय की खातिर, ज़ेरॉक्स प्रयोगशाला में वैचारिक लोगों ने किया, लेकिन परिणामों का पैमाना पूरी तरह से अलग है।)

•••

फिर डिजाइनर की भूमिका क्या है?

मान जोड़ने के लिए।

आप मौजूदा चीज़ में कुछ जोड़ सकते हैं , ध्यान दें।

ग्राहकों, उपयोगकर्ताओं की नज़र में मूल्य।

•••

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

•••

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

लेआउट के बजाय कोड से शुरू करें।

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

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

विकास से हटकर डिजाइन तैयार करना बेहतर है। कोड से शुरू करें - प्रोटोटाइप जो क्लाइंट के कार्य को न्यूनतम तरीके से करता है। एक प्रोटोटाइप जो कार्यशील आपूर्ति में जा सकता है (ग्राहक विकास के बारे में बाद में याद रखें)।

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

टेकअवे

उपयोगकर्ता के कार्य को समझें।

शुरुआत विकास से करें। डेवलपर के साथ मिलकर काम करें (एक कला निर्देशक और कॉपीराइटर के रूप में)।

लेआउट के बजाय एक कार्यशील उत्पाद में सुधार करें।

प्रक्रियाओं के बजाय लक्ष्यों, परिणामों के संदर्भ में सोचें।

उत्पाद डिजाइनर उत्पाद बनाता है, न कि लेआउट।

3. विधि

यह विधि, घटकों के पुस्तकालय के साथ मिलकर, बैंकिंग डिजाइन प्रणाली का आधार बन गई है ।

मैं निम्नलिखित अनुक्रम में काम करने का प्रस्ताव करता हूं:

1. ग्राहक (उपयोगकर्ता) के कार्य को पहचानें और इसे उपयोगकर्ता कहानी के रूप में प्रतिबद्ध करें।
2. मैट्रिक्स को परिभाषित करें। हम कैसे समझते हैं कि उपयोगकर्ता का कार्य हल हो गया है? सुरक्षित करें।
3. परिकल्पना तैयार करें। सुरक्षित करें।
4. ग्राहक यात्रा का नक्शा।
5. एक कार्यशील प्रोटोटाइप। एमवीपी। ग्राहक विकास।
6. लेआउट। (टीमवर्क और मौजूदा डिज़ाइन सिस्टम के साथ, आप लेआउट के बिना कर सकते हैं)।

ग्राहक कार्य

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

ग्राहक के कार्य की पहचान या तो शिकायतों ("ग्राहक पीड़ा") या अनुसंधान आवश्यकताओं के आधार पर की जाती है।

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

जब किसी कार्य का एहसास होता है, तो उसे उपयोगकर्ता कहानी के रूप में दर्ज किया जाता है। इस बारे में कई लेख और किताबें लिखी गई हैं, इसलिए मैं यहां खुद को नहीं दोहराऊंगा - अपने दम पर अध्ययन।

इस मुद्दे की जानकारी के लिए, मैं अत्यधिक रूप से पुस्तक यूजर स्टोरी मैपिंग: डिस्कवर द होल स्टोरी, बिल्ड द राइट प्रोडक्ट (जेफ पैटन एंड पीटर इकोनॉमी) की सिफारिश करता हूं।

दो प्रकार के मैट्रिक्स (दोनों को ठीक करना महत्वपूर्ण है!)

1. प्रश्न का औपचारिक उत्तर "हम कैसे समझते हैं कि उपयोगकर्ता का कार्य हल हो गया है।" जिसे हम समाधान के रूप में प्राप्त करना चाहते हैं।
2. डिजिटल: सापेक्ष और पूर्ण मूल्य। मात्रात्मक संकेतक (वित्तीय, गति, ग्राहकों, समय) के बारे में अधिक बार। हम कैसे समझते हैं कि निर्णय सफल है। एक चाल है: अक्सर प्रस्तुतियों में, सापेक्ष मूल्य छिपाए जाते हैं, अतिरंजित होते हैं या निर्णय के उद्देश्य पैमाने को खो देते हैं। उदाहरण के लिए, "दर्शकों की वृद्धि 3% थी" - क्या यह बहुत कम है या थोड़ा है? यदि यह 150,000 लोगों (स्कूलों और किंडरगार्टन, दुकानों और अपने प्रशासन के साथ एक शहरी प्रकार का निपटान) है, तो यह पहले से ही एक प्रभावशाली संख्या है, हालांकि यह छोटी चीजों की तरह लगता है। दूसरी ओर, "300% लाभ वृद्धि", यदि यह प्रति माह 300 रूबल है, तो पहले से ही एक संदिग्ध संकेतक है। और फिर, यदि 150,000 लोग पूरे उत्पाद के दर्शकों के आकार में एक सांख्यिकीय त्रुटि हैं (उदाहरण के लिए, प्रति वर्ष खोज इंजन के मुख्य पृष्ठ पर जाकर), तो ये आकार सबसे अधिक उपेक्षित हो सकते हैं, हालांकि हम उसी शहरी प्रकार के गांव की आबादी के बारे में बात कर रहे हैं।

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

परिकल्पना - उपयोगकर्ता की समस्या को हल करने के सबसे तेज़ तरीके के बारे में सवाल का जवाब

समस्या के हमेशा कई समाधान होते हैं। विकास (डिजाइन) में एक तक सीमित नहीं किया जा सकता है! पहले से कोई नहीं जानता कि कौन सबसे अच्छा काम करेगा।

मानसिक कार्य करें और कम से कम तीन अलग-अलग समाधानों के साथ आएं।

ध्यान रखें कि उत्तरोत्तर बदलते लेआउट के रूप में एक विचार को "विकसित करना" एक समाधान है, तीन नहीं (या आप कितने अलग-अलग लेआउट बनाने में कामयाब रहे हैं)।

सादगी के लिए, तीन तरीकों की कोशिश करें:

1. इंटरफ़ेस समाधान। कई भी हो सकते हैं।
2. स्वचालित (उदाहरण के लिए, किसी घटना की घटना पर सर्वर पर एक कार्य किया जाता है) - उपयोगकर्ता के हस्तक्षेप के बिना।
3. प्रक्रियाएं - प्रक्रियाओं में क्या बदला जा सकता है ताकि उपयोगकर्ता को किसी कार्य का सामना न करना पड़े, लेकिन सही समय पर एक समाधान प्राप्त होता है।

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

ग्राहक यात्रा का नक्शा प्रसंग में डूबता है

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

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

CJM के बारे में काफी कुछ लिखा गया है, आपको इसे स्वयं अध्ययन करने और इसे अपने काम में लागू करने की आवश्यकता है।

आप जेफ पैटन की पुस्तक " कस्टम स्टोरीज़ " से शुरू कर सकते हैं।

एक कार्यशील प्रोटोटाइप। एमवीपी। ग्राहक विकास।

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

« . Lean Startup -» . .

MVP, . .

,

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

टेकअवे

जानकारी के लिए

सबसे बड़ी चीज जो आप कर सकते हैं

, / , . , .

.

, - , . , , . -. : , - , . , , , .

: , , . . , , .

, . ( ), , , , . , ( , «»; — ).

: , . , . — -: , — . -, . , , , , . ( «»), /. / , : / , , .

, .

, .

?

, / (), , , , . . , , .

, .

: ?

? ?

?

30 ? ?

? , ?

?

, ?

— , . .

, . — , : , . .

.

« », .

, . , . . , - . .

: .

? . ? .

. , — «» :-)

.

. : , , .

, , . ( ).

: , . : / .

:

1. , : , -, (// ). . ( ).
2. , , — . , : , «, » ( ), , «», . — .
3. , . , — . — /, . — , , , , . - . , — . « ».

कुल मिलाकर

1. — .
2. — .
3. «» .
4. सब कुछ जो केवल "विशेषज्ञ राय" और "अनुभव" (विशिष्ट इंटरफ़ेस / उत्पाद समाधान में) द्वारा समर्थित है, साहसपूर्वक कूड़ेदान में भेजा जाता है - आपको केवल वास्तविक उपयोगकर्ताओं के व्यवहार को देखने पर ध्यान केंद्रित करने की आवश्यकता है।

और एक और बोनस

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

EPub डाउनलोड करें