User Persona কখন কাজে লাগে, কখন বিভ্রান্ত করে

একটি Product team কয়েক সপ্তাহ ধরে নতুন একটি ফিচার নিয়ে আলোচনা করছে। Marketing বলছে, তাদের মূল ব্যবহারকারী তরুণ পেশাজীবী। UX দলের ধারণা, নতুন ব্যবহারকারীরাই বেশি সমস্যায় পড়ছেন। Product Manager আবার দেখছেন ছোট ব্যবসার মালিকদের অনুরোধ বেশি আসছে।

এ অবস্থায় User Persona কাজে লাগতে পারে। কারণ আলোচনাটি অন্তত একটি জায়গায় এসে দাঁড়ায়—আমরা ঠিক কার সমস্যা সমাধান করছি?

কিন্তু persona আছে বলেই উত্তর পাওয়া গেল, এমন নয়। বরং persona কীভাবে তৈরি হয়েছে, সেটিই বেশি গুরুত্বপূর্ণ। বাস্তব গবেষণার বদলে যদি কয়েকজন সহকর্মীর ধারণা দিয়ে একটি কাল্পনিক মানুষ বানানো হয়, তাহলে সেই persona দলের পুরোনো অনুমানকেই আরও বিশ্বাসযোগ্য করে তুলতে পারে।

ধরা যাক, ছোট ব্যবসার জন্য একটি হিসাবরক্ষণ সফটওয়্যার তৈরি হচ্ছে। ব্যবহারকারীদের সঙ্গে কথা বলে জানা গেল, একটি অংশ নিজেরাই হিসাব রাখেন। হিসাববিজ্ঞানের জটিল শব্দ তাদের খুব একটা দরকার হয় না। মাস শেষে তারা মূলত দেখতে চান কত আয় হলো, কত খরচ হলো এবং হাতে কত রইল।

এই তথ্যগুলো কাজে লাগতে পারে। কারণ এগুলো interface, ভাষা বা report কীভাবে সাজানো হবে, সে সিদ্ধান্তে প্রভাব ফেলতে পারে।

এখন একই persona-তে যদি যোগ করা হয়—তিনি কফি পছন্দ করেন, ছুটিতে ঘুরতে যান, সন্ধ্যায় Netflix দেখেন—তাহলে চরিত্রটি হয়তো দেখতে বেশি “বাস্তব” লাগবে। কিন্তু হিসাবরক্ষণ সফটওয়্যারের কোনো সিদ্ধান্ত কি এতে বদলাবে?

না বদলালে তথ্যটি রাখার প্রয়োজনও কম।

User Persona নিয়ে কাজ করতে গিয়ে এই সহজ প্রশ্নটি অনেক সময় বাদ পড়ে যায়: এই তথ্যটি জানলে আমরা কী সিদ্ধান্ত অন্যভাবে নেব?

Persona-এর আসল কাজ মানুষকে গল্পে পরিণত করা নয়

Persona-এর উপকার সবচেয়ে বেশি বোঝা যায় এমন দলে, যেখানে সবাই সরাসরি ব্যবহারকারী গবেষণার সঙ্গে যুক্ত নন।

একজন UX Researcher হয়তো পাঁচটি সাক্ষাৎকার দেখেছেন। Designer কয়েকটি usability session-এ ছিলেন। কিন্তু Developer বা Marketing দলের কেউ হয়তো শুধু গবেষণার সারাংশ দেখেছেন। কিছুদিন পর বিস্তারিত তথ্য আরও ঝাপসা হয়ে যায়।

ভালো persona তখন কয়েকটি দরকারি বিষয় সামনে রাখে। এই মানুষটি কী করতে চাইছেন, কোথায় সমস্যায় পড়ছেন, কোন পরিস্থিতিতে পণ্যটি ব্যবহার করছেন—এগুলো মনে করিয়ে দেয়।

সমস্যা হয় যখন persona-কে গবেষণার সারাংশ না ভেবে গবেষণার বিকল্প বানানো হয়।

কোনো মিটিংয়ে কেউ বললেন, “আমাদের persona তো এই ফিচার চাইবে।”

সঙ্গে সঙ্গে প্রশ্ন হওয়া উচিত—কোন গবেষণা থেকে সেটা জানা গেছে?

Persona নিজে কোনো প্রমাণ নয়। তার পেছনের গবেষণাই প্রমাণের কাছাকাছি নিয়ে যায়।

একই ব্যাপার feature prioritization-এর ক্ষেত্রেও দেখা যায়।

