مهم: مقاله 10 سال پیش ظاهر شد (تاریخ بالا تاریخ نگارش نیست، بلکه تاریخ آخرین ویرایش است). مقاله به طرز وحشتناکی منسوخ شده است و ما آن را به هیچ وجه حذف نمی کنیم زیرا به دلایلی نامعلوم، طی این سال ها هیچ کس بهتر و جدیدتر به زبان روسی ننوشته است.

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

به راحتی می توان فهمید که آزمایش چیست، با تمام محاسن آن، بسیار وقت گیر و غیرقابل قبول گران است.

در سال های اخیر، وضعیت شروع به تغییر کرده است: به جای تست های بسیار رسمی و بسیار گران قیمت، تست های غیررسمی و ارزان در حال محبوب شدن هستند. به جای یک جمعیت کوچک با یک سری تجهیزات گران قیمت، یک فرد مجرد با حداقل چیزها به میدان می آید. ماهیت این رویکرد در کتاب طراحی وب شرح داده شده است: کتاب استیو کروگ یا من را وادار به فکر کردن نکن! .

البته تست های ساده جهانی نیستند. برای داشبورد هواپیما، احتمالاً مناسب نیستند. اما برای نرم افزارهای معمولی، تست های ساده بسیار بهتر هستند، البته فقط به این دلیل که می توان تعداد بیشتری از آنها را انجام داد.

در اینجا شما یاد خواهید گرفت که چگونه تست قابلیت استفاده را فقط با استفاده از تکنیک های تست سریع انجام دهید. روش‌های پیچیده‌تر و رسمی‌تر را می‌توان در ادبیات تخصصی یافت یا خودتان اختراع کنید.

تست قابلیت استفاده چیست

تست قابلیت استفاده هر آزمایشی است که با هدف اندازه گیری کیفیت یک رابط یا جستجوی مشکلات خاص در آن انجام می شود.

مزایای تست قابلیت استفاده بسیار زیاد است. آزمایش اجازه می دهد:

• برای درک اینکه چقدر رابط کاربری بد یا خوب کار می کند، که ممکن است باعث بهبود آن شود، یا اگر به اندازه کافی خوب است، آرام باشید. در هر صورت سود حاصل می شود.
• کیفیت رابط های قدیمی و جدید را مقایسه کنید و از این طریق تغییرات یا پیاده سازی ها را توجیه کنید.
• قطعات مشکل ساز رابط را پیدا و شناسایی کنید و با حجم نمونه کافی، فراوانی آنها را نیز ارزیابی کنید.

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

اولین آزمایش سیستم های بزرگ همیشه نشان می دهد که رابط کاربری بسیار بدتر از آن چیزی است که صاحب یا سازنده آن فکر می کند و بسیار بهتر از آن چیزی است که آزمایش کننده در ابتدا فکر می کند.

چرا ارزان

سه روش می توانند شدت کار و در نتیجه هزینه تست قابلیت استفاده را به طور چشمگیری کاهش دهند:

1. برخی از ساده سازی مفهوم قابلیت استفاده.
2. امتناع از جمع آوری داده های کمی
3. کاهش هزینه تجهیزات و کاهش پرداخت برای زمان پاسخ دهندگان.

رویکرد سوم استفاده از آزمایشگاه‌های سیار است که در بخش توضیح داده شده است. دو رویکرد باقی مانده در زیر توضیح داده شده است.

کارایی و کارایی

در تفسیر اصلی و پرکاربرد (استاندارد ISO 9241-11)، مفهوم قابلیت استفاده به صورت تعریف شده است.

میزانی که یک محصول می تواند توسط کاربران مشخص برای دستیابی به اهداف مشخص با اثربخشی، کارایی و رضایت در زمینه استفاده مشخص استفاده شود.

ترجمه من از این جمله به روسی:

میزان کارایی*، تلاش** و رضایتی که با آن می توان یک محصول را توسط کاربران خاصی در زمینه استفاده معین برای دستیابی به اهداف معین استفاده کرد.

* مثلاً سرعت کار یا تعداد خطاهای انسانی و مدت زمان اصلاح آنها.

** به عنوان مثال تعداد عملیاتی که برای رسیدن به نتیجه باید انجام شود یا مقدار اطلاعاتی که برای تصمیم گیری باید پردازش شود. مدت، اصطلاح بهره وریهنوز اغلب به روسی به عنوان ترجمه شده است بهره وری; به نظر من، این یک اشتباه فاحش است، زیرا در استاندارد اصلی ISO 9241-11 تحت بهره وریچیزی نزدیک به مفهوم کارایی درک می شود.

شاخص های اصلی عملکرد عبارتند از سرعت کاربر، سرعت یادگیری و تعداد خطاهای انسانی (برای فهرست دقیق تر معیارها، به بخش مراجعه کنید). اینها شاخص های لازم و همچنین تأثیرگذار در طراحی هستند. آنچه خوب است این است که اندازه گیری آنها مشکل خاصی ندارد.

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

• موفقیت، یعنی نسبت تکالیف آزمایشی تکمیل شده به کارهای تکمیل نشده یا کاملاً نادرست انجام شده است.
• قدرت، یعنی نسبت وظایف از فعالیت کاربر به وظایفی که این محصول برای آنها در نظر گرفته شده است.
• بار روی کاربر (هم بار ذهنی و هم، برای مثال، تعداد اقدامات کاربر در هر کار آزمایشی).

اینجا دوتا مشکل داریم. قدرت اصلاً یک شاخص قابل اندازه گیری نیست (قدرت کم و بیش یک محصول کاملاً به طراحی بستگی دارد). اندازه‌گیری بار روی کاربر یا سخت است یا نامربوط، زیرا همچنان در شاخص‌های عملکرد خود را نشان می‌دهد - با یک بار شدید، سرعت کار کاهش می‌یابد. بنابراین، از تمام شاخص های شدت کار در عمل، تنها موفقیت باقی می ماند.

هیچ چیز فتنه انگیزی در این ساده سازی وجود ندارد. در آزمایش واقعی، به هر حال، کل مجموعه شاخص ها هرگز جمع آوری نمی شوند - از این گذشته، فقط برخی از آنها برای هر سیستم خاص مهم هستند. با این حال، پیامد اصلی این ساده‌سازی عبارت - ساده‌سازی قابل‌توجه روش‌شناسی تست قابلیت استفاده - به هیچ طریق دیگری قابل دستیابی نیست.

درجه کارایی، موفقیت و رضایتی که با آن یک محصول می تواند توسط کاربران خاص در زمینه استفاده خاص برای دستیابی به اهداف خاص مورد استفاده قرار گیرد.

بدون مقدار!

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

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

کیفیت یا کمیت؟

آزمایش قابلیت استفاده می‌تواند بر روی دستیابی به داده‌های کمی (که برای اندازه‌گیری قابلیت استفاده رابط مورد نیاز است) یا بر روی دستیابی به داده‌های کیفی (برای درک اینکه دقیقاً چه چیزی بد است و چگونه آن را برطرف کنیم ضروری است) متمرکز شود. به عنوان یک قاعده، دستیابی به هر دو هدف در یک آزمون غیرممکن است.

فرض کنید سرعت کار با سیستم را اندازه گیری می کنیم. در این مورد، آزمایش باید به گونه ای برنامه ریزی شود که از کاهش سرعت کاربر که برای کار واقعی غیرمعمول است، حذف شود. به عنوان مثال، زمانی که کاربر اشتباه می کند، برای یافتن دلایل این خطا نمی توان از او سوالی پرسید. از سوی دیگر، اگر روی داده های کیفی تمرکز کنید، همه نتایج کمی مشکوک خواهند بود.

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

اعداد غیر قابل اعتماد

علاوه بر این، این سؤال که آیا اصلاً باید به نتایج آزمایش قابلیت استفاده اعتماد کرد یا خیر، شایسته بررسی است. از این گذشته، تست کردن جادو نیست، بنابراین با فرض اینکه تست می تواند بد باشد، باید نتیجه گرفت که تست کردن نیز می تواند بد باشد.

پاسخ به این سوال ساده و غم انگیز است - هیچ دلیلی برای باور به نتایج تست قابلیت استفاده وجود ندارد.

در واقع، علیرغم این واقعیت که در آزمایش قابلیت استفاده، داده‌های کاملاً واقعی را به عنوان ورودی داریم، داوطلبانه اجتناب‌ناپذیر ما به ما اجازه نمی‌دهد که به طور کامل به آنها اعتماد کنیم. ما منابع بالقوه زیادی برای خطا داریم:

• کاربران واقعی ممکن است با پاسخ دهندگان منتخب ما متفاوت باشند. در یک نمونه کوچک، حتی یک نوسان جزئی در رفتار پاسخ دهندگان می تواند یک متخصص قابلیت استفاده را به نتیجه گیری های نادرست سوق دهد.
• وظایف تست ممکن است به اندازه کافی فعالیت های واقعی کاربران در سیستم را منعکس نکنند.
• یک متخصص قابلیت استفاده ممکن است بخش هایی از مشکلات را نادیده بگیرد یا اصل مشکلات متوجه شده را اشتباه درک کند.

Rolf Molich به طور منظم تست قابلیت استفاده خود را معیار قرار می دهد. نتایج تکان دهنده است. بنابراین، در آزمون دوم، که در آن 9 گروه از متخصصان کاربردپذیری در سطوح مختلف سرویس HotMail را آزمایش کردند، پراکندگی نتایج بسیار زیاد بود، حتی اگر موارد تست یکسان بودند. همه گروه ها در مجموع 310 مشکل رابط پیدا کردند. اما سه چهارم مشکلات فقط توسط یک گروه یافت شد و توسط بقیه گروه ها یافت نشد (این درصدها شامل بیست و نه مشکل واقعاً جدی است).

به طور کلی، تست قابلیت استفاده شایدتحقیقات علمی که تمام الزامات تحقیقات علمی به طور کلی به طور کامل در مورد آنها قابل اجرا است.

به عنوان مثال، بیایید تست قابلیت استفاده را با تحقیقات جامعه شناختی مقایسه کنیم. متذکر می شوم که جامعه شناس اقدامات ویژه ای انجام می دهد - "پیچیده و کار فشرده" - برای اطمینان از صحت انتخاب پاسخ دهندگان. ما - نه. جامعه شناس هم در جمع آوری داده ها و هم در تجزیه و تحلیل آنها از ابزارهای ثابت شده و از نظر آماری صحیح استفاده می کند. ما - نه.

بنابراین هر زمان که بخواهیم چیزی را به دقت اندازه گیری کنیم، اشتباه می کنیم. وقتی حتی سعی نمی‌کنیم دقیق باشیم، اشتباه می‌کنیم، شاید نه چندان، زیرا میله تقریباً روی زمین قرار دارد.

این به طور خاص به چه معناست؟ به عنوان یک قاعده، نمی توانیم با قاطعیت بگوییم، به عنوان مثال، ما تمام علل خطاهای انسانی را از رابط حذف کرده ایم. صرفاً به این دلیل که با پاسخ دهندگان دیگر، شاید به درستی تطبیق داده شوند، ما - دوباره شاید - - خطاهای بیشتری پیدا می کنیم. همین ملاحظات برای سایر شاخص‌های کیفیت رابط، و حتی بیشتر از آن برای سایر کارهای آزمایشی صادق است. و اگر آزمایش توسط فردی با تجربه تر از ما برنامه ریزی و اجرا شود چه اتفاقی می افتد! و تصورش ترسناک است.

بنابراین، ما باید ارگونومی را فقط برای مقایسه با رابط جدید اندازه گیری کنیم، در حالی که تشخیص می دهیم که اندازه گیری های ما به هیچ وجه صحیح نیستند. آنها فقط برای برنامه ریزی بهینه سازی های بعدی مورد نیاز هستند. ما فقط می توانیم یک چیز را با قاطعیت بگوییم - مهم نیست چقدر آزمایش می کنیم، همیشه جایی برای پیشرفت وجود دارد. به عنوان ذخیره ای برای بهبود خود رابط و همچنین روش های آزمایش ما.

چرا ما به اعداد نیاز داریم؟

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

دقیقا چه چیزی را اندازه گیری کنیم؟

تعداد شاخص های اندازه گیری شده در یک آزمون خاص می تواند بسیار زیاد باشد، اما همه آنها، به عنوان یک قاعده، به مجموعه ای از پنج ویژگی اساسی می رسند. در زیر لیستی از این ویژگی ها با نمونه هایی از معیارهای مبتنی بر آنها آورده شده است.

• سرعت کاربر.معیارها: مدت زمان عملیات. زمان صرف شده برای تشخیص خطا؛ زمان صرف شده برای تصحیح خطاها؛ تعداد دستورات اجرا شده در طول عملیات (این قابل درک است که هر چه تعداد دستورات بیشتر باشد، صدور آنها بیشتر طول می کشد). مدت زمان جستجوی اطلاعات در اسناد؛ تعداد دستوراتی که کارآمدتر از دستورات استفاده شده توسط کاربر هستند. کاهش عملکرد در طول عملیات طولانی مدت
• اشتباهات.معیارها: درصد عملیاتی که باعث خطا شده است. میانگین تعداد خطاها در هر عملیات برای کاربران باتجربه (دقیقا برای کاربران با تجربه، زیرا برای عوامل بی تجربه از گروه نرخ یادگیری نیز می توانند عمل کنند). تعداد اشکالاتی که توسط کاربران شناسایی نشده و تصحیح نشده اند.
• آموزش کار با سیستممعیارها: تعداد و فراوانی ارجاعات به سیستم کمکی. مدت زمان بین شروع استفاده از سیستم و نقطه ای که سرعت کار / تعداد خطاهای کاربر افزایش می یابد. تفاوت در تعداد خطاها / سرعت کار برای کاربران با تجربه در استفاده از سیستم و بدون چنین تجربه ای.
• رضایت ذهنی کاربراندازه گیری این مشخصه با مشکلات خاصی همراه است که شایسته بررسی جداگانه است. معیارهای این ویژگی را در زیر ببینید.
• حفظ مهارت در کار با سیستم.معیارها: تفاوت در سرعت / میزان خطا بین یک کاربر پس از یک ساعت استفاده از سیستم و همان کاربر در شروع استفاده از سیستم پس از یک وقفه طولانی.

همانطور که می بینید، اندازه گیری کیفیت یک رابط می تواند بسیار دشوار باشد، برای مثال، آزمون حفظ مهارت می تواند بیش از یک ماه طول بکشد. اما اینها فقط تست هایی برای مؤلفه های دوم و سوم کاربردپذیری، یعنی کارایی و رضایت هستند. علاوه بر آنها، موفقیت نیز وجود دارد، که مهمتر است و اندازه گیری آن بسیار ساده تر است - فقط باید محاسبه کنید که کاربر چند درصد از وظایف را کاملاً نادرست انجام می دهد یا اصلاً نمی تواند انجام دهد. این امر زندگی یک متخصص قابلیت استفاده را بسیار ساده می کند.

