منطق شرطی چگونه پرسشنامه را کوتاهتر میکند؟
منطق شرطی را با مثال خرید آنلاین یاد بگیرید؛ نقشه مسیر، جدول قواعد و آزمون شاخهها بسازید تا هر فرد سؤال مرتبط ببیند و پاسخ پنهان در تحلیل هم اشتباه تفسیر نشود.
در این نوشته میخوانید
منطق شرطی کمک میکند هر پاسخدهنده فقط سؤالهای مرتبط با تجربه خودش را ببیند. در این راهنما با یک مثال فروشگاه، نقشه مسیر، جدول قواعد و برگه آزمون میسازیم؛ سپس بررسی میکنیم سؤالهای پنهان چه اثری بر داده و گزارش دارند.
فرض کنید هنوز سفارش خود را دریافت نکردهاید، اما فرم از شما میخواهد به کیفیت بستهبندی نمره بدهید. انتخاب تصادفی یک گزینه یا ترک فرم، هر دو ممکناند. مسئله فقط طول پرسشنامه نیست؛ سؤال در زمان نامناسب از فرد نامناسب پرسیده شده است.
قبل از ساخت مسیرها، هدف هر سؤال را روشن کنید. نقشه طراحی پرسشنامه نقطه شروع مناسبی برای اتصال هدف تحقیق به سؤال است. شاخهبندی زمانی مفید است که این اتصال از قبل مشخص باشد.
فهرست مطالب
- منطق شرطی چیست؟
- چه سؤالهایی را شرطی کنیم؟
- مثال نقشه مسیر برای تجربه خرید
- جدول قواعد پیش از پیادهسازی
- چگونه مسیرها را آزمایش کنیم؟
- اثر شاخهبندی بر تحلیل پاسخها
- خطاهای رایج و راه اصلاح
- جمعبندی
- پرسشهای متداول
منطق شرطی چیست؟
منطق شرطی یعنی نمایش سؤال یا انتخاب مسیر بعدی بر پایه یک پاسخ یا وضعیت مشخص. برای نمونه، سؤال ارزیابی پشتیبانی فقط به کسی نمایش داده شود که قبلاً گفته از پشتیبانی استفاده کرده است. فرد دیگر از این بخش عبور میکند و به سؤال مشترک بعدی میرسد.
سه رفتار را هنگام طراحی از هم جدا کنید. نمایش شرطی یک سؤال یا گروه کوچک را آشکار میکند. پرش پاسخدهنده را به بخش دیگری میبرد. پایان مسیر پرسشنامه را برای وضعیت مشخصی تمام میکند؛ این پایان باید با توضیح روشن همراه باشد تا شبیه خطای فنی به نظر نرسد.
کمشدن سؤالهای هر مسیر با کمشدن کل سؤالهای فایل یکسان نیست. یک فرم ممکن است چند بخش تخصصی داشته باشد، اما هر فرد فقط بخش مرتبط را ببیند. برای سنجش بار پاسخگویی، مسیر واقعی و زمان مشاهدهشده مهماند؛ تعداد سؤالهای سازنده بهتنهایی کافی نیست.
این مقاله روش طراحی را توضیح میدهد. نام دکمهها، دسترسی هر طرح اشتراک و رفتار ذخیره پاسخ در ابزار مورد استفاده باید در محیط واقعی بررسی شوند.
چه سؤالهایی را شرطی کنیم؟
برای هر سؤال بنویسید «چه کسی میتواند با اتکا به تجربه خودش پاسخ دهد؟». اگر پاسخ همه مخاطبان نیست، احتمالاً به سؤال تشخیصی یا شاخه جدا نیاز دارید. «آیا در سفارش اخیر با پشتیبانی تماس گرفتید؟» میتواند شرط ورود به ارزیابی پشتیبانی باشد؛ «آیا از فروشگاه راضی هستید؟» شرط مناسبی برای تشخیص تماس نیست.
| نوع سؤال | تصمیم پیشنهادی | دلیل |
|---|---|---|
| رضایت از بستهبندی | فقط پس از دریافت سفارش | فرد هنوز دریافتنکرده تجربه مشاهده ندارد |
| ارزیابی پاسخ پشتیبانی | فقط برای استفادهکنندگان پشتیبانی | حدس دیگران داده مرتبط تولید نمیکند |
| رضایت کلی از تجربه سفارش | با متن مناسب برای همه وضعیتها | مقایسه گروهها به سؤال مشترک نیاز دارد |
| شماره تماس بدون کاربرد مشخص | حذف یا بازطراحی درخواست | پنهانکردن، ضرورت جمعآوری را ایجاد نمیکند |
در راهنمای رسمی ساختار فرم GOV.UK توصیه میشود برای هر داده، دلیل نیاز و مخاطب آن را روشن کنید. کاربرد عملی این اصل در پرسشنامه آن است که پیش از افزودن شرط، اصل نیاز به سؤال را بررسی کنیم.
از شرط برای حذف پاسخهای ناخوشایند استفاده نکنید. اگر فقط مشتریان راضی سؤال پیشنهاد محصول را ببینند، نتیجه آن سؤال نماینده همه مشتریان نیست. همچنین سؤالهایی که برای مقایسه گروهها لازماند باید با معنای یکسان و دامنه پاسخگویی روشن طراحی شوند.
مثال نقشه مسیر برای تجربه خرید
مثال زیر فرضی و ساخته تحریریه است. هدف فروشگاه، شناسایی مسئله در تحویل و پشتیبانی سفارش اخیر است. همه افراد نمونه، سفارش ثبتشده دارند؛ بنابراین این نقشه برای بازدیدکنندهای که خرید نکرده طراحی نشده است.
سؤال آغازین چنین است: «وضعیت دریافت سفارش اخیر شما چیست؟» گزینهها «دریافت کردهام»، «هنوز دریافت نکردهام» و «اطلاع ندارم» هستند. پس از انتخاب گزینه اول، میتوان درباره وضعیت بستهبندی پرسید. گزینه دوم باید به بررسی وضعیت مورد انتظار تحویل برسد، نه فوراً به فرض تأخیر.
مسیر دریافتشده
از فرد درباره سالمبودن بستهبندی بپرسید. سپس او را به سؤال مشترک استفاده از پشتیبانی ببرید. اگر هدف تحقیق بررسی کیفیت کالا نیست، سؤالهای جزئی درباره ویژگیهای کالا را صرفاً به دلیل وجود این شاخه اضافه نکنید.
مسیر هنوز دریافتنشده
بپرسید «آیا زمان اعلامشده برای تحویل گذشته است؟». پاسخ «بله» میتواند سؤال توضیح مشکل تحویل را نشان دهد. پاسخ «خیر» و «اطلاع ندارم» بدون تحمیل برچسب تأخیر به سؤال مشترک پشتیبانی میروند. اگر زمان تحویل اصلاً اعلام نشده، این وضعیت را نیز از ابتدا در گزینهها و مسیر عبور پوشش دهید.
محل اتصال مسیرها
از همه بپرسید آیا برای همین سفارش از پشتیبانی استفاده کردهاند. فقط پاسخ «بله» وارد ارزیابی پشتیبانی میشود. سپس همه به سؤال رضایت کلی از «تجربه ثبت و پیگیری سفارش تا این لحظه» و پایان میرسند؛ این عبارت، تجربه افراد هنوز دریافتنکرده را هم پوشش میدهد.

