SaaS প্ল্যাটফর্মের জন্য ডিজাইন সিস্টেম

সমস্যাটা কী ছিল

প্রোডাক্টের screen বাড়ার সঙ্গে একই ধরনের UI-তে তফাত হচ্ছিল। জরুরি প্রোডাক্টের পার্থক্য না ঢেকে দ্রুত কাজ শেষ করতে shared component-এর নিয়ম দরকার ছিল।

যে সীমাগুলো মাথায় ছিল

• আগের screen-এ অসামঞ্জস্যপূর্ণ ইমপ্লিমেন্টেশন
• একাধিক ইঞ্জিনিয়ারের ফিচার যোগ করা
• কাজ না আটকে চেহারায় মিল রাখা
• ঘন screen-এ accessibility আর বিভিন্ন মাপে কাজ করা

যেভাবে এগিয়েছি

• বারবার হচ্ছে আর সামলাতে খরচ বাড়ছে এমন UI pattern খুঁজেছি।
• সাজানোর সুবিধের বদলে প্রোডাক্টের মানে ধরে component-এর সীমানা করেছি।
• card, action, empty state, loading state আর ঘন তথ্যের অংশ ব্যবহারের লিখিত pattern করেছি।

আর্কিটেকচারের সিদ্ধান্ত

• সাজানোর মূল token আর প্রোডাক্টের component-এর আচরণ আলাদা রেখেছি।
• বড় generic component-এর চেয়ে ছোট, মেলানো যায় এমন API পছন্দ করেছি।
• spacing, type আর state-এর নিয়মে মিল রেখে চেহারা আলাদা হয়ে যাওয়া কমিয়েছি।

যেখানে ছাড় দিতে হয়েছে

• সব pattern shared component করিনি। কিছু লিখে রাখা স্থানীয় pattern হিসেবেই ভালো ছিল।
• আলাদা screen-এ নতুনত্বের চেয়ে সামলানো যায় এমন মিলকে গুরুত্ব দিয়েছি।

কী বদল এসেছে

• বারবার একই UI pattern বানানো কমেছে
• আচরণে মিল বেড়েছে
• component-এর দায়িত্ব স্পষ্ট হয়েছে
• পরের ফিচারের কাজ সহজ হয়েছে

যা শিখেছি

• ডেলিভারির চাপেও ইঞ্জিনিয়ার কাজে লাগাতে পারলে তবেই design system-এর দাম আছে।
• সঠিক abstraction অনেক সময় প্রথমে যা চাওয়া হয় তার চেয়ে ছোট।