পার্ট ৩: Documentation & Style Guides for Devs: ডেভেলপার হ্যান্ডঅফ ও ডকুমেন্টেশন প্রসেস

ডিজাইনার হিসেবে আমাদের মনে রাখা উচিত, আমাদের কাজের শেষ আউটপুট কোনো ফিগমা ফাইল নয়। আমাদের শেষ আউটপুট হলো লাইভ প্রোডাক্ট (Live Product), যা আসল ইউজারেরা ব্যবহার করছে। অনেক সুন্দর ডিজাইন করার পরও লাইভ করার সময় দেখা যায় ডিজাইনের সাথে রিয়েল কোডের অমিল। মার্জিন মিলছে না, ফন্টের ওয়েট ভুল হয়েছে, কিংবা হোভার ট্রানজিশন স্মুথ নয়।

এই সমস্যার বড় কারণ হলো ডিজাইনার ও ডেভেলপারের মধ্যকার কনভার্সন গ্যাপ এবং ত্রুটিপূর্ণ ডেভেলপার হ্যান্ডঅফ (Developer Handoff)। একটি ভালো ডিজাইন লাইব্রেরি যদি সঠিকভাবে ডকুমেন্ট না করা হয় এবং ডেভেলপাররা যদি ডিজাইন ভ্যালু সহজে খুঁজে না পায়, তবে সম্পূর্ণ ডিজাইন সিস্টেম ব্যর্থ হতে বাধ্য।

আজকে আমরা কথা বলব কীভাবে ক্লিয়ার মেজারমেন্ট রেডলাইন, ফিগমার দেব মোড (Dev Mode) এবং স্টোরিবুক (Storybook) অ্যালাইনমেন্টের মাধ্যমে আপনার ডিজাইন টিম ও ইঞ্জিনিয়ারিং টিমের মধ্যে পারফেক্ট সিঙ্ক তৈরি করবেন।

১. লুপ হোল: ফিগমা দেখে অনুমানের ওপর কোডিং

পূর্বে ডিজাইনাররা ফাইল বানিয়ে স্রেফ লিংকটি ডেভেলপারদের পাঠিয়ে দিত এবং ভাবত তাদের দায়িত্ব শেষ। ডেভেলপাররা তাদের নিজস্ব চোখে মার্জিন-প্যাডিং অনুমান করে কোড করত। যেমন: ডেভেলপার হয়তো ভাবল কার্ডের স্পেসিং ২০ পিক্সেল হবে, অথচ ডিজাইনার ফাইলে ওটি ২৪ পিক্সেল রেখেছিল।

যখন বড় প্রজেক্টে এ ধরনের শত শত অসঙ্গতি একসাথে জমা হয়, তখন লাইভ প্রোডাক্টের ইউজার ইন্টারফেস ভাঙা ও অপেশাদার মনে হয়।

স্কেলেবল প্রোডাক্টে ডিজাইনার ও ডেভেলপারের মধ্যে জল্পনাকল্পনার কোনো সুযোগ নেই। প্রতিটি মেজারমেন্ট ও অ্যাকশন সুনির্দিষ্টভাবে ডকুমেন্ট করা থাকতে হবে। একে বলে ডিজাইন ডিফিনিশন (Design Definition)।

২. মেজারমেন্ট রেডলাইনিং ও অ্যানোটেশন (Redline Specs)

ডিজাইন সিস্টেমে প্রধান কম্পোনেন্টগুলো যেমন: বাটন, ইনপুট ফিল্ড এবং ন্যাপবার যখন পাবলিশ করবেন, তখন পাশে অবশ্যই একটি Specs বা Specs Details আর্টবোর্ড রাখুন। সেখানে যা যা থাকা উচিত:

• আউটার অ্যান্ড ইনার ডাইমেনশনস (Padding & Width):

