معیارهای تست کاربردپذیری؛ SUS، Task Success و گزارش

هشت نفر فرایند خرید را امتحان کرده‌اند؛ شش نفر بدون کمک موفق شده‌اند، یک نفر با راهنمایی و یک نفر هرگز به پرداخت نرسیده است. آیا طراحی «خوب» است؟ عدد ۷۵٪ به‌تنهایی پاسخ نمی‌دهد. باید بدانیم موفقیت دقیقاً چگونه تعریف شده، شرکت‌کنندگان نمایندهٔ چه کسانی بوده‌اند، کمک Moderator چه اثری داشته، زمان از کجا تا کجا اندازه‌گیری شده و عدم‌قطعیت این نمونهٔ کوچک چقدر است.

این راهنما دربارهٔ معیارهای تست کاربردپذیری و تبدیل مشاهدهٔ جلسه به تصمیم محصول است: Task Success، Time on Task، خطا، SEQ و SUS چگونه تعریف و محاسبه می‌شوند، دادهٔ کیفی چگونه کدگذاری می‌شود و یک گزارش قابل‌بازتولید چه اجزایی دارد. اگر ابتدا به تعریف، انواع و فرایند کلی نیاز دارید، مقالهٔ تست کاربردپذیری چیست نقطهٔ شروع و مالک Intent اصلی است.

خروجی این راهنما چیست؟

در پایان می‌توانید برای یک مطالعهٔ Formative یا Benchmark:

• پرسش تصمیم و Context of use را روشن کنید؛
• وظیفه‌ای بنویسید که راه‌حل را لو ندهد؛
• Success، Assistance، Error و زمان را پیش از جلسه Operationalize کنید؛
• معیار مناسب را بدون تبدیل SUS به «درصد» انتخاب کنید؛
• نتایج نمونهٔ کوچک را با عدم‌قطعیت گزارش کنید؛
• Observation را از Interpretation و Recommendation جدا نگه دارید؛
• رضایت آگاهانه، ضبط و دادهٔ شخصی را کنترل کنید؛
• یافته را به Owner، اقدام و Retest متصل کنید.

کاربردپذیری یک عدد مطلق نیست

استاندارد ISO 9241-11:2018 کاربردپذیری را پیامد استفاده در یک زمینهٔ مشخص می‌داند؛ یعنی کاربر، هدف، وظیفه، منابع و محیط اهمیت دارند. سه بُعد مشهور آن عبارت‌اند از:

• Effectiveness: آیا کاربر به نتیجهٔ درست و کامل می‌رسد؟
• Efficiency: برای رسیدن به آن نتیجه چه زمان، تلاش یا منبعی مصرف می‌شود؟
• Satisfaction: تجربه از دید کاربر چگونه ادراک می‌شود؟

بنابراین «SUS ما ۸۰ است» بدون نسخهٔ محصول، کاربران، وظایف، دستگاه و روش اجرا قابل تفسیر کامل نیست. همان سامانه می‌تواند برای کارشناس روزانه کارآمد و برای کاربر باراولی یا کاربر Screen reader دشوار باشد.

اول نوع مطالعه را مشخص کنید

نوع مطالعه	پرسش اصلی	خروجی مناسب
Formative / تشخیصی	کجا و چرا کاربر گیر می‌کند؟	مشاهده، الگو، Severity، فرضیهٔ طراحی
Summative / Benchmark	عملکرد نسخه در برابر معیار یا Baseline چیست؟	Task success، زمان، خطا، رضایت و عدم‌قطعیت
Comparative	تفاوت نسخه A و B یا دو محصول چقدر است؟	اختلاف تعریف‌شده، طرح تخصیص و تحلیل آماری
Longitudinal	یادگیری و ماندگاری در طول زمان چگونه تغییر می‌کند؟	اندازه‌گیری تکراری و اثر ترتیب/تمرین

یک Round کوچکِ تشخیصی برای کشف مشکل با یک Benchmark رسمی یکسان نیست. Think aloud برای فهم «چرا» مفید است، اما حرف‌زدن می‌تواند زمان انجام وظیفه را تغییر دهد. اگر زمان معیار تصمیم است، Protocol را ثابت کنید و اثر مداخله را در گزارش بنویسید.

از پرسش تصمیم به Measurement plan برسید

«Checkout را تست کنیم» برنامه نیست. پرسش تصمیم باید به یک انتخاب متصل باشد:

