লো-ফিডেলিটি প্রোটোটাইপিং — স্কেচ ও পেপার প্রোটোটাইপ
এই পাঠে যা শিখবেন
- লো-ফিডেলিটি প্রোটোটাইপ কী এবং এটি কোন কোন রূপে (স্কেচ, পেপার প্রোটোটাইপ) আসে
- কেন ডিজাইনাররা ইচ্ছাকৃতভাবে প্রথমে "রুক্ষ" থাকতে বেছে নেন — গতি, খরচ, এবং সৎ ফিডব্যাক
- কীভাবে একটি পেপার প্রোটোটাইপ টেস্ট পরিচালনা করবেন
- লো-ফিডেলিটির সীমাবদ্ধতা এবং কখন এটি যথেষ্ট নয় (L27-এ হাই-ফিডেলিটির প্রিভিউ)
১ · লো-ফিডেলিটি প্রোটোটাইপ কী
লো-ফিডেলিটি প্রোটোটাইপLow-Fidelity Prototypeএকটি ডিজাইন ধারণার দ্রুত, সস্তা, ইচ্ছাকৃতভাবে অসম্পূর্ণ প্রতিনিধিত্ব — হাতে আঁকা স্কেচ বা কাগজে তৈরি স্ক্রিন, যা রঙ, ফন্ট, ছবি বা বাস্তব ইন্টারঅ্যাকশন ছাড়াই শুধু কাঠামো ও ফ্লো দেখায়। মানে একটি ডিজাইন ধারণাকে সবচেয়ে কম সময়ে, সবচেয়ে কম বিনিয়োগে বাস্তব রূপ দেওয়া — সাধারণত কাগজে পেন্সিল দিয়ে আঁকা স্ক্রিন-স্কেচ, স্টিকি নোট, বা হোয়াইটবোর্ডে আঁকা ফ্লো-চার্ট আকারে। লক্ষ্য সৌন্দর্য নয় — লক্ষ্য হলো একটি ধারণা কাজ করে কি না তা দ্রুত যাচাই করা।
পেপার প্রোটোটাইপিং এর একটি নির্দিষ্ট, ব্যাপকভাবে ব্যবহৃত কৌশল — প্রতিটি স্ক্রিনকে আলাদা কাগজে আঁকা হয় (বাটন, মেনু, পপ-আপ আলাদা কাগজের টুকরা হিসেবে কাটা থাকতে পারে), এবং একজন গবেষক "কম্পিউটারের" ভূমিকা পালন করেন — অংশগ্রহণকারী যখন কাগজে কোনো বাটনে "ক্লিক" করেন (আঙুল দিয়ে ছুঁয়ে), গবেষক হাতে করে পরের স্ক্রিনের কাগজটি সামনে বসিয়ে দেন।
২ · কেন ইচ্ছাকৃতভাবে "রুক্ষ" রাখা হয়
নতুন ডিজাইনাররা প্রায়ই ভাবেন প্রথম প্রোটোটাইপটাও যতটা সম্ভব ভালো দেখানো উচিত। কিন্তু HCI-এর প্রতিষ্ঠিত অভ্যাস উল্টো — লো ফিডেলিটি একটি সচেতন কৌশলগত সিদ্ধান্ত, তিনটি কারণে:
একটি স্কেচ কয়েক মিনিটে আঁকা যায় এবং বাতিল করা যায় কোনো আফসোস ছাড়াই। কোড বা পলিশড ডিজাইনে একই আইডিয়া টেস্ট করতে ঘণ্টার পর ঘণ্টা লাগতো।
একটি রুক্ষ স্কেচ দেখলে মানুষ মনে করে "এটা এখনো তৈরি হচ্ছে" — তাই কাঠামোগত সমস্যা নিয়ে খোলাখুলি সমালোচনা করে। একটি পলিশড মকআপ দেখলে প্রায়ই শুধু রঙ বা ফন্ট নিয়ে মন্তব্য আসে, মূল ফ্লো নিয়ে নয়।
একটি সুন্দর করে বানানো ডিজাইনে যত বেশি সময়/শ্রম যায়, দলের পক্ষে সেই দিক ছেড়ে অন্য দিকে যাওয়া তত কঠিন হয়ে যায় (sunk-cost প্রভাব) — লো-ফিডেলিটি এই ফাঁদ এড়ায়।
৩ · একটি পেপার প্রোটোটাইপ টেস্ট কীভাবে পরিচালনা করবেন
একটি কার্যকর পেপার প্রোটোটাইপ সেশনে সাধারণত থাকে:
- একটি বাস্তব টাস্ক — অংশগ্রহণকারীকে বলা হয় "একটি নতুন প্রোডাক্ট খুঁজে কার্টে যোগ করুন", নির্দিষ্ট স্ক্রিন দেখতে বলা হয় না — যাতে তারা নিজের মতো নেভিগেট করার চেষ্টা করেন।
- একজন "কম্পিউটার" গবেষক — যিনি শুধু অংশগ্রহণকারীর ইনপুট অনুযায়ী কাগজ বদলান, নিজের মতামত বা সাহায্য যোগ করেন না (M31-এর থিংক-অ্যালাউড প্রোটোকলের সাথে একসাথে ব্যবহার করা যায়)।
- একজন পর্যবেক্ষক — যিনি অংশগ্রহণকারী কোথায় থামলেন, কোথায় ভুল বাটনে হাত দিলেন, বা কোথায় বিভ্রান্ত হলেন তা নোট করেন — এগুলোই সবচেয়ে মূল্যবান তথ্য।
- দ্রুত পুনরাবৃত্তি — একটি সমস্যা ধরা পড়লে পরের অংশগ্রহণকারীর আগেই কাগজ কেটে/এঁকে বদলে ফেলা যায়, একদিনে একাধিকবার ইটারেট করা সম্ভব।
লো-ফিডেলিটি প্রোটোটাইপিং মূলত M5-এর ইউজার রিসার্চের ধারাবাহিকতা — কনটেক্সচুয়াল ইনকোয়ারি (L20), ইন্টারভিউ (L21), এবং টাস্ক অ্যানালাইসিস (L23) থেকে যা শেখা গেছে, তার ভিত্তিতে তৈরি প্রথম ডিজাইন ধারণাকে দ্রুত বাস্তব ব্যবহারকারীর সামনে যাচাই করার সবচেয়ে সস্তা উপায়।
৪ · লো-ফিডেলিটির সীমাবদ্ধতা
লো-ফিডেলিটি প্রোটোটাইপ সবকিছুর উত্তর দেয় না। এটি ভালো কাজ করে কাঠামো, ফ্লো ও তথ্য-সংগঠন টেস্ট করতে (L26-এ ইনফরমেশন আর্কিটেকচার), কিন্তু এটি বলতে পারে না:
- একটি রঙের কম্বিনেশন পড়তে কতটা সহজ বা কষ্টকর (M8-এর ভিজ্যুয়াল ডিজাইন, M10-এর কনট্রাস্ট রেশিও)
- একটি অ্যানিমেশন বা মাইক্রো-ইন্টারঅ্যাকশন কেমন "অনুভূত" হবে
- বাস্তব লোডিং টাইম বা রেসপন্সিভনেসের প্রভাব ব্যবহারকারীর অভিজ্ঞতায়
এই প্রশ্নগুলোর জন্য প্রয়োজন উচ্চতর ফিডেলিটি — সেটাই L27-এর বিষয়: হাই-ফিডেলিটি প্রোটোটাইপিং।
লো-ফিডেলিটি প্রোটোটাইপিং মানে "অলস কাজ" নয় — এটি একটি সচেতন কৌশল যা দ্রুত, সস্তা ইটারেশন এবং সৎ ফিডব্যাক নিশ্চিত করে, ঠিক যে মুহূর্তে ধারণাগুলো এখনো বদলানো সহজ। ফিডেলিটি ধীরে ধীরে বাড়ানোই এই মডিউলের মূল থিম — স্কেচ থেকে ওয়্যারফ্রেম (L26), ওয়্যারফ্রেম থেকে হাই-ফিডেলিটি প্রোটোটাইপ (L27) পর্যন্ত।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একজন স্টেকহোল্ডার বলছেন, "আমি একটা রুক্ষ কাগজের স্কেচ দেখে বুঝব কীভাবে? আমাকে একটা রঙিন, পলিশড ডিজাইন দেখান।" আপনি কীভাবে যুক্তি দিয়ে বোঝাবেন কেন প্রথমে লো-ফিডেলিটিতেই যাওয়া ভালো?
ব্যাখ্যা করা যেতে পারে — এই পর্যায়ে প্রশ্নটি হলো "ফ্লো ও কাঠামো কি সঠিক?", রঙ বা ফন্ট নয়। যদি একটি পলিশড ডিজাইন আগে দেখানো হয়, স্টেকহোল্ডার/ব্যবহারকারী পৃষ্ঠতলীয় বিষয়ে (রঙ পছন্দ কি না) আটকে যাবেন, এবং যদি কাঠামোতেই বড় সমস্যা থাকে, সেটি অনেক পরে, অনেক বেশি খরচে ধরা পড়বে। লো-ফিডেলিটি সেই ঝুঁকি কমায়।
প্র ০২ পেপার প্রোটোটাইপ টেস্টে "কম্পিউটার"-এর ভূমিকা পালনকারী গবেষক যদি অংশগ্রহণকারীকে ইঙ্গিত দিয়ে সাহায্য করেন (যেমন "না, ওদিকে না, এই বাটনটা চেষ্টা করুন"), তাহলে ফলাফলে কী সমস্যা হবে?
ফলাফল বিকৃত হয়ে যাবে — টেস্টের আসল উদ্দেশ্য হলো ব্যবহারকারী নিজে থেকে কীভাবে নেভিগেট করেন তা পর্যবেক্ষণ করা। ইঙ্গিত দিলে দেখা যাবে ডিজাইনটি "কাজ করেছে" মনে হচ্ছে, কিন্তু বাস্তবে ব্যবহারকারী নিজে থেকে সেই পথ খুঁজে পাননি — যা আসল সমস্যাগুলো লুকিয়ে ফেলে (M31-এর থিংক-অ্যালাউড প্রোটোকলে এই একই নীতি প্রযোজ্য)।
প্র ০৩ একটি ভয়েস-শুধুমাত্র ইন্টারফেস (স্ক্রিন নেই) ডিজাইন করার সময় "পেপার প্রোটোটাইপ" ধারণাটি কীভাবে মানিয়ে নেওয়া যেতে পারে?
কাগজের বদলে একটি স্ক্রিপ্ট বা কথোপকথন-ফ্লো-চার্ট ব্যবহার করা যায় — একজন গবেষক লিখিত স্ক্রিপ্ট অনুসরণ করে ব্যবহারকারীর মৌখিক ইনপুটে সাড়া দেন, অনেকটা M9-এ পরে দেখা "Wizard-of-Oz"-এর মতো একটি কৌশল। মূল নীতি একই থাকে — কোনো বাস্তব সিস্টেম তৈরি না করেই ইন্টারঅ্যাকশন ফ্লো টেস্ট করা।
অনুশীলন
-
ডিজাইন করুন: একটি লাইব্রেরি অ্যাপের "বই রিনিউ করা" ফিচারের জন্য একটি পেপার প্রোটোটাইপ
ফ্লো কল্পনা করুন। কমপক্ষে ৪টি স্ক্রিন/কাগজের টুকরার তালিকা লিখুন (যেমন "আমার বই" স্ক্রিন, একটি নির্দিষ্ট
বইয়ের বিস্তারিত স্ক্রিন, ইত্যাদি) এবং প্রতিটি স্ক্রিনে ব্যবহারকারী কোন বাটনে "ক্লিক" করলে পরের কোন
স্ক্রিনে যাবেন তা বর্ণনা করুন।
একটি সম্ভাব্য ফ্লো: (১) "আমার বই" স্ক্রিন — বর্তমানে ধার নেওয়া সব বইয়ের তালিকা, প্রতিটির পাশে "রিনিউ" বাটন। (২) নির্দিষ্ট বইয়ে "রিনিউ" চাপলে একটি নিশ্চিতকরণ কাগজ দেখানো হয় — "নতুন ফেরত-তারিখ: XX তারিখ, নিশ্চিত করুন?"। (৩) নিশ্চিত করলে একটি সফলতার স্ক্রিন — "রিনিউ সম্পন্ন হয়েছে"। (৪) যদি বইটি অন্য কেউ রিজার্ভ করে রেখে থাকেন, তাহলে বদলে একটি এরর কাগজ দেখানো হয় — "এই বই রিনিউ করা যাচ্ছে না, কারণ..." — এই শেষ শাখাটি দেখায় কীভাবে পেপার প্রোটোটাইপে একাধিক সম্ভাব্য পথ (happy path + error path) আগে থেকেই প্রস্তুত রাখতে হয়।
-
বিশ্লেষণ করুন: একটি দল প্রথম স্টেকহোল্ডার মিটিংয়ে সরাসরি একটি রঙিন, সম্পূর্ণ পলিশড
মকআপ দেখায়। মিটিং শেষে একমাত্র ফিডব্যাক আসে "রংটা আরেকটু হালকা করা যায় কি না" — কাঠামো বা ফ্লো নিয়ে কোনো
প্রশ্ন ওঠেনি। আজকের পাঠের ধারণা ব্যবহার করে ব্যাখ্যা করুন কেন এমন হয়েছে, এবং দলটির কী করা উচিত ছিল।
একটি পলিশড, "সম্পন্ন মনে হওয়া" ডিজাইন দেখলে মানুষ ধরে নেয় বড় সিদ্ধান্তগুলো আগেই চূড়ান্ত হয়ে গেছে, তাই তারা শুধু পৃষ্ঠতলীয় (রঙ, ফন্ট) বিষয়ে মন্তব্য করতে স্বাচ্ছন্দ্য বোধ করে — গভীর কাঠামোগত প্রশ্ন তোলা "এত দূর এসে এখন এটা বলা ঠিক হবে না" মনে হয়। দলটির উচিত ছিল প্রথমে একটি লো-ফিডেলিটি স্কেচ দিয়ে ফ্লো ও কাঠামো নিয়ে সৎ ফিডব্যাক নেওয়া, তারপরই ভিজ্যুয়াল পলিশে বিনিয়োগ করা।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- ওয়্যারফ্রেমিং ও ইনফরমেশন আর্কিটেকচার পরবর্তী পাঠ স্কেচ থেকে একধাপ কাঠামোগতভাবে নির্দিষ্ট — ওয়্যারফ্রেম ও সাইটের তথ্য-সংগঠন কীভাবে ডিজাইন করবেন।
- কম্পিটিটিভ অ্যানালাইসিস ও হিউরিস্টিক ইভালুয়েশন আগের পাঠ প্রোটোটাইপিং শুরুর আগে প্রতিযোগী বিশ্লেষণ ও হিউরিস্টিক ইভালুয়েশন থেকে কী শেখা যায়।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ কগনিটিভ সাইকোলজি, ইন্টারঅ্যাকশন ডিজাইন, ইউজেবিলিটি হিউরিস্টিক্স, ইউজার রিসার্চ, প্রোটোটাইপিং, ইভালুয়েশন মেথড, ভিজ্যুয়াল ডিজাইন, অ্যাক্সেসিবিলিটি ও ক্যাপস্টোন — সব একসাথে।