বিষয় 3.2 — ডিজাইন সিস্টেম ও প্রোটোটাইপিং

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

স্বাস্থ্য ও পরিচর্যায় কেন এটি গুরুত্বপূর্ণ#

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

একটি ডিজাইন সিস্টেম হলো একই ভুলের জন্য বারবার মূল্য দেওয়া বন্ধ করার উপায়। যখন একটি অ্যাক্সেসযোগ্য, ভালোভাবে পরীক্ষিত উপাদান একবার গড়া হয় এবং ডজনখানেক সেবা জুড়ে পুনর্ব্যবহৃত হয়, আপনি একটি অ্যাক্সেসিবিলিটি ত্রুটি বা নিরাপত্তা অস্পষ্টতা এক জায়গায় ঠিক করেন এবং প্রতিটি সেবা সংশোধন উত্তরাধিকারে পায়। বিকল্প, সর্বত্র বিশেষভাবে নির্মিত ফ্রন্ট-এন্ড, মানে অজানা, অসম মান: কিছু সেবা Web Content Accessibility Guidelines (WCAG) পূরণ করে এবং কিছু নীরবে সেই মানুষদের বাদ দেয় যারা জনস্বাস্থ্য সেবার ওপর সবচেয়ে বেশি নির্ভর করে।

সামঞ্জস্য বোধগম্যতার বিষয়ও। রোগী ও কর্মীরা সেবাগুলোর মধ্যে চলাচল করেন, একটি National Health Service (NHS) অ্যাপ, একটি ট্রাস্টের বহির্বিভাগীয় পোর্টাল, একটি সাধারণ চিকিৎসা অনুশীলনের বুকিং হাতিয়ার, এবং প্রতিটি অপরিচিত ধরন জ্ঞানীয় ভার চাপায়। যেখানে জনগোষ্ঠীতে অসুস্থ, উদ্বিগ্ন, বয়স্ক, ডিজিটালভাবে বঞ্চিত বা সহায়ক প্রযুক্তি ব্যবহারকারী মানুষ আছেন, সেই ভার সমানভাবে বণ্টিত হয় না। ভাগ করা ধরন সবার জন্য তা কমায়। এই বিষয় যন্ত্র নিয়ে: উপাদান, ধরন, টোকেন, প্রোটোটাইপ ও ডিজাইন অপারেশন্স, যা নিরাপদ, অ্যাক্সেসযোগ্য, সামঞ্জস্যপূর্ণ নকশাকে বীরত্বের কাজ নয়, সবচেয়ে কম বাধার পথ করে।

মূল ধারণা#

একটি ডিজাইন সিস্টেম হলো একসেট ডিজিটাল সেবা গড়তে ব্যবহৃত পুনর্ব্যবহারযোগ্য উপাদান, ধরন, শৈলী ও নির্দেশিকার একটি একক সত্য-উৎস। এটি একটি শৈলী নির্দেশিকার চেয়ে বেশি: এটি কাজ করা, কোড-করা উপাদানকে নকশা-যুক্তি, অ্যাক্সেসিবিলিটি নোট ও ব্যবহার নির্দেশিকার সঙ্গে জোড়া দেয় যা বলে প্রতিটি কখন ও কীভাবে ব্যবহার করতে হবে। সবচেয়ে প্রাসঙ্গিক দুটি সরকারি উদাহরণ হলো NHS ডিজাইন সিস্টেম (NHS England দ্বারা রক্ষিত, NHS.UK ফ্রন্ট-এন্ডের ওপর গড়া) এবং Government Digital Service (GDS) দ্বারা রক্ষিত GOV.UK ডিজাইন সিস্টেম। দুটোই উন্মুক্ত, বিনামূল্যে সহজলভ্য, এবং লক্ষ লক্ষ মিথস্ক্রিয়ায় ঝড়ে-পরীক্ষিত।

একটি উপাদান লাইব্রেরি আলাদা নির্মাণ-খণ্ড ধরে, বোতাম, ফর্ম ইনপুট, হেডার, ত্রুটি সারাংশ, আর একটি ধরন লাইব্রেরি বারবার আসা সমস্যার উচ্চতর-ক্রমের সমাধান ধরে: জন্মতারিখ কীভাবে জিজ্ঞাসা করবেন, প্রশ্নের একটি পাতা কীভাবে কাঠামো দেবেন, ত্রুটি কীভাবে জানাবেন, ব্যবহারকারীকে তাঁর NHS নম্বর কীভাবে জিজ্ঞাসা করবেন। উপাদান হলো শব্দভান্ডার; ধরন হলো বাক্য। দুটোই উপাদান-ভিত্তিক সফটওয়্যার প্রকৌশল থেকে আঁকে, যেখানে সিস্টেম শিথিলভাবে যুক্ত, স্বাধীনভাবে পরীক্ষাযোগ্য, পুনর্ব্যবহারযোগ্য অংশ থেকে জোড়া লাগানো হয়।

ডিজাইন টোকেন হলো নামধারী ভেরিয়েবল হিসেবে প্রকাশিত ক্ষুদ্রতম ভাগ করা সিদ্ধান্ত: একটি রঙ, একটি ব্যবধান একক, একটি ফন্ট সাইজ, একটি ফোকাস-অবস্থা রূপরেখা। যেহেতু টোকেন হার্ড-কোড না করে নাম দিয়ে উল্লেখ করা হয়, একটি টোকেনের পরিবর্তন (ধরুন ন্যূনতম টাচ-টার্গেট আকার বা কনট্রাস্ট বাড়ানো) তা ব্যবহারকারী প্রতিটি উপাদানে সামঞ্জস্যপূর্ণভাবে ছড়ায়। টোকেন হলো সেই প্রক্রিয়া যা একটি সিস্টেমকে মাপে বাড়ার সময় সুসংগত রাখে এবং ফর্ক না করেই স্থানীয় ব্যবহারের জন্য একটি ভাগ করা সিস্টেমকে থিম করা সম্ভব করে।

একটি একক সত্য-উৎস হলো নিয়ন্ত্রক ধারণা: প্রতিটি নকশা সিদ্ধান্ত ঠিক এক জায়গায় মাস্টার করা হয়, তাই তা সেবা জুড়ে সিঙ্কের বাইরে সরে যেতে পারে না। যখন একটি উপাদানের নকশা, কোড ও নির্দেশিকা সবই একটি প্রামাণ্য লাইব্রেরিতে থাকে, আপনি সেই শ্রেণির বাগ নির্মূল করেন যেখানে ছবি ও পণ্য একমত নয়।

