নো-কোড UI বিল্ডারে ডিজাইন টোকেন দিয়ে সামঞ্জস্যপূর্ণ থিম
নো-কোড UI বিল্ডারে ডিজাইন টোকেন টিমকে একবার রং, টাইপ, স্পেসিং ও ভ্যারিয়েন্ট নির্ধারণ করে অনুমানের বাইরে সামঞ্জস্যপূর্ণ UI প্রকাশ করতে সাহায্য করে।

কেন টিমগুলো UI-তে ভিন্নতা দেখা দেয়
অসামঞ্জস্যপূর্ণ UI সাধারণত “ডিজাইন সমস্যা” হিসেবে শুরু করে না। এটি সময়ের সমস্যা হিসেবে শুরু করে। কাউকে এখনই একটি বাটন দরকার, তাই তারা অন্য পেজ থেকে একটা কপি করে সামান্য পরিবর্তন করে যতক্ষণ না এটা ঠিকমতো দেখায়।
এভাবেই ছোট পার্থক্য ঢুকে পড়ে: প্রায় একরকম দুইটি নীল, কর্নার রেডিয়াস 6 থেকে 8 হয়ে যাওয়া, একটি হেডিং যা “কিছুখানি বোল্ড” মনে হয়, এবং প্যাডিং যা স্ক্রিন বানানো ব্যক্তির উপর নির্ভর করে। নো-কোড বিল্ডারে, ছোট এক-অফ এডিট করা আরও সহজ হয় কারণ কন্ট্রোলগুলো হাতের কাছে থাকে এবং পরিবর্তনগুলো ঝটপট harmless লাগে।
প্রোডাক্ট যত বড় হয়, ড্রিফ তত দ্রুত বৃদ্ধি পায়। বেশি পেজ মানে বেশি পুনরাবৃত্ত প্যাটার্ন। বেশি বিল্ডার মানে বেশি ব্যক্তিগত রুচি। বেশি সহকর্মী মানে আরও বেশি “দ্রুত ফিক্স” আলাদা করে করা। একজন যদি কাস্টমার পোর্টাল বানায় এবং আরেক জন অ্যাডমিন প্যানেল, ফলাফল হল একই ব্র্যান্ডের দুইটি ভিন্ন ব্যাখ্যা।
“চোখে দেখা” প্রতিদিনকার কাজে আসে: রঙ এমনভাবে বেছে নেয়া যতক্ষণ না তা “ঠিক মেলে”, কয়েক পিক্সেল প্যাডিং নড়ানো কারণ স্ক্রিনটা “টাইট” মনে হয়, একটি নতুন বাটন স্টাইল তৈরি করা বদলে একটি বিদ্যমান ব্যবহার করা উচিত ছিল, ডিফল্ট ফন্ট সাইজ “একটু ছোট” মনে হওয়ার কারণে ফন্ট সাইজ মিশিয়ে দেয়া, বা একটি স্ক্রিন ঠিক করা কিন্তু বাকিগুলো যাচাই না করা।
খরচ পরে দেখা দেয়। রিভিউ ধীর হয় কারণ ফিডব্যাক সাবজেকটিভ হয়ে যায় (“আরও অন্য পেজের মতো অনুভূত করান”)। পুনরায় কাজ বাড়ে কারণ পরিবর্তনগুলো সব জায়গায় প্রয়োগ করা কঠিন। ওয়েব ও মোবাইল আলাদা হয় কারণ বিভিন্ন মানুষ প্রায় একই কিন্তু পুরোপুরি মিলছে না এমন সিদ্ধান্ত নেয়।
ডিজাইন টোকেন এগুলোকে প্রতিস্থাপন করে “প্রায় ঠিক” সিদ্ধান্তগুলোর বদলে শেয়ারড মান রাখায়। টিম ও অ্যাপ যতই বড় হোক UI সঙ্গত থাকে।
ডিজাইন টোকেন—সহজ কথায়
ডিজাইন টোকেন হল আপনার UI সম্পর্কে নামকৃত সিদ্ধান্ত। “এই নীল ব্যবহার করুন” বা “বাটনগুলো roomy রাখুন” বলার বদলে আপনি সেসব সিদ্ধান্তকে স্পষ্ট নাম দেন যাতে যেকেউ তা পুনরায় ব্যবহার করতে পারে।
একটি টোকেন কাঁচা মান নয়। কাঁচা মান হতে পারে 16px, #2563EB, বা 600 (ফন্ট ওজন)। টোকেন হল সেই লেবেল যা বলে দেয় ঐ মানটার পণ্যগত মানে কি, যেমন space-4, color-primary, বা font-weight-semibold।
এই পরিবর্তন চোখে দেখা সমাধানটাকে বন্ধ করে দেয়। যখন মানুষ অনুভব করে মান বেছে নেয়, আপনি ধীরে ধীরে পাঁচটি ভিন্ন নীল, তিনটি সামান্য ভিন্ন হেডিং, এবং স্ক্রিন থেকে স্ক্রিনে ভিন্ন স্পেসিং সংগ্রহ করে ফেলেন।
টোকেনগুলো সবচেয়ে ভাল কাজ করে যখন তা একটি একক উৎস হিসেবে থাকে। যদি প্রতিটি স্ক্রিন ও কম্পোনেন্ট একই নামগুলোর দিকে রেফার করে, আপনি শুধু কয়েকটি টোকেন মান আপডেট করে পুরো অ্যাপের লুক বদলে দিতে পারবেন, ডজনগুলো স্ক্রিন ধরে না খোঁজাখুঁজি করে।
টোকেন ডিজাইন ও বিল্ডের মধ্যেও একটি সেতুবন্ধন করে। ডিজাইনার স্পেসিফিকেশনে টোকেন নাম ব্যবহার করে, এবং বিল্ডারও একই নামগুলো একটি নো-কোড UI বিল্ডারে ব্যবহার করে, ফলে হ্যান্ডঅফ টিকে যায়।
অধিকাংশ টোকেন সেট কয়েকটি ক্যাটাগরিতে পড়ে: রং রোল (primary, background, text, danger), টাইপোগ্রাফি (ফন্ট ফ্যামিলি, সাইজ, ওয়েট, লাইনের হাইট), স্পেসিং ধাপ (প্যাডিং, মার্জিন, গ্যাপ), শেপ ও ডেপথ (রেডিয়াস, বর্ডার উইথ, শ্যাডো), এবং মাঝে মাঝে মোশন (দৈর্ঘ্য ও ইজিং)।
যে টোকেন সেটটা বেশিরভাগ প্রোডাক্ট আসলে লাগে
অধিকাংশ টিমকে বিশাল টোকেন লাইব্রেরি দরকার হয় না। তাদের দরকার একটি ছোট, পরিষ্কার সেট যা বেশিরভাগ স্ক্রিন কভার করে যাতে লোকেরা মান অনুমান করা বন্ধ করে। নো-কোড টুলগুলোতে যেখানে “এবারই” টুইকগুলো দ্রুত ছড়ায়, এটা আরও বেশি গুরুত্ব রাখে।
একটি প্রয়োগযোগ্য স্টার্টার সেটে পাঁচটি গ্রুপ কভার করা উচিত:
- রং: কিছু ব্র্যান্ড রোল (primary, secondary), একটি নিউট্রাল সেট (text, background, border), এবং স্ট্যাটাস রোল (success, warning, error). যদি আপনি Hover বা Disabled প্রায়ই ব্যবহার করেন তাহলে সেগুলোও যোগ করুন।
- টাইপোগ্রাফি: একটি ফন্ট ফ্যামিলি (সর্বোচ্চ দুইটি), একটি ছোট সাইজ স্কেল (যেমন 12/14/16/20/24/32), আপনি যেসব ওয়েট ব্যবহার করেন সেগুলো, এবং ম্যাচ করা লাইনের হাইট।
- স্পেসিং: একটি সরল ল্যাডার (যেমন 4/8/12/16/24/32) প্যাডিং ও গ্যাপের জন্য।
- শেপ ও ইফেক্ট: কিছু রেডিয়াস (none/sm/md/lg), বর্ডার উইথ, এবং একটি ছোট শ্যাডো সেট (0-3)।
- মোশন (ঐচ্ছিক): যদি আপনার অ্যাপে অ্যানিমেশন থাকে, তবে কেবল 2-3 দৈর্ঘ্য এবং 1-2 ইজিং নাম।
একটি নিয়ম লাইব্রেরিকে সুষ্ঠু রাখে: যদি কোনো মান তিন বা তার বেশি জায়গায় দেখা যায়, সেটি টোকেন করুন। যদি একবার দেখা যায়, সেটিকে সন্দেহজনক ভাবুন যাতে তা “নতুন নর্ম” না হয়ে উঠে।
টোকেন নামে যে নিয়মগুলো বিশৃঙ্খলা রোধ করে
ভালো টোকেন নাম ঝগড়া হওয়ার আগেই প্রতিহত করে। যদি মানুষ একটি টোকেন অনুমান করে পেতে পারে, তারা তা পুনরায় ব্যবহার করবে। যদি না পারে, তারা একটি নতুন টোকেন তৈরি করবে, এবং আপনার থিম বিভক্ত হয়ে যাবে।
সেম্যান্টিক নামগুলো প্রথমে ব্যবহার করুন (রং নয়)
যে নামটা UI-তে কোন ভূমিকা করে তা বর্ণনা করে এমন নাম ব্যবহার করুন, কি দেখতে লাগে তা না। text-primary সবাইকে বলে কখন এটি ব্যবহার করতে হবে। blue-600 কেবল একটি রং-নাম।
একটি ব্যবহারযোগ্য প্যাটার্ন হচ্ছে দুই স্তর:
- বেস টোকেন: কাঁচা বিল্ডিং ব্লক যেমন
color-blue-600,space-16,font-14 - সেম্যান্টিক টোকেন: UI রোল যেমন
text-primary,bg-surface,border-muted
নো-কোড UI বিল্ডারে, সেম্যান্টিক টোকেনই অ-ডিজাইনারদের দ্রুত সঠিক মান বেছে নিতে সাহায্য করে চোখে দেখে সিদ্ধান্ত না নিতেই।
নতুন টোকেন যোগ করার নিয়ম
অধিকাংশ টোকেন লাইব্রেরি গোলমাল হয় কারণ “নতুন” ডিফল্ট হয়ে যায়। “পুনরায় ব্যবহার” কে ডিফল্ট করুন।
নিয়মগুলো সহজ রাখুন:
- একটি টোকেন যোগ করুন কেবল যদি এটা ২+ জায়গায় ব্যবহৃত হয় বা একটি বাস্তব স্টেট (hover, disabled, error) সমর্থন করে।
- যদি এটা একবারের জন্য হয়, কম্পোনেন্ট-লোকাল রাখুন।
- যদি দুইটি টোকেন সূক্ষ্মভাবে আলাদা হয়, একটি বেছে নিন এবং অন্যটি ডিলিট করুন।
- যদি আপনি টোকেনটির উদ্দেশ্য এক বাক্যে ব্যাখ্যা করতে না পারেন, সেটি যোগ করবেন না।
তারপর নামকরণ মানক করুন। একটি কেসিং স্টাইল বেছে নিন (kebab-case ভাল কাজ করে), স্থির প্রিফিক্স ব্যবহার করুন (text-, bg-, border-, icon-, space-), এবং সংখ্যা স্কেল নিরবচ্ছিন্ন রাখুন (space-4, space-8, space-12, space-16)।
ধাপে ধাপে: আপনি ইতিমধ্যে যা ব্যবহার করেন তা থেকে টোকেন সংজ্ঞায়িত করা
আপনার বর্তমান UI-কে প্রমাণ হিসেবে নিন। কিছুই নতুন তৈরি করার আগে একটি দ্রুত ইনভেন্টরি করুন: স্ক্রিনশট সংগ্রহ করুন, স্টাইল ইনস্পেক্ট করুন, এবং আপনি প্রকৃত প্রোডাকশনে দেখা প্রতিটি রং মান, ফন্ট সাইজ, এবং স্পেসিং মান লিখে রাখুন (এক-অফ মানগুলোও অন্তর্ভুক্ত করুন)।
পরবর্তী ধাপে, সচেতনভাবে ডুপ্লিকেট কমান। সাধারণত আপনি একই ধূসর দেখতে পাবেন পাঁচটি সামান্য ভিন্ন হেক্স মানে, অথবা স্পেসিং 14, 15, এবং 16 এ লাফিয়ে ওঠে। একটি মান নির্বাচন করে রাখুন, তারপর পুরোনো মানগুলোকে তার সাথে মানচিত্র করুন। এখানেই টোকেন ব্যবহারিক হয়ে ওঠে: আপনি স্বাদ নিয়ে তর্ক করা বন্ধ করে একটি ছোট সেটে সম্মত হন।
একটি শক্ত ভিত্তি এক পাসেই তৈরি করা যেতে পারে:
- Palette টোকেন: কাঁচা রং (ব্র্যান্ড, নিউট্রাল, ফিডব্যাক কালার)
- সেম্যান্টিক টোকেন: অর্থভিত্তিক রং (text, background, border, success, warning)
- টাইপোগ্রাফি স্কেল: 6-8 সাইজ স্পষ্ট রোল সহ (body, label, H1-H3)
- স্পেসিং স্কেল: 6-10 ধাপ যা সর্বত্র পুনরায় ব্যবহারযোগ্য
- কম্পোনেন্ট বেসিক: কিছু স্ট্যান্ডার্ড রেডিয়াস ও শ্যাডো
প্রতিটি টোকেনের জন্য একটি বাক্যে গাইডেন্স যোগ করুন: কোথায় ব্যবহার করতে হবে এবং কোথায় নয়। উদাহরণ: “text-muted সহায়ক টেক্সটের জন্য; প্রাইমারি বাটনের জন্য নয়।”
শেষে, মালিকানা নির্ধারণ করুন। একটি ব্যক্তি (অথবা ছোট দল) কে পরিবর্তন মঞ্জুর করার দায়িত্ব দিলে সহায়তা হয়, সাদামাটা নিয়ম: “কোনো নতুন টোকেন যোগ করা যাবে কেবল যদি একটি বিদ্যমান সেটে ফিট না করে।” এতে সিস্টেম স্থিতিশীল থাকে যখন প্রোডাক্ট বাড়ে।
নো-কোড UI বিল্ডারে টোকেন কিভাবে প্রয়োগ করবেন
প্রতি স্ক্রিন একটি ডিফল্ট সেট থেকে শুরু করুন: একটি বেস টেক্সট স্টাইল (ফন্ট, সাইজ, লাইনের হাইট, রং), হেডিং স্টাইল (H1-H3), এবং কিছু লেআউট স্পেসিং নিয়ম যাতে পেজগুলো এলোমেলো না লাগে।
পরবর্তী ধাপে, আপনার টুল যা বলে theme settings—theme variables, global styles, style presets, বা design system settings—এসবের সাথে টোকেন ম্যাপ করুন। লক্ষ্য হলে যে “Primary” বা “Space/16” নির্বাচন করলে একটি টোকেনই নির্বাচন করা হচ্ছে, এক-অফ মান না।
রিইউজেবল স্টাইলগুলোকে এমন প্যাটার্নে ফোকাস করুন যা আপনি প্রতিদিন ব্যবহার করেন। একটি স্টার্টার সেটে থাকতে পারে একটি কার্ড স্টাইল (background, border, radius, padding, shadow), একটি ফর্ম ফিল্ড স্টাইল (লেবেল, ইনপুট, হেল্প টেক্সট), বাটন স্টাইল, এবং টেবিল রো ডেনসিটি ও hover স্টেট।
স্টেটগুলোই যেখানে অসামঞ্জস্য সহজে ঢুকতে পারে—তাই সেগুলো আগে থেকেই নির্ধারণ করুন। প্রতিটি ইন্টারেক্টিভ কম্পোনেন্টের hover, focus, disabled, এবং error এর জন্য টোকেন-চালিত মান থাকা উচিত। Focus সব জায়গায় একই রিং কালার ও পুরুত্ব ব্যবহার করা উচিত। Error একই বর্ডার ও টেক্সট রং জোড়া ব্যবহার করুন।
সবশেষে শেয়ারিং প্ল্যান করুন। যদি আপনার ওয়ার্কস্পেস টেমপ্লেট বা রিইউজেবল মডিউল সাপোর্ট করে, টোকেন ও বেস স্টাইলগুলো একটি “স্টার্টার অ্যাপ”-এ রাখুন যা নতুন প্রকল্পগুলো কপি করবে। এইভাবে নতুন স্ক্রিনগুলো ডিফল্টভাবে সঙ্গত হয়।
এমন কম্পোনেন্ট ভ্যারিয়েন্ট যা স্থিতিশীল থাকে
ভ্যারিয়েন্টগুলোই হল জায়গা যেখানে UI সিস্টেম শান্ত ও পূর্বানুমেয় হয় অথবা একক-অফ টুইকের স্তুপে পরিণত হয়। ভ্যারিয়েন্টগুলো সবচেয়ে ভাল কাজ করে যখন সেগুলো একটি পাতলা স্তর হয় যা রং, টাইপ, ও স্পেসিং-এর জন্য টোকেনের সাথে ম্যাপ করে।
প্রতিদিন যেসব গুরুত্বপূর্ণ কম্পোনেন্ট হয় সেগুলো থেকেই শুরু করুন: বাটন, ইনপুট, ব্যাজ, অ্যালার্ট, এবং কার্ড। প্রতিটির জন্য একই দুটি বেছে নেওয়ার মাত্রা দিন: size এবং intent। Size মেকানিক্যাল হওয়া উচিত (টাইপোগ্রাফি ও স্পেসিং)। Intent হওয়া উচিত অর্থভিত্তিক (সেম্যান্টিক রং)।
অনুমান ছাড়া সাইজ ও উদ্দেশ্য
সাইজ ভ্যারিয়েন্টগুলো তখনই সঙ্গত থাকে যখন সেগুলো কেবল কয়েকটি টোকেন-ভিত্তিক প্রপার্টি বদলায়: ফন্ট সাইজ, প্যাডিং, এবং বর্ডার রেডিয়াস। Intent ভ্যারিয়েন্টগুলো প্রধানত রং রোল বদলাবে (background, text, border) এবং কখনও গোপনভাবে স্পেসিং বদলাবে না।
একটি সেট যা বেশিরভাগ প্রোডাক্ট কভার করে:
- সাইজ: sm, md, lg
- উদ্দেশ্য: primary, secondary, danger
- স্টেট: default, hover, focus, disabled
দলের জন্য ইন্টারঅ্যাকশন নিয়ম
স্টেট নিয়মগুলো প্রতিটি কম্পোনেন্টে প্রযোজ্য করুন, শুধুমাত্র বাটনের জন্য নয়। উদাহরণস্বরূপ: focus সব জায়গায় একটি দৃশ্যমান রিং দেখাবে, hover ধারাবাহিকভাবে কনট্রাস্ট বাড়াবে, এবং disabled একই অপাসিটি ব্যবহার করে ক্লিক ব্লক করবে।
নতুন ভ্যারিয়েন্ট তখনই যোগ করুন যখন তা একটি পুনরাবৃত্ত মান (যেমন “danger”) প্রতিনিধিত্ব করে। যদি এটা একবারের লেআউট প্রয়োজন, তা সাধারণত একটি নতুন কম্পোনেন্ট বা একটি র্যাপার হওয়া উচিত, ভ্যারিয়েন্ট নয়—যা পরে সবাই ভুলভাবে ব্যবহার করতে পারে।
ওয়েব ও মোবাইল থিম কীভাবে সঙ্গত রাখা যায়
যখন একটি প্রোডাক্ট ওয়েব ও মোবাইল উভয়ে শিপ করে, “একই ব্র্যান্ড” সবসময় মানে “একই পিক্সেল” নয়। লক্ষ্য হল স্ক্রিনগুলো একই পরিবারের মতো অনুভব করা, যদিও প্ল্যাটফর্মগুলোর ডিফল্ট ভিন্ন।
শুরু করুন এমন শেয়ারড টোকেন দিয়ে যা ভালো করে চলে: রং রোল (background, surface, text, primary, danger), টাইপোগ্রাফি স্কেল (সাইজ এবং ওয়েট), এবং স্পেসিং টোকেন (4, 8, 12, 16, 24). এগুলো অনুমান দূর করে এবং আপডেটগুলো পূর্বানুমেয় করে।
তারপর বাস্তব ভিন্নতা মেনে নিন। মোবাইলে টাচ টার্গেট বড় হওয়া দরকার এবং সাধারণত একটু বেশি স্পেসিং। ওয়েবে ঘন টেবিল, সাইডবার, ও মাল্টি-কলাম লেআউট লাগতে পারে। ফন্টও আলাদা হতে পারে: আপনি ওয়েেবে ব্র্যান্ড ফন্ট ব্যবহার করতে পারেন কিন্তু iOS/Android-এ পাঠযোগ্যতা ও কর্মক্ষমতার জন্য প্ল্যাটফর্ম ডিফল্ট পছন্দ করতে পারেন।
একটি বাস্তবসম্মত পদ্ধতি হল দুটি স্তর: গ্লোবাল টোকেন যারা মান নির্ধারণ করে, এবং প্ল্যাটফর্ম টোকেন যারা সেই মান কিভাবে রেন্ডার হবে তা নির্ধারণ করে।
- গ্লোবাল:
color.text,color.primary,space.md,radius.sm,type.body - ওয়েব-অনলি:
type.family.web,control.height.web,space.tableRow - মোবাইল-অনলি:
type.family.mobile,control.height.mobile,space.touch
কম্পোনেন্ট নামগুলোকে সঙ্গত রাখুন (Button/Primary) যদিও সাইজগুলো ভিন্ন। রিলিজের আগে উভয় থিমের জন্য কনট্রাস্ট চেক বাধ্যতামূলক করুন।
গভর্ন্যান্স: টোকেন কিভাবে সময়ের সঙ্গে সুস্থ থাকে
টোকেনগুলো কেবল তখনই কাজ করে যখন সেগুলো স্থিতিশীল এবং বোধ্য থাকে। হালকা-ওজনের গভর্ন্যান্স ছাড়া, টিম চুপচাপ “আরেকটা নীল” বা “আরেকটা প্যাডিং” যোগ করে এবং আপনি আবার চোখে দেখা অবস্থায় ফিরে আসেন।
একটি হালকা-ওজনের টোকেন চেঞ্জ ফ্লো
প্রক্রিয়াটি ছোট কিন্তু বাস্তব রাখুন:
- রিকোয়েস্ট: কেউই একটি নতুন টোকেন চাইতে পারে বা পরিবর্তন চাইলেই, স্ক্রিনশট ও কারণ সহ।
- রিভিউ: একজন ডিজাইনার এবং একজন বিল্ডার মূল স্ক্রিনগুলোতেও প্রভাব পরীক্ষা করে।
- অনুমোদন: নামকরণ, অ্যাক্সেসিবিলিটি (কনট্রাস্ট, ট্যাপ সাইজ), এবং এটা সত্যিই নতুন কি না নিশ্চিত করা।
- রিলিজ: হ্যাপ-হ্যাজ না করে নির্দিষ্ট শিডিউলে (সাপ্তাহিক বা স্প্রিন্ট) আপডেট প্রকাশ করা।
- যোগাযোগ: কি পরিবর্তিত হয়েছে এবং এখন থেকে কি ব্যবহার করা উচিত তা শেয়ার করা।
ডিপ্রেকেশনের সাথে একটি সহজ চেঞ্জলগ রক্ষা করুন। যদি পুরোনো টোকেন প্রতিস্থাপন হয়, বলে দিন বিকল্প কী, এটি কিছু সময় ধরে কাজ করবে, এবং স্পষ্টভাবে চিহ্নিত করুন যাতে নতুন স্ক্রিনগুলো এটিকে গ্রহণ না করে।
ক্লিনআপও কাজের অংশ। মাসে একবার অনবহিত টোকেন ও কম্পোনেন্ট ভ্যারিয়েন্ট অপসারণ করুন (অথবা অন্তত পতাকা দিন)।
টোকেন সবাই ব্যবহার যোগ্য করুন
অ-ডিজাইনারদের প্রবল সময় প্রয়োজন উদাহরণ, তত্ত্ব নয়।
করুন: গ্যাপের জন্য স্পেসিং ল্যাডার ব্যবহার করুন, এবং প্রধান অ্যাকশনের জন্য Primary Button ভ্যারিয়েন্ট ব্যবহার করুন।
করবেন না: “13px প্যাডিং কারণ চোখে ঠিক লাগে” সেট করা, বা একটি স্ক্রিন মেলাতে একটি নতুন বাটন স্টাইল তৈরি করা।
টোকেন কাজকে প্রোডাক্ট অগ্রাধিকারগুলোর সাথে বাঁধুন: নতুন ফিচার, রিব্র্যান্ড, এবং অ্যাক্সেসিবিলিটি ফিক্স টোকেন আপডেট চালানো উচিত, ব্যক্তিগত পছন্দ নয়।
সাধারণ ভুল ও ফাঁদ
টোকেনের সুবিধা হারানোর দ্রুত উপায় হল সেগুলোকে একটি ডাম্পিং গ্রাউন্ড ভাবা। ভাল উদ্দেশ্য নিয়ে শুরু করে, তারপর কয়েকটি দ্রুত ফিক্স জমতে থাকে, এবং টিম আবার চোখে দেখে কাজ করা শুরু করে।
একটি সাধারণ ফাঁদ হল খুব আগেই অনেক টোকেন তৈরি করা। যদি প্রতিটি স্ক্রিন তার নিজস্ব রং বা স্পেসিং টোকেন পায়, আপনি সিস্টেম তৈরি করছেন না—আপনি ব্যতিক্রমগুলোর ক্যাটালগ তৈরি করছেন। একটি নতুন টোকেন যোগ করুন শুধুই তখনই যখন আপনি দেখাতে পারেন এটি কমপক্ষে দুই জায়গায় ব্যবহার হবে।
আর একটি চুপচাপ সমস্যা হল কম্পোনেন্টে কাঁচা মান ঢোকে দেয়া। কেউ বাটন প্যাডিং 14px সেট করে “এবারই” বলে, অথবা কার্ডে সরাসরি হেক্স রঙ ব্যবহার করে। সপ্তাহ পরে কেউই মনে রাখে না কেন সেটা আলাদা করা হয়েছিল। অভ্যাস করুন: দেখা যায় এমন এবং পুনরাবৃত্তিযোগ্য হলে এটি একটি টোকেন হওয়া উচিত।
বেস বনাম সেম্যান্টিক টোকেন মিশিয়ে ফেলা থেকেও সমস্যা হয়। বেস টোকেন (যেমন gray-900 বা space-4) কাঁচা মান বর্ণনা করে। সেম্যান্টিক টোকেন (যেমন text-primary বা surface-muted) মানে বর্ণনা করে। সমস্যা শুরু হয় যখন একটি কম্পোনেন্ট বেস টোকেন ব্যবহার করে এবং অন্যটি একই রোলের জন্য সেম্যান্টিক টোকেন—এটি বিরূপ ব্যবহার সৃষ্টি করে।
স্টেটগুলোও একধরনের দেরিতে সমস্যা। টিম প্রায়ই নর্মাল স্টাইলগুলো নির্ধারণ করে, তারপর রিলিজের ঠিক আগে focus, hover, disabled, ও error প্যাচ করে। এভাবেই আপনি অসামঞ্জস্যপূর্ণ ফোকাস রিং এবং তিনটি ভিন্ন “error” লাল তৈরি করেন।
স্কেল করার আগে একটি দ্রুত ফাঁদ-চেক করুন:
- নতুন টোকেন সীমাবদ্ধ রাখুন শেয়ারড প্রয়োজনের জন্য, এক-অফ স্ক্রিনের জন্য নয়
- কম্পোনেন্টে কাঁচা মান প্রয়োগ এড়িয়ে চলুন যতটা সম্ভব
- বেস বনাম সেম্যান্টিক টোকেন আলাদা রাখুন এবং ধারাবাহিকভাবে প্রয়োগ করুন
- স্টেট (focus, error, disabled) আগে থেকেই সংজ্ঞায়িত করুন
- ডার্ক মোড বা ভবিষ্যৎ ব্র্যান্ড রিফ্রেশের জায়গা রাখুন—সেম্যান্টিক টোকেন বদলে কম্পোনেন্ট না লিখে
স্কেল করার আগে দ্রুত চেকলিস্ট
আপনার UI আরও স্ক্রিন, টিম, বা প্রোডাক্টে রোল আউট করার আগে চেক করুন যে আপনার ভিত্তি কপি করে নেওয়ার জন্য পরিস্কার কি না, অনুমান ছাড়া।
- রং রোল সেম্যান্টিক। টোকেনগুলো টেক্সট (ডিফল্ট, muted, inverse), সারফেস (পেজ, কার্ড), বর্ডার (ডিফল্ট, ফোকাস), এবং স্ট্যাটাস (success, warning, danger) কভার করে।
- টাইপ ছোট স্কেলে ম্যাপ করা। H1-H3, body, small—স্পষ্ট সাইজ, ওয়েট, ও লাইনের হাইট সহ একটি সংক্ষিপ্ত টেক্সট স্টাইল সেট।
- স্পেসিং ধাপে বিভক্ত। সাধারণ প্যাডিং ও গ্যাপগুলো একটি ঘন ল্যাডার থেকে আসে (4, 8, 12, 16, 24)। যদি “14” বারবার দেখা যায়, তা ইঙ্গিত যে আপনার ল্যাডার কাজ করা দরকার।
- শীর্ষ কম্পোনেন্টগুলোর ভ্যারিয়েন্ট আছে। সবচেয়ে ব্যবহৃত কম্পোনেন্টগুলোর সাইজ (sm/md/lg) এবং উদ্দেশ্য (primary/secondary/danger) টোকেন রোলের সাথে মেলে।
- মালিকানা স্পষ্ট। একজন ব্যক্তি (অথবা ছোট দল) পরিবর্তন মঞ্জুর করে, হালকা রুটিন: কেন, প্রভাব, এবং কখন রিলিজ।
উদাহরণ: পোর্টাল ও অ্যাডমিন প্যানেলে UI ড্রিফ বন্ধ করা
একটি ছোট টিম একই সময়ে দুইটি অ্যাপ তৈরি করছে: একটি কাস্টমার পোর্টাল এবং একটি ইন্টার্নাল অ্যাডমিন প্যানেল। বিভিন্ন মানুষ বিভিন্ন স্ক্রিন স্পর্শ করে, এবং তারা দ্রুত একটি নো-কোড UI বিল্ডারে কাজ করে। কয়েক সপ্তাহ পরে UI "অফ" বোধ করা শুরু করে, যদিও কেউই কোনও নির্দিষ্ট সমস্যা নাম করতে পারে না।
টোকেনের আগে রিভিউয়ে ঘুরপাক খায়: বাটনগুলো প্রায় একই কিন্তু পুরোপুরি মিলছে না, স্পেসিং স্ক্রিন থেকে স্ক্রিনে বদলায়, ফর্ম ফিল্ড মেলেনা, এবং পোর্টাল আকস্মিকভাবে "ফ্রেন্ডলি" দেখায় আর অ্যাডমিন প্যানেল “কঠোর” মনে হয়।
তারা একটি ছোট, ব্যবহারিক টোকেন সেট পরিচয় করিয়ে সমস্যার সমাধান করে। তারা সেম্যান্টিক রং নির্ধারণ করে (Primary, Success, Danger, TextMuted), একটি স্পেসিং স্কেল (4, 8, 12, 16, 24), এবং বাটন ভ্যারিয়েন্ট (Primary, Secondary, Ghost) একটি রেডিয়াস ও স্থায়ী স্টেটের সাথে।
এখন কনট্রিবিউটররা র্যান্ডম হেক্স মান এবং ফন্ট সাইজ বেছে নেওয়া বন্ধ করে। তারা টোকেন ও ভ্যারিয়েন্ট বেছে নেয়, তাই প্রতিটি নতুন পেজ একই সিদ্ধান্ত উত্তোলন করে।
বিল্ডিং দ্রুত হয় কারণ সিদ্ধান্তগুলো আগেই নেয়া আছে। রিভিউগুলো ছোট ভিজ্যুয়াল নিট থেকে আসল UX সমস্যাগুলোতে সরে আসে। “এই বাটনটি প্রাইমারি ভ্যারিয়েন্ট কর” প্রতিস্থাপন করে “এটাকে একটু বেশি নীল ও সামান্য লম্বা করে দিতে পারেন?”
এরপর একটি ছোট রিব্র্যান্ড আসে: প্রাইমারি রং বদলে যায় এবং ফন্ট স্কেল টাইট হয়। টোকেন থাকায় দল কয়েকটি মান একবারে আপডেট করে, এবং পোর্টাল ও অ্যাডমিন প্যানেল দুটোই একসঙ্গে রিফ্রেশ হয়।
পরের ধাপ: ছোট থেকেই শুরু করুন, তারপর মানক করুন
একটি ফ্লো বেছে নিন যা মানুষ বেশী ব্যবহার করে এবং যেখানে স্পষ্ট ড্রিফ আছে—যেমন অনবোর্ডিং, একটি সেটিংস পেজ, বা একটি সহজ ফর্ম। একটি একক ফ্লো কনভার্ট করা সবচেয়ে দ্রুত আইডিয়াটি প্রমাণ করে এবং চোখে দেখা বন্ধ করে।
একটা ছোট, সেফ টোকেন সেট দিয়ে শুরু করুন: primary/background/text/border/danger, একটি সংক্ষিপ্ত টাইপ স্কেল, একটি স্পেসিং ল্যাডার, এবং 2-3 রেডিয়াস ও শ্যাডো লেভেল। তারপর একটি ছোট কম্পোনেন্ট সেট তৈরি করুন যা কেবল টোকেন ব্যবহার করে: এক বাটন, এক ইনপুট, এক কার্ড, এক অ্যালার্ট। ভ্যারিয়েন্ট যোগ করুন শুধুমাত্র যখন সেগুলো বাস্তবে প্রয়োজন সমাধান করে।
দল দিয়ে একটি সংক্ষিপ্ত রিভিউ চালান দুটি স্ক্রিনশট ব্যবহার করে: একটি “পূর্ব” স্ক্রিন যেখানে অসামঞ্জস্যপূর্ণ প্যাডিং ও ফন্ট আছে, এবং একটি “পরে” স্ক্রিন যা টোকেন ও ভ্যারিয়েন্ট ব্যবহার করে তৈরি। কয়েকটি নিয়মে সম্মত হন (যেমন “হার্ড-কোড কালার নেই” এবং “স্পেসিং অবশ্যই একটি টোকেন হতে হবে”) এবং শীর্ষ অসামঞ্জস্যগুলো ঠিক করুন।
রোলআউটে, নতুন স্ক্রিনগুলো প্রথমে রূপান্তর করুন, তারপর পুরোনোগুলোকে ব্যাকফিল করুন যখন আপনি সেগুলো স্পর্শ করেন। যখন সাপোর্ট একটি নতুন অ্যাডমিন ফিল্টার চায়, সেই প্যানেলটি টোকেন-ভিত্তিক কম্পোনেন্ট ব্যবহার করে পুনর্নির্মাণ করুন এবং কেবল আপনি যে অংশটি স ঠিক করছেন তা প্রতিস্থাপন করুন।
আপনি যদি ব্যাকএন্ড, ওয়েব, এবং মোবাইলসহ সম্পূর্ণ প্রোডাক্ট AppMaster-এ তৈরি করে থাকেন, তাহলে টোকেন এবং রিইউজেবল UI স্টাইলগুলো আগে থেকেই সেট করা সাহায্য করে যাতে নতুন স্ক্রিন একই সিদ্ধান্ত উত্তরাধিকারসূত্রে পায়। এভাবে ভিজ্যুয়াল সামঞ্জস্যতা ও অ্যাপ লজিক একসাথে এগোতে পারে পুনরাবৃত্ত ক্লিনআপ ছাড়াই।
প্রশ্নোত্তর
UI ড্রিফ সাধারণত ছোট “এবারই করব” কেটে-করা সংস্কারের থেকে শুরু হয়: একটি কম্পোনেন্ট কপি করা, প্যাডিং সামান্য পরিবর্তন করা, বা চোখ দিয়ে রঙ বেছে নেওয়া। ধীরে ধীরে এসব ছোট পার্থক্য পেজ জুড়ে জমে যায়, এবং রিভিউগুলো দ্রুত যাচাইয়ের বদলে ব্যক্তিগত মতামতে পরিণত হয়।
ডিজাইন টোকেন হল পুনরায় ব্যবহারযোগ্য নামকৃত UI সিদ্ধান্তগুলো যাতে মানুষ কাঁচা মান অনুমান না করে। মান হতে পারে 16px বা #2563EB, কিন্তু টোকেনের নাম যেমন space-16 বা color-primary উদ্দেশ্যটি বলে দেয়, ফলে সবাই একই পছন্দ বারবার ব্যবহার করে।
শুরু করুন রং রোল, টাইপোগ্রাফি, স্পেসিং, এবং একটি ছোট রেডিয়াস ও শ্যাডো সেট দিয়ে। এগুলো বেশিরভাগ স্ক্রিনকে কভার করে এবং সবচেয়ে সাধারণ eyeballing সমস্যাগুলো থামায়, সাথে টোকেন সেটটি এত ছোট থাকে যে মানুষ সত্যিই ব্যবহার করবে।
একটি ব্যবহারিক ডিফল্ট হলো: যখনই কোনো মান দুইটার বেশি জায়গায় ব্যবহার হয়, অথবা এটি কোনো বাস্তব স্টেট (hover, focus, disabled, error) সমর্থন করে—তখন টোকেন তৈরি করুন। যদি মানটা সত্যিই একবারের জন্য হয়, তা কম্পোনেন্ট-লেভেলে রাখুন।
সেম্যান্টিক নামগুলো (text-primary, bg-surface) কী কাজে লাগবে তা বোঝায়, ফলে মানুষ প্যালেট মনে না রেখে সঠিকটি বেছে নিতে পারে। কাঁচা নাম যেমন blue-600 বেস টোকেন হিসেবে ভালো, কিন্তু কম্পোনেন্টে যথেষ্টভাবে নির্ভর করলে রঙগুলো ভুলভাবে ব্যবহৃত হতে পারে।
আপনি যা চালু করেন তা অডিট করুন: প্রকৃত প্রোডাকশনে ব্যবহৃত রং, ফন্ট সাইজ, এবং স্পেসিং সংগ্রহ করুন, তারপর কাছাকাছি নকলগুলো উদ্দেশ্যপ্রণোদিতভাবে মিশিয়ে দিন। একটি ছোট, পরিষ্কার সেট তৈরি হলে পুরোনো মানগুলোকে নিকটতম টোকেনে ম্যাপ করুন যাতে ভবিষ্যতে টোকেনগুলোই ব্যবহৃত হয়।
প্রথমে গ্লোবাল ডিফল্ট সেট করুন, তারপর আপনার টুল যতই ডাকা হয় theme variables, global styles, বা style presets—সেগুলোতে টোকেন ম্যাপ করুন যাতে কম্পোনেন্টগুলো নাম রেফার করে, হেক্স বা পিক্সেলে না। এরপর দৈনন্দিন ব্যবহারের জন্য একটি ছোট রিইউজেবল স্টাইল সেট তৈরি করুন এবং নিশ্চিত করুন যে hover, focus, disabled, ও error স্টেটগুলোও টোকেন ব্যবহার করছে।
ভ্যারিয়েন্টগুলোকে সহজ ও ভবিষ্যদ্ব্যতী বানাতে সীমাবদ্ধ রাখুন: size এবং intent। Size শুধুমাত্র টোকেন-ভিত্তিক প্রপার্টি (ফন্ট সাইজ, প্যাডিং) বদলাবে; intent মূলত সেম্যান্টিক রং বদলাবে। এতে করে “danger” বাটন ভুলে স্পেসিং বা টাইপোগ্রাফি বদলাবে না।
গ্লোবাল সেম্যান্টিক টোকেন শেয়ার করুন যাতে মান এক থাকে, এবং প্ল্যাটফর্ম-নির্দিষ্ট টোকেনগুলো ভিন্নতা সামলে: টাচ টার্গেট সাইজ, ঘনত্ব ইত্যাদি। লক্ষ্য হল “একই পরিবার, না যে-একই পিক্সেল”—ওয়েব ও মোবাইলকে সঙ্গতিপূর্ণ অনুভূত করানো কিন্তু প্রতিটির সীমাবদ্ধতা সম্মান করা।
পরিষ্কার মালিকানা দিন এবং পরিবর্তনের জন্য একটি ছোট রিভিউ ফ্লো রাখুন যাতে নতুন টোকেনগুলো দ্রুত সমাধান হিসেবে যোগ না হয়। নিয়মিত আপডেট প্রকাশ করুন এবং পুরনো টোকেনগুলোর স্থানে বিকল্প দেখিয়ে ডিপ্রেকেশন নোট রাখুন—এতে সিস্টেম স্থিতিশীল থাকে, বিশেষ করে যখন অনেকজন AppMaster প্রকল্পে দ্রুত কাজ করে।


