Юзабіліті - це не те, що ви можете зробити на будь-якій стадії проектування, воно повинно бути розроблено та вдосконалено протягом всього процесу. Якщо ви хочете отримати кінцевий продукт в кращому вигляді, ви повинні передбачити реальні користувальницькі сценарії ще на етапі прототипирования.
Для того, щоб підготувати сайт для реальних людей, він повинен бути протестований на реальних людей. Прототипи будуються для експериментів, так що вони мають сенс тільки для тестування на реальних користувачів.
Давайте подивимося, як врахувати юзабіліті при розробці прототипу, як протестувати юзабіліті до того, як буде готовий прототип і розглянемо різні поради по тестуванню прототипів.
Юзабіліті тести перед прототіпірованії
Юзабіліті тестування не обов'язково починати зі створення прототипів (насправді, якщо у вас є ресурси для того, щоб приступити до роботи раніше, то так, слід почати). Ці тести можуть визначити кращий спосіб структурування навігації прототипу та інформаційної архітектури. Найбільш поширені тести пре-прототипирования включають:
Правильні користувачі і правильні завдання
Незважаючи на те, що юзабіліті-тести все різні, всім їм потрібні користувачі та більшість з них включають в себе завдання. Оскільки ці два елементи займають чільне місце у всіх юзабіліті тестах, ми будемо коротко пояснювати, як найкращим чином впоратися з обома.
1. Підбір користувачів: після роботи з людьми, ви повинні мати чітке уявлення про ваших цільових відвідувачів. Це також допомагає сегментувати користувачів на основі їх поведінки. Насправді, ви не повинні зациклюватися на демографії. Найбільш важливим, ймовірно, буде: чи мають користувачі досвід в цьому або наскільки добре вони обізнані в своїй області або галузі, а не стать, вік або місце розташування.
Знати, кого залучити до тестування - тільки перший крок. Джефф Савур описав 7 кращих способів знайти ідеального користувача для тестування.
2. Написання завдань: завдання визначають що саме користувач робив під час тесту і таким чином визначає які сценарії тестуються. Тінтін Чжао, юзібіліті фахівець Ubuntu, описує деякі особливості, які слід брати до уваги при проектуванні завдань. Існує два основних рішення:
- Пряма вказівка vs. сценарій: пряме завдання - це завдання, яке дає чітку інструкцію (наприклад, «Здійсніть пошук по сайту за запитом рецепт приготування курки Тандурі»), а сценарій задається контекстом (наприклад, «Ви влаштовуєте звану вечерю для своїх старих друзів і вам потрібен рецепт приготування курки Тандурі »). Прямі завдання працюють краще, якщо ви тестируете технічні дані, в інших випадках підходять сценарії.
- Закриті vs. необмежені: Закриті завдання чітко визначають критерії успіху, в той час як нескінченна завдання може бути завершена декількома способами. Закриті завдання перевіряють конкретні функціональні можливості, в той час як відкриті краще підходять для розуміння думок користувачів. Закриті завдання можуть бути: «У вашого друга день народження в ці вихідні. Знайдіть місце святкування на 15 осіб ". Відкритої буде:« Ви чули, як ваші колеги говорили про iWatch. Ви хочете дізнатися, як це працює ».
Загальні поради для юзабіліті-тестування прототипів
Ще одна поширена помилка в тестуванні - зупинити тестування або дати альтернативне завдання, якщо користувач зазнає труднощів. Оскільки мета юзабіліті-тестування - це знаходити труднощі і вирішувати їх, така ситуація може зробити тест вдалим. Якщо, наприклад, користувач йде за сценарієм, який ще не був розроблений в прототипі, Ви можете запитати його чому він туди пішов і чого хотів цим досягти. Кілька уточнюючих питань можуть дати більш цінну зворотний зв'язок, ніж користувач з «ідеальним досвідом взаємодії».
Різні принципи тестування прототипів
Деякі вважають, що краще тестувати раніше, ще сирі прототипи, а інші - прихильники тестування готових прототипів, ми ж вважаємо, що краще тестувати на кожному з можливих етапів. Кріс Фарнум - старший інформаційний архітектор компанії Enlighten, пояснює плюси і мінуси кожного типу. Нижче ми розглянемо, що тести низькою точності більше підходять для тестування концептів, а тести високої точності - для більш доопрацьованих версій.
Низька точність (Low fidelity): юзабіліті-тестування lo-fi прототипів, включаючи паперові прототипи, може працювати на ранніх стадіях розробки, але стає марним в подальшому. Lo-fi прототипи спонукають до більш об'єктивної критики, так як з самого початку зрозуміло, що робота ще в процесі.
Однак, на пізніх стадіях, коли юзабіліті-тести перевіряють допрацьовані функціональні можливості, lo-fi прототипи стають марними, як тільки ви досягли межі точності. Особливо це актуально для паперових прототипів, так як вам потрібен комп'ютер для того, щоб управляти всіма частинами і це стане проблематично, як тільки ви додасте меню, сторінки і елементи.
Висока точність (High fidelity): тестування hi-fi прототипів дає користувачам максимально реалістичне враження того, що кінцевий продукт сподобається. Hi-fi прототипи ідеально підходять для тестування складних взаємодій і рішень проблем, що виникли на ранніх стадіях тестування. Однак, на відміну від lo-fi прототипів, ці дорожчі.
Середня точність (Medium fidelity): не можете зробити вибір між високою і середньою точністю? Прототипи m id-fi краще працюють, коли необхідний баланс між точністю і вартістю. Якщо ви збираєтеся запустити тільки один етап юзабіліті тестів, то використовуйте medium fidelity.
Чотири принципи контентного тестування прототипів
З нашого досвіду, найкорисніші поради з підготовки вашого прототипу до тестування:
1. Уникайте lorem ipsum: відволікає, збиває з пантелику, чи не передає сенс, текст lorem ipsum повністю не відображає сенс вашого продукту.
2. Використовуйте загальні імена: тести можуть проходити більш захоплююче, якщо використовуються імена знаменитостей або просто дурні назви, але мета тестування - не весело. Будь відволікаючий фактор може вплинути на результат, так що використовуйте загальні і реалістичні назви.
3. Додайте картинки-заглушки або іконки: картинки та іконки грають велику роль в UX, так що вони повинні бути реалізовані на час тестування, навіть якщо тільки будуть представлені у вигляді ескізів. Виняток становлять випадки, якщо образи є суто декоративними і не допомагають розібратися в інтерфейсі.
Учасники тестування можуть зациклиться на деталях, які для вас були незначні, так що будьте обережні в тому, що недоговорюєте. Всі ці маленькі кроки допоможуть зменшити неуважність на шляху до отримання точних даних.