টাস্ক অ্যানালাইসিস ও হায়ারার্কিক্যাল টাস্ক অ্যানালাইসিস
এই পাঠে যা শিখবেন
- টাস্ক অ্যানালাইসিস ও Hierarchical Task Analysis (HTA)-এর সংজ্ঞা ও কাঠামো বোঝা
- KLM/GOMS মডেলের চারটি মূল অপারেটর (K, P, H, M) ও তাদের স্ট্যান্ডার্ড সময় জানা
- একটি লক্ষ্যকে অপারেটর-সিকোয়েন্সে ভাঙতে পারা
- দুটি ভিন্ন ইন্টারঅ্যাকশন ডিজাইনের প্রেডিক্টেড সময় গণনা করে তুলনা করতে পারা
১ · Task Analysis ও Hierarchical Task Analysis (HTA)
টাস্ক অ্যানালাইসিস হলো একটি ব্যবহারকারীর লক্ষ্য অর্জনের জন্য ঠিক কী কী পদক্ষেপ প্রয়োজন তা পদ্ধতিগতভাবে ভাঙা। Hierarchical Task Analysis (HTA) এই পদ্ধতির সবচেয়ে প্রতিষ্ঠিত রূপ — একটি মূল লক্ষ্য (০) কে কয়েকটি সাব-টাস্কে (১, ২, ৩...) ভাঙা হয়, প্রতিটি সাব-টাস্ক আবার আরও ছোট ধাপে (১.১, ১.২...) ভাঙা যায়, যতক্ষণ না প্রতিটি ধাপ যথেষ্ট নির্দিষ্ট হয়ে যায়। প্রয়োজনে একটি "প্ল্যান" যোগ করা হয় যা বলে দেয় সাব-টাস্কগুলো কোন ক্রমে বা কোন শর্তে করতে হবে (যেমন "প্ল্যান ০: ১ করুন, তারপর ২ করুন, যদি ব্যর্থ হয় তাহলে ৩ করুন")।
উদাহরণ — "একটি ইমেইল ডিলিট করা" লক্ষ্যের একটি সরল HTA:
মূল লক্ষ্য
ব্যবহারকারী সিদ্ধান্ত নেন এই ইমেইলটি অপ্রয়োজনীয়
ইনবক্স লিস্টে সঠিক ইমেইলটি খুঁজে ক্লিক করা
এখানেই ডিজাইনের পথ ভিন্ন হতে পারে — টুলবার আইকন বা কনটেক্সট মেনু (নিচের ডেমো দেখুন)
২ · KLM/GOMS — অপারেটর দিয়ে সময় প্রেডিক্ট করা
HTA শুধু ধাপগুলো দেখায়, কিন্তু Keystroke-Level Model (KLM) — GOMS (Goals, Operators, Methods, Selection rules) পরিবারের একটি সরলীকৃত মডেল — প্রতিটি ধাপকে একটি স্ট্যান্ডার্ড "অপারেটর"-এ ম্যাপ করে এবং প্রতিটির একটি সুপরিচিত, টেক্সটবুক-স্বীকৃত গড় সময় থাকে:
| অপারেটর | অর্থ | সময় |
|---|---|---|
| K | Keystroke — একটি কী চাপা | 0.28s |
| P | Pointing — মাউস দিয়ে টার্গেটে পৌঁছে ক্লিক করা | 1.10s |
| H | Homing — কীবোর্ড ও মাউসের মধ্যে হাত সরানো | 0.40s |
| M | Mental preparation — পরবর্তী পদক্ষেপ কী হবে তা চিন্তা করা | 1.35s |
একটি পুরো টাস্ককে অপারেটরের একটি সিকোয়েন্স হিসেবে লিখে, প্রতিটির সময় যোগ করলে সেই টাস্কের প্রেডিক্টেড মোট সময় (predicted execution time) পাওয়া যায় — এটিই দুটি ভিন্ন ডিজাইনের তুলনা করার একটি দ্রুত, সংখ্যাভিত্তিক পদ্ধতি, ব্যবহারকারী পরীক্ষা ছাড়াই একটি প্রাথমিক অনুমান দেয়।
৩ · সত্যিকারের ডেমো — দুটি ডিজাইনের তুলনা
একই লক্ষ্য — "ইনবক্সে একটি ইমেইল ডিলিট করা" — অর্জনের দুটি ভিন্ন উপায় বিবেচনা করা যাক। রুট A — টুলবার আইকন: ইমেইল সিলেক্ট করে টুলবারের ডিলিট আইকনে ক্লিক করা। রুট B — রাইট-ক্লিক কনটেক্সট মেনু: ইমেইলে রাইট-ক্লিক করে মেনু থেকে "Delete" খুঁজে ক্লিক করে, তারপর একটি কনফার্মেশন ডায়ালগে "Yes" ক্লিক করা — এই রুটে দুটি অতিরিক্ত ধাপ আছে (মেনু স্ক্যান করা ও কনফার্মেশন)। নিচের কোড সেলে প্রতিটি রুটকে অপারেটর-সিকোয়েন্স হিসেবে লিখে প্রকৃত KLM সময় গণনা করা হয়েছে।
K = 0.28 # keystroke
P = 1.10 # pointing (মাউস মুভ + ক্লিক)
H = 0.40 # homing (কীবোর্ড-মাউস হাত পরিবর্তন)
M = 1.35 # mental preparation
OP_TIME = {"K": K, "P": P, "H": H, "M": M}
# রুট A -- টুলবার ডিলিট-আইকন
# 1. M -- সিদ্ধান্ত নেওয়া যে এই ইমেইলটি ডিলিট করতে হবে
# 2. P -- ইমেইল রো-তে ক্লিক করে সিলেক্ট করা
# 3. M -- টুলবারে ডিলিট আইকনের অবস্থান মনে করা
# 4. P -- ডিলিট আইকনে ক্লিক করা
toolbar_route = ["M", "P", "M", "P"]
# রুট B -- রাইট-ক্লিক কনটেক্সট মেনু (রুট A-এর চেয়ে ২টি অতিরিক্ত ধাপ)
# 1. M -- সিদ্ধান্ত নেওয়া যে এই ইমেইলটি ডিলিট করতে হবে
# 2. P -- ইমেইল রো-তে রাইট-ক্লিক করা (কনটেক্সট মেনু খোলে)
# 3. M -- মেনুর ভেতর "Delete" অপশনটি চোখ দিয়ে খুঁজে বের করা
# 4. P -- "Delete" অপশনে ক্লিক করা
# 5. M -- কনফার্মেশন ডায়ালগ আশা করা ও তা পড়া
# 6. P -- কনফার্মেশন ডায়ালগে "Yes"-এ ক্লিক করা
context_menu_route = ["M", "P", "M", "P", "M", "P"]
def klm_total(ops):
return sum(OP_TIME[op] for op in ops)
for label, ops in [("টুলবার আইকন রুট (A)", toolbar_route),
("রাইট-ক্লিক কনটেক্সট মেনু রুট (B)", context_menu_route)]:
total = klm_total(ops)
breakdown = " + ".join(f"{op}({OP_TIME[op]:.2f})" for op in ops)
print(f"{label}: {breakdown} = {total:.2f}s ({len(ops)}টি অপারেটর)")
diff = klm_total(context_menu_route) - klm_total(toolbar_route)
pct = (diff / klm_total(toolbar_route)) * 100
print(f"\nপার্থক্য: {diff:.2f}s ({pct:.1f}% বেশি সময় লাগে রুট B-তে)")KLM/GOMS একটি নিখুঁত পূর্বাভাস নয় — এটি একটি আপেক্ষিক তুলনার টুল, যা ব্যবহারকারী পরীক্ষা চালানোর আগেই দুটি ডিজাইনের মধ্যে কোনটি কাঠামোগতভাবে দ্রুত তা প্রাথমিকভাবে অনুমান করতে সাহায্য করে। এটি M4-এর ইউজেবিলিটি হিউরিস্টিক্সের সাথে ঘনিষ্ঠভাবে সম্পর্কিত — কম ধাপ, কম মানসিক প্রস্তুতি সাধারণত ভালো "efficiency of use" (Nielsen-এর হিউরিস্টিক #৭) নির্দেশ করে। চূড়ান্ত সিদ্ধান্তের আগে M7-এ শেখা প্রকৃত ব্যবহারকারী পরীক্ষা দিয়ে এই অনুমান যাচাই করা উচিত।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ উপরের ডেমোতে যদি রুট A-তে একটি "M" অপারেটর কমিয়ে দেওয়া যায় (যেমন ডিলিট আইকনের অবস্থান এতটাই পরিচিত হয়ে যায় যে আলাদা মনে করার দরকার পড়ে না), তাহলে মোট সময় কেমন বদলাবে?
একটি M (1.35s) বাদ দিলে রুট A হবে শুধু P+M+P = ৩টি অপারেটর = ৩.৫৫ সেকেন্ড — অর্থাৎ রুট B (৭.৩৫s)-এর তুলনায় পার্থক্য আরও বেড়ে যাবে। এটি একটি বাস্তব ঘটনার প্রতিফলন — বারবার ব্যবহারের ফলে কিছু মানসিক প্রস্তুতি "অটোমেটিক" হয়ে যায় (অভ্যাস তৈরি হয়), যা অভিজ্ঞ ব্যবহারকারীদের জন্য প্রেডিক্টেড সময় আরও কমিয়ে দেয়।
প্র ০২ KLM/GOMS মডেল মূলত রুটিন, পূর্বাভাসযোগ্য টাস্কের জন্য ভালো কাজ করে। এটি কোন ধরনের টাস্কে ভালো কাজ নাও করতে পারে?
এটি এক্সপ্লোরেটরি টাস্কে (যেমন "একটি নতুন সফটওয়্যারে প্রথমবার একটি ফিচার খুঁজে বের করা", যেখানে ব্যবহারকারী জানেন না ঠিক কোন ধাপগুলো লাগবে) ভালো কাজ করে না — কারণ KLM ধরে নেয় ব্যবহারকারী ইতিমধ্যে সঠিক পদ্ধতি জানেন এবং শুধু তা বাস্তবায়ন করছেন (error-free execution)। ভুল করা, ঘুরে বেড়ানো, বা শেখার প্রক্রিয়া KLM-এর মডেলে ধরা পড়ে না — এর জন্য অন্য মূল্যায়ন পদ্ধতি (M7-এ think-aloud, cognitive walkthrough) দরকার।
প্র ০৩ উপরের ডেমোতে রুট B-তে "কনফার্মেশন ডায়ালগ" রাখা হয়েছে যা একটি ভুলবশত ডিলিট প্রতিরোধ করে (M19-এর error prevention মনে করুন)। এটি কি রুট B-কে "খারাপ ডিজাইন" বানিয়ে দেয়, নাকি এটি একটি সচেতন ট্রেড-অফ?
এটি একটি সচেতন ট্রেড-অফ — গতি (efficiency) বনাম নিরাপত্তা (error prevention)। যদি "ডিলিট" একটি বিপজ্জনক, ফেরত না-পাওয়া অ্যাকশন হয়, তাহলে অতিরিক্ত সময় একটি ভুল রোধ করার জন্য একটি যুক্তিসঙ্গত মূল্য। কিন্তু যদি একটি "আনডু" অপশন থাকে (M19-এ আলোচিত), তাহলে কনফার্মেশন ডায়ালগ ছাড়াই দ্রুত ডিলিট করে, ভুল হলে আনডু দিয়ে ঠিক করা — এটি গতি ও নিরাপত্তা দুটোই দিতে পারে, KLM সময়ও কমিয়ে দেয়।
অনুশীলন
-
চিন্তা করুন: যদি রুট B থেকে কনফার্মেশন ডায়ালগ ধাপটি (M + P, শেষ দুটি অপারেটর) সরিয়ে
ফেলা হয় — তাহলে রুট B-এর মোট সময় কত হবে বলে আপনার ধারণা, এবং এটি কি তখনও রুট A-এর চেয়ে ধীর থাকবে?
কনফার্মেশন ধাপ (M+P = ২.৪৫s) সরালে রুট B হবে M+P+M+P = ৪.৯০s — এবং এটি তখন রুট A-এর সমান হবে (দুটোই M+P+M+P, ৪টি অপারেটর)! এটি দেখায় কেন কনফার্মেশন ডায়ালগটাই আসলে পুরো ২.৪৫ সেকেন্ড পার্থক্যের জন্য দায়ী — মেনু-স্ক্যান করাটা নিজে থেকে বাড়তি সময় যোগ করে না যদি সেটাই একমাত্র অতিরিক্ত ধাপ হতো।
-
পরীক্ষা করুন: উপরের কোড সেলে
context_menu_routeথেকে শেষ দুটি অপারেটর ("M", "P") সরিয়ে (অর্থাৎ["M", "P", "M", "P"]করে) Run চেপে আপনার অনুমান যাচাই করুন।সরানোর পর রুট B হবে M(1.35)+P(1.10)+M(1.35)+P(1.10) = ৪.৯০s — ঠিক যেমন অনুমান করা হয়েছিল, এবং এটি রুট A-এর ৪.৯০s-এর সাথে হুবহু মিলে যায়। এটি নিশ্চিত করে যে কনফার্মেশন ডায়ালগ ধাপটিই ছিল পুরো পার্থক্যের একমাত্র উৎস, এবং KLM গণনা নির্ভরযোগ্যভাবে দেখায় ঠিক কোন নির্দিষ্ট ধাপ ডিজাইনকে ধীর করে দিচ্ছে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ M7/L34-এ আরও পরিমাপ-ভিত্তিক ইউজেবিলিটি মেট্রিক্স (SUS, task success rate) দেখুন।
- পরবর্তী পাঠ — কম্পিটিটিভ অ্যানালাইসিস ও হিউরিস্টিক ইভালুয়েশন L24 টাস্ক অ্যানালাইসিসের পর — একটি ডিজাইনকে এক্সপার্ট রিভিউ ও প্রতিযোগীদের সাথে তুলনা করে মূল্যায়ন করার পদ্ধতি।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, Machine Learning, Deep Learning, System Design, Cybersecurity, Cloud Computing & DevOps, এবং আরও অনেক কোর্স — সব এক জায়গায়।