رضایت چقدر عمیق است؟

برخلاف سایر ویژگی ها، رضایت در دنیای واقعی نیست، بلکه در ذهن کاربر است. در نتیجه، "احساس" آن غیرممکن است و بنابراین به طور عینی آن را اندازه گیری کرد. اما حداقل می توان آن را به طور غیر مستقیم اندازه گیری کرد.

دو روش ممکن برای عمل وجود دارد. ابتدا، می توان از پاسخ دهنده پرسید که رابط کاربری چقدر رضایت بخش به نظر می رسد. ثانیاً، با رفتار مخاطب می توان تعیین کرد که آیا او رابط را در هر لحظه خاص از زمان دوست دارد یا نه. با شمارش تعداد واکنش های نشان داده شده، می توان رضایت را ارزیابی کرد. البته این برآوردها نسبی هستند. ارزش آنها فقط در مقایسه با رابط جدید یا در مقایسه با رقبا نشان داده می شود.

در زیر چند روش برای سنجش رضایت آورده شده است.

پرسشنامه

اگر سعی کنید رضایت خود را از طریق نظرسنجی از پاسخ دهندگان تعیین کنید، بدون پرسشنامه رسمی نمی توانید انجام دهید. در واقع، اگر قالب نظرسنجی ثابت نباشد، نمی توان اطمینان داشت که از پاسخ دهندگان سؤال مشابهی پرسیده می شود، به این معنی که پاسخ ها مشکوک می شوند.

متأسفانه، سؤال در شرایط روسیه یک اشکال اساسی دارد - پرسشنامه های قابل اعتماد به سادگی وجود ندارند. علیرغم این واقعیت که پرسشنامه های کاملاً کاربردی زیادی در کشورهای غرب در حال زوال (SUMI، QUIS، MUMMS، IsoMetrics و غیره) ایجاد شده است، هیچ یک از آنها به روسی ترجمه نشده و دوباره آزمایش نشده است. در نتیجه، این پرسشنامه ها، در حالی که اتفاقاً بسیار گران هستند، از هر پرسشنامه ای که خودتان بتوانید تهیه کنید قابل اعتمادتر نیستند.

متأسفانه، تهیه و آزمایش پرسشنامه های قابل اعتماد یک فرآیند بسیار طولانی و پر زحمت است، بنابراین نمی توان روی ظهور سریع پرسشنامه های داخلی با کیفیت بالا حساب کرد.

در زیر دو پرسشنامه قابل اجرا و البته غیر قابل اعتماد آورده شده است.

پرسشنامه با کلمات

این پرسشنامه برای اولین بار توسط محققان آزمایشگاه کاربردپذیری مایکروسافت به عنوان روشی برای اندازه گیری رضایت بسیار سریع، البته به طور مشهور غیرقابل اعتماد، پیشنهاد شد. پرسشنامه بسیار ساده است. به پاسخگو یک ورق کاغذ با مجموعه ای از صفت های تصادفی انتخاب شده ارائه می شود که نیمی از آن نسبتا مثبت و نیمی دیگر منفی است. از پاسخ دهنده خواسته می شود زیر کلماتی که به نظر او برای محصول قابل استفاده است خط بکشد (شباهت پرسشنامه با پرسشنامه های مورد استفاده در روش تفاضلی معنایی معنی دار نیست - اینها روش های کاملاً متفاوتی هستند). پس از تکمیل پرسشنامه، تفاوت بین تعداد عبارت های منفی و مثبت محاسبه می شود.

من از مجموعه صفت های زیر استفاده می کنم:

قدیمی - موثر - مبهم - ناخوشایند - ناخوشایند - کسل کننده - روشن - تمیز - مستقیم - واضح - ناسازگار - فراموش نشدنی - جذاب - استاندارد - مدیریت شده - خوب - شهودی - شاد - آماتور - غیر موثر - خطرناک - خسته کننده - شاد - ایمن - سخت - تحریک کننده - مثلثی - ناخوشایند - راحت - خنک - هوشمند - بی فایده - حلتورال - گرم - سبک - ثابت - مرموز - با کیفیت بالا - جالب - غیر قابل اعتماد - انعطاف پذیر - زیبا - زشت - غیر جذاب - مفید - احمقانه - راحت - راحت - زیبا غیر قابل پیش بینی - واضح - سنگین - مدرن - سبک - دوستانه - غیر استاندارد - بد - قابل اعتماد - پیچیده - ساده - تاریک - حرفه ای - آهسته - گرد - غمگین - غیر دوستانه - قابل پیش بینی - نامفهوم - سریع - معما - غمگین - دلپذیر

لطفاً توجه داشته باشید که کلمات به طور تصادفی با هم مخلوط نمی شوند، به این ترتیب باید به پاسخ دهندگان ارائه شوند.

پرسشنامه رسمی

بر خلاف پرسشنامه کلمات، این پرسشنامه را نمی توان بدون انطباق برای یک پروژه خاص استفاده کرد. برخی از سوالات او گاهی بی ربط هستند، گاهی نیاز به تغییر در عبارت دارند. در هر صورت، برای پاسخ دهندگان زن، تغییر جنسیت عبارت پرسشنامه ضروری است.

این پرسشنامه از چندین سوال تشکیل شده است که پاسخ دهنده می تواند برای هر یک از پنج پاسخ یکی را انتخاب کند. توجه داشته باشید که این پرسشنامه را صرفاً به صورت پس آزمون طراحی کردم، استفاده از آن در هر ظرفیت دیگری مشکوک است.

سوالات پرسشنامه:

من در طول کارها اشتباه کردم نه/بله

سیستم قادر است تمام کارهایی که من نیاز دارم و حتی بیشتر از آن را انجام دهد خیر/بله سیستم به اندازه کافی سریع است خیر/بله

من ظاهر رابط را دوست دارم نه/بله

من احساس می کنم اگر سیستم را بهتر بشناسم، می توانم کارهایی را در آن انجام دهم که در حال حاضر حتی در مورد آنها نمی دانم نه/بله

سیستم را می توان به راحتی بر اساس نیازهای من سفارشی کرد نه/بله

شروع کار آسان بود. من با مشکلات قابل توجهی مواجه نشده ام نه/بله

هر وقت اشتباه می کردم به راحتی متوجه اشتباهم می شدم و اشتباهم را اصلاح می کردم نه/بله

از سرعت کارم راضی هستم خیر/بله

من در طول کارها کاملاً مطمئن بودم نه/بله

در هر زمان می‌دانستم که بعد از آن چه باید بکنم نه/بله

این سیستم برای من مفید به نظر می رسد، خوشحال می شوم از آن برای حل مشکلاتم استفاده کنم خیر / بله

نتایج باید بر اساس الگوریتم زیر محاسبه شوند: مقدار مرکزی امتیاز صفر می دهد، مقادیر افراطی یا -2 امتیاز (پاسخ چپ) یا +2 امتیاز (پاسخ راست)، مقادیر میانی یا -1 یا + می دهد. به ترتیب 1 امتیاز. امتیاز ارزش مقایسه شده است.

مشاهده واکنش های احساسی

علاوه بر نظرسنجی، می توانید واکنش های احساسی پاسخ دهنده را بشمارید. به عنوان مثال، پاسخ دهنده لبخند زد - یک علامت مثبت گذاشت، فحش داد یا اخم کرد - منفی گذاشت. تعداد و علامت واکنش ها مقدار مورد نظر نشانگر است.

در این روش نیز مشکلاتی وجود دارد.

اول، نحوه شمارش واکنش‌های با قدرت‌های مختلف مشخص نیست. پاسخ دهنده چند بار باید لبخند بزند تا هشت ثانیه فحش دادن را متعادل کند؟ و نه ثانیه سرزنش؟

ثانیاً، یک شخص باید واکنش های همه پاسخ دهندگان را بشمارد، زیرا برای چندین نفر غیرممکن است که ایده های خود را در مورد آنچه در واقع در مفهوم واکنش عاطفی گنجانده شده است، هماهنگ کنند. در نتیجه، شدت منابع آزمون به شدت افزایش می یابد.

اگر کمی در مورد توانایی خود در درک احساسات دیگران مطمئن نیستید (مثلاً اگر Em هستید و نه جو) این آزمون را انجام ندهید.

مشکل دوم عدم قطعیت آزمون است. فقط رضایت عملیاتی، یعنی لذت، مشاهده می شود و رضایت درک شده، تقریباً همیشه مهمتر، در پشت صحنه باقی می ماند.

آنچه برای آزمایش نیاز دارید

اکنون که مسائل اساسی به طور کلی حل شده است، می توانیم به سراغ تمرین برویم. شما باید با لیستی از آنچه باید در یک مکان برای آزمایش قابلیت استفاده جمع آوری کنید شروع کنید (این موارد با جزئیات بیشتر در زیر توضیح داده خواهند شد). پس به چه چیزی نیاز داریم:

• پاسخ دهندگان
• روش آزمون
• سناریوهای تست
• محل کار برای آزمایش و روش ثابت شده برای تعمیر مواد
• تست تست شده

پاسخ دهندگان

هنگام انتخاب پاسخ دهندگان برای آزمایش، ابتدا راحت است که الزامات کلی پاسخ دهندگان را تعیین کنید و تنها پس از آن پاسخ دهندگان را از بین مخاطبان هدف با استفاده از نیازهای ایجاد شده انتخاب کنید.

به خاطر داشته باشید که انتخاب پاسخ دهندگانی که در بین مخاطبان هدف نیستند بسیار خطرناک تر از آن چیزی است که در نگاه اول به نظر می رسد. شما یا مشکلات موجود را شناسایی خواهید کرد یا مشکلات موجود را شناسایی نخواهید کرد. در بدترین حالت، رابط کاربری را به قدری ساده خواهید کرد که استفاده از آن برای کاربران معمولی که در واقع اکثریت هستند، دشوار خواهد بود.

الزامات عمومی برای پاسخ دهندگان

اولین مورد این است که آیا پاسخ دهندگان به تجربه با سیستم نیاز دارند یا خیر. قاعده کلی این است که اگر رابط یک سیستم موجود در حال بهینه سازی باشد، نیمی از پاسخ دهندگان باید تجربه کاری داشته باشند (آنها می توانند مشکلات یادگیری مجدد را در حین اجرا شناسایی کنند)، و نیمی دیگر نباید (نرخ یادگیری را تعیین می کنند). اگر سیستم های رقیب وجود دارد، نسبت دیگری بهتر است: یک سوم با تجربه با نسخه قبلی، یک سوم دیگر با تجربه در استفاده از سیستم های رقیب، یک سوم باقی مانده بدون تجربه با سیستم.

نکته دوم سطح سواد کامپیوتری است. در صورت مساوی بودن سایر موارد، انتخاب ارجح انتخاب واقعی است، یعنی. همزمان با تجربه مخاطب هدف، سطح سه چهارم پاسخ دهندگان و سطح پایین - - برای سه ماهه باقی مانده (می تواند مشکلات بیشتری را شناسایی کند).

سطح سواد رایانه به راحتی با مقیاس زیر تعیین می شود:

1. بالاپاسخ دهنده در محل کار و در خانه یک کامپیوتر دارد، بیشتر کار بر روی کامپیوتر انجام می شود، پاسخ دهنده از کامپیوتر به عنوان وسیله ای برای توسعه خود استفاده می کند، فعالانه از خدمات اینترنتی استفاده می کند (به عنوان مثال، به طور منظم کالاها و خدمات را در فروشگاه های آنلاین خریداری می کند. ).
2. بالاتر از حد متوسط.پاسخ دهنده در محل کار و در خانه یک کامپیوتر دارد، بیشتر کار بر روی کامپیوتر انجام می شود، اما پاسخ دهنده از کامپیوتر برای حل کارهایی که فراتر از فعالیت اصلی او هستند استفاده نمی کند (در کامپیوتر "از تماس تا تماس" کار می کند و بیشتر نه).
3. میانگین.استفاده از کامپیوتر به مدت دو سال یا بیشتر بخشی از فعالیت های عادی (کار یا شخصی) بوده است.
4. کوتاه.چه در محل کار و چه در خانه کامپیوتر وجود دارد، اما تجربه کار با کامپیوتر بیش از دو سال نیست و کامپیوتر ابزار قابل توجهی در کار نیست.
5. خیلی کم.تجربه استفاده از رایانه پراکنده است، مدت زمان آن از سه سال تجاوز نمی کند. کامپیوتر نه در محل کار و نه در خانه استفاده نمی شود.

در رتبه سوم سن است. نسبت بهینه: سه چهارم پاسخ دهندگان در سنین مخاطب هدف سیستم هستند، یک چهارم باقی مانده مسن تر است (مشکلات بیشتری را می توان روی آن شناسایی کرد).

جنسیت پاسخ دهندگان تأثیر کمتری بر نتایج دارد، اما این بدان معنا نیست که لازم نیست پاسخ دهندگان با جنسیت صحیح انتخاب شوند. ارزش افزایش تعداد زنان در میان پاسخ دهندگان را در مقایسه با نسبت مخاطب هدف دارد، زیرا شناسایی مشکلات در حین اجرا بر روی زنان آسان تر است (زنان، به طور کلی، آهسته تر یاد می گیرند، اما با آموختن، بهتر کار می کنند).

آخرین ویژگی مهم سطح باز بودن عاطفی پاسخ دهندگان است. هر چه پاسخ دهنده محدودتر باشد، کمتر می تواند به شما بگوید ارزشمند است. حتی اگر تشخیص دهید که مشکلی وجود دارد، نمی توانید از او اطلاعاتی در مورد علت این مشکل دریافت کنید. یک راه عالی برای حل مشکل باز بودن احساسی ناکافی وجود دارد - ارزش دارد که پایگاهی از پاسخ دهندگان داشته باشید و دوباره از آنها استفاده کنید. پاسخ دهنده ای که قبلاً به تجربه می داند که هیچ مشکلی در آزمایش قابلیت استفاده وجود ندارد، بسیار مایل به برقراری تماس است و به طور کلی پرحرف تر است.

در نهایت، زمانی که ویژگی های کاربران مورد نظر برای آزمون از قبل مشخص شده است، زمان آن فرا می رسد که پاسخ دهندگانی را انتخاب کنید که نه تنها شرایط فوق را برآورده می کنند، بلکه به مخاطبان هدف سیستم نیز تعلق دارند.

به چند پاسخ دهنده نیاز دارید