این نمودار فقط شاخه نخست دریافت سفارش را نشان میدهد؛ سؤالهای تأخیر و پشتیبانی در جدول قواعد توضیح داده شدهاند.
در این نقشه، دریافتنکردن به معنای نارضایتی نیست و نامعلوم هم معادل «خیر» نیست. چنین تمایزی جلوی یک خطای تحلیلی را از همان مرحله طراحی میگیرد.
جدول قواعد پیش از پیادهسازی
طرح را به چند جمله قابل آزمون تبدیل کنید. هر ردیف باید پاسخ ورودی، مقصد و رفتار حالتهای دیگر را مشخص کند. اگر دو قانون همزمان فعال میشوند، اولویت آنها را بنویسید یا شرطها را طوری بازطراحی کنید که تداخل نداشته باشند.
| شناسه | شرط | رفتار مورد انتظار | مسیر سایر پاسخها |
|---|---|---|---|
| R1 | سفارش دریافت شده | نمایش سؤال بستهبندی | عدم نمایش بستهبندی |
| R2 | سفارش هنوز دریافت نشده | پرسش درباره گذشتن موعد اعلامشده | عبور به سؤال استفاده از پشتیبانی |
| R3 | موعد گذشته است | نمایش سؤال مشکل تحویل | عبور به سؤال استفاده از پشتیبانی |
| R4 | از پشتیبانی استفاده شده | نمایش ارزیابی پشتیبانی | عبور به رضایت کلی |
| R5 | پایان هر شاخه تخصصی | بازگشت به سؤال مشترک بعدی | هیچ مسیر بدون مقصد نماند |
برای سؤال تشخیصی نخست، رفتار بیپاسخماندن هم باید معلوم باشد. اگر پاسخ برای تعیین مسیر لازم است، ضرورت آن را توضیح دهید و گزینه صادقانه «اطلاع ندارم» را در نظر بگیرید. اگر سؤال اختیاری است، عبور بدون پاسخ باید مقصد مشخصی داشته باشد؛ سیستم نباید یک پاسخ را از روی سکوت فرض کند.
در دفتر قواعد، متن دقیق سؤال و شناسه ثابت آن را نگه دارید. اشارههایی مانند «برو به سؤال پنجم» بعد از جابهجایی سؤالها مبهم میشوند. در پیادهسازی از مقصد پایدار ابزار استفاده کنید و پس از تغییر ترتیب، نقشه را دوباره کنترل کنید.
چگونه مسیرها را آزمایش کنیم؟
پیشنمایش یک مسیر کافی نیست. با پاسخهای ساختگی، شاخههای مثبت، منفی و نامعلوم را طی کنید. سپس به سؤال قبلی برگردید و پاسخ را عوض کنید؛ نتیجه نمایش و داده ذخیرهشده باید با مسیر نهایی سازگار باشد.
| مورد آزمون | ورودی یا اقدام | انتظار |
|---|---|---|
| دریافت سفارش | انتخاب «دریافت کردهام» | سؤال بستهبندی دیده شود |
| عدم دریافت | انتخاب «هنوز دریافت نکردهام» | سؤال موعد دیده شود؛ بستهبندی پنهان باشد |
| وضعیت نامعلوم | انتخاب «اطلاع ندارم» | رسیدن به سؤال مشترک بدون اجبار بستهبندی |
| پاسخ شرطی منفی | عدم استفاده از پشتیبانی | ارزیابی پشتیبانی نمایش داده نشود |
| تغییر پاسخ قبلی | دریافتشده به دریافتنشده | پاسخ قبلی بستهبندی در تحلیل نهایی ناسازگار باقی نماند |
| بازگشت و ارسال | رفتوبرگشت در هر شاخه | رسیدن به پایان بدون خطای سؤال اجباری پنهان |
نحوه برخورد ابزار با پاسخ پنهان را حدس نزنید. ممکن است با تغییر شرط، پاسخ قدیمی حذف شود، حفظ شود یا در خروجی بماند. یک خروجی آزمایشی بگیرید و قاعده مدیریت این پاسخها را ثبت کنید. اگر ابزار پاسخ قدیمی را نگه میدارد، روش حذف یا کنارگذاشتن آن در گزارش باید پیش از انتشار مشخص شود.
آزمون را روی موبایل هم اجرا کنید. بازشدن یک بخش تازه نباید باعث شود فرد نداند کجا ادامه دهد. با صفحهکلید نیز ترتیب حرکت و امکان رسیدن به پیام خطا را بررسی کنید؛ رنگ بهتنهایی نباید علامت مسیر یا خطا باشد.
اثر شاخهبندی بر تحلیل پاسخها
خانه خالی میتواند چند معنا داشته باشد: سؤال به فرد نمایش داده نشده، نمایش داده شده اما پاسخ نداده، یا فرد قبل از رسیدن به آن فرم را ترک کرده است. این وضعیتها را در حد امکانات ابزار و دفتر اجرای تحقیق از هم جدا کنید؛ تبدیل همه آنها به صفر یا نارضایتی، نتیجه را مخدوش میکند.
برای گزارش ارزیابی پشتیبانی، دامنه تحلیل استفادهکنندگان پشتیبانی است. تعداد پاسخ معتبر همان سؤال را کنار نتیجه بنویسید و مشخص کنید چه کسانی وارد شاخه شدهاند. درصد رضایت این گروه را بدون توضیح به همه خریداران نسبت ندهید.
اگر میخواهید اثر منطق شرطی را بر تکمیل بسنجید، تعریف شروع و تکمیل را در نسخههای قبل و بعد یکسان نگه دارید و تغییر ترکیب مخاطبان را بررسی کنید. راهنمای نرخ پاسخ و تفاوت آن با نرخ تکمیل کمک میکند این نسبتها را به جای هم گزارش نکنید.
کاهش تعداد سؤالهای یک مسیر، بهتنهایی اثبات کاهش زمان یا افزایش کیفیت نیست. زمان واقعی، نقاط مکث و کیفیت پاسخها را مشاهده کنید. راهنمای طراحی پرسشنامه Analysis Function نیز آزمودن تجربه پاسخدهنده و بازنگری تکرارشونده را در روند طراحی قرار میدهد.
خطاهای رایج و راه اصلاح
شرط مبهم: عبارت «اگر مشتری فعال بود» تعریف اجرایی ندارد. معیار را به یک پاسخ روشن یا داده معتبر و مجاز تبدیل کنید؛ برای داده نامعلوم هم مسیر مشخص بسازید.
شاخهبندی زودهنگام: سؤالهای سادهای که برای همه لازماند بین چند شاخه تکرار میشوند. آنها را در محل اتصال قرار دهید تا نگهداری متن و مقایسه نتایج سادهتر شود.
حلقه یا بنبست: یک پرش به عقب میتواند فرد را دوباره به همان شرط برساند. مسیر را از آغاز تا پایان روی کاغذ دنبال کنید؛ هر شاخه باید خروج روشن داشته باشد.
اجبار عمومی سؤال پنهان: فرد پیام «همه سؤالها را پاسخ دهید» میبیند، اما سؤال خطادار را نمیبیند. نمایش، اعتبارسنجی و اجبار پاسخ را با هم آزمایش کنید.
اعتماد به نام قابلیت: وجود گزینهای با عنوان منطق شرطی، رفتار مورد نیاز شما را تضمین نمیکند. قواعد ترکیبی، بازگشت و پاکسازی پاسخ قبلی را در همان نسخه و محیطی که منتشر میکنید امتحان کنید.
جمعبندی
طراحی خوب از تعیین مخاطب هر سؤال شروع میشود. نقشه مسیر را بسازید، قواعد را مکتوب کنید، حالت نامعلوم و تغییر پاسخ را بیازمایید و مخرج تحلیل هر شاخه را روشن نگه دارید. خروجی مطلوب، مسیر مرتبط و قابل توضیح است.
برای پروژه بعدی، جدول قواعد همین مقاله را با سؤالهای خودتان پر کنید؛ سپس از پُرس ایکس شروع کنید و پیش از دعوت عمومی، رفتار مسیرها را در فرم نهایی بیازمایید. جزئیات دسترسی و تنظیمات را در محیط محصول بررسی کنید.
پرسشهای متداول
اگر هدف مقایسه دو گروه است، حذف سؤال از یکی از گروهها مقایسه را ناممکن میکند. سؤال مشترک را با متن و مقیاس سازگار نگه دارید و سؤال تخصصی را جدا کنید. ابتدا مشخص کنید مقایسه درباره چه تجربه مشترکی معنا دارد.
مشخص کنید وجود یک گزینه کافی است یا باید چند گزینه با هم انتخاب شوند. حالت «هیچکدام» و انتخاب همزمان گزینههای متناقض را هم بررسی کنید. اگر ترتیب اجرای چند شاخه مبهم میشود، سؤال تشخیصی را سادهتر یا شاخهها را مستقل کنید.
تغییر قواعد میتواند دامنه افرادی را که سؤال را دیدهاند عوض کند. اگر اصلاح ضروری است، نسخه، زمان تغییر و اثر آن بر مسیرها را ثبت و بازآزمایی کنید. نتایج دو نسخه را بدون بررسی تفاوت مسیرها یکجا تفسیر نکنید.