ডিজাইন টোকেন ও নিয়ম দিয়ে React অ্যাপে সঙ্গতিপূর্ণ UI

কেন জেনারেট করা React স্ক্রিনগুলো প্রায়শই অসঙ্গত মনে হয়

UI অসঙ্গতি সাধারণত ছোট ছোট বিবরণে দেখা যায় যা ক্লিক করলে অপ্রতিষ্ঠিত মনে হয়। এক পেজে বড় প্যাডিং, অন্যটায় সংকুচিত। হেডিংগুলো সাইজ বদলায়, বাটনের আকার ও রঙ পাল্টায়, এবং একই ইনপুট স্ক্রিন অনুযায়ী ভিন্নভাবে আচরণ করে।

প্রায়শই, এই ড্রিফট কয়েকটি ভিত্তির থেকেই আসে:

• Spacing: padding, gaps, এবং section রিদম ভিন্ন হয়
• Typography: ফন্ট সাইজ, ওজন, ও লাইন-হাইট স্থির থাকে না
• Components: বাটন, কার্ড, বর্ডার, এবং শ্যাডো সামান্যভাবে পরিবর্তিত হয়
• Forms: ভ্যালিডেশন টাইমিং, এরর প্লেসমেন্ট, এবং disabled স্টেট পৃথক হয়

এটি সাধারণ যখন স্ক্রিনগুলো আলাদা প্রম্পট থেকে জেনারেট করা হয়। প্রতিটি প্রম্পট কার্যত একটি নতুন শুরুর মতো, তাই মডেল মিসিং সিদ্ধান্তগুলো অনুমান করে পূরণ করে। এমনকি "মডার্ন স্টাইলিং ব্যবহার করুন" বললেই স্টিলিংয়ের শত শত ছোট চয়েস থামে না: 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 চাই, নতুন সংখ্যা নিয়ে আসার বদলে নিকটতম টোকেনে রাউন্ড করুন।

তারপর টাইপোগ্রাফি ডিফল্টগুলো নির্ধারণ করুন যাতে হেডিং ও বডি টেক্সট ড্রিফট বন্ধ হয়ে যায়। বড় টাইপ সিস্টেমের দরকার নেই; কিন্তু স্পষ্ট, পুনরাবৃত্তধর্মী ধাপ থাকা দরকার।

একটি কমপ্যাক্ট সেট যা ব্যবহারযোগ্য থেকেও অতিরিক্ত ভারী নয়:

• Spacing: 4, 8, 12, 16, 24, 32
• Type: এক বডি সাইজ, দুই হেডিং সাইজ, বডির জন্য এক লাইন হাইট, হেডিং-এর জন্য এক লাইন হাইট
• Colors: text-primary, text-muted, bg, surface, border, accent
• Radius: দুই মান (উদাহরণস্বরূপ 4 ও 12)
• Elevation: none, small, medium (সর্বোচ্চ তিন স্তর)

