নিশ্চিতকরণ
নিশ্চিতকরণ ব্যবহারকারীদের তাদের ইনপুট কিভাবে বোঝা হয়েছে তার প্রতিক্রিয়া দেয়। এটি শুধুমাত্র ব্যবহারকারীদের অবিলম্বে ভুলগুলি সংশোধন করার ক্ষমতা দেয় না, তবে এটি তাদের সামাজিকভাবে এবং কথোপকথনের জন্য উপযুক্ত উপায়ে সাধারণ ভিত্তি স্থাপন করে আশ্বস্ত করে। তদ্ব্যতীত, নিশ্চিতকরণগুলি প্রসঙ্গ বজায় রেখে কথোপকথনের থ্রেডকে এগিয়ে নিয়ে যেতে সহায়তা করে।
এছাড়াও দেখুন আপনি আবার বলতে পারেন: জেমস জিয়াঙ্গোলা, কথোপকথন এবং ব্যক্তিত্ব ডিজাইন লিড @ Google দ্বারা কথোপকথন ডিজাইনে পুনরাবৃত্তির ভূমিকা
কি এবং কিভাবে নিশ্চিত করা
নিশ্চিত করা প্রয়োজন হতে পারে যে 2 ধরনের জিনিস আছে:
পরামিতি
তথ্যের মূল অংশ যা বলা বা উহ্য ছিল।
উদাহরণ: পুরুষদের চলমান জুতা (জুতার শৈলী), রাজকীয় নীল এবং নিয়ন সবুজ (রঙ)
কর্ম
অ্যাসিস্ট্যান্ট কিছু করতে চলেছে বা সম্পূর্ণ করেছে৷
উদাহরণ: ব্যবহারকারীর সময়সূচীতে একটি সেশন যোগ করা
সুস্পষ্ট নিশ্চিতকরণ
অন্তর্নিহিত নিশ্চিতকরণ
কোন নিশ্চিতকরণ
ব্যবহার
কিছু ধরনের নিশ্চিতকরণ অন্যদের তুলনায় অনেক বেশি ঘন ঘন হয়। সর্বাধিক- থেকে সর্বনিম্ন-সাধারণ পরিস্থিতিতে কীভাবে নিশ্চিতকরণ ব্যবহার করবেন তার একটি তালিকা এখানে রয়েছে:
পরামিতিগুলির অন্তর্নিহিত নিশ্চিতকরণ (সাধারণ)
বেশিরভাগ সময় ব্যবহার করুন, ব্যবহারকারীর ইনপুট নিশ্চিত করতে নয়, বরং বলা বা উহ্য করা পরামিতিগুলি নিশ্চিত করতে। ব্যবহারকারীদের প্রতিক্রিয়া বোঝার জন্য এই প্রসঙ্গ প্রয়োজন।
করবেন।
অনুমানকৃত সংখ্যা নিশ্চিত করা ব্যবহারকারীকে আশ্বস্ত করে যে তারা বুঝতে পেরেছিল এবং তাদের পরবর্তী অনুমান ফ্রেম করতে সহায়তা করে।
করবেন না।
আপনার অ্যাকশন যা শুনেছে বা ব্যবহারকারী যা বলেছেন তার উপর ফোকাস করে নিশ্চিতকরণগুলি বলবেন না।
কর্মের অন্তর্নিহিত নিশ্চিতকরণ (সাধারণ)
স্বীকার করুন যে একটি ক্রিয়া সম্পন্ন হয়েছে (যদি না এটি স্ব-স্পষ্ট হয়)।
করবেন।
নিশ্চিত করুন যে বিশদগুলি পাঠানো হয়েছে এবং ব্যবহারকারীকে জানান যে তারা কোথায় পাঠানো হয়েছে৷
করবেন না।
ব্যবহারকারীরা বিশদ সেট করা ছিল বিশ্বাস নাও হতে পারে.
কর্মের কোন নিশ্চিতকরণ নেই (অসাধারন)
যখন ক্রিয়া/প্রতিক্রিয়া নিজেই তাৎক্ষণিকভাবে পরিষ্কার করে দেয় যে আপনি ব্যবহারকারীকে বুঝতে পেরেছেন তখন ব্যবহার করুন। এটি "স্টপ" বা "বাতিল" এর মতো বিশ্বব্যাপী কমান্ডের জন্য সত্য।
করবেন না।
আপনার অ্যাকশন ব্যবহারকারীকে কথোপকথন চালিয়ে যেতে বাধ্য করতে পারে না।
পরামিতিগুলির কোন নিশ্চিতকরণ নেই (বিরল)
ইনপুট সহজ এবং সাধারণত উচ্চ আত্মবিশ্বাসের সাথে স্বীকৃত কিনা তা নিশ্চিত করবেন না, উদাহরণস্বরূপ, হ্যাঁ/না ব্যাকরণ।
করবেন।
নোট করুন যে ব্যবহারকারীর 'হ্যাঁ' প্রতিক্রিয়া নিশ্চিত করা হয়নি।
করবেন না।
হ্যাঁ/না ব্যাকরণ নিশ্চিত করবেন না, যেমন "ঠিক আছে, হ্যাঁ।"
কর্মের সুস্পষ্ট নিশ্চিতকরণ (বিরল)
পূর্বাবস্থায় ফেরানো কঠিন হবে এমন একটি ক্রিয়া সম্পাদন করার আগে ব্যবহারকারীর সাথে ডবল-চেক করুন, উদাহরণস্বরূপ, ব্যবহারকারীর ডেটা মুছে ফেলা, একটি লেনদেন সম্পূর্ণ করা ইত্যাদি।
করবেন।
ব্যবহারকারীর ডেটা মুছে ফেলার আগে স্পষ্টভাবে নিশ্চিত করুন। (এছাড়াও, লক্ষ্য করুন যে সদস্যপদ বাতিল না করার বিষয়টি স্পষ্টভাবে নিশ্চিত করা হয়েছে, তাই কোন অস্পষ্টতা নেই।)
করবেন না।
এখানে একটি ত্রুটি থেকে পুনরুদ্ধার করা কঠিন হবে। একটি নতুন সদস্যপদ অ্যাকাউন্ট তৈরি করা সময়সাপেক্ষ এবং অ্যাকাউন্টের সাথে সম্পর্কিত তথ্য হারিয়ে যাবে।
পরামিতিগুলির সুস্পষ্ট নিশ্চিতকরণ (বিরল)
অল্প ব্যবহার করুন, শুধুমাত্র যখন ব্যবহারকারীর ভুল বোঝার খরচ বেশি হয়, উদাহরণস্বরূপ, নাম, ঠিকানা, পাঠ্য ব্যবহারকারীর পক্ষ থেকে শেয়ার করতে হবে।
করবেন।
পাঠানোর আগে পাঠানো সঠিক বার্তাটি নিশ্চিত করুন কারণ এটি পাঠানোর পরে ব্যবহারকারী এটি সংশোধন করতে অক্ষম।
করবেন না।
এখানে, কোন বার্তা অন্তর্ভুক্ত করা হবে তা ব্যবহারকারীর কাছে স্পষ্ট নয়। যদি একটি ত্রুটি ছিল, লোলা (প্রাপক) কিছু না বললে ব্যবহারকারী কখনই জানতেন না।
সংশোধন
ব্যবহারকারীরা তাদের ইনপুট সম্পর্কে ভুল বোঝাবুঝি বা ভুল ব্যাখ্যা করার পরে, স্পষ্ট এবং অন্তর্নিহিত নিশ্চিতকরণের পরে সংশোধন করার প্রত্যাশা করুন৷ ভুল না থাকলেও ব্যবহারকারীদের পরিবর্তন করার সুযোগ দিন।
এক-পদক্ষেপ সংশোধনের অনুমতি দিন।
ব্যবহারকারী সংশোধন আশা করুন যে তারা "না" বলে সমবায় নীতি অনুসরণ করবে, তারপরে তাদের সংশোধন (উদাহরণস্বরূপ, "না, সকাল 7 AM")। একে এক-ধাপে সংশোধন বলা হয়।
করবেন।
ব্যবহারকারীদের এক-পদক্ষেপ সংশোধন করার অনুমতি দিন।
করবেন না।
এখানে ব্যবহারকারীর প্রতিক্রিয়াকে "না" হিসাবে ভুল ব্যাখ্যা করা হয়েছে "এটাই কি সব হবে?"
সংযোগ সমর্থন করার জন্য ডায়ালগ তৈরি করুন।
ব্যবহারকারীদের যেকোনো প্যারামিটারে পরিবর্তন করতে দিন (তথ্যের মূল অংশ যা বলা বা উহ্য ছিল)।
করবেন।
ব্যবহারকারীরা কী সংশোধন করতে চান তা দ্ব্যর্থহীন করুন এবং নতুন তথ্যের জন্য জিজ্ঞাসা করুন৷
করবেন না।
এই ক্ষেত্রে একটি নতুন কাস্টম তোড়া তৈরি করে বাতিল করবেন না এবং ব্যবহারকারীদের ডায়ালগ শুরু করতে বাধ্য করবেন না।