چرا کاربران باگ گزارش نمی‌دهند (و چطور این را عوض کنیم)

اگر ماهی هزار کاربر دارید و ماهی سه گزارش باگ می‌گیرید، نتیجه‌گیری وسوسه‌انگیز این است که سایتتان تقریباً بی‌عیب است. تقریباً همیشه اشتباه است.

واقعیت این است که اکثریت قاطع کاربرانی که به مشکل می‌خورند، هیچ‌وقت چیزی نمی‌گویند. این مقاله دربارهٔ دلایل آن سکوت است — و اینکه هر کدام چه راه‌حلی دارد.

۱. گزارش دادن کار می‌برد، رفتن نه

ریشه‌ای‌ترین دلیل. کاربر باید صفحهٔ تماس را پیدا کند، فرمی را پر کند، مشکل را با کلمات توضیح دهد. رفتن، صفر تلاش می‌خواهد.

راه‌حل: مسیر را به تقریباً صفر برسانید. دکمه‌ای در همان صفحه‌ای که مشکل رخ داده، یک کادر متن، و ارسال. بدون جابه‌جایی، بدون ورود به حساب، بدون فیلد اجباری.

۲. فکر می‌کنند تقصیر خودشان است

کاربر غیرفنی وقتی دکمه‌ای کار نمی‌کند، اول به اینترنت خودش شک می‌کند، بعد به مرورگرش، بعد به اینکه شاید بلد نیست — و تقریباً هرگز به سایت شما.

راه‌حل: در متن ویجت صریح باشید که مشکل احتمالاً از آن‌ها نیست. عبارتی مثل «چیزی درست کار نکرد؟ به ما بگویید» بار مسئولیت را از دوش کاربر برمی‌دارد، برخلاف «مشکلی دارید؟» که ضمنی می‌گوید مشکل مال شماست.

۳. باور ندارند فرقی می‌کند

اگر یک بار جایی بازخورد داده‌اند و هیچ اتفاقی نیفتاده — نه پاسخی، نه تغییری — دفعهٔ بعد تکرارش نمی‌کنند. و این تجربه را از سایت‌های دیگر با خودشان می‌آورند.

راه‌حل: حلقه را ببندید. تأیید دریافت خودکار، حداقل کاری است که باید بکنید. و وقتی مشکلی را واقعاً حل کردید، به کسی که گزارشش کرده بود خبر دهید — کاری که تقریباً هیچ‌کس نمی‌کند و دقیقاً به همین دلیل اثرش زیاد است.

۴. نمی‌دانند چطور توضیحش دهند

«یه چیزی درست کار نمی‌کنه» تمام چیزی است که خیلی‌ها می‌توانند بگویند. خودشان هم می‌دانند که کافی نیست، و همین حس ناکافی بودن باعث می‌شود اصلاً ننویسند.

راه‌حل: به آن‌ها بگویید که همین کافی است. اگر سیستم شما اسکرین‌شات، آدرس صفحه، مرورگر و خطاهای کنسول را خودکار ضمیمه می‌کند، جملهٔ «یه چیزی کار نمی‌کنه» به گزارشی کاملاً قابل پیگیری تبدیل می‌شود.

۵. عجله دارند

کاربری که وسط خرید است، هدفی دارد و باگ شما مانع آن است. متوقف شدن برای نوشتن گزارش، یعنی رها کردن هدف اصلی.

راه‌حل: ارسال باید چند ثانیه طول بکشد و کاربر را از جایی که هست بیرون نبرد. ویجتی که صفحه را عوض کند یا فرم بلندی باز کند، دقیقاً در همین لحظه شکست می‌خورد.

۶. نمی‌دانند کجا بگویند

ساده‌ترین دلیل و رایج‌تر از آنچه فکر می‌کنید. اگر راه ارتباطی در فوتر پنهان است، برای کاربری که در صفحهٔ تسویه گیر کرده وجود ندارد.

راه‌حل: دکمه باید در همهٔ صفحات دیده شود. و در سایت‌های فارسی، سمت چپ — چون گوشهٔ پایین-راست معمولاً محل منو یا ویجت چت است و دکمه روی آن می‌افتد.

در سامانه‌های سازمانی این مشکل شدیدتر است. کارشناسی که هر روز با یک سامانه کار می‌کند، مثلاً کارشناس HSE یک واحد صنعتی که با نرم‌افزار ممیزی HSE خودارزیابی واحدش را ثبت می‌کند، اغلب نمی‌داند مشکل را باید به واحد فناوری اطلاعات بگوید، به پیمانکار نرم‌افزار یا به ستاد. نتیجه همان سکوت است؛ مگر اینکه راه گزارش درست داخل خود نرم‌افزار باشد.

۷. نگران‌اند که پاسخ ندهند یا بدتر، سرزنش شوند

تجربهٔ فرم‌هایی که به پاسخ خودکار بی‌ربط ختم می‌شوند، یا پشتیبانی‌ای که با لحن «شما اشتباه کردید» جواب می‌دهد، ماندگار است.

