منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۹ دقیقه

تست کاربردپذیری (یوزبیلیتی تست) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. متن کامل اصلی به‌همراه همهٔ تصاویر در لینک انتهای صفحه در دسترس است.

تست کاربردپذیری (Usability Testing) یعنی اینکه طرح‌تان را جلوی کاربران واقعی بگذارید، از آن‌ها بخواهید کار مشخصی را انجام دهند، و تماشا کنید چه اتفاقی می‌افتد. نه بپرسید «نظرت چیست؟»، نه توضیح بدهید که «اینجا را باید بزنی»؛ فقط یک وظیفهٔ واقعی بدهید و ساکت بمانید. هرجا کاربر مکث کرد، اشتباه کلیک کرد، عقب برگشت یا زیر لب گفت «این کجاست؟»، یک مشکل کاربردپذیری را با چشم خودتان دیده‌اید.

تفاوت بنیادی این روش با بقیهٔ روش‌ها همین‌جاست: تست کاربردپذیری رفتار را می‌سنجد، نه عقیده را. کاربران در توصیف اینکه چه چیزی می‌خواهند یا چرا کاری کرده‌اند ضعیف‌اند، اما در انجام‌دادن کار — و شکست‌خوردن در آن — کاملاً صادق‌اند. به همین دلیل، تست کاربردپذیری مستقیم‌ترین راهی است که برای فهمیدن «آیا این طرح واقعاً کار می‌کند؟» در اختیار داریم.

نکتهٔ مهم دیگر: تست کاربردپذیری یک رویداد یک‌باره در انتهای پروژه نیست. از همان اسکچ‌های کاغذی و وایرفریمهای اولیه شروع می‌شود، روی پروتوتایپ ادامه پیدا می‌کند و حتی بعد از انتشار محصول هم متوقف نمی‌شود. هرچه زودتر تست کنید، اصلاح‌کردن ارزان‌تر است؛ مشکلی که در اسکچ کاغذی پیدا شود با یک پاک‌کن حل می‌شود، همان مشکل بعد از انتشار ممکن است ماه‌ها کار مهندسی بخواهد.

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

هدف تست کاربردپذیری «اثباتِ خوب‌بودن طرح» نیست؛ برعکس، هدف پیداکردن جاهایی است که طرح می‌شکند. یک جلسهٔ تست خوب معمولاً به این پرسش‌ها جواب می‌دهد:

• - آیا کاربر می‌تواند وظیفه را مستقلاً تمام کند؟ بدون راهنمایی، بدون کمکِ تسهیل‌گر، بدون حدس‌زدن‌های شانسی.
• - چقدر طول می‌کشد و چه هزینه‌ای دارد؟ کاربر چند کلیک زد، چند بار برگشت، چند مسیر اشتباه رفت.
• - حال کاربر در حین کار چطور است؟ آیا آرام و مطمئن است، یا کلافه، مردد و مضطرب؟
• - مشکلات دقیقاً کجا هستند و چقدر جدی‌اند؟ یک اشکالِ آزاردهندهٔ کوچک با یک مانعِ کاملاً بازدارنده فرق دارد.
• - راه‌حل احتمالی چیست؟ رفتار کاربر معمولاً خودش سرنخ می‌دهد که انتظار داشته چه چیزی کجا باشد.

و یک هدف نانوشته اما بسیار مهم: پایان‌دادن به بحث‌های سلیقه‌ای درون تیم. وقتی همهٔ اعضای تیم ببینند که سه کاربر پشت سر هم دکمهٔ «ادامه» را پیدا نکردند، بحث دربارهٔ رنگ آن دکمه در پنج دقیقه تمام می‌شود.

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

سه سوءتفاهم رایج را روشن کنیم:

• - جایگزین تحقیق کاربر نیست. تحقیق کاربر به شما می‌گوید کاربران چه کسانی‌اند، چه نیازی دارند و چه مشکلی را باید حل کنید؛ تست کاربردپذیری می‌گوید راه‌حلی که ساخته‌اید قابل‌استفاده هست یا نه. اولی مسئلهٔ درست را پیدا می‌کند، دومی راه‌حل را اصلاح می‌کند. هیچ‌کدام دیگری را بی‌نیاز نمی‌کند.
• - ارزیابی اکتشافی نیست. در ارزیابی اکتشافی، متخصص‌ها رابط را با معیارهای شناخته‌شده بررسی می‌کنند — سریع و ارزان، اما بدون حضور کاربر واقعی. این دو روش مکمل‌اند: ارزیابی اکتشافی مشکلات آشکار را قبل از تست پاک می‌کند تا وقتِ گران‌بهای شرکت‌کننده‌ها صرف مسائل عمیق‌تر شود.
• - «تست کاربر» نیست. اصطلاح رایجِ «تست کاربر» گمراه‌کننده است؛ ما کاربر را تست نمی‌کنیم، طرح را تست می‌کنیم. این تفاوت فقط لفظی نیست: اگر شرکت‌کننده حس کند خودش در حال آزمون‌دادن است، شکستش را پنهان می‌کند و داده‌های شما خراب می‌شود.

چرخهٔ چهارمرحله‌ای تست

تست کاربردپذیری یک فرایند تکرارشونده است: تست می‌کنید، اصلاح می‌کنید، دوباره تست می‌کنید. هر دور معمولاً چهار مرحله دارد.

۱. برنامه‌ریزی: چه چیزی را می‌خواهید بفهمید؟

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

در همین مرحله تصمیم بگیرید تست حضوری باشد یا از راه دور، مدیریت‌شده باشد یا نه، و روی چه چیزی اجرا شود: اسکچ کاغذی، پروتوتایپ کلیک‌خور، یا محصول زنده.

۲. تعریف وظایف: کار بدهید، نه دستورالعمل

وظیفه باید سناریوی واقعی زندگی کاربر باشد، نه فهرست مراحل. تفاوت را ببینید:

• - ❌ بد: «روی منوی تنظیمات کلیک کن، بعد برو به بخش پرداخت و کارت جدید را اضافه کن.» — این عملاً جواب را لو داده است.
• - ✅ خوب: «کارت بانکی‌ات منقضی شده و می‌خواهی اشتراکت قطع نشود. لطفاً ترتیبش را بده.» — حالا می‌بینید کاربر خودش کجا را می‌گردد.

چند قاعدهٔ عملی: بیشتر از پنج وظیفه به هر نفر ندهید، کل جلسه را حدود ۶۰ دقیقه نگه دارید، از واژه‌های داخل رابط در متن وظیفه استفاده نکنید (اگر بگویید «سبد خرید»، کاربر فقط دنبال همان کلمه می‌گردد)، و وظایف را از ساده به پیچیده مرتب کنید تا شرکت‌کننده گرم شود. اگر پرسونا دارید، سناریوها را از دل اهداف واقعی همان پرسونا بیرون بکشید.

۳. جذب شرکت‌کننده: چند نفر و چه کسانی؟

مهم‌تر از تعداد، تناسب است. شرکت‌کننده باید نمایندهٔ کاربر واقعی شما باشد؛ تست‌کردن یک اپلیکیشن حسابداری با پنج دانشجوی طراحی، داده‌ای تولید می‌کند که به درد نمی‌خورد. با یک پرسش‌نامهٔ کوتاهِ غربالگری، افراد را بر اساس ویژگی‌های واقعی — سطح تجربه، شغل، دفعات استفاده — انتخاب کنید و برای وقتی که می‌گذارند پاداشی در نظر بگیرید.