در سال 1992، رابرت ویرزی در پالایش مرحله آزمایشی ارزیابی قابلیت استفاده: چند موضوع کافی است؟ فرض کرد که پنج پاسخ دهنده برای آزمون کافی بودند. یک سال بعد، یاکوب نیلسن و توماس کی. لاندوئر با مقاله مدل ریاضی یافتن مشکلات کاربردپذیری، رهبری را به دست گرفتند، که در آن استدلال کردند که پنج پاسخ‌دهنده برای 70 درصد مشکلات کافی است و سه پاسخ‌دهنده دیگر مورد نیاز است. به منظور رساندن اثربخشی به 85٪.

جامعه کاربردپذیری این اعداد را با تمام وجود دوست داشتند. از آن زمان، عبارت "5-8 پاسخ دهندگان" تقریباً به یک مانترا تبدیل شده است. افسوس که این مانترا نادرست است.

اول، هر سه نویسنده فقط در مورد آزمایش سیستم های کوچک نوشتند. چه می‌شود اگر سیستم آنقدر بزرگ باشد که تست را برای هر پاسخ‌دهنده در یک ساعت و نیم جای دهد (این حداکثر چیزی است که یک فرد، هم پاسخ‌دهنده و هم آزمایش‌کننده، می‌تواند تحمل کند؛ تست‌های 40 دقیقه‌ای بسیار بهتر است). در این مورد، شما باید چندین تست مختلف را بر روی پاسخ دهندگان مختلف انجام دهید. بدون این، پوشش کل رابط سیستم به سادگی غیرممکن خواهد بود. تعداد پاسخ دهندگان در این مورد به سیستم بستگی دارد، هیچ درجه بندی واضحی در اینجا وجود ندارد. بنابراین، برای تست یک سایت شرکتی بزرگ، به روشی خوب، به بیست نفر در چندین سری 5 نفره نیاز دارید.

ثانیاً، هشت نفر - این برای صحبت در مورد حداقل دقت در اندازه‌گیری ویژگی‌های ارگونومیک بسیار کم است. برای اندازه گیری حداقل به دوازده نفر نیاز دارید.

ثالثاً، هشت نفر نمی توانند جنسیت، سن یا هر تنوع دیگری از پاسخ دهندگان را در خود جای دهند. اگر می خواهید یک رابط طراحی شده برای چندین گروه مخاطب مجزا را آزمایش کنید، هر گروه باید پنج تا هشت پاسخ دهنده خود را داشته باشد.

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

مسائل سازمانی

علاوه بر الزامات واقعی برای پاسخ دهندگان، این سوال باقی می ماند: چگونه یک پاسخ دهنده بالقوه را متقاعد کنیم که در آزمون شرکت کند؟

اگر در حال طراحی یک رابط سفارشی هستید، سعی کنید جستجوی پاسخ دهندگان را به مشتری تغییر دهید. تقریباً همیشه، سیستم دارای کاربران واقعی یا بالقوه ای است که مشتری با آنها رابطه ویژه ای دارد و کسانی که  - که خوب هستند - به خصوص به رابط کاربری جدید علاقه مند هستند، به همین دلیل آنها بسیار اجتماعی هستند.

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

بسیاری از شرکت‌های استخدام برای گروه‌های متمرکز استخدام می‌کنند، بنابراین می‌توانند پاسخ دهندگان را برای تست قابلیت استفاده نیز جذب کنند. متأسفانه، گروه تمرکز رویدادی یکباره و نسبتاً کوتاه است. آزمایش قابلیت استفاده نیاز به زمان‌بندی مصاحبه با پاسخ‌دهندگان به نوبه خود، یک نفر در یک زمان دارد، که این فرآیند را بسیار دشوار می‌کند.

یک پایگاه داده از افرادی که قبلاً برای آزمایش استفاده کرده اید، نگهداری کنید. به عنوان یک قاعده، مذاکره با آنها راحت تر از کسانی است که تجربه شرکت در آزمون را ندارند.

هنگام ترتیب دادن ملاقات با مخاطب، تا حد امکان انعطاف پذیر و سازگار باشید. پاسخ دهنده، حتی اگر وقتش پرداخت شده باشد، با موافقت با شرکت در آزمون، به شما لطف می کند.

اگر پاسخ دهنده را خودتان پیدا کردید، حتی اگر دوست یا خویشاوند شما باشد، باید برای زمانی که صرف کرده است، پاداش دریافت کنید (اگر پاسخ دهندگان توسط مشتری رابط ارائه شده باشند، می توانید بدون پاداش انجام دهید، اما اگر از خدمات خدمات استخدام، پاداش باید با نماینده خدمات مورد بحث قرار گیرد). برای یک مخاطب غیر خاص، بهترین انگیزه پول است - مقدار بهینه پرداخت دو برابر نرخ ساعتی یک مخاطب خاص است، با در نظر گرفتن زمانی که پاسخ دهنده در جاده صرف کرده است. برای یک مخاطب خاص، اغلب به مقادیر بسیار زیادی جوایز نیاز است، در چنین شرایطی معقول است که به پاسخ دهندگان هدایای ارزشمندی بدهید، که برای آن می توانید یک تخفیف عمده فروشی دریافت کنید (من شخصا ترجیح می دهم از الکل گران قیمت استفاده کنم).

روش های امتحان

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

• نظارت غیرفعال وظایف آزمون.ماهیت روش بسیار ساده است: پاسخ دهنده وظایف آزمایشی را انجام می دهد، اقدامات او (طبق پروتکل ها در طول آزمایش یا بعد از آن) تجزیه و تحلیل می شود، که هم امکان یافتن قطعات مشکل ساز و هم اندازه گیری ویژگی های ارگونومیک رابط را فراهم می کند.
• جریان آگاهی (با صدای بلند فکر کنید).مربوط به یک آزمون مشاهده غیرفعال است، اما از پاسخ دهنده نیز خواسته می شود که به صورت شفاهی در مورد اعمال خود اظهار نظر کند. سپس نظرات مورد تجزیه و تحلیل قرار می گیرند. این روش نسبتاً ناپایدار است، اما گاهی اوقات نتایج جالبی می دهد (تا حد زیادی به پرحرفی پاسخ دهنده بستگی دارد). منهای اصلی جریان آگاهی  - اندازه گیری ویژگی های ارگونومیک رابط بسیار مشکوک است.
• مداخله فعالدر این روش، متخصص کاربردپذیری در شخص پاسخ دهنده از طبیعت انتظار لطفی ندارد، بلکه سعی می کند خودش آنها را بگیرد. پس از هر اقدام پاسخ دهنده، آزمايشگر از او مي پرسد كه چرا پاسخ دهنده به اين صورت عمل مي كند. در هر صفحه، آزمایشگر می پرسد که پاسخ دهنده دقیقاً چگونه هدف و عملکرد این صفحه را درک می کند. این روش به یک مصاحبه متمرکز بیشتر از آزمایش واقعی نزدیک است. واضح است که با مداخله فعال، هیچ اندازه گیری به سادگی امکان پذیر نیست، اما میزان داده های کیفی به دست آمده بیشترین مقدار است.

سناریوهای تست

یک مورد آزمایشی  -  جنبه قابل آزمایش سیستم است. به نظر من سناریوهای تست انتخاب شده به اندازه کافی مهم ترین پیش نیاز برای تست کیفیت هستند.

سناریوها شامل یک کار سفارشی و همراهان آن است:

• معیارهای ارگونومیک قابل توجه
• وظایف آزمون برای پاسخ دهندگان (ممکن است چندین کار وجود داشته باشد)
• نشانه های موفقیت آمیز انجام کار

بیایید آنها را با جزئیات تجزیه و تحلیل کنیم.

کار سفارشی

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

وظیفه سفارشی چیست؟ این وظیفه ای است که فعالیت های آنها برای کاربران ایجاد می کند و برای کاربران ارزش مستقلی دارد. یک کار سفارشی به عنوان یک یا چند عملیات اجرا می شود (یک عملیات سفارشی ارزش مستقلی ندارد). به عنوان مثال، برای یک برنامه سرویس گیرنده ایمیل، وظایف عبارتند از:

• نوشتن و ارسال نامه
• دریافت پیام از سرور
• سفارشی کردن برنامه مطابق با نیازهای شما (به عنوان مثال، تنظیم دریافت خودکار نامه در فواصل زمانی مشخص).

اما انتخاب مخاطب از دفترچه آدرس هنگام نوشتن نامه جدید دیگر کار نیست، زیرا این عمل به خودی خود ارزشی ندارد. این یک عملیات متشکل از اقدامات زیادی است (روی دکمه To... کلیک کنید > یک مخاطب را انتخاب کنید > انتخاب را تأیید کنید).

هنگام انتخاب وظایف برای تست، دو نکته باید در نظر گرفته شود:

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

معیارهای کار ارگونومیک قابل توجه

برای هر کار، باید ویژگی های رابط را انتخاب کنید که برای آن مهم است. البته، ما معیارهایی را از بخش "دقیقاً چه چیزی باید اندازه گیری کنیم" در اختیار داریم. با این حال، این معیارها ناخوشایند هستند: اندازه گیری آنها دشوار و درک آنها دشوار است (اگرچه مقایسه آنها آسان تر است). از نقطه نظر عملی، ویژگی های پیش پا افتاده تر بسیار راحت تر است.

برای مثال می توانید تعداد خطاهای انسانی را بشمارید. اما تأثیر این معیار بر نتیجه انتگرال آنقدر پیچیده است که با این حال، تحلیل بدون عناصر اراده گرایی و ذهنیت گرایی نمی تواند انجام شود. تعیین تأثیر همان خطاها بلافاصله حتی قبل از آزمایش بسیار ساده تر است، به عنوان مثال، با تنظیم یک مشخصه رابط قابل توجه "کاربر می تواند برنامه را در کمتر از پنج دقیقه نصب کند، در حالی که بیش از دو مورد جزئی نیست. خطاها» (که در آن خطای جزئی به معنای خطایی است که خود کاربر متوجه آن شده و آن را تصحیح کرده است). البته خودسری در چنین الزامی بسیار است. اما هنوز کمتر از حدس و گمان های مشکوک در مورد تعداد خطاهای انسانی شناسایی شده است. بنابراین، معیارهای "دنیوی" راحت تر از معیارهای جهانی هستند.

علاوه بر این، معیارهای ساده اعلامی نیز راحت هستند زیرا به شما این امکان را می دهند که بفهمید چه زمانی باید به بهینه سازی رابط ادامه دهید و چه زمانی می توانید متوقف شوید. با بازگشت به مثال پاراگراف قبل، می توان گفت که باید رابط را تا زمانی که نصب کمتر از پنج دقیقه طول بکشد، بهینه سازی کنیم. اگر پس از بهینه سازی رابط، برنامه در شش دقیقه نصب می شود، دلیلی است برای تغییر مجدد رابط و تست مجدد آن.

در اینجا نمونه هایی از این معیارها آورده شده است:

• موفقیت   - پاسخ دهندگان 90 درصد وظایف را به درستی انجام می دهند.
• کارایی - سرعت تجربه کاربری: ثبت نام در سایت در کمتر از 7 دقیقه تکمیل می شود.
• کارایی  - خطا: هنگام وارد کردن 10 فرم، تعداد خطاهای ورودی از 2 بیشتر نمی شود.
• کارایی--توانایی یادگیری نحوه کار با سیستم: هنگام انجام وظیفه 9 که تنها در داده های ورودی با کار 2 متفاوت است، پاسخ دهندگان یک اشتباه هم مرتکب نمی شوند (به جز اشتباهات تایپی).
• رضایت - طبق نتایج نظرسنجی، تعداد امتیازات نسبت به نتایج قبلی 20 درصد افزایش یافته است.

وظایف تست

یک کار آزمایشی چیزی است که پاسخ دهنده از شما دریافت می کند، وظیفه ای که به شما امکان می دهد پاسخ دهنده را از طریق بخشی از رابط سیستم هدایت کنید و ویژگی های این قطعه را تعیین کنید.

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

• عدم ابهاموظایف باید به گونه ای تنظیم شوند که تفسیر نادرست آنها توسط پاسخ دهنده حذف شود. اگر پاسخ‌دهنده تکلیف را اشتباه متوجه شود، تقریباً مطمئناً نمی‌توانید او را در مسیر درست قرار دهید بدون اینکه همزمان ترتیب کار را به او گوشزد کنید.
• کامل بودن.متن کار باید حاوی تمام اطلاعات لازم برای تکمیل این کار باشد.
• اختصار.اگر سرعت کارها را اندازه‌گیری می‌کنید، کارها باید به اندازه‌ای کوتاه باشند که مدت زمانی که پاسخ‌دهندگان تکالیف را می‌خوانند تأثیری بر طول مدت کارها نداشته باشد (افراد با سرعت‌های متفاوتی می‌خوانند). اگر حجم متن کار زیاد باشد، باید مدت زمان خواندن هر کار را به صورت دستی قطع کنید که بسیار پر زحمت است.
• فقدان نکات.با توجه به متن تکلیف نباید مشخص شود که این وظیفه چگونه باید انجام شود. به عنوان مثال، استفاده از اصطلاحات سیستم  -  به جای هر اصطلاح غیرقابل قبول است، لازم است معنای آن را توضیح دهید، در غیر این صورت پاسخ دهندگان به سادگی روی دکمه های همان کلمات کلیک می کنند و هیچ مشکلی را شناسایی نمی کنید.
• تکلیف باید شامل باشد نقطه شروع کار، یعنی پنجره یا صفحه ای که پاسخ دهنده باید در ابتدا روی آن باشد باید نوشته شود. اگر چنین اطلاعاتی ارائه نشود، پاسخ‌دهندگان ناگزیر به بخش‌های دیگر رابط می‌روند، به این معنی که کار توسط پاسخ‌دهندگان مختلف به‌طور متفاوتی انجام می‌شود، که همه محاسبات آماری را بی‌معنا می‌کند. شما باید نقطه شروع کار را در پایان کار قبلی ثابت کنید. اگر کار با یک صفحه خالی شروع می شود، در پایان کار قبلی باید بگوید "بازگشت به صفحه اصلی". اگر قرار است کاری از جایی شروع شود که کار قبلی به پایان رسیده است، کار قبلی باید با عبارت "وقتی تمام شد، پنجره فعلی را نبندید/در این صفحه بمانید" پایان یابد.

علاوه بر این الزامات عمومی، موارد زیر نیز باید در نظر گرفته شود:

