Планування юзабіліті-тестування. Частина 2



Привіт, Хабр, з вами знову Наталія Спрогіс, керівник напрямку UX-досліджень в Mail.Ru Group! Це друга частина статті про планування юзабіліті-тестування. першою я розповідала про формулювання цілей і гіпотез, вибору методу тестування та інструментів фіксації даних, а також про організаційні моменти для дослідника. Ця частина присвячена складанню протоколу (сценарію) тестування: продумування того, які завдання ви дасте респондентові, які питання будете задавати, які опитувальники запропонуйте заповнити.

Протокол будь-якого юзабіліті-тестування складається з наступних частин:

  • Інструктаж/брифінг (вітання, опис заходу, підписання документів)
  • Вступне інтерв'ю (перевірка скринінгу, невелике інтерв'ю про використання продукту, контексті і сценаріях)
  • Робота з продуктом (завдання тестування)
  • Збір підсумкових вражень від продукту на підставі досвіду тестування
Інструктаж/брифінг


Незалежно від предмета тестування, будь-яке дослідження починається однаково. Потрібно:

  • Створити атмосферу. Познайомтеся з людиною, запропонуйте йому чай, каву або воду, покажіть, де туалет. Постарайтеся трохи розслабити респондента, адже він може нервувати перед заходом. Дізнайтеся, чи легко було знайти вас, запитайте, як настрій.
  • Описати процес. Розкажіть, що за захід чекає респондента, скільки часу вона займе, з яких частин воно складається, що ви будете робити. Обов'язково зверніть увагу респондента на те, що його внесок допоможе поліпшити продукт і що ви не перевіряєте здібності людини. Якщо ви ведете відеозапис, попередьте про це респондента і заспокойте його, що дані не з'являться в Мережі. Я кажу приблизно наступне:
    «Ми знаходимося в офісі компанії Mail.Ru Group. Сьогодні ми поговоримо про проект ХХХ. Це займе близько години. Спочатку ми трохи поговоримо, потім я попрошу вас щось спробувати зробити самому проекті, а після ми обговоримо ваші враження. Ми будемо вести відеозапис того, що відбувається в кімнаті і на екрані комп'ютера. Запис потрібна виключно для аналізу, в інтернеті ви себе не побачите. Ми проводимо дослідження, щоб зробити проект ХХХ краще, зрозуміти, що в ньому потрібно виправити і в яку сторону йому розвиватися. Тому дуже прошу вас відкрито висловлювати будь-які коментарі, і позитивні, і негативні. Не бійтеся нас образити. Якщо при вивченні проекту у вас щось не вийде, ставтеся до цього спокійно. Значить, ми з вами знайшли проблему, яку команді проекту треба виправити. Найголовніше — пам'ятайте: ми не тестуємо вас, це ви тестуєте продукт. Якщо ви готові, пропоную починати».
  • Підписати документи. Як правило, це згода на обробку персональних даних, а іноді — угода про нерозголошення інформації про тестування. Для тестів з неповнолітніми необхідно згоду батьків на участь дитини в дослідженні. Зазвичай ми висилаємо його батькам заздалегідь і просимо принести його з собою. Обов'язково поясніть, навіщо ви просите підписати документи, і дайте час вивчити їх. У Росії люди з острахом ставляться до будь-яких паперів, які потрібно підписати.
  • Налаштувати обладнання. Якщо ви використовуєте айтрекинг, біометричне обладнання або просто ведете відеозапис, саме час все це включити. Попередьте респондента, коли почнете запис.
Вступне інтерв'ю