ধরা যাক, একটি report screen-এ 20টি filter দেওয়ার প্রস্তাব এসেছে। কারও যুক্তি, বেশি option থাকলে ব্যবহারকারী বেশি স্বাধীনতা পাবেন। আরেকজন বলছেন, এত option interface-কে জটিল করবে।

যদি গবেষণায় দেখা যায় লক্ষ্য ব্যবহারকারীরা নিয়মিত মাত্র তিন-চার ধরনের তথ্য খোঁজেন, তাহলে persona সেই আলোচনাকে বাস্তব প্রয়োজনের দিকে ফিরিয়ে আনতে পারে।

কিন্তু persona দেখে কেউ বলতে পারবেন না, “তাহলে ঠিক চারটি filter রাখতে হবে।”

সেটি অন্য প্রশ্ন। Prototype বা usability test লাগতে পারে।

এই জায়গাটাই গুরুত্বপূর্ণ। Persona সাধারণত ভালো উত্তর দেওয়ার চেয়ে ভালো প্রশ্ন করতে সাহায্য করে বেশি।

“রাহুল, 32, প্রযুক্তিপ্রেমী”—এখানেই ঝুঁকি শুরু হতে পারে

Persona বানানোর workshop-এ খুব পরিচিত একটি দৃশ্য আছে। প্রথমে নাম ঠিক করা হলো। তারপর বয়স। ছবি। চাকরি। কয়েকটি personality trait।

তারপর লেখা হলো:

“রাহুল, 32 বছর বয়সী। শহরে থাকেন। নতুন প্রযুক্তি দ্রুত গ্রহণ করেন। বেশির ভাগ কাজ মোবাইলে করেন।”

পড়লে যথেষ্ট নির্দিষ্ট শোনায়।

কিন্তু এই চারটি কথার মধ্যে কয়টি সত্যিই গবেষণায় পাওয়া?

এখানেই persona অনেক সময় পিছলে যায়।

একটি দলের প্রাথমিক ধারণাগুলো লিখে রাখা অবশ্যই কাজে লাগতে পারে। এ ধরনের নথিকে proto persona হিসেবে ব্যবহার করা হয়। নতুন প্রকল্পের শুরুতে কারা কী ধরে নিয়ে এগোচ্ছেন, সেটি পরিষ্কার করার জন্য এর মূল্য আছে।

তবে সমস্যা হয় যখন “অনুমান” কথাটি পরে হারিয়ে যায়।

তিন মাস পর নতুন কোনো সদস্য সেই নথি দেখে ধরে নিতে পারেন সব তথ্যই গবেষণায় প্রমাণিত। ছয় মাস পর হয়তো কেউ বলবেন, “আমরা তো জানি আমাদের ব্যবহারকারী mobile-first।”

কিন্তু আসলে কেউ কখনো সেটি যাচাইই করেনি।

তাই persona-তে তথ্যের উৎস যতটা সম্ভব পরিষ্কার থাকা দরকার। কোনটি দেখা গেছে, কোনটি শোনা গেছে, আর কোনটি এখনো অনুমান—এই পার্থক্যটুকু না রাখলে একটি সুন্দর card সহজেই ভুল ধারণার স্থায়ী নথি হয়ে উঠতে পারে।

বয়স-পেশা দিয়ে আচরণ ব্যাখ্যা করতে গেলে আরও সতর্ক হতে হয়

Demographic তথ্য খুব সহজে ব্যবহার করা যায়। বয়স, পেশা, শহর—সবই পরিচিত শ্রেণি।

কিন্তু 28 বছর বয়সী দুই মানুষের প্রযুক্তি ব্যবহারের অভ্যাস এক নাও হতে পারে। একই প্রতিষ্ঠানে একই পদে থাকা দুই Manager-এর কাজের ধরনও আলাদা হতে পারে।

তবু persona-তে প্রায়ই এমন শর্টকাট দেখা যায়:

তরুণ, তাই মোবাইল পছন্দ করেন।

বয়স বেশি, তাই নতুন প্রযুক্তিতে ধীর।

Manager, তাই বিস্তারিত dashboard দরকার।

এগুলো গবেষণা ছাড়া লিখলে persona বাস্তব মানুষকে বোঝানোর বদলে stereotype শক্তিশালী করতে পারে।

Persona stereotyping নিয়ে 80 জন novice designer-এর একটি গবেষণায় দেখা গিয়েছিল, অংশগ্রহণকারীরা persona-তে সরাসরি দেওয়া হয়নি এমন কিছু বৈশিষ্ট্যও নিজেরা অনুমান করেছিলেন। কিছু ক্ষেত্রে সেই অনুমান design decision-এও প্রতিফলিত হয়েছিল।