• این امکان وجود دارد که چندین کار آزمایشی برای یک کار کاربر نوشته شود. مورد معمولی - وظیفه خیلی بزرگ است که در یک کار جای بگیرد. همچنین، اگر یک کار کاربر مکرر است، نباید زیاد به نحوه انجام آن در بار اول اهمیت دهید - بسیار جالب‌تر است بدانید که کاربران چگونه این کار را بار دوم، سوم، چهارم (و غیره) انجام خواهند داد. . در این مورد، در آزمون روی یک پاسخ دهنده، این کار باید چندین بار اجرا شود و هر بار وظایف متفاوت باشد.
• علاوه بر وظایفی که پاسخ دهنده باید در آنها عملی انجام دهد، وظایف دوگانه قابل قبول و مطلوب است که در آن ها پاسخ دهنده باید ابتدا تصمیم بگیرد که آیا نیاز به انجام این عمل در یک زمان معین دارد یا خیر.به عنوان مثال، اگر در حال تست یکپارچه سازی دیسک هستیم، به جای وظیفه "Defragment the computer disk"، بهتر است از کار "بررسی میزان قطعه قطعه شدن دیسک و در صورت لزوم، دیسک کامپیوتر را یکپارچه سازی کنید" استفاده کنید. چنین وظایفی باید به گونه ای طراحی شوند که پاسخ دهنده نتواند بدون نگاه کردن از تصمیم گیری خودداری کند و بگوید که آنها می گویند همه چیز خوب است و نیازی به یکپارچه سازی نیست. همچنین، قبل از چنین آزمایشی، منطقی است که دیسک را عمداً تکه تکه کنیم تا پاسخ دهنده نتواند از انجام وظیفه اجتناب کند.
• گاهی اوقات در طول یک کار، شما باید به زور وضعیت سیستم را تغییر دهید. به عنوان مثال، اگر می خواهید بدانید که کاربران چگونه یک مشکل خاص را حل می کنند، باید آن مشکل را ایجاد کنید. قطع کردن آزمون برای این کار غیرقابل قبول است، زیرا این امر باعث حواس پرتی پاسخ دهنده می شود. در چنین مواردی می توان یک کار دیگر را قبل از آیتم مربوطه درج کرد که در آن پاسخ دهنده باید به تنهایی مشکل را ایجاد کند. البته چنین کاری هیچ اطلاعاتی در مورد رابط ارائه نمی دهد.
• تجزیه و تحلیل نتایج و جمع‌بندی آمار بسیار ساده‌تر می‌شود اگر تعداد کمی کار طولانی را انجام ندهید، بلکه تعداد زیادی کار کوتاه را انجام دهید که نیاز به جابجایی تنها چند صفحه یا پر کردن یک یا دو فرم دارد.
• اولین وظیفه آزمون باید مقدماتی باشد و صرفاً برای معرفی پاسخ دهنده به فرآیند طراحی شده باشد. بر این اساس، باید ساده باشد و می توان نتایج آن را نادیده گرفت.

حتما بررسی کنید که سناریوهای شما می توانند توسط پاسخ دهندگان در زمان آزمون مورد انتظار تکمیل شوند. احتمالاً فهرست سناریوها باید کاهش یابد.

نشانه های انجام موفقیت آمیز یک کار

آخرین مؤلفه سناریو نشانه هایی از انجام موفقیت آمیز وظایف است. نکته اینجاست: همیشه نمی توان یک کار را به تنها روش انجام داد. اجرای آزمون بدون دانستن همه این روش ها نادرست است، زیرا تجزیه و تحلیل بیشتر مشکوک خواهد بود. فرض کنید پاسخ دهنده A کار را به روش A و پاسخ دهنده B به روش B انجام داده است. از این گذشته، به نظر می رسد که روش های مختلف کارایی متفاوتی دارند، به عنوان مثال، تعداد اقداماتی که در روش B گنجانده شده است، یک و نیم برابر بیشتر از تعداد اقدامات روش A است. روش A در این شرایط، در یک سیستم ایده آل ارجح است. (که باید برای آن تلاش کنید) همه کاربران فقط باید از آن استفاده کنند.

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

محل کار و راه های اصلاح داده ها

دو رویکرد برای سازماندهی یک محل کار برای آزمایش قابلیت استفاده وجود دارد: یک محل کار ثابت و یک محل کار سیار. فقط توصیه‌های مربوط به فضاهای کاری سیار در اینجا ارائه می‌شود، زیرا آزمایشگاه‌های سیار خود ارزان‌تر هستند و پاداش کمتری را برای پاسخ‌دهندگان در نظر می‌گیرند (البته به قیمت وقت متخصص قابلیت استفاده، که باید خودش به پاسخ‌دهندگان سفر کند).

بنابراین، آنچه شما باید برای آزمایش کامل داشته باشید:

1. نوت بوک.الزامات یک لپ تاپ ساده است. اول، قدرتمندترین پردازنده ممکن برای ضبط همزمان صفحه نمایش (اگرچه حتی ضعیف ترین پردازنده های Centrino اینتل به شما امکان می دهند یک جریان ویدیویی را در پس زمینه ضبط کنید، رابط مورد آزمایش روی پردازنده های قدرتمندتر سریعتر کار می کند و کیفیت ویدیو بالاتر خواهد بود) . ثانیاً، اگر می‌خواهید با خود مخاطب ویدیویی ضبط کنید (به پایین مراجعه کنید)، به صفحه نمایش بزرگ‌تری نیاز دارید تا هم رابط آزمایش‌شده و هم پنجره را با چهره مخاطب هماهنگ کند.

2. وبکماگر می خواهید حالات چهره و جهت نگاه مخاطب را ضبط کنید. به عنوان یک قاعده، هرچه دوربین گرانتر باشد، کیفیت تصویر بهتری ارائه می دهد. دوربینی با پایه صفحه نمایش لپ تاپ مطلوب است، زیرا استفاده از آن راحت تر است.

3. میکروفون.اساساً هر کسی انجام خواهد داد. من شخصا از یک میکروفون Genius معمولی استفاده می کنم که هفتاد روبل قیمت دارد. اگر وب‌کم شما میکروفون داخلی دارد، این نیز خوب است. از طرف دیگر، یک میکروفون بهتر کیفیت ضبط بهتری را ارائه می دهد، بنابراین صدای خش خش کمتری خواهد داشت (اما در هیچ چیزی اختلال ایجاد نمی کند).

4. ضبط کننده صفحه.استاندارد واقعی TechSmith Camtasia است، اما اگر بودجه اجازه می دهد، روی TechSmith Morae سرمایه گذاری کنید، که به طور خاص برای آزمایش قابلیت استفاده طراحی شده است (این نه تنها محتویات صفحه را ثبت می کند، بلکه اقدامات کاربر را نیز ثبت می کند، که می تواند تجزیه و تحلیل بعدی را تا حد زیادی سرعت بخشد. از سوی دیگر، Morae در چهار برابر گران تر از Camtasia، که در حال حاضر گران است).

قبل از اولین آزمایش، تا حد امکان با تجهیزات خود آشنا شوید. نحوه قرارگیری دوربین و میکروفون خود را برای بهترین نتایج بررسی کنید. کلیدهای داغ برنامه ضبط صفحه را بیاموزید، یاد بگیرید چگونه به سرعت آن را در هر حالتی راه اندازی کنید. هیچ چیز به اندازه دیدن آزمایشگر شلوغی که در آخرین لحظه قبل از آزمون تلاش می کند تا ضبط را درست انجام دهد، اعتماد پاسخ دهنده به آزمایش را تضعیف نمی کند.

5. اگر قرار است مدت زمان کارها را ثبت کنید مفید است که داشته باشید کرونومتر ورزشیبا ضبط دایره ها (Laps)، که به شما امکان می دهد یک سری فواصل را به خاطر بسپارید. در غیر این صورت برای محاسبه مدت زمان انجام کارها باید دوباره فیلم ها را تماشا کنید که بسیار خسته کننده است.

6. وظایف تستبرای ارائه به پاسخ دهندگان. به عنوان یک قاعده، بهترین گزینه این است که هر کار را در یک برگه جداگانه چاپ کنید تا پاسخ دهنده نتواند پیش برود و کارهایی را که هنوز انجام نداده است بخواند. در اولین برگه باید نمایش داده شود فرم مقدماتینمونه ای از چنین فرمی (در پرانتز  - داده های متغیر):

عزیز [نام پاسخ دهنده]،

ما از شما دعوت می کنیم تا یک سری از وظایف طراحی شده برای ارزیابی سادگی و سهولت استفاده از [Name of the system] را انجام دهید. با خیال راحت وظایف را کامل کنید. هدف از مطالعه ارزیابی کیفیت رابط مورد مطالعه است و نه شخص شما. اگر کار اشتباهی انجام دهید به این معنی است که رابط و فقط رابط نیاز به بهبود دارد.

هنگام انجام وظایف، باید آنطور که صلاح می دانید عمل کنید. برای مثال، اگر استفاده از Help را انتخاب کردید، می‌توانید بدون درخواست اجازه از آزمایشگر این کار را انجام دهید.

لطفاً توجه داشته باشید که اقدامات و سخنان شما برای مطالعه بیشتر ثبت می شود، اما تمام داده های جمع آوری شده کاملاً محرمانه باقی می ماند و فقط در دسترس محققان خواهد بود.

تکلیف را با دقت بخوانید و دستورالعمل های موجود در آن را دقیقاً دنبال کنید.

سعی کنید هر کار را تا آخر انجام دهید، اما اگر در حین انجام کار متوجه شدید که نمی توانید یا نمی خواهید آن را انجام دهید، آزمایشگر را در این مورد مطلع کنید و به سراغ کار بعدی بروید.

لطفاً فقط زمانی که کار را در صفحه باز انجام دادید، صفحه را با کار ورق بزنید.

اگر وظیفه ای را متوجه نشدید، دوباره از آزمایش کننده بپرسید.

از سوی دیگر، در برخی موارد بسیار کارآمدتر است که تکالیف پاسخ دهندگان را نه روی کاغذ، بلکه به گونه ای که به واقعیت نزدیکتر باشد، صادر کنیم. به عنوان مثال، هنگام آزمایش یک رابط POS، بهتر است وانمود کنید که یک مشتری هستید و مشتریان به ندرت نیازهای خود را به صورت مکتوب بیان می کنند.

7. اگر قصد دارید از کاربران نظرسنجی کنید، نیاز خواهید داشت فرم های چاپی

8. اگر قرار است نزدیک مخاطب باشید و هر پارامتری را فوراً اصلاح کنید، نیاز خواهید داشت تبلت با کاغذ و خودکار.به راحتی می توانید چندین برگه را با نام پاسخ دهنده و شماره صفحه از قبل چاپ کنید - اگر چندین آزمایش را پشت سر هم انجام می دهید، تضمین می شود که از عذاب کاغذهای به هم ریخته جلوگیری کنید.

همانطور که می بینید، چیز زیادی مورد نیاز نیست. هزینه تجهیزات و نرم افزارهای لازم (بدون احتساب لپ تاپ، در قرن بیست و یکم لوکس نیست) در نسخه اقتصادی آن بیش از 450 دلار نیست. مزایای چنین راه حلی قابلیت اطمینان و سهولت کار است. علاوه بر این، تحرک امکان آزمایش با خود پاسخ دهندگان را فراهم می کند، که به طور قابل توجهی تعداد آنها را افزایش می دهد (بسیاری از پاسخ دهندگان بالقوه تحت هیچ شرایطی به دفتر متخصص قابلیت استفاده نمی روند).

ثبت حالات چهره پاسخ دهندگان

اگر قرار است نتایج را بعد از آزمون (و نه در طول آن) تجزیه و تحلیل کنید، ضبط ویدیویی از حالات چهره و حرکات پاسخ دهندگان بسیار مفید خواهد بود. بدون ویدئو با پاسخ دهنده، باید حرکات مکان نما را تجزیه و تحلیل کنید (همراه، زیرا صدا نیز ضبط می شود، با خش خش و جیغ). با ضبط، تجزیه و تحلیل تعامل یک فرد با رابط امکان پذیر خواهد بود، زیرا پیش نیازهای گشتالت ظاهر می شود. یک تفاوت عینی ناچیز در روش به بهبود قابل توجهی در نتایج منجر خواهد شد.

مشکل این است که ضبط یک ویدیو با خود مخاطب با دشواری خاصی همراه است -  شما باید به طور خودکار چهره مخاطب و ضبط اعمال او را همگام کنید.

میکروفون را نزدیک پرینت های آزمایشی قرار ندهید. هنگام تماشای ویدیو ناشنوا شوید.

در یک آزمایشگاه قابل استفاده ثابت، این امر با ترکیب سخت افزاری ویدیو از دوربین با جریان ویدیویی از کارت ویدیوی رایانه به دست می آید. اشکالات عمده این راه حل هزینه بالا و کیفیت پایین تصویر صفحه نمایش ضبط شده است (تعداد پیکسل های روی صفحه چندین برابر بیشتر از آن چیزی است که می توان روی یک ضبط صوت ضبط کرد). علاوه بر این، کار با چنین سوابقی ناخوشایند است.

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

پیش از این، تنها یک راه حل گنگ، هرچند قابل اجرا، در دسترس بود (روش جدید و بهتر در زیر توضیح داده شده است). قبل از تست:

1. غیرفعال کردن شتاب گرافیک در ویندوز (در تابلوهای کنترلانتخاب کنید صفحه نمایش، روی زبانه مولفه هایدکمه را فشار دهید علاوه بر این، در پنجره باز شده در برگه تشخیصنوار لغزنده را حرکت دهید شتاب سخت افزاریبه سمت چپ). پس از تست، شتاب را می توان دوباره فعال کرد.
2. هر برنامه‌ای را اجرا کنید که می‌تواند ویدیوهای دریافتی از دوربین را نمایش دهد. چنین برنامه هایی به وب کم متصل می شوند، علاوه بر این، برنامه های چت تصویری مناسب هستند.
3. پنجره ای را با تصویری که از دوربین می آید روی لبه سمت راست پایین صفحه تنظیم کنید (در آنجا کمتر از همه حواس مخاطب را پرت می کند)، و پنجره سیستم مورد آزمایش را طوری قرار دهید که تصاویر را مبهم نکند. پنجره حاوی ویدئو باید با یک تکه کاغذ مهر و موم شود (با تشکر از دیمیتری ساتین برای ایده).
4. از پاسخ دهنده بخواهید اندازه پنجره سیستم تحت آزمایش را تغییر ندهد.
5. تمام ضبط صفحه را روشن کنید.

به همین دلیل، در طول آزمایش، کل محتوای صفحه، از جمله اقدامات پاسخ دهنده و تصویر او از دوربین، ضبط می شود.

نمایش صفحه هنگام ضبط حالات چهره به این روش.

اضافه: نسخه سوم استودیو TechSmith Camtasia حالت تصویر در تصویر را معرفی کرد (یک جریان از دوربین فیلمبرداری با محتوای صفحه در گوشه فیلمبرداری قرار می گیرد)، بنابراین اکنون همه چیز بسیار ساده تر شده است.

