डिज़ाइन क्रिटिक फ्रेमवर्क: ऐसे रिव्यू कैसे चलाएँ जो काम को सच में बेहतर बनाएँ
डिज़ाइन क्रिटिक चलाने और उससे गुज़रने के लिए एक काम करने वाले डिज़ाइनर की गाइड। वे फ्रेमवर्क, नियम और ढाँचा जो रिव्यू को अहं की रक्षा से असली फीडबैक में बदल देते हैं।
ज़्यादातर डिज़ाइन रिव्यू नौटंकी होते हैं। सीनियर डिज़ाइनर बटन के रंग पर 20 मिनट बोलता रहता है, जूनियर डिज़ाइनर सिर हिलाता है, और काम जैसा था वैसा ही या उससे बदतर होकर शिप हो जाता है। कोई कुछ नहीं सीखता, काम बेहतर नहीं होता, और जिस मीटिंग से टीम को तेज़ होना था, उसी से टीम डरने लगती है।
यह पेपर उसका काम करने वाला संस्करण है। वे फ्रेमवर्क जो क्रिटिक को औज़ार बनाते हैं, वे नियम जो अहं को कमरे से बाहर रखते हैं, और वह ढाँचा जो स्क्रीन पर जिसका काम है उसके लिए फीडबैक को सचमुच उपयोगी बनाता है। "डिज़ाइन कल्चर" के खोखले प्रवचन नहीं, घोषणापत्र नहीं, बस उस टीम की संचालन प्रक्रिया जो अच्छे रिव्यू की वजह से बेहतर काम शिप करती है।
डिज़ाइन क्रिटिक असल में क्या है
डिज़ाइन क्रिटिक चालू काम की संरचित पीयर रिव्यू है। इसका लक्ष्य वे समस्याएँ सामने लाना है जो डिज़ाइनर अपने ही ड्राफ्ट के अंदर से नहीं देख पाता, और शिप होने से पहले काम को यूज़र, ब्रीफ और सिस्टम के सामने परखना है। क्रिटिक अप्रूवल नहीं है, समर्थन नहीं है, और वोट भी नहीं है।
क्रिटिक प्रेजेंटेशन भी नहीं है। डिज़ाइनर वहाँ काम का बचाव करने नहीं आया है। रिव्यूअर वहाँ उसकी तारीफ़ करने नहीं आए हैं। दोनों पक्ष इसलिए हैं कि काम का अगला संस्करण मौजूदा संस्करण से बेहतर बने।
डिज़ाइन पोर्टफोलियो गाइड बताती है कि अलग-अलग काम का बाहर से मूल्यांकन कैसे होता है। यह पेपर टीम के अंदरूनी रिव्यू पर गहराई से जाता है, जिसके लक्ष्य अलग हैं और नियम बिल्कुल अलग।
ज़्यादातर क्रिटिक क्यों फेल होते हैं
जो भी टीम क्रिटिक में जूझती है, उसमें लगभग हर बार वही पाँच गड़बड़ियाँ दिखती हैं। अगर मीटिंग थका देने वाली लगे और काम बेहतर न हो, तो पहले यहीं देखिए।
डिज़ाइनर प्रेजेंट कर रहा है, माँग नहीं रहा। काम शुरू से अंत तक समझाया जाता है, रिव्यूअर शिष्टता से इंतज़ार करते हैं, और कोई ख़ास फीडबैक माँगा ही नहीं जाता। कुछ भी स्कोप नहीं हुआ, इसलिए रिव्यूअर ऊपर-ऊपर की प्रतिक्रियाओं पर उतर आते हैं।
रिव्यूअर होड़ में हैं। हर कोई सबसे चतुर मुद्दा सबसे पहले पकड़ने की कोशिश करता है। बातचीत उसी की ओर बह जाती है जो सबसे सीनियर सुनाई दे। डिज़ाइनर बारह परस्पर विरोधी राय लेकर लौटता है और आगे का कोई साफ़ रास्ता नहीं मिलता।
निजी पसंद को सिद्धांत का लिबास पहनाया जाता है। रिव्यूअर को टाइपफेस पसंद नहीं, और वह इसे हायरार्की की समस्या बता देता है। किसी को दूसरा लेआउट पैटर्न पसंद है, और वह इसे एक्सेसिबिलिटी का मुद्दा बता देता है। फ्रेमवर्क के बिना पसंद जीत जाती है।
कोई कुछ लिखता नहीं। बातचीत होती है, मीटिंग ख़त्म होती है, और डिज़ाइनर को शायद 30% ही याद रहता है। अगला क्रिटिक वही पुरानी ज़मीन दोहराता है।
क्रिटिक बहुत देर से होता है। काम 90% पूरा हो चुका है। बड़े पुनर्गठन वाला फीडबैक अनसुना रह जाता है क्योंकि समय नहीं है। क्रिटिक सिर्फ़ पॉलिश करने तक सिमट जाता है।
इनमें से हर एक ठीक हो सकती है। इस पेपर का बाकी हिस्सा वही इलाज है।
तीन-परत वाला फीडबैक मॉडल
उपयोगी डिज़ाइन फीडबैक का हर टुकड़ा तीन परतों में से किसी एक में आता है। जो रिव्यूअर अपनी परत का नाम ले सकते हैं, वे केंद्रित रहते हैं। जो नहीं ले सकते, वे पसंद-नापसंद में बह जाते हैं।
परत 1: अवलोकन
अवलोकन वह है जो रिव्यूअर को स्क्रीन पर सचमुच दिखता है। कोई व्याख्या नहीं, कोई फ़ैसला नहीं।
"1440 चौड़े व्यूपोर्ट पर CTA फोल्ड के नीचे है।" यह अवलोकन है। "बटन छोटा है।" यह अवलोकन है। "इस पेज पर तीन अलग-अलग सैन्स-सेरिफ़ दिख रहे हैं।" यह अवलोकन है।
अवलोकन पर बहस नहीं होती। डिज़ाइनर इन्हें स्क्रीन पर उसी वक़्त जाँच सकता है। यह सबसे सुरक्षित परत है क्योंकि कोई भी पक्ष इससे असहमत नहीं हो सकता।
परत 2: व्याख्या
व्याख्या यह है कि अवलोकन का यूज़र, ब्रांड या सिस्टम के लिए क्या मतलब हो सकता है।
"CTA के फोल्ड के नीचे होने का मतलब है कि मोबाइल यूज़र शायद यह समझने से पहले ही उसके पार स्क्रॉल कर जाएँगे कि पेज उनसे क्या कराना चाहता है।" यह व्याख्या है। "तीन सैन्स-सेरिफ़ असंगत लगते हैं, जिससे यूज़र को संकेत मिलता है कि ब्रांड वॉइस साफ़ नहीं है।" यह व्याख्या है।
व्याख्याएँ चर्चा के लिए खुली होती हैं। दो लोग एक ही अवलोकन की अलग व्याख्या कर सकते हैं। क्रिटिक का उपयोगी हिस्सा यही है। व्याख्या वह जगह है जहाँ टीम का सामूहिक अनुभव डिज़ाइनर के अकेले ड्राफ्ट में मूल्य जोड़ता है।
परत 3: सुझाव
सुझाव वह है जो रिव्यूअर उस व्याख्या के बारे में करने पर विचार करेगा।
"आप CTA को फोल्ड के ऊपर ले जाकर या स्क्रॉल पर स्टिकी CTA जोड़कर टेस्ट कर सकते हैं।" यह सुझाव है। "आप बॉडी के लिए एक सैन्स-सेरिफ़ और डिस्प्ले के लिए एक फ़ॉन्ट पर आ सकते हैं, फिर एक त्वरित स्क्विंट टेस्ट से हायरार्की परख सकते हैं।" यह सुझाव है।
सुझाव मानना डिज़ाइनर की मर्ज़ी है। काम का मालिक डिज़ाइनर है। रिव्यूअर विकल्प दे रहा है, आदेश नहीं। जिस क्रिटिक में सुझाव मानना ज़रूरी हो, वह क्रिटिक नहीं, कमांड की श्रृंखला है।
वे क्रिटिक फ्रेमवर्क जो सच में काम करते हैं
फ्रेमवर्क मीटिंग की स्क्रिप्ट है। यह उसी पल यह सोचने का बोझ हटा देता है कि फीडबैक कैसे दिया जाए, और रिव्यूअर को काम पर ध्यान देने देता है।
फ्रेमवर्क 1: लक्ष्य, तर्क, फीडबैक
लगाने में सबसे तेज़। तीन चरण, हर काम के लिए दस मिनट।
चरण एक: डिज़ाइनर लक्ष्य बताता है। "मैं यूज़र को होम पेज से एक क्लिक में पेड साइनअप तक पहुँचाने की कोशिश कर रहा हूँ।" ज़्यादा से ज़्यादा दो वाक्य।
चरण दो: डिज़ाइनर तर्क समझाता है। "मैंने CTA को हीरो में रखा क्योंकि पिछले टेस्ट में दिखा कि 60% कन्वर्ज़न फोल्ड के ऊपर होते हैं। मैंने हरा रंग इसलिए चुना क्योंकि ब्रांड इसे प्राइमरी एक्शन के लिए इस्तेमाल करता है।" ज़्यादा से ज़्यादा तीन मिनट।
चरण तीन: रिव्यूअर लक्ष्य के सामने फीडबैक देते हैं। हर टिप्पणी बताए गए लक्ष्य से जुड़नी चाहिए। "क्या CTA लक्ष्य का समर्थन करता है?", न कि "क्या CTA हरे का सही शेड है?"
जो फीडबैक लक्ष्य से नहीं जुड़ता, उसे बाद के लिए अलग सूची में रख दिया जाता है। मीटिंग केंद्रित रहती है। डिज़ाइनर आगे का साफ़ रास्ता लेकर निकलता है।
फ्रेमवर्क 2: मुझे पसंद आया, मेरी इच्छा है, क्या हो अगर
IDEO से उधार लिया और डिज़ाइन टीमों के लिए ढाला गया। तब उपयोगी जब काम शुरुआती और खोजी अवस्था में हो।
मुझे पसंद आया: क्या काम कर रहा है। रिव्यूअर उन ख़ास तत्वों के नाम लेते हैं जिन्हें काम में रखा जाना चाहिए। यह सकारात्मक अवलोकन को मजबूर करता है, जिसे ज़्यादातर क्रिटिक छोड़ देते हैं।
मेरी इच्छा है: रिव्यूअर क्या बदलना चाहेगा। इच्छा के रूप में कहा जाता है, आदेश के रूप में नहीं। "काश हेडलाइन और बॉडी के बीच कॉन्ट्रास्ट ज़्यादा मज़बूत होता।"
क्या हो अगर: अनुमान आधारित विकल्प। "क्या हो अगर CTA इनलाइन की जगह स्टिकी एलिमेंट हो?" ऐसी दिशाएँ खुलती हैं जिनके बारे में डिज़ाइनर ने शायद सोचा न हो।
यह फ्रेमवर्क इसलिए चलता है क्योंकि यह दाँव घटा देता है। इच्छाएँ और "क्या हो अगर" सहयोगी लगते हैं। सीधी आलोचना अक्सर विरोधी लगती है, भले वह हो न।
फ्रेमवर्क 3: डिसीज़न स्टैक
उन देर के चरण वाले कामों के लिए सबसे अच्छा, जहाँ टीम तय कर रही है कि क्या शिप होगा।
ज़रूरी फ़ैसला: डिज़ाइनर को ठीक किस पर फ़ैसला चाहिए? "क्या सेकंडरी CTA रहे या कटे?" यह नहीं कि "इस मॉकअप को रिव्यू कर दो।"
मेज़ पर विकल्प: डिज़ाइनर ने क्या-क्या सोचा? जो विकल्प ख़ारिज हुए, वे दिखाइए। रिव्यूअर पूछ सकते हैं कि ख़ास विकल्प क्यों हटाए गए।
सिफ़ारिश: डिज़ाइनर क्या सुझाता है और क्यों?
जोखिम: सिफ़ारिश में क्या गड़बड़ हो सकती है?
रिव्यूअर का काम सिफ़ारिश को जोखिमों के सामने परखना है। क्या डिज़ाइनर से कोई जोखिम छूट गया? क्या जोखिमों का वज़न सही है? क्या दिखाए गए विकल्पों में सिफ़ारिश सच में सबसे मज़बूत है?
यह फ्रेमवर्क डिज़ाइनरों को मीटिंग से पहले मेहनत करने पर मजबूर करता है। मीटिंग सोच की परीक्षा बन जाती है, शून्य से नई सोच गढ़ने का मंच नहीं।
वे नियम जो कमरे को कामकाजी रखते हैं
फ्रेमवर्क मीटिंग को ढाँचा देते हैं। नियम उसके अंदर के व्यवहार को संभालते हैं। नियमों के बिना सबसे अच्छा फ्रेमवर्क भी उसी ढीली बातचीत में ढह जाता है जो पिछली बार काम नहीं आई थी।
नियम 1: डिज़ाइनर फीडबैक का दायरा तय करता है
क्रिटिक शुरू होने से पहले डिज़ाइनर बताता है कि उसे किस तरह का फीडबैक चाहिए। "मुझे हायरार्की और CTA पर फीडबैक चाहिए। कलर पैलेट लॉक है, कॉपी फ़ाइनल है।" यह डिज़ाइनर का समय और रिव्यूअर का ध्यान, दोनों बचाता है।
अगर कोई रिव्यूअर दायरे से बाहर की किसी चीज़ पर टिप्पणी करना चाहता है, तो वह उसे मीटिंग के बाद या अलग सेशन के लिए नोट कर लेता है। वह क्रिटिक को पटरी से नहीं उतारता।
नियम 2: एक समय में एक ही बातचीत
साइड बातचीत क्रिटिक को मार देती है। पूरा मक़सद एक काम पर सामूहिक ध्यान है। अगर दो रिव्यूअर आपस में बहस करने लगें, तो फैसिलिटेटर उन्हें समूह में वापस खींच लाता है। अगर तीन चीज़ों पर चर्चा करनी है, तो वे एक-एक करके होंगी, समानांतर नहीं।
नियम 3: सामान्य नहीं, विशिष्ट
"कुछ गड़बड़ लग रहा है" फीडबैक नहीं है। "CTA ग्रेडिएंट बैकग्राउंड के सामने कॉन्ट्रास्ट खो देता है, जिससे लाइट मोड में विज़िबिलिटी शायद घटती है" फीडबैक है। जो रिव्यूअर सामान्य प्रतिक्रियाएँ देते हैं, उनसे विशिष्ट होने या पास करने को कहा जाता है।
नियम 4: अवलोकन के बिना कोई नुस्ख़ा नहीं
रिव्यूअर पहले उस अवलोकन को बताए बिना कोई बदलाव नहीं सुझा सकता जिसने उसे प्रेरित किया। "बटन को नीला कर दो" अवलोकन के बिना नुस्ख़ा है। "मौजूदा लाल बटन आपकी एरर स्टेट के क़रीब पढ़ा जाता है, जो अहम फ्लो में यूज़र को भ्रमित कर सकता है। आप नीला या कोई दूसरा लाल आज़मा सकते हैं" यह अवलोकन, व्याख्या और सुझाव है।
यह नियम टीम का लगाया जा सकने वाला सबसे ताक़तवर बदलाव है। यह रिव्यूअर को बोलने से पहले सोचने पर मजबूर करता है और डिज़ाइनर को सिर्फ़ माँग नहीं, तर्क देता है।
नियम 5: सब कुछ दर्ज करें
कमरे में कोई नोट्स लेता है। अवलोकन, व्याख्याएँ, सुझाव, फ़ैसले, फ़ॉलो-अप। डिज़ाइनर नोट लेने वाला नहीं होना चाहिए क्योंकि वह फीडबैक का जवाब देने में पहले ही बहुत लदा होता है।
नोट्स मीटिंग के तुरंत बाद डिज़ाइनर को भेज दिए जाते हैं। डिज़ाइनर हर नोट को स्वीकृत, कारण सहित अस्वीकृत, या बाद के लिए पार्क किया हुआ चिह्नित करता है। अगला क्रिटिक इस बात से शुरू होता है कि पिछली बार से क्या बदला।
नियम 6: समय-सीमा और तय नतीजा
क्रिटिक मीटिंग का अंत का समय पक्का होता है। हर काम को निश्चित स्लॉट मिलता है, आमतौर पर 15 से 30 मिनट। फैसिलिटेटर इसे लागू करता है। खिंचना टीम की ऊर्जा खोने और लोगों को मीटिंग में काम लाना बंद करवाने का सबसे तेज़ तरीक़ा है।
हर स्लॉट एक बताए गए नतीजे पर ख़त्म होता है। "डिज़ाइनर CTA को फोल्ड के ऊपर ले जाएगा और ग्रेडिएंट बैकग्राउंड पर कॉन्ट्रास्ट टेस्ट करेगा। अगले क्रिटिक में v2 साझा करेगा।" अगर कोई नतीजा नहीं है, तो मीटिंग ने कोई मूल्य नहीं बनाया।
क्रिटिक कब होना चाहिए
देर के चरण का क्रिटिक लगभग हमेशा बहुत देर से होता है। क्रिटिक का सबसे ज़्यादा असर वहाँ होता है जहाँ दिशा बदलना अभी सस्ता है।
हर प्रोजेक्ट में तीन क्रिटिक बिंदु
न्यूनतम शेड्यूल जो समय के साथ बेहतर होने वाला शिप किया गया काम देता है:
| चरण | लक्ष्य | फ्रेमवर्क |
|---|---|---|
| दिशा | क्या हम सही समस्या सुलझा रहे हैं? | मुझे पसंद आया, मेरी इच्छा है, क्या हो अगर |
| मध्यम फिडेलिटी | क्या ढाँचा सही है? | लक्ष्य, तर्क, फीडबैक |
| शिप से पहले | क्या यह शिप के लिए तैयार है? | डिसीज़न स्टैक |
हर चरण के लक्ष्य अलग हैं और अलग फ्रेमवर्क से फ़ायदा होता है। इनमें से किसी को छोड़ने पर अनुमानित तरह की विफलताएँ होती हैं।
दिशा वाला क्रिटिक छोड़ने का मतलब है कि टीम ग़लत समाधान का पॉलिश किया हुआ मॉकअप पूरा कर लेती है। बहुत देर से पता चले तो यह टीम की सबसे महँगी ग़लती है।
मध्यम फिडेलिटी क्रिटिक छोड़ने का मतलब है कि संरचनात्मक समस्याएँ ऊँची फिडेलिटी पर मिलती हैं, जहाँ उन्हें ठीक करना पाँच गुना महँगा पड़ता है। टीम समझौता किया हुआ काम शिप करती है क्योंकि दोबारा शुरू करने का समय नहीं होता।
शिप से पहले का क्रिटिक छोड़ने का मतलब है कि टाली जा सकने वाली समस्याएँ प्रोडक्शन तक पहुँच जाती हैं। शिप डॉक बिना दूसरी नज़र के लिखा जाता है और टीम को टूटी हुई स्थिति का पता यूज़र फीडबैक से चलता है।
AI डिज़ाइन वर्कफ़्लो का विश्लेषण बताता है कि क्रिटिक को AI-तेज़ डिज़ाइन लूप में कैसे जोड़ें। तेज़ जनरेशन क्रिटिक को कम नहीं, ज़्यादा ज़रूरी बनाता है।
फैसिलिटेटर की भूमिका
ज़्यादातर डिज़ाइन क्रिटिक में फैसिलिटेटर होता ही नहीं, और इसीलिए वे बिखर जाते हैं। फैसिलिटेटर कमरे का सीनियर डिज़ाइनर नहीं होता। फैसिलिटेटर वह है जिसकी ज़िम्मेदारी मीटिंग को कामकाजी रखना है।
फैसिलिटेटर क्या करता है
फैसिलिटेटर तीन चीज़ों का मालिक है:
- समय। हर काम को उसका तय स्लॉट मिलता है। समय ख़त्म होने पर सख़्ती से रोक। पार्क किए गए मुद्दे फ़ॉलो-अप सूची में जाते हैं।
- फोकस। रिव्यूअर भटकें तो उन्हें वापस लाना, फीडबैक अस्पष्ट हो तो स्पष्ट करने वाले सवाल पूछना, और यह बताना कि बातचीत दायरे से बाहर चली गई है।
- दर्ज करना। या तो ख़ुद नोट्स लेना या यह पक्का करना कि कोई ले रहा है। नोट्स वैकल्पिक नहीं हैं, वे मीटिंग की उपज हैं।
फैसिलिटेटर क्रिटिक देने के लिए नहीं है। वह क्रिटिक तभी दे सकता है जब मीटिंग का ढाँचा पूरा हो चुका हो। फैसिलिटेशन और क्रिटिक को मिलाने से ध्यान बँट जाता है और दोनों पर लगभग हमेशा बदतर नतीजा आता है।
भूमिका बारी-बारी से बदलें
हर क्रिटिक में एक ही व्यक्ति के फैसिलिटेट करने से वह रुकावट बन जाता है। भूमिका को टीम में साप्ताहिक या पाक्षिक घुमाइए। जूनियर डिज़ाइनरों को फैसिलिटेट करने से बहुत फ़ायदा होता है क्योंकि यह उन्हें सिर्फ़ काम के बारे में नहीं, मीटिंग के बारे में भी संरचनात्मक रूप से सोचने पर मजबूर करता है।
सीनियर डिज़ाइनरों को भी फ़ायदा होता है। क्रिटिक करने की जगह फैसिलिटेट करना सीनियर को हावी होने की जगह सुनने पर मजबूर करता है, जो ऐसा हुनर है जिसे ज़्यादातर सीनियर डिज़ाइनर कम आँकते हैं।
क्रिटिक को कैसे ग्रहण करें
क्रिटिक का दूसरा आधा हिस्सा कुर्सी पर बैठा डिज़ाइनर होना है। ज़्यादातर डिज़ाइन शिक्षा इसे पूरी तरह छोड़ देती है। नतीजा डिज़ाइनरों की ऐसी पीढ़ी है जो काम रिव्यू होने पर रक्षात्मक हो जाती है और वही फीडबैक ठुकरा देती है जो उसे सबसे ज़्यादा मदद करता।
डिज़ाइनर के लिए पाँच नियम
जवाब देने से पहले पूरा सुनें। किसी चुनाव का बचाव करने के लिए बीच में न टोकें। फीडबैक को भीतर लें, लिख लें, फिर स्पष्ट करने वाले सवाल पूछें। बचाव की सहज प्रवृत्ति मीटिंग का मूल्य मार देती है।
अवलोकन को सुझाव से अलग करें। रिव्यूअर कोई ऐसा समाधान सुझा सकता है जिससे आप असहमत हों, पर उसके पीछे का अवलोकन फिर भी सही हो सकता है। अवलोकन लें, सुझाव छोड़ें, अपना समाधान खोजें।
"क्यों" पूछें, "क्या" नहीं। "आपको क्यों लगता है कि CTA कॉन्ट्रास्ट खो देता है?" उपयोगी आगे की बात निकालता है। "क्या आपको लगता है कि CTA कॉन्ट्रास्ट खो देता है?" हाँ या ना देता है जो बातचीत ख़त्म कर देता है।
अपनी प्रतिक्रियाओं को पार्क करें। अगर फीडबैक का कोई हिस्सा गहरा चुभे, तो उसे लिख लें और बाद में जवाब दें। उसी वक़्त का बचाव दोनों तरफ़ बुरे जवाब पैदा करता है। 24 घंटे का ठहराव लगभग हमेशा बेहतर जवाब देता है।
फ़ैसले के मालिक बनें। काम का मालिक डिज़ाइनर है। क्रिटिक के बाद डिज़ाइनर तय करता है कि किस पर अमल करना है। रिव्यूअर विकल्प देते हैं, आदेश नहीं। डिज़ाइनर का काम फीडबैक को प्रोजेक्ट के बारे में अपनी बाक़ी जानकारी के साथ तौलकर फ़ैसला करना है।
2026 की परिस्थितियों में क्रिटिक
तीन बदलावों ने डिज़ाइन क्रिटिक के काम करने का तरीक़ा बदल दिया। सिस्टम को तीनों के अनुसार ढलना होगा।
रिमोट और असिंक्रोनस क्रिटिक अब डिफ़ॉल्ट हैं। एक कमरे में सबकी मीटिंग अब दुर्लभ है। क्रिटिक अब Figma कमेंट्स, Loom रिकॉर्डिंग और साझा दस्तावेज़ों में होता है। फ्रेमवर्क अब भी काम करते हैं, फैसिलिटेशन अब भी मायने रखता है, पर टाइमिंग बदल जाती है। असिंक्रोनस क्रिटिक में साफ़ अनुरोध, साफ़ डेडलाइन और साफ़ फ़ैसले का बिंदु होना चाहिए। इनके बिना वह कमेंट्स का क़ब्रिस्तान बन जाता है।
AI से बने काम को क्रिटिक की ज़्यादा ज़रूरत है, कम नहीं। सेकंडों में विकल्प बनाने वाले टूल क्रिटिक छोड़ने का लालच देते हैं क्योंकि काम "बस AI आउटपुट" है। ठीक तभी क्रिटिक सबसे ज़्यादा मायने रखता है। AI से बना काम डिफ़ॉल्ट रूप से जवाबदेह नहीं होता। इंसानी क्रिटिक उसे जवाबदेह बनाता है।
क्रॉस-फंक्शनल क्रिटिक अब मानक है। इंजीनियर, PM और कंटेंट डिज़ाइनर विज़ुअल डिज़ाइनरों के साथ उसी क्रिटिक में बैठते हैं। फ्रेमवर्क सबके लिए काम करते हैं। शब्दावली को सरल करना होगा। "एफ़ोर्डेंस" और "फोल्ड के ऊपर" ठीक हैं, पर पूरी मीटिंग डिज़ाइनर जार्गन में नहीं हो सकती वरना ग़ैर-डिज़ाइनर मन से बाहर हो जाएँगे।
डिज़ाइन हैंडऑफ़ ग्लॉसरी बताती है कि क्रिटिक व्यापक हैंडऑफ़ अनुशासन से कैसे जुड़ता है। जो क्रिटिक कोई साझा करने योग्य दस्तावेज़ नहीं बनाता, वह हैंडऑफ़ में टिकता नहीं।
अक्सर पूछे जाने वाले सवाल
डिज़ाइन क्रिटिक फ्रेमवर्क क्या है?
फ्रेमवर्क डिज़ाइन रिव्यू मीटिंग चलाने की संरचित स्क्रिप्ट है। यह तय करता है कि कौन कब बोलेगा, किस तरह का फीडबैक माँगा जाएगा, और मीटिंग कैसे ख़त्म होगी। सबसे आम फ्रेमवर्क हैं लक्ष्य-तर्क-फीडबैक, मुझे पसंद आया-मेरी इच्छा है-क्या हो अगर, और डिसीज़न स्टैक। हर एक काम के अलग चरण में फिट बैठता है।
अच्छा डिज़ाइन फीडबैक कैसे दें?
तीन-परत वाला मॉडल इस्तेमाल करें। अवलोकन (आप क्या देखते हैं) से शुरू करें, फिर व्याख्या (इसका क्या मतलब हो सकता है), फिर सुझाव (आप क्या करने पर विचार करेंगे)। कोई भी परत छोड़ेंगे तो फीडबैक कमज़ोर होगा। अवलोकन पूरी तरह छोड़ दें तो फीडबैक नुस्ख़ा बन जाता है, जिसे डिज़ाइनर ठुकरा सकता है।
डिज़ाइन क्रिटिक मीटिंग कितनी लंबी होनी चाहिए?
हर काम के लिए 15 से 30 मिनट, सख़्त समय-सीमा के साथ। एक ही काम पर 60 मिनट का क्रिटिक लगभग हमेशा या तो ज़्यादा दायरे वाला होता है या कमज़ोर फ्रेमवर्क पर चल रहा होता है। हर स्लॉट की सीमा तय करें, नतीजे दर्ज करें और आगे बढ़ें। ज़्यादातर टीमें हर सेशन में 2 से 4 कामों का क्रिटिक करती हैं।
डिज़ाइन टीम को कितनी बार क्रिटिक करना चाहिए?
नियमित रूप से शिप करने वाली छोटी टीम के लिए साप्ताहिक आधार रेखा है। लंबे प्रोजेक्ट चक्र वाली टीम के लिए पाक्षिक चलता है। शेड्यूल से ज़्यादा निरंतरता मायने रखती है। जो टीम एक साल तक साप्ताहिक क्रिटिक करती है, वह उस टीम से तेज़ी से सुधरती है जो जब कोई कहे तब बेतरतीब क्रिटिक करती है।
क्रिटिक को निजी होने से कैसे रोकें?
फ्रेमवर्क लगाइए, नियम लगाइए, और फैसिलिटेटर को बदलते रहिए। फ्रेमवर्क अवलोकन को नुस्ख़े से अलग करते हैं, और ज़्यादातर निजी लगने वाला क्रिटिक वहीं से शुरू होता है। फैसिलिटेटर चूकों को पकड़ता है। समय के साथ टीम ढाँचे को आत्मसात कर लेती है और निजी लगने वाला क्रिटिक बंद हो जाता है क्योंकि भाषा अब उसे सहारा नहीं देती।
सीनियर डिज़ाइनर को क्रिटिक कैसे दें?
वैसे ही जैसे किसी और को देते हैं। तीन-परत मॉडल इस्तेमाल करें, फीडबैक को बताए गए लक्ष्य से जोड़ें, और फ़ैसला सीनियर डिज़ाइनर पर छोड़ें। जो सीनियर डिज़ाइनर क्रिटिक नहीं ले सकते, वे क्रिटिक से बड़ी समस्या हैं। जो टीम चुपचाप सीनियर के काम को रिव्यू करने से बचती है, वह समझौता किया हुआ सीनियर काम शिप करती है।
क्रिटिक एक अनुशासन है, मीटिंग नहीं
जो टीम क्रिटिक अच्छे से चलाती है वह बेहतर काम शिप करती है क्योंकि वह समस्याएँ जल्दी पकड़ती है, हर फ़ैसले पर ज़्यादा नज़रिए पाती है, और डिज़ाइन गुणवत्ता की साझा शब्दावली विकसित करती है। जो टीम क्रिटिक बुरी तरह चलाती है वह या तो असमान काम शिप करती है या पॉलिश किया हुआ पर ग़लत काम, और हैरान होती है कि हर हफ़्ते की मीटिंग मदद क्यों नहीं कर रही।
इलाज संरचनात्मक है। एक फ्रेमवर्क चुनिए। नियम लगाइए। क्रिटिक को अंत में नहीं, हर प्रोजेक्ट में तीन बिंदुओं पर रखिए। नतीजे दर्ज कीजिए। फैसिलिटेटर बदलते रहिए। बिना बचाव के क्रिटिक ग्रहण कीजिए। बिना नुस्ख़े के क्रिटिक दीजिए।
इस अनुशासन को लगाने की क़ीमत दो-तीन मीटिंग की हल्की असहजता है, जब तक टीम ढल जाती है। फल यह है कि टीम हर प्रोजेक्ट में तेज़ होती जाती है और काम का ऐसा ज़खीरा बनता है जो समय के साथ सुधरता है, न कि उसकी तरफ़ लौटता है जिसकी राय सबसे ऊँची है।
अगर आप ऐसी टीम चाहते हैं जो इस अनुशासन को हर प्रोजेक्ट का हिस्सा बनाकर चलाए, तो Brainy को हायर करें। हम आंतरिक डिज़ाइन टीमों के साथ जुड़ते हैं और ब्रांड तथा प्रोडक्ट के काम के साथ क्रिटिक सिस्टम भी स्थापित करते हैं।
संबंधित पठन
Want a design team that critiques without the drama and ships better work because of it? Brainy embeds with internal teams to install critique systems and ship product with the rigor baked in.
Get Started
