পাঠ ০৩ · ৫৭-এর মধ্যে · মডিউল ১
Home / Courses / Human-Computer Interaction / ডিজাইন প্রসেস

HCI ডিজাইন প্রক্রিয়া — ইউজার-সেন্টার্ড ডিজাইন লাইফসাইকেল

The HCI design process — user-centered design lifecycle
৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • "ইউজার-সেন্টার্ড ডিজাইন" ঠিক কী বোঝায় এবং এটি একবারের "টেস্টিং ধাপ"-এর চেয়ে কীভাবে আলাদা
  • ISO 9241-210-এর চারটি মূল কাজ — বোঝা, ডিজাইন, প্রোটোটাইপ, ইভালুয়েট
  • কেন এই প্রক্রিয়াটি একটি সরলরেখা নয়, বরং একটি পুনরাবৃত্ত (iterative) চক্র
  • একটি সত্যিকারের, চলমান ডেমো — কীভাবে বারবার ইটারেশন ডিজাইনের সমস্যা কমিয়ে আনে
  • এই কোর্সের কোন মডিউলে প্রতিটি ধাপ বিস্তারিতভাবে কভার করা হবে

১ · কেন "ইউজার-সেন্টার্ড" — এক-ধাপ ডিজাইনের সমস্যা

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

Human-Centered DesignHuman-Centered Designএকটি ডিজাইন-প্রক্রিয়া যেখানে ব্যবহারকারীর প্রকৃত প্রয়োজন, সীমাবদ্ধতা ও প্রতিক্রিয়া প্রক্রিয়ার প্রতিটি ধাপে অন্তর্ভুক্ত করা হয় — শেষে শুধু একবার নয়। (ISO 9241-210-এর ভাষায় "Human-centred design")-এর মূল ধারণা হলো — ব্যবহারকারীর প্রকৃত প্রয়োজন, সীমাবদ্ধতা ও প্রতিক্রিয়া প্রক্রিয়ার শুরু থেকেই এবং বারবার অন্তর্ভুক্ত করা, যাতে ভুল ধারণার উপর ভিত্তি করে বড় সিদ্ধান্ত নেওয়া এড়ানো যায়।

২ · চারটি মূল ধাপ

ISO 9241-210 (এবং প্রায় প্রতিটি প্রচলিত HCI টেক্সটবই) একই মূল চক্রকে বর্ণনা করে, সাধারণত চারটি কাজে ভাগ করে:

১. বোঝা (Understand)
ব্যবহারকারী কারা, তাদের প্রেক্ষাপট, কাজ ও প্রয়োজন কী — কন্টেক্সচুয়াল ইনকোয়ারি, ইন্টারভিউ (M5-এ বিস্তারিত)।
২. ডিজাইন (Design)
প্রয়োজনের ভিত্তিতে ইন্টারঅ্যাকশন সমাধান তৈরি করা — কনসেপচুয়াল মডেল, ওয়ার্কফ্লো (M3-এ বিস্তারিত)।
৩. প্রোটোটাইপ (Prototype)
ডিজাইনকে দেখা ও পরীক্ষা করার মতো একটি রূপে আনা — স্কেচ থেকে ইন্টারঅ্যাকটিভ মকআপ (M6-এ বিস্তারিত)।
৪. ইভালুয়েট (Evaluate)
প্রকৃত ব্যবহারকারীদের দিয়ে প্রোটোটাইপ যাচাই করে প্রয়োজন পূরণ হয়েছে কি না তা মাপা (M7-এ বিস্তারিত)।

চতুর্থ ধাপ শেষ হওয়ার পর যদি প্রয়োজনীয়তা পূরণ না হয় (প্রায় সবসময়ই প্রথমবারে হয় না), প্রক্রিয়া আবার "বোঝা" বা "ডিজাইন" ধাপে ফিরে যায় — এটাই কেন একে লাইফসাইকেল বলা হয়, একটি একরৈখিক তালিকা নয়।

৩ · কেন এটি একটি চক্র, সরলরেখা নয় — একটি ডেমো