تنها مشکل ضبط حالات چهره پاسخ دهنده این است که اگر خودتان به سراغ پاسخ دهندگان بروید، هیچ کس نمی تواند تضمین کند که چیزهای ناخوشایندی در پس زمینه ویدیو وجود نخواهد داشت - پاسخ دهندگان اغلب دوست دارند فقط در مورد ساس ها با متخصصان قابلیت استفاده ملاقات کنند.

تست تست شده

در نهایت، باید خود آزمون را تایید کنیم. شما باید مطمئن شوید که:

1. تجهیزات عملیاتی است
2. شما می دانید که چگونه با او مانند یک نیمه خدای جوان رفتار کنید
3. تمام تنظیمات پیش فرض درست است
4. نوارهای خالی یا فضای دیسک کافی دارید
5. تمام مقالات لازم چاپ شده و از نظر ارتباط و خطا بررسی می شوند
6. وظایف آزمون شامل تمام اطلاعات لازم است و نیازی به توضیح اضافی ندارد
7. هیچ سرنخ پنهانی در کارهای آزمایشی وجود ندارد
8. می توانید به سرعت سیستم مورد آزمایش را به حالت اولیه خود برسانید تا پاسخ دهندگان بعدی تغییرات ایجاد شده توسط شرکت کنندگان قبلی را نبینند.
9. ایده شما در مورد اینکه چه چیزی انجام وظیفه صحیح را تشکیل می دهد درست است
10. آزمون روی یک پاسخ دهنده می تواند در زمان معقول (حداکثر یک ساعت و نیم) انجام شود.

همانطور که می بینید، نقاط زیادی وجود دارد که در آنها می توان اشتباهات را مرتکب شد که بررسی آنها به خودی خود به منبع خطا تبدیل می شود (کارهای دشوار به هیچ وجه بدون خطا انجام نمی شوند). بر این اساس، یک روش تأیید قابل اعتماد مورد نیاز است. این روش خود آزمون را آزمایش می کند، یعنی. آزمایش را روی کسی که برایش متاسف نیستید و به راحتی می توانید آن را بگیرید (مثلاً یک همکار). اگر اجرای آزمایشی حداقل یک خطا در آماده سازی آزمون نشان داد، آن را تصحیح کرده و دوباره اجرا را تکرار کنید.

البته توجه داشته باشید که اجرای آزمایشی جایگزین نیاز به آزمایش خودتان نمی‌شود، زیرا برخی از جنبه‌ها را نمی‌توان با اجرای آزمایشی آزمایش کرد.

آزمایش کردن

بنابراین، آزمون آماده است و می توانید ادامه دهید. روش کار ساده است. روشن کردن ضبط و نشستن مخاطب در رایانه:

1. پاسخ دهنده را در کار وارد کنید
2. از او انتظاراتش از سیستم را دریابید
3. رابط را تست کنید
4. دریابید که چگونه انتظارات پاسخ دهنده برآورده شده است
5. تست را کامل کنید

این مراحل در زیر به تفصیل شرح داده شده است.

مقدمه ای بر مسئله

معرفی پاسخ دهنده به کار در این واقعیت است که شما به طور مداوم قوانین آزمایش را برای او توضیح می دهید. همه این توضیحات بسیار مهم هستند، اگر حتی یک نکته را از دست بدهید، نتایج مخدوش می شود.

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

لیستی از چیزهایی را که باید قبل از آزمایش بگویید حفظ کنید. این نیز بر نتایج تأثیر می گذارد.

شناسایی انتظارات از سیستم

صرف نظر از نوع و هدف آزمایش، هنگام آزمایش یک رابط جدید، تعیین اینکه چقدر انتظارات کاربر را برآورده می کند مفید است. اگر انتظارات برآورده شود، اجرا و حمایت اولیه تا حد زیادی تسهیل خواهد شد. اگر انتظارات فریب خورده باشد، سیستم بلافاصله باعث رد می شود.

استخراج انتظارات معمولاً باید قبل از طراحی رابط انجام شود، اما متأسفانه در مراحل اولیه توسعه بسیار دشوار است و علاوه بر این، به استعداد فوق العاده ای برای گوش دادن و پرسیدن سؤالات مناسب نیاز دارد. با این حال، در مراحلی که از قبل چیزی برای آزمایش وجود دارد، مانند آزمایش نمونه های اولیه، شناسایی انتظارات کاربر آسان تر است، بنابراین احمقانه است که از این فرصت استفاده نکنید.

فرآیند شناسایی انتظارات شامل دو مرحله است:

1. قبل از انجام آزمون باید از پاسخگو پرسید که از سیستم چه انتظاری دارد. شما باید با نگاهی دقیق به صحبت های پاسخ دهنده گوش دهید و همه چیزهایی که او می گوید را می توان با خیال راحت فراموش کرد، زیرا تمام کلمات او خیالی بیش نیست. شما باید بپرسید نه برای اینکه چیزی را بفهمید، بلکه برای اینکه پاسخ دهنده را برای مرحله دوم آماده کنید.
2. پس از آزمون، از پاسخ دهنده باید پرسید که رابط نشان داده شده چگونه انتظارات او را برآورده می کند. در اینجا می توان از قبل به پاسخ دهنده اعتماد کرد: اولاً، او با پاسخ های قبلی خود آماده شده است، و ثانیاً، رابطی که به او نشان داده شده است ممکن است او را وادار کند تا الزاماتی را تنظیم کند که قبلاً از آنها آگاه نبوده است.

آزمایش کردن

هنگام آزمایش، شش "هرگز" زیر باید رعایت شود:

• هرگز بابت نقص سیستم مورد آزمایش عذرخواهی نکنید.
• هرگز نگویید "بعداً آن را درست می کنیم".
• کسی را به خاطر بد بودن رابط سرزنش نکنید ("البته توسعه دهندگان احمق هستند و چیز ناخوشایندی ایجاد کردند، اما ما همین الان آن را برطرف خواهیم کرد").
• هرگز فرآیند تست را "تست کاربر" صدا نکنید - پاسخ دهنده فکر می کند که آن را آزمایش می کند و می ترسد. اگر همیشه به این روش به عنوان "تست قابلیت استفاده رابط" یا به سادگی "تست رابط" اشاره کنید، ایده آل است.
• هرگز حرف مخاطب را قطع نکنید. حتی اگر چیزی نامربوط می گوید، اجازه دهید کامل صحبت کند و فقط بعد از آن سؤالات خود را بپرسید.
• هرگز رفتار پاسخ دهنده را شکل ندهید. برخی از افراد با انتظارات آزمایشگر سازگار می شوند، به عنوان مثال، اگر احساس کنند که می خواهید خطاهای بیشتری در رابط پیدا کنید، دائماً خودشان اشتباه می کنند، حتی اگر رابط پیش نیاز این کار را نداشته باشد. برای جلوگیری از این نتیجه، تمام کلمات شما باید به طور تاکیدی خنثی باشد. دو روش ساده برای دستیابی به بی طرفی وجود دارد. اول اینکه با یک جواب سوال نپرسید. به جای اینکه از پاسخ دهنده بپرسید که سیستم چقدر ساده به نظر می رسد (این بدیهی است که یک سوال اصلی است، زیرا می توان با نگرش متفاوت به موضوع به طور متفاوت پرسید - "سیستم چقدر به نظر شما پیچیده است؟")، بهتر است. برای پرسیدن اینکه آیا سیستم رابط کاربری ساده یا پیچیده ای دارد. ثانیاً، اغلب پاسخ دهندگان خودشان از شما سؤال می پرسند و سعی می کنند از تصمیم گیری خود اجتناب کنند. پاسخ به چنین سوالاتی آسان است، فقط پاسخ ها به دلیل خودجوش بودن، تلقین کننده خواهد بود. در چنین مواردی بهترین پاسخ یک سوال متقابل است. آیا حالم خوب است؟ -شما چی فکر میکنید؟ آیا کار را به درستی انجام دادم؟ -شما چی فکر میکنید؟ و به همین ترتیب، تا زمانی که پاسخ دهنده آرام بگیرد. بی ادب، اما موثر.

علاوه بر این، چند قانون نه چندان طبقه بندی وجود دارد:

• اگر یک ویژگی رابط را در طول آزمایش، مانند شمارش خطاهای پاسخ‌دهنده، نظارت می‌کنید، نباید بیش از یک متریک را نظارت کنید. به عنوان مثال، اگر خطاها را بشمارید، ارزش شمارش زمان اجرا را ندارد - احتمال خطای خود شما بیش از حد افزایش می یابد. به نظر من، در طول آزمایش، شما فقط می توانید فرضیه های خود را در مورد بهبودهای بالقوه در رابط بنویسید - i.e. چیزی که بلافاصله می بینید بهتر است شاخص های رابط را از ضبط های ویدئویی محاسبه کنید.
• حتی با مداخله فعال، سعی کنید از پاسخگو سوالاتی نپرسید که مستقیماً با عملکرد فعلی آنها مرتبط نیست. بهتر است بعد از آزمایش از آنها بپرسید.
• در صورت امکان، سمت راست پشت سر مخاطب بنشینید تا بتواند صورت شما را با سرش کمی برگردانده ببیند. حضور شما برای مخاطب سنگین است، اما در این موقعیت او حداقل تنش کمتری خواهد داشت.
• در طول آزمایش، اغلب نمی توانید مشکلاتی را در کل رابط مشاهده کنید. به عنوان مثال، متوجه یک خطای کاربر می شوید. اما چه چیزی آن را توضیح می دهد؟ آیا این ناهنجاری ناشی از آمادگی کمتر کاربر نسبت به بقیه است؟ آیا مطمئن هستید که همه این اشتباه را تکرار می کنند؟ به همین دلیل، باید حداکثر مشاهدات را ثبت کنید. برخی از آنها را بعداً کنار خواهید گذاشت، اما این بهتر از از دست دادن مشکل است.

• سرعت کار.بین کارها، کرونومتر را به یک دایره جدید منتقل کنید. اگر به هر دلیلی حواس مخاطب پرت شد، کرونومتر را مکث کنید.
• اشتباهات.روی یک ورق کاغذ، برای هر خطای انسانی یک خط تیره قرار دهید. قرار دادن خط تیره های کوچک برای خطاهای کوچک و خطوط طولانی برای خطاهای بزرگ راحت است. بعد از تست کافی است تعداد داش ها را بشمارید. اگر خطاهای انواع مختلف را جداگانه می شمارید (مثلاً خطاهای ساده و موارد انتخاب نادرست منو به طور جداگانه)، بهتر است از کدهای مختلف استفاده کنید، مثلاً برای خطاهای ساده از خط تیره یکسان و برای خطاهای مربوط به منو از حروف M استفاده کنید.
• مشکلاتی که بلافاصله می بینید.به طور خلاصه روی یک تکه کاغذ اصل مسئله و زمان فعلی را یادداشت کنید (اول زمان!). اگر دقیقاً بدانید که مشکل چه زمانی رخ داده است، پیدا کردن کلیپ ویدیویی مربوطه برای شما آسانتر خواهد بود.
• واکنش های عاطفی پاسخ دهنده.برای واکنش های مثبت علامت مثبت و برای واکنش های منفی علامت منفی قرار دهید. واکنش هایی که در لحظه تکمیل وظایف آزمون رخ می دهد در نظر گرفته نمی شود.

اتمام آزمون

پس از اتمام آزمون:

• از پاسخ دهنده سوال بپرسید.
• اگر در حال انجام یک نظرسنجی هستید، از پاسخ دهنده بخواهید که پرسشنامه ها را تکمیل کند.
• از پاسخ دهنده بپرسید که آیا رابط کاربری را دوست دارد یا خیر. صرف نظر از پاسخ، در مورد اینکه دقیقا چه چیزی را دوست داشتید و چه چیزی را دوست نداشتید، توضیح بخواهید.
• به پاسخگو پرداخت کنید.
• از او برای شرکت در آزمون تشکر کنید. به پاسخ دهنده اطمینان دهید که کار بسیار خوبی انجام داده است و به لطف آنها توانسته اید بسیاری از مشکلات رابط را شناسایی کنید (این کار را انجام دهید حتی اگر پاسخ دهنده یک نوع گوشه گیر و ناخوشایند باشد که چیز جدیدی را در آزمون فاش نکرده است).
• اگر پاسخ دهنده به خصوص خوب است، از او بپرسید که آیا می توان در آینده برای کارهای تست جدید با او تماس گرفت. پاسخ دهنده ای با تجربه آزمایشی همیشه بهتر از پاسخ دهنده ای است که تجربه ندارد.

آزمایش نمونه اولیه

باید توجه ویژه ای به آزمایش روی نمونه های اولیه شود. هنگام آزمایش بر روی نمونه های اولیه، دو گزینه دارید:

• شما می توانید خود را به یک آزمون مداخله فعال محدود کنید، بدون اینکه فرصتی برای به دست آوردن داده های کمی داشته باشید. برای انجام این کار، به هیچ نمونه اولیه خاصی نیاز ندارید، زیرا همیشه این فرصت را دارید که معنای اطلاعات خدمات و دلایل شکاف در نمونه اولیه را برای پاسخ دهنده توضیح دهید.
• علاوه بر موارد معمول، می توانید یک نمونه آزمایشی ایجاد کنید و برخی از داده های کمی را بدست آورید و منابع زیادی را که برای نمونه آزمایشی صرف می شود از دست بدهید.

نمونه آزمایشی نوعی از نمونه اولیه است که در آن پاسخ دهنده می تواند وظایف آزمایشی را انجام دهد. به عنوان مثال، اگر نمونه اولیه متشکل از دنباله ای از تصاویر صفحه باشد:

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

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

انصافاً باید گفت که گاهی اوقات هنوز باید نمونه های آزمایشی ایجاد کنید. به عنوان مثال، اگر تعامل در برخی از صفحه نمایش ها بیش از حد پیچیده و متغیر باشد، مشتری قادر به درک آن نخواهد بود (این کار برای شما دشوار خواهد بود). تنها راه خروج در چنین شرایطی این است که این صفحه را در تمام حالت های ممکن با همه گزینه های تعاملی ممکن بکشید. همان نمونه آزمایشی را ایجاد کنید.

بنابراین، استفاده از نمونه‌های آزمایشی غیرعملکردی قابل مدیریت است، اما همچنان یک کابوس است (در واقع، این بحث اصلی به نفع ایجاد نمونه‌های اولیه کاربردی است که در ابتدا نمونه‌های آزمایشی هستند). آیا به این کابوس نیاز داری - خودت تصمیم بگیر.

تجزیه و تحلیل نتایج

در نهایت، نوبت به تجزیه و تحلیل نتایج آزمون می رسد. سه چیز در اینجا مهم است:

• چه زمانی آنالیز را شروع کنیم
• چگونه اقدامات پاسخ دهنده را تجزیه و تحلیل کنیم
• آنچه را که می توان از داده های کمی به دست آورد.