Воно вирішує наступні завдання:

  • Перевірити рекрутинг. На всякий випадок завжди починайте з цього — навіть якщо ви довіряєте агентству або людині, який знайшов респондента. Не раз вже на тесті ми з'ясовували, що респондент неправильно зрозумів запитання та насправді користується продуктом не зовсім так, як нам потрібно. Намагайтеся відійти від формальності і не задавати питання з скринінгового опитувальника: людина може вже знати, що відповідати на них.
  • Сценарії і контекст використання продукту. Навіть якщо у вас мало часу на тест, не пропускайте цей пункт. Хоча б у цілому дізнайтеся у респондента, які завдання він вирішує за допомогою продукту, користується аналогічними проектами, в яких умовах взаємодіє з ними і з яких пристроїв. Знання особливостей використання продукту допоможе вам краще розуміти причини поведінки респондента. А якщо ви застосовуєте гнучкий сценарій — то і формулювати відповідні завдання. Якщо вистачає часу, попросіть респондента показати, що і як він зазвичай робить. Це буває джерелом подальших питань і інсайтів.
  • Очікування і відносини. Початок тестування — гарний час дізнатися, що респондент знає про продукт, як ставиться до нього і чого від нього чекає. Після тесту ви зможете порівняти очікування з підсумковим враженням.
Для більшості тестів підійде така структура вступного інтерв'ю. Однак якщо ви тестуєте новий продукт, можливо, варто пропустити вступні питання. Якщо ви занадто докладно почнете обговорювати якусь тему, це може створити у користувача певні очікування від продукту. Тому залиште тільки кілька найбільш загальних питань, щоб налагодити контакт з респондентом, і відразу ж переходите до завдань. Обговорювати сценарії, відносини і контекст у цьому випадку краще після того, як користувач первинно вивчить продукт.

Робота з продуктом, складання завдань


Які бувають завдання
Давайте уявимо, що ви хочете протестувати інтернет-магазин. У вас є важливі сценарії (пошук і вибір товару, процес оформлення замовлення), відомі проблеми (часті помилки у формі оплати) і навіть гіпотеза, що дизайнер щось намудрил з фільтром за ціною. Як же сформулювати завдання?

Сфокусовані завдання. Очевидним здається зробити приблизно таке завдання:

«Вибрати посудомийну машину завширшки 45 сантиметрів з функцією „промінь на підлозі“ вартістю не більш як 30 тисяч рублів».

Це мотивує респондента користуватися фільтрами і порівнювати товари між собою. Ви зможете перевірити фільтр ціною на всіх респондентів і подивитися на ключовий сценарій підбору товару. Подібні завдання цілком мають право на життя і гарні для перевірки конкретних гіпотез (як з фільтром за ціною). Однак якщо весь тест буде складатися з них, то ви ризикуєте наступним:

  • Точкова перевірка інтерфейсу. Ви знайдете тільки проблеми, пов'язані з деталями завдання (фільтр за ціною і ширині). Ви не побачите інших проблем, наприклад сортування товарів або інших фільтрів, якщо не вкажете і на них. А зробити завдання для всіх елементів сайту ви навряд чи зможете.
  • Відсутність залучення. Подібні завдання користувачі часто виконують механічно. Побачивши перший товар, який підходить під критерії, вони зупиняються. Можливо, в житті респондент ніколи не вибирав посудомийки і йому все одно, що таке «промінь на підлозі». Чим більше завдання схожа на ситуацію з реального життя, чим більше в ньому зрозумілого користувачеві контексту, тим вище шанси залучити респондента, який представить, що насправді вибирає товар. А залучений користувач краще «проживає інтерфейс», залишає більше коментарів, підвищує його шанси знайти проблеми і дати корисні знання про поведінку й особливості аудиторії.
  • Звужений спектр інсайтів. В реальному житті користувач би, можливо, підбирав товар зовсім не так. Наприклад, взагалі не користуючись фільтрами (а тут ви на них вказали). Чи шукав би товар за критеріями, яких немає на сайті. Даючи жорсткі, сфокусовані завдання, ви не дізнаєтеся про реальному контексті використання продукту, не знайдете сценаріїв, які команда проекту, можливо, не передбачила, не зберете дані про потреби в контенті і функціоналі.