راه‌حل: لحن. هم در متن ویجت، هم در پاسخ.

الگوهای طراحی که گزارش دادن را آسان می‌کنند

راه‌حل‌های بالا را می‌شود به چند الگوی مشخص در رابط کاربری ترجمه کرد:

• دعوت در لحظهٔ شکست. وقتی ارسال فرم یا پرداخت با خطا روبه‌رو می‌شود، پیام خطا جای خوبی برای یک پیوند کوچک است: «اگر این مشکل تکرار شد، به ما بگویید». کاربر همان لحظه انگیزه دارد و جزئیات را هم به یاد دارد.
• صفحه‌های خطا را فراموش نکنید. صفحهٔ ۴۰۴، صفحهٔ «مشکلی پیش آمد» و صفحه‌هایی که نتیجه‌ای نشان نمی‌دهند، جاهایی‌اند که کاربر قطعاً به مانع خورده است. یک راه گزارش آنجا بیشترین کاربرد را دارد.
• یک پرسش باز، نه فرم چندبخشی. «چه چیزی درست کار نکرد؟» کافی است. اگر دسته‌بندی می‌خواهید، چند گزینهٔ اختیاری بگذارید که با یک لمس انتخاب شوند، نه فهرست کشویی اجباری.
• ایمیل اختیاری، با دلیل. اگر نشانی تماس می‌خواهید، بنویسید برای چه: «اگر می‌خواهید وقتی درست شد خبرتان کنیم». این هم دلیل می‌دهد و هم وعده‌ای است که باید به آن عمل کنید.
• پیش‌نمایش آنچه ارسال می‌شود. اگر اسکرین‌شات ضمیمه می‌شود، کاربر باید پیش از ارسال ببیندش. وقتی بداند دقیقاً چه چیزی فرستاده می‌شود، کمتر تردید می‌کند.
• روی موبایل امتحانش کنید. دکمه‌ای که روی دسکتاپ مرتب است، ممکن است روی موبایل روی دکمهٔ «پرداخت» بیفتد یا کیبورد کادر متن را بپوشاند.

به گزارش‌دهنده چه بگویید

بخش‌های ۳ و ۷ گفتند حلقه را ببندید و لحن را درست کنید. در عمل یعنی چند پاسخ آماده برای موقعیت‌های تکراری. این‌ها نمونه‌اند؛ با لحن خودتان بازنویسی‌شان کنید:

• هنگام دریافت: «ممنون که گفتید. گزارشتان به تیم فنی رسید و بررسی‌اش می‌کنیم.» کوتاه، بدون وعدهٔ زمانی که نمی‌توانید نگهش دارید.
• وقتی بازتولید نمی‌شود: «هنوز نتوانسته‌ایم همین مشکل را ببینیم. اگر دوباره پیش آمد، لطفاً همان لحظه خبرمان کنید.» نه «مشکلی وجود ندارد».
• وقتی باگ نیست: «این بخش عمداً این‌طور طراحی شده، ولی اینکه گیج‌کننده بوده برای ما مهم است.» سردرگمی یعنی طراحی چیزی را درست منتقل نکرده است.
• وقتی حل شد: «مشکلی که گزارش کرده بودید برطرف شد. ممنون؛ بدون گزارش شما از آن خبر نداشتیم.» این همان پیامی است که دفعهٔ بعد را ممکن می‌کند.

و دو کاری که نباید بکنید: پاسخ از نشانی‌ای که کاربر نمی‌تواند به آن جواب دهد، و بستن گزارش بدون هیچ پیامی.

چطور بفهمیم وضعیت بهتر شده

اگر تغییری در ویجت یا فرآیندتان دادید، از کجا بدانید جواب داده؟ چهار عدد که ارزش پیگیری دارند:

تعداد گزارش به‌ازای هزار بازدید. عدد مطلق گمراه‌کننده است چون با ترافیک بالا و پایین می‌رود. این نسبت، اثر تغییرات شما را نشان می‌دهد.

درصد گزارش‌های قابل بازتولید. اگر بیشتر گزارش‌ها نیاز به سؤال بیشتر دارند، یعنی زمینهٔ کافی جمع نمی‌کنید — نه اینکه کاربرانتان بی‌دقتند.

فاصلهٔ گزارش تا اولین پاسخ. این عدد بیش از هر چیز دیگری تعیین می‌کند کاربر بار دوم هم گزارش بدهد یا نه.

تنوع گزارش‌دهندگان. اگر همیشه همان پنج نفر گزارش می‌دهند، مسیر شما فقط برای کاربران خاصی قابل استفاده است.

یک اشتباه تفسیری

وقتی گزارش‌ها بالا می‌رود، واکنش طبیعی مدیریت این است که «کیفیت محصول افت کرده». تقریباً همیشه غلط است.

