ফিগমা কমেন্টের বাইরে ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ
ফিগমা কমেন্ট একা কেন ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফের ব্যবধান পূরণ করতে পারে না, এবং ছোট টিমের জন্য আসলে কী কাজ করে।
By Ellis Keane · 2026-04-06
সেরা ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ টুল হলো যা ইঞ্জিনিয়াররা কখনো খোলেন না
ডিজাইনাররা তাদের ফিগমা হ্যান্ডঅফ পারফেক্ট করতে যত বেশি বিনিয়োগ করেন – অটো-লেআউট, ডিজাইন টোকেন, ডেভ মোড অ্যানোটেশন, কম্পোনেন্ট ডকুমেন্টেশন – প্রকৃত ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ প্রায়ই তত বেশি খারাপ হয়ে যায়। ডিজাইনের কাজ খারাপ বলে নয় – সেটা সাধারণত অসাধারণ – কিন্তু সেই পরিশ্রম এমন একটি টুলে আটকে থাকে যা ইঞ্জিনিয়াররা অনিচ্ছায় পরিদর্শন করেন, দ্রুত স্কিম করেন, তারপর বন্ধ করেন এবং তারা মনে করেন যা দেখেছেন তা তৈরি করতে চলে যান।
আমি এই উভয় দিকেই ছিলাম। আমি ডিজাইনার হিসেবে শুরু করেছিলাম (আসলে বলতে গেলে "ডিজাইনার" – নিউ হ্যাম্পশায়ারে পন শপের ওয়েবসাইট বানাচ্ছিলাম, তাই শিরোনামটা একটু উদার ধরুন), এবং এখন Sugarbug-এর বেশিরভাগ ইঞ্জিনিয়ারিং কোড আমি লিখি। এবং ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ সমস্যাটা টুলিং সমস্যা নয়, এটা একটা ওয়ার্কফ্লো সমস্যা। তথ্য বিদ্যমান, শুধু ভুল সময়ে ভুল জায়গায়।
সাধারণ ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ এভাবে দেখায়: একজন ডিজাইনার তিন দিন একটি ফিগমা ফ্রেম পালিশ করেন, স্পেসিং সিদ্ধান্ত ও এজ কেস ব্যাখ্যা করে বারোটি কমেন্ট যোগ করেন, ইঞ্জিনিয়ারকে ট্যাগ করেন, তারপর অপেক্ষা করেন। ইঞ্জিনিয়ার ফিগমা খোলেন, প্রায় নব্বই সেকেন্ড ফ্রেমটি দেখেন, ভাবেন "ঠিক আছে, বুঝলাম," ট্যাব বন্ধ করেন, এবং এমন কিছু তৈরি করেন যা ৮০% সঠিক এবং ২০% ভুল – এমনভাবে যা সমাধান করতে আরও এক সপ্তাহের পিছু-পিছু দরকার হবে। বারোটি কমেন্ট? সর্বোচ্চ চারটি পড়া হয়েছে।
ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ কোনো ফাইল নয় যা দেওয়ালের ওপারে ছুঁড়ে মারতে হয়। এটি এমন প্রেক্ষাপট যা ইঞ্জিনিয়ার যেখানে কাজ করেন সেখানে থাকা দরকার – ইস্যুতে, PR-এ, কোডে – কোনো ডিজাইন টুলে নয় যা তারা একবার পরিদর্শন করেন।
কেন ফিগমা কমেন্ট হ্যান্ডঅফের জন্য ভুল আকৃতির
আমি প্রতিদিন ফিগমা ব্যবহার করি এবং সত্যিকারের উপভোগ করি (এই পর্যায়ে এটা সম্ভবত একটি ব্যক্তিত্বের ত্রুটি)। কিন্তু ফিগমা কমেন্ট ডিজাইনার-থেকে-ডিজাইনার সহযোগিতার জন্য অপ্টিমাইজড, ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফের জন্য নয়, এবং পার্থক্যটা বেশিরভাগ টিম যতটা বোঝে তার চেয়ে অনেক বেশি গুরুত্বপূর্ণ।
মূল অসামঞ্জস্য হলো এটি: ফিগমা কমেন্ট ফ্রেম ও কম্পোনেন্টে স্থানিকভাবে নোঙর করা থাকে। এগুলো একটি ডিজাইন ফাইলের ভেতরে বিদ্যমান। কিন্তু ইঞ্জিনিয়াররা ডিজাইন ফাইলের ভেতরে কাজ করেন না – তারা Linear ইস্যু, GitHub PR এবং তাদের IDE-তে কাজ করেন। যখন একজন ডিজাইনার একটি ফ্রেমে কমেন্ট রেখে যান "৬৪০পিএক্সের নিচে মোবাইল ভিউপোর্টে এই ড্রপডাউন ভাঁজ হওয়া উচিত," সেই তথ্য এখন ফিগমায় আটকে আছে। এটি টাস্কে পরিণত হয় না। এটি ইঞ্জিনিয়ারের ওয়ার্কফ্লোতে দেখা যায় না। এটি একটি সমান্তরাল জগতে বিদ্যমান যা ইঞ্জিনিয়ারকে পরিদর্শন করার কথা মনে রাখতে হবে, এবং (এখানে যা সত্যিই গুরুত্বপূর্ণ) ফিগমা পরিদর্শন করা ইঞ্জিনিয়ারের স্বাভাবিক কাজের লুপের অংশ নয় – Linear চেক করা বা PR রিভিউ করার মতো।
ফলাফল অনুমানযোগ্য: গুরুত্বপূর্ণ ডিজাইন সিদ্ধান্ত হারিয়ে যায়, কেউ অসাবধান বলে নয়, বরং তথ্য ভুল টুলে থাকার কারণে। এটি এমন কারো ডেস্কে পোস্ট-ইট রেখে যাওয়ার মতো যিনি বাড়ি থেকে কাজ করেন।
ডিজাইনাররা যেখানে প্রেক্ষাপট রেখে যান
- ফিগমা কমেন্ট – স্থানিক, ফ্রেমে নোঙর করা
- ফিগমা ডেভ মোড অ্যানোটেশন – বিস্তারিত কিন্তু ফিগমা খুলতে হয়
- স্ল্যাক থ্রেড – কথোপকথনমূলক, এক সপ্তাহ পরে অনুসন্ধানযোগ্য নয়
- ডিজাইন সিস্টেম ডকস – ব্যাপক কিন্তু স্প্রিন্টের মাঝে কমই পড়া হয়
ইঞ্জিনিয়াররা আসলে যেখানে দেখেন
- Linear ইস্যু বিবরণ – শুরু করার আগে প্রথম যা পড়েন
- GitHub PR বিবরণ – বাস্তবায়নের সময় রেফারেন্স
- কোড কমেন্ট – রিভিউর সময় আবিষ্কৃত
- IDE – যেখানে তারা ৯০% সময় কাটান
আসলে যা কাজ করে (যিনি উভয়ই করেন তার কাছ থেকে)
Sugarbug তৈরির গত এক বছরে, আমি ডিজাইনার ছিলাম এবং (বেশিরভাগ সময়) ইঞ্জিনিয়ারও, যার মানে আমার নিজেকে হ্যান্ডঅফ করার অদ্ভুত অভিজ্ঞতা হয়েছে এবং তারপরও প্রেক্ষাপট হারিয়ে ফেলেছি। গত মঙ্গলবারের নিজের ডিজাইন সিদ্ধান্ত মনে না থাকলে, একজন আলাদা ইঞ্জিনিয়ার ফিগমা কমেন্ট থ্রেড থেকে সব ধরতে পারবেন এমন কোনো উপায় নেই।
আমাদের টিমের ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ প্রক্রিয়ায় আসলে যা কাজ করেছে তা এখানে দেওয়া হলো, এবং এর কোনোটিই ভালো ফিগমা কমেন্ট লেখার সাথে সম্পর্কিত নয়।
১. ডিজাইন সিদ্ধান্ত ডিজাইন ফাইলে নয়, ইস্যুতে লিখুন
একজন ইঞ্জিনিয়ার বিল্ড শুরু করার আগে, ডিজাইন প্রেক্ষাপট Linear ইস্যুতে (বা আপনার টিম যা ব্যবহার করে) থাকা দরকার। ফিগমা ফাইলের লিংক সহ "ডিজাইন দেখুন" নয় – এটি একটি ফাঁকিবাজি, এবং সবাই জানে। ইস্যুতে অন্তর্ভুক্ত থাকা উচিত:
- কী: একটি স্ক্রিনশট বা রপ্তানি করা ফ্রেম (ফিগমা লিংক নয় – একটি PNG যা ইঞ্জিনিয়ার অন্য টুল না খুলে দেখতে পারেন)
- কেন: মূল সিদ্ধান্তের পেছনের যুক্তি। "আমরা মডালের পরিবর্তে স্লাইড-ওভার প্যানেল বেছে নিয়েছি কারণ এডিট করার সময় ব্যবহারকারীর লিস্ট দেখার প্রয়োজন আছে" – একটি বাক্য যা "কেন মডাল নয়?" এর তিন রাউন্ড বাঁচায়
- এজ কেস: মোবাইলে কী হয়? লম্বা টেক্সটে কী হয়? ডেটা না থাকলে কী হয়? ভেবে থাকলে লিখুন। না ভেবে থাকলে বলুন (সৎভাবে, "আমি এখনো এম্পটি স্টেট ঠিক করিনি" চুপ থাকার চেয়ে বেশি কার্যকর)
২. ডিজাইন রিভিউ ফিগমায় নয়, ইস্যুতে হয়
বাস্তবায়নের সময় ডিজাইন ফিডব্যাক পেলে, আমি চাই সেটি Linear ইস্যু থ্রেডে থাকুক, কোনো ফিগমা কমেন্ট হিসেবে নয় যা আমি দুই দিন নাও দেখতে পারি। ইস্যুটি কাজের জন্য আমার একক সত্যের উৎস – ফিডব্যাক সেখানে থাকলে, পরের বার ইস্যু চেক করার সময় আমি দেখব, যা দিনে কয়েকবার হয়। ফিগমায় থাকলে, আমি দেখব যখন সেই ফাইলটি খুলতে হয়, যা হয়তো কখনোই না।
এর মানে কখনো ফিগমা কমেন্ট ব্যবহার করবেন না, তা নয়। ডিজাইনার-থেকে-ডিজাইনার সহযোগিতার জন্য, নির্দিষ্ট ভিজ্যুয়াল বিবরণ অ্যানোটেট করার জন্য, এবং ডিজাইনের নিজের সম্পর্কে কথোপকথনের জন্য এগুলো দুর্দান্ত। কিন্তু যে মুহূর্তে ফিডব্যাক "ইঞ্জিনিয়ারকে কিছু পরিবর্তন করতে হবে" হয়ে যায়, সেটা ইঞ্জিনিয়ারিং ওয়ার্কফ্লোতে যেতে হবে।
stat: "অধিকাংশ" headline: "হ্যান্ডঅফের জন্য নির্ভর করলে ফিগমা কমেন্ট ৪৮+ ঘণ্টা অদেখা থেকে যেত" source: "৩ মাসের অনানুষ্ঠানিক ট্র্যাকিংয়ে আমাদের টিমের অভিজ্ঞতা"
৩. অনুমানের পরিবর্তে স্ক্রিনশট দিয়ে লুপ বন্ধ করুন
ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ যাচাইয়ের সবচেয়ে সস্তা উপায় হলো একটি স্ক্রিনশট। একজন ইঞ্জিনিয়ার কোনো কম্পোনেন্ট বাস্তবায়ন শেষ করলে, PR বা ইস্যুতে একটি স্ক্রিনশট পেস্ট করেন এবং ডিজাইনারকে ট্যাগ করেন। "এটা কি মিলছে?" দশ সেকেন্ড নেয় এবং শিপ হওয়ার আগে ২০% বিচ্যুতি ধরে। কোনো মিটিং নেই, কোনো ফিগমা তুলনার আচার নেই – শুধু একটি PNG আর একটি প্রশ্ন।
আমরা প্রতিটি UI PR-এর জন্য এটি করতে শুরু করেছি, এবং "এটা ডিজাইনের সাথে মেলে না" কথোপকথনের সংখ্যা প্রায় শূন্যে নেমে এসেছে। যে কথোপকথনগুলো বাকি থাকে সেগুলো হলো প্রকৃত এজ কেস যা ডিজাইন কভার করেনি, যা ঠিক আছে – এই ধরনের বিষয় আলোচনা করা উচিত, "আপনি ১২পিএক্সের পরিবর্তে ১৬পিএক্স প্যাডিং ব্যবহার করেছেন" ধরনের মৌলিক বিষয় নয়।
৪. স্বয়ংক্রিয়ভাবে টুলের মধ্যে প্রেক্ষাপট প্রবাহিত হতে দিন
এখানেই Sugarbug উল্লেখ করব, কারণ আমরা আক্ষরিক অর্থেই এই নির্দিষ্ট সমস্যা সমাধানের জন্য এটি তৈরি করেছি। আমাদের ডিজাইনার স্পেসিং পরিবর্তন সম্পর্কে ফিগমায় একটি কমেন্ট রেখে যান। Sugarbug সেই কমেন্ট তুলে নেয়, প্রাসঙ্গিক Linear ইস্যু এবং GitHub PR-এর সাথে সংযুক্ত করে, এবং ইঞ্জিনিয়ার তাদের ওয়ার্কফ্লোতে এটি দেখেন ফিগমা না খুলে। ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ ম্যানুয়াল কপি-পেস্ট আচার হওয়া বন্ধ হয় এবং এমন কিছুতে পরিণত হয় যা স্বাভাবিকভাবেই ঘটে।
কিন্তু Sugarbug ব্যবহার না করলে (এবং আপনাদের বেশিরভাগই করছেন না, আমরা এখনো প্রি-লঞ্চ), ম্যানুয়াল সংস্করণ হলো: কাউকে "হ্যান্ডঅফ ব্রিজ" হিসেবে নিয়োগ দিন যিনি প্রতিদিন ফিগমা কমেন্ট চেক করেন এবং প্রাসঙ্গিক ফিডব্যাক Linear ইস্যুতে কপি করেন। এটি ক্লান্তিকর, কিন্তু কাজ করে, এবং ইঞ্জিনিয়াররা ফিগমা চেক করার কথা মনে রাখবেন এই আশার চেয়ে অসীম গুণ ভালো।
গত মঙ্গলবারের নিজের ডিজাইন সিদ্ধান্ত মনে না থাকলে, একজন আলাদা ইঞ্জিনিয়ার ফিগমা কমেন্ট থ্রেড থেকে সব ধরতে পারবেন এমন কোনো উপায় নেই। attribution: Chris Calo
আপনার ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ চেকলিস্ট
এই নিবন্ধ থেকে একটি জিনিস নিলে, সেটি হোক এটি: ফিক্স ভালো টুল নয় (প্রাথমিকভাবে তো নয়ই – যদিও আমি একটি তৈরি করছি, তাই একটু সন্দেহ নিয়ে নিন)। ফিক্স হলো ডিজাইন সিদ্ধান্ত কোথায় থাকে সে বিষয়ে নিয়ম প্রতিষ্ঠা করা, এবং নিশ্চিত করা যে সেই "কোথায়" ইঞ্জিনিয়ারের স্বাভাবিক ওয়ার্কফ্লোর ভেতরে।
- [ ] Linear ইস্যুতে মূল ফ্রেম PNG হিসেবে রপ্তানি করুন (শুধু ফিগমা লিংক নয়)
- [ ] ইস্যু বিবরণে প্রতিটি প্রধান ডিজাইন সিদ্ধান্তের "কেন" লিখুন
- [ ] পরিচিত এজ কেস তালিকাভুক্ত করুন (মোবাইল, এম্পটি স্টেট, লম্বা টেক্সট) – বা স্পষ্টভাবে চিহ্নিত করুন কী এখনো সমাধান হয়নি
- [ ] ফিগমা কমেন্ট থেকে বাস্তবায়ন ফিডব্যাক ইস্যু থ্রেডে নিয়ে যান
- [ ] ডিজাইন সাইন-অফের আগে প্রতিটি UI PR-এ স্ক্রিনশট প্রয়োজন করুন
- [ ] ফিগমা এবং Linear স্বয়ংক্রিয়ভাবে সংযুক্ত করার টুলিং না থাকলে একজন "হ্যান্ডঅফ ব্রিজ" ব্যক্তি নিয়োগ দিন
প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী
Q: কেন ফিগমা কমেন্ট ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ টুল হিসেবে ব্যর্থ হয়? A: ফিগমা কমেন্ট ডিজাইন ফাইলের ভেতরে থাকে, ইঞ্জিনিয়ারিং ওয়ার্কফ্লো থেকে বিচ্ছিন্ন। ইঞ্জিনিয়াররা Linear, GitHub এবং তাদের IDE-তে কাজ করেন – ফিগমায় নয়। ফ্রেমের একটি কমেন্ট টাস্কে পরিণত হয় না যতক্ষণ না কেউ ম্যানুয়ালি সেটি কপি করেন, এবং সেই ম্যানুয়াল পদক্ষেপেই ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ ভেঙে পড়ে। এটি মানুষের সমস্যা নয়, এটি টুল-বাউন্ডারি সমস্যা।
Q: Sugarbug কি ফিগমা কমেন্টকে Linear ইস্যুর সাথে স্বয়ংক্রিয়ভাবে সংযুক্ত করে? A: হ্যাঁ – এটি সেই নির্দিষ্ট সমস্যাগুলির একটি যার সমাধানের জন্য আমরা এটি তৈরি করেছি। Sugarbug ফিগমা কমেন্ট স্ক্র্যাপ করে এবং সেগুলো প্রাসঙ্গিক Linear ইস্যু ও GitHub PR-এর সাথে সংযুক্ত করে, ফলে ডিজাইন ফিডব্যাক ইঞ্জিনিয়ারের ওয়ার্কফ্লোতে দেখা যায় কারো কোনো কপি-পেস্ট ছাড়াই। আমরা নিজেরা প্রতিদিন এটি ব্যবহার করি, এবং পার্থক্যটা (সৎভাবে) একটু বিব্রতকর কারণ ধারণাটা কত সহজ।
Q: ছোট টিমের জন্য সেরা ডিজাইন-ইঞ্জিনিয়ারিং হ্যান্ডঅফ প্রক্রিয়া কী? A: ইঞ্জিনিয়ার বিল্ড শুরু করার আগেই ডিজাইন সিদ্ধান্ত Linear ইস্যুতে লিখুন। শুধু ভিজ্যুয়াল নয়, যুক্তিও অন্তর্ভুক্ত করুন। বাস্তবায়নের সময় এজ কেস উঠলে, ফিগমা কমেন্টে নয়, ইস্যু থ্রেডে আলোচনা করুন যা ইঞ্জিনিয়ারকে খুঁজে বের করতে হবে। সবচেয়ে সহজ প্রক্রিয়াই প্রায়ই সবচেয়ে টেকসই।
Q: ইঞ্জিনিয়ারিং শুরু হওয়ার পরে ডিজাইন পরিবর্তন কীভাবে সামলাবেন? A: স্কোপ পরিবর্তনের মতো ট্রিট করুন: স্পষ্ট আগে/পরে সহ ইস্যুতে পরিবর্তন ডকুমেন্ট করুন, কারণ ব্যাখ্যা করুন, এবং কমিট করার আগে ইঞ্জিনিয়ারকে বাস্তবায়নের খরচ মূল্যায়ন করতে দিন। সবচেয়ে খারাপ হ্যান্ডঅফ ব্যর্থতা তখন হয় যখন ডিজাইন পরিবর্তন আসে ক্যাজুয়াল ফিগমা কমেন্ট হিসেবে এমন কাজের উপর যা ইতিমধ্যে তৈরি হয়ে গেছে – এভাবেই বিরক্ত ইঞ্জিনিয়ার এবং হতাশ ডিজাইনার তৈরি হয়।
সিগন্যাল ইন্টেলিজেন্স আপনার ইনবক্সে পৌঁছে দিন।