Завдання з контекстом. Один із способів краще залучити користувачів — додати в сухе завдання реальну історію і контекст. Наприклад, замість «Знайдіть рецепт пирога зі сливами» на сайті з рецептами запропонуйте наступне:

«Через годину до вас прийдуть гості. Знайдіть, що можна спекти за цей час. У вас в холодильнику є все для бісквіта, а також трошки злив. Але, на жаль, немає вершкового масла».

Подібний підхід можна використовувати з інтернет-магазином. Наприклад: «Уявіть, що ви вибираєте подарунок сестрі. У неї недавно зламався фен, і вона була б рада отримати новий. Вам потрібно вкластися в 7 тисяч рублів». Важливо, щоб респондент дійсно вибрав реального людини, якій буде «купатися» подарунок (якщо немає сестри, запропонуйте іншого родича або подругу). Ключове для подібних завдань — реальність і зрозумілість контексту. Легко уявити, що ти обираєш подарунок рідним, куди важче — що ти «бухгалтер складав річний звіт».

Яскравий приклад такого підходу — «метод Боллівуду», який вигадала індійський UX-експерт Апала Лахірі Чаван (Apala Lahiri Chavan). Вона стверджує, що індусам, як і багатьом азіатам, складно відкрито висловлювати свою думку про інтерфейсі. Натомість, представляючи себе героями вигаданих драматичних ситуацій (як в улюблених ними фільмах), вони розкриваються і починають жваво брати участь у тестуванні. Тому завдання для індусів повинні виглядати приблизно так:

«Уявіть, що ваша улюблена юна племінниця збирається заміж. І тут ви дізнаєтеся, що майбутній чоловік — шахрай, та ще й одружений! Вам потрібно терміново купити два квитки на рейс до Бангалора для себе і дружини ошуканця, щоб розладнати весілля і врятувати сім'ю від ганьби. Поспішайте!»

Завдання з опорою на досвід респондентів. Нагадаємо: для успішного тестування респонденти повинні відповідати аудиторії проекту. Тому для перевірки інтернет-магазину побутової техніки ми рекрутируем тих, хто недавно вибирав техніку або обирає її зараз. Саме цим ми будемо користуватися, складаючи завдання з опорою на досвід респондентів. Є два варіанти використання такого підходу:

  • Установки респондентів. У цьому випадку ви адаптуєте фіксовані завдання під респондентів. Наприклад, для випадку з магазином побутової техніки та завдання на роботу з фільтрами уточнюєте у людини, що саме він нещодавно придбав. Дізнаєтеся критерії (ціна, функції і т. д.) і пропонуєте повторити покупку на вашому сайті.
  • Сценарії респондентів. Завдання повністю формуються з опорою на досвід учасників. Щоб зрозуміти, які сценарії перевірити, модератор з'ясовує, як саме людина вирішував завдання в житті, і пропонує зробити це на сайті. Наприклад, покупець довго порівнював між собою кілька моделей перед вибором. Навіть якщо на сайті немає відповідної функції, запропонуйте респондентові порівняти товари, щоб зрозуміти, на які параметри він стане спиратися. Можливо, ви отримаєте ідеї, як повинна виглядати функція порівняння, а також адаптуєте під цей сценарій сторінку товару.
Подібні завдання дають багато реальних прикладів виконання базових операцій в продукті. Це часто породжує набагато більший спектр проблем і знахідок. Крім того, дозволяє перевірити продукт на нові сценарії, які ви не вважали основними або навіть не продумували. Наприклад, коли ми тестували проект Нерухомість Mail.Ru саме завдання з опорою на досвід респондентів допомогли нам зробити багато відкриттів. Так, ми побачили, що люди при пошуку квартири в Підмосков'ї вказують в геофильтре кінцеві станції метро, маючи на увазі, що це станції, до яких можна доїхати з області. Ми ж розраховували, що фільтр метро шукає квартиру недалеко від станції. Також ми дізналися, чим відрізняються сценарії пошуку новобудов від вторинки, що допомогло пізніше винести пошук новобудов в інший розділ на сайті — зі своїми фільтрами і своєю концепцією опису квартир.

