ইউজেবিলিটি টেস্টিং — একটি স্টাডি পরিকল্পনা ও পরিচালনা

১ · ইউজেবিলিটি টেস্টিং কী

ইউজেবিলিটি টেস্টিংUsability Testingসত্যিকারের ব্যবহারকারীদের একটি প্রোডাক্ট বা প্রোটোটাইপের সাথে নির্দিষ্ট টাস্ক করতে দিয়ে পর্যবেক্ষণ করার মাধ্যমে ডিজাইনের সমস্যা খুঁজে বের করা ও কার্যকারিতা মাপার একটি রিসার্চ মেথড। মানে ডিজাইনারের মতামত বা এক্সপার্টের অনুমানের উপর নির্ভর না করে — সত্যিকারের (বা সত্যিকারের মতো) ব্যবহারকারীদের একটি ডিজাইনের সাথে বাস্তব টাস্ক করতে দেওয়া এবং কোথায় তারা আটকে যায়, বিভ্রান্ত হয়, বা ভুল করে তা সরাসরি পর্যবেক্ষণ করা। এটি M6-এর লো/হাই-ফিডেলিটি প্রোটোটাইপের (L25–L27) সাথে সবচেয়ে ভালো কাজ করে — প্রোটোটাইপ থাকলে পরীক্ষা করার মতো কিছু থাকে।

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

২ · একটি স্টাডি পরিকল্পনা করা

একটি ভালো ইউজেবিলিটি স্টাডি পরিকল্পনায় তিনটি সিদ্ধান্ত অবশ্যই স্পষ্ট হতে হবে —

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

খ) পার্টিসিপ্যান্ট রিক্রুট করা: লক্ষ্য ব্যবহারকারীর প্রোফাইলের সাথে মেলে এমন মানুষ খুঁজতে হবে (M22-এর পার্সোনা থেকে গাইডেন্স নেওয়া যায়)। কতজন লাগবে তা নির্ভর করে উদ্দেশ্যের উপর — একটি সাধারণভাবে উদ্ধৃত নীলসেন নরম্যান গ্রুপের গাইডলাইন হলো, একটি নির্দিষ্ট ইউজার গ্রুপের জন্য প্রায় ৫ জন পার্টিসিপ্যান্ট দিয়েই বেশিরভাগ (প্রায় ৮৫%) বড় ইউজেবিলিটি সমস্যা খুঁজে পাওয়া যায় ফরমেটিভ, কোয়ালিটেটিভ টেস্টিংয়ে — তারপর প্রতিটি নতুন পার্টিসিপ্যান্ট ক্রমশ কম নতুন সমস্যা প্রকাশ করে। তবে এটি কোয়ান্টিটেটিভ পরিসংখ্যানগত তুলনার (যেমন L32-এর A/B টেস্ট বা L34-এর SUS গড়ের) জন্য প্রযোজ্য নয় — সেখানে অনেক বেশি পার্টিসিপ্যান্ট/স্যাম্পল লাগে পরিসংখ্যানগত নির্ভরযোগ্যতার জন্য।

গ) মেট্রিক্স বাছাই করা: শুরুতেই ঠিক করে নিতে হবে কী মাপা হবে — টাস্ক সফল হয়েছে কিনা (বাইনারি সফলতা/ব্যর্থতা), কত সময় লাগলো, কতবার ভুল হয়েছে, এবং সাবজেক্টিভ সন্তুষ্টি (যেমন SUS — বিস্তারিত L34-এ)। মেট্রিক্স আগে থেকে ঠিক না করলে পরে ফলাফল ব্যাখ্যা করা পক্ষপাতদুষ্ট হয়ে যেতে পারে।

৩ · স্টাডি পরিচালনা করা — মডারেটরের ভূমিকা

মডারেটরের কাজ হলো পার্টিসিপ্যান্টকে স্বাভাবিকভাবে ব্যর্থ বা সফল হতে দেওয়া — সাহায্য করা নয়। এটি স্বজ্ঞাগতভাবে কঠিন, কারণ মানুষের স্বাভাবিক প্রবৃত্তি হলো কষ্টে থাকা কাউকে সাহায্য করা। কিন্তু মডারেটর যদি ইঙ্গিত দিয়ে ফেলেন ("ওই বাটনটা ট্রাই করে দেখুন তো"), তাহলে ডেটা নষ্ট হয়ে যায় — কারণ বাস্তব ব্যবহারকারী পাশে কাউকে সাহায্য করতে পাবে না।

কিছু ব্যবহারিক নিয়ম —

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