نکته قابل توجه این است که چه زمانی باید بهینه سازی رابط را شروع کرد.

چه زمانی آنالیز را شروع کنیم

می توانید نتایج را هم در حین و هم بعد از آزمون تجزیه و تحلیل کنید. تجزیه و تحلیل در طول آزمایش دارای مزایا و معایبی است. از مزایای آن می توان به این موارد اشاره کرد:

• به شما امکان می دهد در مرحله تجزیه و تحلیل زمان صرفه جویی کنید، زیرا بخشی از تجزیه و تحلیل در مرحله قبلی انجام می شود.
• مستقیم ترین تصور را از آزمون (گشتالت) می دهد، که به شما امکان می دهد مشکلاتی را ببینید که به هیچ وجه متوجه آنها نمی شوند.

معایبی نیز دارد:

• اجازه ضبط بیش از یک نشانگر ارگونومیک را در یک زمان نمی دهد و حتی در آن زمان در عمل فقط می توان سرعت کار کاربر و تعداد خطاهای انسانی را اندازه گیری کرد (اگرچه اینها محبوب ترین نشانگرها هستند).
• تنها با تجربه قابل توجه یک متخصص قابلیت استفاده امکان پذیر است.
• اگر آزمایش توسط یک متخصص انجام شود و تجزیه و تحلیل توسط دیگری انجام شود غیرممکن است (از طرف دیگر مشاهدات کسی که آزمایش را انجام داده است قطعاً برای این شخص دیگر مفید خواهد بود).

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

بنابراین، به نظر می رسد استراتژی بهینه شروع تجزیه و تحلیل در طول آزمون باشد. در برخی موارد، این تحلیل می تواند محدود باشد. اگر این غیرممکن است، همیشه می توانید پروتکل های تست ویدیویی را نیز تجزیه و تحلیل کنید.

تجزیه و تحلیل اقدامات پاسخ دهندگان

تقریباً تمام آزمایش‌های قابلیت استفاده با هدف یافتن و شناسایی مشکلات انجام می‌شود. اما چگونه می توان مشکل را در عملکرد پاسخ دهندگان دید؟

اشتباهات

هر اشتباه پاسخ دهنده با مشکلات رابط توضیح داده نمی شود، به عنوان مثال، پاسخ دهنده می تواند بی توجهی ابتدایی نشان دهد. با این حال، هر خطایی نیاز به بررسی دارد:

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

کاهش سرعت کار

اگر مخاطب بدون هیچ دلیل واضحی مکث کرد، به این معنی است که او در تلاش است تا بفهمد که چه کاری باید انجام دهد. رابط کاربری احتمالاً به اندازه کافی واضح یا بدون ابهام نیست. مشکل باید اصلاح شود.

شما می توانید کاهش سرعت را نه تنها با خود کند شدن سرعت مشاهده کنید، بلکه همیشه به وضوح قابل توجه نیست، بلکه با حرکات تصادفی نشانگر ماوس همراه با آن (بسیاری از افراد، با از دست دادن رشته عمل، به طور خودکار مکان نما را حرکت می دهند).

) مرحله ای از ارزیابی طراحی وجود دارد، در آن است که می توان تست قابلیت استفاده با کیفیت بالا را انجام داد.

به دلیل مشکلاتی که در طول تست قابلیت استفاده من به وجود آمد، مجبور شدم این مقاله را بنویسم. امیدوارم بتوانم به کسی کمک کنم تا با دقت بیشتری تعیین کند که چه زمانی از تست قابلیت استفاده استفاده کند و چگونه از برخی از سوالات در هنگام انجام آن اجتناب کند.

طراحی مجدد وب سایت

چه زمانی باید تست قابلیت استفاده را انجام دهید و چه چیزی قبل از آن انجام می شود؟

در مورد یک سایت از قبل توسعه یافته، سؤال انجام آزمایش قابلیت استفاده زمانی مطرح می شود که احساس می کنید یا متوجه می شوید که مشکلی در سایت وجود دارد. در هر صورت نصب گوگل آنالیتیک (کتاب: گوگل آنالیتیکس. تحلیل حرفه ای ترافیک وب سایت) یا سرویس دیگری برای تجزیه و تحلیل بازدید از وب سایت ضروری است. من در مورد اینکه چرا باید چنین سرویسی نصب شود صحبت نمی کنم ، زیرا موضوع مدت هاست که تمام شده است و فقط افراد تنبل نصب چنین خدماتی را توصیه نمی کنند. پس از نصب گوگل آنالیتیک، از قبل اطلاعات خاصی در مورد آمار بازدید، نقاط ورود و خروج بازدیدکنندگان سایت و سایر اطلاعات دارید.

گام بعدی باید تعریف KPI ها (ویکی پدیا: شاخص های کلیدی عملکرد) باشد. لازم است تجزیه و تحلیل شود که چه چیزی برای کسب و کار مهم است، تا اهدافی که سایت ها باید به آن دست یابند مشخص شوند.

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

اگر تا این مرحله توصیه ها اجباری بود، یعنی در هر صورت، این مراحل به توسعه و ارتقای سایت کمک می کند، اگر واقعاً متوجه شدید که سایت مؤثر نیست، توصیه هایی وجود دارد.

مرحله سوم شناسایی مستقیم صفحات و توابع مشکل ساز است. فقط انجام تست قابلیت استفاده موثر نیست، باید بفهمید که مشکلات کجا رخ می دهد، در کدام صفحه، با کدام تابع، و سپس تست کنید تا مشخص کنید دقیقاً چه چیزی در صفحه اشتباه است و چگونه آن را حل کنید. باز هم، تجزیه و تحلیل گوگل کمک خواهد کرد، در اینجا می توانید تعیین کنید که کاربران کدام صفحات را ترک می کنند، کدام صفحات نادیده گرفته می شوند و کدام توابع استفاده نمی شوند.

آماده شدن برای تست قابلیت استفاده

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

مرحله چهارم باید ایجاد فرضیه هایی در مورد مشکل صفحه باشد و بر این اساس باید معیارهایی (ویکی پدیا: ISO 9126 - ارزیابی محصول نرم افزار) که ویژگی ها در برابر آنها آزمایش می شود (همتا وجود دارد) تعیین شود. روش بررسی که در آن کارشناس فرضیه هایی را برای بهبود رابط کاربری سایت مطرح می کند و بر اساس آنها سایت مجدداً طراحی می شود، با این حال فقط با نتایج اعمال تغییرات می توان بررسی کرد که آیا این فرضیه واقعاً درست است یا خیر. که مستلزم یک قیمت خطای بزرگ است).

مثال: با استفاده از Google analytics مشخص کردیم که کاربران وارد صفحه ثبت نام می شوند اما آن را پاس نمی کنند. شاید کاربران نتوانند بفهمند چه اطلاعاتی را باید در فیلدها وارد کنند یا ندانند بعد از پر کردن فیلدها چه کاری انجام دهند. بنابراین، ما باید این صفحه را از نظر قابل فهم بودن پیام های سیستم و توالی عملیاتی آزمایش کنیم.

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

توجه: سناریویی را انتخاب کنید تا تا آنجا که ممکن است مناطق مشکل دار مورد آزمایش قرار گیرند.

سپس انتخاب پاسخ دهندگان بر اساس شخصیت انتخاب شده است. هرچه پاسخ دهنده بیشتر با پرتره شخصیت مطابقت داشته باشد، بهتر است. تعداد کافی پاسخ دهندگان 5-8 نفر است. من در انتخاب مقدار بر اساس توصیه جاکوب نیلسن و تجربه خودم هستم.

بلافاصله قبل از خود تست قابلیت استفاده، به پاسخ دهنده اجازه دهید پرسشنامه ای را پر کند تا بررسی کند که آیا شخصیت انتخاب شده و پاسخ دهنده با ویژگی های مورد نیاز مطابقت دارند یا خیر. یک جلسه توجیهی مقدماتی برگزار کنید که در طی آن زمینه استفاده از سایت و کار را توضیح دهید (کتاب‌ها: طراحی وب: کتابی نوشته استیو کروگ، یا مرا مجبور نکنید فکر کنم!).

مثال کار: در جستجوی یک تلفن همراه جدید، از طریق یک موتور جستجو به این سایت آمدید. تلفن مورد نظر خود را پیدا کنید (همچنین از مخاطب بخواهید تلفن مورد نظر خود را توصیف کند).

انجام تست قابلیت استفاده خود (برنامه: Usability Studio) آنقدرها هم که به نظر می رسد دشوار نیست. شما به یک لپ‌تاپ با دوربین و نرم‌افزاری نیاز دارید تا از حرکات کاربر و عکس‌برداری از صفحه نمایش عکس بگیرید. از پاسخ دهنده بخواهید در مورد تمام اعمال و احساسات خود اظهار نظر کند. همانطور که تمرین نشان می دهد، او به هر حال این کار را انجام خواهد داد (و این تعجب آور نیست، زیرا حتی در خانه، کاربران اغلب دوست دارند اشکال مختلف و سایر عناصر را در سایت ها سرزنش کنند یا برعکس).

پس از اتمام آزمون، از پاسخ دهنده در مورد تجربه خود، مشکلاتی که برایشان پیش آمده و چه چیزهایی ناراحت کننده بودند، بپرسید. من استفاده از داده های نظرسنجی را به عنوان یک قانون برای تغییر هر چیزی که او دوست ندارد توصیه نمی کنم. شما باید به حرف کاربران گوش دهید، اما به نظر ذهنی او بسیار بی اعتماد باشید. بهتر است اگر بر اساس نتایج نظرسنجی، فرضیه ای در مورد نیاز به تغییر رابط ها ظاهر شد، یک مورد دیگر را به لیست مناطق مشکل اضافه کنید و آن را در تکرار بعدی آزمایش کنید.

مدیریت داده های تست قابلیت استفاده

در مرحله بعد، شما باید مطالب ویدئویی جمع آوری شده را مشاهده کنید، نتایج تست قابلیت استفاده را تجزیه و تحلیل کنید و الزامات رابط را برای طراحی مجدد تعیین کنید (کتاب: طراحی وب. قابلیت استفاده از وب سایت ها). تغییراتی که بر اساس الزامات خاص ایجاد می شوند باید در آزمون قابلیت استفاده بعدی بررسی شوند. تعداد چنین تکرارهایی باید تا حد زیادی به اهداف و بودجه اختصاص داده شده برای طراحی مجدد سایت بستگی داشته باشد.

مثال‌ها: نکاتی را به فرم ثبت‌نام اضافه کنید، دکمه خرید را برجسته کنید، فیلد "پلتفرم" را به فرم انتخاب تلفن بر اساس پارامترها اضافه کنید و غیره.

طراحی سایت

اگر طراحی بر اساس استاندارد ISO 9241-210 انجام شده باشد، تست قابلیت استفاده نباید فرآیندی پرهزینه و زمان بر در ارتباط با پایگاه تحلیلی تهیه شده باشد. مراحل اصلی تست قابلیت استفاده هنگام طراحی سایت از ابتدا همان چیزی است که در بالا توضیح داده شد، به استثنای برخی جنبه ها:

1. شکل گیری فرضیه ها
2. تعریف معیارها برای تست
3. تعریف شخصیت ها و سناریوها
4. انتخاب پاسخ دهندگان
5. پر کردن پرسشنامه
6. آموزش القایی
7. انجام تست قابلیت استفاده
8. نظرسنجی از پاسخ دهندگان
9. تجزیه و تحلیل نتایج
10. تعیین الزامات طراحی سایت

مشکل اصلی که من در طول تست قابلیت استفاده در این مورد با آن مواجه شدم، آزمایش یک طراحی ثابت است، نه یک سایت کامل. در واقع بهتر است طرح و حتی سایت برنامه ریزی شده را تست کنید، اما هزینه تکرار در طرح از قبل بالا خواهد بود. هر چه زودتر مشکلی در رابط پیدا شود، هزینه رفع آن کمتر است. چگونه می توان آزمایش قابلیت استفاده کامل یک تصویر استاتیک را انجام داد؟ راه حل این مشکل برنامه Axure بود. ارزان ترین و موفق ترین راه، قرار دادن مصنوعی لینک ها بر روی یک تصویر ثابت از طراحی سایت و تولید آن در HTML صفحه بود. این روش امکان تست سایت را بدون صرف منابع حتی برای چیدمان فراهم می کند. البته در صفحات تولید شده تقریبا هیچ عملکردی وجود ندارد، فقط به شکل خاصی نمایش داده می شود، اما همین برای شناسایی مشکلات بیشتر کافی است.

من گزینه آزمایش قابلیت استفاده کمی را در نظر نمی گیرم ، زیرا به شما امکان می دهد ارگونومی کلی رابط را تعیین کنید ، اما به شما امکان نمی دهد تعیین کنید چه مشکلاتی ایجاد می شود ، چرا و چگونه آنها را برطرف کنید.

P.S. من منتظر انتقاد سازنده در مورد راه حل پیشنهادی تست قابلیت استفاده با کیفیت بالا از طراحی هستم، زیرا من چنین راه حلی را در هیچ کجا ندیده ام. اگر پیشنهاداتی در مورد نحوه انجام تست قابلیت استفاده کامل و با کیفیت بالا ارزان و شاد وجود دارد، خوشحال می شوم آن را بخوانم.

برای یافتن مناطق مشکل دار در سایت یا محصول انجام می شود. هدف اصلی آن ایجاد تغییرات بعدی در سایت و ارائه فرضیه های جدید برای تست A/B است.

آیا نیاز به افزایش نرخ تبدیل در وب سایت خود دارید؟ راه اندازی یک وب سایت یا محصول جدید و نیاز به بازخورد از مشتریان بالقوه؟ پس این مقاله برای تو است. امروز در مورد مراحل تست و نحوه انجام صحیح آن صحبت خواهیم کرد.

6 مرحله تست قابلیت استفاده

مرحله 1. اهداف کلیدی مطالعه را تعیین کنید

کیفیت و نتیجه نهایی تست قابلیت استفاده بستگی به این دارد که چگونه اهداف مطالعه را درست و دقیق فرموله کنید. شما نباید همه چیز را یکباره در یک آزمون بررسی کنید. توصیه می کنیم برای هر آزمون یک هدف را انتخاب کنید، این به شما کمک می کند تا وظایف را به درستی برای کاربران تنظیم کنید و داده های بیشتری را برای تجزیه و تحلیل به دست آورید.

مثال بد:

• هدف از مطالعه شناسایی تمامی مشکلات سایت می باشد.

مثال خوب:

• هدف از مطالعه این است که بفهمیم کاربر چقدر راحت می تواند محصول مناسب را پیدا کند و سفارش دهد.

مرحله 2. مخاطب هدف را انتخاب کنید

