https://virgool.io/feed/@m_75616744 پژوهشگر تجربهٔ کاربر در دیوار fa 2026-06-18 01:39:17 https://files.virgool.io/upload/users/571081/avatar/O9zWHp.jpeg?height=120&width=120 https://virgool.io/@m_75616744 https://virgool.io/DivarDesign/%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-%D8%AF%D8%B1-%D8%AF%DB%8C%D9%88%D8%A7%D8%B1-kxbsfgvlpuat تصویرسازی از آناهیتا آقایینیاز کلی به تست ریموتحالا نزدیک دو ساله که به خاطر کرونا دورکار هستیم و خیلی از شرکت‌های دنیا هم تصمیم گرفتن این مدل رو برای همیشه ادامه بدن. اما توی این شرایط، تأمین یکی از نیازهای اصلی ما پژوهشگران و طراحان تجربه‌ی کاربر، یعنی گرفتن تست کاربردپذیری (usability test) چی می‌شه؟ اگه می‌خواید راجع بهش بیشتر بدونید توی این شماره از خبرنامه‌مون بهش پرداختیم.فکر می‌کنم تقریباً نزدیکای عید ۹۹ بود که قرار شد برای محصول چت دیوار، تست کاربردپذیری بگیرم. ما به‌تازگی دورکار شده بودیم و باید برای این معضل راه‌حلی پیدا می‌کردیم. اون موقع اینجا نوشتم که چطوری از امکان به اشتراک‌گذاری صفحه در اسکایپ برای تست‌مون استفاده کردیم. اما فکر می‌کنم مزایای تست ریموت محدود به شرایط کرونا نمی‌شه و برای همه‌ی حالت‌ها مناسبه.از اون جایی که کاربرهای دیوار از سنین، شغل‌ها و شهرهای مختلفی هستند؛ حتی اگه امکان برگزاری تست حضوری رو هم داشتیم، نمی‌تونستیم از همه‌ی کاربرهای مناسبِ تست‌مون بخوایم به شرکت بیان. اینجوری عملاً افرادی رو که ساکن تهران نبودن یا امکان اومدن به تهران رو نداشتن از دست می‌دادیم و ما نمی‌خواستیم هزینه‌ی این سوگیری بزرگ رو (ساکن تهران بودن و امکان به تهران اومدن مخاطبانِ تست‌هامون) متحمل بشیم.در نتیجه تصمیم گرفتیم چالش‌های تست گرفتن رو به حداقل برسونیم. در این مطلب سعی کردم این چالش‌ها و راه‌حل‌هایی که براشون یافتیم رو توضیح بدم.باید بگم که برای فهمیدن این چالش‌ها و حل کردنشون، هر کدوم از اعضای چپتر پژوهش به‌نوعی سهم داشتن و بدون همکاری با همدیگه، رسیدن به این نتایج ممکن نبود.چالش‌های قبل از تستیکی از مشکلاتمون برای تست گرفتن، پایین بودن نرخ مشارکت کسانی بود که برای تست مناسب بودن. برای یافتن افراد مناسبِ تست، گروه هدف (target group) مورد نظرمون رو در هر تست مشخص می‌کردیم و برای تعدادی از اون‌ها پرسشنامه‌ می‌فرستادیم. در این پرسشنامه اطلاعات مورد نیازمون رو می‌پرسیدیم تا بدونیم فرد برای تست مناسب هست یا نه، و هم ازشون می‌پرسیدیم که آیا موافق انجام دادن تست هستن یا نه. سعید در این مقاله، در مورد اهمیت آماده کردن کاربرها برای تست‌ به‌تفصیل توضیح داده.مثلاً برای پیدا کردن مشکلات کاربردپذیریِ چت دیوار وقتی کاربر در مسدود کردن طرف مقابل ناموفقه، نیاز داشتیم از کسانی تست بگیریم که:۱. از چت دیوار استفاده کرده باشن.۲. با مخاطب خودشون به مشکل خورده باشن.۳. نتونسته باشن از گزینه‌ی «گزارش و مسدود کردن» استفاده کنن.علت اینکه نیاز داشتیم فرد حتماً این تجربه‌ی ناموفق رو داشته باشه این بود که می‌خواستیم از کسانی تست بگیریم که واقعاً به امکان «مسدود کردن» نیاز داشتن.چون اگه برای بار اول و حین تست دادن با این سناریو درگیر می‌شدن، در حالی که قبلاً به این امکان احساس نیاز نکرده بودن، این تجربه نمی‌تونست لزوماً دقیق و بدون سوگیری باشه. بنابراین، برای افرادی که طبق دیتای دیوار در یک هفته‌ی اخیر (برای اینکه هنوز نیازشون به اون ویژگی رو یادشون باشه) از چت استفاده کردن ولی کسی رو مسدود نکردن پرسشنامه‌ای فرستادیم و اول ازشون پرسیدیم که آیا براشون در این هفته پیش اومده که بخوان کسی رو در چت مسدود کنن ولی نتونن؟ بعد اگه جوابشون مثبت بود، در مورد شرایط تست سوال می‌پرسیدیم. مثل اینکه اسکایپ دارن یا مشکلی ندارن که نصب کنن؟ یا مشکلی ندارن صفحه‌ی گوشی‌شون رو در اسکایپ به‌اشتراک بذارن؟ و...در قدم بعدی، مشکل این بود که تعداد افراد واجد شرایط که برای شرکت در تست اعلام آمادگی کرده بودن کم بود. همچنین کسانی که در نهایت موفق می‌شدیم ازشون تست بگیریم از اون هم کمتر بود و گاهی مجبور می‌شدیم زمان زیادی برای پیدا کردن کاربر مورد نظرمون صرف کنیم. اون موقع بود که فکر کردیم نیازه این روند رو بهینه کنیم.در صحبت با کسانی که برای تست اعلام آمادگی کرده بودن فهمیدیم عدم شفافیتِ روند فعلی یکی از بزرگترین موانعِ ما در یافتن افراد مناسبه. ضمن اینکه ما مشکل کمبود دیتا (یعنی کمبود نفرات مناسب برای تست) نداشتیم. چون برای هر مسئله‌ای که نیاز به تست کاربردپذیری داشت، تعداد کاندیداهای زیادی داشتیم. همچنین برامون مهم بود فردی که به مرحله‌ی نهایی برای تست می‌رسه، توجیه باشه و فرایند تست بدون مانع پیش بره. پس برای شفاف کردن مراحل، پرسشنامه‌ی اول رو بازتولید کردیم. این بار مرحله به مرحله به کاربر توضیح دادیم قراره چه اتفاقی بیفته و در صورتی به مرحله‌ی بعدی می‌فرستادیمش که با شرایط موافق باشه. این پرسشنامه آخرین ورژنیه که برای کاربر ارسال می‌کنیم.زمانی می‌تونستیم بگیم این پرسشنامه راهکار مناسبی بوده که در تماس تلفنی برای هماهنگی با کاربر، دیگه نیازی به توضیح روند تست نباشه و هماهنگی کمترین وقت رو بگیره. چون در برخی موارد به نظر می‌رسید توضیحات متنیِ پرسشنامه برای بیان بعضی پیچیدگی‌ها کافی نیست، تصمیم گرفتیم از ویدیو برای توضیح بیشتر استفاده کنیم. می‌دونستیم احتمالاً نرخ باز کردن ویدئو خیلی بالا نباشه. ولی همونطور که بالاتر گفتم، به نفرات زیادی دسترسی داشتیم و اینجا برای ما کیفیت مهم بود نه کمیت. بنابراین با کمک باهار، امید و سعید سناریوی یک فیلم آموزشی برای کاربر رو نوشتیم و ساختیمش. این فیلم به انتهای پرسشنامه‌ی کاربرگزینی الصاق شد. قرار شد به همراه پیامکی که برای نصب اسکایپ به منتخبان نهایی تست‌مون می‌زنیم، لینک این فیلم رو هم اضافه کنیم تا احتمال دیده‌شدنش رو افزایش بدیم.چالش‌های حین تستتعداد نفرات لازمقبل‌تر شنیدیم که طبق گفته‌ی nn group (در سال ۲۰۰۰) اگه تست رو تنها با ۵ نفر بگیریم، تا حد خوبی برای فهمیدن مشکلات کاربردپذیری کفایت می‌کنه. ولی این ۵ از کجا اومده؟ آیا واقعاً تست گرفتن با ۵ نفر می‌تونه بهمون درصد موفقیتِ هر تسک رو بده؟ جواب این سوال بستگی به هدف‌مون از تست گرفتن داره.اگه قراره مشکلات طراحی رو شناسایی کنیم یا ابهامات و ایرادهای طراحی‌مون رو متوجه بشیم، بله ۵ نفر احتمالاً کافیه. البته با این فرض که قرار نیست خروجی کمّی برای میزان موفقیت افراد در هر تسک ارائه کنیم.ولی اگه قراره خروجی کمّی ارائه بدیم، مثلاً برای مقایسه‌ی بهبود عملکرد افراد در انجام دادن یک تسک قبل و بعد از تغییر در محصول، یا برای مقایسه‌ی عملکرد اون‌ها در انجام دادن یک تسک واحد در اپلیکیشن‌های مختلف، استناد به کافی بودن ۵ نفر برداشت اشتباه (و رایجی) است. ولی چرا؟ در ادامه بیشتر توضیح می‌دم.وقتی برای فهمیدن بهبود طراحی یا مقایسه‌ی انجام دادن تسک در چند اپ به اعداد و درصدها نیاز داریم، یعنی لازم داریم بدونیم در مقیاس بزرگ و در تعداد زیاد کاربر این مقایسه‌ چطوریه. به این معنی که اگر کل افراد جامعه‌ی مورد نظر ما (یا همون segment group مورد نظرمون) ابتدا طرح ۱ رو می‌دیدن، چند درصدشون به مشکل X برمی‌خورن و حالا که طرح ۲ رو می‌بینن آیا نسبت کسانی که به همون مشکل برخوردن کمتر شده؟ولی آیا ما به همه‌ی افراد جامعه‌مون دسترسی داریم؟ طبیعتاً نه. اینجاست که سر و کله‌ی آمار و انداز‌ه‌ی نمونه پیدا می‌شه.اینجا می‌خوام یک پرانتز باز کنم و مسئله رو به‌صورت آماری توضیح بدم. پس اگر حوصله‌ی محاسبات آماری رو ندارید یا براتون جالب نیست، این بخش رو تا انتهای پرانتز رد کنید.پرانتز بازاز اون جایی که ما نمی‌تونیم روی همه‌ی جامعه آزمایش کنیم، لازمه روی نمونه‌ی مناسبی از جامعه‌ آزمایش کنیم و بعد مقدار حاصل از آزمایش‌مون رو به جامعه تعمیم بدیم. روش‌های مختلف و همچنین ماشین‌حساب‌های محاسبه‌ی آنلاین زیادی برای نمونه‌گیری و تعیین اندازه‌ی نمونه از جامعه وجود داره. برای مثال به اینجا نگاه کنید. همونطور که می‌بینید شما با در نظر گرفتن سطح اطمینان (confidence level) و میزان خطا (confidence interval) می‌تونید از روی اندازه‌ی جامعه‌تون به اندازه‌ی نمونه‌ی مناسب برسید.مثلاً اگر بخوایم مقدار یک متغیر رو در جامعه‌ی ۱۰۰۰ نفری با اطمینان ٪۹۵ و خطای ٪۷ تخمین بزنیم، کافیه اون متغیر رو در یک نمونه‌ی ۱۶۴ تایی رندم از اون جامعه اندازه بگیریم. اگه اون متغیر در نمونه‌ی ما ٪a باشه، با اطمینان ٪۹۵ مقدار متغیر مورد نظر در جامعه بین ٪(۷-a) تا ٪(۷+a) است.اینجا لازمه به این نکته‌ اشاره کنم که وقتی اندازه‌ی جمعیت از یک مقداری بزرگ‌تر می‌شه، دیگه خیلی تأثیری روی اندازه‌ی نمونه نداره و به‌اصطلاح نمونه اشباع می‌شه. مثلاً در سایز جامعه با مقدار ۱۰۰,۰۰۰ و یک بار ۱,۰۰۰,۰۰۰ با خطای ٪۵، اندازه‌ی نمونه از ۳۸۳ به ۳۸۴ نفر تغییر می‌کنه و حتی اگه اندازه‌ی جامعه رو بزرگ‌تر کنید، دیگه اندازه‌ی نمونه عوض نمی‌شه. این اتفاقیه که معمولاً برای ما در دیوار می‌افته، یعنی جامعه‌ی هدف مورد نظر ما انقدر بزرگه که نمونه اشباع می‌شه.در ماشین‌حساب‌ آنلاینی که بالاتر لینکشو گذاشتم، در صورتی که سایز جامعه رو خالی بذاریم، سایز نمونه‌ رو با فرض اشباع شدن بهمون می‌ده.همه‌ی این‌‌ پیش‌نیازها رو گفتم تا برگردم سراغ اون ۵ کاربر معروف تست‌های کاربردپذیری! حالا بیاید اندازه‌ی خطا رو در اون ماشین‌حسابِ اندازه‌‌ی نمونه، انقدر عوض کنیم تا به اندازه‌ی نمونه‌ی ۵ نفر برسیم. اگه خطا رو ٪۴۰ بذاریم، اندازه‌‌ی نمونه ۴ می‌شه. با یکم بالا پایین کردن خطا، می‌بینیم که در خطای ٪۴۲ اندازه‌ی نمونه ۵ نفره. یعنی چی؟ یعنی اگر بخوایم نتایج عددی حاصل از یک نمونه‌ی ۵ تایی رو به کل جامعه تعمیم بدیم، ٪۴۲ خطا داریم.یکم دقیق‌تر بشیم: مثلاً اگر تسکی در این ۵ نفر ٪۸۰ موفقیت داشته باشه، می‌تونیم بگیم ٪۴۲+-٪۸۰ یعنی بین ٪۳۸ تا ٪۱۰۰ (درسته که ۸۰+۴۲=۱۲۲، ولی بزرگتر از ۱۰۰ که معنی نداره) افراد جامعه هم اون خطا رو دارن. معنیش چیه؟ یعنی ممکنه اون مشکل در جامعه اهمیت نسبتاً کم (٪۳۸ افراد فقط باهاش مشکل داشتن) یا اهمیت خیلی زیاد (٪۱۰۰ افراد جامعه!) داشته باشه. طبیعتا وقتی بازه‌ی اینقدر بزرگی رو ارائه دادیم، این تخمین به هیچ درد ما نمی‌خوره. برای همین وقتی از تعداد ۵ یا ۶ نفر برای تست کاربردپذیری استفاده می‌شه، ارائه‌ی خروجی عددی و کمّی معنی نداره. پیشنهاد می‌کنم برای تفریح این محاسبات رو برای اندازه‌ی نمونه‌ی ۴ نفر هم امتحان کنید. خطا در این شرایط ٪۴۷ می‌شه، در این حالت اگر تسکی در هر ۴ نفر با مشکل پیش بره، در جامعه هم بین ٪۵۳ تا ٪۱۰۰ افراد باهاش به مشکل می‌خورن. یعنی تسکی که در نمونه همه باهاش مشکل داشتن، صرفاً حدود نصف افراد جامعه رو درگیر می‌کنه. در نتیجه به نظر می‌رسه اگه اندازه‌‌ی نمونه زیر ۵ نفر باشه، حتی اگه همگی در تسکی با خطا روبرو بشن، نمی‌شه با اطمینان گفت این خطا خیلی مهمه.با این حال ممکنه در مواردی لازم داشته باشیم بهبود طراحی‌مون رو با مقادیر عددی حاصل از تست کاربردپذیری اندازه بگیریم. در این شرایط باید برای کاهش خطا، اندازه‌‌ی نمونه رو بزرگتر کنیم. اینجا می‌تونید مقاله‌ی nn group رو که در همین مورد و در سال ۲۰۲۱ منتشر شده، بخونید.پرانتز بستهاگه قرار باشه درگیر محاسبات هم نشیم، می‌تونیم شهودی ببنیم وقتی تستی رو با ۵ نفر می‌گیریم، احتمالش خیلی زیاده که افراد سوگیرانه انتخاب شده باشن. پس طبیعتاً کار عجیبیه که به دیتای عددی حاصل از تست با ۵ نفر اعتماد کنیم. با نتایج این تست، ممکنه صرفاً بتونیم برخی ایرادات رو مشاهده کنیم.اگر در دیوار بخوایم با این تعداد محدود تست بگیریم، تمام تلاشمون رو می‌کنیم که از کاربرهای واقعی‌ در نقاط مختلف و با دانش‌های زمینه‌ای، آشنایی با تکنولوژی، جنسیت، شغل، نیاز و... متفاوت انتخاب کنیم.پس در دیوار، چجوری از تست‌های کاربردپذیری با تعداد نفرات کم استفاده می‌کنیم؟ ما صرفاً سعی می‌کنیم مشکلات رو مشاهده و گزارش کنیم و هیچ تأکیدی روی خروجی کمّی نمی‌کنیم. مگر اینکه مثلاً در توافق با طراح یا مدیر محصول ایراداتی که می‌دونیم با اطمینان بیش از نیمی از جامعه حتماً درگیرش هستن رو اعلام کنیم. اون هم بدون مقایسه‌ی اولویتشون نسبت به هم. خلاصه تمرکزمون رو می‌ذاریم روی خروجی‌های کیفی حاصل از تست. در این مقاله از nn group‌ می‌تونید راجع به تفاوت‌های خروجی کمّی و کیفی تست‌های کاربردپذیری بیشتر بخونید.نحوه‌‌‌ی تست گرفتنبرای گرفتن تست کاربردپذیری ریموت می‌شه از دو روش moderated و unmoderated استفاده کرد. در روش اول (یعنی moderated) پژوهشگری که تست می‌گیره و کاربری که داره تست می‌ده، هر دو آنلاین هستن و فرصت تعامل با همدیگه رو دارن اما در روش دوم (یعنی unmoderated) این فرصت وجود نداره و فیلمِ نحوه‌ی انجام دادن تسک‌ها بعد از پایان تست در اختیار پژوهشگر قرار می‌گیره.در دیوار، ما بیشتر تست‌هامون رو از نوع moderated می‌گیریم تا بتونیم در تعامل با کاربر بیشترین بهره رو ببریم. در مورد اینکه فرایند تست گرفتن به چه صورته و خوبه که چه نکاتی رعایت بشه، محتواهای زیادی وجود داره. اگه خواستید در این مورد بیشتر بخونید، اینجا خوب و مختصر بهش اشاره کرده.با توضیحاتی که تا اینجا دادم، فکر می‌کنم مشخص شده باشه که چرا برای تست‌هامون با تعداد محدود time on task و SUS (به عنوان معیاری برای اندازه‌گیری رضایت) رو اندازه نمی‌گیریم.چالش‌های بعد از تستخروجی نهایی تست‌های کیفی رو به روش‌های مختلفی می‌شه نشون داد که به توافق پژوهشگر، طراح و مدیر محصول بستگی داره. ما هم چندین مدل رو امتحان کردیم و فعلاً داریم در این فرمت ارائه‌ش می‌دیم:حروف انگلیسی نوشته شده معنی خاصی ندارن، برای مثال نوشته شدن :‌)شرح توافق‌های ما در این فرمت:رنگ‌های خونه‌های کاربران ۱ تا ۶ بر این اساسه: قرمز یعنی تسک انجام نشده. زرد یعنی به سختی انجام شده. سبز یعنی به راحتی انجام شده.عدد در ستون موفقیت، تعداد تسک‌های انجام‌شده تقسیم بر تعداد کل نفراتیه که تسک رو دیدن.عدد در ستون سهولت هم تعداد افرادیه که با سهولت و راحتی تسک رو انجام می‌دن تقسیم بر تعداد نفراتی که موفق به انجام تسک شدن.برای رنگ‌بندی در ستون موفقیت و سهولت، از این قاعده‌ی کلی پیروی می‌کنیم: اگر در تسکی با احتساب خطای نمونه‌گیری‌مون، قطعاً بالای ۵۰٪ سهولت یا موفقیت داشتیم، رنگ اون خونه سبزه. اگر در تسکی با احتساب خطای نمونه‌گیری‌مون، قطعاً کمتر از ۵۰٪ سهولت یا موفقیت داشتیم رنگ اون خونه قرمزه. و رنگ باقی خونه‌ها که نمی‌شه با اطمینان گفت بزرگتر یا کوچکتر از ۵۰٪ هستن، زرده.در مورد تسک‌هایی که برای اجرای اون‌ها بیشتر از یک مسیر وجود داره، مشابه تسک ۱ و ۳ عمل می‌کنیم. این مسیرها نباید نسبت به هم اولویتی داشته باشن. در غیر این صورت مسیر ترجیحی به عنوان مسیر موفقیت تعریف می‌شه.اعداد دو ستون آخر برای مشخص کردن منطق رنگ‌دهی گذاشته شده و به هیچ وجه نشون دهنده‌ی میزان اهمیت تسک نیست.بیشتر از دو ستون رنگی آخر، جزئیات و ایرادهایی که حین تست مشاهده می‌کنیم برامون مهمه. این اطلاعات رو توی جدول برای هر فرد و هر تسک گزارش می‌کنیم.تجربه‌ی شمااین‌ها خلاصه‌ای بود از چالش‌هایی که در راه گرفتن تست کاربردپذیری از راه دور سعی کردیم حلشون کنیم. برامون جالبه بدونیم شما هم با این چالش‌ها مواجه شدین؟ چطور حلش کردین؟ برامون بنویسین. آلما روشنی آلما روشنی Wed, 15 Dec 2021 19:01:39 +0330 https://virgool.io/DivarDesign/%D8%AD%D9%84-%D9%85%D8%B3%D8%A6%D9%84%D9%87-%DB%8C-%D9%BE%D8%A7%DB%8C%DB%8C%D9%86-%D8%A8%D9%88%D8%AF%D9%86-%D9%86%D8%B1%D8%AE-%D9%BE%D8%A7%D8%B3%D8%AE-%D8%AF%D9%87%DB%8C-%D8%AF%D8%B1-%DA%86%D8%AA-oo33ti84l7jz تصویرسازی از آناهیتا آقاییدر این یادداشت قراره یک مطالعه موردی از همکاری خودم به عنوان پژوهشگر تجربه‌ی کاربر با سعید اسماعیلی به عنوان تحلیلگر داده رو برای حل مسئله‌ای در تیم ارتباطات توضیح بدم.نحوه‌ی تعامل UX Researcher و Data Analyst در حل مسائلدیوار پلتفرمی با بیش از ۳۵ میلیون کاربره که رفتار‌های متفاوتی در این محصول دارند. مطالعه و بررسی رفتار‌های کاربرانمون در دیوار، بهمون اطلاعات ارزشمند زیادی برای بهبودش می‌ده. برای همین هم همکاری تنگاتنگی بین اعضای محصولی هر تیم با تحلیلگران داده داریم. مثلا: گاهی لازمه تا با کمک تحلیل داده‌های کاربرانمون، مشکلاتشون رو بشناسیم. گاهی مشکلات رو می‌شناسیم و با کمک تحلیل داده‌ها اون‌ها رو اولویت‌بندی می‌کنیم. گاهی برای جدا کردن بخشی از کاربران مورد نظرمون از تحلیل دیتاهاشون استفاده می‌کنیم. و موارد بسیار دیگه‌ای... این بار برای محاسبه‌ی هزینه‌ی راه‌حل‌هامون از دیتاهای کاربرانمون استفاده کردیم. توی این یادداشت قراره به بررسی همین مورد بپردازم.*سعید؛ تحلیلگر داده‌ی صنف تجربه قراره در آینده‌ای نزدیک یادداشتی درباره‌ی همکاری داده و پژوهش در حل مسائل دیوار بنویسه و دقیق‌تر توضیح بده. بعد از انتشار یادداشت، اینجا لینک مطلب رو می‌ذارم.*تو این مطلب در ابتدا به تعریف ادبیات موضوع می‌پردازم. بعد مسئله‌مون در تیم ارتباطات رو شرح می‌دم. و در ادامه به بررسی راه‌حلمون و نحوه‌ی استفاده‌ از داده برای اندازه‌گیری اثر راه‌حلمون اشاره می‌کنم.تعریف نرخ پاسخ‌دهییکی از وظایف ما در تیم ارتباطات دیوار، راحت‌تر کردن ارتباط خریدار و فروشنده با چت دیواره. پس از بررسی و صحبت با خریداران، متوجه شدم برخی خریداران وقتی با فروشنده چت می‌کنند جوابی از اون‌ها نمی‌گیرند. یا فروشنده خیلی دیر جوابشون رو می‌ده و این باعث نارضایتی خریداران می‌شه.ما برای اینکه وضعیت پاسخ‌دهی فروشنده‌ها رو بدونیم، متریک نرخ پاسخ‌دهی رو اینجوری تعریف کرده بودیم: اگه فروشنده تا ۲۴ ساعت به خریدار جواب نده، فرض می‌کنیم خریدار پاسخی دریافت نکرده. و روزانه محاسبه می‌کردیم فروشنده چند درصد از چت‌ها رو زیر ۲۴ ساعت جواب داده. این درصد در هر دسته‌ی کالایی، می‌شد نرخ‌ پاسخ‌دهی به چت در اون دسته.شفاف‌سازی مسئلههمونطور که بالاتر توضیح دادم، متوجه شدم که برخی از خریدار‌هامون از فروشنده‌ها پاسخی نمی‌گیرند. بنابراین نرخ پاسخ‌دهی رو در دسته‌های کالایی مختلف بررسی کردم. و متوجه شدم نرخ‌ پاسخ‌دهی به طرز معنی‌داری در دسته‌های املاک، خودرو و برای کسب‌وکار‌ها از بقیه‌ی دسته‌ها پایین‌تره. حالا سوال این بود که چرا؟فهمیدن این مسئله بهمون کمک می‌کرد تا مشکلات فروشنده‌ها رو برای پاسخ‌دهی حل کنیم. در اون صورت می‌تونستیم این نرخ رو افزایش و مشکلاتی که برای خریدارهامون به واسطه‌ی پاسخ ندادن فروشنده پیش اومده بود، بهبود بدیم.مراحل انجام پژوهشابتدا تحلیلگر داده نمونه‌هایی رو از فروشنده‌هایی که در ۳ دسته‌ی مذکور نرخ پاسخ‌دهی پایینی داشتند در اختیارم گذاشت. این نمونه‌ها رو بررسی کردم و تصمیم گرفتم از روش «مصاحبه‌ی عمیق» با کاربر برای فهم دلایل عدم پاسخ‌دهی فروشنده‌ها استفاده کنم. علت این تصمیم‌گیری این بود که حدس می‌زدم برخی از این فروشنده‌ها تمایلی نداشته باشند تا به عدم پاسخ‌دهیشون به خریدارها اشاره‌ای کنند. من نیاز داشتم در بستر امنی با فروشنده‌ها صحبت کنم تا اطمینان داشته باشند که مشکلی براشون پیش نمیاد و دلایل عمیقشون رو برای پاسخ ندادن به خریدار بهم بگند.در ادامه برخی از این دلایل رو مرتب کردم:از مصاحبه‌ها این طور به نظر می‌رسید که عمده دلایل فروشندگان برای پاسخ ندادن به خریدار وابسته به عدم تمایلشون برای دریافت پیام در چت دیوار بوده. پس چرا چت رو برای آگهی‌هاشون فعال نگه داشتند؟از طرفی در صحبت‌هایی که باهاشون داشتم به نظرم رسید متوجه این نکته نیستند که می‌تونند در صورت عدم تمایل به پاسخ‌دهی به چت‌ها، تنظیمات دریافت چت رو برای آگهی‌هاشون خاموش کنند. در واقع حین ثبت آگهی، گزینه‌ای برای فعال بودن چت آگهی وجود داره که به صورت پیش‌فرض تیک خورده ولی می‌شه خاموشش کرد. به نظر می‌رسه اصل گزینه‌ی پیش‌فرض، باعث شده تا افراد حواسشون به خاموش کردن گزینه در حالتی که تمایل به چت ندارند، نباشه.مورد بعدی که در این مصاحبه‌ها دیده شد این بود که تعداد خوبی از این افراد بیزنس‌هایی بودند که در این دسته‌ها فعالیت می‌کردند. و علت پاسخ ندادنشون هم این بود که فرصت نداشتند. البته این مورد رو نمی‌شد با اطمینان گفت چون ما داشتیم یک ارزیابی کیفی (مصاحبه) با تعداد ناکافی اندازه‌ی نمونه انجام می‌دادیم. ولی دلیل دیگه‌ای هم داشتیم که این مورد رو برامون محتمل‌تر می‌کرد و اون هم این بود که ما این مشاهده رو (پایین‌تر بودن نرخ پاسخ‌دهی) در سه دسته‌ای داشتیم که فعالین بیزنسی توش زیادتر بودند. یعنی املاک و خودرو و برای کسب‌و‌کارها.بنابراین حالا یک فرضیه‌ی جدید داشتیم که نیاز بود راستی آزمایی کنیم!به نظر می‌رسید «برخی از افرادی که رفتار بیزنسی داشتند، متوجه این که می‌تونند تیک پیش‌فرض فعال بودن چت آگهی رو بردارند، نبودند.»و اگه این فرضیه درست بود، ما می‌تونستیم تیک پیش‌فرض چت رو برای این افراد خاموش کنیم. البته با در نظر گرفتن ملاحظاتی که در ادامه بهشون می‌پردازم. البته راه رو برای کسانی که می‌خواستند چتشون فعال بمونه نمی‌بستیم. صرفا تنظیماتش رو از حالت پیش‌فرضِ روشن به خاموش تغییر می‌دادیم. در اون صورت اگه کسی هم به واسطه‌ی مدت محدودی عدم فعالیت، پیش‌فرض چتش خاموش شده بود می‌تونست حین ثبت آگهیش روشنش کنه.البته این تغییر واقعا تغییر بزرگی در محصول محسوب نمی‌شد. ولی به دلایلی که در ادامه شرحش می‌دم، نتیجه‌ی ارزشمندی داشت.ملاحظاتخاموش کردن تیک پیش‌فرض چت برای افرادی که بیزنس بودند، برای ما هزینه داشت. هم به خاطر اینکه زیرساخت این کار رو نداشتیم و نیاز به تغییرات بک‌اندی داشتیم و هم این که همه‌ی افرادی که رفتار بیزنسی داشتند، لزوما در دسته‌ی پاسخ‌ندهندگان به چت نبودند. پس نیاز داشتمدر وهله‌ی اول:تعریفمون رو از افرادی که لازمه روشون اکشنی بزنیم، دقیق‌تر کنیم.کسانی که در این دسته‌ها رفتار بیزنسی داشتند، احتمالا افرادی بودند که تعداد آگهی‌های فعالشون در لحظه بزرگتر مساوی *۳ تا بود. همچنین همه‌ی این افراد جز پاسخ‌ندهندگان نبودند. پس فرض کردیم که اگه پایین *۳۰% از پیام‌هاشون رو هم در ۲۴ ساعت اول پاسخ داده باشند، احتمالا جزء پاسخ‌ندهندگان هستند.*برای پیدا کردن این اعداد با کمک سعید، به دیتای کل فروشنده‌هامون نگاه کردیم. با دیدن بازه‌ی تعداد آگهی‌های فعال همه‌ی فروشنده‌ها و بازه‌ی درصد پاسخ‌دهی به پیام‌هاشون، دیدی اولیه از این اعداد بدست آوردیم. ولی برای مطمئن شدن، در انتها این محاسبات رو با اعداد فرضی دیگری هم انجام دادیم. نهایتا این مقادیر حاصل، بهترین و کم‌ریسک‌ترین مقادیر ممکن بودند.و در وهله‌ی دوم:لازمه با محاسبات عددی نشون بدیم که در صورت انجام این تغییر، چه درصدی از افراد مشکلاتشون برطرف می‌شه. و اینکه چقدر هم موجب افزایش نرخ پاسخ‌دهی می‌شه. بنابراین اعضای فنّی تیم می‌تونستن با بررسی هزینه‌ای که لازمه برای این کار داده بشه و میزان دستاوردی که داره، برای انجامش تصمیم بگیرند.راستی‌آزمایی فرضیهحالا باید به نحوی متوجه می‌شدم که آیا فرضیه‌ای که داشتم درسته یا نه. فهمیدن درستی این فرضیه ارزشمند بود. به دو دلیل:بخشی از فروشنده‌هامون که مایل به دریافت پیام نبودند، دیگه پیامی دریافت نمی‌کردند. و مشکلاتی که بابت پر شدن اینباکس و نوتیف‌های فراوون در چت داشتند برطرف می‌شد.خریدارهایی که به این افراد پیام می‌دادند، از اون جایی که چت این افراد فعال بود، توقع پاسخ‌دهی داشتند. ولی این فروشنده‌ها پاسخ نمی‌دادند. و باعث ایجاد مشکل برای این خریدارها می‌شد.البته افزایش نرخ پاسخ‌دهی با این راه حل، به تنهایی چیز مطلوبی نیست. چون واقعا میزان «پاسخ‌دهی» عوض نشده. ولی این متریکی بود که در اون زمان اندازه‌ش می‌گرفتیم و بر اساسش اکشن‌هایی انجام می‌دادیم. پس همچنان میزان افزایشش برامون ارزشمند بود.حالا چطور باید درستی این فرضیه رو بررسی کرد؟این قسمت هم با همکاری سعید جلو رفت. برای بررسی این فرضیه، لازم داشتیم ببینیم اگه در ابتدای ماه گذشته پیش‌فرض چت رو برای آگهی‌های بعدی افراد مورد نظرمون که بیزنسند و پاسخگو هم نیستن خاموش می‌کردیم، در انتهای ماه نرخ پاسخ‌دهی کلی اون دسته چقدر عوض می‌شد؟ در واقع برای فهمیدن نتیجه‌ی تغییراتمون در آینده، گذشته رو نگاه کردیم. و دیدیم این تغییر می‌تونسته به صورت بالقوه چه اثری روی نرخ پاسخ‌دهی بذاره.برای این محاسبه، چند فرض ساده شونده کردیم تا تخمینی حدودی از تفاوت نرخ پاسخ‌دهی درابتدای ماه قبل و انتهای ماه قبل داشته باشیم:فرض کردیم در ابتدای ماه قبل همه‌ی افرادی که چتشان فعال است، پاسخ‌دهنده بوده‌اند. با این فرض نرخ پاسخ‌دهی ۴۵.۷٪ بود. که البته قطعا نرخ واقعی کوچکتر مساوی این مقدار بوده است. چون برخی از این افراد دیرتر از ۲۴ ساعت به پیام‌هایشان جواب داده‌اند که در این صورت نباید جز پاسخ‌دهنده‌ها حساب شوند.فرض کردیم در انتهای ماه قبل همه‌ی افرادی که زیر ۳۰٪ پاسخ‌دهی داشته‌اند، چتشان خاموش بوده‌است و دیگر پیامی دریافت نکرده‌اند و چتشان را هم روشن نکرده‌اند. در این حالت نرخ‌ پاسخ‌دهی به ۷۳.۲٪ می‌رسید. البته احتمالا در واقعیت، برخی از این افراد (که پاسخ‌دهی خیلی کمی داشتند) حتما چتشان را روشن می‌کردند. ولی حدسمان این بود که تعدادشان زیاد نباشد. چون در طول یک ماه به کمتر از ۳۰٪ از پیام‌هاشون پاسخ داده بودند. پس فرض پر ریسکی نکرده بودیم.نتیجه خیلی جالب توجه بود! همونطور که اشاره شد، دیدیم نرخ پاسخ‌دهی می‌تونه از حدود ۴۵.۷٪ به ۷۳.۲٪ تغییر پیدا کنه که عدد جالب توجهیه و تونستیم با این محاسبات نشون بدیم پرداختن هزینه‌های فنّی این تغییر می‌تونه چه تاثیر بزرگی هم روی افزایش نرخ پاسخ‌دهی و هم روی کاهش مشکلات خریدار و فروشنده بذاره.البته شاید کار دقیق‌تر این بود که A/B تست بگیریم. ولی هزینه‌ای که از نظر زمانی و زیرساختی داشت، از این تخمین‌ها و محاسبات خیلی سنگین‌تر بود. بنابراین این راه رو رفتیم.مرسی از حسام حداد، دیگر تحلیلگر داده‌ در تیم ارتباطات که در این مسیر بهمون کمک کرد. آلما روشنی آلما روشنی Sat, 10 Apr 2021 18:39:02 +0430 https://virgool.io/DivarDesign/%D8%B1%D8%A7%D9%87-%D8%B1%D9%81%D8%AA%D9%86-%D8%A8%D8%A7-%DA%A9%D9%81%D8%B4-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1-ols3gqxiadqs تصویرسازی از آناهیتا آقایی https://virgool.io/p/ols3gqxiadqs/%F0%9F%93%B7 من پژوهشگر تجربه‌ی کاربر در قبیله‌ی کالا و تیم فروشگاه دیوار هستم. برای شناخت بهتر مفهوم قبیله و تیم در دیوار می‌تونین به این مقاله مراجعه کنین.همچنین برای اینکه در مورد نقش پژوهشگران تجربه‌ی کاربر در محصول بیشتر بخونین، می‌تونین به این مقاله مراجعه کنین.پا در کفش کدام کاربران دیوار کردیم؟دیوارِ فروشگاه‌ها جاییه که فروشنده‌های کالای نو می‌تونن توش فروشگاه بسازن و محصولاتشون رو برای فروش آگهی کنن. البته آگهی‌های فروشگاهی فرق‌هایی هم با آگهی‌های شخصی دارن. مثلا اینکه منقضی نمی‌شن و همیشه در صفحه‌ی فروشگاه هر فروشنده باقی می‌مونن.دیوارِ فروشگاه‌ها در دوران کرونا به دنیا اومده تا خریدارها و فروشنده‌ها بتونند به صورت غیرحضوری خرید و فروش انجام بدن. از اون جایی که این محصول هنوز خیلی جوونه، لازمه که خیلی ایرادات و نقاط تاریک و روشنش رو بررسی کنیم.ما در تیم محصول فروشگاه، همواره در تلاشیم مشکلات کاربرهامون رو شناسایی و حل کنیم. همچنین خلأهایی که محصول فعلی داره رو روز به روز پر کنیم و خدمات مفیدتری ارائه بدیم. برای همین پژوهش‌های زیادی در زمینه‌ی مشکلات فروشندگان و خریدارانمون انجام دادیم و در ادامه هم خواهیم داد. و تا جایی که می‌تونیم برای این مشکلات راه‌حل ارائه می‌کنیم.از طرفی از اون جایی که معتقدیم «محصولاتی خلق می‌کنیم که خودمون هم مشتاق استفاده ازشون هستیم.» بنابراین چند ماه پیش در تیم تصمیم گرفتیم برای بهتر درک کردن فروشندگان دیوارِ فروشگاه‌ها، خودمون هم به عنوان فروشنده ثبت‌نام کنیم. البته نه برای صرفا تست کردن! بلکه قرار شد تا واقعا کالاهایی رو در فروشگاه برای فروش بذاریم. اینطوری می‌تونستیم تقریبا تجربه‌ی کاربر فروشنده رو درک کنیم و به سختی‌ها و پیچیدگی‌های فلوهایی که طراحی کرده بودیم آگاه بشیم.بنابراین من هم فروشگاهم رو ثبت کردم. و این تازه شروع بینش‌گیری -این بار به عنوان فروشنده- از فلوهای موجود بود.بینش‌گیری از فرآیندهااین بینش‌گیری دو بخش داشت. اول ثبت‌نام و ثبت‌ آگهی در فروشگاه و دوم فروش در فروشگاه. حین ثبت‌نام مواردی داشتیم که این فلو رو پیچیده می‌کردند. مثلا اینکه ممکن بود فروشنده پروانه‌ی کسب نداشته باشه (مثل من) ولی کالایی برای فروش داشته باشه. که در ادامه پروانه‌ی کسب و کار رو برای فروشنده‌ها به صورت امتیازی قرار دادیم.یا مثلاً گاهی تماسی که باید کد ورود برای ثبت فروشگاه رو به من اعلام می‌کرد، به خاطر مشکلات فنی برقرار نمی‌شد.همچنین ایرادات فنّی دیگه‌ای هم حین ثبت آگهی داشتیم. مثلا اینکه اگر در زمانی که آگهی در انتظار تایید بود عنوانش رو ویرایش می‌کردم، این تغییر در لیست آگهی‌های در انتظار تایید دیده نمی‌شد.که البته به بسیاری از این ایرادها هم در روند تست QA واقف بودیم. ولی وقتی خودمون به عنوان کاربر باهاش درگیر بودیم و برامون اتفاق می‌افتاد، بیشتر در جهت یافتن و حلشون مُصر می‌شدیم.بعد از بررسی مشکلات اولیه در ثبت‌نام و برنامه‌ریزی‌های فنّی و محصولی در تیم برای حلشون، وارد پروسه‌ی آگهی گذاشتن شدیم.من فروشگاهم رو در دسته‌ی آرایشی بهداشتی ثبت کرده بودم. و در حدود ۱۰ تا آگهی گذاشتم از کالاهایی که از برخی‌شون هم چند تا داشتم. به طور مثال چند رایحه‌ی مختلف بادی‌اسپلش آگهی کردم. همچنین ریش‌تراش مردانه و چند مورد دیگه.در بخش دوم که مربوط به فروش اجناس بود هم مواردی رو از سختی‌ها و موانع کاربر فروشنده دریافتیم. که در زیر چندتاشون رو توضیح می‌دم:خریدارها با من تماس می‌گرفتن تا بپرسن رایحه‌های دیگه‌ای از یکی از آگهی‌های بادی‌اسپلشم رو دارم یا نه. من تقریبا از همه‌ی این افراد می‌پرسیدم که آیا بقیه‌ی آگهی‌هام رو هم دیدن؟ آیا متوجه شدن آگهیم فروشگاهیه؟ جواب‌ها ناراحت‌کننده بود. تقریبا در هیچ موردی این اتفاق نیفتاده بود. ایراد از کجا بود که کاربرهای خریدار متوجه بقیه‌ی آگهی‌های فروشگاهی یک فروشنده نمی‌شدن؟ برای فهمیدن این مسئله در ادامه تست کاربردپذیری طراحی و اجرا کردیم و برای بهبود این مشکل، طراحیمون رو به نحوی عوض کردیم تا فروشگاهی بودن آگهی‌های فروشگاه مشخص‌تر باشن. و دوباره در تست کاربردپذیری بررسی کردیم که مشکل قبلی چقدر پیش میاد. نتیجه حاکی از بهتر شدن مشکل قبلی بود.خریدارها ازم می‌خواستن اطلاعات تکمیلی در مورد کالایی که آگهی کرده بودم بدم. مثلا می‌پرسیدن این ریش‌تراش نیاز به چند ساعت شارژ داره؟ یا اینکه آیا از مدل دیگه‌ای که یک رده پایین‌تره، خیلی ضعیف‌تره؟ خب من اطلاعات تکمیلی یک فروشنده که شغلش فروش لوازم آرایشی بهداشتیه رو نداشتم! گاهی جواب سوال‌هاشون رو با سرچ کردن پیدا می‌کردم. اما کار سخت و وقت‌گیری بود. و البته می‌دونیم که این دغدغه رو نه فقط من بلکه هر فروشنده‌ای ممکنه داشته باشه که اطلاعات خیلی تخصصی از کالاش رو ندونه. برای این مورد هم طراحان راه‌حلی ارائه کردن که به طور آزمایشی برای دسته‌ی موبایل اجرا شد. به این صورت که دسترسی به اطلاعات کامل برند و مدل هر موبایل در صفحه‌ی آگهی موجود شد. برای سنجش طراحی مذکور هم تست کاربردپذیری دیگه‌ای طراحی و اجرا کردیم تا راه‌حل‌هامون رو بهبود بدیم.چالش دیگه‌م هم تعامل با مشتریانی بود که در اصل مشتری نبودن و قصدشون کلاهبرداری بود که تو مورد من از روش‌های خیلی کلاسیکش استفاده کردن. در هر دو مورد افراد اصرار داشتن با فشار زمانی گذاشتن و تاکید بر اینکه پول کالا رو به حسابم واریز کردن، جنس رو بهشون تحویل بدم. که البته این اتفاق نیفتاد. همچنین به خاطر شرایط ویژه‌ی کرونا، امکان مراجعه‌ی حضوری خریداران کم شده بود. و اکثرا مایل بودن تا کالا رو براشون ارسال کنم. پس من به عنوان فروشنده چطور باید اعتماد می‌کردم و کالا رو به خریدار می‌دادم بدون اینکه پولی دریافت کنم؟ راه‌حل من البته این بود که به خریدارها می‌گفتم می‌تونن بیان حضوری هم کالا رو مشاهده کنن و اگه مطمئن شدن هزینه رو واریز کنن. ولی شاید هر فروشنده‌ای این امکان رو نداشته باشه. این مسئله هنوز برای فروشنده‌ها حل نشده. همچنان فروشنده‌هایی که ارسال کالا دارن ریسک‌هایی رو هم متحمل می‌شن. و البته بعضاً خودشون هم راه‌حل‌هایی برای این مسئله پیدا کردن. و البته می‌دونیم که ریسک‌ کلاه‌برداری سمت خریدار هم وجود داره.ولی ما در تیم محصول دیوارِ فروشگاه‌ها، در پی حل این مسئله هستیم! و امیدواریم بتونیم به زودی با ایده‌هایی که داریم دیوار رو به جای امن‌تر و بهتری برای خریدار و برای فروشنده بدل کنیم.این تازه شروع کارهاین اتفاق در کل تجربه‌ی خوبی بود و صرفا محدود به پیدا کردن مشکلات فلو نشد. حالا ما سعی می‌کنیم خودمون رو مثل کاربرها درگیر کنیم، و مسائل رو از زاویه‌ی دید اون‌ها نگاه کنیم. یا به عبارتی کفش کاربر رو پامون کنیم! :)مرسی از میلاد حاج‌فتحعلی؛ مدیر محصول دیوارِ فروشگاه‌ها که این تجربه رو برامون تسهیل کرد. آلما روشنی آلما روشنی Wed, 10 Mar 2021 18:05:41 +0330