১১ ডিসে, ২০২৫·6 মিনিট
ডিজাইন টোকেন ও নিয়ম দিয়ে React অ্যাপে সঙ্গতিপূর্ণ UI
ডিজাইন টোকেন ও কম্পোনেন্ট/ফর্ম নিয়ম ব্যবহার করে React অ্যাপে ধারাবাহিক UI কিভাবে পেতে হয়—স্পেসিং, টাইপোগ্রাফি এবং ফর্ম আচরণ মিলিয়ে AI-জেনারেটেড স্ক্রিনগুলো একরকম রাখুন।
ডিজাইন টোকেন ও কম্পোনেন্ট/ফর্ম নিয়ম ব্যবহার করে React অ্যাপে ধারাবাহিক UI কিভাবে পেতে হয়—স্পেসিং, টাইপোগ্রাফি এবং ফর্ম আচরণ মিলিয়ে AI-জেনারেটেড স্ক্রিনগুলো একরকম রাখুন।
UI অসঙ্গতি সাধারণত ছোট ছোট বিবরণে দেখা যায় যা ক্লিক করলে অপ্রতিষ্ঠিত মনে হয়। এক পেজে বড় প্যাডিং, অন্যটায় সংকুচিত। হেডিংগুলো সাইজ বদলায়, বাটনের আকার ও রঙ পাল্টায়, এবং একই ইনপুট স্ক্রিন অনুযায়ী ভিন্নভাবে আচরণ করে।
প্রায়শই, এই ড্রিফট কয়েকটি ভিত্তির থেকেই আসে:
এটি সাধারণ যখন স্ক্রিনগুলো আলাদা প্রম্পট থেকে জেনারেট করা হয়। প্রতিটি প্রম্পট কার্যত একটি নতুন শুরুর মতো, তাই মডেল মিসিং সিদ্ধান্তগুলো অনুমান করে পূরণ করে। এমনকি "মডার্ন স্টাইলিং ব্যবহার করুন" বললেই স্টিলিংয়ের শত শত ছোট চয়েস থামে না: 8px বনাম 12px গ্যাপ, 14px বনাম 16px বডি টেক্সট, কখন এরর দেখাবেন, কীভাবে primary বাটন দেখতে হবে—এসব।
আপনি দুটি বা তিনটি পেজ ম্যানুয়ালি ক্লিন করতে পারবেন, কিন্তু সেটা স্কেল করে না। আপনি এক-অফ CSS টুইকের পিছনে ছুটে চলবেন, ফাইলগুলোর মধ্যে স্টাইল কপি করবেন, এবং ফর্মগুলো আবার ঠিক করবেন। নিয়মগুলো আপনার মাথায় আছে, প্রজেক্টে নয়।
আজ একটি লগইন স্ক্রিন জেনারেট করলে এবং আগামীকাল একটি প্রোফাইল স্ক্রিন করলে ভেবে দেখুন। যদি একে শুধু সাবমিটে এরর দেখায় আর অন্যটি blur-এ দেখায়, ব্যবহারকারীরা তা লক্ষ্য করবে। যদি primary বাটনের উচ্চতা স্ক্রিনগুলোতে বদলে যায়, অ্যাপটি টুকরো টুকরো মনে হবে।
যখন প্রতিটি স্ক্রিন একই শেয়ার করা সিস্টেম অনুসরণ করে — ডিজাইন টোকেন (spacing, type, color) প্লাস একটি ছোট কম্পোনেন্ট ও ফর্ম নিয়ম সেট — তখন ধারাবাহিকতা স্বাভাবিক হয়ে ওঠে।
ডিজাইন টোকেন হল সহজ নামকৃত মান যা আপনি UI জুড়ে পুনরায় ব্যবহার করেন। প্রতিটি স্ক্রিনে বারবার "কমফোর্টেবল প্যাডিং" চাইতে না বলে, আপনি space-4 মতো একটি টোকেন ব্যবহার করবেন। "একটু রাউন্ডেড" বলতে না বলে আপনি radius-md ব্যবহার করবেন। নামটি স্থির থাকে, এমনকি পরে আপনি এটি যে মানে ম্যাপ করবেন তা বদলে দিলেও।
টোকেনগুলো হল সেই সিদ্ধান্তগুলোর সেট যা আপনি চান প্রতিটি স্ক্রিন শেয়ার করুক। এগুলো স্বাদ ও অনুমানকেই অপসারণ করে, এবং ঠিক তাই—যেটাই ড্রিফট জন্মায় যখন আপনি নতুন পেজ জেনারেট বা বিল্ড করেন।
স্বাভাবিক টোকেনগুলো স্পেসিং, টাইপোগ্রাফি, রঙ, শেপ, এবং কিছু ইভেল্যুশন ঢেকে রাখে। বাস্তব জয় হল: একটি হেডার সবসময় একই সাইজ ব্যবহার করে, একটি কার্ড সবসময় একই প্যাডিং ব্যবহার করে, এবং একটি primary বাটন একই রঙ ও রেডিয়াস রাখে।
পণ্য জুড়ে সামগ্রিক অনুভূতিতে প্রভাব ফেলে এমন জিনিসগুলো টোকেনাইজ করুন: স্পেসিং স্কেল, ফন্ট সাইজ ও লাইন হাইট, কোর রঙ (টেক্সট, ব্যাকগ্রাউন্ড, প্রাইমারি, ডেঞ্জার, বর্ডার), এবং কয়েকটি বর্ডার রেডিয়াস।
কন্টেন্ট-চালিত পছন্দগুলো নমনীয় রাখুন, যেমন কপির দৈর্ঘ্য, কোন আইকন ব্যবহার হবে, বা একটি সেকশনে দুই বা তিনটি কার্ড দরকার কিনা।
যখন আপনি স্ক্রিন জেনারেট করেন (Koder.ai ব্যবহার করলেও), আগে একটি ছোট টোকেন সেট দিলে অনুমানের পরিমাণ কমে যায় এবং আউটপুটটি লক্ষণীয়ভাবে বেশি ধারাবাহিক হয়।
একটি টোকেন সেট হলো অনুমোদিত মানগুলোর ছোট মেনু। ছোট হওয়াই ভাল কারণ এটা র্যান্ডম পছন্দের জায়গা কম রাখে, তবে তা এখনও সেই বেসিকগুলো ঢাকতে হবে যা স্ক্রিনগুলোকে খারাপ দেখায়।
স্পেসিং থেকে শুরু করুন। একটি স্কেল বেছে নিন এবং সব জায়গায় padding, gaps, ও লেআউটের জন্য এটি ব্যবহার করুন। 4, 8, 12, 16, 24, 32 মত একটি সেট বেশিরভাগ UI কভার করে। যদি ডিজাইনে 10px বা 18px চাই, নতুন সংখ্যা নিয়ে আসার বদলে নিকটতম টোকেনে রাউন্ড করুন।
তারপর টাইপোগ্রাফি ডিফল্টগুলো নির্ধারণ করুন যাতে হেডিং ও বডি টেক্সট ড্রিফট বন্ধ হয়ে যায়। বড় টাইপ সিস্টেমের দরকার নেই; কিন্তু স্পষ্ট, পুনরাবৃত্তধর্মী ধাপ থাকা দরকার।
একটি কমপ্যাক্ট সেট যা ব্যবহারযোগ্য থেকেও অতিরিক্ত ভারী নয়:
অ্যাক্সেসিবিলিটিও সিস্টেমে থাকা উচিত। ফোকাস আউটলাইন স্টাইল নির্ধারণ করুন (রঙ, পুরুত্ব, অফসেট) যাতে কীবোর্ড ব্যবহারকারীরা ধারাবাহিক ফোকাস পায়। মোবাইলের জন্য একটি ন্যূনতম ট্যাপ টার্গেট (যেমন 44x44) নির্ধারণ করুন। কনট্রাস্ট প্রেডিক্টেবল রাখার জন্য টেক্সট রঙকে একটি ছোট, নির্ভরযোগ্য সেটে সীমাবদ্ধ করুন।
যদি বাটনগুলো কখনও সংকুচিত মনে হয়, তার কারণ সাধারণত এক স্ক্রিনে প্যাডিং 10 ব্যবহার করা এবং অন্যটিতে 12 ব্যবহার করা। টোকেন থাকলে আপনি বলতে পারবেন: “Buttons use paddingY=8, paddingX=16, radius=12, focus outline token, min height 44.” একবার এই মানগুলো স্থির হলে, জেনারেটর আর অনুমান করা বন্ধ করে।
টোকেনগুলো সংখ্যাগুলো নির্ধারণ করে। কম্পোনেন্ট নিয়মগুলো অভ্যাসগুলো স্থির করে।
কোহর একটি ছোট সেট কোর কম্পোনেন্ট বেছে নিন এবং সেগুলোকে স্ক্রিন তৈরির একমাত্র বিল্ডিং ব্লক হিসেবে বিবেচ্য করুন। সেগুলোকে বিরক্তিকরভাবে সাধারণ ও পুনরায় ব্যবহারযোগ্য রাখুন: Button, Input, Select, Checkbox, Card। আপনি TextArea এবং Modal যোগ করতে পারেন, কিন্তু সেগুলো একই সিস্টেম (লেবেল, স্পেসিং, স্টেট) অনুসরণ করা উচিত।
পরবর্তী, ভ্যারিয়েন্ট সীমিত করুন এবং কখন এগুলো ব্যবহার করা যাবে তা নির্ধারণ করুন। উদাহরণস্বরূপ: Button-এর primary, secondary, এবং danger আছে। Primary হলো স্ক্রিনের মূল অ্যাকশন (সাধারণত একটাই)। Secondary হলো cancel বা কম-প্রাধান্যের অ্যাকশন। Danger শুধুমাত্র destructive অ্যাকশনের জন্য যেমন delete। যদি ভ্যারিয়েন্টটি যুক্তি দিয়ে বোঝানো না যায়, ডিফল্টে secondary ব্যবহার করুন।
স্পেসিং নিয়মগুলো সূক্ষ্ম ড্রিফটকে প্রতিহত করে। কম্পোনেন্টগুলোর ভিতরে ডিফল্ট নির্ধারণ করুন: Button padding, Input উচ্চতা, label-to-field gap, stacked fields-এর মধ্যে স্ট্যান্ডার্ড গ্যাপ। কিছু লেইআউট নিয়মও যোগ করুন: Cards-এর fixed internal padding এবং consistent header/body spacing; Modals একই width step এবং footer alignment ব্যবহার করবে।
অবশেষে, স্টেটগুলো অ-আলোচ্য রাখুন কারণ এখান থেকেই UI সাধারণত র্যান্ডম দেখতে শুরু করে:
যখন আপনি “Create project” মত একটি ফর্ম-ভিত্তিক স্ক্রিন জেনারেট করবেন, এই নিয়মগুলো মিশ্র বাটন সাইজ, লেবেল অবস্থান বদলানো, বা এক-অফ “স্পেশাল” কার্ড যা কেবল এক পেজে দেখা যায়—এসব প্রতিরোধ করবে।
দৃশ্যমান স্থিতিশীলতার পাশাপাশি, অনেক “এটা অদ্ভুত মনে হচ্ছে” অভিযোগ আসে ফর্ম আচরণ থেকেই। যদি প্রতিটি স্ক্রিন লেবেল, এরর, এবং ফোকাস ভিন্নভাবে হ্যান্ডল করে, ব্যবহারকারীরা এটিকে অসঙ্গতি হিসেবে বিবেচনা করবে।
একটি ফর্ম প্যাটার্ন বেছে নিন এবং সব জায়গায় ব্যবহার করুন: লেবেল, optional/required মার্কার, helper text, তারপর error text. লেখাও ধারাবাহিক রাখুন (উদাহরণস্বরূপ, sentence case লেবেল, সংক্ষিপ্ত helper text, এবং এরর মেসেজগুলো ক্রিয়াপদ দিয়ে শুরু)।
সবচেয়ে বেশি ড্রিফট প্রতিরোধকারী নিয়মগুলো:
সাইজিং ও লেআউট লক করুন যাতে স্ক্রিনগুলো আলাদা ভাবে “ব্রিদ” না করে। এক ইনপুট উচ্চতা, এক বাটন উচ্চতা, এবং একটি ডিফল্ট ফিল্ড প্রস্থ নির্ধারণ করুন। ডেস্কটপে, ফিল্ডগুলোকে একটি কনসিস্টেন্ট গ্রিডে অ্যালাইন করুন এবং লেবেলগুলো ইনপুটের উপরে স্ট্যাক করুন। মোবাইলে, ফিল্ডগুলো ফুল-উইডথ করুন এবং দুই-কলাম ফর্ম এড়িয়ে চলুন যদি না সত্যিই দরকার হয়।
একটি সাধারণ উদাহরণ: “Create project” স্ক্রিনে Name, Region, এবং Description থাকতে পারে। Region যদি একটি select হয়, তবুও এটিকে অন্য কোনো ফিল্ডের মতো ট্রীট করুন: একই উচ্চতা, একই লেবেল অবস্থান, একই এরর লাইন। যদি ব্যবহারকারী Name ফাঁকা রেখে সাবমিট করে, ফোকাস Name-এ যাবে, এরর তার নিচে প্রদর্শিত হবে, এবং লেআউট স্থির থাকবে।
আপনি যদি Koder.ai-এ স্ক্রিন জেনারেট করেন, এই ফর্ম নিয়মগুলো একবার আপনার প্রম্পটে রেখে প্রত্যেক ফিচারে পুনরায় ব্যবহার করুন যাতে প্রতিটি নতুন ফর্ম একইভাবে আচরণ করে এবং বারবার ক্লিনআপের দরকার না পরে।
আপনার প্রম্পটকে একটি ছোট UI চুক্তি হিসেবে বিবেচনা করুন। এটিকে সংক্ষিপ্ত, নির্দিষ্ট, এবং পুনরায় ব্যবহারযোগ্য রাখুন যাতে প্রতিটি নতুন স্ক্রিন একই স্পেসিং, টাইপোগ্রাফি, কম্পোনেন্ট, এবং আচরণে স্ন্যাপ করে।
একটি ব্যবহারিক প্যাটার্ন হলো অনুরোধের শীর্ষে একটি সংক্ষিপ্ত UI স্পেস পেস্ট করা, তারপর স্ক্রিনটি সাধারণ ভাষায় বর্ণনা করা।
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
স্পেসের পরে, কিছু acceptance চেক যোগ করুন যা ড্রিফট ছোটতেই ধরবে:
আপনি যদি চ্যাট-ভিত্তিক জেনারেটর ব্যবহার করেন, প্রতিটি অনুরোধে এই স্পেসটি স্থির রাখুন। প্রতিবার পরিবর্তন করলে এর উদ্দেশ্য নষ্ট হয়ে যায়।
কিছু জেনারেট করার আগে UI চুক্তি লিখুন: একটি ছোট টোকেন সেট (spacing, type, colors, radius, shadows) প্লাস একটি সংক্ষিপ্ত কম্পোনেন্ট ইনভেন্টরি (Button, Input, Select, Card, Modal, Table, Toast). যদি কোনো টোকেন বা কম্পোনেন্ট অনুপস্থিত থাকে, মডেল একটি নতুন কিছু উদ্ভাবন করবে এবং আপনার UI ড্রিফট করবে।
তারপর একটি রেফারেন্স স্ক্রিন তৈরি করুন যা নিয়মগুলো পরীক্ষা করে। একটি ফর্ম-ভিত্তিক পেজ ভালো স্ট্রেস টেস্ট কারণ এতে হেডার, হেল্পার টেক্সট, ভ্যালিডেশন এরর, প্রাইমারি ও সেকেন্ডারি বাটন, এবং একটি সফল টোস্ট আছে। সেই স্ক্রিনকে বেসলাইন হিসাবে বিবেচনা করুন।
ওই থেকে, আপনার যা সংজ্ঞায়িত করেছেন তা গঠন করে নতুন স্ক্রিন তৈরি করুন। “Fresh styling” চান না; একই Card, একই spacing স্কেল, একই টাইপোগ্রাফি ধাপ, এবং একই ফিল্ড প্যাটার্ন চাইুন।
একটি সহজ ওয়ার্কফ্লো:
যদি “Search users” স্ক্রিনটি রেফারেন্সের তুলনায় টাইটারের স্পেসিং নিয়ে আসে, ম্যানুয়ালি মার্জ না করে স্পেসিং টোকেন বা Card প্যাডিং রুল আপডেট করুন এবং পুনরায় জেনারেট করুন।
আপনি যদি Koder.ai ব্যবহার করেন, snapshots এবং rollback এখানে সাহায্য করতে পারে: একটি বেসলাইন লক করুন, নিরাপদে পরীক্ষা-নিরীক্ষা করুন, এবং যদি কোনো পরিবর্তন ড্রিফট আনতে শুরু করে দ্রুত পূর্বাবস্থায় ফিরিয়ে আনুন।
কোনো প্রজেক্টে ধারাবাহিকতা হারানোর দ্রুততম উপায় হলো টোকেন ও নিয়মগুলোকে কেবল প্রস্তাবনা মনে করা। ছোট ব্যতিক্রমগুলো নতুন স্ক্রিনে গুণানুগভাবে বৃদ্ধি পায়।
একটি সাধারণ ফাঁদ হলো স্পেসিং স্কেল মাঝপথে বদলে ফেলা। প্রাথমিক স্ক্রিনগুলো 8, 16, 24 ব্যবহার করছিল; একটি নতুন স্ক্রিন 10 ও 18 যোগ করে “ভালো লাগছে” বলে। এখন ড্রিফট অনুমোদিত হয়ে গেল, এবং পুরনো স্ক্রিনগুলো কখনো হালনাগাদ হয় না।
আরেকটি ড্রিফট উত্স হলো জেনারেটরকে নতুন কম্পোনেন্ট স্টাইল আবিষ্কার করতে দেয়া। যদি আপনি না বলুন “শুধু এই বাটন ভ্যারিয়েন্টগুলোই আছে,” মডেল একক স্ক্রিনে নতুন রেডিয়াস বা ভিন্ন ইনপুট প্যাডিং তৈরি করতে পারে।
স্টেটস আরেকটি সাধারণ অনুপযুক্ত এলাকা। Loading, empty, এবং error স্টেটগুলো প্রায়শই স্পেসিং ও আচরণ পাল্টায়। যদি এগুলো পরে যোগ করা হয়, সাধারণত আপনি ব্যস্ত প্যাটার্ন পাবেন যা বাকি অংশের সাথে মেলেনা।
আরো লক্ষ্য রাখুন ভুল ধরণের স্পেসিফিসিটি-এর ওপর: “এরকে আধুনিক নরম শ্যাডো দিয়ে করো” অস্পষ্ট, কিন্তু আচরণগত নিয়মগুলো যেমন “এরর ফিল্ডের নিচে দেখান”, “disabled বাটনেও ফোকাস স্টাইল রাখো”, এবং “Enter কেবল শেষ ফিল্ডে সাবমিট করুক” হল স্পষ্ট এবং পুনরাবৃত্তিধর্মী।
একটি লাইটওয়েট গার্ডরেইল ব্লক যদি প্রম্পটে পেস্ট করার দরকার হয়, সংক্ষিপ্ত রাখুন:
জেনারেট করা স্ক্রিন মর্জ করার আগে দুই-মিনিটের স্ক্যান করুন।
স্পেসিং দিয়ে শুরু করুন। 13px বা এক-অফ মার্জিনের মতো র্যান্ডম মান দেখুন। যদি আপনি টোকেন ব্যবহার করেন, প্রতিটি গ্যাপ অনুমোদিত সেট থেকে আসা উচিত—গাটার, কার্ড প্যাডিং, এবং ফর্ম ফিল্ডের মধ্যে স্পেসিংসহ।
তারপর টাইপোগ্রাফি টাইপ স্কেলের বিরুদ্ধে পরীক্ষা করুন। হেডিংগুলো ধারাবাহিকভাবে ধাপে নত হওয়া উচিত। অনুরূপ সেকশনে বডি টেক্সট সাইজ বদলানো উচিত নয়। লাইন হাইটও গুরুত্বপূর্ণ, বিশেষ করে settings page-গুলোর মত ঘন পেজে।
এরপর বাটনগুলো স্ক্যান করুন। ভ্যারিয়্যান্ট ও সাইজগুলো আপনার নিয়ম মেনে চলছে কি না: প্রধান অ্যাকশনের জন্য primary, কম গুরুত্বপূর্ণ অ্যাকশনের জন্য secondary, শুধু gerçek delete-র জন্য danger। বাটন উচ্চতা, আইকন অবস্থান, ও লেবেল স্টাইল মিল থাকা উচিত।
ফর্মের জন্য, ধারাবাহিকতা মূলত স্ট্রাকচারের ব্যাপার। লেবেলগুলো এক জায়গায় থাক, required নির্দেশকগুলো এক নিয়ম অনুসরণ করুক, হেল্পার টেক্সট ও এরর একে অপরের সাথে প্রতিদ্বন্দ্বিতা না করুক, এবং এররগুলো ধারাবাহিক স্থানে প্রদর্শিত হোক।
সংক্ষিপ্ত চেকলিস্ট:
শেষে, দ্রুত মোবাইল পরীক্ষা করুন। প্রস্থ সংকুচিত করে দেখুন লেআউট কিভাবে অভিযোজিত হচ্ছে এবং নতুন ফন্ট সাইজ বা স্পেসিং তৈরি হচ্ছে না কি না।
ধরা যাক একটি সহজ অনবোর্ডিং ফ্লো: তিনটি স্ক্রিন (Profile, Preferences, Confirm), পরে একটি Settings পেজ। আপনি চান প্রতিটি স্ক্রিন যেন একই ডিজাইনারের তৈরি—এমনকি আলাদা রানেও জেনারেট হলে।
কিছু জেনারেট করার আগে একটি ছোট টোকেন সেট এবং কিছু কম্পোনেন্ট নিয়ম দিন:
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
এখন আলাদাভাবে “Profile” এবং “Preferences” জেনারেট করুন। কারণ উভয়েই Page, Card, Field, এবং Button row ব্যবহারের অনুরূপ শর্তে থাকতে হবে, সেগুলো একই মার্জিন, লেবেল স্পেসিং, এবং বাটন প্লেসমেন্ট নিয়ে আসবে। Confirm ধাপটিও ঠিক বসবে, যদিও এতে বেশি read-only টেক্সট আছে।
ফর্ম আচরণই হচ্ছে যেখানে ড্রিফট সচরাচর ঢুকতে থাকে, তাই এটিকে একবার সংজ্ঞায়িত করে পুনরায় ব্যবহার করুন: বৈধ না হওয়া পর্যন্ত সাবমিট অসক্রিয়, inline এররগুলো কেবল blur বা submit-এর পরে, Enter কেবল শেষ স্টেপে সাবমিট করে, এবং Back বাটন ইতিমধ্যেই প্রবেশ করা মানগুলো ক্লিয়ার করে না।
যখন একটি নতুন UI এলেমেন্ট দরকার হয়, মডেলকে ইম্প্রোভাইজ করতে দেবেন না। এক নিয়ম যোগ করুন, তারপর পুনরায় জেনারেট করুন যাতে পুনরায় ব্যবহার বজায় থাকে:
টোকেন ও নিয়মগুলোকে একটি পুনরায় ব্যবহারযোগ্য স্পেসিফিকেশনে রূপান্তর করুন এবং সত্যিই ব্যবহার করুন। যদি এটা পেস্ট করার জন্য অনেক বড় হয়, তবে কেউ এটাকে অনুসরণ করবে না।
একটি ব্যবহারিক স্পেসিফিকেশন সাধারণত অন্তর্ভুক্ত করে: আপনার টোকেন টেবিল (spacing, type, radii, colors), একটি সংক্ষিপ্ত কম্পোনেন্ট রুল সেট (buttons, inputs, cards, headings), ফর্ম আচরণ নিয়ম (ভ্যালিডেশন টাইমিং, এরর, disabled/loading), লেআউট ডিফল্ট (page padding, max width, section spacing), এবং একটি ছোট “কখনও করবেন না” তালিকা (র্যান্ডম মার্জিন, এক-অফ ফন্ট সাইজ)।
তারপর একটি অভ্যাস গড়ে তুলুন: individual pixels পরিবর্তন না করে প্রথমে স্পেসিফিকেশন আপডেট করুন।
আপনি যদি Koder.ai (koder.ai) ব্যবহার করেন, planning mode-এ স্পেসিফিকেশনটি পুনরায় বলার ভালো জায়গা—তাতে জেনারেশনের আগে নিশ্চিতকরণ হয়। বিকল্পগুলো পরীক্ষা করতে চাইলে snapshots ও rollback আপনাকে একটি স্থিতিশীল বেসলাইন হারানো ছাড়াই পরীক্ষা করার অনুমতি দেবে।
প্রতিটি স্ক্রিন অনুরোধ একটি নতুন শুরু হিসেবে পৌঁছে। যদি আপনি একটি শেয়ার করা সিস্টেম না দেন, জেনারেটর অনুপস্থিত বিস্তারিতগুলো অনুমান করে ভর্তি করে—স্পেসিং, ফন্ট সাইজ, বাটন প্যাডিং, শ্যাডো এবং ফর্ম আচরণ—ফলে ছোট ভিন্নতাগুলো পাতাগুলো জুড়ে জমা হতে থাকে।
ডিজাইন টোকেন হল নামকৃত, পুনরায় ব্যবহারযোগ্য মান যেমন স্পেসিং, টাইপ সাইজ, রঙ এবং রেডিয়াস।
"আরম্ভে আরামদায়ক প্যাডিং" বলার বদলে আপনি space-md মতো একক টোকেন ব্যবহার করেন। নামটি স্থির থাকে এবং প্রতিটি স্ক্রিন একই সিদ্ধান্তগুলো পুনরায় ব্যবহার করে, ফলে UI ড্রিফট বন্ধ হয়ে যায়।
ছোট শুরু করুন এবং শুধু সেইগুলো ঢাকুন যেগুলো দৃশ্যগতভাবে ড্রিফট সৃষ্টি করে:
প্রতিটি অনুরোধের শীর্ষে একটি সংক্ষিপ্ত UI স্পেস ব্লক রাখুন এবং এটিকে একটি চুক্তি হিসেবে ব্যবহার করুন:
তারপর স্ক্রিনটি নিচে বর্ণনা করুন। মূল কথা: স্পেসিফিকেশনটি প্রতিটি স্ক্রিনে অপরিবর্তিত রাখুন।
টোকেন সংখ্যাগুলো সংখ্যাগত সিদ্ধান্ত দেয়; কম্পোনেন্ট নিয়মগুলো অভ্যাস ঠিক করে। উপকারী নিয়মগুলো:
ডিফল্ট নীতি: যদি কোনো ভ্যারিয়্যান্ট যুক্তিসংগত না হয়, স্ট্যান্ডার্ডে ফিরে যান।
একটি প্যাটার্ন বেছে নিন এবং সর্বত্র ব্যবহার করুন:
এই নিয়মগুলো সাবধানভাবে ফলো করলে “একটি স্ক্রিন blur-এ যাচাই করে, অন্যটি কেবল submit-এ” ধরণের বিচ্যুতি হবে না।
কিছু অপরিবর্তনীয় স্টেট নির্ধারণ করুন:
যদি স্টেট নির্দিষ্ট না করেন, প্রতিটি স্ক্রিন সাধারণত নিজস্ব প্যাটার্ন আবিষ্কার করে।
নতুন কম্পোনেন্টকে অনুমোদন করার আগে সেটির স্টাইলিং মডেল করবেন না:
যদি আপনি টোকেন দিয়ে বর্ণনা করতে না পারেন, তা সাধারণত অত্যধিক কাস্টম এবং ড্রিফট ঘটাবে।
একটি “রেফারেন্স” স্ক্রিন তৈরি করুন যা সিস্টেমটিকে টেস্ট করে (ফর্ম-ভিত্তিক পেজ ভাল), তারপর প্রতিটি নতুন স্ক্রিনে একই স্পেস ব্যবহার করুন।
Koder.ai-এর planning mode-এ স্পেসিফিকেশনটি পুনরায় বলুন এবং নিশ্চিত করুন; snapshots এবং rollback-ও আপনাকে স্টেবল বেসলাইন রাখতেও সহায় করে।
মার্জ করার আগে দ্রুত স্ক্যান করুন:
কিছু ভুল থাকলে স্পেসিফিকেশন/টোকেন আপডেট করে পুনরায় জেনারেট করুন—এক-অফ মার্জিন প্যাচ করবেন না।
নতুন মান দরকার হলে, 10px বা 18px invent না করে নিকটতম টোকেনে রাউন্ড করুন।