آیا کاربران موبایلِ باراولی می‌توانند با نشانی فارسی، کد تخفیف و درگاه Sandbox خرید را بدون کمک کامل کنند؟ اگر نرخ شکست یا خطای بحرانی از حد پذیرفته‌شده بیشتر باشد، Release متوقف نمی‌شود به‌صورت خودکار؛ Owner باید Risk، اصلاح یا Mitigation را تصمیم بگیرد.

برای هر پرسش، این قرارداد را پیش از جذب شرکت‌کننده ثبت کنید:

فیلد	نمونه
نسخه و Scope	Android ۴.۸.۰، از سبد تا رسید Sandbox
کاربر هدف	خریدار باراولی، فارسی‌زبان، Android میان‌رده
Context	اینترنت موبایل، RTL، صفحه‌کلید فارسی/لاتین
Task	خرید یک کالا با سقف بودجه و دریافت رسید
Success oracle	یک سفارش Paid، یک کسر موجودی، رسید قابل مشاهده
Measures	Unassisted success، assistance، critical error، time، SEQ
قواعد زمان	Start/stop/pause/timeout مشخص
Exclusion	قطعی ابزار ضبط؛ نه شکست واقعی محصول
تصمیم	اصلاح، آزمایش بیشتر، پذیرش ریسک یا Retest

نوشتن Task بدون لو دادن مسیر

سناریو، انگیزه می‌دهد؛ دستور، مسیر را لو می‌دهد

نسخهٔ ضعیف: «روی فیلتر قیمت بزنید، تهران را انتخاب کنید و با دکمهٔ سبز پرداخت کنید.» این متن Navigation و Labelها را آموزش می‌دهد.

نسخهٔ بهتر: «برای یک هدیه تا سقف ۲ میلیون تومان کالایی پیدا کنید که حداکثر تا دوشنبه به نشانی شما در تهران برسد؛ اگر مناسب بود، خرید آزمایشی را کامل کنید.» Success از نتیجه سنجیده می‌شود، نه از دنبال‌کردن قدم‌های پژوهشگر.

Oracle باید از ظاهر فراتر برود

برای Checkout فقط دیدن صفحهٔ «موفق» کافی نیست. Oracle می‌تواند شامل State سفارش، اثر موجودی، نبود Duplicate و رسید باشد. در موبایل، بازگشت از درگاه، Background/Foreground و Deep link نیز مهم‌اند؛ راهنمای تست اپلیکیشن موبایل این شرایط را پوشش می‌دهد.

ترتیب و اثر یادگیری

وقتی یک نفر چند نسخه یا Task مشابه می‌بیند، تمرین و خستگی نتیجه را تغییر می‌دهد. ترتیب را Counterbalance یا Randomize کنید و در تحلیل ثبت کنید کدام Task اول بوده است. دادهٔ چند Task را بدون توجه به تفاوت سختی در یک میانگین کلی ادغام نکنید.

معیار اول: نرخ موفقیت وظیفه (Task Success)

پیش از جلسه تعیین کنید چه چیزی Success، Assisted، Partial و Failure است. تغییر تعریف بعد از دیدن داده، نتیجه را قابل‌بازی می‌کند.

وضعیت	تعریف نمونه
Unassisted success	نتیجهٔ درست در مهلت، بدون Hint یا Intervention
Assisted success	نتیجه درست است، اما Moderator راهنمایی مؤثر داده
Partial	بخشی از Outcome حاصل شده؛ فقط اگر از قبل تعریف شده باشد
Failure	نتیجه غلط، رهاشدن، Timeout یا اثر بحرانی
Not eligible	مشکل ابزار/Recruitment خارج از معیار ازپیش‌نوشته‌شده

فرمول پایه:

Unassisted completion rate = موفقیت بدون کمک ÷ تلاش‌های واجد شرایط × 100

Assisted را داخل Success پنهان نکنید. می‌توانید هر دو را کنار هم گزارش کنید، اما «۶ موفق بدون کمک + ۱ موفق با کمک از ۸ نفر» اطلاعات بیشتری از «۷ نفر موفق شدند» می‌دهد.

نمونهٔ کوچک و فاصلهٔ اطمینان