সফটওয়্যার প্রোটোটাইপিং হলো আসল জিনিস গড়ার প্রতিশ্রুতির আগে কিছু শেখার জন্য একটি সেবার ইচ্ছাকৃতভাবে অসম্পূর্ণ সংস্করণ গড়ার চর্চা। প্রোটোটাইপ নিম্ন-বিশ্বস্ততা (কাগজের স্কেচ, গ্রেস্কেল ওয়্যারফ্রেম) থেকে উচ্চ-বিশ্বস্ততা (ইন্টারঅ্যাকটিভ, বাস্তবসম্মত, প্রায়ই কোডে গড়া) পর্যন্ত বিস্তৃত। GDS নীতি হলো শেখার জন্য প্রোটোটাইপ করুন, রাখার জন্য নয়: একটি প্রোটোটাইপের কাজ প্রকৃত ব্যবহারকারীদের সঙ্গে ব্যবহারযোগ্যতা পরীক্ষা-র মাধ্যমে একটি প্রশ্নের উত্তর দেওয়া, যার পরে তা ফেলে দেওয়া হয়: এটি ফেলে-দেওয়া (বা "দ্রুত") প্রোটোটাইপিং, যে বিবর্তনশীল প্রোটোটাইপ আপনি প্রোডাকশনে শক্ত করতে চান তা থেকে ভিন্ন।

DesignOps (ডিজাইন অপারেশন্স) হলো বড় মাপে নকশা চালানোর শৃঙ্খলা: একটি প্রতিষ্ঠান বা সমন্বিত পরিচর্যা ব্যবস্থা (ICS) জুড়ে একটি ভাগ করা ডিজাইন সিস্টেমকে সুস্থ, অর্থায়িত ও বিশ্বস্ত রাখা মানুষ, কর্মপ্রবাহ, গভর্ন্যান্স, অবদান মডেল ও হাতিয়ার। এটি নকশার জন্য তাই যা প্ল্যাটফর্ম প্রকৌশল কোডের জন্য: কাজ করলে প্রায়ই অদৃশ্য, না করলে যন্ত্রণাদায়কভাবে সুস্পষ্ট। প্রোটোটাইপিং করা হয় Figma-র মতো নকশা হাতিয়ারে বা সরাসরি একটি ডিজাইন সিস্টেমের ফ্রন্ট-এন্ড ব্যবহার করে কোডে, যা আমাদের নিয়ে আসে ফ্রন্ট-এন্ড ওয়েব ডেভেলপমেন্ট-এ: HTML, CSS ও JavaScript স্তর যেখানে পুনর্ব্যবহার আসলে নকল, খরচ ও ঝুঁকি কমায়।

এই বিষয় ইচ্ছাকৃতভাবে ব্যবহারকারীদের কী দরকার (বিষয় 3.0 — ব্যবহারকারী গবেষণা ও সেবা নকশা দেখুন) বা শব্দ কীভাবে লেখা হয় (বিষয় 3.1 — কনটেন্ট ডিজাইন ও স্বাস্থ্য সাক্ষরতা দেখুন) পুনরায় ঢাকে না। সেই শাস্ত্রগুলো ডিজাইন সিস্টেমকে খাদ দেয়; এই বিষয় সেই পুনর্ব্যবহারযোগ্য যন্ত্র নিয়ে যা তাদের উপসংহারকে নিরাপদে প্রোডাকশনে বহন করে।

শ্রেষ্ঠ চর্চা#

1. গড়ার আগে গ্রহণ করুন। নিজের উদ্ভাবনের বদলে NHS ডিজাইন সিস্টেম ও GOV.UK ডিজাইন সিস্টেম থেকে শুরু করুন। তারা ইতিমধ্যে স্বাস্থ্য ও সরকারি সেবা জুড়ে বছরের পর বছর অ্যাক্সেসিবিলিটি পরীক্ষা, কনটেন্ট ডিজাইন ও বাস্তব-জগতের ব্যবহার এনকোড করেছে। একটি তারিখ নির্বাচক বা ত্রুটি সারাংশ নতুন করে উদ্ভাবন দুষ্প্রাপ্য, ব্যয়বহুল নকশা ও প্রকৌশল সামর্থ্যের ভালো ব্যবহার নয়, এবং ঘরে-তৈরি সংস্করণ প্রায় সবসময় কম অ্যাক্সেসযোগ্য হবে। স্থানীয় প্রয়োজনের জন্য এই সিস্টেমগুলো প্রসারিত ও থিম করুন; সুচিন্তিত, নথিবদ্ধ কারণ ছাড়া ফর্ক করবেন না।

2. অ্যাক্সেসিবিলিটি ও ক্লিনিক্যাল নিরাপত্তা পৃথক স্ক্রিনে নয়, ভাগ করা উপাদানে গড়ুন। একটি ডিজাইন সিস্টেমের সম্পূর্ণ অর্থনৈতিক ও নিরাপত্তা যুক্তি হলো আপনি কিছু একবার ঠিক করেন এবং সর্বত্র তা উত্তরাধিকারে পান। একবার গড়া ও আশ্বাসপ্রাপ্ত একটি অ্যাক্সেসযোগ্য, কীবোর্ড-নেভিগেবল, স্ক্রিন-রিডার-পরীক্ষিত জন্মতারিখ উপাদান তা ব্যবহারকারী প্রতিটি সেবাকে রক্ষা করে। WCAG সামঞ্জস্য, বিবেচ্য ত্রুটি সামলানো, এবং নিরাপত্তা-প্রাসঙ্গিক আচরণ (ধ্বংসাত্মক কাজের স্পষ্ট নিশ্চিতকরণ, ডোজ ও পরিমাপের জন্য নিঃসন্দেহ একক) উপাদানেই বেক করুন, যাতে দলগুলো সহজে ভুল করতে না পারে (বিষয় 1.9 — ডিজিটাল অন্তর্ভুক্তি ও অ্যাক্সেসিবিলিটি এবং বিষয় 1.6 — ক্লিনিক্যাল নিরাপত্তা ও ঝুঁকি ব্যবস্থাপনা দেখুন)।

3. শেখার জন্য প্রোটোটাইপ করুন, রাখার জন্য নয়। প্রোটোটাইপকে ফেলে-দেওয়া পরীক্ষা হিসেবে দেখুন যা সস্তায় ও দ্রুত একটি নির্দিষ্ট প্রশ্নের উত্তর দেয়: "কম স্বাস্থ্য সাক্ষরতার রোগী কি এই রেফারাল সম্পূর্ণ করতে পারেন?" বিশ্বস্ততা প্রশ্নের সঙ্গে মেলান: প্রবাহ ও বোধগম্যতা আগে পরীক্ষা করতে নিম্ন-বিশ্বস্ততা স্কেচ ব্যবহার করুন, এবং বাস্তবসম্মত মিথস্ক্রিয়া, অ্যাক্সেসিবিলিটি ও প্রান্তিক ক্ষেত্র পরে পরীক্ষা করতে উচ্চ-বিশ্বস্ততা কোড-করা প্রোটোটাইপ। একটি প্রোটোটাইপ সরাসরি প্রোডাকশনে উন্নীত করার টান প্রতিহত করুন; শেখার গতির জন্য অপ্টিমাইজ করা প্রোটোটাইপ কোড একটি লাইভ ক্লিনিক্যাল সেবার জন্য নিরাপদ, সুরক্ষিত বা রক্ষণযোগ্য হওয়ার মতো যথেষ্ট কদাচিৎ হয়।