অ্যারো বা দাগ টেনে পরিষ্কার করে দেখিয়ে দিন টপ-বটম প্যাডিং কত এবং লেফট-রাইট প্যাডিং কত। সব মেজারমেন্ট আমাদের স্পেসিং ভেরিয়েবল অনুযায়ী হতে হবে (যেমন: padding: spacing-16).

• ইন্টারঅ্যাকশন অ্যানোটেশনস (States):

ডিজাইন সিস্টেমে কম্পোনেন্টের সকল স্টেট পাশাপাশি সাজিয়ে রাখুন: Default, Hover, Focused, Disabled, Active এবং Error State। প্রতিটি স্টেটের ট্রানজিশন টাইম কত মিলিসেকেন্ড হবে (যেমন: transition: background-color 200ms ease-out) তাও লিখে দিতে হবে।

৩. ফিগমা দেব মোড ও টোকেন এক্সপোর্ট (Figma Dev Mode & API)

ফিগমার মডার্ন দেব মোড (Dev Mode) ডেভেলপারদের কাজকে অত্যন্ত সহজ করে দিয়েছে।

• ডেভ অ্যানোটেশন (Dev Annotations):

ডিজাইনার হিসেবে আপনি দেব মোডে ঢুকে সরাসরি গুরুত্বপূর্ণ সেকশনে রেডলাইনিং ও রুলার এড করে রাখতে পারেন, যাতে ইঞ্জিনিয়াররা ফাইল ওপেন করলেই প্রয়োজনীয় মাপযোগ এক ক্লিকে দেখতে পায়।

• টোকেন কোড এক্সপোর্ট (Variable Exporting):

ফিগমা ভেরিয়েবলস খুব সহজেই প্লাগইন (যেমন: Variables2CSS বা Tokens Studio) দিয়ে সরাসরি JSON ফরম্যাটে এক্সপোর্ট করা যায়। এই JSON ফাইলটি ডেভেলপাররা তাদের কোডবেসে রিড করতে পারে। এর ফলে ফিগমাতে আপনি কোনো কালার চেঞ্জ করলে তা সরাসরি ডেভেলপারের লোকাল CSS ভেরিয়েবলস বা Tailwind কনফিগ ফাইলে অটো-আপডেট হয়ে যায়।

৪. স্টোরিবুক অ্যালাইনমেন্ট (Storybook & Design System QA)

লার্জ স্কেল ডেভেলপমেন্টে ফ্রন্টএন্ড ইঞ্জিনিয়াররা তাদের কম্পোনেন্টগুলো আইসোলেশনে ডেভেলপ ও টেস্ট করার জন্য স্টোরিবুক (Storybook) ব্যবহার করে।

• নামকরণে মিল (Naming Consistency):

ফিগমার কম্পোনেন্ট ও প্রোপার্টির নাম কোডবেসের নামের সাথে একদম হুবহু মিলতে হবে। যেমন: ফিগমাতে যদি কোনো প্রোপার্টির নাম হয় size = large, কোডবেসেও যেন প্রোপার্টিটির নাম size: "large" হয়। কখনই ফিগমাতে size আর কোডে type লিখে কনফিউশন তৈরি করা যাবে না।

• ডিজাইন QA (Quality Assurance):

ডেভেলপার যখন কোনো কম্পোনেন্ট স্টোরিবুকে রেডি করবে, তখন ডিজাইনার লোকাল ফিজিক্যাল ডেক্সটপ বা ব্রাউজারে সেটি চেক করে ফিগমার সাথে মেলাবে। একে বলে ডিজাইন কিউএ প্রসেস।

পরবর্তী পর্বে আমরা দেখব কীভাবে সময়ের সাথে সাথে আপনার ডিজাইন সিস্টেমটি মেইনটেইন করবেন এবং টিমের অন্যান্য ডিজাইনারদের থেকে অবদানের জন্য রুলস তৈরি করবেন।

ধন্যবাদ সবাইকে।