۶ موفقیت از ۸ تلاش برابر ۷۵٪ است، اما Wilson ۹۵% interval تقریباً از ۴۱٪ تا ۹۳٪ امتداد دارد. این فاصلهٔ پهن یادآوری می‌کند که ۷۵٪ حقیقت دقیق کل بازار نیست. برای مطالعهٔ تشخیصی، الگوی شکست مهم‌تر است؛ برای Benchmark یا تصمیم پرریسک، حجم نمونه باید از حداقل تفاوت مهم، پراکندگی، توان تحلیل، Segmentها، ریزش و قواعد حذف داده طراحی شود.

معیار دوم: زمان انجام وظیفه (Time on Task)

زمان فقط وقتی قابل‌مقایسه است که Start، Stop، Pause و Timeout ثابت باشند. نمونه:

• Start: پایان خواندن سناریو و اعلام آمادگی؛
• Stop: رسیدن به Outcome معتبر، نه صرفاً کلیک آخر؛
• Pause: قطع فنی پژوهش، اگر از قبل مجاز باشد؛
• Failure time: تا رهاکردن یا Timeout جداگانه نگه‌داری شود؛
• Intervention: لحظه و نوع کمک ثبت شود.

زمان معمولاً توزیع نامتقارن دارد. Median و IQR در کنار دادهٔ خام از Average تنها گویاترند. زمان موفقیت‌ها و شکست‌ها را جدا نشان دهید؛ حذف همهٔ شکست‌های طولانی می‌تواند طراحی را مصنوعی سریع جلوه دهد. همچنین «سریع‌تر» همیشه بهتر نیست: مرور مبلغ یا هشدار امنیتی می‌تواند زمان را بیشتر ولی خطای پرهزینه را کمتر کند.

معیار سوم: خطا، انحراف و بازیابی

هر کلیک اضافه Error نیست و هر Error شدت یکسان ندارد. Taxonomy را به Task و Risk متصل کنید:

نوع	مثال	معیار
Critical error	پرداخت تکراری یا ثبت سفارش با نشانی غلط	رخداد/شرکت‌کننده و Outcome
Non-critical error	بازکردن مسیر اشتباه و بازیابی مستقل	تعداد، زمان بازیابی
Slip	Tap ناخواسته روی کنترل نزدیک	قابلیت Undo و تکرار
Mistake	برداشت نادرست از مفهوم «اعتبار کیف پول»	مدل ذهنی و پیام طراحی
Assistance	Hint ناظر مسیر را آشکار می‌کند	سطح و زمان Intervention
Near miss	کاربر پیش از تأیید، مبلغ اشتباه را می‌بیند و برمی‌گردد	ریسک بالقوه و Recovery

Recovery rate، زمان بازیابی و کیفیت پیام خطا گاهی از تعداد خطا مهم‌ترند. Observation را دقیق بنویسید: «P04 سه بار بین سبد و نشانی رفت و پس از ۹۰ ثانیه کمک خواست» بهتر از «Navigation گیج‌کننده بود» است.

معیار چهارم: SEQ برای سهولت هر Task

Single Ease Question یا SEQ یک امتیاز پس از هر وظیفه است؛ معمولاً از شرکت‌کننده می‌پرسد انجام این کار چقدر دشوار یا آسان بود و پاسخ در مقیاس ۷ نقطه‌ای ثبت می‌شود. آن را بلافاصله پس از Task و پیش از بحث طولانی بپرسید.

• SEQ ادراکِ سهولت همان Task است، نه Success واقعی؛
• ممکن است کاربر Fail کند ولی تجربه را آسان بداند یا برعکس؛
• Median، توزیع و پاسخ‌های فردی را همراه Outcome ببینید؛
• ترجمه، جهت Scale و Labelها را بین Roundها تغییر ندهید؛
• اگر نسخهٔ فارسی اعتبارسنجی‌شده ندارید، محدودیت مقایسه را صریح کنید.

معیار پنجم: امتیاز SUS؛ محاسبه و تفسیر درست

System Usability Scale یک پرسشنامهٔ ۱۰ آیتمی دربارهٔ ادراک کلی سامانه است. SUS معمولاً پس از تعامل کافی با کل محصول یا Scope تعریف‌شده اجرا می‌شود؛ برای تشخیص دقیق اینکه کدام فیلد مشکل دارد طراحی نشده است.

فرمول امتیاز SUS

1. پاسخ هر آیتم روی مقیاس ۱ تا ۵ ثبت می‌شود.
2. برای آیتم‌های فرد: response - 1.
3. برای آیتم‌های زوج: 5 - response.
4. مجموع Contributionها در ۲٫۵ ضرب می‌شود.
5. نتیجه بین ۰ و ۱۰۰ است.