এটিকে অবশ্য সার্বজনীন নিয়ম হিসেবে দেখা ঠিক নয়। গবেষণাটি novice designer এবং নির্দিষ্ট graphical design task-এর মধ্যে সীমাবদ্ধ ছিল।

কিন্তু সতর্ক হওয়ার যথেষ্ট কারণ এখানে আছে। Persona-তে যত বেশি ফাঁক থাকবে, মানুষ তত বেশি নিজের পরিচিত ধারণা দিয়ে সেই ফাঁক পূরণ করতে পারে।

Analytics-এর সঙ্গে Persona-র বিরোধ নেই

আরেকটি সাধারণ ভুল হলো Persona আর data-কে দুই বিপরীত পদ্ধতি হিসেবে দেখা।

ধরা যাক, গবেষণায় পাওয়া গেছে কোনো ব্যবহারকারী গোষ্ঠী খুব দ্রুত payment শেষ করতে চায়। সেটি persona-তে রাখা হলো।

তারপর নতুন payment flow চালু করা হলো।

এখন যদি জানতে চান কতজন payment শেষ করেছেন, কোন ধাপে বেশি মানুষ বেরিয়ে গেছেন, কিংবা পরিবর্তনের পর completion বেড়েছে কি না—persona দেখে উত্তর পাওয়া যাবে না।

Analytics দরকার।

আবার Analytics বলল, checkout-এর একটি নির্দিষ্ট ধাপে অনেক মানুষ বেরিয়ে যাচ্ছেন। কেন যাচ্ছেন?

সেটাও Analytics সব সময় বলে না।

সেখানে আবার ব্যবহারকারীর কাছে ফিরতে হতে পারে।

অর্থাৎ কাজের মধ্যে একটা যাওয়া-আসা আছে। Research থেকে একটি pattern পাওয়া গেল। সেটি persona-তে ধরা হলো। বাস্তব ব্যবহার দেখে Analytics-এ অন্য কিছু পাওয়া গেল। এরপর আবার সাক্ষাৎকার বা usability test করা হলো।

বাস্তব Product Development সাধারণত এতটাই অগোছালো। একটি document সব প্রশ্নের উত্তর দেয় না।

আরও পড়ুনঃ Roadmap-এ Date দেওয়া উচিত নাকি Outcome?

Persona তৈরি করার আগে কিছু না বানিয়েও থাকা যায়

User Persona জনপ্রিয় বলে অনেক দল project kickoff-এর সঙ্গে সঙ্গে persona workshop করে।

এটি সব সময় প্রয়োজনীয় নয়।

প্রথম দিকে বরং ব্যবহারকারীদের কাজ দেখাই বেশি দরকারি হতে পারে।

তারা কী করতে চাইছেন?

এখন কীভাবে করছেন?

কোথায় বারবার সমস্যা হচ্ছে?

কোন কাজটি এড়িয়ে যাচ্ছেন?

Support team-এর কাছে কী ধরনের অভিযোগ আসছে?

একই সমস্যা কি কয়েক ধরনের মানুষের মধ্যে আলাদা কারণে হচ্ছে?

এসব দেখার পর যদি স্পষ্ট কিছু pattern পাওয়া যায়, তখন persona বানানো অর্থপূর্ণ।

Pattern না পাওয়া গেলে জোর করে তিনটি persona তৈরি করার বিশেষ লাভ নেই।

কখনো research summary যথেষ্ট। কখনো user journey। আবার খুব ছোট একটি Product team যদি নিয়মিত ব্যবহারকারীদের সঙ্গে কথা বলে, তাহলে আলাদা persona card-এর প্রয়োজনই নাও হতে পারে।

এখানে কোনো “সঠিক সংখ্যা” নেই—একটি product-এ অবশ্যই তিন বা পাঁচটি persona থাকতে হবে এমন নিয়মও নেই।

ব্যবহারকারীদের মধ্যে বাস্তব পার্থক্য আছে কি না, সেটিই আসল।

ক্রেতা আর ব্যবহারকারীকে এক করে ফেললে আরেক ধরনের ভুল হয়

শিশুদের শিক্ষামূলক একটি অ্যাপের কথা ধরা যাক।

অ্যাপটি ব্যবহার করছে শিশু। টাকা দিচ্ছেন অভিভাবক। কোনো স্কুল কিনলে সিদ্ধান্তে শিক্ষক বা প্রশাসকও থাকতে পারেন।

এখন একটি persona দিয়ে তিনজনকে বোঝানোর চেষ্টা করলে সমস্যা হবে।