باگ‌ها از قبل بودند؛ چیزی که تغییر کرده این است که حالا می‌بینیدشان. نمودار صعودی گزارش‌ها بعد از بهبود مسیر بازخورد، نشانهٔ سلامت است — مثل اینکه چراغ را در اتاق تاریک روشن کنید و ناگهان گرد و خاک را ببینید. هزینهٔ پنهان نداشتن سیستم رصد خطا همین سوگیری را با عدد نشان می‌دهد.

اگر این را از قبل به تیم و مدیریت توضیح ندهید، ممکن است همان چراغ را دوباره خاموش کنند.

وقتی گزارش‌ها زیاد شد

اگر این‌ها را اجرا کنید، تعداد گزارش‌ها بالا می‌رود — و این نشانهٔ سلامت است، نه بدتر شدن محصول. ولی دو مسئلهٔ جدید می‌سازد که باید آماده باشید:

تکراری‌ها. ده نفر یک باگ را گزارش می‌کنند. این داده است نه مزاحمت — نشان می‌دهد چقدر گسترده است. گروه‌بندی کنید، نه اینکه ببندید.

مواردی که باگ نیستند. بخشی از گزارش‌ها درخواست قابلیت یا سردرگمی خواهند بود. این‌ها را دور نریزید؛ سردرگمی معمولاً ارزشمندترین بازخوردی است که می‌گیرید، چون به‌ازای هر نفری که گفته، چند نفر گفته‌اند و ساکت مانده‌اند.

چک‌لیست بازبینی مسیر گزارش

یک بار خودتان جای کاربر بنشینید. با گوشی، از صفحهٔ پرداخت، یک گزارش آزمایشی بفرستید و این‌ها را بسنجید:

1. دکمهٔ گزارش را بدون جست‌وجو پیدا کردید؟
2. از لمس اول تا ارسال چند قدم طول کشید؟ هر قدم اضافه یک دلیل برای منصرف شدن است.
3. جایی مجبور شدید وارد حساب شوید یا فیلدی را اجباری پر کنید؟
4. بعد از ارسال، روی همان صفحه ماندید و سبد خریدتان دست‌نخورده بود؟
5. پیامی دیدید که بگوید گزارش رسید؟
6. گزارشی که به تیم رسید، بدون پرسیدن سؤال اضافه قابل پیگیری بود؟
7. چقدر طول کشید تا کسی به آن پاسخ دهد؟

هر «نه» در این فهرست، یکی از دلیل‌های سکوت است که هنوز سر جایش مانده.

پرسش‌های رایج

دکمهٔ گزارش باگ را به همه نشان دهیم یا فقط به بعضی کاربران؟

بستگی به محصول دارد. در سامانه‌های داخلی که کاربران شناخته‌شده‌اند، نشان دادن به همه منطقی است. در سایت عمومی ممکن است بخواهید از گروه کوچک‌تری شروع کنید، مثلاً کاربران واردشده، و حجم گزارش‌ها را بسنجید. در باگ‌ماگ می‌توانید تعیین کنید چه کسانی دکمه را ببینند، و اگر فعلاً دکمه نمی‌خواهید، با showWidget: false فقط خطاها را خودکار ثبت کنید.

فرق دکمهٔ گزارش باگ با فرم «تماس با ما» چیست؟

فرم تماس معمولاً در صفحه‌ای جداست و فقط متن کاربر را می‌گیرد. دکمهٔ گزارش در همان صفحه‌ای است که مشکل رخ داده و می‌تواند زمینهٔ فنی را خودکار ضمیمه کند. اولی برای سؤال و درخواست مناسب است، دومی برای «همین‌جا چیزی خراب است».

برای گزارش باگ جایزه بدهیم؟

برای کاربران عادی معمولاً لازم نیست و ممکن است گزارش‌های کم‌کیفیت یا تکراری را زیاد کند. آنچه بیشتر اثر دارد، دیده شدن است: پاسخ سریع و خبر دادن وقتی مشکل حل شد. پاداش برای یافتن آسیب‌پذیری‌های امنیتی دنیای جداگانه‌ای است؛ اگر به آن سمت علاقه دارید، باگ‌هانتینگ چیست را ببینید.

یک نکتهٔ ناخوشایند

حتی با بهترین اجرا، هنوز اکثریت کاربرانی که به مشکل می‌خورند چیزی نمی‌گویند. بازخورد کاربر سقف دارد.

برای همین است که رصد خودکار خطا مکمل ضروری است، نه گزینهٔ رقیب: خطاهای فنی را می‌بینید حتی وقتی هیچ‌کس گزارش نداده، و بازخورد کاربر آن دسته از مشکلاتی را می‌آورد که هیچ خطایی تولید نمی‌کنند. هیچ‌کدام به‌تنهایی تصویر کامل را نمی‌دهد.

منابع و مطالعهٔ بیشتر

• Error-Message Guidelines — گروه نیلسن نورمن — لحن و محتوای پیام خطا
• Visibility of System Status — گروه نیلسن نورمن — چرا کاربر باید بداند درخواستش رسیده
• First Rule of Usability? — گروه نیلسن نورمن — فاصلهٔ حرف کاربر و رفتار واقعی‌اش