Раджу також прочитати відмінну статтю Джареда Спула про користь подібних завдань.

Завдання без завдань. Іноді краще взагалі не пропонувати користувачам завдання на роботу з проектом, а подивитися, з чого вони самі почнуть знайомство з продуктом. Дайте респонденту ввідну: «Уявіть, що ви вирішили спробувати цей продукт. Я покину вас на декілька хвилин. Робіть те, що ви стали б робити в реальному житті. Я не даю вам ніяких завдань».

Важливо, щоб модератор при цьому виходив з кімнати. В іншому випадку в користувача з'являється спокуса відразу ж щось запитати, уточнити: «А чи потрібно реєструватися? А ось як це зробити?» і т. д.

Даний тип завдань корисний для повністю нових продуктів. Ми часто застосовуємо його для мобільних додатків та ігор. Так, ми бачимо, читають користувачі навчальні матеріали, які деталі відразу привертають увагу, що люди розуміють у концепції продукту, як потім описують його можливості. Вже після вільного завдання йдуть заплановані конкретні сценарії.

Ще одна область застосування вільних завдань — тематичні проекти. Якщо ви хочете зрозуміти, як читають ваші статті, де надовго затримуються, що пропускають, на які елементи на сторінці звертають увагу тощо, то просто залиште респондента на кілька хвилин наодинці з проектом. Тільки без модератора, який дивиться через плече, користувач розслабиться і буде читати текст так само, як звичайно, в реальному житті. Так ми тестуємо проекти Новини Mail.Ru, Леді Mail.Ru та ін. Цей підхід дозволив виділити різні моделі поведінки на сайті, різні патерни читання статей і зрозуміти, які типи матеріалів варто оформляти по-іншому.

Складаємо хороші завдання
Перше завдання — просте. Починайте тестування з ознайомчих та нескладних завдань. Респондент повинен освоїтися з форматом тестування, особливо якщо ви використовуєте метод «думки вголос»: на першому завданні людині потрібно звикнути до необхідності озвучувати свої думки і почуття. Не варто відразу вивалювати на нього всю біль і страждання інтерфейсу.

Не підказуйте. Сформулюйте завдання так, щоб не підказувати правильних дій респондентові. Наприклад, якщо ви хочете протестувати можливість додавання в обране товарів в інтернет-магазині, обійдіться без завдання «Давайте додамо ось цей телевізор в обране», особливо якщо кнопка так і називається. Респондент, прочитавши завдання, буде просто знаходити кнопку з потрібною підписом на екрані, можливо, навіть не розуміючи, що саме він робить. Краще пояснити сенс завдання, не вдаючись до термінів в інтерфейсі. Наприклад: «На сайті є можливість зберегти вподобані товари і потім вибрати з них замовити. Давайте спробуємо зробити це з таким телевізором».

Слідкуйте за термінологією. Не використовуйте незрозумілі слова і позначення. Це здається очевидним, але ми часто, звикнувши до певних термінів, забуваємо, що їх мало хто знає за межами IT-тусовки. Наприклад, при тестуванні нового функціоналу тредів (бесід) в Пошті Mail.Ru нам довелося досить складно. Адже у користувачів, незнайомих з подібним функціоналом, просто немає в голові терміна, який би позначав треди. У підсумку ми ніяк їх не називали. Ми просто показували респондентам ящик з підключеними ланцюжками і обговорювали цю нову можливість. В рамках обговорення давали користувачам самим підібрати слово для позначення тредів. Це допомогло нам пізніше використовувати найбільш зрозумілі тексти в навчальних промоматеріалах. Стежте не тільки за завданнями, але й за питаннями модератора, особливо за тими, які приходять від команди під час тестування. Не варто, наприклад, використовувати слово «тулбар» при обговоренні функцій: воно не всім знайоме. Ще кілька років тому навіть слово «браузер» знали далеко не всі користувачі. Те, як саме краще сформулювати завдання, залежить від аудиторії тестування. Не варто кидатися і в протилежну крайність, пояснюючи всі терміни поспіль. Наприклад, досвідченим гравцям не треба розтлумачувати, що таке «баф», «фрагмент», «респаун» та ін