شما باید تست قابلیت استفاده را بر روی افراد واقعی انجام دهید، تا جایی که ممکن است به مخاطبان هدف خود نزدیک شوید. علاوه بر این، آنها باید برای اولین بار از سایت شما استفاده کنند (یا برای اولین بار یک به روز رسانی جدید را آزمایش کنند). اگر شخصی قبلاً نحوه استفاده از سایت را یاد گرفته باشد، نسبت به خریدار جدید با مشکلات بسیار کمتری روبرو می شود و خطاها و مشکلات کمتری پیدا می کند.

کجا به دنبال آزمایش کننده ها بگردیم؟

اگر یک شرکت b2c دارید و کالا یا خدماتی را به مخاطبان گسترده ای (کفش، کالاهای خانگی و غیره) می فروشید، توصیه می کنیم از خدمات تست قابلیت استفاده آنلاین ما استفاده کنید. نقطه کاربری. en، جایی که پایگاه بزرگی از آزمایش کننده ها وجود دارد که از بین آنها می توانید مخاطبان هدف خود را بر اساس سن، جنسیت و هر پارامتر دیگری انتخاب کنید:

البته، اگر مخاطبان بسیار محدودی دارید (به عنوان مثال، اگر یک فروشگاه آنلاین برای چوب بران چوکوتکا دارید)، باید یک گروه متمرکز را به روش قدیمی برگزار کنید، فرآیند آزمایش را خودتان، در یک اتاق مناسب سازماندهی کنید. یا از خدمات آژانس ها استفاده کنید. البته تست سنتی بسیار گرانتر است و ده برابر زمان بیشتری را می طلبد.

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

در محافل علمی، این موضوع بحث قدیمی است. طبق تحقیقات Jakob Nielsen و Thomas Landauer، 5 کاربر 85٪ مشکلات را در قابلیت استفاده پیدا می کنند، 15 کاربر 100٪ مشکلات را پیدا می کنند. شکل یک مدل ریاضی برای یافتن مسائل قابلیت استفاده ارائه شده توسط نیلسن را نشان می دهد.

تحقیقات جدیدتر و محکم تر نیاز به مشارکت بیشتر شرکت کنندگان را نشان می دهد. دکتر گیته لیندگارت از دانشگاه کارلتون نشان داده است که درصد مشکلات یافت شده بیشتر به کیفیت مشکلات برای آزمایش بستگی دارد تا نمونه. گروه‌های 5-6 کاربر در تحقیقات او 30 تا 50 درصد از مشکلات قابلیت استفاده را در رویکردهای مختلف برای فرمول‌بندی مشکل پیدا می‌کنند. می توانید با گاهشمار تحقیقات و اختلافات در لینک - تاریخچه جادوی عدد 5 در تست کاربردپذیری آشنا شوید.

توصیه می کنیم آزمایش قابلیت استفاده را با هر دو مورد انجام دهید حداقل 10 نفرو باید به خاطر داشت که یک شاخص به همان اندازه مهم علاوه بر نمونه، کیفیت وظایف و سوالات است.

اگر قصد دارید چندین تکرار را در طول فرآیند توسعه سایت اجرا کنید، باید یک گروه جدید برای هر آزمون استخدام کنید. این در هنگام محاسبه بودجه مهم است.

مرحله 3: یک اسکریپت و وظایف ایجاد کنید

سناریو - مسیری که کاربر از ابتدا تا انتها برای رسیدن به هدف مطالعه طی می کند. در هر مرحله از اسکریپت، باید وظایفی را ایجاد کنید که به افراد اجازه می‌دهد هنگام تعامل با سایت یا محصول شما، با صدای بلند فکر کنند.

همانطور که قبلاً گفتیم، شما نباید همه چیز را یکباره در یک تست بررسی کنید. گزینه ایده آل این است که تحقیقات خود را برای هر هدف انجام دهید و یک سناریوی خاص برای آن با مجموعه ای از وظایف ایجاد کنید. به یاد داشته باشید که برای تست کیفیت، 15-20 دقیقه زمان بهینه برای کاربر برای تکمیل یک سناریو است. همچنین، انجام بیش از 4-5 کار را در یک سناریو توصیه نمی کنیم.

از انواع وظایف مختلف در اسکریپت ها استفاده کنید

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

نمونه هایی از وظایف گسترده:

• کیفی را که دوست دارید پیدا کنید.
• هتل مناسب را برای تعطیلات خود در سوچی در ماه آینده پیدا کنید. لطفا نظرات خود را به اشتراک بگذارید.

خاص Tasks می تواند به شناسایی ابزارهایی که کاربران با آنها مشکل دارند و با آنها مشکل دارند کمک کند.

نمونه هایی از وظایف خاص:

• یک کیسه قرمز تا 10 هزار روبل پیدا کنید.
• هنگام ثبت سفارش برای هدیه، نشان دهید که می خواهید آن را از نزدیک ترین نقطه تحویل بگیرید. صفحه نتایج را بررسی کنید. موارد را بر اساس بهترین نظرات مرتب کنید.

کارهای پیچیده مرکب را انجام ندهید

مثال بد:

• افزودن مورد به سبد خرید حالا مورد دیگری را انتخاب کنید و آن را نیز اضافه کنید. سپس تعداد اولین کالا را در سبد خرید افزایش دهید. اکنون سفارش دهید و تحویل را انتخاب کنید.

بهتر است 4 کار مختلف را انجام دهید:

• افزودن مورد به سبد خرید
• کالای دیگری را پیدا کنید و به سبد خرید اضافه کنید.
• تعداد اولین کالا در سبد خرید را افزایش دهید.
• برای تحویل سفارش دهید.

اهدافی را برای مقایسه با رقبا تعیین کنید

البته قیمت و شرایط تحویل، مهم ترین فاکتور در انتخاب فروشگاه است. اما آیا مطمئن هستید که مشتری محصول را از رقیب خریداری کرده است زیرا قیمت آن 1% کمتر است؟ شاید سایت شما اعتماد کمتری را القا کند؟ یا شاید چت آنلاین کافی وجود ندارد؟ یا مشکل حمل و نقل است؟ اگر شک دارید که دلیل آن در شرایط تحویل است، می توانید این کار را انجام دهید "شرایط تحویل و پرداخت را با رقیب X مقایسه کنید" یا حتی "با رقبای از 3 نتیجه برتر Yandex". دلایل زیادی برای انتخاب یک شرکت می تواند وجود داشته باشد، و تست قابلیت استفاده فرصتی عالی برای یافتن اینکه چرا مشتریان برای خرید محصولات از سایت های رقبای شما انتخاب می کنند، است.

سوالات مناسب برای وظایف بپرسید

وظایف در تست قابلیت استفاده برای مشاهده اقدامات انجام شده توسط آزمایش کنندگان و سوالات مربوط به وظایف برای جمع آوری بازخورد مورد نیاز است. بسته به نوع سوال (سوال ساده، سوال چند گزینه ای، مقیاس رتبه بندی، بازخورد) می توانید نتایج متفاوتی دریافت کنید. برای هر کار، باید سؤالات درستی بپرسید تا داده ها را تا حد امکان به طور کامل برای تجزیه و تحلیل کیفی و فرضیه های بعدی جمع آوری کنید.

نمونه کار:

• در وب سایت های xxx.ru و yyy.ru یک هدیه برای یک دوست در محدوده قیمت از 5 تا 10 هزار روبل انتخاب کنید.

مثال سوال:

• استفاده از فیلترهای محصول در کدام سایت راحت تر است؟

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

مرحله 4: تست خود را تست کنید

البته، تقریباً غیرممکن است که برای اولین بار یک اسکریپت کامل ارائه کنید، بنابراین یک آزمایش آزمایشی برای 1-2 کاربر اجرا کنید. با این کار اکثر کاستی ها در فرمول بندی وظایف و سوالات شناسایی و برطرف می شود.

هدف اصلی این است که مطمئن شوید آزمایش‌کننده‌ها وظایف و سوالات شما را به درستی درک می‌کنند و آنها را به فکر کردن و سوالات اضافی وادار نمی‌کند.

می توانید کارهای زیر را انجام دهید:

• از کسی که می شناسید بخواهید در آزمون شرکت کند (که با پروژه شما آشنایی چندانی ندارد).
• ببینید که شخص با هر کار و موضوعی چگونه کار می کند، هر مشکلی که دارد را یادداشت کنید.
• تغییراتی در وظایف ایجاد کنید و روی کاربر دیگری تست کنید.

استفاده از تست قابلیت استفاده، اجرای یک تست را بر روی 1-2 کاربر از مخاطبان هدف شما آسان و سریع می کند. در عرض 1-2 روز ویدیوها را دریافت خواهید کرد، می توانید وظایف را ویرایش کنید و یک آزمایش جدید برای کاربران بیشتری راه اندازی کنید.

آزمایش آزمایشی کیفیت تحقیق را بهبود می بخشد و در درازمدت در زمان شما صرفه جویی می کند.

مرحله 5: تست

اگر با UserPoint کار می‌کنید، کل فرآیند (ارائه نرم‌افزارهای لازم به آزمایش‌کنندگان، ضبط ویدیویی که تمام استدلال‌های یک فرد در فرآیند تکمیل وظایف را ضبط می‌کند) به‌طور خودکار و بدون مشارکت شما انجام می‌شود. بنابراین، ما به جزئیات این مرحله نمی پردازیم.

اگر تصمیم به انجام تست سنتی دارید، توصیه می کنیم با مواد یکی از پیشگامان تست سنتی گروه نیلسن نورمن آشنا شوید.

مرحله 6. نتایج را تجزیه و تحلیل کنید و فرضیه هایی را برای آن مطرح کنیدآ/ ب- آزمایش کردن

پس از آزمایش، باید داده های کمی (تعداد کارهای انجام شده با موفقیت، زمان تست، تعداد خطاها و مشکلات یافت شده) و کیفی (مشکلات و مشکلاتی که آزمایش کنندگان داشتند، نظرات و توصیه های کاربران، پاسخ ها) را بنویسید و ساختار دهید. به سوالات شما در مورد وظایف). به یاد داشته باشید که هدف نهایی از تست قابلیت استفاده، شناسایی مشکلات آشکار به منظور ایجاد تغییرات در سایت یا محصول و آماده سازی فرضیه ها برای تست A/B جدید است.

همه مشکلات را برطرف کنید

به طور دقیق و مختصر تمام مشکلات و مشکلاتی را که آزمایش کنندگان در روند انجام وظایف داشتند یادداشت کنید.

مثال های بد:

• در مورد ناوبری گیج شده است.
• روی لینک اشتباه کلیک کرد

مثال خوب:

• در مرحله خرید به جای لینک پرداخت، روی لینک "ورود" کلیک کردم.

اهمیت مشکلات را مشخص کنید.

• بحرانی- اگر اصلاح نشود، کاربران نمی توانند کار را کامل کنند.
• جدی- اگر مشکل را برطرف نکنیم اکثر کاربران ناامید خواهند شد.
• جزئی- مردم اذیت می شوند، اما این مانع از انجام کار بدون مشکل نمی شود.

نتیجه گیری را تدوین کنید، تغییراتی ایجاد کنید، فرضیه هایی را برای موارد زیر مطرح کنیدآ/ ب-آزمایش کردن

هر نتیجه گیری باید بر اساس داده های دریافت شده باشد و حاوی توصیه هایی در مورد اقدامات بعدی باشد. اگر مشکل حیاتی است، باید بلافاصله تغییراتی در سایت یا محصول ایجاد کنید. بر اساس اکثر مشکلات، برای اجرای تست های A/B باید فرضیه هایی را مطرح کنید.

فراموش نکنید که نمی توانید تمام توصیه های آزمایش کنندگان را دنبال کنید و سایت یا محصول را بدون استثنا تا حد امکان برای همه راحت کنید. ابتدا روی بزرگترین مسائلی که مستقیماً بر تبدیل سایت شما تأثیر می گذارد تمرکز کنید.

گاهی اوقات با برنامه‌های مبهم و غیرمنطقی مواجه می‌شویم که بسیاری از عملکردها و کاربردهای آن‌ها اغلب آشکار نیستند. پس از چنین کاری، به ندرت تمایل به استفاده مجدد از برنامه وجود دارد، و ما به دنبال آنالوگ های راحت تر هستیم. برای اینکه یک برنامه محبوب باشد، کافی نیست که یک برنامه کاربردی باشد - همچنین باید راحت باشد. وقتی به آن فکر می کنید، برنامه های بصری از ناامیدی کاربران و هزینه های آموزش کارفرما صرفه جویی می کنند. این بدان معنی است که آنها رقابتی تر هستند! بنابراین، تست قابلیت استفاده، که در زیر مورد بحث قرار خواهد گرفت، بخشی جدایی ناپذیر از آزمایش هر محصول انبوه است.

تست قابلیت استفاده- این یک روش آزمایشی است که با هدف تعیین درجه کاربردپذیری، یادگیری، قابل فهم بودن و جذابیت برای کاربران محصول توسعه یافته در زمینه شرایط داده شده انجام می شود. [ ISO 9126]

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

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

سطوح رفتار

تست قابلیت استفاده را می توان هم در رابطه با محصول نهایی، از طریق تست جعبه سیاه و هم در رابط های برنامه (API) مورد استفاده در توسعه - تست جعبه سفید انجام داد. در این حالت، راحتی استفاده از اشیاء، کلاس‌ها، متدها و متغیرهای داخلی بررسی می‌شود و راحتی تغییر، گسترش سیستم و ادغام آن با سایر ماژول‌ها یا سیستم‌ها نیز در نظر گرفته می‌شود. استفاده از رابط های راحت (API) می تواند کیفیت را بهبود بخشد، سرعت نوشتن و حفظ کد توسعه یافته را افزایش دهد و در نتیجه کیفیت محصول را در کل بهبود بخشد.

از اینجا آشکار می شود که تست قابلیت استفاده را می توان در سطوح مختلف توسعه نرم افزار انجام داد: ماژولار، یکپارچه سازی، سیستم و پذیرش. در عین حال، کاملاً به این بستگی دارد که چه کسی از برنامه در یک سطح خاص استفاده می کند - یک توسعه دهنده، یک کاربر تجاری سیستم و غیره.

برای طراحی اپلیکیشن‌های کاربرپسند، پیروی از اصول “bye-yoke” یا Fail-Safe مفید است. در کشور ما، این را بیشتر به عنوان "ضد احمق" می شناسند. یک مثال ساده، اگر فیلد به مقدار عددی نیاز دارد، منطقی است که محدوده ورودی کاربر را فقط به ارقام محدود کنید - خطاهای تصادفی کمتری وجود خواهد داشت.

برای بهبود قابلیت استفاده برنامه‌های موجود، می‌توانید با جمع‌آوری بازخورد در مورد عملکرد و طراحی برنامه از کاربران موجود، از چرخه Demming Plan-Do-Check-Act استفاده کنید و مطابق با نظرات آنها، بهبودها را برنامه‌ریزی و اجرا کنید.