این عدد درصد نیست. SUS=۷۰ یعنی «۷۰٪ از کاربران موفق شدند» یا «محصول ۷۰٪ کاربردپذیر است» نیست. تفسیر به نسخهٔ پرسشنامه، زبان، Context، محصول مرجع، نمونه و فاصلهٔ اطمینان وابسته است. عدد ۶۸ را نیز Threshold جهانی Pass/Fail نگیرید؛ Benchmark معتبرِ دامنه یا Baseline خود محصول مناسب‌تر است.

مثال محاسبه

اگر پاسخ‌ها ۴،۲،۴،۱،۵،۲،۴،۲،۴،۱ باشند، Contribution آیتم‌های فرد ۳+۳+۴+۳+۳ و آیتم‌های زوج ۳+۴+۳+۳+۴ است؛ مجموع ۳۳ و SUS برابر ۸۲٫۵ می‌شود. Report باید Mean/Median، پراکندگی، تعداد پاسخ معتبر و عدم‌قطعیت را نیز نشان دهد؛ یک امتیاز بدون n کافی نیست.

قواعدی که پیش از اجرا لازم‌اند

• از یک ترجمهٔ ثابت و، در صورت نیاز به مقایسهٔ رسمی، نسخهٔ اعتبارسنجی‌شده استفاده کنید.
• ترتیب و جهت آیتم‌ها را خودسرانه عوض نکنید.
• سیاست پاسخ گمشده را از قبل بنویسید؛ Imputation پنهان نکنید.
• امتیاز تک‌آیتم را به‌عنوان Subscale تفسیر نکنید.
• SUS را با Task success، خطا و Evidence کیفی Triangulate کنید.

مقالهٔ اصلی John Brooke روش امتیازدهی را معرفی کرده و قالب Common Industry Format در NIST نیز Performance و Satisfaction را در گزارش رسمی از هم جدا می‌کند.

NPS، Analytics و A/B جای تست کاربردپذیری نیستند

روش/سیگنال	چه می‌گوید؟	چه نمی‌گوید؟
Usability test	کاربر در Task مشخص چه کرد و چرا گیر کرد	شیوع دقیق در کل بازار با نمونهٔ کوچک
Analytics/Funnel	در مقیاس واقعی کجا Drop-off رخ می‌دهد	علت شناختی یا زمینهٔ کامل کاربر
A/B test	کدام Variant روی معیار تعریف‌شده تفاوت داشت	چرا و آیا مسیر از نظر کیفی/اخلاقی مناسب است
NPS	تمایل اظهارشده به توصیه در Context خودش	Effectiveness و Efficiency یک Task
Accessibility evaluation	موانع انطباق و استفاده برای افراد دارای معلولیت	با چند جلسهٔ عمومی کامل نمی‌شود

این منابع مکمل‌اند. Drop-off می‌تواند Task پژوهش را اولویت دهد؛ تست کاربردپذیری فرضیهٔ علت را بسازد؛ A/B اثر یک راه‌حل را در مقیاس بسنجد. تست با چند کاربر دارای معلولیت نیز جای ارزیابی استاندارد دسترس‌پذیری را نمی‌گیرد؛ راهنمای تست دسترس‌پذیری این مرز را توضیح می‌دهد.

چند شرکت‌کننده لازم است؟

قاعدهٔ جهانی «همیشه ۵ نفر کافی‌اند» وجود ندارد. عدد باید از هدف مطالعه بیاید:

برای Formative discovery

Roundهای کوچک و پی‌درپی می‌توانند برای کشف و اصلاح سریع مفید باشند، اما پوشش Segmentها مهم‌تر از رسیدن به یک عدد جادویی است. اگر کاربر باراولی، فروشنده، پشتیبان، سالمند و Screen-reader user رفتارهای متفاوت دارند، پنج نفر از یک گروه جای همه را نمی‌گیرند. پس از هر Round، یافته‌ها را اصلاح و در Round بعد Retest کنید.

برای Benchmark یا مقایسه

پیش از جمع‌آوری داده، Minimum detectable difference، نرخ/واریانس اولیه، سطح خطا، توان، تعداد Segment، Attrition و Exclusion را تعیین کنید. Pilot می‌تواند برآورد اولیه بدهد، اما دادهٔ Pilot را بدون برنامه با مطالعهٔ اصلی مخلوط نکنید. برای تصمیم‌های مالی، سلامت یا ایمنی، تحلیل‌گر روش تحقیق/آمار را وارد کنید.