Менше тестового. Часто дуже велика спокуса зробити респондентові тестовий аккаунт в системі і проводити тестування на ньому. Адже можна заздалегідь все обкатати в цьому записі, уникнути накладок і не витрачати час на реєстрацію або авторизацію респондента. Часто ще і технічно набагато легше включити новий дизайн на тестових, а не на реальних даних. Однак при такому підході ви ризикуєте отримати набагато менше корисних результатів. Адже у тестових дій немає реальних наслідків. Ситуація стає зовсім штучною, користувачам складно проектувати її на реальний досвід. Наприклад, при роботі у власному акаунті в соцмережі респонденти, як і в реальному житті, будуть акуратно робити все, що можуть побачити їх друзі (публікувати посилання, відправляти повідомлення). При налаштуваннях власного ящика в пошті намагатися видалити важливі листи. При тестуванні інтернет-магазинів іноді застосовують підхід, коли винагорода потрібно витратити прямо на тесті. В такому випадку респондент не тицьне в перший відповідний за завданням товар, а підбере те, що йому насправді потрібно.

Плюс, маючи одні лише тестові дані, ви знайдете проблеми, пов'язані тільки з ними, а не перевірите функціонал на різних варіаціях. Наприклад, коли ми тестували соціальну панель браузера Аміго, один з респондентів, подключивший в панель свій аккаунт «ВКонтакте», відразу зазначив, що так читати йому незручно. Майже вся стрічка складалася з підписок на групи з еротичними фотографіями. А у вузькій панелі на картинках було просто нічого не розгледіти.

Ще одна проблема тестових даних — складно розібратися в системі, так як все навколо незвичне. Наприклад, користувач соцмережі звик дізнаватися свою сторінку з власної фотографії. Навіть тестуючи прототипи, ми намагаємося максимально персоналізувати їх. Наприклад, при тестуванні клікабельних прототипів в «Однокласниках» ми завжди адаптуємо їх для кожного користувача, вставляючи на сторінку його ім'я і фотографію, а іноді і останні новини.

Не обмежуйтеся тільки інтерфейсом. Не забувайте про те, що взаємодія з продуктом часто не обмежується одним лише інтерфейсом. Якщо є можливість, тестуйте супутні продукти або послуги і зв'язку між ними. Наприклад, при тестуванні ігор ми намагаємося перевірити не тільки гру, але і її сайт і пов'язані з ним завантаження, реєстрацію в грі, пошук інформації на форумі. А при тестуванні одного інтернет-магазину я також перевіряла дзвінок оператора після оформлення замовлення, що дало рекомендації для колл-центру.

Думайте про таймінгу. Для хорошого сценарію важливо розставляти пріоритети завдань. Швидше за все, якщо система велика і цілей у тесту багато, вам захочеться зробити дуже багато завдань. Однак втомлений респондент вже не буде корисний. Хороший тест триває не більше півтора годин, два — це максимум. Виняток хіба що ігри. І пам'ятайте, що ваша мета — не лише завдання, але й інтерв'ю, опитувальники, налаштування обладнання та підписання документів. Все це зазвичай займає не менше півгодини. Якщо завдань дуже багато, а відмовитися від якихось дуже не хочеться, можете найменш пріоритетні пустити в ротацію, тобто показувати тільки частини респондентів. Або зробити частину тіста обов'язковою для всіх, а решту дивитися тільки з тими, з ким вистачить часу. Але це, швидше за все, будуть найбільш успішні респонденти.