শিশুর কাছে প্রশ্ন হতে পারে—নির্দেশনা বুঝতে পারছে কি না, কাজটি কোথায় কঠিন লাগছে।

অভিভাবকের চিন্তা অন্য জায়গায়।

তিনি হয়তো পণ্য কেনার কারণ, প্রয়োজন বা ব্যবহারের উপযোগিতা নিয়ে ভাবছেন।

Marketing Persona তাই UX-এর User Persona-এর জায়গা নিতে পারে না। আবার শিশুর ব্যবহারগত persona দিয়ে ক্রেতার সিদ্ধান্ত বোঝা যাবে না।

একই product-এর জন্য দুই ধরনের persona থাকতেই পারে। গুরুত্বপূর্ণ হলো কোনটি কোন সিদ্ধান্তে ব্যবহার হচ্ছে।

Persona পুরোনো হলে সেটি বদলাতে হবে, রক্ষা করতে নয়

একটি persona দুই বছর ধরে ব্যবহার করা হচ্ছে। তাই সেটি ঠিক—এমন কোনো যুক্তি নেই।

পণ্য বদলে যেতে পারে। User base বদলাতে পারে। নতুন দেশ বা বাজার থেকে মানুষ আসতে পারে। আগে বড় সমস্যা ছিল এমন কিছু নতুন feature-এর কারণে আর সমস্যা নাও থাকতে পারে।

নতুন গবেষণা যদি বলে পুরোনো persona বাস্তবতার সঙ্গে মিলছে না, তাহলে গবেষণাকে persona-র সঙ্গে মানিয়ে নেওয়া উচিত নয়।

Persona-টিই বদলাবে।

এটা ব্যর্থতা নয়।

বরং একটি গবেষণাভিত্তিক কাজের নথির এটাই স্বাভাবিক জীবন।

তাই একটি Persona হাতে পেলে প্রথমে ছবির দিকে তাকাবেন না

দেখুন তথ্যগুলো কোথা থেকে এসেছে।

একটি বাক্যের পাশে যদি প্রশ্ন করা হয় “এটা আমরা কীভাবে জানি?”—দল কি উত্তর দিতে পারে?

এরপর দেখুন, তথ্যটি কোনো সিদ্ধান্তে কাজে লাগছে কি না।

তারপর আরেকটি কঠিন প্রশ্ন করুন: আগামী মাসে নতুন গবেষণা যদি এর বিপরীত কিছু বলে, তখন কি persona বদলানো হবে?

এই প্রশ্নগুলোর উত্তর পরিষ্কার হলে User Persona কাজে লাগার সম্ভাবনা অনেক বেশি।

আর যদি উত্তর হয়—“আমরা জানি না, তবে persona-তে লেখা আছে”—তাহলে সেটি আর ব্যবহারকারী গবেষণার সহায়ক নথি নেই। সেটি একটি অনুমানের দলিল।

User Persona বানানো নিজে কোনো অর্জন নয়। ব্যবহারকারীর সমস্যা ভালোভাবে বোঝা এবং সেই বোঝাপড়াকে Product, UX বা Marketing-এর সিদ্ধান্তে কাজে লাগানোই মূল কাজ।

কখনো persona সেই কাজ সহজ করে।

কখনো করে না।

দ্বিতীয় অবস্থায় শুধু একটি সুন্দর card পাওয়ার জন্য persona বানানোর দরকার নেই।

শেষ কথা

User Persona তখনই মূল্যবান, যখন এটি বাস্তব ব্যবহারকারীর আচরণ, প্রয়োজন ও সমস্যাকে সংক্ষেপে সামনে আনে। কিন্তু একটি সুন্দর নাম, ছবি বা গল্প কোনো অনুমানকে সত্যে পরিণত করে না। Persona-র প্রতিটি গুরুত্বপূর্ণ তথ্যের পেছনে গবেষণার ভিত্তি থাকা দরকার, আর নতুন প্রমাণ এলে সেটি বদলানোর প্রস্তুতিও থাকতে হবে।

Product team-এর লক্ষ্য Persona তৈরি করা নয়; লক্ষ্য হলো ব্যবহারকারীকে ভালোভাবে বোঝা এবং সেই বোঝাপড়াকে ভালো সিদ্ধান্তে রূপ দেওয়া। কখনো Persona সেই কাজকে সহজ করে, কখনো Research Summary, Analytics বা User Journey আরও কার্যকর হয়। তাই প্রশ্নটি হওয়া উচিত নয়—“আমাদের Persona আছে কি?” বরং—“আমরা যে সিদ্ধান্ত নিচ্ছি, তার পেছনে ব্যবহারকারীর বাস্তব প্রমাণ আছে কি?”