و اما عددِ معروف: حدود پنج کاربر، نزدیک به ۸۵٪ مشکلات اصلی را آشکار می‌کنند. دلیلش ساده است — بیشترِ مشکلات جدی آن‌قدر بنیادی‌اند که تقریباً هر کاربری به آن‌ها برمی‌خورد؛ از نفر ششم به بعد بیشتر تکرار می‌بینید تا کشف تازه. منطقِ عملی این یافته این نیست که «فقط پنج نفر کافی است»، بلکه این است که به‌جای یک تست بزرگ با پانزده نفر، سه دور تست پنج‌نفره اجرا کنید و بین هر دور طرح را اصلاح کنید. اگر چند گروه کاربری کاملاً متفاوت دارید (مثلاً خریدار و فروشنده)، برای هر گروه جداگانه حساب کنید.

۴. اجرا و مشاهده: ساکت بمانید

سخت‌ترین مهارت تسهیل‌گری، سکوت است. وقتی کاربر گیر می‌کند، غریزهٔ طراح می‌گوید کمک کن؛ اما دقیقاً همان لحظهٔ گیرکردن، گران‌بهاترین دادهٔ کل جلسه است. اجازه بدهید کاربر تلاش کند، و فقط وقتی واقعاً به بن‌بست رسید مداخله کنید.

چند اصل کلیدی در جلسه:

• - در ابتدا صریح بگویید «ما طرح را تست می‌کنیم، نه شما را؛ هیچ جواب غلطی وجود ندارد».
• - سؤال هدایت‌کننده نپرسید. به‌جای «آسان بود، نه؟» بپرسید «الان چه فکری می‌کنی؟».
• - به‌جای پاسخ‌دادن، سؤال را برگردانید: «خودت فکر می‌کنی اینجا چه اتفاقی باید بیفتد؟»
• - دقیقاً بنویسید کاربر چه کرد، جدا از اینکه چه گفت؛ این دو اغلب با هم نمی‌خوانند.
• - با اجازهٔ شرکت‌کننده ضبط کنید تا بعداً بتوانید لحظه‌های کلیدی را به تیم نشان دهید.

روش «بلندبلند فکر کن»

پرکاربردترین تکنیک در جلسات تست، «Think Aloud» است: از شرکت‌کننده می‌خواهید هرچه از ذهنش می‌گذرد را بلند بگوید — انتظارش، تردیدش، دلیل هر کلیک. این کار پنجره‌ای به مدل ذهنی کاربر باز می‌کند و به شما نشان می‌دهد که او فکر می‌کند سیستم چطور کار می‌کند. اغلبِ مشکلات کاربردپذیری دقیقاً از فاصلهٔ همین مدل ذهنی با مدل واقعی سیستم می‌آیند.

دو نکته: بلندفکرکردن کمی سرعت کاربر را کم می‌کند، پس برای سنجش دقیقِ «زمان انجام وظیفه» مناسب نیست. و اگر شرکت‌کننده ساکت شد، به‌جای پرسش‌های جهت‌دار فقط یادآوری کنید: «همین‌طور بلند فکر کن».

حالت‌های مختلف تست

تست کاربردپذیری یک قالب ثابت ندارد. دو محور اصلی انتخاب دارید: حضور یا نبودِ تسهیل‌گر، و حضوری یا از راه دور بودنِ جلسه.

• - مدیریت‌شدهٔ حضوری: غنی‌ترین داده. زبان بدن، مکث‌ها، آه‌کشیدن‌ها و امکان پرسیدن «چرا؟» درست در همان لحظه. در عوض گران‌ترین و کندترین حالت است.
• - مدیریت‌شدهٔ از راه دور: با یک تماس تصویری و اشتراک صفحه اجرا می‌شود. تقریباً همان کیفیت گفت‌وگو را دارد، جغرافیا را حذف می‌کند و هزینه را پایین می‌آورد؛ اما بخشی از سیگنال‌های بدنی و کنترل محیط را از دست می‌دهید.
• - غیرمدیریت‌شدهٔ از راه دور: کاربر در زمان دلخواه خودش وظایف را روی ابزاری آنلاین انجام می‌دهد و ابزار، صفحه و صدا را ضبط می‌کند. سریع، ارزان و مقیاس‌پذیر — مناسب وقتی سؤال‌تان کمّی است یا به نمونهٔ بزرگ نیاز دارید. اما نمی‌توانید سؤال پیگیرانه بپرسید و «چرا»ی رفتارها اغلب مبهم می‌ماند.
• - تست چریکی (گوریلا): نسخهٔ سبک و سریع کار — با یک لپ‌تاپ یا موبایل سراغ آدم‌ها در کافه یا لابی می‌روید و پنج دقیقه وقت می‌گیرید. دقتش پایین‌تر است، ولی برای گرفتنِ بازخورد سریع روی یک ایدهٔ خام بی‌رقیب است.