Оцінюйте корисність завдання. Подумайте, чи дійсно воно відповідає вашим гіпотез. Наприклад, ви хочете перевірити функцію підписки на новини на сайті. Завдання Підпишіться на розсилку» дозволить перевірити тільки те, чи зможуть знайти розсилку ті, хто буде її шукати. Однак ми розуміємо, що люди рідко приходять на сайт, щоб підписатися на новини. Завдання не відноситься до реального життя. Вам же потрібно зрозуміти, помічають можливість підписки ті, хто виконує зовсім інші завдання. Перевіряти це можна різними способами — в залежності від реалізації функції. Якщо людина займався завданнями, в яких йому на очі могла потрапити можливість підписки, запитайте його, чи є вона на сайті. Тільки обов'язково уточніть, де він бачив цю можливість або як вона реалізована, щоб упевнитися, що респондент не просто з вами погоджується. Якщо пропозиція підписки вбудовано в процес реєстрації або оформлення замовлення, подивіться, чи скористається їм респондент, а після завдання обговоріть це. Дуже мало шансів, що в лабораторних умовах люди реально підпишуться на розсилки, але можна перевірити, звернув людина увагу на таку можливість, чого він очікує від розсилки і т. п.

Збір підсумкових вражень


Мета заключної фази тестування — зібрати враження від роботи з продуктом, зрозуміти, що сподобалося користувачеві, а що засмутило, оцінити суб'єктивну задоволеність. Як правило, в цій частині тесту використовується поєднання інтерв'ю з модератором та заповнення формальних опитувальників.

Інтерв'ю з модератором
У підсумковому інтерв'ю ми завжди ставимо респондентам приблизно одні і ті ж питання: «Які враження залишилися?», «Що сподобалося, а що ні?», «Було щось, що здалося складним або незручним?», «Чого не вистачало?», «Що хотілося б змінити в продукті?» і т. п. Саме час уточнити незрозумілі моменти поведінки респондента, якщо ви не зробили цього в процесі тесту. А якщо ви дізнавалися у користувачів ставлення до бренду або продукту та очікування від нього до тесту — з'ясуйте, чи змінилося що-небудь. При інтерв'ю звертайте увагу на наступне:

  • Соціальна бажаність. Звертайтеся за результатами інтерв'ю дуже акуратно. Якщо під час тесту ви часто чуєте імпульсивні коментарі під впливом проблем, то у фінальному інтерв'ю щосили розквітає соціальна бажаність. Одним здається, що, говорячи про проблеми в продукті, вони визнаються у власній некомпетентності. Інші просто не хочуть засмучувати приємного в спілкуванні модератора. Дуже часто респонденти (особливо жінки), які промучилися увесь тест, кажуть, що все, в принципі, нормально. Негативні відгуки також можуть бути продиктовані соціальної желательностью: якщо респондент впевнений, що мета тесту — знайти недоліки, він старанно намагається їх відшукати.
  • Цитати і пріоритети. Незважаючи на те що всі слова учасників тесту у фінальному інтерв'ю часто треба ділити на два, а то й на десять, це не означає, що вони марні. По тому, як саме респонденти підсумовують враження, ви можете зробити висновок про пріоритети. Продукт — «повний відстій»? Що саме вплинуло на це? Яку з багатьох проблем респондент запам'ятав найбільше і вважає самої дратівної? Однак робіть знижку на те, що найкраще запам'ятовується останнє завдання. Також дуже корисно відслідковувати, якими прикметниками описують продукт респонденти в розмові, з чим порівнюють свій досвід.
  • Не забуваємо про хороше. Дуже часто звіт про юзабіліті-тестування — це довгий перелік знайдених під час тесту проблем. Загалом-то, пошук проблем — одна з основних завдань. Однак, будь-ласка, не забувайте і про позитивні сторони продукту. Тому що, по-перше, звіт без позитивних результатів просто демотивує команду. А по-друге, корисно знати, що користувачам в продукті подобається. Раптом при наступному редизайні вирішать забрати функцію, яка так всім сподобалася. Тому обов'язково запитуйте у респондентів про позитивні сторони продукту, навіть якщо вони лаяли інтерфейс протягом всього тестування.
  • Ставлення до «хотінням». Швидше за все, крім своїх вражень, респонденти будуть також висловлювати побажання та ідеї. Ваше завдання — зрозуміти, яка проблема стоїть за пропозиціями. Тому що рішення, які запропонують користувачі, з високою ймовірністю вам не підійдуть. Адже учасники тестування — не дизайнери, вони не в курсі особливостей і обмежень розробки. Тим не менше за будь-яким подібним запитом стоїть потреба, яку ви повинні зафіксувати. Якщо респондент говорить, що йому ось тут неодмінно потрібна велика зелена кнопка, обов'язково запитайте — а навіщо?
