UX КАЛЕНДАР – 22 ГРУДНЯ – 5 запитань, яких слід уникати під час тестування користувачів, і що ставити натомість

Побудова питань у тестуванні користувачів дуже важлива для збору надійних і корисних ідей. Розглянемо деякі поширені помилки як приклад: ми побачимо, як їх уникнути та вдосконалимо наші протоколи тестування.

1 – Як би ви використовували цей продукт?

Звертайте увагу на будь-які запитання, які просять користувача спроектувати себе на майбутню поведінку. Ми завжди повинні сприймати «декларацію» з недовірою, навіть коли користувач повідомляє про свою пам’ять про реальну ситуацію, і особливо важко покладатися на неї, коли користувач повинен уявити вигадану ситуацію: те, що ми можемо уявити, це часто не буде відповідати тому, що ми насправді збираємося робити.

«Як ви використовуєте/використовували цей продукт?» 

Замість того, щоб просити його уявити майбутнє, ми можемо натомість поставити користувачеві запитання про сьогодення чи минуле: «Як ви використовуєте подібні продукти чи функції сьогодні?», «Який у вас минулий досвід роботи з подібними продуктами чи функціями?»

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

2 – Чи варто нам додати цю функцію?

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

Спостереження за поведінкою 

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

3 – Ви розумієте цей елемент?

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

«Чи можете ви пояснити мені цей елемент?» 

Натомість користувача попросять пояснити елемент своїми словами. Якщо відповідь неправильна або неточна, завжди додаватимуться нагадування, щоб переконатися, що вони є нерозумінням з боку користувача, а не труднощами у висловленні чи поясненні елемента, який насправді зрозумілий. У 2nd час, ми також можемо запитати, чи вони знайшли це зрозумілим або легким для розуміння, тоді ми оцінимо дві речі: розуміння, а також складність, яку сприймає користувач.

4 – Як можна покращити цей елемент?

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

«Як би працював цей елемент в ідеальному світі?»

Щоб знати, як покращити елемент, ми будемо спостерігати за труднощами користувача та просити його пояснити їх нам, деталізувати, що не працює і чому. Розв’язання цих труднощів має знайти дизайнер: це робота!

Насправді ми можемо поставити це запитання не для того, щоб включити бажаний дизайн як є, а щоб перезапустити його, щоб ще краще зрозуміти, що його блокує. Швидше, це формулюється так: «Що б ви могли зробити з цим елементом в ідеальному світі? Як це буде працювати? ".

5 – Чи є цей продукт естетичним?

Смаки та кольори дуже суб’єктивні, і коли ми просимо користувачів оцінити естетику продукту, сайту, сторінки, ми отримуємо суперечливі дані: половині респондентів колір сподобається, а іншій – не сподобається. Приклад кольору актуальний, тому що часто саме цей елемент вражає першим учасника, який не є дизайнером, і це елемент, який рідко можна змінити.

«Що для вас означає дизайн сайту?»

Естетика залишається важливою віссю для оцінки, оскільки вона бере участь у сприйнятті зручності використання інтерфейсу. Користувачі можуть багато розповісти нам про своє сприйняття продукту своєю думкою про естетику. Ми б скоріше запитали «що викликає у вас дизайн сайту? », « які слова спадають на думку, щоб описати естетику сайту? » і знову запустіть спонтанні зауваження « Ви кажете, що кольорів забагато, можете пояснити мені, чому? Які наслідки цього «забагато кольорів»? Що ти відчуваєш ? ".

 

 

Візьміть

Під час тестування користувача порівняння поведінки учасників із заявами учасників є найкращим способом збору відповідних даних.

Коли ми оскаржуємо хитке питання в нашому протоколі, ми повинні завжди повертатися до нашого дослідницького питання і запитувати себе:

  • Чому ми хочемо задати це питання користувачеві?
  • Що ми намагаємося виміряти?
  • Як ми можемо це виміряти?

 

Марі ЮЗЕН, UX-дизайнер @UX-Republic

 

Наші наступні тренування