Тестування зворотного зв’язку з користувачем на мобільних девайсах

Що відноситься до зворотного зв'язку?

Коли користувач натискає кнопку в додатку і у відповідь не отримує ніякої реакції, він, швидше за все, подумає, що програма не відгукується на його дію. Коли користувач натискає кнопку і отримує у відповідь «Something went wrong» замість інформативного повідомлення про помилку, йому буде набагато складніше працювати з додатком, так як зовсім не очевидно, де саме був збій. Коли користувач намагається виконати будь-яку операцію і не отримує ніяких інструкцій і допомоги від програми, то йому, швидше за все, буде складно її завершити.

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

Додаток може вести зворотний зв'язок з користувачем декількома способами:

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

Простіше кажучи, під поняттям “зворотний зв'язок” мають на увазі те, що додаток відгукується на будь яку дію користувача і користувач розуміє цей відгук.

Але потрібно також розуміти, що зворотний зв'язок не повинен бути грубим. Якщо кожне натискання кнопки буде супроводжуватися появою спливаючого вікна, то користувачеві це швидко набридне. Адже це незручно, наприклад, кожен раз натискати кнопку «ОК» в діалоговому вікні після додавання товару в кошик, чи не так?

Які перевірки необхідно провести?

При тестуванні мобільного додатку завжди варто звертати увагу на наявність зворотного зв'язку та його зміст. Важливо розуміти, що користувачі будуть взаємодіяти з додатком для досягнення будь-якої мети і не завжди вони матимуть достатньо досвіду для цього.

Перш за все потрібно переконатися, що всі натискання супроводжуються реакцією і зміною стану кнопок. Наприклад, відображається відповідна анімація, щоб користувач бачив, що дія відбулася. Якщо передбачено, що при виборі кнопки будуть відображатися певні елементи (наприклад, фільтрація), то кнопка повинна мати стан «натиснуто». 

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

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

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

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

Стандарти, вимоги до  зворотного зв'язку на різних ОС

На сьогоднішній день існують прописані інструкції та стандарти правильного проєктування мобільних додатків. Один з них – це Android Guidelines, список рекомендацій по розробці доступних і зручних користувачеві додатків для операційної системи Android. У цій інструкції є цілий розділ, який присвячений рекомендаціям, пов'язаних з правильною організацією зворотного зв'язку з користувачем. Це розділ Usability, в якому містяться поради для розробки зрозумілого користувачеві додатку.

Виділяють декілька основних  порад з Android Guidelines:

• Ієрархія. Важливі функціональні кнопки повинні бути згруповані у верхній або нижній частині екрану. Елементи зі схожою функціональністю краще розміщувати поруч один з одним.
• Фокус. Якщо елементів на екрані багато, головні з них повинні бути виділені фокусом. Після відправки довгої форми з помилками, в фокусі повинні бути поля з ними.
• Межі площі натискання. Якщо кнопка невеликого розміру, то для неї повинна бути задана межа натискання для зручної взаємодії з нею. Стандартний розмір кордону повинен бути на 8dp більше від висоти самої кнопки (наприклад, висота кнопки 36dp, межа натискання для кнопки – 44dp).
• Відгук на натискання. За стандартами, час відгуку на натиснення елемента дорівнює 300ms між самим натисканням і функцією, за яку відповідає елемент. Але, в залежності від контексту, час може відрізнятися.

Для операційної системи iOS також існують стандарти проєктування мобільних систем – Human Interface Guidelines. Керівництва для iOS та Android дуже схожі, так як зрозумілість при роботі з додатком важлива незалежно від платформи, для якої програма розроблена.

У Human Interface Guidelines зазначено, що всі інтерактивні елементи повинні виділятися під час натискання, а індикатори прогресу повинні відображати стан тривалих операцій. Також в додаток повинні бути впроваджені анімація і звук, щоб користувачеві були зрозумілі результати дій.

Приклади багів

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

Ще один приклад не інформативного повідомлення про помилку. Умовою успішної реєстрації користувача в цьому додатку було створення складного пароля довжиною 8 або більше знаків, які включають в себе як мінімум одну цифру, букву і спецсимвол. В даному випадку тестувалася реєстрація без інтернет з'єднання. І після відправки форми з введенням дійсного паролю, відображалася помилка «Oops – that did not work». Якщо інтернет з'єднання несподівано зникло, користувач не зможе швидко зрозуміти, що він зробив не так. Користувач може почати вводити інший пароль, так як буде думати, що початковий пароль – невалідний. Але всі його спроби будуть невдалими, і, розчарувавшись, користувач швидше за все видалить додаток, так і не зрозумівши, що проблема полягала у відсутності підключення до Інтернету.

Наступний приклад – відсутність повідомлення про помилку. Під час реєстрації в додатку є ймовірність введення невалідних даних. І в такому випадку ці помилки повинні відображатися і, звичайно ж, бути зрозумілими. На представленому скріншоті в поля форми реєстрації були введені дані, при яких кнопка «Sign up» недоступна: короткий пароль і невалідна адреса електронної пошти. Але користувачеві не зрозуміло, що саме він ввів неправильно, так як ні одна помилка не відображається.

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