تست کاربردپذیری زمانی ارزش دارد که یک کاربر واقعی، یک کار واقعی را انجام دهد و تیم بدون راهنماییکردن او ببیند کجا متوقف، مردد یا منحرف میشود. Heatmap، نظر مدیر یا شمارش کلیک جای این مشاهده را نمیگیرد. از طرف دیگر، دیدن سه خطا در پنج جلسه هم بهتنهایی ثابت نمیکند نسخه جدید Conversion را افزایش میدهد.
این راهنما از سؤال تحقیق تا جذب مشارکتکننده، سناریو، اجرای جلسه، تحلیل و تصمیم را پوشش میدهد. برای فرایند گستردهتر تحقیق و طراحی، ابتدا راهنمای تجربه کاربری UX را ببینید.
تست کاربردپذیری چیست؟
Usability Testing روشی پژوهشی است که در آن افراد نماینده مخاطب، Taskهای مشخصی را با یک محصول، سایت یا Prototype انجام میدهند. پژوهشگر رفتار، مسیر، خطا و توضیح کاربر را ثبت میکند تا بفهمد تجربه برای هدف موردنظر تا چه اندازه قابلفهم، کارآمد و قابلاعتماد است.
هدف جلسه اثبات خوببودن طرح یا آموزش رابط نیست. خروجی خوب، فهرستی اولویتدار از مسئلهها، شواهد هر مسئله و تصمیم بعدی است.
چه چیزی تست کاربردپذیری نیست؟
| روش | سؤال اصلی | تفاوت |
|---|---|---|
| QA عملکردی | آیا قابلیت طبق Specification کار میکند؟ | ممکن است دکمه سالم باشد ولی کاربر آن را پیدا نکند |
| Accessibility audit | آیا معیارهای فنی دسترسپذیری رعایت شدهاند؟ | استاندارد و تست با کاربر مکملاند |
| Heuristic review | کارشناس چه مسئله محتملی میبیند؟ | سریع است، اما رفتار مخاطب واقعی را نشان نمیدهد |
| مصاحبه | کاربر چه میگوید، نیاز دارد یا به یاد میآورد؟ | در Usability رفتار حین Task محور است |
| Analytics | چه اتفاقی و در چه مقیاسی رخ میدهد؟ | علت را باید با شواهد کیفی بررسی کرد |
| A/B Test | کدام نسخه روی KPI بهتر عمل میکند؟ | برای علت و کشف مسئله طراحی نشده است |
چه زمانی تست کنیم؟
- Discovery: بررسی محصول فعلی یا راهحل رقیب برای شناخت مدل ذهنی؛
- Concept: فهم واژگان، ارزش پیشنهادی و مسیر اصلی؛
- Prototype: اصلاح Flow پیش از هزینه توسعه؛
- قبل از انتشار: تست Taskهای بحرانی روی Build نزدیک به واقعیت؛
- پس از انتشار: عیبیابی افت Funnel، Ticket یا خطای پرتکرار؛
- بهصورت دورهای: کنترل Journeyهای مهم پس از تغییر محصول یا رفتار بازار.
برای Checkout، پرداخت، حذف داده، دسترسی یا تغییر مالی، تست زودهنگام و سپس QA روی نسخه واقعی لازم است.
انواع تست کاربردپذیری
با تسهیلگر و بدون تسهیلگر
در تست Moderated، پژوهشگر زنده حضور دارد، سؤال پیگیری میپرسد و برای Prototype پیچیده یا موضوع حساس مناسبتر است. در Unmoderated، مشارکتکننده دستور را مستقل انجام میدهد؛ سریعتر و مقیاسپذیرتر است، اما ابهام دستور یا مشکل فنی ممکن است داده را خراب کند.
حضوری و از راه دور
Remote برای کاربران شهرهای مختلف ایران و محیط واقعی دستگاه مفید است. حضوری امکان مشاهده زمینه و تجهیزات را میدهد. کیفیت روش به سؤال، نمونه و اجرا وابسته است، نه صرفاً مکان جلسه.
کیفی و کمی
تست کیفی برای کشف الگو، اصطکاک و چرایی رفتار است. تست کمی نرخ موفقیت، زمان و مقایسه نسخهها را با نمونه و پروتکل استاندارد میسنجد. اعداد پنج جلسه کیفی را به کل کاربران تعمیم ندهید.
Formative و Summative
Formative در طول طراحی برای یادگیری و اصلاح است. Summative برای Benchmark یا مقایسه با معیار/نسخه قبلی، کنترل بیشتر و نمونه بزرگتر میخواهد.
از سؤال تحقیق شروع کنید
«کاربران سایت را دوست دارند؟» سؤال قابلاقدامی نیست. سؤال را به تصمیم وصل کنید:
- آیا خریدار موبایل میتواند محصول سازگار را پیدا کند؟
- کدام بخش فرم آدرس بیشترین خطای قابلجبران را میسازد؟
- کاربر پس از برگشت نامشخص از درگاه، وضعیت سفارش را میفهمد؟
- آیا صاحب کسبوکار تفاوت پلنها و هزینه نهایی را تشخیص میدهد؟
- آیا کاربر Keyboard-only میتواند ثبتنام را کامل کند؟
پیش از جذب، تصمیمی را که نتیجه تغییر میدهد، مالک تصمیم و موعد آن را بنویسید.
طرح تحقیق یکصفحهای
| بخش | نمونه |
|---|---|
| زمینه | افت تکمیل خرید موبایل پس از تغییر آدرس |
| هدف | کشف مانعهای انتخاب شهر، کدپستی و تحویل |
| مخاطب | خریدار موبایل با حداقل یک خرید آنلاین اخیر |
| روش | ۶ جلسه Remote با تسهیلگر، هرکدام ۴۵ دقیقه |
| Task | یافتن کالا، افزودن و رسیدن تا قبل از پرداخت واقعی |
| داده | موفقیت، خطا، مسیر، نقلقول کوتاه، SEQ |
| ریسک | نمایش شماره، آدرس یا اطلاعات بانکی در ضبط |
| خروجی | Issueهای Severityدار و جلسه تصمیم محصول |
جذب مشارکتکننده
Segment را بر اساس رفتار بسازید
سن، جنسیت و شهر بهتنهایی Segment کاربردی نیستند. تجربه، هدف، دستگاه، سطح مهارت، محدودیت دسترسی و رفتار اخیر را ببینید. برای مثال «صاحب فروشگاه وردپرسی که در سه ماه اخیر افزونه خریده» بهتر از «مرد ۲۵ تا ۳۵ ساله» است.
Screener کوتاه و غیرالقایی
پاسخ مطلوب را لو ندهید. بهجای «آیا کاربر حرفهای دیجیکالا هستید؟» درباره دفعات و آخرین تجربه واقعی بپرسید. معیار پذیرش/رد، تعارض شغلی، دستگاه و امکان ضبط را ثبت کنید.
چند کاربر لازم است؟
راهنمای جاری Nielsen Norman Group برای مطالعه کیفی معمولاً ۵ تا ۸ مشارکتکننده را پیشنهاد میکند. این عدد را برای هر گروه واقعاً متفاوت جداگانه در نظر بگیرید و در صورت ادامه کشف مسئله جدید، موج بعدی بسازید. «پنج نفر همیشه کافی است» قانون عمومی نیست.
برای Benchmark کمی یا A/B، صدها/هزاران عدد ثابت هم نسخه عمومی نیست. Baseline، حداقل اثر مهم، واریانس، Alpha، Power، تخصیص و مدت چرخه کسبوکار باید وارد محاسبه حجم نمونه شوند.
جبران مشارکت
زمان، هزینه اینترنت و دشواری جذب را منصفانه جبران کنید. مبلغ و روش پرداخت را از قبل روشن کنید و پرداخت را به «پاسخ درست» یا تعریف از محصول وابسته نکنید. No-show، لغو و زمان اضافه را در سیاست جذب بنویسید.
Consent، حریم خصوصی و امنیت
- هدف، مدت، نوع ضبط، ناظران و کاربرد داده را پیش از شروع توضیح دهید.
- رضایت شرکت و رضایت ضبط را جدا و قابلپسگرفتن نگه دارید.
- ورود رمز، OTP، کد ملی، آدرس و اطلاعات پرداخت واقعی را ممنوع یا Mask کنید.
- از حساب و داده آزمایشی استفاده کنید.
- نام فایل را با شناسه پژوهش بسازید، نه نام و شماره شخص.
- دسترسی، محل ذخیره و تاریخ حذف فایلها مشخص باشد.
- Session replay و ابزار خارجی را از نظر انتقال داده، Masking و دسترسی بررسی کنید.
- نقلقول در گزارش را تا حد امکان ناشناس کنید.
در ایران ممکن است محدودیت سرویس خارجی، سرعت اتصال یا نگرانی ضبط بیشتر باشد؛ مسیر جایگزین تماس و ذخیره امن داخلی را از قبل آماده کنید.
Task خوب چگونه نوشته میشود؟
Task هدف و زمینه میدهد، نه مسیر و برچسب رابط. بد: «روی فیلتر قیمت بزنید و ارسال رایگان را انتخاب کنید.» بهتر: «برای هدیه، کالایی تا سقف سه میلیون تومان پیدا کنید که پیش از پنجشنبه به شیراز برسد.»
- واقعگرایانه و مرتبط با Segment باشد.
- پاسخ یا واژه دقیق UI را لو ندهد.
- شروع و پایان قابلمشاهده داشته باشد.
- به داده شخصی/پرداخت واقعی نیاز نداشته باشد.
- از ساده به بحرانی بچیند، ولی اثر یادگیری را در مقایسه کنترل کند.
- Taskهای مستقل را در صورت نیاز Counterbalance کنید.
Prototype و محیط تست
- سطح Fidelity با سؤال متناسب باشد؛ Copy و داده واقعیتر از تزئین اضافه مهمتر است.
- لینکها، حالت خطا و مسیر Back را پیش از جلسه Dry run کنید.
- فونت فارسی، RTL، اعداد فارسی/لاتین و Keyboard موبایل را بررسی کنید.
- اگر بخشی ساختگی است، محدودیت را قبل از Task بدون لو دادن پاسخ بگویید.
- نسخه Build، Browser، دستگاه و زمان تست را ثبت کنید.
- Notification، اطلاعات شخصی و پنجرههای نامرتبط روی دستگاه پژوهشگر بسته باشد.
اسکریپت جلسه ۴۵دقیقهای
- ۵ دقیقه: معرفی، Consent و تأکید اینکه محصول تست میشود نه شخص؛
- ۵ دقیقه: سؤال زمینه و تجربه اخیر؛
- ۲۵ دقیقه: سه تا پنج Task با مشاهده و سؤال خنثی؛
- ۵ دقیقه: سؤال پس از Task و مقایسه؛
- ۵ دقیقه: Debrief، اجازه استفاده از داده و توضیح پرداخت.
زمان را با پیچیدگی محصول تنظیم کنید. خستگی در جلسه طولانی میتواند باگ ساختگی تولید کند.
تسهیلگری بدون جهتدهی
- از سکوت نترسید؛ فوراً راهحل ندهید.
- بهجای «این دکمه را ندیدید؟» بپرسید «الان انتظار دارید چه اتفاقی بیفتد؟»
- اگر کاربر کمک خواست، ابتدا بپرسید در استفاده عادی چه میکرد.
- Think-aloud را درخواست کنید، اما سکوت را شکست تلقی نکنید.
- تحسین یا دفاع از طرح نکنید.
- مشکل فنی مطالعه را از مشکل محصول جدا ثبت کنید.
- اگر Task بحرانی یا آزاردهنده شد، Stop rule داشته باشید.
ناظر و یادداشتبرداری
ناظران در کانال جدا و بیصدا بمانند. هر یادداشت شامل زمان، Task، مشاهده و اثر باشد: «P4 در Task ۲ سه بار بین سبد و محصول رفت؛ هزینه ارسال را پیدا نکرد؛ سفارش را متوقف کرد.» تفسیر را از مشاهده جدا کنید.
یک نفر مسئول Technical support و یک نفر Note-taker باشد تا Moderator مجبور به انجام همه کارها نشود. جلسه Debrief تیمی را بلافاصله بعد از هر روز برگزار کنید، اما قبل از دیدن کل داده راهحل نهایی ندهید.
چه چیزهایی را اندازه بگیریم؟
| معیار | تعریف عملی | احتیاط |
|---|---|---|
| Task success | موفق، موفق با کمک، ناموفق با معیار ازپیشتعریفشده | بعد از جلسه معیار نسازید |
| Time on task | از نقطه شروع تا پایان/توقف | در Think-aloud و نمونه کوچک Benchmark قطعی نیست |
| Error | خطای بحرانی یا قابلبازیابی | کلیک متفاوت لزوماً خطا نیست |
| SEQ | سختی ادراکشده پس از هر Task | با موفقیت واقعی ترکیب شود |
| SUS | برداشت کلی از کاربردپذیری | برای تشخیص محل مشکل نیست |
| Help | تعداد/نوع مداخله Moderator | تعریف کمک بین جلسات ثابت باشد |
| Path | مسیر، Backtrack و نقطه تردید | کوتاهترین مسیر همیشه بهترین نیست |
تحلیل از شواهد تا Issue
- ویدئو، Note و Metric را با شناسه مشارکتکننده یکجا کنید.
- Observationها را بدون راهحل زودرس گروهبندی کنید.
- الگو و استثنا را به تفکیک Segment ببینید.
- برای هر Issue، Task، شواهد، Frequency و Impact را ثبت کنید.
- علت محتمل را از واقعیت مشاهدهشده جدا بنویسید.
- پیشنهاد را با Confidence و نیاز به Validation همراه کنید.
- کلیپ کوتاهِ ناشناس را فقط در صورت Consent به گزارش اضافه کنید.
Severity و اولویت تصمیم
| سطح | معنا | نمونه |
|---|---|---|
| بحرانی | Task ممکن نیست یا خطر مالی/حریم خصوصی دارد | پرداخت تکراری، نمایش داده کاربر دیگر |
| زیاد | اکثر افراد Segment متوقف یا منحرف میشوند | CTA اصلی قابلتشخیص نیست |
| متوسط | تأخیر یا خطای قابلبازیابی | Label مبهم و Backtrack |
| کم | اصطکاک محدود بدون شکست Task | ترتیب ثانویه نامناسب |
Frequency کوچک در نمونه کیفی را درصد بازار ننامید. شدت، میزان مواجهه در Analytics، ارزش Journey، ریسک، Confidence و Effort را کنار هم بگذارید.
تست با کاربران دارای معلولیت
راهنمای W3C برای ارزیابی با کاربران دارای معلولیت تأکید میکند که ارزیابی با افراد واقعی، مشکلاتی را پیدا میکند که بررسی Conformance بهتنهایی نمیبیند؛ در عین حال تجربه یک فرد نماینده همه افراد با همان معلولیت نیست.
- افراد با فناوری کمکی و تجربه مرتبط جذب کنید.
- دستگاه و تنظیمات ترجیحی خودشان را در صورت امکان حفظ کنید.
- زمان، استراحت، قالب Consent و شیوه ارتباط را دسترسپذیر کنید.
- هزینه همراه/تجهیزات یا زمان اضافه را در جبران ببینید.
- Screen reader، Keyboard، Zoom، Voice input و Cognitive load را بر اساس دامنه پوشش دهید.
- یافته Usability را جایگزین Audit معیارهای WCAG نکنید.
تفاوت تست کاربردپذیری و A/B
Usability مسئله و چرایی را کشف میکند؛ A/B اثر علّی یک تغییر مشخص را روی KPI در ترافیک واقعی میسنجد. ابتدا با پژوهش Hypothesis بسازید، سپس اگر ترافیک و ریسک اجازه میدهد Experiment کنید.
مقاله قدیمی Google Optimize را پیشنهاد میکرد؛ این سرویس طبق اعلام رسمی Google از ۳۰ سپتامبر ۲۰۲۳ در دسترس نیست. ابزار را بر اساس Randomization، Sample-ratio mismatch، Feature flag، Exposure logging، Guardrail، حریم خصوصی و امکان Export انتخاب کنید، نه فهرست قدیمی برندها.
پروتکل A/B حداقلی
- Hypothesis، Primary metric و Guardrail پیش از شروع ثبت شود.
- واحد تصادفیسازی User/Account/Session روشن باشد.
- کاربر بین نسخهها نپرد و Exposure واقعی ثبت شود.
- حجم نمونه و حداقل اثر مهم قبل از اجرا تعیین شود.
- تست بهخاطر نتیجه موقت زود متوقف نشود.
- چرخه هفتگی/فصلی و رخدادهای کمپین پوشش داده شود.
- SRM، خطای Instrumentation و Segmentهای ازپیشتعریفشده بررسی شوند.
- برد آماری با اثر تجاری و Guardrail تفسیر شود.
Analytics چگونه تست را تکمیل میکند؟
Funnel و Error log محل اصطکاک و دامنه مواجهه را نشان میدهند؛ تست کاربر علت محتمل را آشکار میکند. پس از اصلاح، Analytics و Experiment پایداری اثر را میسنجند. برای Event taxonomy، Data quality و داشبورد، راهنمای UX دادهآگاه را دنبال کنید.
در فروشگاه، مسئلهها را روی Journey واقعی Search، Product، Cart و Payment بسنجید؛ راهنمای UX فروشگاه اینترنتی چکهای هر مرحله را دارد.
ابزار را بر اساس قابلیت انتخاب کنید
- ضبط و تماس پایدار با امکان جایگزین در محدودیت شبکه؛
- Prototype با State، RTL و دستگاه هدف؛
- Note و Repository با سطح دسترسی؛
- Caption/Transcript فارسی با امکان اصلاح انسانی؛
- Masking داده حساس و سیاست نگهداری؛
- تست Unmoderated با Screening و جلوگیری از پاسخ تکراری؛
- Experiment با Feature flag، Assignment و Export داده؛
- Analytics با QA رخداد و Debug.
قبل از خرید، یک Pilot با زبان فارسی، پرداخت، دسترسی از ایران و فرایند حذف داده اجرا کنید.
اشتباههای پرتکرار
- جذب همکاران بهجای کاربر هدف؛
- پرسیدن نظر درباره زیبایی بهجای Task واقعی؛
- راهنمایی کاربر و سپس ثبت «موفق»؛
- نمایش فقط Happy path بدون خطا و بازگشت؛
- درصدسازی از پنج جلسه کیفی؛
- ترکیب Segmentهای متفاوت در یک نتیجه؛
- ضبط رمز، شماره، آدرس یا صفحه شخصی؛
- تبدیل هر نقلقول به Feature request؛
- تحلیل بدون Owner و موعد تصمیم؛
- انتخاب A/B برای سایت کمترافیک؛
- نادیدهگرفتن Accessibility و شبکه ضعیف؛
- گزارش صداسلایدی بدون شواهد و اولویت.
برنامه اجرایی دهروزه
- روز ۱: سؤال، تصمیم و Stakeholder؛
- روز ۲: Plan، Segment و Screener؛
- روز ۳: Task، Script، Consent و داده آزمایشی؛
- روز ۴: Pilot و اصلاح؛
- روز ۵ تا ۷: جلسات و Debrief روزانه؛
- روز ۸: Synthesis و Severity؛
- روز ۹: کارگاه تصمیم، Owner و Validation؛
- روز ۱۰: Backlog، کلیپهای مجاز و برنامه Retest.
چکلیست تست کاربردپذیری
- سؤال تحقیق به تصمیم محصول وصل است.
- Segment و معیار جذب رفتاری و مستند است.
- تعداد نمونه با نوع مطالعه متناسب است.
- Consent، ضبط، جبران و حذف داده روشن است.
- Task واقعی، خنثی و دارای پایان قابلمشاهده است.
- Pilot روی دستگاه و شبکه هدف انجام شده است.
- Moderator کمک و سؤال القایی را کنترل میکند.
- موفقیت، خطا، Help و Severity تعریف ثابت دارند.
- Accessibility با افراد و فناوری مرتبط پوشش دارد.
- یافته، تفسیر و پیشنهاد از هم جدا هستند.
- هر Issue شواهد، Owner و تصمیم بعدی دارد.
- نسخه اصلاحشده Retest یا با داده پس از انتشار سنجیده میشود.
سؤالات متداول تست کاربردپذیری
تست کاربردپذیری چیست؟
مشاهده افراد نماینده مخاطب هنگام انجام Taskهای واقعی با محصول یا Prototype است تا مسئلههای فهم، مسیر، خطا و اعتماد کشف شوند.
برای تست کاربردپذیری چند کاربر لازم است؟
برای مطالعه کیفی، ۵ تا ۸ نفر در هر گروه متمایز نقطه شروع رایجی است؛ Saturation و ریسک تصمیم را ببینید. برای Benchmark یا A/B حجم نمونه باید محاسبه آماری شود.
تست با ناظر بهتر است یا بدون ناظر؟
برای مسئله اکتشافی، Prototype پیچیده و سؤال پیگیری، Moderated مناسبتر است. برای Task روشن و نمونه پراکنده، Unmoderated سریعتر است. انتخاب به سؤال و ریسک بستگی دارد.
آیا Heatmap جای تست کاربر را میگیرد؟
خیر. Heatmap الگوی کلیک/Scroll را نشان میدهد، اما هدف، فهم و علت رفتار را قطعی نمیکند. از آن برای انتخاب ناحیه تحقیق و همراه با Analytics و جلسه کاربر استفاده کنید.
تفاوت تست کاربردپذیری و A/B چیست؟
تست کاربردپذیری مشکل و چرایی را کشف میکند؛ A/B با تخصیص تصادفی میسنجد کدام نسخه روی KPI بهتر است. معمولاً پژوهش کیفی Hypothesis را میسازد و Experiment آن را اعتبارسنجی میکند.
جمعبندی
تست خوب از ابزار شروع نمیشود؛ از تصمیم، مخاطب و Task شروع میشود. نمونه مناسب جذب کنید، جلسه را بدون جهتدهی اجرا کنید، حریم خصوصی و دسترسپذیری را جدی بگیرید و یافته را به Issue دارای شواهد، Severity، Owner و Retest تبدیل کنید.
برای طراحی Plan پژوهش، اجرای تست فارسی/RTL یا اعتبارسنجی Checkout، از فرم مشاوره UX مایندیو استفاده کنید و Journey، مخاطب، دستگاه و تصمیم موردنظر را بنویسید.