برای Accessibility و Edge context

افرادی را جذب کنید که واقعاً از فناوری کمکی و Setup شخصی خود استفاده می‌کنند. GOV.UK نیز در راهنمای رسمی Moderated usability testing توجه به Setup شخصی Assistive technology و Taskهای واقعی را توصیه می‌کند.

طرح اجرای مطالعه در ۱۲ گام

۱. Decision و Risk را بنویسید

قرار است بعد از مطالعه چه تصمیمی بگیرید؟ کدام خطای کاربر اثر مالی، حقوقی، امنیتی یا عملیاتی دارد؟

۲. Context of use و Segmentها را تعریف کنید

کاربر، هدف، دستگاه، زبان، توانایی، محیط، شبکه و تجربهٔ قبلی را مشخص کنید. «کاربران ایرانی» Segment کافی نیست.

۳. Task و Oracle بسازید

سناریوی طبیعی، Start/End، دادهٔ لازم، Success و Failure را بنویسید. برای Stateهای محصول، دادهٔ تستِ ایزوله و قابل Reset آماده کنید؛ مدیریت داده تست در این بخش کمک می‌کند.

۴. Measure و قواعد Coding را Freeze کنید

تعریف Assistance، Critical error، Timeout، Exclusion و Instrument failure را پیش از مشاهدهٔ نتایج ثبت کنید.

۵. Sampling و Recruitment را طراحی کنید

Screening criteria، Segment quota، تعارض منافع، جبران منصفانه و ریزش احتمالی را لحاظ کنید. همکار تیم جای کاربر هدف نیست مگر محصول داخلی و نقش او واقعاً نماینده باشد.

۶. Consent و Privacy plan آماده کنید

هدف، دادهٔ جمع‌آوری‌شده، مشاهده‌گران، ضبط، محل نگهداری، مدت Retention، اشتراک، حق توقف و راه تماس را به زبان قابل‌فهم توضیح دهید. راهنمای رضایت آگاهانه GOV.UK تأکید می‌کند رضایت باید قابل‌اثبات، داوطلبانه و قابل‌پس‌گرفتن باشد.

۷. محیط و Instrumentation را آماده کنید

Build، Feature flag، Device، Network، Screen/audio recording، Timestamp و Note template را ثبت کنید. برای پرداخت، هویت یا خدمات حساس از Sandbox و دادهٔ ساختگی استفاده کنید؛ دادهٔ واقعی فقط با ضرورت، مبنای قانونی/سازمانی و کنترل مناسب.

۸. Pilot اجرا کنید

Pilot برای فهمیدن ابهام Task، خرابی ابزار، زمان جلسه و اثر Moderator است. اگر Task را تغییر دادید، نسخهٔ Guide را ثبت کنید و تصمیم بگیرید دادهٔ Pilot قابل ادغام هست یا نه.

۹. جلسه را بی‌طرفانه اجرا کنید

بگویید «محصول را تست می‌کنیم، نه شما». سکوت را فوری با Hint پر نکنید. سؤال‌های خنثی مانند «الان انتظار دارید چه اتفاقی بیفتد؟» از «دکمه را ندیدید؟» بهتر است.

۱۰. Observation را ساخت‌یافته ثبت کنید

شناسهٔ ناشناس شرکت‌کننده، Task، Timestamp، رفتار، Quote کوتاهِ مجاز، Outcome، Assistance و Evidence را بنویسید. راهنمای رسمی ثبت و ضبط جلسات GOV.UK بر رضایت، امنیت ذخیره‌سازی و حذف دادهٔ شخصیِ غیرضروری تأکید دارد.

۱۱. داده را پاک‌سازی و تحلیل کنید

Missing، Exclusion و Protocol deviation را علامت بزنید؛ نسخهٔ خام را دستکاری نکنید. دادهٔ کمی را به Task/Segment بشکنید و دادهٔ کیفی را با Affinity یا Codebook تحلیل کنید.

۱۲. تصمیم، Owner و Retest را ثبت کنید

یافته بدون Owner و معیار پذیرش به اسلاید فراموش‌شده تبدیل می‌شود. Fix پیشنهادی را Hypothesis بدانید و با همان Task و Oracle دوباره بیازمایید.

