HCI-এর জন্য ইন্টারভিউ ও সার্ভে
এই পাঠে যা শিখবেন
- Structured, semi-structured ও unstructured ইন্টারভিউয়ের মধ্যে ফারাক বোঝা
- লিডিং প্রশ্ন চিহ্নিত করা ও নিরপেক্ষ প্রশ্নে রূপান্তর করতে পারা
- একটি বেসিক Likert-স্কেল সার্ভে আইটেম ডিজাইন করতে পারা
- একটি নির্দিষ্ট গবেষণা প্রশ্নের জন্য ইন্টারভিউ নাকি সার্ভে বেশি উপযুক্ত তা যুক্তিসহ ঠিক করতে পারা
১ · ইন্টারভিউ কৌশল — কতটা কাঠামোবদ্ধ রাখবেন
নির্দিষ্ট প্রশ্নের একটি নির্দিষ্ট ক্রম, প্রতিটি অংশগ্রহণকারীর কাছে হুবহু একই — তুলনা করা সহজ, কিন্তু গভীরতা কম।
একটি মূল প্রশ্নের সেট থাকে, কিন্তু আকর্ষণীয় উত্তরের পর ফলো-আপ প্রশ্ন করার স্বাধীনতা থাকে — HCI-তে সবচেয়ে বেশি ব্যবহৃত।
একটি বিস্তৃত বিষয় নিয়ে মুক্ত কথোপকথন, নির্দিষ্ট প্রশ্নের তালিকা ছাড়া — সবচেয়ে বেশি গভীরতা কিন্তু বিশ্লেষণ করা কঠিন ও সময়সাপেক্ষ।
যেকোনো ধরনের ইন্টারভিউয়েই ওপেন-এন্ডেড প্রশ্ন (যার উত্তর "হ্যাঁ/না" নয়) বেশি তথ্য দেয় — যেমন "আপনি কি এই ফিচারটা পছন্দ করেন?" এর বদলে "এই ফিচারটা ব্যবহার করার সময় আপনার অভিজ্ঞতা কেমন ছিল, একটু বলুন।" প্রথমটির উত্তর এক শব্দে শেষ হতে পারে; দ্বিতীয়টি ব্যাখ্যা, প্রসঙ্গ, ও অপ্রত্যাশিত তথ্য বের করে আনে।
২ · লিডিং প্রশ্ন এড়ানো
একটি লিডিং প্রশ্নLeading questionএমন প্রশ্ন যার গঠনই একটি নির্দিষ্ট উত্তরের দিকে ঠেলে দেয় — উত্তরদাতার প্রকৃত মতামত নয়, প্রশ্নকর্তার প্রত্যাশিত উত্তর প্রতিফলিত হয়। হলো এমন প্রশ্ন যার গঠনেই একটি পক্ষপাত লুকিয়ে থাকে। এটি প্রশ্নকর্তার অজান্তেই ঘটতে পারে — বিশেষ করে যখন প্রশ্নকর্তা নিজেই ডিজাইন টিমের অংশ এবং সাবকনশাসলি ইতিবাচক ফিডব্যাক চান।
| লিডিং (সমস্যাযুক্ত) | নিরপেক্ষ (ঠিক করা) |
|---|---|
| "আপনি কি নতুন ডিজাইনটা পছন্দ করেননি?" | "নতুন ডিজাইন সম্পর্কে আপনার মতামত কী?" |
| "বেশিরভাগ মানুষ এই ফিচারটা সহজ মনে করে, আপনার কী মনে হয়?" | "এই ফিচারটা ব্যবহার করা আপনার কাছে কেমন লাগল?" |
| "চেকআউট প্রসেসটা কতটা মসৃণ ছিল বলুন তো?" | "চেকআউট প্রসেসের সময় আপনার কী অভিজ্ঞতা হয়েছে?" |
৩ · সার্ভে ডিজাইন — Likert স্কেল ও প্রশ্নের গঠন
Likert স্কেল একটি সাধারণ ৫-পয়েন্ট (কখনো ৭-পয়েন্ট) স্কেল, যেখানে অংশগ্রহণকারী একটি বক্তব্যের সাথে কতটা সহমত/দ্বিমত তা বেছে নেন — "একেবারে দ্বিমত (১)" থেকে "একেবারে সহমত (৫)" (এই সাইটের System Usability Scale/SUS-এও এই একই ধরনের স্কেল ব্যবহৃত হয় — M7/L34-এ বিস্তারিত)। ভালো সার্ভে প্রশ্ন লেখার কয়েকটি নিয়ম:
"অ্যাপটি দ্রুত ও সহজ ছিল কি?" — এটি আসলে দুইটি প্রশ্ন একসাথে মিশিয়ে দেওয়া। দ্রুততা ও সহজতা আলাদা প্রশ্নে জিজ্ঞেস করুন।
"সবসময়" বা "কখনোই না" এর মতো শব্দ উত্তরদাতাকে দ্বিধায় ফেলে — "প্রায়ই" বা "মাঝে মাঝে" এর মতো নমনীয় বিকল্প ভালো।
নেতিবাচক ও ইতিবাচক অপশনের সংখ্যা সমান রাখুন, এবং মাঝে একটি নিরপেক্ষ অপশন রাখুন কিনা তা সচেতনভাবে ঠিক করুন।
গবেষণা প্রশ্ন যদি "কেন" বা "কীভাবে" হয় (যেমন "মানুষ কেন এই ফিচারটা ব্যবহার করেন না?") তাহলে ইন্টারভিউ ভালো — এটি ব্যাখ্যা ও প্রসঙ্গ দেয়। গবেষণা প্রশ্ন যদি "কত/কতজন/কোন শতাংশ" হয় (যেমন "কত শতাংশ ব্যবহারকারী এই ফিচারটা জানেন না?") তাহলে সার্ভে ভালো — এটি বড় নমুনা থেকে পরিমাপযোগ্য প্যাটার্ন দেয়। অনেক প্রজেক্টে দুটোই ব্যবহৃত হয় — প্রথমে কয়েকটি ইন্টারভিউ দিয়ে অনুমান তৈরি, তারপর সার্ভে দিয়ে সেই অনুমান বড় নমুনায় যাচাই।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ "আপনি কি আমাদের নতুন ফিচারটা পছন্দ করেননি?" — কেন এই প্রশ্নটি সমস্যাযুক্ত? কীভাবে ঠিক করবেন?
এটি দুইভাবে সমস্যাযুক্ত — (১) নেতিবাচক বাক্যগঠন ("করেননি") উত্তরদাতাকে বিভ্রান্ত করে এবং একটি নির্দিষ্ট (নেতিবাচক) উত্তরের দিকে ঠেলে দেয়, (২) এটি হ্যাঁ/না প্রশ্ন, ব্যাখ্যা পাওয়া যায় না। ঠিক করা যায় — "নতুন ফিচারটা সম্পর্কে আপনার মতামত কী? একটু বিস্তারিত বলুন।" — নিরপেক্ষ ও ওপেন-এন্ডেড, ফলে প্রকৃত অভিজ্ঞতা (ইতিবাচক বা নেতিবাচক যেটাই হোক) বের হয়ে আসে।
প্র ০২ একটি ৫-পয়েন্ট Likert স্কেল প্রশ্নে মাঝের নিরপেক্ষ অপশনটা বাদ দিয়ে ৪-পয়েন্ট "forced-choice" স্কেল ব্যবহার করলে কী প্রভাব পড়তে পারে?
নিরপেক্ষ অপশন ছাড়া অংশগ্রহণকারীকে বাধ্য হয়ে একদিকে (সহমত বা দ্বিমত) ঝুঁকতে হয়, এমনকি তাদের প্রকৃত অনুভূতি সত্যিকারভাবে নিরপেক্ষ হলেও। এতে ডেটা "পোলারাইজড" দেখাতে পারে যা বাস্তবতাকে সঠিকভাবে প্রতিফলিত করে না। কিছু গবেষক ইচ্ছাকৃতভাবে এটি করেন যখন তারা মনে করেন উত্তরদাতারা নিরপেক্ষ অপশনে "পালিয়ে" যাওয়ার প্রবণতা দেখান (সত্যিকারের মতামত থাকা সত্ত্বেও) — কিন্তু এটি একটি সচেতন ট্রেড-অফ, দুর্ঘটনাক্রমে নয়।
প্র ০৩ কখন সার্ভে যথেষ্ট নয় এবং ইন্টারভিউ প্রয়োজন হয়ে পড়ে?
যখন আপনি এখনো জানেন না কী প্রশ্ন করা উচিত — অর্থাৎ সমস্যাটির পরিসর এখনো স্পষ্ট নয় — তখন সার্ভে বিপজ্জনক, কারণ সার্ভে শুধু আগে থেকে ঠিক করা অপশনগুলোর মধ্যে উত্তর মাপে; অপ্রত্যাশিত সমস্যা ধরতে পারে না। এছাড়া যখন সংখ্যার পেছনের "কেন" জানা জরুরি (যেমন সার্ভেতে দেখা গেল ৪০% ব্যবহারকারী একটি ফিচার ব্যবহার করেন না, কিন্তু কেন করেন না তা সার্ভে বলবে না) তখন ফলো-আপ ইন্টারভিউ প্রয়োজন।
অনুশীলন
-
রিরাইট করুন: নিচের তিনটি লিডিং/পক্ষপাতদুষ্ট সার্ভে প্রশ্ন নিরপেক্ষভাবে পুনর্লিখন করুন —
(ক) "আমাদের চমৎকার নতুন নেভিগেশন মেনু আপনার কতটা পছন্দ হয়েছে?" (খ) "আপনি কি স্বীকার করেন যে পুরনো
ডিজাইনটা বিভ্রান্তিকর ছিল?" (গ) "এই দ্রুত ও সহজ চেকআউট প্রসেস ব্যবহার করতে কেমন লাগল?"
(ক) "নতুন নেভিগেশন মেনু সম্পর্কে আপনার মতামত কী?" — "চমৎকার" শব্দটি বাদ, যা একটি ইতিবাচক উত্তরের দিকে ঠেলে দিচ্ছিল। (খ) "পুরনো ডিজাইন ব্যবহার করার সময় আপনার কী অভিজ্ঞতা হয়েছিল?" — "স্বীকার করেন" শব্দটি একটি প্রত্যাশিত (নেতিবাচক) উত্তর ধরে নিয়েছিল। (গ) "চেকআউট প্রসেসটা ব্যবহার করতে কেমন লেগেছে?" — "দ্রুত ও সহজ" এই বর্ণনামূলক শব্দগুলো বাদ, যা প্রশ্নের মধ্যেই একটি রায় বসিয়ে দিয়েছিল (এবং এটি double-barreled-ও ছিল — দ্রুততা ও সহজতা দুটো আলাদা মাত্রা)।
-
ডিজাইন করুন: একটি অনলাইন গ্রন্থাগার অ্যাপ (library app) নিয়ে সেমি-স্ট্রাকচার্ড
ইন্টারভিউয়ের জন্য ৫টি প্রশ্নের একটি গাইড লিখুন, যা "মানুষ কীভাবে বই খুঁজে বের করেন" তা বোঝার লক্ষ্যে
ডিজাইন করা।
(১) "সবশেষ কবে আপনি এই অ্যাপে একটা বই খুঁজেছিলেন — একটু বর্ণনা করুন কী হয়েছিল।" (২) "আপনি সাধারণত বই খোঁজার সময় কোন পথে যান — সার্চ বক্স, ক্যাটাগরি ব্রাউজিং, নাকি অন্য কিছু?" (৩) "কখনো এমন হয়েছে যে আপনি যে বইটা খুঁজছিলেন সেটা খুঁজে পাননি? তখন কী করেছিলেন?" (৪) "কোন পরিস্থিতিতে আপনি অ্যাপের বাইরে গিয়ে (যেমন গুগল সার্চ) বই খোঁজেন?" (৫) "যদি একটা জিনিস বদলাতে পারতেন বই খোঁজার প্রক্রিয়ায়, সেটা কী হতো?" — প্রতিটি প্রশ্ন ওপেন-এন্ডেড ও নির্দিষ্ট ঘটনার উপর ভিত্তি করে, যাতে say-do gap কম হয় (M20-এর ধারণা মনে করুন)।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ M7/L34-এ System Usability Scale (SUS)-এর বাস্তব গণনা দেখুন — Likert-স্কেল সার্ভে ডেটা থেকে একটি প্রকৃত ইউজেবিলিটি স্কোর তৈরি করা।
- পরবর্তী পাঠ — পার্সোনা ও ইউজার জার্নি ম্যাপ L22 ইন্টারভিউ ও সার্ভে থেকে পাওয়া তথ্য কীভাবে ব্যবহারযোগ্য ডিজাইন আর্টিফ্যাক্টে রূপান্তরিত করবেন।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, Machine Learning, Deep Learning, System Design, Cybersecurity, Cloud Computing & DevOps, এবং আরও অনেক কোর্স — সব এক জায়গায়।