پاسخ مستقیم: تست کاربردپذیری سایت یعنی مشاهده کاربران واقعی یا نزدیک به مخاطب هدف، هنگام انجام چند کار مشخص در سایت؛ برای مثال پیدا کردن یک خدمت، مقایسه گزینهها یا تکمیل فرم درخواست. هدف این تست سنجیدن حافظه یا مهارت کاربر نیست؛ میخواهیم ببینیم رابط، محتوا و مسیرها تا چه اندازه قابل فهماند و کاربر دقیقاً کجا مکث میکند، مسیر اشتباه میرود یا از ادامه منصرف میشود.
یک تست مفید با سؤال پژوهشی روشن، شرکتکننده مرتبط، سناریوی باورپذیر و مشاهده بیطرفانه شروع میشود. خروجی آن نیز فهرستی از سلیقهها نیست؛ شواهدی است که نشان میدهد کدام مشکل، کدام کاربر و کدام مرحله مهم را تحت تأثیر قرار داده است. در این راهنما از طراحی مطالعه تا اجرای جلسه، تحلیل یافتهها و تبدیل آنها به تصمیم طراحی را قدمبهقدم بررسی میکنیم.
تست کاربردپذیری سایت چیست و چه چیزی را مشخص میکند؟
در تست کاربردپذیری، شرکتکننده تلاش میکند یک یا چند وظیفه را با نسخه واقعی سایت، نمونه اولیه یا حتی طرح تعاملی انجام دهد. پژوهشگر رفتار را میبیند، گفتههای کاربر را میشنود و پس از هر مرحله با پرسشهای باز، دلیل تصمیمها را روشن میکند. راهنمای رسمی GOV.UK برای تست کاربردپذیری هدایتشده نیز این روش را مشاهده شرکتکنندگان هنگام انجام وظایف مشخص تعریف میکند.
این روش به پرسشهایی مانند اینها پاسخ میدهد: آیا کاربر معنی برچسب منو را میفهمد؟ آیا اطلاعات لازم برای اعتماد در زمان درست دیده میشود؟ آیا بین صفحه خدمت و فرم تماس گسست وجود دارد؟ آیا پیام خطا راه اصلاح را نشان میدهد؟ پاسخها فقط از چیزی که کاربر میگوید به دست نمیآیند. فاصله میان گفته و رفتار، مکث طولانی، بازگشت مکرر و انتخاب مسیر غیرمنتظره نیز دادهاند.
| روش | چه چیزی نشان میدهد؟ | چه چیزی را به تنهایی ثابت نمیکند؟ |
|---|---|---|
| تست کاربردپذیری | نحوه انجام وظیفه و نقاط اصطکاک | اندازه مشکل در کل کاربران |
| تحلیل رفتار و قیف | الگو و حجم رفتار ثبتشده | دلیل ذهنی رفتار |
| نظرسنجی | نظر و ادراک خوداظهاری | توانایی واقعی انجام کار |
| آزمون فنی | خطا، سازگاری و عملکرد سیستم | فهمپذیری رابط برای مخاطب |
تست کاربر جای کنترل کیفیت فنی، تحلیل داده یا ارزیابی دسترسپذیری را نمیگیرد. این روش آنها را کامل میکند. سایت ممکن است از نظر فنی بدون خطا باشد، اما کاربر دکمه اصلی را نبیند. برعکس، شرکتکننده شاید یک مسیر را کامل کند، ولی صفحه برای فناوریهای کمکی همچنان مانع داشته باشد.
پیش از جلسه، سؤال پژوهشی و محدوده را دقیق کنید
جمله «میخواهیم ببینیم سایت خوب است یا نه» قابل آزمون نیست. سؤال پژوهشی باید به یک رفتار، گروه کاربر و مرحله تصمیم اشاره کند: «آیا مدیر یک کسب و کار خدماتی میتواند خدمت مناسب را پیدا کند، تفاوت آن را بفهمد و بداند برای دریافت برآورد چه اطلاعاتی لازم است؟» چنین سؤالی به شما کمک میکند صفحه، وظیفه و شرکتکننده مناسب را انتخاب کنید.
دامنه هر دور را محدود نگه دارید. بررسی همه منوها، محتوا، موبایل، فرمها و فرایند خرید در یک جلسه، تمرکز را از بین میبرد و شرکتکننده را خسته میکند. ابتدا پرریسکترین فرض یا مهمترین مسیر را انتخاب کنید. اگر هنوز ساختار صفحه تثبیت نشده، میتوانید با وایرفریم سایت تست را آغاز کنید؛ لازم نیست برای کشف مشکل بنیادین تا پایان توسعه صبر کنید.
یک برنامه پژوهش یکصفحهای بسازید
- تصمیم موردنظر: نتیجه این مطالعه قرار است کدام تصمیم طراحی یا محتوا را روشن کند؟
- گروه هدف: چه کسی این مسیر را در دنیای واقعی طی میکند؟
- سؤال پژوهشی: چه چیز مشخصی را هنوز نمیدانیم؟
- نمونه یا محیط: سایت زنده، محیط آزمایشی یا پروتوتایپ؟
- وظایف: کدام رفتارها باید بدون راهنمایی مشاهده شوند؟
- شواهد: موفقیت، شکست، مکث، مسیر و برداشت کاربر چگونه ثبت میشود؟
- محدودیت: این مطالعه درباره چه چیزی نتیجهگیری نخواهد کرد؟
برای نمونه، اگر نرخ ارسال فرم پایین است، فوراً فرض نکنید فرم طولانی است. شاید کاربر پیش از رسیدن به فرم درباره دامنه خدمت، قیمت یا مرحله بعد پاسخ نگرفته باشد. سؤال پژوهشی را به کل مسیر مرتبط کنید، نه فقط به عنصری که در گزارش عدد پایینتری دارد.
شرکتکننده مرتبط انتخاب کنید و رضایت آگاهانه بگیرید
شرکتکننده باید با کاربر واقعی یا محتمل مسیر تناسب داشته باشد. همکاران داخلی معمولاً اصطلاحات، ساختار سازمان و هدف صفحه را میدانند؛ بنابراین ممکن است مشکلی را که کاربر تازهوارد دارد تجربه نکنند. در راهنمای جذب شرکتکننده GOV.UK نیز بر انتخاب کاربران واقعی یا احتمالی و پوشش ویژگیهای مرتبط با خدمت تأکید شده است.
معیار جذب را از سؤال پژوهشی استخراج کنید. برای تست فرم درخواست طراحی سایت، داشتن یا برنامهریزی برای راهاندازی کسب و کار آنلاین میتواند مرتبط باشد؛ عنوان شغلی دقیق شاید ضروری نباشد. اگر محصول برای چند گروه با نیازهای متفاوت است، آنها را آگاهانه در دورهای جدا یا نمونه متنوع بگنجانید. تعداد شرکتکنندگان نسخه جادویی و ثابتی ندارد؛ به تنوع مخاطب، ریسک تصمیم، پیچیدگی مسیر و میزان تکرار یافتهها وابسته است.
دسترسپذیری را وارد نمونه پژوهش کنید
اگر سایت باید برای افراد دارای معلولیت یا کاربران فناوری کمکی کار کند، حضور این کاربران را به یک مرحله فرعی موکول نکنید. راهنمای W3C درباره مشارکت کاربران در ارزیابی دسترسپذیری توضیح میدهد که حضور کاربران دارای معلولیت میتواند مسائل کاربردپذیری واقعی را آشکار کند؛ با این حال این مشاهده جای ارزیابی نظاممند بر اساس استانداردهای دسترسپذیری را نمیگیرد.
شرکتکننده باید پیش از جلسه بداند چه چیزی ثبت میشود، چه کسی داده را میبیند، نگهداری آن تا چه زمانی است و آیا میتواند بدون پیامد از ادامه انصراف دهد. فقط داده لازم را جمع کنید. نام فایلها، ویدئوها و یادداشتها نباید اطلاعات حساس را بیدلیل آشکار کنند. اگر از صفحه واقعی استفاده میکنید، راهی برای جلوگیری از ثبت سفارش، پرداخت یا ارسال اطلاعات شخصی واقعی در نظر بگیرید.
سناریو و وظیفهای بنویسید که پاسخ را لو ندهد
وظیفه خوب کوتاه، باورپذیر و نتیجهمحور است؛ اما نام دقیق منو، دکمه یا پاسخ مطلوب را در خود ندارد. به جای «از منوی خدمات وارد طراحی سایت اختصاصی شوید و فرم درخواست را پر کنید» بگویید: «فرض کنید برای کسب و کارتان به یک وبسایت نیاز دارید. بررسی کنید این مجموعه چه راهحلی برای شما دارد و اگر مناسب بود، ببینید برای شروع همکاری چه کاری باید انجام دهید.»
وظایف را با زبان کاربر بنویسید، نه ساختار سازمان. اگر کاربر باید از متن سناریو بفهمد کدام لینک را انتخاب کند، شما بیشتر توانایی پیروی از دستور را سنجیدهاید تا فهم رابط. راهنمای GOV.UK نیز توصیه میکند وظایف روشن و باورپذیر باشند، پاسخ را تلقین نکنند و بر فعالیتهایی تمرکز کنند که کاربر واقعاً انجام میدهد.
نمونه سناریو برای یک سایت خدماتی
فرض کنید صاحب یک فروشگاه محلی است و سایت قدیمی او روی موبایل سخت استفاده میشود. میخواهد بداند بازطراحی چه مراحلی دارد، آیا نمونه مرتبطی وجود دارد و برای برآورد اولیه چه اطلاعاتی باید آماده کند. از او بخواهید گزینه مناسب را پیدا کند و توضیح دهد قدم بعدی از نظر او چیست. پژوهشگر نباید بگوید از کدام صفحه یا کدام CTA استفاده شود.
برای هر وظیفه، معیار مشاهده بنویسید: نقطه شروع، نتیجه مورد انتظار، مسیرهای قابل قبول و شرایط توقف. اگر چند مسیر به نتیجه درست میرسند، فقط مسیر طراحیشده توسط تیم را موفق ندانید. گاهی مسیر غیرمنتظره بهتر از معماری فعلی است و سرنخی برای بهبود ساختار میدهد. مقاله اشتباهات رایج طراحی سایت نمونههایی از مشکلاتی را نشان میدهد که میتوان آنها را به وظایف قابل مشاهده تبدیل کرد.
جلسه هدایتشده را بیطرف و منظم اجرا کنید
در آغاز توضیح دهید که سایت آزمایش میشود، نه شرکتکننده؛ بنابراین پاسخ درست یا غلطی وجود ندارد. از او بخواهید هنگام کار، آنچه انتظار دارد یا موجب تردیدش میشود با صدای بلند بیان کند. این درخواست را تمرین کنید، اما او را وادار به توجیه هر کلیک نکنید؛ فکر کردن با صدای بلند نباید انجام طبیعی کار را کاملاً مختل کند.
هنگام وظیفه بیشتر مشاهده کنید و کمتر حرف بزنید. اگر شرکتکننده میپرسد «باید روی این دکمه بزنم؟» پاسخ خنثی بدهید: «شما انتظار دارید بعد از انتخاب آن چه اتفاقی بیفتد؟» کمک زودهنگام، دقیقاً همان نقطهای را پنهان میکند که باید ثبت شود. اگر کاربر کاملاً گیر کرده یا ناراحت شده، جلسه را قربانی جمعآوری داده نکنید؛ کمک کنید و آن لحظه را بهعنوان مانع ثبت کنید.
نقشها و ابزار ثبت
- تسهیلگر: رابطه جلسه را مدیریت میکند و سؤال بیطرف میپرسد.
- یادداشتبردار: مشاهده، نقلقول کوتاه و زمان رخداد را ثبت میکند.
- ناظر: در صورت حضور، ساکت میماند و مستقیماً از کاربر سؤال نمیپرسد.
- ضبط: فقط با رضایت و با برنامه روشن برای دسترسی و حذف انجام میشود.
یک جدول ساده برای هر رخداد کافی است: وظیفه، رفتار مشاهدهشده، گفته کاربر، نتیجه و یادداشت زمینه. برداشت پژوهشگر را از مشاهده جدا بنویسید. «کاربر سه بار بین صفحه خدمت و قیمت برگشت» مشاهده است؛ «کاربر به برند اعتماد ندارد» تفسیر است و برای پذیرفتن به شواهد بیشتری نیاز دارد.
جلسه را با چند پرسش باز تمام کنید: «کدام بخش بیشترین تردید را ایجاد کرد؟»، «پیش از تصمیم چه اطلاعات دیگری لازم داشتید؟» و «اگر این کار را در دنیای واقعی انجام میدادید، قدم بعدی چه بود؟» از پرسشهایی مثل «طراحی را دوست داشتید؟» یا «دکمه واضح بود، درست است؟» دوری کنید؛ این پرسشها پاسخ مطلوب را القا میکنند.
یافتهها را از مشاهده به اولویت طراحی تبدیل کنید
پس از هر جلسه یادداشتها را سریع مرور کنید؛ اما با اولین مشکل، کل طراحی را عوض نکنید. شواهد دورها را کنار هم بگذارید و بر اساس وظیفه و نقطه مسیر خوشهبندی کنید. تفاوت رفتارها را نیز حفظ کنید. اگر یک نفر بهدلیل تجربه قبلی مسیر دیگری را انتخاب کرده، این داده لزوماً خطا نیست و میتواند تفاوت یک گروه کاربری را نشان دهد.
هر یافته باید چهار جزء داشته باشد: چه کسی، در چه شرایطی، چه رفتاری نشان داد و پیامد آن برای انجام کار چه بود. به جای «صفحه شلوغ است» بنویسید: «سه شرکتکنندهای که از موبایل وارد شدند، اطلاعات مرحله بعد را زیر بخش نمونهها پیدا نکردند و دو نفر پیش از رسیدن به فرم از وظیفه صرفنظر کردند.» اگر تعداد یا نتیجه دقیق ندارید، آن را نسازید؛ گزارش فقط باید آنچه واقعاً مشاهده شده بازتاب دهد.
ماتریس ساده اولویتبندی
| معیار | پرسش تصمیمگیری |
|---|---|
| اثر | آیا مشکل مانع تکمیل کار اصلی میشود یا فقط سرعت را کم میکند؟ |
| دامنه | کدام گروهها و چند مسیر با این مانع روبهرو میشوند؟ |
| فراوانی | آیا الگو در چند جلسه تکرار شد یا موردی وابسته به زمینه بود؟ |
| ریسک | آیا خطا پیامد مالی، حقوقی، حریم خصوصی یا دسترسی دارد؟ |
| اطمینان | شاهد مستقیم داریم یا هنوز با یک فرضیه روبهرو هستیم؟ |
راهحل را مستقیماً از جمله کاربر کپی نکنید. کاربر در توضیح مسئله متخصص است، اما لزوماً بهترین معماری یا رابط را طراحی نمیکند. اگر میگوید «یک دکمه بزرگتر لازم است»، ابتدا ببینید آیا مشکل از نامشخص بودن ارزش اقدام، جایگاه نامناسب، کنتراست، ترتیب محتوا یا چند CTA رقیب ناشی میشود. سپس چند راهحل بسازید و نسخه اصلاحشده را دوباره آزمایش کنید.
با معیار پایه و دورهای کوتاه، کیفیت را پیوسته بسنجید
تست کاربردپذیری یک تأیید نهایی پیش از انتشار نیست. آن را در نقاط تصمیم تکرار کنید: هنگام تعیین معماری، روی نمونه اولیه، پیش از انتشار و پس از مشاهده رفتار واقعی. دورهای متمرکز کمک میکنند مسئله را زودتر کشف و اثر تغییر را بررسی کنید. برای پروژهای که صفحه فرود نیز دارد، راهنمای طراحی صفحه فرود کمپین تبلیغاتی نشان میدهد پیام، فرم و سنجش چگونه باید در یک مسیر واحد بررسی شوند.
برای مقایسه نسخهها میتوانید معیار پایه تعریف کنید. راهنمای رسمی معیارسنجی کاربردپذیری GOV.UK پیشنهاد میکند داده عملکرد با پژوهش کیفی ترکیب شود. موفقیت وظیفه، زمان انجام، رهاکردن مسیر، موفقیت کاذب و دشواری ادراکشده از معیارهای ممکناند؛ اما عدد بدون مشاهده توضیح نمیدهد چرا تغییر رخ داده است.
چکلیست آمادهسازی و کنترل کیفیت
- سؤال پژوهشی به یک تصمیم واقعی و یک مسیر مشخص متصل است.
- شرکتکنندگان با کاربران واقعی یا احتمالی مسیر تناسب دارند.
- رضایت، حریم خصوصی و شیوه نگهداری داده روشن شده است.
- وظایف باورپذیرند و نام دکمه یا پاسخ را لو نمیدهند.
- نسخه آزمایشی، دستگاه، اینترنت و حسابهای لازم پیشاپیش بررسی شدهاند.
- تسهیلگر پاسخ را القا نمیکند و کمکهای لازم را ثبت میکند.
- مشاهده از تفسیر جداست و هر یافته به شواهد قابل پیگیری متصل است.
- اولویت با اثر بر کار کاربر، ریسک و دامنه مشکل تعیین میشود.
- نسخه اصلاحشده در دور بعدی دوباره ارزیابی میشود.
جمعبندی: تست کاربردپذیری سایت زمانی ارزشمند است که از یک مسئله تصمیمپذیر شروع شود و به تغییری قابل ارزیابی برسد. کاربر مرتبط انتخاب کنید، وظیفه واقعی بنویسید، هنگام جلسه سکوت و مشاهده را جدی بگیرید، یافتهها را با پیامدشان گزارش کنید و نتیجه یک نمونه کوچک را به همه کاربران تعمیم ندهید. هدف، اثبات خوب بودن طرح نیست؛ کشف زودهنگام موانعی است که تیم از داخل پروژه دیگر نمیبیند.
برای مطالعه مطالب مکمل تجربه کاربری، دسته طراحی Ui , Ux پیناروب را ببینید.
اگر میخواهید مسیرهای کلیدی سایت پیش از توسعه یا بازطراحی با نیاز واقعی کاربران هماهنگ شوند، جزئیات طراحی سایت اختصاصی پیناروب را بررسی کنید.
آخرین بررسی منابع: ۲۸ تیر ۱۴۰۵. منابع تخصصی مقاله از راهنماهای رسمی GOV.UK Service Manual و W3C WAI انتخاب شدهاند.