4. মিথস্ক্রিয়া ও অ্যাক্সেসিবিলিটি প্রশ্ন হলে প্রকৃত ফ্রন্ট-এন্ডে প্রোটোটাইপ করুন। নকশা-হাতিয়ার প্রোটোটাইপ (Figma ও অনুরূপ) বিন্যাস, প্রবাহ ও কনটেন্ট দ্রুত ও সহযোগিতামূলকভাবে অন্বেষণের জন্য চমৎকার। কিন্তু তারা বিশ্বস্তভাবে কীবোর্ড নেভিগেশন, স্ক্রিন-রিডার আচরণ, ফোকাস ব্যবস্থাপনা বা পুরোনো NHS ভুবনের হার্ডওয়্যারে কর্মক্ষমতা পরীক্ষা করতে পারে না। যখন সেগুলোই ঝুঁকি, ডিজাইন সিস্টেমের ফ্রন্ট-এন্ড ব্যবহার করে কোডে প্রোটোটাইপ করুন, যাতে আপনি প্রকৃত সহায়ক প্রযুক্তির সঙ্গে প্রকৃত ব্যবহারকারীরা আসলে যা অনুভব করবেন তার কাছাকাছি কিছু পরীক্ষা করেন।

5. গড়ার আগে প্রকৃত ব্যবহারকারীদের সঙ্গে প্রোটোটাইপ পরীক্ষা করুন। প্রতিনিধিত্বমূলক ব্যবহারকারীদের সামনে কখনো না রাখা একটি প্রোটোটাইপ কেবল একটি ব্যয়বহুল মতামত। আপনার প্রকৃত জনগোষ্ঠী প্রতিফলিত করা মানুষদের সঙ্গে পরীক্ষা করুন, বয়স্ক মানুষ, প্রতিবন্ধী মানুষ, কম ডিজিটাল আত্মবিশ্বাসী মানুষ এবং সময়ের চাপে কাজ করা কর্মীসহ। এমনকি পাঁচজন অংশগ্রহণকারী বেশির ভাগ গুরুতর ব্যবহারযোগ্যতা ও বোধগম্যতা সমস্যা তুলে আনবে, এবং একটি প্রোটোটাইপে সেগুলো খুঁজে পাওয়া প্রোডাকশনে পাওয়ার চেয়ে মাত্রার ক্রমে সস্তা (বিষয় 3.7 — পরীক্ষা ও গুণমান নিশ্চয়তা দেখুন)।

6. সামঞ্জস্যের চুক্তি হিসেবে টোকেন পরিচালনা করুন। রঙ, ব্যবধান, টাইপোগ্রাফি ও মিথস্ক্রিয়া অবস্থা নামধারী ডিজাইন টোকেন হিসেবে প্রকাশ করুন, এবং সেগুলোর পরিবর্তনকে একটি ভাগ করা নির্ভরতা পরিবর্তনের গুরুত্ব দিয়ে দেখুন। টোকেন আপনাকে সিস্টেম-ব্যাপী ন্যূনতম কনট্রাস্ট, টাচ-টার্গেট আকার ও ফোকাস দৃশ্যমানতা প্রয়োগ করতে দেয়, এবং একটি স্থানীয় দলকে অন্তর্নিহিত অ্যাক্সেসিবিলিটি নিশ্চয়তা না ভেঙে তাদের ব্র্যান্ডের জন্য পুনঃথিম করতে দেয়। যখন একটি জাতীয় মান সরে, আপনি দশ হাজার স্ক্রিন নিরীক্ষা নয়, একটি টোকেন বদলাতে চান।

7. একটি অবদান মডেল চালান, প্রাচীর-ঘেরা বাগান নয়। যে ডিজাইন সিস্টেম কেবল একটি কেন্দ্রীয় দলের অবদান নেয় তা সবসময় প্রকৃত সেবার প্রয়োজনের পেছনে পড়বে এবং ডেলিভারি দলগুলোর বিরক্তির কারণ হবে। দলগুলোকে নতুন উপাদান ও ধরন প্রস্তাব করার একটি স্পষ্ট পথ প্রকাশ করুন, কী গৃহীত হবে, কে পর্যালোচনা করবে, এবং ভাগ করা লাইব্রেরিতে কিছু উন্নীত হওয়ার আগে অ্যাক্সেসিবিলিটি ও নিরাপত্তা কীভাবে আশ্বাসপ্রাপ্ত হবে তার মানদণ্ডসহ। এটি মূল DesignOps কাজ: এটি সিস্টেমকে পচতে বা খণ্ডিত হতে না দিয়ে স্থানীয় নমনীয়তা ও ভাগ করা সামঞ্জস্যের মধ্যকার টানাপোড়েনের ভারসাম্য রাখে।

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

9. কেবল অস্তিত্ব নয়, গ্রহণ ও মান পরিমাপ করুন। একটি ডিজাইন সিস্টেম কেবল ব্যবহৃত হলেই মূল্য দেয়। ট্র্যাক করুন কোন সেবা ভাগ করা উপাদান ব্যবহার করে, কোথায় দলগুলোকে বিশেষ বিকল্প গড়তে হয়েছে (এবং কেন), এবং গ্রহণ বাড়লে অ্যাক্সেসিবিলিটি সামঞ্জস্য উন্নত হয় কি না। স্থানীয় ঘুরপথের উচ্চ হার একটি সংকেত যে সিস্টেমে প্রকৃত কিছু অনুপস্থিত, সেগুলোকে অবাধ্যতা নয়, ব্যাকলগ হিসেবে দেখুন।

দলের সঙ্গে আলোচনার প্রশ্ন#

