Тестування продукту

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

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

Етапи тестування

Часто запуску продукту передує стадія тестувань. Це може бути досить тривалий процес, який також має власні етапи. Так, поширеним є альфа-тестування, закрите бета-тестування та відкрите бета-тестування.

Якщо говорити простою мовою, то альфа-тестування — це тестування продукту без інтерфейсу. Коли розробники перевіряють, чи суто відпрацьовує функціональність застосунку на технічному рівні. На цьому етапі тестування з продуктом взаємодіють виключно команда розробки та контролю якості (англійською її ще називають QA від Quality Assurance).

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

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

Системи аналітики

І на етапі бета-тестування, і після релізу продукту, цінним є забезпечення автоматизованого збору даних. Для цього використовують різні платформи, найпопулярнішими з яких є HotJar та Google Analytics.

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

Система HotJar дозволяє, по суті, бачити продукт очима клієнтів, і дає розробникам відеозаписи окремих сесій користувачів.

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

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

Чи можна обійтися без досліджень

Відвертим буде сказати, що в реальному житті команди не завжди мають ресурс на дослідження. Часто обставини — обмежений бюджет чи час розробки — змушують поступитись дослідженнями й перейти до проєктування.

І це не завжди завершується фіаско. Наприклад, Мстислав Банік, керівник з розвитку електронних послуг у Міністерстві цифрової трансформації, в інтерв’ю для цього курсу зізнався, що при створенні популярного застосунку Дія вони спільно з командою агенції Spiilka не занурювались глибоко в дослідження. Але це не завадило застосунку стати одним з найпопулярніших цифрових продуктів України, мати чотири зірки в App Store на основі 155 тисяч відгуків та отримати за його інтерфейс нагороду Red Dot.

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

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

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

На завершення

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

Ми плануємо згодом запустити додаткові курси в карті «Дослідження взаємодії». Також з більшістю досліджень ви матимете нагоду познайомитись ближче та попрактикувати їх на нашому живому курсі «Дизайн інтерфейсів. Просунутий рівень».