تحلیل کیفی: از مشاهده تا اقدام

چهار لایه را مخلوط نکنید:

لایه	نمونه
Observation	P03 کد پستی فارسی را Paste کرد؛ فیلد بی‌پیام خالی ماند.
Interpretation	Normalization یا Feedback برای رقم فارسی روشن نیست.
Finding	۳ نفر از ۸ نفر در ورود کد پستی متوقف یا نیازمند کمک شدند.
Recommendation/Hypothesis	پذیرش/تبدیل رقم فارسی و پیام نمونه ممکن است شکست را کاهش دهد.

یک Quote جذاب جای Pattern نیست. از Case مخالف نیز یاد کنید: چه کسانی موفق شدند و چه تفاوت زمینه‌ای داشتند؟ Session noteهای ساختاریافته در تست اکتشافی ساختاریافته الگوی خوبی برای Timestamp، Evidence و Debrief ارائه می‌کنند.

اولویت‌بندی بدون عددسازی

ضرب‌کردن چند امتیاز ترتیبی می‌تواند دقت کاذب بسازد. چهار محور را کنار هم نشان دهید:

• User impact: مانع Outcome، خطای پرهزینه، اصطکاک یا ترجیح؛
• Observed frequency: چند نفر از چند نفر در کدام Segment؛
• Persistence/recovery: مستقل بازیابی شد، کمک خواست یا کاملاً متوقف شد؛
• Evidence strength: مشاهدهٔ مستقیم، چند شاهد، Analytics یا فقط Hypothesis.

سطح	نمونهٔ قرارداد
Critical	اثر مالی/ایمنی/حریم خصوصی یا Outcome غلط بدون Recovery امن
High	Task حیاتی متوقف یا نیازمند کمک برای Segment هدف
Medium	تأخیر/سردرگمی قابل‌بازیابی با اثر معنی‌دار
Low	اصطکاک جزئی یا Hypothesis نیازمند شاهد بیشتر

Severity با Priority یکی نیست؛ Priority به Strategy، Reach، هزینه، Dependency و تعهد Release هم بستگی دارد. شاخص‌ها را KPI فردی پژوهشگر یا طراح نکنید؛ مقالهٔ متریک‌های تست نرم‌افزار دربارهٔ Anti-gaming توضیح می‌دهد.

مثال ایرانی: تحلیل فرایند خرید موبایل

طرح مطالعه

• ۸ شرکت‌کنندهٔ واجد شرایط: خریدار باراولی، Android، فارسی‌زبان؛
• Task: یافتن کالا زیر بودجه، نشانی تهران، کد تخفیف، پرداخت Sandbox؛
• Context: دو نوع اندازهٔ صفحه، اینترنت Wi-Fi/Cellular ثبت‌شده؛
• Measure: Unassisted success، assistance، critical error، time، SEQ؛
• Data: شماره، نشانی و تراکنش ساختگی؛
• Protocol: Think aloud ثابت، Timeout ده دقیقه، یک سطح Hint ثبت‌شده.

نتیجهٔ نمونه

معیار	نتیجه	تفسیر محتاطانه
Unassisted completion	۶/۸ = ۷۵٪	Wilson ۹۵% تقریباً ۴۱–۹۳٪؛ Benchmark قطعی نیست
Assisted completion	۱/۸	Hint دربارهٔ کد پستی Outcome را تغییر داد
Failure	۱/۸	بازگشت از درگاه State قابل‌فهم نداشت
Successful time	Median 145s؛ IQR ۹۸–220s	پراکندگی زیاد؛ Segment/Device بررسی شود
Critical errors	۲ رخداد در ۲ نفر	یک سفارش Duplicate و یک نشانی غلط
SEQ	Median 4/7	در کنار Outcome و Comment تفسیر شود

یافته‌ها

1. سه نفر رقم فارسی کد پستی را Paste کردند؛ دو نفر پیام روشنی نگرفتند و یکی Hint خواست.
2. دو نفر پس از بازگشت از درگاه روی Loading طولانی ماندند؛ یکی Retry کرد و Duplicate ساخت.
3. کاربران موفق، نشانی ذخیره‌شده یا صفحه‌کلید لاتین داشتند؛ این تفاوت باید در Round بعد آزموده شود.

تصمیم پیشنهادی