1. ভাগ করা সামঞ্জস্য ও স্থানীয় নমনীয়তার মধ্যে রেখা কোথায় বসা উচিত, এবং কে তা ঠিক করে? এটি যেকোনো ডিজাইন সিস্টেমের কেন্দ্রীয় গভর্ন্যান্স টানাপোড়েন। খুব অনমনীয় হলে, ডেলিভারি দলগুলো আটকে আছে মনে করে, ছায়া উপাদান গড়ে এবং সিস্টেম এড়িয়ে যায়, ঠিক যে সামঞ্জস্য আপনি রক্ষা করতে চেয়েছিলেন তা খণ্ডিত করে। খুব শিথিল হলে, "সিস্টেম" ভাগ করা নিরাপত্তা বা অ্যাক্সেসিবিলিটি নিশ্চয়তা ছাড়া আলগাভাবে সম্পর্কিত এককালীন জিনিসের একটি স্তূপ হয়। স্বাস্থ্য ও পরিচর্যার প্রেক্ষাপটে ঝুঁকি নির্দিষ্ট: কিছু ভিন্নতা বৈধ (একটি মানসিক-স্বাস্থ্য সংকট সেবার প্রয়োজন একটি রুটিন অ্যাপয়েন্টমেন্ট বুকার থেকে সত্যিই ভিন্ন), আর কিছু ভিন্নতা বিপজ্জনক (একটি ধ্বংসাত্মক ক্লিনিক্যাল কাজ নিশ্চিত করার অসংগত উপায়)। ভালো উত্তর কোন সিদ্ধান্তগুলো অনমনীয় (অ্যাক্সেসিবিলিটি, নিরাপত্তা-সংকটপূর্ণ ধরন, মূল মিথস্ক্রিয়া আচরণ) এবং কোনগুলো স্থানীয় থিমিংয়ের জন্য উন্মুক্ত তার নাম বলে, এবং ভিন্নতা কেবল নিষিদ্ধ না করে একটি দলের জন্য ব্যতিক্রম অনুরোধ বা নতুন ধরন অবদানের একটি স্পষ্ট, মানবিক প্রক্রিয়া সংজ্ঞায়িত করে।

2. আমাদের উপাদানের ভেতরে অ্যাক্সেসিবিলিটি ও ক্লিনিক্যাল নিরাপত্তা আসলে কীভাবে আশ্বাসপ্রাপ্ত হবে, এবং কে তা অনুমোদন করেন? অ্যাক্সেসিবিলিটি ও নিরাপত্তা "বেক করা" বলে দাবি করা সহজ; তা নিশ্চিত করা কঠিন। এই প্রশ্ন আপনাকে আশ্বাস পাইপলাইন নিয়ে মূর্ত হতে বাধ্য করে: কে প্রতিটি উপাদান WCAG-র বিপরীতে, কোন সহায়ক প্রযুক্তি দিয়ে এবং কোন প্রতিবন্ধী ব্যবহারকারীদের সঙ্গে পরীক্ষা করেন; নিরাপত্তা-প্রাসঙ্গিক আচরণ আপনার ক্লিনিক্যাল নিরাপত্তা প্রক্রিয়ার (DCB0129/DCB0160) বিপরীতে কীভাবে পর্যালোচিত হয়; এবং "পুনর্ব্যবহারের জন্য নিরাপদ" হিসেবে প্রকাশের আগে একটি উপাদানের সঙ্গে কী প্রমাণ সংযুক্ত। বিতর্কে সৎ ফাঁক প্রকাশ পাওয়া উচিত: হয়তো আপনার স্বয়ংক্রিয় কনট্রাস্ট যাচাই আছে কিন্তু কখনো একজন প্রকৃত স্ক্রিন-রিডার ব্যবহারকারীর সঙ্গে পরীক্ষা করেননি, বা আপনার Clinical Safety Officer কখনো ভাগ করা উপাদান লাইব্রেরি পর্যালোচনা করেননি। শক্তিশালী উত্তর একজন নামধারী মালিক, একটি সংজ্ঞায়িত পরীক্ষা ব্যবস্থা, এবং একটি নিয়ম তৈরি করে যে নথিবদ্ধ অ্যাক্সেসিবিলিটি ও নিরাপত্তা প্রমাণ ছাড়া কোনো উপাদান ভাগ করা লাইব্রেরিতে ঢোকে না, কারণ পঞ্চাশটি সেবা উত্তরাধিকারে পাওয়া একটি ত্রুটি পঞ্চাশ গুণ ক্ষতি।

3. প্রাথমিক উৎসাহ ম্লান হয়ে গেলে কে ডিজাইন সিস্টেমে অর্থায়ন, কর্মী নিয়োগ ও রক্ষণাবেক্ষণ করে? ডিজাইন সিস্টেম প্রায়ই শক্তির একটি বিস্ফোরণে তৈরি হয় এবং তারপর প্রতিষ্ঠাতা দল সরে গেলে নীরবে পরিত্যক্ত হয়, একটি বাসি লাইব্রেরি রেখে যাতে দলগুলো আর আস্থা রাখে না। এটি মৌলিকভাবে একটি DesignOps ও অর্থায়নের প্রশ্ন, নকশার প্রশ্ন নয়। সততার সঙ্গে বিতর্ক করুন আপনার সিস্টেমটিকে একটি চলমান প্রোডাক্ট হিসেবে দায়িত্বশীল একটি স্থায়ী, অর্থায়িত দল আছে কি না, সহায়তা, অবদান পর্যালোচনা, সংস্করণ এবং উজানের NHS ও GOV.UK সিস্টেমের সঙ্গে তাল মেলানোর সামর্থ্যসহ, নাকি আপনি এমন সদিচ্ছার ওপর নির্ভর করছেন যা বাষ্পীভূত হবে। একটি ICS-এ এটি আরও তীক্ষ্ণ: সিস্টেমটি কি একটি প্রধান প্রতিষ্ঠানের মালিকানাধীন, যৌথভাবে শাসিত, নাকি তাদের মাঝে এতিম? ভালো উত্তর ডিজাইন সিস্টেমকে একজন নামধারী মালিক, একটি চলমান বাজেট এবং যে জাতীয় সিস্টেমের ওপর তা গড়া তার সঙ্গে একটি স্পষ্ট সম্পর্কসহ দীর্ঘস্থায়ী অবকাঠামো হিসেবে দেখে, একটি প্রকল্প যা "শেষ হয়" হিসেবে নয়।