برای موبایل چند ملاحظهٔ اضافه هست: دستگاه باید واقعی باشد نه شبیه‌ساز، دست کاربر را (نه صورتش را) ضبط کنید تا حرکت انگشت دیده شود، و حتماً در شرایط واقعی — ایستاده، در حرکت، با یک دست، با اینترنت ضعیف — هم تست کنید.

تست تکوینی و تست تجمیعی

بسته به اینکه کجای مسیر ایستاده‌اید، دو نوع تست وجود دارد:

• - تکوینی (Formative): در حین ساختن، با نمونهٔ کوچک و تمرکز بر کیفیت. پرسش این است: «کجا می‌شکند و چطور درستش کنیم؟» بیشترِ تست‌هایی که در عمل انجام می‌دهید از این نوع‌اند و مستقیماً به مرحلهٔ آزمایش در تفکر طراحی گره می‌خورند.
• - تجمیعی (Summative): در پایان یک چرخه، با نمونهٔ بزرگ‌تر و تمرکز بر عدد. پرسش این است: «وضعیت فعلی چقدر خوب است و نسبت به نسخهٔ قبلی یا رقیب کجا ایستاده‌ایم؟»

چه چیزی را اندازه می‌گیریم؟

تست کاربردپذیری هم داده‌های کمّی می‌دهد و هم کیفی، و قدرت واقعی‌اش در ترکیب این دو است.

سنجه‌های کمّی — چیزهایی که می‌شمارید:

• - نرخ موفقیت در وظیفه: چند درصد شرکت‌کننده‌ها کار را بدون کمک تمام کردند. ساده‌ترین و گویاترین عدد.
• - زمان انجام وظیفه: چقدر طول کشید — به‌ویژه در مقایسه با نسخهٔ قبلی طرح.
• - میزان تلاش: تعداد کلیک‌ها، صفحه‌های اضافی، دفعات برگشت به عقب.
• - خطاها: چند بار کاربر مسیر اشتباه رفت و آیا خودش توانست جبران کند.

سنجه‌های کیفی — چیزهایی که تفسیر می‌کنید: تردیدها و مکث‌های طولانی، حالت چهره و زبان بدن، جمله‌هایی که زیر لب گفته می‌شود، و حس کلی رضایت که معمولاً با یک پرسش‌نامهٔ کوتاه بعد از هر وظیفه یا انتهای جلسه ثبت می‌شود.

عددها به شما می‌گویند «چقدر بد است»، مشاهده‌های کیفی می‌گویند «چرا بد است». اولی مدیر را قانع می‌کند، دومی به طراح می‌گوید چه کاری باید بکند.

تحلیل نتایج و اولویت‌بندی

بعد از جلسات، انبوهی یادداشت و ویدئو دارید. کار تحلیل این است که این‌ها را به فهرستی از «مشکلات» تبدیل کنید، نه فهرستی از «اتفاق‌ها». مسیر عملی:

• - مشاهده‌ها را کنار هم بگذارید: هر لحظهٔ گیرکردن را روی یک برچسب بنویسید و برچسب‌های مشابه را خوشه‌بندی کنید. الگویی که در سه نفر از پنج نفر تکرار شود، یک مشکل واقعی است؛ اتفاقی که فقط برای یک نفر افتاده، احتمالاً نویز است.
• - شدت را رتبه‌بندی کنید: هر مشکل را بر اساس دو معیار بسنجید — چقدر مانع انجام کار می‌شود و برای چند درصد کاربران رخ می‌دهد. نتیجه معمولاً سه سطح می‌شود: بازدارنده (کاربر اصلاً نمی‌تواند ادامه دهد)، جدی (می‌تواند، ولی با اصطکاک زیاد) و جزئی (آزاردهنده اما بی‌خطر).
• - گزارش را کوتاه و بصری بنویسید: برای هر مشکل، یک جملهٔ توصیف، یک شاهد (کلیپ کوتاه یا نقل‌قول)، سطح شدت و یک پیشنهاد اصلاح. گزارش سی‌صفحه‌ای خوانده نمی‌شود.
• - تیم را در جریان بگذارید: بهترین حالت این است که مهندس‌ها و مدیر محصول خودشان چند جلسه را تماشا کنند. هیچ گزارشی به‌اندازهٔ دیدنِ زندهٔ سردرگمی کاربر اثر ندارد.

و بعد مهم‌ترین گام: اصلاح کنید و دوباره تست کنید. تستی که به تغییر ختم نشود، فقط هزینه بوده است.

اشتباه‌های رایج

• - تست‌کردن خیلی دیر: وقتی محصول ساخته شده و تاریخ انتشار نزدیک است، تست به مراسمی تشریفاتی تبدیل می‌شود که نتایجش را کسی اجرا نمی‌کند.
• - راهنمایی‌کردن ناخواسته: یک «الان بزن روی همان دکمهٔ بالا» کل دادهٔ آن وظیفه را بی‌اعتبار می‌کند.
• - تست با همکاران و دوستان: آن‌ها محصول و واژگانش را می‌شناسند و ناخودآگاه مهربان‌اند؛ نتیجه، خوش‌بینی کاذب است.
• - پرسیدن به‌جای مشاهده: «آیا از این صفحه استفاده می‌کنی؟» جوابش تقریباً همیشه خوش‌بینانه است. رفتار را ببینید، نه ادعا را.
• - گوش‌ندادن به یک گروه: اگر کاربران دارای معلولیت در نمونهٔ شما نباشند، بخشی از مشکلات دسترس‌پذیری هرگز در تست‌تان ظاهر نمی‌شود.
• - جمع‌کردن یافته‌ها بدون اقدام: فهرست مشکلاتی که در بک‌لاگ خاک می‌خورد، ارزشی برابر با تست‌نکردن دارد.

جمع‌بندی

• - تست کاربردپذیری یعنی تماشای کاربران واقعی هنگام انجام وظایف واقعی؛ رفتار را می‌سنجد، نه عقیده را.
• - چرخهٔ کار چهار مرحله دارد — برنامه‌ریزی با فرضیهٔ روشن، تعریف حداکثر پنج وظیفهٔ سناریومحور، جذب شرکت‌کنندهٔ نماینده، و مشاهدهٔ ساکت — و باید تکرار شود.
• - حدود پنج کاربر بیشترِ مشکلات اصلی را آشکار می‌کنند؛ پس به‌جای یک تست بزرگ، چند دور کوچک با اصلاح در فاصلهٔ بین آن‌ها اجرا کنید.
• - حالت‌های مدیریت‌شده/غیرمدیریت‌شده و حضوری/از راه دور هرکدام موازنهٔ خودشان را میان عمق، سرعت و هزینه دارند.
• - سنجه‌های کمّی می‌گویند مشکل چقدر بزرگ است و مشاهده‌های کیفی می‌گویند چرا رخ می‌دهد؛ یافته‌ها را بر اساس شدت اولویت‌بندی کنید.
• - تست کاربردپذیری جایگزین تحقیق کاربر یا ارزیابی اکتشافی نیست؛ مکمل آن‌هاست و مثل آن‌ها فقط وقتی ارزش دارد که به تغییر در طرح ختم شود.