پیش از Release، Invariant سفارش تکراری به‌عنوان Risk فنی جداگانه اصلاح و تست شود؛ Normalization رقم فارسی و State بازگشت از درگاه دو Hypothesis طراحی‌اند. Round بعد با Task ثابت، دادهٔ Reset‌شونده، کاربران صفحه‌کلید فارسی و Instrumentation سفارش اجرا می‌شود. نتیجهٔ مطالعه جای تصمیم UAT یا Risk acceptance کسب‌وکار را نمی‌گیرد.

قالب گزارش تست کاربردپذیری

NIST در Common Industry Format، گزارش را حول Executive summary، Introduction، Method و Results سازمان می‌دهد تا خواننده بتواند اعتبار و ارتباط مطالعه را ارزیابی کند. قالب فشردهٔ زیر برای تیم محصول مناسب است:

Study ID / version / date: …
Decision question: …
Product/build/scope: …
Context of use: users, goals, tasks, environment …
Participants: eligibility, segments, n, exclusions …
Method: moderated/unmoderated, location, order, think aloud …
Consent/privacy: recording, access, retention, deletion …
Task/oracle: start, success, assistance, failure, timeout …
Measures: formula, scale, missing-data rule, uncertainty …
Results by task/segment: raw counts + summary …
Findings: observation → pattern → impact → evidence …
Limitations: sampling, prototype, network, moderator, translation …
Decision: fix / investigate / accept risk / retest …
Owner and due date: …
Retest criterion: …

گزارش باید Clip و Quote را فقط در محدودهٔ رضایت به اشتراک بگذارد. برای Issue اجرایی، اطلاعات تشخیصی را به قالب قابل‌اقدام تبدیل کنید؛ راهنمای گزارش باگ مرز Expected/Actual و Evidence را پوشش می‌دهد.

حریم خصوصی و اخلاق پژوهش در ایران

• رضایت‌نامه را فارسی روان و متناسب با سواد/دسترس‌پذیری شرکت‌کننده ارائه کنید.
• ضبط Screen، صدا، چهره، حضور Observer و استفاده از Clip را جدا و روشن توضیح دهید.
• شرکت‌کننده باید بتواند بدون پیامد جلسه را متوقف یا رضایت را پس بگیرد.
• نام، شماره همراه، کدملی، نشانی، صدای قابل‌شناسایی و تصویر، دادهٔ شخصی‌اند؛ حداقل لازم را بگیرید.
• برای پرداخت، بیمه، سلامت و دولت از حساب، شماره و سند ساختگی استفاده کنید مگر مجوز و ضرورت واقعی وجود داشته باشد.
• فایل را روی حساب شخصی Moderator نگه ندارید؛ Access، Retention و Delete owner مشخص باشد.
• Transcription یا سرویس ابری ثالث را در Consent و ارزیابی تأمین‌کننده لحاظ کنید.
• جبران هزینه/زمان را منصفانه طراحی کنید، اما آن را به تکمیل اجباری یا پاسخ مطلوب مشروط نکنید.

این بخش مشاورهٔ حقوقی نیست؛ سیاست سازمان و قوانین قابل‌اعمال باید توسط مسئول حریم خصوصی/حقوقی بررسی شود.

دام‌های رایج در تحلیل تست کاربردپذیری

• ۵ نفر = ۸۵٪: فرض‌های مدل، Segment و نوع مسئله نادیده گرفته می‌شود.
• SUS به‌عنوان درصد: مقیاس ادراک با Completion rate اشتباه می‌شود.
• ۶۸ به‌عنوان Pass جهانی: Context، Benchmark و عدم‌قطعیت حذف می‌شوند.
• Assisted داخل Success: اثر Moderator پنهان می‌ماند.
• Average زمان بدون شکست‌ها: کندترین و ناموفق‌ترین مسیر حذف می‌شود.
• کلیک اضافه = خطا: Exploration طبیعی با Error قاطی می‌شود.
• Quote = شیوع: یک جملهٔ جذاب نمایندهٔ جمعیت فرض می‌شود.
• Task جهت‌دار: متن سناریو Label و مسیر پاسخ را لو می‌دهد.
• تغییر Coding بعد از نتیجه: معیار به نفع داستان مطلوب بازتعریف می‌شود.
• NPS جای Usability: وفاداری اظهارشده جای Outcome وظیفه می‌نشیند.
• ضبط بی‌حدومرز: دادهٔ شخصی بیش از Consent نگه‌داری می‌شود.
• یافته بدون Retest: Recommendation اثبات‌شده فرض می‌شود.