4. উজানের NHS ও GOV.UK সিস্টেমের সঙ্গে আমাদের সম্পর্ক কী, এবং তারা বদলালে আমরা কীভাবে তাল মেলাব? একটি জাতীয় ডিজাইন সিস্টেম গ্রহণ একবারের ডাউনলোড নয়; এটি আপনার নিয়ন্ত্রণের বাইরের অবকাঠামোর ওপর একটি চলমান নির্ভরতা। এই প্রশ্ন আপনাকে সুচিন্তিতভাবে ঠিক করতে বাধ্য করে "হালকাভাবে থিম করুন এবং উজান ঘনিষ্ঠভাবে অনুসরণ করুন" থেকে "ফর্ক করুন এবং ভিন্ন হোন" পর্যন্ত বর্ণালীতে আপনি কোথায় বসেন। প্রতিটি পছন্দের একটি খরচ আছে: কাছাকাছি থাকা মানে উজানের পরিবর্তন (একটি নতুন অ্যাক্সেসিবিলিটি সংশোধন, একটি সংশোধিত ধরন) অন্য কারও সূচিতে শুষে নেওয়া এবং মাঝে মাঝে স্থানীয় কাস্টমাইজেশন পুনরায় কাজ করা; ফর্ক করা মানে প্রতিটি ভবিষ্যৎ অ্যাক্সেসিবিলিটি ও নিরাপত্তা সংশোধনের মালিক আপনি যা জাতীয় দল অন্যথায় আপনাকে বিনামূল্যে দিত। স্বাস্থ্য ও পরিচর্যায় ভিন্ন হওয়ার টান বাস্তব, ক্লিনিক্যাল কর্মপ্রবাহ ও স্থানীয় ব্র্যান্ডিং প্রকৃত চাপ তৈরি করে, কিন্তু প্রতিটি বিচ্যুতি একটি স্থায়ী দায়। ভালো উত্তর নাম বলে কে উজানের রিলিজ নোট দেখেন, স্থানীয় এক্সটেনশন কীভাবে কাঠামো দেওয়া হয় যাতে তা উজানের হালনাগাদে টেকে, এবং একটি প্রস্তাবিত বিচ্যুতিকে অনুমোদিত হওয়ার আগে কোন স্পষ্ট পরীক্ষা পেরোতে হবে, যাতে "আমাদের ভিন্ন দেখাতে হতো" কখনো নীরবে "আমরা এখন NHS তারিখ নির্বাচকের একটি বাসি, কম-অ্যাক্সেসযোগ্য ফর্ক রক্ষণাবেক্ষণ করি" না হয়।

5. "শেখার জন্য প্রোটোটাইপ" ও "রাখার জন্য নির্মাণ"-এর মধ্যে রেখা আমরা আসলে কীভাবে ধরে রাখব? নীতিগতভাবে সবাই একমত যে ফেলে-দেওয়া প্রোটোটাইপ প্রোডাকশন সেবা হওয়া উচিত নয়; ব্যর্থতা ঘটে সময়সীমার চাপে, যখন একটি বিশ্বাসযোগ্য উচ্চ-বিশ্বস্ততা প্রোটোটাইপ ঠিক সেখানে বসে আছে এবং তা পাঠানো একটি শর্টকাট মনে হয়। এই প্রশ্ন সীমানাকে আকাঙ্ক্ষার বদলে মূর্ত করে। বিতর্ক করুন ব্যবহারিকভাবে কী প্রোটোটাইপ কোডকে, নিরাপত্তা, স্থিতিস্থাপকতা বা রক্ষণযোগ্যতার জন্য নয়, শেখার গতির জন্য অপ্টিমাইজ করা, একটি লাইভ ক্লিনিক্যাল সেবায় উন্নীত হওয়া থেকে আটকায়: এটি কি একটি প্রযুক্তিগত বিচ্ছেদ (প্রোডাকশনে পৌঁছাতে না পারা একটি স্যান্ডবক্সে গড়া প্রোটোটাইপ), একটি গভর্ন্যান্স গেট (ক্লিনিক্যাল নিরাপত্তা অনুমোদন নেই, গো-লাইভ নেই), নাকি কেবল একটি ভাগ করা সদিচ্ছা যা ডেলিভারি তারিখ পিছোলে প্রথমবারই বাষ্পীভূত হয়? স্বাস্থ্য ও পরিচর্যার ঝুঁকি নির্দিষ্ট, কারণ একটি ক্লিনিক্যাল পথে অনাশ্বাসিত কোড একটি রোগী-নিরাপত্তা ঝুঁকি, কেবল টেকনিক্যাল ঋণ নয়। সৎ উত্তর স্বীকার করে চাপ কোথা থেকে আসবে, নাম বলে কে "না" বলার ক্ষমতাপ্রাপ্ত, এবং সংজ্ঞায়িত করে "আশ্বাসপ্রাপ্ত উপাদান থেকে প্রোডাকশনের জন্য পুনর্নির্মাণ" আসলে কী দাবি করে যাতে সীমানা পরীক্ষিত হলে টেকে।

6. ডিজাইন সিস্টেম আসলে কাজ করছে কি না আমরা কীভাবে জানব, এবং মেট্রিক অস্বস্তিকর হলে আমরা কী করব? একটি ডিজাইন সিস্টেম থাকতে পারে, সুন্দরভাবে নথিবদ্ধ হতে পারে, এবং তবু দলগুলো নীরবে তা এড়িয়ে গেলে সামান্য মূল্য দিতে পারে। এই প্রশ্ন "আমাদের একটি ডিজাইন সিস্টেম আছে" ছাড়িয়ে "এটি কি নিজের জায়গা অর্জন করছে"-তে যায়। ঠিক করুন আপনি কী পরিমাপ করবেন: সেবা জুড়ে গ্রহণ, বিশেষ ঘুরপথের হার ও কারণ, গ্রহণ বাড়লে অ্যাক্সেসিবিলিটি সামঞ্জস্য আসলে উন্নত হয় কি না, এবং পুনর্নির্মাণের বদলে পুনর্ব্যবহার করে দলগুলো কতটা সময় বাঁচায়। কঠিন অংশ সংখ্যা সংগ্রহ নয়, সেগুলো কীভাবে পড়বেন তা আগেই সম্মত হওয়া, কারণ স্থানীয় ঘুরপথের উচ্চ হার একটি সংকেত যে ভাগ করা সিস্টেমে প্রকৃত কিছু অনুপস্থিত, ডেলিভারি দলগুলো অবাধ্য হচ্ছে তার প্রমাণ নয়। ভালো উত্তর অস্বস্তিকর গ্রহণ ডেটাকে ব্যাকলগ ও রোডম্যাপ ইনপুট হিসেবে দেখতে প্রতিশ্রুতিবদ্ধ হয়, সংজ্ঞায়িত করে কে তা কতবার পর্যালোচনা করেন, এবং যে জিনিসটি গুরুত্বপূর্ণ (নিরাপদ, আরও অ্যাক্সেসযোগ্য, আরও সামঞ্জস্যপূর্ণ সেবা আসলে সরবরাহ হয়েছে) তার বদলে কেবল তোষামুদে জিনিস (অস্তিত্ব, ডাউনলোড সংখ্যা) পরিমাপের প্রলোভন প্রতিহত করে।

বাস্তবে: স্বাস্থ্য ও পরিচর্যার একটি উদাহরণ#

