फिग्मा कमेंट्स से परे: डिज़ाइन-इंजीनियरिंग हैंडऑफ
फिग्मा कमेंट्स अकेले डिज़ाइन-इंजीनियरिंग हैंडऑफ की खाई को क्यों नहीं पाट सकते – और छोटी टीमों के लिए वास्तव में क्या काम करता है।
By Ellis Keane · 2026-04-06
सबसे अच्छा डिज़ाइन-इंजीनियरिंग हैंडऑफ टूल वह है जिसे इंजीनियर कभी नहीं खोलते
डिज़ाइनर जितना अधिक अपने फिग्मा हैंडऑफ को परफेक्ट करने में निवेश करते हैं – ऑटो-लेआउट, डिज़ाइन टोकन्स, डेव मोड एनोटेशन्स, कम्पोनेंट डॉक्यूमेंटेशन –, वास्तविक डिज़ाइन-इंजीनियरिंग हैंडऑफ उतनी ही बार बदतर होती जाती है। इसलिए नहीं कि डिज़ाइन काम खराब है – यह आमतौर पर शानदार होता है –, बल्कि इसलिए कि वह सारी मेहनत एक ऐसे टूल में रहती है जिसे इंजीनियर अनमने ढंग से खोलते हैं, जल्दी से देखते हैं और फिर बंद करके वह बनाने जाते हैं जो उन्हें लगता है कि उन्होंने देखा।
मैं इस दोनों पक्षों पर रहा हूँ। मैंने एक डिज़ाइनर के रूप में शुरुआत की (खैर, «डिज़ाइनर» – मैं New Hampshire में पॉन शॉप वेबसाइट्स बना रहा था, तो शीर्षक के साथ उदार रहते हैं) और अब Sugarbug के लिए ज़्यादातर इंजीनियरिंग कोड लिखता हूँ। डिज़ाइन-इंजीनियरिंग हैंडऑफ की समस्या एक टूलिंग समस्या नहीं है – यह एक वर्कफ़्लो समस्या है। जानकारी मौजूद है, बस गलत समय पर गलत जगह है।
एक सामान्य डिज़ाइन-इंजीनियरिंग हैंडऑफ कुछ इस तरह दिखती है: एक डिज़ाइनर तीन दिन एक फिग्मा फ्रेम को पॉलिश करने में बिताता है, स्पेसिंग निर्णयों और एज केसेज़ को समझाते हुए बारह कमेंट्स जोड़ता है, इंजीनियर को टैग करता है और फिर इंतज़ार करता है। इंजीनियर फिग्मा खोलता है, लगभग नब्बे सेकंड फ्रेम देखता है, सोचता है «ठीक है, समझ गया», टैब बंद करता है और कुछ ऐसा बनाता है जो 80% सही और 20% गलत होता है – ऐसे तरीकों से जिन्हें सुलझाने में एक और हफ्ते का आना-जाना लगेगा। बारह कमेंट्स? शायद चार पढ़े।
डिज़ाइन-इंजीनियरिंग हैंडऑफ कोई फ़ाइल नहीं है जिसे आप दीवार के ऊपर से फेंकते हैं। यह वह संदर्भ है जिसे वहाँ रहना चाहिए जहाँ इंजीनियर काम करता है – issue में, PR में, कोड में –, न कि किसी डिज़ाइन टूल में जिसे वह एक बार विज़िट करता है।
फिग्मा कमेंट्स हैंडऑफ के लिए गलत आकार के क्यों हैं
मैं हर दिन फिग्मा का उपयोग करता हूँ और इसे वास्तव में पसंद करता हूँ (जो इस बिंदु पर शायद एक व्यक्तित्व दोष है)। लेकिन फिग्मा कमेंट्स डिज़ाइनर-से-डिज़ाइनर सहयोग के लिए अनुकूलित हैं, डिज़ाइन-इंजीनियरिंग हैंडऑफ के लिए नहीं, और यह अंतर ज़्यादातर टीमों की तुलना में अधिक मायने रखता है।
मूलभूत बेमेल यह है: फिग्मा कमेंट्स स्थानिक रूप से फ्रेम्स और कम्पोनेंट्स से जुड़े होते हैं। वे एक डिज़ाइन फ़ाइल के अंदर मौजूद हैं। लेकिन इंजीनियर डिज़ाइन फ़ाइलों के अंदर काम नहीं करते – वे Linear issues, GitHub PRs और अपने IDE में काम करते हैं। जब कोई डिज़ाइनर किसी फ्रेम पर एक कमेंट छोड़ता है जिसमें लिखा है «यह ड्रॉपडाउन 640px से नीचे के मोबाइल व्यूपोर्ट पर collapse होना चाहिए», वह जानकारी अब फिग्मा में फँस जाती है। यह कार्य नहीं बनती। यह इंजीनियर के वर्कफ़्लो में नहीं दिखती। यह एक समानांतर ब्रह्मांड में मौजूद है जिसे इंजीनियर को विज़िट करना याद रखना होगा, और (यहाँ वह हिस्सा है जो वास्तव में मायने रखता है) फिग्मा खोलना इंजीनियर के प्राकृतिक कार्य लूप का हिस्सा नहीं है जैसे कि Linear चेक करना या PRs रिव्यू करना है।
परिणाम अनुमानित है: महत्वपूर्ण डिज़ाइन निर्णय खो जाते हैं, इसलिए नहीं कि कोई लापरवाह है, बल्कि इसलिए कि जानकारी गलत टूल में है। यह किसी के डेस्क पर पोस्ट-इट नोट छोड़ने जैसा है जो घर से काम करता है।
जहाँ डिज़ाइनर संदर्भ छोड़ते हैं
- फिग्मा कमेंट्स – स्थानिक, फ्रेम्स से जुड़े
- फिग्मा डेव मोड एनोटेशन्स – विस्तृत लेकिन फिग्मा खोलना आवश्यक
- Slack थ्रेड्स – संवादात्मक, एक हफ्ते बाद खोजने योग्य नहीं
- डिज़ाइन सिस्टम डॉक्स – व्यापक लेकिन स्प्रिंट के मध्य में शायद ही देखे जाते हैं
जहाँ इंजीनियर वास्तव में देखते हैं
- Linear issue विवरण – शुरू करने से पहले सबसे पहले पढ़ते हैं
- GitHub PR विवरण – कार्यान्वयन के दौरान संदर्भ
- कोड कमेंट्स – रिव्यू के दौरान मिलते हैं
- IDE – जहाँ वे 90% समय बिताते हैं
वास्तव में क्या काम करता है (किसी ऐसे व्यक्ति से जो दोनों करता है)
Sugarbug बनाने के पिछले एक साल में, मैं डिज़ाइनर और (ज़्यादातर) इंजीनियर था, जिसका मतलब है कि मुझे खुद को हैंडऑफ करने और फिर भी संदर्भ खोने का असाधारण अनुभव रहा है। अगर मुझे पिछले मंगलवार के अपने डिज़ाइन निर्णय याद नहीं हैं, तो कोई अलग इंजीनियर फिग्मा कमेंट थ्रेड से सब कुछ नहीं पकड़ पाएगा।
यहाँ वह है जो हमारी टीम की डिज़ाइन-इंजीनियरिंग हैंडऑफ प्रक्रिया के लिए वास्तव में काम किया है, और इसमें से कोई भी बेहतर फिग्मा कमेंट्स लिखने के बारे में नहीं है।
1. डिज़ाइन निर्णय को issue में लिखें, डिज़ाइन फ़ाइल में नहीं
इंजीनियर के बनाना शुरू करने से पहले, डिज़ाइन संदर्भ को Linear issue में रहना होगा (या जो भी आपकी टीम उपयोग करती है)। «डिज़ाइन देखें» के साथ फिग्मा फ़ाइल का लिंक नहीं – यह एक बहाना है, और सब जानते हैं। issue में शामिल होना चाहिए:
- क्या: एक स्क्रीनशॉट या एक्सपोर्ट किया हुआ फ्रेम (फिग्मा लिंक नहीं – एक PNG जिसे इंजीनियर कोई अन्य टूल खोले बिना देख सके)
- क्यों: प्रमुख निर्णयों के पीछे का कारण। «हमने मोडल की बजाय स्लाइड-ओवर पैनल चुना क्योंकि उपयोगकर्ता को संपादन करते समय सूची को संदर्भित करना होगा» – एक वाक्य जो «मोडल क्यों नहीं?» के तीन राउंड बचाता है
- एज केसेज़: मोबाइल पर क्या होता है? लंबे टेक्स्ट के साथ क्या होता है? जब कोई डेटा नहीं है तो क्या होता है? अगर आपने इसके बारे में सोचा है, तो लिख दें। अगर नहीं सोचा है, तो बता दें (ईमानदारी से, «मैंने अभी तक empty state का पता नहीं लगाया है» चुप्पी से अधिक उपयोगी है)
2. डिज़ाइन रिव्यू issue में होते हैं, फिग्मा में नहीं
जब मुझे कार्यान्वयन के दौरान डिज़ाइन फीडबैक मिलता है, तो मैं इसे Linear issue थ्रेड में चाहता हूँ, न कि किसी फिग्मा कमेंट के रूप में जिसे मैं दो दिनों तक नहीं देख सकता। issue मेरे काम का एकमात्र सत्य का स्रोत है – अगर फीडबैक वहाँ रहता है, तो मैं अगली बार issue चेक करने पर इसे देखूँगा, जो दिन में कई बार होता है। अगर यह फिग्मा में है, तो मैं इसे तब देखूँगा जब मैं वह फ़ाइल खोलने का अवसर मिलेगा, जो शायद कभी न हो।
इसका मतलब यह नहीं है कि फिग्मा कमेंट्स का कभी उपयोग न करें। वे डिज़ाइनर-से-डिज़ाइनर सहयोग के लिए, विशिष्ट दृश्य विवरणों को एनोटेट करने के लिए और डिज़ाइन के बारे में बातचीत के लिए बढ़िया हैं। लेकिन जिस क्षण फीडबैक का मतलब «इंजीनियर को कुछ बदलना होगा» हो जाए, उसे इंजीनियरिंग वर्कफ़्लो में जाना होगा।
stat: "अधिकांश" headline: "फिग्मा कमेंट्स 48+ घंटों तक नहीं देखे गए जब हम हैंडऑफ के लिए उन पर निर्भर थे" source: "3 महीने के अनौपचारिक ट्रैकिंग पर हमारी टीम का अनुभव"
3. स्क्रीनशॉट से लूप बंद करें, अनुमानों से नहीं
डिज़ाइन-इंजीनियरिंग हैंडऑफ वैलिडेशन का सबसे सस्ता रूप एक स्क्रीनशॉट है। जब कोई इंजीनियर किसी कम्पोनेंट को implement करना खत्म करता है, तो वे PR या issue में एक स्क्रीनशॉट पेस्ट करते हैं और डिज़ाइनर को टैग करते हैं। «क्या यह मेल खाता है?» में दस सेकंड लगते हैं और 20% विचलन को शिप होने से पहले पकड़ लेता है। कोई मीटिंग नहीं, कोई फिग्मा तुलना अनुष्ठान नहीं – बस एक PNG और एक सवाल।
हमने हर UI PR के लिए यह करना शुरू किया है, और «यह डिज़ाइन से मेल नहीं खाता» बातचीत की संख्या लगभग शून्य हो गई। जो बातचीतें बाकी हैं वे वास्तविक एज केसेज़ हैं जिन्हें डिज़ाइन ने cover नहीं किया – यह ठीक है। यही वह चीज़ है जो discuss होनी चाहिए, न कि बुनियादी «आपने 12px के बजाय 16px padding इस्तेमाल किया»।
4. संदर्भ को टूल्स के बीच स्वचालित रूप से प्रवाहित होने दें
यहीं मैं Sugarbug का उल्लेख करूँगा, क्योंकि हमने इसे सचमुच इस विशिष्ट समस्या को हल करने के लिए बनाया। हमारा डिज़ाइनर फिग्मा में एक स्पेसिंग परिवर्तन के बारे में एक कमेंट छोड़ता है। Sugarbug वह कमेंट उठाता है, उसे संबंधित Linear issue और GitHub PR से जोड़ता है, और इंजीनियर फिग्मा खोले बिना इसे अपने वर्कफ़्लो में देखता है। डिज़ाइन-इंजीनियरिंग हैंडऑफ एक मैन्युअल कॉपी-पेस्ट अनुष्ठान बनना बंद हो जाती है और कुछ ऐसा बन जाती है जो बस होता है।
लेकिन अगर आप Sugarbug का उपयोग नहीं कर रहे हैं (और आप में से ज़्यादातर नहीं हैं – हम अभी भी प्री-लॉन्च हैं), तो मैन्युअल संस्करण है: किसी को «हैंडऑफ ब्रिज» के रूप में नियुक्त करें जो प्रतिदिन फिग्मा कमेंट्स जाँचे और प्रासंगिक फीडबैक को Linear issues में कॉपी करे। यह थकाऊ है, लेकिन काम करता है, और यह इंजीनियरों से उम्मीद करने से अनंत गुना बेहतर है कि वे फिग्मा जाँचना याद रखें।
अगर मुझे पिछले मंगलवार के अपने डिज़ाइन निर्णय याद नहीं हैं, तो कोई अलग इंजीनियर फिग्मा कमेंट थ्रेड से सब कुछ नहीं पकड़ पाएगा। attribution: Chris Calo
आपकी डिज़ाइन-इंजीनियरिंग हैंडऑफ चेकलिस्ट
अगर आप इस लेख से एक चीज़ लेते हैं, तो यह हो: समाधान बेहतर टूल्स नहीं हैं (खैर, मुख्य रूप से नहीं – हालाँकि मैं एक बना रहा हूँ, तो इसे थोड़े नमक के साथ लें)। समाधान यह है कि यह नियम स्थापित किए जाएँ कि डिज़ाइन निर्णय कहाँ रहते हैं, और यह सुनिश्चित करें कि वह «कहाँ» इंजीनियर के प्राकृतिक वर्कफ़्लो के अंदर हो।
- [ ] प्रमुख फ्रेम्स को Linear issue में PNG के रूप में एक्सपोर्ट करें (केवल फिग्मा लिंक नहीं)
- [ ] issue विवरण में प्रत्येक प्रमुख डिज़ाइन निर्णय के लिए «क्यों» लिखें
- [ ] ज्ञात एज केसेज़ सूचीबद्ध करें (मोबाइल, empty states, लंबा टेक्स्ट) – या स्पष्ट रूप से बताएँ कि आपने अभी तक क्या हल नहीं किया है
- [ ] कार्यान्वयन फीडबैक को फिग्मा कमेंट्स से issue थ्रेड में स्थानांतरित करें
- [ ] डिज़ाइन साइन-ऑफ से पहले हर UI PR में एक स्क्रीनशॉट की आवश्यकता करें
- [ ] एक «हैंडऑफ ब्रिज» व्यक्ति नियुक्त करें यदि आपके पास Figma और Linear को स्वचालित रूप से जोड़ने के लिए टूलिंग नहीं है
अक्सर पूछे जाने वाले प्रश्न
Q: फिग्मा कमेंट्स डिज़ाइन-इंजीनियरिंग हैंडऑफ टूल के रूप में क्यों विफल होते हैं? A: फिग्मा कमेंट्स डिज़ाइन फ़ाइल के अंदर रहते हैं, इंजीनियरिंग वर्कफ़्लो से अलग। इंजीनियर Linear, GitHub और अपने IDE में काम करते हैं – फिग्मा में नहीं। किसी फ्रेम पर एक कमेंट तब तक कार्य नहीं बनता जब तक कोई इसे मैन्युअल रूप से कॉपी न करे, और यही वह मैन्युअल कदम है जहाँ डिज़ाइन-इंजीनियरिंग हैंडऑफ टूट जाती है। यह लोगों की समस्या नहीं है, यह टूल-सीमा की समस्या है।
Q: क्या Sugarbug फिग्मा कमेंट्स को Linear issues से स्वचालित रूप से जोड़ता है? A: हाँ – यह उन विशिष्ट समस्याओं में से एक है जिन्हें हल करने के लिए हमने इसे बनाया। Sugarbug फिग्मा कमेंट्स को स्क्रैप करता है और उन्हें संबंधित Linear issues और GitHub PRs से जोड़ता है, ताकि डिज़ाइन फीडबैक इंजीनियर के वर्कफ़्लो में दिखे बिना किसी के टूल्स के बीच कॉपी-पेस्ट किए। हम खुद इसे हर दिन उपयोग करते हैं, और अंतर (ईमानदारी से) विचार की सरलता को देखते हुए थोड़ा शर्मनाक है।
Q: छोटी टीमों के लिए सबसे अच्छी डिज़ाइन-इंजीनियरिंग हैंडऑफ प्रक्रिया क्या है? A: इंजीनियर के बनाना शुरू करने से पहले डिज़ाइन निर्णय को Linear issue में लिखें। केवल visual नहीं, बल्कि reasoning भी शामिल करें। अगर कार्यान्वयन के दौरान एज केसेज़ आते हैं, तो उन्हें issue थ्रेड में चर्चा करें – किसी फिग्मा कमेंट में नहीं जिसे इंजीनियर को ढूँढना पड़े। सबसे सरल प्रक्रिया अक्सर सबसे टिकाऊ होती है।
Q: इंजीनियरिंग शुरू होने के बाद डिज़ाइन परिवर्तनों को कैसे संभालें? A: उन्हें स्कोप परिवर्तनों की तरह मानें: issue में स्पष्ट पहले-और-बाद के साथ परिवर्तन दस्तावेज़ीकृत करें, reasoning स्पष्ट करें और प्रतिबद्ध होने से पहले इंजीनियर को कार्यान्वयन लागत का आकलन करने दें। सबसे बुरे हैंडऑफ विफलताएँ तब होती हैं जब डिज़ाइन परिवर्तन उस काम पर अनौपचारिक फिग्मा कमेंट्स के रूप में आते हैं जो पहले से बन चुका है – इस तरह नाराज़ इंजीनियर और हताश डिज़ाइनर मिलते हैं।
सिग्नल इंटेलिजेंस सीधे अपने इनबॉक्स में पाएँ।