নিচের কোড সেলে একটি সরলীকৃত, ইলাস্ট্রেটিভ মডেল (কোনো নির্দিষ্ট বাস্তব গবেষণার তথ্য নয়) দেখানো হয়েছে — একটি ডিজাইনে শুরুতে ২০টি অজানা ইউজেবিলিটি সমস্যা আছে ধরে নিয়ে, প্রতিটি "ডিজাইন → প্রোটোটাইপ → ইভালুয়েট" চক্রে অর্ধেক অবশিষ্ট সমস্যা খুঁজে বের করে ঠিক করা হয়, কিন্তু প্রতিটি রিডিজাইনে নতুন কিছু ছোট সমস্যাও যোগ হতে পারে (বাস্তবে যেমন হয়)।

Python
# সরলীকৃত, ইলাস্ট্রেটিভ মডেল -- কোনো নির্দিষ্ট বাস্তব স্টাডির ডেটা নয়
issues = 20  # শুরুতে অজানা ইউজেবিলিটি সমস্যার সংখ্যা
new_issues_each_round = [3, 1, 1, 0, 0]  # প্রতি রাউন্ডে রিডিজাইন থেকে নতুন যোগ হওয়া সমস্যা

history = []
for round_num, new in enumerate(new_issues_each_round, start=1):
    fixed = issues // 2          # প্রতি ইভালুয়েশন রাউন্ডে অর্ধেক অবশিষ্ট সমস্যা খুঁজে ঠিক করা হয়
    issues = issues - fixed + new
    history.append((round_num, fixed, new, issues))

for round_num, fixed, new, remaining in history:
    print(f"রাউন্ড {round_num}: ঠিক হলো={fixed:2d}টি | নতুন পাওয়া গেল={new}টি | অবশিষ্ট={remaining}টি")

    


    

      লক্ষ্য করুন — ২০টি সমস্যা দিয়ে শুরু করে ৫ রাউন্ড পরে মাত্র ২টি অবশিষ্ট থাকে (২০ → ১৩ → ৮ →
      ৫ → ৩ → ২)। প্রথম রাউন্ডে অনেক সমস্যা ঠিক হয় কিন্তু নতুন সমস্যাও বেশি ধরা পড়ে (রিডিজাইন নিজেই কখনো কখনো নতুন
      সমস্যা তৈরি করে) — শেষের দিকে উন্নতি ছোট হয়ে আসে, কিন্তু শূন্যে পৌঁছায় না। এটাই বাস্তবতার
      কাছাকাছি একটি ধারণা — ইটারেশন সমস্যা কমায়, সম্পূর্ণ নির্মূল করে না, তাই কোথাও থামার সিদ্ধান্ত নিতে হয় (সময়,
      বাজেট, বা "যথেষ্ট ভালো" মানদণ্ডের ভিত্তিতে)।
    


    