তিনটি অ্যাকিউট ট্রাস্ট, একটি মানসিক-স্বাস্থ্য ট্রাস্ট ও একটি কমিউনিটি প্রদানকারী জুড়ে একটি সমন্বিত পরিচর্যা ব্যবস্থা তার রোগী-মুখী ডিজিটাল ভুবন একীভূত করতে সিদ্ধান্ত নেয়। আজ প্রতিটি প্রতিষ্ঠান নিজস্ব বহির্বিভাগীয় পোর্টাল চালায়; তাদের মধ্যে চারটি অসামঞ্জস্যপূর্ণ তারিখ নির্বাচক, NHS নম্বর জিজ্ঞাসার তিনটি ভিন্ন উপায়, এবং ব্যাপকভাবে ভিন্ন অ্যাক্সেসিবিলিটি সামঞ্জস্য আছে। একটি অভ্যন্তরীণ নিরীক্ষা দেখে চারটি পোর্টালের মধ্যে কেবল একটি তার অ্যাপয়েন্টমেন্ট-বুকিং প্রবাহের একটি মৌলিক স্ক্রিন-রিডার পরীক্ষা পাস করে, একটি স্পষ্ট ন্যায্যতা ও ক্লিনিক্যাল-নিরাপত্তা ঝুঁকি।

ICS একটি ছোট, যৌথভাবে অর্থায়িত ডিজাইন সিস্টেম দল দাঁড় করায়। গোড়া থেকে না গড়ে, তারা NHS ডিজাইন সিস্টেমকে তাদের ভিত্তি হিসেবে গ্রহণ করে এবং ICS-নির্দিষ্ট ব্র্যান্ডিংয়ের জন্য ডিজাইন টোকেনের একটি পাতলা স্থানীয় স্তর, সঙ্গে মুষ্টিমেয় প্রকৃত স্থানীয় ধরন (যেমন দোভাষী সহায়তা বুকিংয়ের একটি ভাগ করা ধরন, যা কোনো জাতীয় সিস্টেম ঢাকে না) সংজ্ঞায়িত করে। প্রতিটি ভাগ করা উপাদান প্রকাশের আগে নথিবদ্ধ WCAG প্রমাণ এবং DCB0129 প্রক্রিয়ার অধীনে ICS Clinical Safety Officer-এর অনুমোদন বহন করে।

বহির্বিভাগীয় বুকিং প্রবাহ পুনর্নির্মাণের আগে, দল প্রোটোটাইপ করে। তারা নিম্ন-বিশ্বস্ততা দিয়ে শুরু করে, স্থানীয় জনগোষ্ঠী প্রতিফলিত করতে নিয়োগ করা বারোজন অংশগ্রহণকারীর সঙ্গে নতুন প্রবাহের একটি কাগজ-ও-গ্রেস্কেল সংস্করণ পরীক্ষা করে, যার মধ্যে দুজন স্ক্রিন-রিডার ব্যবহারকারী, ৭৫-এর ওপরে তিনজন, এবং কম ডিজিটাল আত্মবিশ্বাসের কয়েকজন। প্রোটোটাইপ একটি গুরুতর বোধগম্যতা সমস্যা প্রকাশ করে: রোগীরা একটি "পুনঃনির্ধারণ" কাজকে একটি "বাতিল" কাজ থেকে আলাদা করতে পারেন না। দল ধরনটি ঠিক করে, তারপর ডিজাইন সিস্টেম ফ্রন্ট-এন্ড ব্যবহার করে একটি উচ্চ-বিশ্বস্ততা কোড-করা প্রোটোটাইপ গড়ে এবং আবার পরীক্ষা করে, এবার একটি অংশীদার ট্রাস্টের বহির্বিভাগীয় ক্লিনিকে ব্যবহৃত প্রকৃত হার্ডওয়্যারে কীবোর্ড ও স্ক্রিন-রিডার আচরণ নিশ্চিত করে।

কেবল তখনই তারা সত্যিই গড়ে, প্রোডাকশন সেবা মূলত আশ্বাসপ্রাপ্ত, পুনর্ব্যবহারযোগ্য উপাদান থেকে জোড়া লাগিয়ে। আঠারো মাস পরে, একটি WCAG হালনাগাদ ফোকাস-দৃশ্যমানতার আবশ্যকতা কঠোর করে। যেহেতু ফোকাস শৈলী একটি একক ডিজাইন টোকেনে থাকে, দল একটি পরিবর্তন পাঠায় এবং প্রতিটি ICS সেবা পরবর্তী রিলিজে তা উত্তরাধিকারে পায়, একটি সংশোধন যা পুরোনো খণ্ডিত ভুবনে পাঁচটি আলাদা প্রতিকার প্রকল্প এবং, বাস্তবসম্মতভাবে, অন্তত একটি সেবা ভাঙা রেখে যেত।

খাতভিত্তিক দৃষ্টিকোণ#

স্টার্ট-আপ#

একটি ছোট ডিজিটাল-স্বাস্থ্য স্টার্ট-আপের প্রায় কখনো নিজের ডিজাইন সিস্টেম শূন্য থেকে গড়া উচিত নয়: সে অ্যাক্সেসিবিলিটি পরীক্ষার ওভারহেড বহন করতে পারে না, এবং বিনিয়োগকারীরা ক্লিনিক্যাল যাচাইয়ের জন্য অর্থ দিচ্ছেন, বিশেষভাবে নির্মিত বোতামের জন্য নয়। আপনি NHS ব্যবহারকারীদের জন্য গড়লে NHS বা GOV.UK ফ্রন্ট-এন্ড গ্রহণ করুন, এবং প্রোটোটাইপিংকে আপনার মূল প্রতিযোগিতামূলক সুবিধা হিসেবে দেখুন: প্রকৃত রোগীদের সঙ্গে পরীক্ষা করা সস্তা, দ্রুত, ফেলে-দেওয়া প্রোটোটাইপ আপনাকে ভালো-অর্থায়িত প্রতিষ্ঠিত প্রতিষ্ঠানের চেয়ে দ্রুত শিখতে দেয়। ঝুঁকি উল্টো: একটি বিনিয়োগকারী ডেমোয় পৌঁছাতে একটি চটকদার উচ্চ-বিশ্বস্ততা প্রোটোটাইপ সরাসরি প্রোডাকশনে উন্নীত করা, একটি লাইভ ক্লিনিক্যাল সেবায় অনাশ্বাসিত, অনিরাপদ কোড বহন করে। অর্থায়নের চাপেও "শেখার জন্য প্রোটোটাইপ" ও "রাখার জন্য নির্মাণ"-এর মধ্যে একটি কঠোর রেখা রাখুন।

ক্ষুদ্র ব্যবসা#

