کاربردپذیری در دیوار

نیاز کلی به تست ریموت

حالا نزدیک دو ساله که به خاطر کرونا دورکار هستیم و خیلی از شرکت‌های دنیا هم تصمیم گرفتن این مدل رو برای همیشه ادامه بدن. اما توی این شرایط، تأمین یکی از نیازهای اصلی ما پژوهشگران و طراحان تجربه‌ی کاربر، یعنی گرفتن تست کاربردپذیری (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 (به عنوان معیاری برای اندازه‌گیری رضایت) رو اندازه نمی‌گیریم.

چالش‌های بعد از تست

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

شرح توافق‌های ما در این فرمت:

• رنگ‌های خونه‌های کاربران ۱ تا ۶ بر این اساسه: قرمز یعنی تسک انجام نشده. زرد یعنی به سختی انجام شده. سبز یعنی به راحتی انجام شده.
• عدد در ستون موفقیت، تعداد تسک‌های انجام‌شده تقسیم بر تعداد کل نفراتیه که تسک رو دیدن.
• عدد در ستون سهولت هم تعداد افرادیه که با سهولت و راحتی تسک رو انجام می‌دن تقسیم بر تعداد نفراتی که موفق به انجام تسک شدن.
• برای رنگ‌بندی در ستون موفقیت و سهولت، از این قاعده‌ی کلی پیروی می‌کنیم: اگر در تسکی با احتساب خطای نمونه‌گیری‌مون، قطعاً بالای ۵۰٪ سهولت یا موفقیت داشتیم، رنگ اون خونه سبزه. اگر در تسکی با احتساب خطای نمونه‌گیری‌مون، قطعاً کمتر از ۵۰٪ سهولت یا موفقیت داشتیم رنگ اون خونه قرمزه. و رنگ باقی خونه‌ها که نمی‌شه با اطمینان گفت بزرگتر یا کوچکتر از ۵۰٪ هستن، زرده.
• در مورد تسک‌هایی که برای اجرای اون‌ها بیشتر از یک مسیر وجود داره، مشابه تسک ۱ و ۳ عمل می‌کنیم. این مسیرها نباید نسبت به هم اولویتی داشته باشن. در غیر این صورت مسیر ترجیحی به عنوان مسیر موفقیت تعریف می‌شه.
• اعداد دو ستون آخر برای مشخص کردن منطق رنگ‌دهی گذاشته شده و به هیچ وجه نشون دهنده‌ی میزان اهمیت تسک نیست.
• بیشتر از دو ستون رنگی آخر، جزئیات و ایرادهایی که حین تست مشاهده می‌کنیم برامون مهمه. این اطلاعات رو توی جدول برای هر فرد و هر تسک گزارش می‌کنیم.

تجربه‌ی شما

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