প্রায়শই জিজ্ঞাসিত প্রশ্ন

User Persona কী?

User Persona হলো গবেষণা থেকে পাওয়া ব্যবহারকারীর আচরণ, লক্ষ্য, প্রয়োজন, সমস্যা ও ব্যবহারের প্রেক্ষাপটের একটি সংক্ষিপ্ত উপস্থাপন। এটি কোনো কাল্পনিক চরিত্র তৈরির অনুশীলন নয়; বরং Product, UX ও Marketing দলের সিদ্ধান্তে ব্যবহারকারীর বাস্তব প্রয়োজন সামনে রাখার একটি উপায়।

User Persona তৈরি করা কি সব Product team-এর জন্য প্রয়োজনীয়?

না। প্রতিটি Product team-এর জন্য Persona বাধ্যতামূলক নয়। কোনো ক্ষেত্রে Research Summary, User Journey, Analytics বা নিয়মিত ব্যবহারকারী সাক্ষাৎকারই যথেষ্ট হতে পারে। Persona তখনই তৈরি করা উচিত, যখন এটি বাস্তব কোনো সিদ্ধান্ত নিতে সাহায্য করে।

ভালো User Persona তৈরির জন্য কী ধরনের তথ্য দরকার?

ব্যবহারকারীর লক্ষ্য, কাজের ধরন, সমস্যা, আচরণ, পণ্য ব্যবহারের পরিস্থিতি এবং সিদ্ধান্তে প্রভাব ফেলে এমন তথ্য সবচেয়ে গুরুত্বপূর্ণ। বয়স, পছন্দ বা ব্যক্তিগত শখের মতো তথ্য কেবল তখনই রাখা উচিত, যখন সেগুলো Product বা UX সিদ্ধান্তে সত্যিই প্রাসঙ্গিক।

Proto Persona এবং Research-based Persona-এর পার্থক্য কী?

Proto Persona সাধারণত দলের প্রাথমিক অনুমান বা বিদ্যমান ধারণা থেকে তৈরি হয়। Research-based Persona তৈরি হয় সাক্ষাৎকার, পর্যবেক্ষণ, usability test বা অন্য ব্যবহারকারী গবেষণার তথ্য থেকে। Proto Persona ব্যবহার করলে কোন তথ্য অনুমানভিত্তিক, তা পরিষ্কারভাবে চিহ্নিত করা জরুরি।

Persona কি Analytics-এর বিকল্প?

না। Persona ব্যবহারকারীর প্রয়োজন, লক্ষ্য ও আচরণের প্রেক্ষাপট বুঝতে সাহায্য করে। Analytics দেখায় বাস্তবে কী ঘটছে—যেমন কোথায় ব্যবহারকারী বেরিয়ে যাচ্ছেন বা কতজন একটি কাজ সম্পন্ন করছেন। ভালো Product Development-এ Research, Persona এবং Analytics একে অন্যকে সম্পূরক করে।

একটি Product-এর জন্য কতটি Persona থাকা উচিত?

এর কোনো নির্দিষ্ট সংখ্যা নেই। ব্যবহারকারীদের মধ্যে যদি লক্ষ্য, আচরণ বা সমস্যার গুরুত্বপূর্ণ পার্থক্য থাকে, তাহলে একাধিক Persona প্রয়োজন হতে পারে। শুধু সংখ্যা পূরণের জন্য তিন বা পাঁচটি Persona তৈরি করার প্রয়োজন নেই।

Buyer Persona এবং User Persona কি একই?

সব সময় নয়। User Persona মূলত যিনি পণ্য ব্যবহার করেন তাকে বোঝায়, আর Buyer Persona কেনার সিদ্ধান্তে যুক্ত ব্যক্তিকে বোঝাতে পারে। শিশুদের একটি শিক্ষামূলক অ্যাপে শিশু ব্যবহারকারী হলেও অভিভাবক বা স্কুল হতে পারে ক্রেতা। তাই তাদের প্রয়োজন ও সিদ্ধান্ত আলাদাভাবে বোঝা দরকার।

কতদিন পর Persona আপডেট করা উচিত?

নির্দিষ্ট সময়সীমা না ধরে নতুন গবেষণা, পরিবর্তিত ব্যবহারকারী গোষ্ঠী, নতুন বাজার বা Product পরিবর্তনের সঙ্গে Persona পর্যালোচনা করা ভালো। নতুন প্রমাণ যদি পুরোনো Persona-র সঙ্গে না মেলে, তাহলে Persona-ই পরিবর্তন করা উচিত।