৪ · এই কোর্সে কোথায় প্রতিটি ধাপ বিস্তারিত হবে

    

      এই চারটি ধাপ এই পুরো কোর্সের কাঠামো তৈরি করে — M5-এ "বোঝা" ধাপের জন্য কন্টেক্সচুয়াল
      ইনকোয়ারি, ইন্টারভিউ, পার্সোনা ও টাস্ক অ্যানালাইসিস; M3-এ "ডিজাইন" ধাপের জন্য অ্যাফোর্ডেন্স,
      ম্যাপিং, কনসেপচুয়াল ডিজাইন; M6-এ "প্রোটোটাইপ" ধাপের জন্য লো-ফাই স্কেচ থেকে হাই-ফাই
      প্রোটোটাইপ; আর M7-এ "ইভালুয়েট" ধাপের জন্য ইউজেবিলিটি টেস্টিং, A/B টেস্টিং ও SUS স্কোরিং
      কভার করা হবে। M4-এর ইউজেবিলিটি হিউরিস্টিক্স পুরো চক্র জুড়েই একটি সহায়ক টুল হিসেবে ব্যবহৃত হয়।
    


    

      মূল কথা · Key takeaway
      

        ইউজার-সেন্টার্ড ডিজাইন মানে "একবার ব্যবহারকারীর মতামত নেওয়া" নয় — এটি একটি নিয়মতান্ত্রিক, পুনরাবৃত্ত চক্র
        যেখানে প্রতিটি ধাপ পরের ধাপকে প্রভাবিত করে এবং ইভালুয়েশনের ফলাফল আবার ডিজাইনে ফিরে আসে। এই লুপ যত বেশি
        দ্রুত ও সস্তায় চালানো যায় (ছোট প্রোটোটাইপ, দ্রুত টেস্ট), ততই কম ব্যয়ে বেশি সমস্যা আগেভাগে ধরা পড়ে।
      

    


  


  

    
    
  


  

    
 ভাবনার প্রশ্ন

    
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।


    

      
        প্র ০১
        কেন প্রথম ধাপ "ব্যবহারকারীদের বোঝা" ছাড়া সরাসরি প্রোটোটাইপ বানিয়ে ফেলা ঝুঁকিপূর্ণ?
      
      

        

          ব্যবহারকারীদের প্রকৃত প্রয়োজন না বুঝে ডিজাইন করলে দল আসলে নিজেদের অনুমানের জন্য ডিজাইন
          করে, প্রকৃত ব্যবহারকারীর জন্য নয়। এতে ভুল সমস্যার জন্য সুন্দর সমাধান তৈরি হওয়ার ঝুঁকি থাকে — যা
          ইভালুয়েশন ধাপে ধরা পড়লে পুরো ডিজাইন থেকে শুরু করে আবার তৈরি করতে হয়, যা "বোঝা" ধাপে সময় দিলে অনেকটাই
          এড়ানো যেত।
        

      

    


    

      
        প্র ০২
        ইভালুয়েশন ধাপে সমস্যা পাওয়া গেলে পরবর্তী ধাপ কী হওয়া উচিত, এবং কেন এই প্রক্রিয়াটি একরৈখিক
        (linear) নয়?
      
      

        

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

      

    


    

      
        প্র ০৩
        একটি সংস্থা যদি বলে "সময় বাঁচাতে আমরা ইভালুয়েশন ধাপ বাদ দেব", L01-এর "HCI একটি পরিমাপযোগ্য
        বিজ্ঞান" দৃষ্টিকোণ থেকে এর সম্ভাব্য ফলাফল কী?
      
      

        

          ইভালুয়েশন ছাড়া দল কখনো জানতে পারবে না তাদের ধারণা প্রকৃত ব্যবহারকারীর ক্ষেত্রে সত্যিই কাজ করেছে কি না —
          তারা শুধু অনুমান নিয়ে চলবে, L01-এ যেমন বলা হয়েছে ফিটস'স ল দিয়ে "অনুমান নয়, প্রকৃত
          গণনা" যাচাই করা যায়, তেমনি ইভালুয়েশন ছাড়া কোনো ডিজাইন সিদ্ধান্ত সত্যিকারের প্রমাণের ভিত্তিতে নয়, নিছক
          বিশ্বাসের ভিত্তিতে দাঁড়িয়ে থাকে — যা পরে বড় ব্যবহারযোগ্যতা সমস্যা আকারে সামনে আসতে পারে, তখন ঠিক করা
          অনেক বেশি ব্যয়বহুল।
        

      

    

  


  

    
 অনুশীলন

    
    
      
  1. 
        চিন্তা করুন: উপরের কোড সেলে যদি new_issues_each_round-এ ষষ্ঠ একটি রাউন্ড
        0 নতুন সমস্যা দিয়ে যোগ করা হয়, আপনার ধারণায় অবশিষ্ট সমস্যার সংখ্যা (বর্তমানে ৫ রাউন্ড পরে
        ২টি) কী হবে?
        
    
          
          
    
            
    
              যেহেতু প্রতি রাউন্ডে অবশিষ্ট সমস্যার অর্ধেক ঠিক হয়, ২টি থেকে 2 // 2 = 1টি
              ঠিক হবে এবং নতুন কিছু যোগ না হলে অবশিষ্ট থাকবে ১টি — সংখ্যাটি শূন্যের কাছাকাছি
              যেতে থাকে কিন্তু ধীরে ধীরে, কখনো ঠিক শূন্যে পৌঁছায় না (ইন্টিজার ডিভিশনের কারণে)।
            
    
          
    
        
    
      
    2. 
      
  2. 
        পরীক্ষা করুন: কোড সেলে new_issues_each_round-এ [3, 1, 1, 0, 0]-এর
        বদলে [3, 1, 1, 0, 0, 0] লিখে (৬ষ্ঠ রাউন্ড যোগ করে) Run চেপে আপনার অনুমান যাচাই করুন। এরপর
        প্রথম মানটি 3-এর বদলে 8 করে দেখুন (একটি অনেক দুর্বল প্রাথমিক ডিজাইন অনুকরণ
        করে) — শেষ রাউন্ডের ফলাফল কি বদলে যায়?
        
    
          
          
    
            
    
              ৬ রাউন্ড চালালে ফলাফল হয় ২০ → ১৩ → ৮ → ৫ → ৩ → ২ → ১ — ঠিক যেমন অনুমান করা হয়েছিল।
              আর প্রথম মান ৩-এর বদলে ৮ করলে (অনেক দুর্বল প্রাথমিক ডিজাইন) ফলাফল হয় ২০ → ১৮ → ১০ → ৬ → ৩ →
              ২ — অর্থাৎ শুরুতে অনেক বেশি সমস্যা (৮টি নতুন বনাম ৩টি) পাওয়া সত্ত্বেও, একই পাঁচ
              রাউন্ড পরে চূড়ান্ত ফলাফল প্রায় একই জায়গায় পৌঁছায় (২টি, বদলে ২টি)! এটি দেখায় — একটি দুর্বল
              প্রাথমিক ডিজাইনও যথেষ্ট ইটারেশনের মাধ্যমে ভালো ডিজাইনের কাছাকাছি পৌঁছাতে পারে — অর্থাৎ প্রথমবারেই
              নিখুঁত হওয়ার চেয়ে ধারাবাহিকভাবে ইটারেট করার প্রক্রিয়াটাই বেশি গুরুত্বপূর্ণ।
            
    
          
    
        
    
      
    3. 
    

  


  

    
 আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

    
    
      
  • 
        
          কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ
        
        কগনিটিভ সাইকোলজি, ইন্টারঅ্যাকশন ডিজাইন, ইউজেবিলিটি হিউরিস্টিক্স, ইউজার রিসার্চ, প্রোটোটাইপিং, ইভালুয়েশন মেথড, ভিজ্যুয়াল ডিজাইন, অ্যাক্সেসিবিলিটি ও ক্যাপস্টোন — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
      
    • 
      
  • 
        
          Human-Centered AI কোর্স সহোদর কোর্স
        
        ট্রাস্ট ক্যালিব্রেশন, এক্সপ্লেইনেবিলিটি ও হিউম্যান-ইন-দ্য-লুপ ডিজাইনের গভীর কভারেজ — এই কোর্স সেই একই ভিত্তির উপর সাধারণ ইন্টারঅ্যাকশন ডিজাইনের দিকটি যোগ করে।
      
    • 
      
  • 
        
          সব Courses দেখুন ABCL TECH
        
        C, C++, Python, Java, JavaScript, DSA, Machine Learning, Deep Learning, System Design, Cybersecurity, Cloud Computing & DevOps, এবং আরও অনেক কোর্স — সব এক জায়গায়।
      
    • 
    

  







  
  
     এই পাঠে ভুল পেয়েছেন? জানান
  





  
    
 আগের পাঠ

    
HCI-এর সংক্ষিপ্ত ইতিহাস — কমান্ড লাইন থেকে টাচ ও ভয়েস পর্যন্ত