باورهای غلط در مورد تست قابلیت استفاده

1. تست رابط کاربری = تست قابلیت استفاده

تست قابلیت استفاده ارتباطی با تست عملکرد رابط کاربری ندارد، این تست فقط بر روی رابط کاربری و همچنین بسیاری از اجزای محصول ممکن دیگر انجام می شود. در عین حال، نوع تست و موارد تست کاملاً متفاوت خواهد بود، زیرا می توان در مورد راحتی استفاده از اجزای غیر بصری (در صورت وجود) یا فرآیند مدیریت، به عنوان مثال، محصول توزیع شده مشتری-سرور و غیره صحبت کرد. .

2. تست قابلیت استفاده را می توان بدون متخصص انجام داد

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

تست قابلیت استفاده روشی برای ارزیابی قابلیت استفاده و اثربخشی یک رابط است. برای ارزیابی، نمایندگانی از مخاطبان هدف محصول درگیر هستند که با رابط کار می کنند و وظایف انتخاب شده ویژه ای را انجام می دهند. بر اساس رفتار پاسخ دهندگان، متخصص قابلیت استفاده در مورد وجود مشکلات قابلیت استفاده در رابط و ماهیت آنها نتیجه گیری می کند.

چرا به تست قابلیت استفاده نیاز دارید؟

مانند سایر روش‌های ممیزی قابلیت استفاده، آزمایش در مورد درک این است که چه چیزی مانع از موثر بودن محصول شما می‌شود. تست قابلیت استفاده به شما کمک می کند تا دلایل زیر را بیابید:

• فروشگاه آنلاین شما نرخ تبدیل پایینی دارد.
• کاربران شما با سؤالاتی که قبلاً در سایت وجود دارد با مرکز تماس تماس می گیرند.
• برنامه تلفن همراه شما در اپ استور و گوگل پلی نقدهای منفی دریافت می کند.
• کارکنانی که با EDMS شما کار می کنند از آن متنفرند و شکایت دارند که کار با آن بسیار دشوار است.
• و غیره.

همچنین در صورت تمایل به آزمایش نیاز خواهید داشت:

• دو رابط، به عنوان مثال، قدیمی و جدید، خود و یک رقیب را مقایسه کنید تا بفهمید کدام یک بهتر است.
• مقایسه راحتی رابط برای دو گروه از کاربران، به عنوان مثال، برای مبتدیان و با تجربه.
• شناسایی مشکلات بالقوه قابلیت استفاده محصول جدید قبل از عرضه به بازار؛
• انطباق محصول با KPIهای خاص را ارزیابی کنید (به عنوان مثال، "فرایند پرداخت بیش از 5 دقیقه طول نمی کشد").

تست قابلیت استفاده چه تفاوتی با گروه های متمرکز دارد؟

گروه های کانونی همیشه چندین پاسخ دهنده را به طور همزمان درگیر بحث در مورد یک موضوع می کنند. بنابراین، آنها به شما این امکان را می دهند که به طور موثر نظرات پاسخ دهندگان را در مورد یک محصول، خدمات، نام تجاری و هر موضوع دیگری جمع آوری کنید. گروه های کانونی معمولاً برای ارزیابی قابلیت استفاده استفاده نمی شوند، زیرا این روش اطلاعات کمی در مورد مشکلاتی که کاربران هنگام استفاده از رابط تجربه می کنند ارائه می دهد.

در تست قابلیت استفاده، پاسخ دهندگان یک به یک شرکت می کنند، به ندرت دو نفر، اما هرگز به صورت گروهی. هر پاسخ دهنده وظایف خاصی را در رابط سرویس شما انجام می دهد. کارشناس رفتار پاسخ دهنده را مشاهده می کند و نتیجه گیری می کند که چگونه محصول را می توان بهبود بخشید. نتیجه چنین مطالعه ای تشریح مشکلات قابلیت استفاده و توصیه هایی برای رفع آنها بر اساس رفتار است و نه بر اساس نظرات پاسخ دهندگان.

انواع تست قابلیت استفاده چیست؟

با استفاده از معیارهای طبقه بندی مختلف می توان انواع مختلفی از تست را نام برد. ما از همه آنها در تمرین خود استفاده می کنیم.

بسته به میزان مشارکت مدیر (تحلیل UX):

• تعدیل شده - ناظم وظایفی را ارائه می دهد ، پیشرفت اجرای آنها را نظارت می کند ، سؤالات روشن کننده می پرسد.
• بدون تعدیل - یک سرویس تخصصی وظایفی را ارائه می دهد، معیارها و بازخوردها را به طور خودکار و بدون مشارکت ناظر جمع آوری می کند.

یکی از گزینه های تست کنترل نشده از راه دور

بسته به مکان پاسخ دهنده:

• رو در رو - پاسخ دهنده و ناظم در یک اتاق، معمولاً در آزمایشگاه هستند و مستقیماً با هم ارتباط برقرار می کنند.
• از راه دور - پاسخ دهنده در آزمایش از خانه یا محل کار خود شرکت می کند. به عنوان یک قاعده، این آزمایش غیرمعمول است. در صورت نیاز به ناظر، تحلیلگر از طریق پیوند ویدیویی با پاسخ دهنده ارتباط برقرار می کند.

بسته به اهداف:

• اکتشافی - در مرحله توسعه یک مفهوم رابط انجام می شود تا بررسی شود که چگونه این مفهوم توسط کاربران به طور کلی درک می شود، نیازها و انتظارات آنها را برآورده می کند.
• تأیید - برای یافتن و رفع مشکلات قابلیت استفاده یا ارزیابی عملکرد محصول نهایی یا طرح آن (زمان صرف شده برای وظایف، رضایت کاربر و غیره) انجام می شود.
• مقایسه ای - برای مقایسه اثربخشی نسخه جدید و قدیمی یا دو محصول رقیب انجام شده است. نیاز به مشارکت تعداد زیادی از پاسخ دهندگان به منظور نتیجه گیری آماری معنی دار دارد.

تست آزمایشگاهی حضوری برای اکثر پروژه ها مناسب است. این به شما امکان می دهد مشکلات کلیدی رابط را شناسایی کنید و بازخورد دقیق از پاسخ دهندگان جمع آوری کنید. به منظور مقایسه عملکرد دو نسخه از رابط، تست کنترل نشده از راه دور بسیار مناسب است زیرا به شما امکان می دهد حجم زیادی از داده ها را در مدت زمان کوتاهی جمع آوری کنید، اما بینشی در مورد مشکلاتی که پاسخ دهندگان با آن مواجه هستند ارائه نمی دهد.

مدیران ما در مرحله برنامه ریزی پروژه از مشتری در می یابند که او مایل است در نتیجه پروژه چه اطلاعاتی را دریافت کند و بر اساس نیاز او مناسب ترین روش را انتخاب می کند.

تست قابلیت استفاده چگونه انجام می شود؟

به عنوان یک قاعده، ما تست قابلیت استفاده تعدیل شده رو در رو انجام می دهیم. این بدان معنی است که پاسخ دهنده به آزمایشگاه ما می آید و زیر نظر یک متخصص قابلیت استفاده انجام می دهد.

قبل از شروع پروژه، ما با مشتری ارتباط برقرار می کنیم تا درباره محصول مورد آزمایش، مخاطبان آن، اهداف آزمایش و فرضیه هایی که می خواهیم آزمایش کنیم، بیشتر بدانیم.

پس از جمع آوری الزامات پروژه، تحلیلگر UX یک اسکریپت تست می نویسد. این سندی است که حاوی دستورالعمل‌هایی برای پاسخ‌دهنده، فهرستی از کارهایی است که باید آزمایش شوند و سؤالاتی که ناظم باید پس از اتمام هر کار و پس از اتمام آزمایش بپرسد. سناریو با مشتری توافق شده است.

گزیده سناریو عبارت‌ها، معیارهای موفقیت، فرضیه‌هایی که باید مورد آزمایش قرار گیرند و سؤالاتی که ناظم پس از تکمیل کار از سوی پاسخ‌دهنده می‌پرسد، مشخص شده‌اند.

به موازات نگارش فیلمنامه، جستجوی پاسخ دهندگان نیز انجام می شود. به عنوان یک قاعده، 8-12 نفر است. برخی از شرکت ها به ما کمک می کنند تا پاسخ دهندگان را از میان مشتریان خود جذب کنیم. اگر این امکان پذیر نیست یا اهداف مطالعه را برآورده نمی کند، ما به دنبال پاسخ دهندگان از طریق آژانس های تخصصی، به عنوان مثال، RusOpros هستیم. ما شرایط لازم را برای پاسخ دهندگان به آنها ارائه می کنیم و آنها لیستی از شرکت کنندگان بالقوه آزمون را ارائه می دهند. در عین حال، کیفیت استخدام را به دقت کنترل می کنیم: تماس های تلفنی بیشتری با پاسخ دهندگان انجام می دهیم، از آنها سؤالاتی در مورد تجربه شرکت در چنین مطالعاتی می پرسیم، و اگر پاسخ دهنده برای ما نامناسب به نظر می رسد، آن را از بین می بریم.

پس از توافق سناریو و یافتن پاسخ دهندگان، فرآیند تست آغاز می شود. پاسخ دهنده به آزمایشگاه ما می آید. ما با او ملاقات می کنیم، در مورد روش تست صحبت می کنیم، سپس وظایفی که در فیلمنامه تعیین شده است را برای او می خوانیم و پیشرفت اجرای آنها را مشاهده می کنیم. در همان زمان، ما معیارهای مختلف قابلیت استفاده را ثبت می کنیم: زمان و موفقیت کار، رضایت پاسخ دهنده، و برخی از معیارهای روانشناختی عملیاتی که توسط شرکت ما همراه با موسسه روانشناسی آکادمی علوم روسیه ایجاد شده است. قبل از شروع پروژه، مجموعه ای از معیارها را با مشتری در میان می گذاریم.

آزمایشگاه قابلیت استفاده ما نمایی از اتاق مدیر. تصویر از صفحه پاسخ دهنده روی صفحه تکرار می شود

در حین تست، ویدیویی را ضبط می کنیم که هر اتفاقی را که روی صفحه مخاطب می افتد، چهره او و نظراتش شنیده می شود را نشان می دهد. در صورت لزوم، می توانیم از فناوری ثبت حرکات چشم (ردیابی چشم) استفاده کنیم - این اطلاعات اضافی در مورد ماهیت مشکلاتی که پاسخ دهندگان با آن روبرو هستند ارائه می دهد.

پس از اتمام تمام جلسات تست، تحلیلگر UX گزارشی را می نویسد و آن را برای مشتری ارسال می کند.

تست قابلیت استفاده چقدر طول می کشد؟

یک جلسه تست، از لحظه ملاقات پاسخ دهنده تا لحظه جدایی از او، حدود یک ساعت و نیم طول می کشد. از این تعداد، مراحل تست خود حدود یک ساعت طول می کشد، بقیه زمان صرف گفتگوی مقدماتی و نهایی می شود. طولانی تر کردن جلسات تست منطقی نیست. پاسخگویان خسته می شوند و یا به دلیل بی توجهی مرتکب اشتباه می شوند و یا به صورت رسمی شروع به انجام وظایف می کنند که تاثیر بدی بر کیفیت نتایج دارد.

یک پروژه معمولی تست قابلیت استفاده، از جمله تهیه و نوشتن گزارش، حدود سه هفته طول می کشد. با این حال، بسته به ماهیت محصول، اهداف و پیچیدگی آزمایش، فرآیندهای تجاری در شرکت مشتری، زمان ممکن است متفاوت باشد. به عنوان مثال، برای شرکت‌هایی که بر اساس متدولوژی Agile کار می‌کنند، می‌توانیم تست‌های بسیار کوتاهی را انجام دهیم که 1 تا 3 روز طول می‌کشد تا سرعت اسپرینت را برآورده کند. و یک پروژه بزرگ شامل تحقیقات بین فرهنگی می تواند سه تا چهار ماه طول بکشد.

آیا ردیابی چشم شامل تست قابلیت استفاده است؟

آزمایشگاه ما تجهیزاتی برای ثبت حرکات چشم دارد. اما همه پروژه ها نیاز به ردیابی چشم ندارند. معمولاً برای آزمایش فرضیه هایی در مورد اینکه کاربران چگونه یک صفحه را مشاهده می کنند استفاده می شود. برای مثال، اگر فرض کنید که کاربران روی دکمه‌ای کلیک نمی‌کنند زیرا متوجه آن نمی‌شوند، ردیابی چشم می‌تواند به شما در آزمایش این فرضیه کمک کند.

نقشه حرارتی نشان می دهد که چگونه توجه کاربران در صفحه اصلی سایت ما توزیع می شود. برای کارهای مختلف، نقشه حرارتی به دست آمده برای یک صفحه نمایش متفاوت به نظر می رسد.

به‌طور پیش‌فرض، آزمایش‌هایی را بدون ثبت حرکات چشم انجام می‌دهیم. اما همیشه می توانید با مدیر ما در مورد امکان افزودن این گزینه به پروژه خود صحبت کنید.

چه چیزی در گزارش قابلیت استفاده گنجانده شده است؟

به طور معمول، گزارش شامل:

• اطلاعات در مورد ویژگی های محصول، اهداف و اهداف پروژه، پاسخ دهندگان و روش تست؛
• معیارهای قابلیت استفاده برای هر کار (اگر اندازه گیری شده باشند)؛
• شرح مصور دقیق مشکلات قابلیت استفاده یافت شده با نشانه ای از بحرانی بودن و وقوع آنها.
• توصیه هایی برای حل مشکلات یافت شده؛
• اگر حرکات چشم را در حین آزمایش ثبت کرده باشیم، نقشه های حرارتی می گیرد.

ساختار گزارش ممکن است بسته به مشخصات یک پروژه خاص متفاوت باشد. به عنوان مثال، اگر مشکلات زیادی وجود دارد، لیستی از تمام مشکلات را به انتهای گزارش اضافه می کنیم که بر اساس بحرانی بودن مرتب شده اند. این کار تصمیم گیری در مورد آنچه را که ابتدا باید اصلاح شود برای شما آسان تر می کند. همچنین می توانیم شرح راه حل های موفق رقبا را به گزارش اضافه کنیم.

چگونه از نتایج آزمایش استفاده کنیم؟

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

آیا مایلید تست قابلیت استفاده را برای شما انجام دهیم؟

اگر می خواهید که ما تست قابلیت استفاده رابط کاربری شما را انجام دهیم، درخواستی را در وب سایت ما بگذارید. مدیر ما برای بحث در مورد جزئیات و انتخاب بهترین روش با شما تماس خواهد گرفت.