একটি প্রতিষ্ঠিত ছোট প্রদানকারী, যেমন একটি জিপি প্র্যাকটিস, কমিউনিটি ফার্মেসি, কেয়ার হোম, বা একটি রোগী-মুখী হাতিয়ার কমিশন করা একক-স্থানের ক্লিনিক, লাইভ রোগী রাখে কিন্তু কোনো নিবেদিত নকশা বা ফ্রন্ট-এন্ড সামর্থ্য নেই, এবং বিশেষভাবে নির্মিত উপাদানের খরচ শুষে নিতে পারে না। তার সবচেয়ে শক্তিশালী পদক্ষেপ হলো যেকোনো সরবরাহকারীকে NHS বা GOV.UK ফ্রন্ট-এন্ডের ওপর গড়তে জোর দেওয়া, যাতে অ্যাক্সেসিবিলিটি ও নিরাপত্তা নিশ্চয়তা প্রতিশ্রুত নয়, উত্তরাধিকারে আসে, এবং তা একটি আশার বদলে চুক্তির লিখিত শর্ত করা। তার নিজস্ব ডিজাইন সিস্টেম চালানোর কদাচিৎ দরকার হয়; তার একটি ভালোভাবে ব্যবহার করা দরকার, এবং চেনা দরকার যে একজন সরবরাহকারীর চটকদার ডেমো একটি অ্যাক্সেসযোগ্য, আশ্বাসপ্রাপ্ত লাইভ সেবার প্রমাণ নয়। যেখানে সে প্রোটোটাইপ করে, তার প্রকৃত, প্রায়ই বয়স্ক বা কম ডিজিটালভাবে আত্মবিশ্বাসী রোগীদের সঙ্গে একটি নতুন অনলাইন বুকিং প্রবাহ পরীক্ষা করে, প্রকৃত ব্যবহারকারীদের সঙ্গে কয়েকটি অধিবেশন একটি পালিশ করা মক-আপ যা কখনো প্রকাশ করে তার চেয়ে অনেক বেশি ধরবে। একটি বড় ট্রাস্টের মতো একই সংবিধিবদ্ধ অ্যাক্সেসিবিলিটি ও ক্লিনিক্যাল-নিরাপত্তা দায়িত্ব প্রযোজ্য, তাই সৎ প্রশ্ন মেনে চলা হবে কি না নয়, ভাগ করা জাতীয় অবকাঠামো থেকে উত্তরাধিকারে-পাওয়া সম্মতি কীভাবে সস্তায় পাওয়া যায়।

বৃহৎ প্রতিষ্ঠান#

একটি বড় NHS ট্রাস্ট বা স্বাস্থ্য-প্রযুক্তি প্রতিষ্ঠানের ইতিমধ্যে ওভারল্যাপিং ইন্টারফেস গড়া একাধিক দল আছে, তাই তার সমস্যা খণ্ডায়ন ও নকল খরচ। মূল্যের যুক্তি হলো একটি প্রকৃত অবদান মডেল চালানো একটি অর্থায়িত, স্থায়ী ডিজাইন সিস্টেম দল, নেতৃত্বের কাছে প্রতিবেদিত গ্রহণ মেট্রিক এবং ক্লিনিক্যাল নিরাপত্তা ও অ্যাক্সেসিবিলিটি আশ্বাসে একটি স্পষ্ট গভর্ন্যান্স রেখাসহ। কেন্দ্রীয় টানাপোড়েন রাজনৈতিক: ক্ষমতাশালী ডেলিভারি দলগুলো নিয়ন্ত্রণ ছাড়তে প্রতিরোধ করে, এবং একটি ভারী-হাতের কেন্দ্রীয় দল ছায়া উপাদান জন্ম দেয়। বড় প্রতিষ্ঠানগুলো সফল হয় ভাগ করা সিস্টেমকে সত্যিই সহজতর পছন্দ করে, ভালোভাবে নথিবদ্ধ, ভালোভাবে সমর্থিত এবং প্রদর্শনযোগ্যভাবে উচ্চতর মানের, বাধ্যতামূলক করে আশা করার বদলে।

সরকার#

NHS England বা GDS-এর মতো একটি জাতীয় সংস্থা ডিজাইন সিস্টেমকে এমন প্রতিষ্ঠানগুলোর ব্যবহৃত সরকারি অবকাঠামো হিসেবে চালায় যাদের সে নিয়ন্ত্রণ করে না, তাই উন্মুক্ততা, স্থিতিশীলতা ও পশ্চাদমুখী সামঞ্জস্য অপরিসীমভাবে গুরুত্বপূর্ণ। তার বাধ্যবাধকতা সবচেয়ে শক্তিশালী: সংবিধিবদ্ধ অ্যাক্সেসিবিলিটি প্রবিধান, সমতার দায়িত্ব, এবং বাস্তবতা যে একটি ভাগ করা জাতীয় উপাদানের ত্রুটি লক্ষ লক্ষ নাগরিকের কাছে ছড়ায়। কাজটি উদ্ভাবনের চেয়ে কম, তত্ত্বাবধানের বেশি: স্পষ্ট সংস্করণ, অবচয় নীতি, নিঃশেষ অ্যাক্সেসিবিলিটি প্রমাণ, এবং নিচের শত শত দলের প্রতি সাড়া। NHS ডিজাইন সিস্টেম ও GOV.UK ডিজাইন সিস্টেম রেফারেন্স উদাহরণ ঠিক এই কারণে যে তারা সিস্টেমকে একটি প্রকল্প নয়, দীর্ঘস্থায়ী জনকল্যাণ হিসেবে দেখে।

ব্যর্থতার সাধারণ ধরন#

