Як ітеративне тестування скоротило кількість звернень до техпідтримки Mozilla на 70%

Одне з найчастіших питань, яке ставлять собі маркетологи, мабуть: «Чи варто робити редизайн для покращення юзабіліті? Іншими словами, яким буде повернення від інвестицій (return-on-investment, ROI) у такий редизайн?

У цій статті ми розповімо, як за допомогою редизайну юзабіліті Mozilla вдалося покращити ефективність свого сайту техпідтримки майже втричі. Ціна такого редизайну склала 14 людино-тижнів або 560 людино-годин. Багато це чи мало, залежить від погодинної ставки ваших співробітників та вартості вашого сайту, тому якоїсь єдиної відповіді тут бути не може. Однак для Mozilla, як і для будь-якого великого сайту чи компанії, зростання показників виправдовує витрачені зусилля.

Отже, як же компанії вдалося досягти таких вражаючих результатів? Що являв собою їх процес редизайну?

«Больові точки»

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

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

План дій

Для покращення інформаційної архітектури (information architecture, IA) сайту, компанія прийняла рішення інвестувати в дослідження та ітеративне юзабіліті-тестування. Завдання дослідження полягали у тому, щоб з'ясувати (1) як користувалися системою техпідтримки; (2) які типи інформації були справді важливими.

1. Основні питання дослідження:

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

2. UX-команда

UX-команда складалася з трьох членів:

Сьюзан Фаррелл (Susan Farrell) - провідний UX-фахівець у Nielsen Norman Group. Сьюзен провела дослідження, виявлення та аналіз даних, та розробила рекомендації щодо зміни дизайну.
Кристал Біслі (Crystal Beasley) - дизайнер продукту в Mozilla. Кристал керував проектом, узгоджуючи всі дії із зацікавленими сторонами Mozilla, та провів дослідження за допомогою паперового прототипування (paper prototyping).
Брем Пітойо (Bram Pitoyo) - UX-дизайнер в Mozilla. Брем розробив потоки завдань (task flows) та прототипи та контролював зміни дизайну взаємодії на веб-сайті. Він також протестував стару інформаційну архітектуру, щоб порівняти її результати із результатами нової інформаційної архітектури.

Щоб зрозуміти потреби користувачів, а також перебудувати інформаційну архітектуру та робочий процес (workflow), були використані різні методи дослідження:

Виявлення та аналіз даних - розуміння того, як користувачі поводяться на сайті техпідтримки і чому саме так. Зокрема, було розглянуто різні джерела даних визначення основних завдань користувачів, і навіть труднощів, із якими стикалися на поточному сайті. У наведеній нижче таблиці наведено всі використані методи:

Звіти з юзабіліті та профілі користувача

Частіпитання Аналітика трафіку та пошуку

Організація інформації та зв'язність Структура: заголовки, рубрики, угруповання Оцінка потоків завдань, юзабіліті веб-форм Пробіли: відсутня найбільш популярна інформація

Тестування старих та нових схем навігації шляхом сортування карток (card sorting) та деревоподібних тестів (tree testing) для покращення інформаційної архітектури.
Тестування варіацій найважливіших потоків завдань для десктопних та мобільних веб-дизайнів за допомогою паперового прототипування.

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

Оцінюючи дизайн у перервах між тестуваннями, вони змогли покращити ключові сторінки за 7 версій лише через 2 тижні тестування. Розробка прототипів, включаючи тестування та остаточні ревізії, зайняла 9 тижнів.

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

Результати редизайну

Після тестування прототипу, але перед впровадженням нового дизайну, фахівці Mozilla тимчасово розмістили на домашній сторінці швидкі посилання (quicklinks) на найбільш затребуваний контент. Вони вирішили таким чином перевірити, чи це призведе до зменшення кількості нових питань на форумі.

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

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

На цьому графіку з інформаційної панелі KPI Mozilla відображено обсяг питань (синя область), що надходять, на форум техпідтримки до, під час і після 3-місячних UX-заходів (червоний прямокутник).

Забезпечення легкого доступу до найбільш затребуваної інформації призвело до моментального зниження кількості питань на форумі на 70% (приблизно з 7 000 до 2 000 питань на місяць), що дозволило фахівцям покращити якість своєї роботи. Через місяць після UX-заходів співробітники Mozilla переглянули документацію техпідтримки і зробили її доступнішою для пошуку, а безперервний аналіз даних дозволяє їм змінювати найактуальніші теми за необхідності.

Редизайн помітно збільшив показник відповідей протягом доби: кількість запитань зросла з 40-60% до 80-90%. Цей огляд за 4 місяці протягом всіх UX-заходів та впровадження початкового редизайну показує кількість запитань, що надходять на форумі (синя область) та кількість відповідей (зелена область).

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

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

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

Безперечно, інвестиції Mozilla в UX-дизайн свого сайту техпідтримки окупилися з лишком і майже відразу ж показали відчутні поліпшення. Ми сподіваємося, що цей приклад допоможе вам переконливо обґрунтувати ROI досвіду користувача та паперове прототипування для ітеративного, орієнтованого на користувача дизайну.