چطور از کاربران بازخورد واقعی بگیریم
در این مقاله میخوانید
- چرا کاربران گزارش نمیدهند
- اصل اول: اصطکاک را حذف کنید، نه اینکه کمش کنید
- حداقل فیلد ممکن
- اصل دوم: زمینه را خودتان جمع کنید، نه از کاربر
- اصل سوم: بازخورد را از پشتیبانی جدا کنید
- اصل چهارم: حلقه را ببندید
- چه چیزی را نباید بپرسید
- یک نکتهٔ مهم دربارهٔ حریم خصوصی
- حلقه را چطور ببندیم: سه سطح
- سطح اول: تأیید دریافت (خودکار)
- سطح دوم: پاسخ انسانی (انتخابی)
- سطح سوم: اطلاع از رفع (باارزشترین)
- هویت گزارشدهنده: چرا مهم است
- دکمه را کجا بگذاریم؟
- سه نوع بازخورد و کاری که با هرکدام باید کرد
- گزارش باگ
- درخواست قابلیت
- ابراز سردرگمی
- بازخورد را چطور اولویتبندی کنیم
- از کجا بفهمیم دارد کار میکند؟
- جمعبندی
- منابع و مطالعهٔ بیشتر
اگر از تیمتان بپرسید «کاربران چه مشکلاتی دارند؟»، معمولاً جوابی میگیرید که بر پایهٔ چند ایمیل پشتیبانی و حدس ساخته شده است. مشکل این نیست که کاربران مشکلی ندارند؛ مشکل این است که اکثر قریب به اتفاق آنها هرگز به شما نمیگویند.
این مقاله دربارهٔ بستن همان شکاف است: چرا کاربران سکوت میکنند و چطور مسیری بسازیم که گفتن برایشان آسانتر از رفتن باشد.
چرا کاربران گزارش نمیدهند
وقتی کاربری به مشکل میخورد و چیزی نمیگوید، معمولاً یکی از این دلایل پشتش هست:
هزینهٔ گزارش دادن از ارزشش بیشتر است. پیدا کردن صفحهٔ «تماس با ما»، پر کردن فرمی با پنج فیلد اجباری، توضیح دادن مشکل با کلمات — همهٔ اینها کار است. رفتن رایگان است.
فکر میکنند تقصیر خودشان است. کاربر غیرفنی وقتی دکمهای کار نمیکند، اول به اینترنت خودش یا «بلد نبودن» خودش شک میکند، نه به سایت شما.
باور ندارند فرقی میکند. اگر قبلاً جایی بازخورد دادهاند و هیچ اتفاقی نیفتاده، دیگر تکرارش نمیکنند.
نمیدانند چطور توضیحش دهند. «یه چیزی درست کار نمیکنه» — این تمام چیزی است که خیلیها میتوانند بگویند، و خودشان هم میدانند که کافی نیست، پس بیخیال میشوند. هر کدام از این دلایل و راهحلش را در چرا کاربران باگ گزارش نمیدهند جداگانه باز کردهایم.
اصل اول: اصطکاک را حذف کنید، نه اینکه کمش کنید
هر مرحلهای که بین کاربر و ثبت بازخورد قرار میدهید، بخش بزرگی از گزارشها را حذف میکند. فرم تماسی که در صفحهٔ دیگری است، عملاً یعنی فقط عصبانیترین کاربران گزارش میدهند — و بازخورد آنها نمایندهٔ بقیه نیست.
مسیر ایدهآل این است: کاربر در همان صفحهای که مشکل را دیده، با یک کلیک، بتواند بگوید چه شد. بدون جابهجایی، بدون ورود به حساب، بدون فرم طولانی.
حداقل فیلد ممکن
وسوسه میشوید که نام، ایمیل، شماره تماس، دستهبندی مشکل و اولویت را بپرسید. هر فیلدی که اضافه میکنید، نرخ تکمیل را پایین میآورد. یک کادر متن و یک دکمهٔ ارسال کافی است. اگر کاربر لاگین کرده، حتی ایمیل هم نپرسید — شما از قبل میدانید او کیست.
اصل دوم: زمینه را خودتان جمع کنید، نه از کاربر
این مهمترین ایدهٔ این مقاله است. کاربر نمیتواند و نباید به شما بگوید که مرورگرش چیست، اندازهٔ صفحهاش چقدر است، در کدام آدرس بود، و چه خطایی در کنسول رخ داد. ولی نرمافزار شما همهٔ اینها را میداند.
یک گزارش بازخورد خوب باید خودکار شامل اینها باشد:
- اسکرینشات لحظهٔ گزارش — تفاوت بین حدس زدن و دیدن.
- آدرس دقیق صفحه — با پارامترها.
- اطلاعات مرورگر و دستگاه — بسیاری از باگها مخصوص یک مرورگر یا اندازهٔ صفحهاند.
- خطاهای کنسول همان نشست — اغلب علت فنی همانجاست.
- مسیر کاربر تا آن لحظه — چه صفحاتی دید و چه کلیکهایی کرد.
وقتی اینها خودکار ضمیمه شوند، جملهٔ «یه چیزی کار نمیکنه» ناگهان به گزارشی قابل پیگیری تبدیل میشود. رفتوبرگشت «دقیقاً چه دیدید؟» که معمولاً چند روز طول میکشد، کلاً حذف میشود. برای اینکه ببینید یک گزارش کامل چه بخشهایی دارد، قالب گزارش باگ خوب را ببینید.
اصل سوم: بازخورد را از پشتیبانی جدا کنید
«مشکلی دارم و کمک میخواهم» با «این خراب است، درستش کنید» فرق دارد. اولی نیاز به پاسخ سریع دارد، دومی نیاز به ثبت در صف توسعه.
اگر هر دو در یک صندوق بیفتند، معمولاً دومی گم میشود. تفکیک سادهای که جواب میدهد این است که در همان ویجت بازخورد، به کاربر اجازه دهید بگوید این «باگ» است یا «پیشنهاد» — و این دو به مسیرهای متفاوتی بروند.
اصل چهارم: حلقه را ببندید
کاربری که بازخورد داده و هیچ جوابی نگرفته، دیگر بازخورد نمیدهد. لازم نیست پاسخ مفصلی بدهید؛ حتی یک پیام کوتاه «دیدیم، در حال بررسی است» تفاوت بزرگی میسازد.
و وقتی مشکلی را واقعاً حل کردید، به کسی که گزارشش کرده بود خبر دهید. این کار دو اثر دارد: آن کاربر تبدیل به گزارشدهندهٔ همیشگی میشود، و معمولاً به بقیه هم میگوید که این تیم به بازخورد اهمیت میدهد.
چه چیزی را نباید بپرسید
چند اشتباه رایج که کیفیت بازخورد را پایین میآورند:
- «از ۱ تا ۱۰ چقدر راضی بودید؟» در لحظهٔ خطا. کاربر عصبانی است؛ عدد گرفتن از او اطلاعاتی به شما نمیدهد.
- پرسیدن دستهٔ فنی مشکل. کاربر نمیداند مشکلش «فرانتاند» است یا «پرداخت». این را خودتان تشخیص دهید.
- اجبار به ورود به حساب. بخشی از باگها اصلاً مربوط به همان صفحهٔ ورودند.
یک نکتهٔ مهم دربارهٔ حریم خصوصی
اگر اسکرینشات خودکار میگیرید، مسئولیت هم میپذیرید. ممکن است کاربر در حال پر کردن فرمی با اطلاعات شخصی یا مالی باشد. حداقل کاری که باید بکنید:
- فیلدهای رمز عبور همیشه و بهصورت خودکار محو شوند.
- امکانی باشد که فیلدهای حساس دیگر را هم علامت بزنید تا محو شوند.
- به کاربر نشان دهید چه اسکرینشاتی قرار است ارسال شود و اجازهٔ لغو بدهید.
- در سیاست حریم خصوصی سایتتان به این موضوع اشاره کنید.
شفافیت اینجا فقط الزام اخلاقی نیست؛ کاربری که میداند چه چیزی فرستاده میشود، راحتتر گزارش میدهد.
حلقه را چطور ببندیم: سه سطح
«بستن حلقه» شعار خوبی است ولی در عمل یعنی چه؟ سه سطح دارد و هرکدام هزینه و اثر متفاوتی دارند:
سطح اول: تأیید دریافت (خودکار)
بلافاصله بعد از ارسال، کاربر ببیند که گزارشش رسیده. همین یک جملهٔ ساده، بیشترین اثر را بهازای کمترین هزینه دارد، چون رایجترین دلیل نارضایتی این است که کاربر نمیداند اصلاً چیزی ارسال شده یا نه.
سطح دوم: پاسخ انسانی (انتخابی)
برای گزارشهایی که ابهام دارند یا کاربر ناراضی به نظر میرسد. لازم نیست به همه پاسخ دهید؛ ولی پاسخ به همانهایی که واقعاً وقت گذاشتهاند، معمولاً آنها را به گزارشدهندهٔ همیشگی تبدیل میکند.
سطح سوم: اطلاع از رفع (باارزشترین)
وقتی مشکل واقعاً حل شد، به کسی که گزارشش کرده بود خبر دهید. این کاری است که تقریباً هیچکس انجام نمیدهد و دقیقاً به همین دلیل اثرش زیاد است. برای این کار باید ایمیل یا شناسهٔ گزارشدهنده را به مشکل گره زده باشید — که یکی از دلایل مهم ثبت هویت گزارشدهنده است.
هویت گزارشدهنده: چرا مهم است
گزارشی که نمیدانید از چه کسی است، سه محدودیت جدی دارد: نمیتوانید سؤال بپرسید، نمیتوانید از رفع خبر دهید، و نمیتوانید بفهمید پنج گزارش مشابه از پنج نفر است یا از یک نفر پیگیر.
ولی یک نکتهٔ ظریف هست: ایمیلی که کاربر خودش تایپ میکند با هویتی که سیستم شما تأیید کرده یکی نیست. اولی قابل جعل است و ممکن است اشتباه تایپ شده باشد. اگر کاربر در سایت شما وارد حساب شده، هویتش را از نشست خودتان بردارید و اصلاً از او نپرسید — هم دقیقتر است و هم یک فیلد کمتر برای پر کردن.
برای کاربران مهمان، دستکم یک شناسهٔ پایدار در مرورگر نگه دارید. هویت واقعی نمیدهد، ولی به شما میگوید که این سه گزارش از یک نفر آمدهاند — که برای اولویتبندی تفاوت بزرگی است.
دکمه را کجا بگذاریم؟
جای ویجت بازخورد بیشتر از آنچه فکر میکنید روی نرخ استفاده اثر دارد. چند نکتهٔ عملی:
در همهٔ صفحات، نه فقط صفحهٔ اصلی. باگها معمولاً در صفحات داخلی و فرمها رخ میدهند، نه در صفحهٔ اول.
در سایتهای فارسی، سمت چپ. در چیدمان راستبهچپ، گوشهٔ پایین-راست معمولاً محل منوی اصلی، دکمهٔ بازگشت به بالا یا ویجت چت است. دکمهای که روی عنصر دیگری بیفتد، هم آزاردهنده است هم کلیکهای اشتباه میگیرد.
قابل جابهجایی باشد. هیچ موقعیتی برای همهٔ سایتها درست نیست. اگر کاربر بتواند دکمه را به سمت دیگر ببرد، مشکل تداخل خودبهخود حل میشود.
همیشه دیده شود، ولی غالب نباشد. پاپآپی که بعد از ۳۰ ثانیه میپرد وسط صفحه، بازخورد بیشتری نمیگیرد؛ فقط کاربر را عصبانی میکند.
سه نوع بازخورد و کاری که با هرکدام باید کرد
همهٔ بازخوردها یک جنس نیستند و برخورد یکسان با آنها باعث میشود مهمترینها گم شوند:
گزارش باگ
«این کار نمیکند.» قابل تأیید است: یا بازتولید میشود یا نه. باید مستقیم وارد صف توسعه شود و بر اساس تعداد کاربران متأثر اولویت بگیرد. چرخهٔ عمر یک باگ از همینجا شروع میشود.
درخواست قابلیت
«کاش میشد این کار را کرد.» قابل تأیید نیست و نباید در صف باگها بنشیند، وگرنه یا باگها را عقب میاندازد یا خودش برای همیشه فراموش میشود. جای درستش فهرست جداگانهای است که موقع برنامهریزی محصول مرور شود.
ابراز سردرگمی
«نفهمیدم این یعنی چه.» کمارزشترین به نظر میرسد و در واقع ارزشمندترین است. اگر یک نفر چیزی را نفهمیده، دهها نفر دیگر هم نفهمیدهاند و فقط چیزی نگفتهاند. اینها معمولاً با تغییر یک جمله حل میشوند و بیشترین اثر را بهازای کمترین کار دارند.
بازخورد را چطور اولویتبندی کنیم
وقتی جریان بازخورد راه افتاد، مشکل بعدی این است که همهچیز فوری به نظر میرسد. سه سؤال معمولاً کافی است:
- چند نفر؟ یک نفر که با اصرار پیگیری میکند، لزوماً نمایندهٔ بقیه نیست. بازخوردهای مشابه را بشمارید.
- کجای مسیر؟ مشکلی در ثبتنام یا پرداخت، وزنش با مشکلی در صفحهٔ تنظیمات قابل مقایسه نیست.
- راه دور زدن دارد؟ مشکلی که کاربر میتواند از راه دیگری انجامش دهد، از مشکلی که کاملاً مسدودش میکند کمفوریتتر است.
و یک اشتباه رایج: بازخورد کاربر جای تصمیم محصول را نمیگیرد. کاربران مشکلاتشان را خوب توصیف میکنند ولی راهحلهایشان معمولاً بهترین راهحل نیست. به آنچه میگویند نیاز دارند گوش کنید، ولی خودتان تصمیم بگیرید چطور حلش کنید.
از کجا بفهمیم دارد کار میکند؟
چند نشانهٔ ساده که برنامهٔ بازخورد شما سالم است:
- تعداد گزارشها بالا میرود، نه پایین. افزایش گزارش یعنی اعتماد بیشتر، نه محصول بدتر. کاهش ناگهانی معمولاً یعنی مسیر خراب شده یا کاربران ناامید شدهاند.
- نسبت گزارشهای قابل بازتولید بالاست. اگر بیشتر گزارشها نیاز به رفتوبرگشت دارند، یعنی زمینهٔ کافی جمع نمیکنید.
- فاصلهٔ گزارش تا پاسخ کوتاه است. این عدد بیش از هر چیز دیگری تعیین میکند کاربر بار دوم هم گزارش بدهد یا نه.
- گزارشها از کاربران متنوعی میآیند، نه فقط از چند نفر همیشگی.
جمعبندی
بازخورد کاربر منبعی نیست که بشود «جمعآوری» کرد؛ چیزی است که باید برایش مسیر ساخت. تیمهایی که بازخورد زیادی میگیرند، کاربران خاصی ندارند — فقط اصطکاک را حذف کردهاند، زمینه را خودشان جمع میکنند، و به کسانی که وقت گذاشتهاند جواب میدهند.
و نکتهٔ آخر: بازخورد کاربر مکمل رصد خودکار خطاست، نه جایگزین آن. رصد خودکار خطاهای فنی را میبیند ولی نمیداند کدام دکمه گیجکننده است؛ کاربر این را میداند ولی نمیتواند stack trace بدهد. تیمی که هر دو را دارد، تصویر کاملی از کیفیت محصولش دارد.
منابع و مطالعهٔ بیشتر
- First Rule of Usability? Don't Listen to Users — گروه نیلسن نورمن — تفاوت آنچه کاربران میگویند و آنچه واقعاً انجام میدهند
- Error-Message Guidelines — گروه نیلسن نورمن — پیام خطایی که کاربر را سرزنش نکند و راه نشان دهد
- How to Report Bugs Effectively — سایمن تاتام — مقالهٔ کلاسیک دربارهٔ اینکه گزارش مفید چه دارد
باگماگ را رایگان امتحان کنید
خطاهای سایتتان را خودکار ثبت کنید و بگذارید کاربران با یک کلیک باگ گزارش دهند.
شروع رایگان