فرض کنید فرایند پرداخت از نظر فنی سالم است: دکمه کار میکند، تراکنش ثبت میشود و پیام موفقیت هم نمایش داده میشود. بااینحال کاربر نمیفهمد مبلغ به ریال است یا تومان، کد پویا را در فیلد اشتباه وارد میکند و پس از بازگشت از درگاه مطمئن نیست سفارش ثبت شده یا نه. محصول «کار میکند»، اما استفاده از آن آسان و مطمئن نیست. این دقیقاً مسئله تست کاربردپذیری است.
در این راهنما یاد میگیرید Usability Testing را با کاربر هدف برنامهریزی و اجرا کنید، Task مناسب بنویسید، بدون راهنماییکردن کاربر جلسه را تسهیل کنید و یافتهها را به اصلاح قابل اقدام تبدیل کنید. یک نمونه کامل برای خرید موبایلی در فروشگاه ایرانی نیز داریم تا خروجی فقط مجموعهای از تعریفها نباشد.
کاربردپذیری یا Usability چیست؟
استاندارد ISO ۹۲۴۱-۱۱:۲۰۱۸ کاربردپذیری را نتیجه استفاده در یک زمینه مشخص میداند و آن را حول سه مؤلفه تعریف میکند: کاربر مشخص بتواند به هدف مشخص، با اثربخشی، کارایی و رضایت برسد. بنابراین «این صفحه ساده است» یک نیازمندی قابل آزمون نیست؛ باید بگوییم برای چه کاربری، چه هدفی، روی چه دستگاه و در چه شرایطی.
- اثربخشی (Effectiveness): کاربر آیا هدف را درست و کامل انجام داد؟
- کارایی (Efficiency): برای رسیدن به هدف چه زمان، تلاش یا منبعی صرف شد؟
- رضایت (Satisfaction): تجربه از نگاه کاربر تا چه حد پذیرفتنی و خوشایند بود؟
- زمینه استفاده (Context of Use): چه کاربر، وظیفه، دستگاه، محیط و محدودیتی در کار است؟
یک پنل حسابداری برای حسابدار حرفهای روی دسکتاپ و همان سرویس برای صاحب کسبوکار کمتجربه روی موبایل، زمینههای متفاوتی دارند. نتیجه یک تست را نباید بدون توجه به این تفاوتها تعمیم داد.
تست کاربردپذیری چیست؟
تست کاربردپذیری روشی پژوهشی و ارزیابی است که در آن افراد نماینده کاربران هدف، Taskهای واقعبینانه را با محصول یا Prototype انجام میدهند. پژوهشگر رفتار، نقاط مکث، خطا، مسیر، پرسشها و برداشت کاربر را مشاهده میکند و در کنار داده کیفی، معیارهایی مانند موفقیت و زمان انجام را ثبت میکند.
این تست در خوشه تستهای غیرکارکردی قرار میگیرد، زیرا کیفیت تعامل را میسنجد. بااینحال میتواند نقص Functional هم آشکار کند؛ مثلاً کاربر دکمه را درست پیدا میکند اما سفارش واقعاً ذخیره نمیشود. چنین موردی به تست کارکردی نیز نیاز دارد.
تفاوت Usability Testing با UX Research، Accessibility و A/B Test
| روش/مفهوم | پرسش اصلی | خروجی معمول |
|---|---|---|
| Usability Testing | آیا کاربر هدف میتواند Task مشخص را انجام دهد و کجا گیر میکند؟ | مشکل کاربردپذیری، شواهد، شدت و پیشنهاد اصلاح |
| UX Research | کاربر چه نیاز، رفتار، انگیزه و زمینهای دارد؟ | بینش، Journey، نیاز و فرصت محصول |
| Accessibility Testing | آیا افراد دارای معلولیت میتوانند بهطور برابر از محصول استفاده کنند؟ | عدم انطباق فنی، مانع تعامل و اثر بر کاربر |
| Heuristic Evaluation | رابط با اصول شناختهشده طراحی چه فاصلهای دارد؟ | فهرست مشکلات از بازبینی متخصص |
| A/B Test | کدام نسخه در رفتار واقعی و مقیاس آماری بهتر عمل میکند؟ | تفاوت KPI میان نسخهها |
| UAT | آیا راهکار نیاز کسبوکار و معیار پذیرش را برآورده میکند؟ | پذیرش، رد یا شرطهای تحویل |
ظاهر زیبا هممعنای کاربردپذیری نیست و Heuristic Review جای مشاهده کاربر را نمیگیرد. A/B Test میگوید نسخه B نرخ تکمیل بالاتری دارد، اما لزوماً توضیح نمیدهد چرا؛ Usability Test میتواند علت اصطکاک را آشکار کند.
مرز کاربردپذیری و دسترسپذیری
کاربردپذیری و Accessibility همپوشانی دارند اما جایگزین هم نیستند. طبق راهنمای W3C WAI درباره Accessibility، Usability و Inclusion، پرداختن هماهنگ به هر سه نتیجه بهتری میدهد، ولی تمرکز دسترسپذیری بر موانع افراد دارای معلولیت باید حفظ شود.
یک تست با کاربران عمومی نمیتواند انطباق Accessibility را اثبات کند. در کنار تست فنی استانداردها، افراد دارای معلولیت و فناوری کمکی واقعی مانند صفحهخوان، بزرگنمایی یا ورودی صوتی را در پژوهش وارد کنید. مقاله تست دسترسپذیری و WCAG مسیر تخصصی این ارزیابی را توضیح میدهد.
چه زمانی تست کاربردپذیری انجام دهیم؟
- Discovery: برای شناخت مشکل موجود و مشاهده راهحل فعلی کاربر؛
- وایرفریم کمجزئیات: برای آزمودن معماری اطلاعات و جریان پیش از هزینه توسعه؛
- Prototype تعاملی: برای مقایسه مفهومها و اصلاح تعامل؛
- Alpha/Beta: برای کشف فاصله طراحی و پیادهسازی واقعی؛
- محصول Live: برای بررسی Taskهای واقعی، تغییرات و شکایتهای پرتکرار؛
- پس از بازطراحی: برای سنجش اینکه مشکل واقعاً حل شده، نه فقط صفحه متفاوت شده است.
یک دور بزرگ در انتهای پروژه معمولاً دیر است. دورهای کوچک و تکرارشونده، سؤال محدودتری دارند و امکان اصلاح و Retest را میدهند.
انواع تست کاربردپذیری
Moderated و Unmoderated
در تست Moderated، تسهیلگر جلسه را هدایت و سؤالهای پیگیری میپرسد؛ برای کشف چرایی رفتار و Prototypeهای اولیه مناسب است. در تست Unmoderated، شرکتکننده مستقل Task را انجام میدهد؛ مقیاسپذیرتر است اما کنترل زمینه و امکان پرسش عمیق کمتر میشود.
حضوری و از راه دور
جلسه حضوری مشاهده محیط و زبان بدن را آسان میکند. Remote Recruiting را گستردهتر و برای ایران کمهزینهتر میکند، اما کیفیت اینترنت، اشتراک صفحه و حریم خصوصی باید از قبل آزموده شود. برای فناوری کمکی، تنظیم شخصی کاربر را حفظ کنید؛ الزام به دستگاه آزمایشگاه ممکن است رفتار واقعی را از بین ببرد.
Formative و Summative
Formative برای پیدا کردن مشکل و اصلاح طراحی در طول ساخت است. Summative برای سنجش عملکرد نسخه نسبتاً پایدار در برابر Benchmark یا معیار پذیرش انجام میشود. نوع دوم به طراحی نمونه، سناریوی کنترلشده و تحلیل کمی دقیقتری نیاز دارد.
اکتشافی و مقایسهای
تست اکتشافی میپرسد «کاربر این مفهوم و جریان را چگونه میفهمد؟». تست مقایسهای دو راهحل را تحت Task و شرایط مشابه بررسی میکند. ترتیب نمایش نسخهها را کنترل کنید تا اثر یادگیری نتیجه را منحرف نکند.
فرایند گامبهگام Usability Testing
۱. Research Question را محدود کنید
هدف «بررسی کاربردپذیری اپ» بیش از حد گسترده است. سؤال بهتر: «آیا خریدار موبایلی که قبلاً از سایت خرید نکرده میتواند کالای مشخصی را پیدا کند، واحد قیمت را بفهمد و خرید مهمان را بدون کمک کامل کند؟»
۲. کاربر و زمینه را تعریف کنید
سن، تجربه، نقش، زبان، دستگاه، محدودیت دسترسی و تجربه اخیر مرتبط را مشخص کنید. Persona خیالی جای Recruitment Criteria را نمیگیرد. اگر چند گروه رفتار متفاوت دارند—مثلاً فروشنده و خریدار—برای هر گروه نمونه و تحلیل جدا لازم است.
۳. Task واقعبینانه بنویسید
Task باید هدف را بگوید، نه مسیر یا نام کنترل را. بهجای «روی فیلتر قیمت بزنید و کفش را به سبد اضافه کنید» بنویسید: «برای هدیه، یک کفش زیر ۱۵ میلیون ریال پیدا کنید که سایز ۴۲ موجود باشد و آن را برای خرید آماده کنید.»
۴. معیار و تعریف موفقیت را پیشاپیش تعیین کنید
موفقیت کامل، موفقیت با کمک و شکست را تعریف کنید. زمان از کجا شروع و کجا تمام میشود؟ چه چیزی Error محسوب میشود؟ کمک Moderator چگونه ثبت میشود؟ اگر این تصمیمها پس از مشاهده نتایج گرفته شوند، تحلیل مستعد سوگیری است.
۵. Pilot اجرا کنید
یک جلسه آزمایشی با فرد نزدیک به جامعه هدف، ابهام Task، مشکل Prototype، طول جلسه، داده ناکافی و خرابی ضبط را آشکار میکند. نتیجه Pilot را بیدلیل با داده اصلی مخلوط نکنید.
۶. جلسه را بدون هدایت اجرا کنید
به شرکتکننده بگویید «ما محصول را تست میکنیم، نه شما را». سؤالهای خنثی مانند «الان انتظار دارید چه اتفاقی بیفتد؟» بپرسید. از اشاره به دکمه، تأیید پاسخ یا آموزش در میانه Task خودداری کنید. اگر مجبور به کمک شدید، نوع و زمان کمک را ثبت کنید.
۷. یافتهها را ترکیب و اولویتبندی کنید
مشاهده را از تفسیر جدا کنید. «سه نفر پس از ورود از درگاه، وضعیت سفارش را ندیدند» مشاهده است؛ «کاربران حواسپرتاند» قضاوت است. اثر بر Task، فراوانی، تداوم و ریسک کسبوکار را برای شدت در نظر بگیرید.
۸. اصلاح را Retest کنید
تغییر طراحی بهتنهایی نشانه حل مشکل نیست. Task بحرانی را با افراد تازه یا در دور بعد تکرار و اثر جانبی اصلاح بر گروههای دیگر را کنترل کنید.
چند شرکتکننده برای تست کاربردپذیری لازم است؟
یک عدد ثابت برای همه مطالعهها وجود ندارد. راهنمای پژوهش GOV.UK برای مطالعه کیفی کاربردپذیری، ۵ تا ۶ شرکتکننده را برای یک دور کیفی پیشنهاد میکند و تأکید دارد مطالعه کمی به نمونه بیشتری نیاز دارد. این عدد نقطه شروع است، نه تضمین کشف درصد مشخصی از همه مشکلات.
تعداد مناسب به این عوامل وابسته است:
- تعداد گروههای کاربری متمایز؛
- پیچیدگی و ریسک Task؛
- کیفی یا کمی بودن هدف؛
- تنوع دستگاه، توانایی و زمینه استفاده؛
- تکرارشونده بودن دورهای پژوهش؛
- نیاز به مقایسه آماری یا Benchmark.
اگر سه گروه اصلی دارید، پنج نفر در مجموع ممکن است فقط یک گروه را نمایندگی کند. برای تخمین نرخ موفقیت یا مقایسه زمان دو نسخه، نمونه و تحلیل آماری را بر اساس اندازه اثر و دقت مورد نیاز طراحی کنید.
مثال عملی؛ تست خرید موبایلی در فروشگاه ایرانی
هدف و شرکتکنندگان
سؤال پژوهش: آیا خریداران موبایلی تازهوارد میتوانند قیمت را بهدرستی تفسیر، ارسال را انتخاب و پس از بازگشت از درگاه وضعیت سفارش را تشخیص دهند؟
نمونه یک دور کیفی: شش نفر از کاربران هدف که طی سه ماه اخیر خرید اینترنتی موبایلی داشتهاند؛ ترکیبی از Android میانرده و ضعیف، تجربه دیجیتال متفاوت و دستکم یک کاربر با نیاز دسترسی مرتبط. در دورهای بعد، گروههای کمتر نمایندگیشده جدا بررسی میشوند.
Taskهای پیشنهادی
- محصولی با بودجه ۱۵ میلیون ریال پیدا و تفاوت گزینهها را توضیح دهید.
- بدون ساخت حساب، آن را برای ارسال به نشانی مشخص آماده کنید.
- کد تخفیف دادهشده را اعمال و مبلغ نهایی را با صدای بلند تفسیر کنید.
- پرداخت Sandbox را انجام دهید و سپس بگویید آیا سفارش ثبت شده و قدم بعد چیست.
- سفارش را در حساب یا رهگیری مهمان پیدا کنید.
دادههای قابل ثبت
| داده | مثال مشاهده | کاربرد |
|---|---|---|
| Task Success | ۴ کامل، ۱ با کمک، ۱ شکست | اثربخشی مسیر |
| Time on Task | زمان کاربران موفق، جدا از زمان شکست | مقایسه کارایی در نسخهها |
| Error | سه نفر ریال را تومان خواندند | ریسک مالی و وضوح محتوا |
| Assistance | Moderator محل رهگیری را نشان داد | تفکیک موفقیت مستقل از موفقیت با کمک |
| Behavior | کاربر چند بار میان سبد و محصول برگشت | سرنخ مشکل معماری یا اطلاعات |
| Quote | نقلقول کوتاه با رضایت و بدون داده هویتی | توضیح تجربه، نه جایگزین شمارش |
نمونه یافته قابل اقدام
یافته: چهار نفر از شش نفر مبلغ ۱۲٬۸۵۰٬۰۰۰ ریال را ۱۲٬۸۵۰٬۰۰۰ تومان برداشت کردند. دو نفر پیش از پرداخت متوجه واحد نشدند. اثر: ریسک ترک خرید یا تصور قیمت نادرست. شواهد: Sessionهای U02، U03، U05 و U06. پیشنهاد برای آزمون: نمایش تومان بهعنوان واحد اصلی با معادل ریال در نقطه پرداخت و Retest روی همان Task.
پیشنهاد، حکم طراحی نهایی نیست؛ فرضیه اصلاح است. تیم محصول ممکن است محدودیت حقوقی یا فنی داشته باشد و راهحل دیگری را آزمایش کند.
متریکهای کاربردپذیری
متریک را بر اساس سؤال پژوهش انتخاب کنید، نه بهخاطر آسانبودن جمعآوری. برای فرمولها، Benchmark، SUS و روشهای پیشرفتهتر، مقاله روشها و معیارهای تست کاربردپذیری را بخوانید.
- Task Success Rate: نسبت تلاشهای موفق به کل تلاشها؛ موفقیت با کمک را جدا گزارش کنید.
- Time on Task: زمان انجام با تعریف شروع/پایان ثابت؛ شکستها را بیفکر با موفقها میانگین نگیرید.
- Error Rate: تعداد و نوع خطا؛ خطای بحرانی با لغزش بیاثر وزن یکسان ندارد.
- Assistance Rate: چند نفر برای تکمیل Task به راهنمایی نیاز داشتند.
- Path Deviation: انحراف از مسیر مورد انتظار، برگشت و بنبست.
- Single Ease Question: ارزیابی آسانی همان Task بلافاصله پس از انجام.
- SUS: پرسشنامه استاندارد نگرش کلی به کاربردپذیری؛ امتیاز ۰ تا ۱۰۰ است اما درصد موفقیت نیست.
متریک بدون زمینه گمراهکننده است. زمان کمتر میتواند نتیجه عجله و خطای بیشتر باشد. رضایت بالا هم ممکن است کنار شکست Task رخ دهد. داده کمی را با مشاهده و گفتوگوی کیفی تفسیر کنید.
محیط، داده و حریم خصوصی
محیط تست باید با سؤال پژوهش سازگار باشد. Prototype غیرکامل را میتوان آزمود، اما محدودیت آن را به شرکتکننده توضیح دهید. برای نسخه واقعی، حساب آزمایشی، پرداخت Sandbox، نشانی ساختگی و Cleanup فراهم کنید. چکلیست آمادهسازی محیط تست برای کنترل نسخه، داده و دسترسی مفید است.
- رضایت آگاهانه برای مشارکت و ضبط بگیرید؛ ضبط را پیشفرض و اجباری نکنید.
- هدف، مدت نگهداری، افراد دارای دسترسی و امکان انصراف را روشن کنید.
- رمز، شماره کارت، کد ملی، تلفن و نشانی واقعی را در Task یا ویدئو ثبت نکنید.
- داده شخصی را در کلیپ ارائه یا ابزار خارجی بدون بررسی سیاست سازمان بارگذاری نکنید.
- حقالزحمه و زمان شرکتکننده را محترمانه و شفاف مدیریت کنید.
نکات ویژه برای کاربران فارسیزبان و بازار ایران
- RTL و ترکیب متن: آمیختن فارسی با شماره سفارش، URL و عبارت انگلیسی را روی دستگاه واقعی بررسی کنید.
- ریال و تومان: واحد، جداکننده رقم و تبدیل ذهنی را در لحظه تصمیم مالی بسنجید.
- عدد فارسی و لاتین: ورود تلفن، کارت، OTP و جستوجو با هر دو شکل را مشاهده کنید.
- تاریخ و زمان: شمسی/میلادی، منطقه زمانی و عبارتهای نسبی مانند «فردا» را بدون ابهام نمایش دهید.
- شبکه و دستگاه: Android قدیمیتر، صفحه کوچک، اینترنت ناپایدار و بازگشت از اپ بانکی بخشی از Context هستند.
- پیامک و درگاه: تأخیر کد پویا، Timeout، بازگشت ناقص و تراکنش نامشخص را در سناریو لحاظ کنید.
- زبان روشن: اصطلاح فنی یا ترجمه تحتاللفظی را با کاربران همان حوزه بسنجید.
- دسترسی: کاربر کمبینا، سالمند، صفحهخوان و تعامل فقط با صفحهکلید را از Recruitment حذف نکنید.
چگونه یافتهها را اولویتبندی و گزارش کنیم؟
گزارش طولانی جلسه بهتنهایی تصمیم ایجاد نمیکند. هر Finding را با این ساختار بنویسید:
- عنوان رفتاری: مشکل در زبان کاربر، نه نام Component؛
- Task و گروه: مشکل برای چه هدف و چه کاربری رخ داد؟
- Evidence: چند مشاهده، چه الگو و چه داده کمی؟
- Impact: شکست، تأخیر، خطا، ریسک مالی یا کاهش اعتماد؛
- Severity: ترکیب اثر، فراوانی، تداوم و قابلیت بازیابی؛
- Recommendation/Hypothesis: جهت اصلاحی که باید آزموده شود؛
- Owner و Retest: مسئول تصمیم و روش تأیید اصلاح.
| شدت | تعریف عملی | نمونه |
|---|---|---|
| بحرانی | Task حیاتی برای بخش بزرگی شکست میخورد یا ریسک حقوقی/مالی دارد | کاربر مبلغ را با واحد اشتباه تأیید میکند |
| زیاد | Task ممکن است اما با خطای جدی، کمک یا مسیر طولانی | رهگیری سفارش فقط با راهنمایی پیدا میشود |
| متوسط | اصطکاک تکرارشونده بدون شکست کامل | برچسب فیلتر نامفهوم و چند بار آزمون |
| کم | اثر محدود یا ترجیحی با بازیابی آسان | متن کماهمیت نیاز به وضوح بیشتر دارد |
یافته کاربردپذیری همیشه Bug فنی نیست، اما اگر رفتار با Requirement یا طراحی مصوب مغایر است میتوان آن را با شواهد مناسب در Tracker ثبت کرد. قالب گزارش باگ حرفهای را برای ثبت Expected/Actual و Evidence تطبیق دهید.
اشتباهات رایج در Usability Testing
- انتخاب همکاران بهجای کاربر هدف: آشنایی با محصول موانع واقعی را پنهان میکند.
- Task هدایتکننده: نام دکمه یا مسیر درست را داخل سناریو میگوییم.
- دفاع از طراحی: Moderator در لحظه مکث توضیح میدهد چرا صفحه اینطور است.
- پرسیدن «دوستش داشتید؟»: نظر کلی جای رفتار در Task واقعی را میگیرد.
- اعلام قانون پنج نفر: بدون توجه به گروه، هدف و نوع مطالعه، عدد ثابت تجویز میشود.
- میانگینگیری بیمعنا: زمان شکست، موفقیت با کمک و موفقیت مستقل مخلوط میشوند.
- نادیدهگرفتن Accessibility: نمونه فقط کاربران بدون معلولیت را شامل میشود.
- ضبط بدون رضایت: اعتماد و حریم خصوصی شرکتکننده نقض میشود.
- گزارش نقلقولهای جذاب بدون الگو: یک جمله به کل جامعه تعمیم داده میشود.
- نداشتن Retest: تیم فرض میکند هر تغییر طراحی مشکل را حل کرده است.
قالب کوتاه Test Plan کاربردپذیری
هدف پژوهش:
Research Questions:
کاربران هدف و معیار جذب:
گروههای نیازمند نمونه جدا:
محصول/نسخه/Prototype:
Context و دستگاه:
Taskها و ترتیب:
تعریف موفقیت، کمک و شکست:
متریکهای اصلی و فرعی:
روش جلسه و مدت:
Pilot:
رضایت، ضبط و نگهداری داده:
نقش Moderator و Note-taker:
روش تحلیل و Severity:
ذینفعان مشاهدهکننده:
تصمیم مورد انتظار:
زمان اصلاح و Retest:چکلیست اجرای تست کاربردپذیری
- Research Question محدود و تصمیم مورد انتظار مشخص است.
- شرکتکنندگان نماینده کاربران و Context واقعیاند.
- گروههای متفاوت بیدلیل در یک نمونه کوچک مخلوط نشدهاند.
- Task هدف را بیان میکند و نام مسیر یا کنترل را لو نمیدهد.
- تعریف Success، Failure، Assistance و Error پیشاپیش نوشته شده است.
- Prototype، حساب، داده و Sandbox در Pilot بررسی شدهاند.
- رضایت آگاهانه و قواعد ضبط/حذف داده روشن است.
- Moderator سؤال خنثی میپرسد و کمک را ثبت میکند.
- مشاهده از تفسیر و پیشنهاد طراحی جدا نگه داشته میشود.
- یافته با Task، گروه، Evidence، Impact و Severity ثبت میشود.
- Accessibility با تست فنی و کاربران دارای معلولیت پوشش دارد.
- نتیجه به Owner، تصمیم و تاریخ Retest متصل است.
جمعبندی
تست کاربردپذیری راهی برای رأیگیری درباره زیبایی رابط نیست؛ روشی است برای مشاهده اینکه کاربر مشخص در زمینه مشخص چگونه به هدف میرسد. یک مطالعه خوب سؤال محدود، شرکتکننده نماینده، Task غیرهدایتکننده، معیار ازپیشتعریفشده و خروجی قابل اقدام دارد.
برای شروع، یک سفر پرریسک مانند ثبتنام، پرداخت یا بازیابی رمز را انتخاب کنید. با یک دور کیفی کوچک، بزرگترین مانعها را پیدا کنید، اصلاح را بسازید و دوباره با افراد تازه تست کنید. کیفیت این چرخه از حجم گزارش مهمتر است.
سوالات متداول درباره تست کاربردپذیری
تست کاربردپذیری چیست؟
مشاهده کاربران نماینده هنگام انجام Taskهای واقعی با محصول یا Prototype است تا اثربخشی، کارایی، رضایت و موانع تعامل در Context مشخص ارزیابی شوند.
آیا پنج کاربر برای Usability Testing کافی است؟
برای یک دور کیفی با گروه نسبتاً همگن، ۵ تا ۶ نفر میتواند نقطه شروع عملی باشد؛ اما قانون عمومی نیست. چند گروه کاربری، مطالعه کمی، محصول پرریسک یا نیاز به مقایسه آماری به نمونه و طراحی متفاوت نیاز دارند.
تفاوت تست کاربردپذیری و UAT چیست؟
UAT روی پذیرش نیاز کسبوکار و آمادگی راهکار تمرکز دارد. Usability Testing بررسی میکند کاربران هدف با چه میزان موفقیت، تلاش و رضایت میتوانند به هدف برسند. یک محصول ممکن است UAT را Pass کند اما همچنان برای کاربر دشوار باشد.
آیا تست کاربردپذیری را میتوان خودکار کرد؟
بخشهایی مثل Analytics، ثبت زمان یا اجرای Checkهای فنی قابل خودکارسازیاند، اما مشاهده فهم، انتظار، تردید و راهبرد کاربر به مشارکت انسان نیاز دارد. Automation مکمل پژوهش است، نه جایگزین آن.
مهمترین خروجی Usability Test چیست؟
فهرست قابل اولویتبندی از موانع کاربر همراه شواهد، اثر بر Task، گروه درگیر و برنامه Retest. ویدئو یا درصد موفقیت بدون اتصال به تصمیم محصول، خروجی کاملی نیست.