• পরিত্যক্ত সিস্টেম। একটি ডিজাইন সিস্টেম ধুমধামে গড়া হয়, তারপর প্রতিষ্ঠাতা দল ছড়িয়ে পড়লে অরক্ষিত ফেলে রাখা হয়; দলগুলো আস্থা হারায় এবং বিশেষ কাজে ফিরে যায়। এড়ান একটি একবারের প্রকল্প নয়, একটি স্থায়ী প্রোডাক্ট দলে অর্থায়ন করে।
• মিথ্যা বলা ছবি। একক সত্য-উৎস না থাকায় নকশা ফাইল ও প্রোডাকশন কোড একমত নয়, তাই "ডিজাইন সিস্টেম" এমন কিছু বর্ণনা করে যা পণ্য আর করে না। কোড-করা উপাদান ও তাদের নথি প্রামাণ্য এবং একসঙ্গে সংস্করণ করে রাখুন।
• পরে-ভাবা অ্যাক্সেসিবিলিটি। প্রকৃত সহায়ক-প্রযুক্তি পরীক্ষা ছাড়া উপাদান পাঠানো হয়, ফলে একটি অ্যাক্সেস-অযোগ্য ধরন সর্বত্র উত্তরাধিকারে পাওয়া যায়, ক্ষতি কমানোর বদলে গুণিত করে। কোনো উপাদান প্রকাশের আগে নথিবদ্ধ WCAG ও স্ক্রিন-রিডার প্রমাণ চাইুন।
• প্রোটোটাইপ-থেকে-প্রোডাকশন। সময় বাঁচাতে একটি উচ্চ-বিশ্বস্ততা প্রোটোটাইপ সরাসরি একটি লাইভ সেবায় উন্নীত হয়, একটি ক্লিনিক্যাল পরিবেশে অনিরাপদ, অরক্ষণযোগ্য, অনাশ্বাসিত কোড বহন করে। ফেলে-দেওয়ার সীমানা প্রয়োগ করুন; আশ্বাসপ্রাপ্ত উপাদান থেকে প্রোডাকশনের জন্য পুনর্নির্মাণ করুন।
• প্রাচীর-ঘেরা বাগান। একটি কেন্দ্রীয় দল সব অবদান প্রত্যাখ্যান করে, তাই সিস্টেম কখনো প্রকৃত সেবার প্রয়োজন মেটায় না এবং ডেলিভারি দলগুলো তা এড়িয়ে যায়। একটি অবদান ও ব্যতিক্রম প্রক্রিয়া প্রকাশ করুন এবং স্থানীয় ঘুরপথকে ব্যাকলগ সংকেত হিসেবে দেখুন।
• সামঞ্জস্যের নাটক। যেখানে প্রকৃত স্থানীয় ভিন্নতা যথার্থ (সংকট সেবা, শিশুরোগ) সেখানে অনমনীয় অভিন্নতা প্রয়োগ করা হয়, পরিচ্ছন্নতার নামে নিরাপত্তা ও ব্যবহারযোগ্যতা ক্ষয় করে। অনমনীয় সিদ্ধান্তকে বৈধভাবে স্থানীয় সিদ্ধান্ত থেকে আলাদা করুন।
• ভুল বিশ্বস্ততা পরীক্ষা। মিথস্ক্রিয়া ও অ্যাক্সেসিবিলিটি ঝুঁকি কেবল একটি স্থির নকশা হাতিয়ারে "পরীক্ষা" করা হয় যা কীবোর্ড বা স্ক্রিন-রিডার আচরণ চালাতে পারে না, মিথ্যা আত্মবিশ্বাস দেয়। মিথস্ক্রিয়াই প্রশ্ন হলে কোডে প্রোটোটাইপ করুন।

পরিপক্বতা মডেল#

চেকলিস্ট#

• আপনি গোড়া থেকে না গড়ে আপনার ভিত্তি হিসেবে NHS ডিজাইন সিস্টেম এবং/অথবা GOV.UK ডিজাইন সিস্টেম গ্রহণ করেছেন।
• ভাগ করা উপাদান প্রকৃত সহায়ক প্রযুক্তি ও প্রতিবন্ধী ব্যবহারকারীদের সঙ্গে পরীক্ষিত নথিবদ্ধ WCAG সামঞ্জস্য প্রমাণ বহন করে।
• নিরাপত্তা-প্রাসঙ্গিক উপাদান পুনর্ব্যবহারের জন্য প্রকাশের আগে আপনার ক্লিনিক্যাল নিরাপত্তা প্রক্রিয়ার অধীনে পর্যালোচিত।
• ডিজাইন টোকেন রঙ, ব্যবধান, টাইপোগ্রাফি ও মিথস্ক্রিয়া অবস্থা নিয়ন্ত্রণ করে, এক জায়গা থেকে সিস্টেম-ব্যাপী পরিবর্তন সক্ষম করে।
• একটি একক সত্য-উৎস আছে যেখানে কোড-করা উপাদান ও তাদের নির্দেশিকা থাকে এবং একসঙ্গে সংস্করণ করা হয়।
• প্রোটোটাইপ প্রশ্নের সঙ্গে বিশ্বস্ততায় মেলানো, একটি প্রতিনিধিত্বমূলক ব্যবহারকারী নমুনা দিয়ে পরীক্ষিত, এবং ফেলে-দেওয়ার যোগ্য হিসেবে গণ্য।
• মিথস্ক্রিয়া- ও অ্যাক্সেসিবিলিটি-সংকটপূর্ণ প্রবাহ কেবল একটি নকশা হাতিয়ারে নয়, কোডে প্রোটোটাইপ করা হয়।
• একটি অর্থায়িত, নামধারী দল ডিজাইন সিস্টেমের একটি চলমান প্রোডাক্ট হিসেবে মালিক, রোডম্যাপ ও সহায়তা চ্যানেলসহ।
• একটি প্রকাশিত অবদান ও ব্যতিক্রম প্রক্রিয়া ডেলিভারি দলগুলোকে নতুন উপাদান ও ধরন প্রস্তাব করতে দেয়।
• গ্রহণ ও মান পরিমাপ করা হয়, এবং স্থানীয় ঘুরপথের উচ্চ হার অবাধ্যতা নয়, ব্যাকলগ হিসেবে গণ্য।

মূল উৎস#

• NHS ডিজাইন সিস্টেম — NHS England: NHS ডিজিটাল সেবার জন্য উপাদান, ধরন, শৈলী ও অ্যাক্সেসিবিলিটি নির্দেশিকা।
• GOV.UK ডিজাইন সিস্টেম — Government Digital Service: যুক্তরাজ্য সরকারি সেবার জন্য শৈলী, উপাদান ও ধরন।
• GOV.UK Service Manual — প্রোটোটাইপিং ও "একটি প্রোটোটাইপ বানান" — Government Digital Service: শেখার জন্য প্রোটোটাইপিং ও ব্যবহারকারীদের সঙ্গে পরীক্ষার নির্দেশিকা।
• NHS Digital Service Standard — NHS England: যে মানের বিপরীতে ভাগ করা ও সামঞ্জস্যপূর্ণ সেবা মূল্যায়িত হয়।
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative: অ্যাক্সেসিবিলিটি সামঞ্জস্যের মান।
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — যুক্তরাজ্য সরকার: সরকারি খাতের সেবার জন্য সংবিধিবদ্ধ অ্যাক্সেসিবিলিটি দায়িত্ব।
• DCB0129 / DCB0160 Clinical Risk Management মান — NHS England: স্বাস্থ্য IT সিস্টেমের উৎপাদন ও মোতায়েনের জন্য ক্লিনিক্যাল নিরাপত্তা মান।
• Design Council Double Diamond — Design Council: ডিসকভারি ও নকশার ভিত্তি আবিষ্কার–সংজ্ঞায়ন–বিকাশ–সরবরাহ মডেল।

তথ্যসূত্র#

1. Design system — Wikipedia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipedia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipedia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipedia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipedia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipedia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipedia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipedia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards