ক্যাপস্টোন — একটি সম্পূর্ণ ইন্টারঅ্যাকটিভ সিস্টেম এন্ড-টু-এন্ড ডিজাইন, প্রোটোটাইপ ও ইভালুয়েশন
এই পাঠে যা শিখবেন
- কোর্সের একাধিক প্যাটার্নকে (ওয়েটেড হিউরিস্টিক স্কোরিং, WCAG কনট্রাস্ট, SUS, টাস্ক-সাকসেস পরিসংখ্যান) একটি সুসংগত, ধাপে-ধাপে মূল্যায়ন প্রক্রিয়ায় সংযুক্ত করা
- প্রকৃত SUS ফর্মুলা ও প্রকৃত WCAG কনট্রাস্ট ফর্মুলা ব্যবহার করে একটি ডিজাইনের ইউজেবিলিটি ও অ্যাক্সেসিবিলিটি সংখ্যাগতভাবে যাচাই করা
statisticsমডিউল দিয়ে একটি ছোট সিমুলেটেড ইউজেবিলিটি-সেশন ডেটাসেট থেকে সত্যিকারের টাস্ক-সাকসেস-রেট ও সময়ের পরিসংখ্যান বের করা- কীভাবে একটি চূড়ান্ত ডিপ্লয়মেন্ট-সুপারিশ সম্পূর্ণভাবে আগের ধাপগুলোর প্রকৃত গণনা করা প্রমাণ থেকে (হার্ডকোড না করে) তৈরি করা যায়, এমনকি যখন একটি একক সমস্যা ভালো গড় স্কোরকেও ছাপিয়ে যায়
১ · ক্যাপস্টোন পরিকল্পনা — মেডিরিমাইন্ড মূল্যায়ন
L56-এ আমরা মেডিরিমাইন্ড ডিজাইন করেছিলাম (সম্পূর্ণ কাল্পনিক ও ইলাস্ট্রেটিভ) — বয়স্ক রোগীদের জন্য একটি ওষুধ-রিমাইন্ডার অ্যাপ, যেখানে বড় থাম্ব-জোন "নিয়েছি" বাটন, ট্রাফিক-লাইট রঙ ম্যাপিং (সবুজ/লাল/নীল), আইকন-ভিত্তিক রিকগনিশন, ও কেয়ারগিভারের জন্য আলাদা নিয়ন্ত্রণ-স্তর রাখা হয়েছিল — সবকিছুই M3, M4, M5 ও M10-এর নীতির উপর ভিত্তি করে। কোর্স জুড়ে আমরা একটি একটি করে মূল্যায়ন-প্যাটার্ন শিখেছি — ওয়েটেড হিউরিস্টিক স্কোরিং (M4/L16, M5/L24), WCAG কনট্রাস্ট চেক (M10/L43, M8/L35), ও SUS/টাস্ক-সাকসেস মেট্রিক্স (M7/L34)। এই ক্যাপস্টোনে সেগুলো আলাদা আলাদা না রেখে একসাথে জোড়া লাগিয়ে একটি সম্পূর্ণ, প্রমাণ-ভিত্তিক মূল্যায়ন চালানো হবে — ঠিক একজন প্রকৃত HCI ডিজাইনার/রিসার্চার শিপ করার আগে যা করবেন।
২ · ধাপ ১ — ওয়েটেড হিউরিস্টিক ইভালুয়েশন স্কোর
প্রথম টুকরোটি M4/L16 ও M5/L24-এর ওয়েটেড-চেকলিস্ট প্যাটার্নে L56-এর ডিজাইন সিদ্ধান্তগুলোকে ৮টি আইটেমের একটি চেকলিস্টে রূপান্তরিত করে — প্রতিটির নিজস্ব ওজন (গুরুত্ব) ও প্রকৃত পাস/ফেল/আংশিক স্কোর সহ।
# ========== ধাপ ১: ওয়েটেড হিউরিস্টিক ইভালুয়েশন স্কোর ==========
checklist = [
{"name": "সিস্টেম স্ট্যাটাসের দৃশ্যমানতা (নিয়েছি/মিস করা/আসন্ন স্পষ্ট ব্যাজ)", "weight": 3, "score": 1.0},
{"name": "এরর প্রিভেনশন (মিস-মার্ক করার আগে কনফার্মেশন, আনডু আছে)", "weight": 3, "score": 1.0},
{"name": "রিকগনিশন, রিকল নয় (পিল-আইকন/ছবি, নাম মনে রাখতে হয় না)", "weight": 2, "score": 1.0},
{"name": "ফ্লেক্সিবিলিটি ও দক্ষতা (কেয়ারগিভার সেটআপ আছে, কিন্তু কাস্টমাইজেশন সীমিত)", "weight": 2, "score": 0.5},
{"name": "সিস্টেম ও বাস্তব জগতের মিল (সাধারণ ভাষা, পরিচিত আইকন)", "weight": 2, "score": 1.0},
{"name": "ব্যবহারকারীর নিয়ন্ত্রণ ও স্বাধীনতা (নিয়েছি/মিস করা মার্ক আনডু করা যায়)", "weight": 2, "score": 1.0},
{"name": "নান্দনিক ও মিনিমালিস্ট ডিজাইন (বড়, ফাঁকা, অগোছালো নয়)", "weight": 1, "score": 1.0},
{"name": "হেল্প ও ডকুমেন্টেশন (ইন-অ্যাপ হেল্প নেই, শুধু কেয়ারগিভার-সহায়তা)", "weight": 1, "score": 0.5},
]
total_weight = sum(item["weight"] for item in checklist)
weighted_sum = sum(item["weight"] * item["score"] for item in checklist)
checklist_pct = weighted_sum / total_weight * 100
for item in checklist:
print(f"[w={item['weight']}] {item['score']:.2f} {item['name']}")
print(f"\nমোট ওজন: {total_weight} | ওয়েটেড স্কোর: {weighted_sum:.2f} | চূড়ান্ত চেকলিস্ট স্কোর: {checklist_pct:.1f}%")
৩ · ধাপ ২ — WCAG কনট্রাস্ট-রেশিও চেক
দ্বিতীয় টুকরোটি M10/L43 ও M8/L35-এর প্যাটার্নে প্রকৃত WCAG রিলেটিভ-লুমিনেন্স ও কনট্রাস্ট-রেশিও ফর্মুলা ব্যবহার করে মেডিরিমাইন্ডের তিনটি UI রঙ-জোড়া (নেওয়া-হয়েছে ব্যাজ, মিস-করা ব্যাজ, ও একটি মিউটেড হেল্পার-টেক্সট) AA নরমাল-টেক্সট থ্রেশহোল্ড (৪.৫:১) এর বিপরীতে যাচাই করে — এটি বিশেষভাবে গুরুত্বপূর্ণ, কারণ L56-এ চিহ্নিত করা ব্যবহারকারী-গোষ্ঠীর (বয়স্ক, বয়সজনিত দৃষ্টি সমস্যাযুক্ত) জন্য কনট্রাস্ট একটি নিরাপত্তা-সংক্রান্ত প্রয়োজন, নিছক নান্দনিকতা নয়।
# ========== ধাপ ২: WCAG কনট্রাস্ট-রেশিও চেক ==========
def relative_luminance(rgb):
def channel(c):
c = c / 255
if c <= 0.03928:
return c / 12.92
return ((c + 0.055) / 1.055) ** 2.4
r, g, b = rgb
return 0.2126 * channel(r) + 0.7152 * channel(g) + 0.0722 * channel(b)
def contrast_ratio(rgb1, rgb2):
l1 = relative_luminance(rgb1)
l2 = relative_luminance(rgb2)
lighter, darker = max(l1, l2), min(l1, l2)
return (lighter + 0.05) / (darker + 0.05)
AA_NORMAL = 4.5
pairs = [
("'নিয়েছি' (Taken) ব্যাজ -- সাদা টেক্সট অন গাঢ় সবুজ", (255, 255, 255), (27, 94, 32)),
("'মিস করা' (Missed) ব্যাজ -- সাদা টেক্সট অন গাঢ় লাল", (255, 255, 255), (198, 40, 40)),
("মিউটেড হেল্পার টেক্সট -- হালকা ধূসর অন সাদা ব্যাকগ্রাউন্ড", (156, 163, 175), (255, 255, 255)),
]
results = []
for label, fg, bg in pairs:
ratio = contrast_ratio(fg, bg)
status = "PASS" if ratio >= AA_NORMAL else "FAIL"
results.append((label, ratio, status))
print(f"{label}\n contrast = {ratio:.2f}:1 (AA থ্রেশহোল্ড {AA_NORMAL}:1) -> {status}\n")
passed_pairs = sum(1 for _, _, s in results if s == "PASS")
total_pairs = len(results)
print(f"মোট {total_pairs}টি রঙ-জোড়ার মধ্যে {passed_pairs}টি AA পাস করেছে")
passed_pairs = 2, total_pairs = 3) —
ঠিক সেই ব্যবহারকারীদের জন্য যাদের দৃষ্টি ইতিমধ্যে দুর্বল, এই মিউটেড হেল্পার-টেক্সট একটি বাস্তব সমস্যা।
৪ · ধাপ ৩ — System Usability Scale (SUS) স্কোর
তৃতীয় টুকরোটি M7/L34-এর প্যাটার্নে একটি হাইপোথেটিক্যাল ইউজেবিলিটি টেস্টের ৬ জন বয়স্ক অংশগ্রহণকারীর ১০-আইটেম SUS প্রতিক্রিয়া (১-৫ Likert স্কেল) থেকে প্রকৃত SUS ফর্মুলা দিয়ে স্কোর গণনা করে — বিজোড় আইটেম (ইতিবাচক ভাষায় লেখা): স্কোর − ১; জোড় আইটেম (নেতিবাচক ভাষায় লেখা): ৫ − স্কোর; মোট যোগফল × ২.৫।
# ========== ধাপ ৩: System Usability Scale (SUS) স্কোর ==========
respondents = [
[5, 1, 4, 2, 5, 1, 4, 2, 5, 1], # রহিমা, ৬৮ -- অভিজ্ঞ ব্যবহারকারী, বড় বাটনে স্বচ্ছন্দ
[4, 2, 4, 1, 4, 2, 5, 1, 4, 2], # করিম, ৭২
[3, 2, 3, 3, 3, 2, 4, 2, 3, 3], # আনোয়ারা, ৭৫ -- হালকা দৃষ্টি সমস্যা
[4, 1, 5, 1, 4, 1, 4, 1, 5, 2], # সেলিনা, ৬৫ -- কেয়ারগিভার সহায়তায় শুরু করেছেন
[2, 4, 2, 3, 2, 3, 3, 4, 2, 4], # জব্বার, ৭৮ -- প্রথমবার স্মার্টফোন ব্যবহার করছেন, কষ্ট হয়েছে
[4, 2, 4, 2, 5, 1, 4, 2, 4, 1], # নাসিমা, ৭০
]
def sus_score(responses):
total = 0
for i, score in enumerate(responses):
item_num = i + 1
if item_num % 2 == 1: # বিজোড় আইটেম (ইতিবাচক ভাষায় লেখা): score - 1
total += (score - 1)
else: # জোড় আইটেম (নেতিবাচক ভাষায় লেখা): 5 - score
total += (5 - score)
return total * 2.5
sus_scores = [sus_score(r) for r in respondents]
names = ["রহিমা", "করিম", "আনোয়ারা", "সেলিনা", "জব্বার", "নাসিমা"]
for name, s in zip(names, sus_scores):
print(f"{name}: {s:.1f}")
avg_sus = sum(sus_scores) / len(sus_scores)
print(f"\nগড় SUS স্কোর (n={len(sus_scores)}): {avg_sus:.1f} (ইন্ডাস্ট্রি-গড় বেঞ্চমার্ক প্রায় ৬৮)")
৫ · ধাপ ৪ — টাস্ক সাকসেস রেট ও সময়ের পরিসংখ্যান
চতুর্থ টুকরোটি M7/L34-এর statistics-মডিউল প্যাটার্নে একই ৬ জন অংশগ্রহণকারীর একটি নির্দিষ্ট টাস্ক
— "আজকের সকালের ওষুধ 'নিয়েছি' হিসেবে চিহ্নিত করুন" — সম্পন্ন করার সময় ও সাফল্যের প্রকৃত ডেটা থেকে সাকসেস রেট ও
সময়ের পরিসংখ্যান গণনা করে।
# ========== ধাপ ৪: টাস্ক সাকসেস রেট ও সময়ের পরিসংখ্যান ==========
import statistics
# টাস্ক: "আজকের সকালের ওষুধ 'নিয়েছি' হিসেবে চিহ্নিত করুন" (একই ৬ জন অংশগ্রহণকারী)
sessions = [
{"name": "রহিমা", "success": True, "time_s": 6.2},
{"name": "করিম", "success": True, "time_s": 8.1},
{"name": "আনোয়ারা", "success": True, "time_s": 11.4},
{"name": "সেলিনা", "success": True, "time_s": 7.5},
{"name": "জব্বার", "success": False, "time_s": 42.0},
{"name": "নাসিমা", "success": True, "time_s": 9.8},
]
successes = [s for s in sessions if s["success"]]
n = len(sessions)
n_success = len(successes)
success_rate = n_success / n * 100
times_all = [s["time_s"] for s in sessions]
times_success = [s["time_s"] for s in successes]
mean_all = statistics.mean(times_all)
median_all = statistics.median(times_all)
mean_success = statistics.mean(times_success)
median_success = statistics.median(times_success)
stdev_success = statistics.stdev(times_success)
for s in sessions:
status = "সফল" if s["success"] else "ব্যর্থ"
print(f"{s['name']:8s} {status} time={s['time_s']:5.1f}s")
print(f"\nমোট অংশগ্রহণকারী: {n}, সফল: {n_success}")
print(f"টাস্ক সাকসেস রেট: {success_rate:.1f}%")
print(f"সব সেশনের গড় সময়: {mean_all:.1f}s, মধ্যক: {median_all:.1f}s")
print(f"শুধু সফল সেশনের গড় সময়: {mean_success:.1f}s, মধ্যক: {median_success:.1f}s, স্ট্যান্ডার্ড ডেভিয়েশন: {stdev_success:.2f}s")
৬ · ধাপ ৫ — চূড়ান্ত মূল্যায়ন সারাংশ ও সুপারিশ
শেষ টুকরোটি উপরের চারটি ধাপের প্রকৃত গণনা করা ফলাফল একত্র করে একটি একক, প্রমাণ-ভিত্তিক সুপারিশে পৌঁছায় — কোনো
হার্ডকোড করা উপসংহার নয়, বরং major_issues-এর একটি সাধারণ শর্ত-চেক থেকে বেরিয়ে আসে। যেহেতু
মেডিরিমাইন্ড একটি স্বাস্থ্য-সংক্রান্ত অ্যাপ, এখানে দুটি অতিরিক্ত-কঠোর শর্ত যোগ করা হয়েছে — WCAG কনট্রাস্ট ব্যর্থতা
এবং একটি উচ্চতর টাস্ক-সাকসেস থ্রেশহোল্ড (৮৫%, সাধারণ অ্যাপের চেয়ে বেশি, কারণ একটি মিস করা ডোজের বাস্তব
পরিণতি আছে) — সরাসরি মেজর ইস্যু হিসেবে গণনা করা হয়।
# ========== ধাপ ৫: চূড়ান্ত মূল্যায়ন সারাংশ ও সুপারিশ -- ধাপ ১-৪-এর প্রকৃত ফলাফল থেকে ==========
SUCCESS_THRESHOLD = 85.0 # স্বাস্থ্য-সংক্রান্ত অ্যাপের জন্য প্রত্যাশিত ন্যূনতম টাস্ক-সাকসেস মান
major_issues = [item["name"] for item in checklist if item["weight"] >= 3 and item["score"] < 1.0]
if passed_pairs < total_pairs:
major_issues.append(f"WCAG AA কনট্রাস্ট ({passed_pairs}/{total_pairs} পাস) -- মিউটেড হেল্পার টেক্সট ফেল করেছে")
if success_rate < SUCCESS_THRESHOLD:
major_issues.append(f"টাস্ক সাকসেস রেট {success_rate:.1f}% প্রত্যাশিত {SUCCESS_THRESHOLD:.0f}% থ্রেশহোল্ডের নিচে")
minor_issues = [item["name"] for item in checklist if item["weight"] < 3 and item["score"] < 1.0]
print("=" * 70)
print("চূড়ান্ত মূল্যায়ন সারাংশ -- মেডিরিমাইন্ড (হাইপোথেটিক্যাল)")
print("=" * 70)
print(f"১. ওয়েটেড হিউরিস্টিক চেকলিস্ট স্কোর: {checklist_pct:.1f}%")
print(f"২. WCAG AA কনট্রাস্ট: {passed_pairs}/{total_pairs} পেয়ার পাস")
print(f"৩. গড় SUS স্কোর: {avg_sus:.1f} / 100")
print(f"৪. টাস্ক সাকসেস রেট: {success_rate:.1f}% (সফল সেশনের গড় সময় {mean_success:.1f}s)")
print()
print(f"মেজর ইস্যু ({len(major_issues)}টি): {major_issues}")
print(f"মাইনর ইস্যু ({len(minor_issues)}টি): {minor_issues}")
if major_issues:
verdict = "মেজর রিভিশন দরকার"
elif checklist_pct >= 90:
verdict = "রেডি টু শিপ"
elif checklist_pct >= 75:
verdict = "মাইনর রিভিশন সহ শিপ করা যায়"
else:
verdict = "রিভিশন দরকার"
print(f"\nচূড়ান্ত সুপারিশ: {verdict}")
major_issues-এ ঠিক ২টি আইটেম পড়েছে — WCAG কনট্রাস্ট ব্যর্থতা ও ৮৫% থ্রেশহোল্ডের
নিচে থাকা টাস্ক-সাকসেস রেট — আর minor_issues-এ ২টি (ফ্লেক্সিবিলিটি ও হেল্প
ডকুমেন্টেশন)। যেহেতু major_issues খালি নয়, শর্ত-চেইনের প্রথম শাখাই সক্রিয় হয়, চেকলিস্ট স্কোর ৯০.৬%
"রেডি টু শিপ" সীমার (≥৯০%) মধ্যে থাকা সত্ত্বেও। চূড়ান্ত সুপারিশ: "মেজর রিভিশন দরকার"। এটি একটি
গুরুত্বপূর্ণ শিক্ষা: ডিজাইনের হিউরিস্টিক ভিত্তি শক্তিশালী (৯০.৬%) এবং গড় ব্যবহারকারী সন্তুষ্ট (SUS ৭২.৯,
বেশিরভাগ টাস্ক ৮.৬s-এ সম্পন্ন) — কিন্তু দুটি সুনির্দিষ্ট, ঝুঁকিপূর্ণ সমস্যা (একজন কম-দৃষ্টিসম্পন্ন
ব্যবহারকারীর জন্য অপর্যাপ্ত কনট্রাস্ট, এবং একজন প্রথমবার-ব্যবহারকারীর সম্পূর্ণ টাস্ক ব্যর্থতা) পুরো ডিজাইনকে
"রেডি টু শিপ" হওয়া থেকে আটকে দেয় — ঠিক যেমন এই কোর্সে বারবার দেখা গেছে, একটি ভালো গড় স্কোরও প্রান্তিক
ব্যবহারকারীর প্রকৃত ব্যর্থতাকে চাপা দিতে পারে না।
একটি বাস্তবসম্মত HCI মূল্যায়ন কখনোই একটি একক মেট্রিক নয় — এটি একাধিক স্বাধীন কিন্তু আন্তঃসংযুক্ত পরীক্ষার সমষ্টি: ডিজাইন নীতিগতভাবে হিউরিস্টিক্স মেনে চলছে কি না (M4), সবার জন্য দৃশ্যমান কি না (M8, M10), ব্যবহারকারীরা প্রকৃতপক্ষে এটি ব্যবহারযোগ্য মনে করেন কি না (M7), এবং তারা আসলেই টাস্ক সম্পন্ন করতে পারছেন কি না (M7) — আর এই সবকিছু একসাথে মিলিয়ে সামগ্রিক ছবিটা কেমন দাঁড়ায়। এই কোর্সে আমরা এই প্রতিটি লেন্স আলাদা আলাদা করে গভীরভাবে শিখেছি (M1-M13), আর এই শেষ পাঠে দেখলাম কীভাবে তারা একসাথে একটি বাস্তবসম্মত, প্রমাণ-ভিত্তিক মূল্যায়নে রূপ নেয়। Human-Computer Interaction কোনো একটি সূত্র বা একটি চেকবক্স নয় — এটি একটি অনুশীলন, যা এই কোর্স জুড়ে ধাপে ধাপে তৈরি করা টুল ও প্রশ্নগুলো দিয়ে প্রতিটি নতুন ইন্টারফেসের সাথে নতুন করে প্রয়োগ করতে হয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ ওয়েটেড হিউরিস্টিক স্কোর ৯০.৬% (যা সাধারণত "রেডি টু শিপ"-এর সীমা), তবুও চূড়ান্ত সুপারিশ "মেজর রিভিশন দরকার" হলো কেন?
কারণ চূড়ান্ত ধাপের কোডে major_issues অ-খালি থাকলে, সামগ্রিক পার্সেন্টেজ যত ভালোই হোক, সুপারিশ
সরাসরি "মেজর রিভিশন দরকার"-এ চলে যায় — এই শর্ত-চেইনটি ইচ্ছাকৃতভাবে এভাবে ডিজাইন করা, কারণ WCAG কনট্রাস্ট
ব্যর্থতা ও একটি সম্পূর্ণ টাস্ক-ব্যর্থতা উভয়ই এমন সমস্যা যা গড় স্কোরে চাপা পড়া উচিত নয় — এগুলো নির্দিষ্ট
ব্যবহারকারীদের জন্য অ্যাপটি আক্ষরিক অর্থে ব্যবহারযোগ্য নয় বলে প্রমাণ করে, নিছক "একটু কম চকচকে" নয়।
প্র ০২ ধাপ ৪-এ টাস্ক-সাকসেস থ্রেশহোল্ড ৮৫% বেছে নেওয়া হয়েছে, একটি সাধারণ অ্যাপে হয়তো ৭০% যথেষ্ট মনে হতো। এই উচ্চতর থ্রেশহোল্ডের পেছনে যুক্তি কী, এবং এটি কি নির্বিচারে বেছে নেওয়া?
থ্রেশহোল্ডটি নির্বিচারে নয়, কিন্তু এটি অবশ্যই একটি নীতিগত সিদ্ধান্ত (যা কোডে স্বচ্ছভাবে একটি নামকৃত
ভ্যারিয়েবল, SUCCESS_THRESHOLD, হিসেবে দেখানো হয়েছে, লুকানো ম্যাজিক-নাম্বার হিসেবে নয়)।
যুক্তিটি হলো — একটি বিনোদনমূলক অ্যাপে একজন ব্যবহারকারীর টাস্ক ব্যর্থ হলে বিরক্তি হয়, কিন্তু একটি ওষুধ-রিমাইন্ডার
অ্যাপে ব্যর্থতা মানে সম্ভাব্য একটি মিস করা ডোজ — তাই গ্রহণযোগ্য ব্যর্থতার হার অনেক কম হওয়া উচিত। এই ধরনের
থ্রেশহোল্ড কীভাবে নির্ধারিত হচ্ছে তা ডকুমেন্ট করা জরুরি, যাতে ভবিষ্যতে কেউ প্রশ্ন করতে ও পুনর্বিবেচনা করতে
পারেন।
প্র ০৩ জব্বার একাই ধাপ ৩ (সর্বনিম্ন SUS) ও ধাপ ৪ (একমাত্র ব্যর্থ টাস্ক) দুটোতেই সবচেয়ে খারাপ ফলাফল দিয়েছেন। এই দুই স্বাধীন পরিমাপের মিল কী প্রমাণ করে, আর কী প্রমাণ করে না?
এটি একটি শক্তিশালী সংকেত (দুটি ভিন্ন পরিমাপ পদ্ধতি একই ব্যবহারকারীর কষ্টের কথা বলছে) যে জব্বারের অভিজ্ঞতা দৈব-দুর্বিপাক নয়, বরং একটি প্রকৃত ব্যবহারযোগ্যতা-বাধা প্রতিফলিত করে — সম্ভবত প্রথমবার-স্মার্টফোন-ব্যবহারকারীদের জন্য অপর্যাপ্ত অনবোর্ডিং। কিন্তু এটি প্রমাণ করে না যে সমস্যাটি ঠিক কোথায় (বাটন খুঁজে পাননি? আইকন বুঝতে পারেননি? নাকি অন্য কিছু?) — এটি জানতে থিংক-অ্যালাউড প্রোটোকল (M7/L31)-এর মতো একটি গুণগত মেথড প্রয়োজন হবে, শুধু সংখ্যা যথেষ্ট নয়। n=1-এ একজন ব্যবহারকারীর ভিত্তিতে সাধারণীকরণ করাও ঝুঁকিপূর্ণ — বাস্তবে আরও বেশি প্রথমবার-ব্যবহারকারী নিয়ে পুনরায় পরীক্ষা করা প্রয়োজন হবে।
অনুশীলন
-
চিন্তা করুন: ধাপ ৫-এর কোড সেলে
SUCCESS_THRESHOLD = 85.0-কে80.0-এ পরিবর্তন করলে (টাস্ক সাকসেস রেট ৮৩.৩%, মনে রাখুন)major_issuesতালিকা, ও চূড়ান্ত সুপারিশ কীভাবে বদলাবে বলে আপনার ধারণা — তবে মনে রাখুন WCAG কনট্রাস্ট সমস্যাটি তখনও থেকে যাবে।যেহেতু ৮৩.৩% >= ৮০.০%, টাস্ক-সাকসেস সংক্রান্ত মেজর-ইস্যুটি আর যোগ হবে না —
major_issuesতালিকায় শুধু WCAG কনট্রাস্ট আইটেমটি থেকে যাবে (১টি, ২টি নয়)। কিন্তু যেহেতুmajor_issuesতখনও খালি নয় (এখনও ১টি আইটেম আছে), চূড়ান্ত সুপারিশ তখনও "মেজর রিভিশন দরকার"ই থাকবে — থ্রেশহোল্ড পরিবর্তনে শুধু ইস্যুর সংখ্যা কমবে, উপসংহার বদলাবে না, কারণ শর্তটি "যেকোনো একটি মেজর ইস্যু থাকলেই" সক্রিয় হয়। -
পরীক্ষা করুন: ধাপ ৫-এর কোড সেলে
SUCCESS_THRESHOLD80.0-এ পরিবর্তন করে আবার Run করে আপনার অনুমান যাচাই করুন। তারপর ধাপ ২-এর কোড সেলে "মিউটেড হেল্পার টেক্সট" পেয়ারের ব্যাকগ্রাউন্ড(255, 255, 255)-কে গাঢ় করে(0, 0, 0)(কালো) করে দুটি সেলই আবার Run করলে কী হয় দেখুন।প্রথম পরিবর্তনের পর ফলাফল নিশ্চিত করবে
major_issues-এ ১টি আইটেম ও সুপারিশ এখনও "মেজর রিভিশন দরকার"। দ্বিতীয় পরিবর্তনের পর (হালকা ধূসর টেক্সট অন কালো ব্যাকগ্রাউন্ড) কনট্রাস্ট অনেক বেড়ে যাবে ও PASS করবে, ফলেpassed_pairs = 3 = total_pairsহবে, ধাপ ৫ আবার Run করলেmajor_issuesসম্পূর্ণ খালি হয়ে যাবে এবং (checklist_pct=৯০.৬% যেহেতু ≥৯০%) চূড়ান্ত সুপারিশ বদলে "রেডি টু শিপ" হয়ে যাবে। এটি দেখায় কীভাবে একটি নির্দিষ্ট, ছোট ডিজাইন-ফিক্স (রঙ পরিবর্তন) সরাসরি চূড়ান্ত সিদ্ধান্তে প্রতিফলিত হয় — এটাই একটি প্রকৃত প্রমাণ-ভিত্তিক ডিজাইন প্রক্রিয়ার শক্তি।
কোর্স সম্পূর্ণ — অভিনন্দন!
- Human-Computer Interaction কোর্সের সম্পূর্ণ সিলেবাস পুনরায় দেখুন ৫৭টি পাঠ — সম্পূর্ণ M1 ফাউন্ডেশন থেকে M13 ক্যাপস্টোন পর্যন্ত — কগনিটিভ সাইকোলজি, ইন্টারঅ্যাকশন ডিজাইন, ইউজেবিলিটি হিউরিস্টিক্স, ইউজার রিসার্চ, প্রোটোটাইপিং, ইভালুয়েশন মেথড, ভিজ্যুয়াল ডিজাইন, ডিভাইস ও মোডালিটি, অ্যাক্সেসিবিলিটি, HCI-এর প্রয়োগ ও এই ক্যাপস্টোন — কোর্সের সবগুলো পাঠ এখন সম্পূর্ণ।
- Human-Centered AI কোর্স পরবর্তী কোর্স এই কোর্স শিখিয়েছে যেকোনো ইন্টারঅ্যাকটিভ সিস্টেমের সাধারণ ডিজাইন নীতি — Human-Centered AI কোর্স সেই একই ভিত্তির উপর AI-নির্দিষ্ট ট্রাস্ট ক্যালিব্রেশন, এক্সপ্লেইনেবিলিটি ও হিউম্যান-ইন-দ্য-লুপ ডিজাইনের গভীর কভারেজ যোগ করে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, Machine Learning, Deep Learning, System Design, Cybersecurity, Cloud Computing & DevOps, এবং আরও অনেক কোর্স — সব এক জায়গায়।