چک‌لیست کنترل کیفیت مطالعه

• پرسش تصمیم، نسخه و Scope مشخص‌اند.
• کاربر/هدف/Task/محیط به‌عنوان Context ثبت شده‌اند.
• Success، Assistance، Failure، Timeout و Exclusion از قبل تعریف‌اند.
• Task راه‌حل را لو نمی‌دهد و Oracle واقعی دارد.
• Segment و نمونه با هدف Formative یا Benchmark تناسب دارند.
• Protocol، ترتیب Task، Think aloud و Intervention ثابت و ثبت‌شده‌اند.
• دادهٔ تست ایزوله است و اثر مالی/شخصی واقعی ندارد.
• رضایت، Observer، ضبط، Retention و حق خروج روشن‌اند.
• نتیجهٔ کمی با n، denominator، پراکندگی و عدم‌قطعیت آمده است.
• Observation، Interpretation، Finding و Recommendation جدا هستند.
• محدودیت‌ها و Caseهای مخالف گزارش شده‌اند.
• هر اقدام Owner، موعد و معیار Retest دارد.

سوالات متداول معیارهای تست کاربردپذیری

مهم‌ترین معیار تست کاربردپذیری چیست؟

معیار واحدی برای همهٔ تصمیم‌ها وجود ندارد. Task success برای Effectiveness، زمان/تلاش برای Efficiency و SEQ یا SUS برای ادراک کاربرند. آن‌ها را با خطا و Evidence کیفی ترکیب کنید و قبل از جلسه تعریف عملیاتی بنویسید.

آیا امتیاز SUS همان درصد کاربردپذیری است؟

خیر. SUS روی بازهٔ ۰ تا ۱۰۰ گزارش می‌شود، اما درصد موفقیت یا درصد کیفیت نیست. باید با نسخهٔ معتبر پرسشنامه، Context، نمونه، Benchmark و عدم‌قطعیت تفسیر شود.

چند کاربر برای تست کاربردپذیری کافی است؟

به هدف، Segmentها و تصمیم بستگی دارد. Round کوچک برای کشف و Retest سریع مناسب است؛ Benchmark یا مقایسه به طراحی حجم نمونه براساس تفاوت مهم، پراکندگی، توان، ریزش و تعداد Segment نیاز دارد. عدد ۵ تضمین پوشش ۸۵٪ نیست.

آیا زمان کوتاه‌تر همیشه یعنی طراحی بهتر؟

نه. زمان باید در کنار Outcome، خطا و Risk دیده شود. مرور مبلغ یا هشدار می‌تواند کندی مفید ایجاد کند. Start/Stop و شیوهٔ برخورد با Failure نیز باید ثابت باشند.

نمونه گزارش تست کاربردپذیری چه بخش‌هایی دارد؟

خلاصهٔ تصمیم، نسخه و Scope، Context، شرکت‌کنندگان، روش، Consent، Task/Oracle، معیار و فرمول، نتایج با عدم‌قطعیت، یافته و Evidence، محدودیت، تصمیم، Owner و Retest. دادهٔ خام و Clip فقط با دسترسی و رضایت مناسب پیوست می‌شوند.

منابع و یادداشت بازبینی

تعریف Context/Effectiveness/Efficiency/Satisfaction با ISO ۹۲۴۱-۱۱:۲۰۱۸، چرخهٔ Human-centred design با ISO 9241-210:2019، ساختار گزارش با NIST CIF و راهنمای اجرا/رضایت/ضبط با GOV.UK تطبیق داده شده است. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. استاندارد پولی ISO در این مقاله بازنشر نشده و برای انطباق رسمی باید متن مجاز همان استاندارد بررسی شود.

جمع‌بندی: اندازه‌گیری خوب از انتخاب ابزار شروع نمی‌شود؛ از تصمیم، Context و تعریف Outcome شروع می‌شود. Success را بدون کمک جدا کنید، زمان و خطا را با قرارداد ثابت بسنجید، SUS را درصد ننامید، نمونهٔ کوچک را با عدم‌قطعیت گزارش کنید و مشاهده را پیش از تفسیر حفظ کنید. وقتی گزارش Owner و Retest دارد، تست کاربردپذیری از مجموعه‌ای ویدئو و Quote به سازوکار تصمیم محصول تبدیل می‌شود.