অ্যাক্সেসিবিলিটিও সিস্টেমে থাকা উচিত। ফোকাস আউটলাইন স্টাইল নির্ধারণ করুন (রঙ, পুরুত্ব, অফসেট) যাতে কীবোর্ড ব্যবহারকারীরা ধারাবাহিক ফোকাস পায়। মোবাইলের জন্য একটি ন্যূনতম ট্যাপ টার্গেট (যেমন 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 সাধারণত র‍্যান্ডম দেখতে শুরু করে:

• Loading: কন্ট্রোল ডিসেবল করুন, একটি স্পিনার দেখান, উইথ স্থির রাখুন
• Disabled: কনট্রাস্ট কমান, কিন্তু হোভার/ফোকাস স্টাইল পুরোপুরি সরিয়ে ফেলবেন না
• Empty states: সংক্ষিপ্ত বার্তা প্লাস একটি পরিষ্কার অ্যাকশন
• Validation: এররগুলো ফিল্ডের নিচে দেখান এবং বড় লেআউট শিফট করবেন না

যখন আপনি “Create project” মত একটি ফর্ম-ভিত্তিক স্ক্রিন জেনারেট করবেন, এই নিয়মগুলো মিশ্র বাটন সাইজ, লেবেল অবস্থান বদলানো, বা এক-অফ “স্পেশাল” কার্ড যা কেবল এক পেজে দেখা যায়—এসব প্রতিরোধ করবে।

ফর্ম আচরণ নিয়ম: সেই খুঁটিনাটি যা সাধারণত ড্রিফট করে

দৃশ্যমান স্থিতিশীলতার পাশাপাশি, অনেক “এটা অদ্ভুত মনে হচ্ছে” অভিযোগ আসে ফর্ম আচরণ থেকেই। যদি প্রতিটি স্ক্রিন লেবেল, এরর, এবং ফোকাস ভিন্নভাবে হ্যান্ডল করে, ব্যবহারকারীরা এটিকে অসঙ্গতি হিসেবে বিবেচনা করবে।

একটি ফর্ম প্যাটার্ন বেছে নিন এবং সব জায়গায় ব্যবহার করুন: লেবেল, optional/required মার্কার, helper text, তারপর error text. লেখাও ধারাবাহিক রাখুন (উদাহরণস্বরূপ, sentence case লেবেল, সংক্ষিপ্ত helper text, এবং এরর মেসেজগুলো ক্রিয়াপদ দিয়ে শুরু)।

সবচেয়ে বেশি ড্রিফট প্রতিরোধকারী নিয়মগুলো:

• লেবেল সবসময় ফিল্ডের উপরে (placeholder নয়), লেবেলে required মার্কার
• Helper text সবসময় ফিল্ডের নিচে, একই সাইজ ও রঙ, কখনও এরর হিসেবে ব্যবহার করবেন না
• ভ্যালিডেশন টাইমিং: blur অথবা submit-এর পরে এরর দেখান, change-এ পরিষ্কার করুন
• এরর প্লেসমেন্ট: ফিল্ডের ঠিক নিচে একটি এরর লাইন, হেল্পার টেক্সটের সাথে অ্যালাইন রাখা
• ফোকাস আচরণ: Tab অর্ডার ভিজ্যুয়াল লেআউট অনুসরণ করবে; Enter কেবল শেষ ফিল্ডে বা যখন primary বাটন ফোকাসড থাকে তখনই সাবমিট করবে

সাইজিং ও লেআউট লক করুন যাতে স্ক্রিনগুলো আলাদা ভাবে “ব্রিদ” না করে। এক ইনপুট উচ্চতা, এক বাটন উচ্চতা, এবং একটি ডিফল্ট ফিল্ড প্রস্থ নির্ধারণ করুন। ডেস্কটপে, ফিল্ডগুলোকে একটি কনসিস্টেন্ট গ্রিডে অ্যালাইন করুন এবং লেবেলগুলো ইনপুটের উপরে স্ট্যাক করুন। মোবাইলে, ফিল্ডগুলো ফুল-উইডথ করুন এবং দুই-কলাম ফর্ম এড়িয়ে চলুন যদি না সত্যিই দরকার হয়।

একটি সাধারণ উদাহরণ: “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 চেক যোগ করুন যা ড্রিফট ছোটতেই ধরবে:

• “Use only the tokens above; no inline styles.”
• “All forms must use FormRow and show errors the same way.”
• “If you must add a component, base it on Card plus existing typography.”

আপনি যদি চ্যাট-ভিত্তিক জেনারেটর ব্যবহার করেন, প্রতিটি অনুরোধে এই স্পেসটি স্থির রাখুন। প্রতিবার পরিবর্তন করলে এর উদ্দেশ্য নষ্ট হয়ে যায়।

এমন একটি ওয়ার্কফ্লো যা স্ক্রিনগুলো ধারাবাহিক রাখে

কিছু জেনারেট করার আগে 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 কেবল শেষ ফিল্ডে সাবমিট করুক” হল স্পষ্ট এবং পুনরাবৃত্তিধর্মী।

একটি লাইটওয়েট গার্ডরেইল ব্লক যদি প্রম্পটে পেস্ট করার দরকার হয়, সংক্ষিপ্ত রাখুন:

• বিদ্যমান স্ক্রিনগুলোর একই স্পেসিং স্কেল ও টাইপোগ্রাফি টোকেন ব্যবহার করুন; নতুন মান তৈরি করবেন না
• শুধুই অনুমোদিত কম্পোনেন্ট ও ভ্যারিয়্যান্ট ব্যবহার করুন
• লোডিং, empty, এবং error স্টেটগুলো একই টোকেন ব্যবহার করে অন্তর্ভুক্ত করুন
• আচরণ (validation, focus order, submit, disabled) ভিজ্যুয়ালগুলোর মতই স্পষ্ট করুন

গ্রহণের আগে দ্রুত ধারাবাহিকতা চেকলিস্ট

জেনারেট করা স্ক্রিন মর্জ করার আগে দুই-মিনিটের স্ক্যান করুন।

স্পেসিং দিয়ে শুরু করুন। 13px বা এক-অফ মার্জিনের মতো র‍্যান্ডম মান দেখুন। যদি আপনি টোকেন ব্যবহার করেন, প্রতিটি গ্যাপ অনুমোদিত সেট থেকে আসা উচিত—গাটার, কার্ড প্যাডিং, এবং ফর্ম ফিল্ডের মধ্যে স্পেসিংসহ।

তারপর টাইপোগ্রাফি টাইপ স্কেলের বিরুদ্ধে পরীক্ষা করুন। হেডিংগুলো ধারাবাহিকভাবে ধাপে নত হওয়া উচিত। অনুরূপ সেকশনে বডি টেক্সট সাইজ বদলানো উচিত নয়। লাইন হাইটও গুরুত্বপূর্ণ, বিশেষ করে settings page-গুলোর মত ঘন পেজে।

এরপর বাটনগুলো স্ক্যান করুন। ভ্যারিয়্যান্ট ও সাইজগুলো আপনার নিয়ম মেনে চলছে কি না: প্রধান অ্যাকশনের জন্য primary, কম গুরুত্বপূর্ণ অ্যাকশনের জন্য secondary, শুধু gerçek delete-র জন্য danger। বাটন উচ্চতা, আইকন অবস্থান, ও লেবেল স্টাইল মিল থাকা উচিত।

ফর্মের জন্য, ধারাবাহিকতা মূলত স্ট্রাকচারের ব্যাপার। লেবেলগুলো এক জায়গায় থাক, required নির্দেশকগুলো এক নিয়ম অনুসরণ করুক, হেল্পার টেক্সট ও এরর একে অপরের সাথে প্রতিদ্বন্দ্বিতা না করুক, এবং এররগুলো ধারাবাহিক স্থানে প্রদর্শিত হোক।

সংক্ষিপ্ত চেকলিস্ট:

• স্পেসিং কেবল টোকেন মান ব্যবহার করছে (কোনো র‍্যান্ডম সংখ্যা নেই)
• টাইপোগ্রাফি টাইপ স্কেলের সাথে মেলে (লাইন হাইটসহ)
• বাটনগুলো একই ভ্যারিয়্যান্ট ও সাইজ অনুসরণ করছে
• ফর্মগুলো লেবেল, হেল্পার, ও এররের জন্য একটি প্যাটার্ন ব্যবহার করছে
• স্টেটগুলো আছে: hover, focus, disabled, loading, empty

শেষে, দ্রুত মোবাইল পরীক্ষা করুন। প্রস্থ সংকুচিত করে দেখুন লেআউট কিভাবে অভিযোজিত হচ্ছে এবং নতুন ফন্ট সাইজ বা স্পেসিং তৈরি হচ্ছে না কি না।

উদাহরণ: স্টাইল ড্রিফট ছাড়া একটি ছোট React ফিচার জেনারেট করা

ধরা যাক একটি সহজ অনবোর্ডিং ফ্লো: তিনটি স্ক্রিন (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 এলেমেন্ট দরকার হয়, মডেলকে ইম্প্রোভাইজ করতে দেবেন না। এক নিয়ম যোগ করুন, তারপর পুনরায় জেনারেট করুন যাতে পুনরায় ব্যবহার বজায় থাকে:

• ProgressStepper: height=32, spacing=md, current step bold, completed steps clickable

পরবর্তী ধাপ: ধারাবাহিকতাকে ডিফল্ট বানান

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

একটি ব্যবহারিক স্পেসিফিকেশন সাধারণত অন্তর্ভুক্ত করে: আপনার টোকেন টেবিল (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 আপনাকে একটি স্থিতিশীল বেসলাইন হারানো ছাড়াই পরীক্ষা করার অনুমতি দেবে।