শুধু স্টাইল গ্যালারি নয়—নির্ণয়গুলো সংজ্ঞায়িত করুন
একটি ডিজাইন সিস্টেম কেবল স্ক্রিনশট নয়। এটি সেই সিদ্ধান্তগুলো রেকর্ড করে যা বারবার আসে: সেকশনের মধ্যে স্পেসিং, প্রাইমারি অ্যাকশনের ট্রিটমেন্ট, একটি ফর্ম ত্রুটির আচরণ, এবং সাফল্য বা ব্যর্থতার পর ব্যবহৃত ভাষা। USWDS ডিজাইন টোকেনকে টাইপোগ্রাফি, স্পেসিং, রঙ, লাইন হাইট এবং অপ্যাসিটির মতো মানগুলোর জন্য পৃথক প্যালেট হিসেবে বর্ণনা করে। নিয়ম, উদ্দেশ্য, অনুমোদিত ভ্যারিয়েন্ট এবং মালিককে ডকুমেন্ট করুন। ভিত্তি থেকে শুরু করুন এবং গুরুত্বপূর্ণ যাত্রায় ব্যবহৃত পাঁচ থেকে আটটি কম্পোনেন্টকে অগ্রাধিকার দিন; সব পেজ একসঙ্গে স্ট্যান্ডার্ডাইজ করার চেষ্টা সাধারণত স্পষ্টতার বদলে গোলমাল তৈরি করে।
আপনার সাইটে বাস্তবে ব্যবহৃত অনুমোদিত রঙের রোল, টাইপ, স্পেসিং, বর্ডার, রেডিয়াস, ব্রেকপয়েন্ট এবং মোশন পছন্দগুলো রেকর্ড করুন।
একটি পুনরাবৃত্ত টাস্ক বিন্যাসের জন্য একটি প্যাটার্ন ব্যবহার করুন—যেমন অ্যাকাউন্ট তৈরি বা সার্চ রেজাল্ট—একটি একক ভিজ্যুয়াল সাজসজ্জার জন্য নয়।
পুনরাবৃত্ত মান নিয়ন্ত্রণ করতে টোকেন ব্যবহার করুন
একটি ডিজাইন টোকেন হলো একটি মানব-পাঠযোগ্য নাম যা একটি মানের সঙ্গে সম্পর্কিত। Design Tokens Community Group টোকেনগুলোকে একটি প্ল্যাটফর্ম-অ্যাগনস্টিক উপায় হিসেবে বর্ণনা করে ডিজাইন সিদ্ধান্ত প্রকাশ করার জন্য; ন্যূনতমভাবে একটি টোকেন হলো একটি নাম এবং একটি মান। কাঁচা মান টেমপ্লেটে ছড়িয়ে দেওয়ার বদলে color-action-primary বা space-section এর মতো উদ্দেশ্যভিত্তিক নাম ব্যবহার করুন। উদ্দেশ্য টোকেন থেকে বেস মানে একটি ডকুমেন্টেড ম্যাপিং রাখুন। টোকেনগুলো সমন্বিত পরিবর্তন সহজ করে, কিন্তু এগুলো কনট্রাস্ট, ব্র্যান্ডিং, বা ভাল হায়ারার্কি নিশ্চিত করে না। প্রতিটি রেন্ডার করা কম্বিনেশন এবং পেজ স্টেট যাচাই করুন।
প্রতিটি ব্যতিক্রমের জন্য নয়—পুনরাবৃত্ত সিদ্ধান্তগুলোর জন্য টোকেন তৈরি করুন; না হলে টোকেন তালিকাই অসঙ্গতি সংরক্ষণ করবে।
একটি ব্যাপকভাবে ব্যবহৃত টোকেনের জন্য প্রভাবিত পেজগুলোর তালিকা দিন, প্রতিনিধিত্বমূলক স্ক্রিনগুলো পরীক্ষা করুন, এবং প্রয়োজনে মাইগ্রেশন বা রোলব্যাক নির্দেশিকা দিন।
আচরণ ও সীমা সহ কম্পোনেন্ট তৈরি করুন
একটি কম্পোনেন্ট হলো কেবল ভিজ্যুয়াল আকৃতির চেয়ে বেশি—এটি আচরণসহ একটি পুনঃব্যবহারযোগ্য ইন্টারফেস অংশ। সেমান্টিক স্ট্রাকচার, আবশ্যক এবং ঐচ্ছিক ইনপুট, ভ্যারিয়েন্ট, রেসপন্সিভ আচরণ, এবং সমস্ত প্রাসঙ্গিক স্টেট: লোডিং, ডিসেবলড, এরর, খালি এবং সফল—এইগুলো ডকুমেন্ট করুন। কীবোর্ড আচরণ এবং কন্টেন্ট নির্দেশিকা অন্তর্ভুক্ত করুন। সব লেআউটকে কম্পোনেন্ট করার জন্য বাধ্য করবেন না। GOV.UK কম্পোনেন্টগুলোকে কার্যকারিতা, ইউনিকনেস, ব্যবহারযোগ্যতা, সঙ্গতিপূর্ণতা, এবং বহুমুখীতার ভিত্তিতে মূল্যায়ন করে; এটি নির্ধারণে একটি কার্যকর শৃঙ্খলা যে কোনটা ভাগ করে রক্ষণাবেক্ষণ করার যোগ্য। একটি ব্যাপকভাবে পুনঃব্যবহৃত কম্পোনেন্ট একটি ত্রুটিও ব্যাপকভাবে ছড়িয়ে দিতে পারে, তাই যেখানে মানুষ তা ব্যবহার করে সেই পেজগুলোতে এটি পরীক্ষা করুন।
প্রতিটি ব্যবহারকারী-দৃশ্যমান স্টেট তালিকাভুক্ত করুন এবং বাস্তব লেবেল, দীর্ঘ টেক্সট, এবং ত্রুটিগুলো দেখান যাতে বাস্তবায়নের সীমা দেখা যায়।
পুরনো ভ্যারিয়েন্টগুলো স্পষ্টভাবে মার্ক করুন, বিকল্পের নাম দিন, এবং প্রভাবিত যাত্রাগুলো পর্যালোচনা না করা পর্যন্ত সেগুলো সরান না।
রিলিজ শর্ত হিসেবে অ্যাক্সেসিবিলিটি বানান
অ্যাক্সেসিবিলিটি সিস্টেমের মধ্যে নির্মিত থাকতে হবে কারণ পুনরাবৃত্ত সিদ্ধান্তগুলি বাধাও পুনরাবৃত্ত করে দিতে পারে। WCAG 2.2 লেভেল A-তে, ফাংশনালিটির জন্য কী-বোর্ড অপারেশন প্রয়োজন (যেখানে যাতায়াত পথ স্বতঃস্ফূর্ত নয়) এবং যখন সিকোয়েন্স গুরুত্বপূর্ণ সেখানে অর্থবহ ফোকাস অর্ডার প্রয়োজন। কম্পোনেন্ট নির্দেশিকায় সেমান্টিক কন্ট্রোল, দৃশ্যমান ফোকাস, লেবেল, যৌক্তিক ফোকাস মুভমেন্ট, ত্রুটি সনাক্তকরণ এবং নন-পয়েন্টার টাস্ক সম্পন্নকরণ অন্তর্ভুক্ত করুন। অটোমেটেড চেকগুলো শুরুতেই ব্যবহার করুন, তারপর ম্যানুয়াল কী-বোর্ড, জুম, রেসপন্সিভ এবং পেজ টেস্টিং করুন। USWDS সতর্ক করে যে অ্যাক্সেসযোগ্য কম্পোনেন্ট থাকা মানে সার্ভিসটি অ্যাক্সেসযোগ্য হবে না; কাস্টম কোড, কপিকরণ, ইন্টিগ্রেশন এবং কনটেক্সট এখনও রিভিউ প্রয়োজন।
নিশ্চিত করুন মানুষ কন্ট্রোলগুলো মাউস ছাড়া পৌঁছাতে, চালাতে, বুঝতে এবং ছেড়ে যেতে পারে—কোনও কী-বোর্ড ট্র্যাপ নেই।
আইনি দায় দায়িত্ব ভিন্ন ভিন্ন অঞ্চল এবং চুক্তি অনুযায়ী পরিবর্তিত হয়। যখন সম্মতি গুরুত্বপূর্ণ হয় তখন যোগ্য অ্যাক্সেসিবিলিটি এবং আইনি পর্যালোচনা করুন।
কন্টেন্ট স্ট্যান্ডার্ডকে ইন্টারফেস স্ট্যান্ডার্ড হিসেবে আচরণ করুন
শব্দগুলো হল কম্পোনেন্ট ইনপুট, পরে যোগ করা অলঙ্করণ নয়। অ্যাকশন লেবেল, ফর্ম লেবেল, ত্রুটি, হেডিং, লিংক, পরিভাষা, তারিখ, সংখ্যা এবং সংক্ষেপণের নিয়ম স্থাপন করুন। GOV.UK গাইডলাইন সক্রিয় কণ্ঠ (active voice) এবং সম্ভব হলে ব্যবহারকারীকে 'আপনি' হিসেবে সম্বোধন করতে উৎসাহ দেয়; স্পষ্ট, সঙ্গতিশীল ভাষার নীতি ব্যবহার করুন এবং আপনার শ্রোতাদের অনুযায়ী কণ্ঠ অভিযোজিত করুন। একটি কন্টেন্ট মডেলের সাথে নিয়মগুলো জোড়া দিন: কোন ফিল্ডগুলি আবশ্যক, যুক্তিসংগত দৈর্ঘ্য নির্দেশিকা, এবং তথ্য অনুপস্থিত হলে কি হবে তা নির্দেশ করুন। নির্দেশিকাগুলো কম্পোনেন্ট ডকস এবং CMS ওয়ার্কফ্লোতে রেখে দিন যাতে সম্পাদকরা এগুলো ব্যবহার করতে পারেন।
বলুন কি ব্যর্থ হয়েছে, কোথায় হয়েছে, এবং পরবর্তী করণীয়—যখন এটি নিরাপদ ও দরকারী তখন।
একটি সীমা হচ্ছে পুনঃনির্মাণ বা পুনঃলেখার জন্য সংকেত, না যে অপরিহার্য অর্থ মুছতে অনুমতি দেয়।
সিস্টেমটি তৈরির আগে গভর্ন করুন যাতে বিশ্বাসের চেয়ে দ্রুত বাড়ে না
গভর্নেন্স হলো মালিকানা, অনুরোধ, রিভিউ, রিলিজ এবং অবসর প্রক্রিয়ার জন্য হালকা ওজনের প্রক্রিয়া। একটি দায়িত্বশীল মালিক এবং এমন একটি রিভিউ গ্রুপ নামকরণ করুন যা ডিজাইন, ইঞ্জিনিয়ারিং, কন্টেন্ট এবং অ্যাক্সেসিবিলিটি দক্ষতা নিয়ে আসতে পারে। প্রমাণকে ব্লাস্ট রেডিয়াসের সাথে মিলান। একটি লোকাল প্যাটার্নের জন্য সমস্যা বিবৃতি এবং পেজ টেস্ট প্রয়োজন হতে পারে। একটি শেয়ার্ড বাটন বা টোকেন পরিবর্তনের জন্য প্রভাবিত যাত্রা, অ্যাক্সেসিবিলিটি চেক, ভিজ্যুয়াল তুলনা, মাইগ্রেশন নোট, এবং রোলব্যাক নির্দেশিকা অন্তর্ভুক্ত করা উচিত। GOV.UK অংশীদারদের অনুরোধ করে দেখাতে যে একটি কম্পোনেন্ট বহু টিমের জন্য উপকারী, কোনও ডুপ্লিকেট নয়, এবং প্রতিনিধিত্বমূলক ব্যবহারকারীদের সাথে টেস্ট করা—এইটাকে সর্বজনীন নিয়ম নয় বরং একটি ব্যবহারিক মডেল হিসেবে ব্যবহার করুন।
সমস্যা, অপশন, সিদ্ধান্ত, মালিক, প্রভাবিত সংস্করণ এবং রিভিউ তারিখ যেখানে টিমগুলো তা খুঁজে পেতে পারে সংরক্ষণ করুন।
পরিবর্তনগুলোকে প্যাচ, অ্যাডিটিভ, বা ব্রেকিং হিসেবে লেবেল করুন যাতে কনজিউমাররা জানে কখন মাইগ্রেশন এবং সামঞ্জস্যকাল দরকার।
রিলিজের আগে রিগ্রেশন প্রতিরোধ করুন
সিস্টেমকে ডেলিভারির সঙ্গে যুক্ত করুন। একটি পরিবর্তনের জন্য টাচ করা টোকেন এবং কম্পোনেন্টগুলো চিহ্নিত করতে বলুন, তারপর প্রভাবিত স্টেট এবং প্রতিনিধিত্বমূলক পেজগুলো পরীক্ষা করুন। ভিজ্যুয়াল তুলনা, ইন্টারঅ্যাকশন টেস্ট, কন্টেন্ট রিভিউ এবং অ্যাক্সেসিবিলিটি চেকগুলো আলাদা ত্রুটি খুঁজে পায়। উচ্চ-প্রভাব যাত্রা এবং উচ্চ-ট্রাফিক যাত্রাকে উভয়ই অগ্রাধিকার দিন; অ্যাকাউন্ট অ্যাক্সেস এবং যোগাযোগ ফর্মগুলো গুরুত্বপূর্ণ হতে পারে যদিও ট্রাফিক আধা-কম থাকে। এটি Status Is UP-এর প্রোঅ্যাকটিভ আপটাইম অপ্টিমাইজেশন এবং মেরামত কাজকে সমর্থন করে কারণ এটি ত্রুটির পরিধি সংকীর্ণ করে এবং অনুমোদিত ফিক্স যাচাই করা সহজ করে। এটি ডাউনটাইম মনিটরিং বা ইনসিডেন্ট প্ল্যানের বিকল্প নয়।
কম্পোনেন্ট সংস্করণ, টেস্ট ফলাফল, আবিষ্কার, অনুমোদন এবং কোনো গৃহীত ঝুঁকি রিলিজ রেকর্ডের সঙ্গে সংরক্ষণ করুন।
আগের স্থিতিশীল সংস্করণ সংরক্ষণ করুন এবং নিম্ন-ঝুঁকিপূর্ণ রক্ষণাবেক্ষণের সময় পুনরুদ্ধার ও যাচাই ধাপ লিখিতভাবে পরীক্ষা করুন।