Міра задоволеності
Часто за словами респондента у фінальному інтерв'ю складно зрозуміти, сподобався йому в підсумку продукт чи ні. А вже тим більше важко порівняти ставлення кількох респондентів, які плюси і відзначали, і недоліки знаходили. Тут на допомогу досліднику приходять опитувальники. По-перше, при заповненні опитувальника (особливо розмови з модератором) трохи менше вплив горезвісної " соціальної бажаності, хоча повністю ви від нього не позбудетеся. По-друге, опитувальник дає вам чіткі параметри, що дозволяють порівнювати сценарії, продукти або стадії проекту.

Складання гарного опитувальника — це окрема і дуже велика тема. Тут важливі і формулювання, і шкали, і багато іншого. Тому хорошою підмогою можуть стати готові та перевірені опитувальники. Вони вже відточені і багаторазово перевірені. Проблема тільки в тому, що майже у всіх цих анкет немає офіційних перекладів на російську. Природно, ви можете перевести їх самостійно, але з методологічної точки зору переклади треба протестувати, щоб перевірити коректність формулювань. Тим не менш анкети можуть стати орієнтиром при складанні власних опитувальників.

Є опитувальники, які даються після кожного завдання, щоб оцінити задоволеність від конкретних сценаріїв. Наприклад:

А є анкети, які застосовуються вже в завершальній фазі тестування. Ось кілька прикладів, які ми використовуємо при необхідності:

  • System Usability Scale (SUS), Post-Study System Usability Questionnaire (PSSUQ). Два класичних і популярних опитувальника, створених понад 20 років тому. Обидва складаються з тверджень. Респонденти повинні вказати ступінь згоди з ними. Всі ці твердження з різних сторін характеризують юзабіліті продукту. Наприклад: «Я легко міг знайти потрібну інформацію», «Різні можливості системи легко доступні» і т. д.
  • Microsoft Desirability Toolkit. Опитувальник, який часто допомагає нам на тестах. Користувачеві надається набір прикметників, з яких він вибирає ті, що, на його погляд, можуть характеризувати продукт. У підсумку ви отримуєте хмара слів — характеристик вашого проекту. Часто ця методика приносить дуже цікаві результати.
  • Game Experience Questionnaire. До ігор не можна застосовувати класичні юзабіліті-опитувальники: залученість в ігровий процес набагато важливіше, ніж зрозумілість інтерфейсів. Тому для ігор треба завжди становити особливі опитувальники або користуватися GEQ. Опитувальник містить декілька модулів: базовий модуль, внутрішньоігровий блок, постопросник і опитувальник соціальних можливостей гри.
Ви можете скористатися запропонованими анкетами або створити свої опитувальники, актуальні для вашого продукту.

Висновок
Гарне планування дозволить вам провести дослідження, точно відповідає цілям замовника і максимально корисне для проектної команди. Також грамотний план скорочує час підготовки звіту. Однак, як би добре ви не підготувалися, обов'язково проведіть пілотний тест на кому-небудь із колег або знайомих. Це дозволить уникнути казусів з неправильно налаштованим обладнанням, покаже, що ви укладаєтеся в таймінг, чи зрозумілі тексти завдань і немає помилок в опитуваннях.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.