Аудит юзабіліті сайту на 1С-Битрикс: де губляться заявки
Аудит юзабіліті сайту — це не косметичний розбір верстки, а розбір шляху клієнта крок за кроком: від входу з пошуку до підтвердження замовлення. Ми дивимося не «подобається чи ні», а в якому місці людина зупиняється і закриває сторінку.
Кожен крок заміряємо часткою покинутих дій — тоді суперечка про смаки замінюється списком точок втрати конверсії зі зрозумілими пріоритетами.
Перша група таких точок зазвичай лежить в оформленні. Форма на дванадцять полів там, де достатньо трьох, обов'язкова реєстрація до розрахунку доставки, вартість і терміни, сховані на окремій сторінці, — це типові бар'єри в оформленні замовлення.
Перевіряємо їх на реальних сценаріях: покупка в одну дію, повторне замовлення, замовлення без дзвінка менеджера.
Друга група — навігація каталогом. Коли позицій тисячі, фільтри перетинаються так, що частина товарів недосяжна за два кроки, а хлібні крихти не повертають до потрібної добірки.
Юзабіліті-аудит інтернет-магазину окремо рахує глибину: скільки дій до цільового товару і скільки тупикових гілок у меню.
Третя група — відгук інтерфейсу. Повільний фільтр, кошик із затримкою перерахунку, спливне вікно поверх кнопки «Оформити» — користувач читає це як поломку і йде.
На 1С-Битрикс таке частіше наслідок налаштувань кешування і перевантажених шаблонів, а не самої платформи: правиться точково, без переписування сайту.
Далі зводимо знахідки в карту: крок, частка втрат, причина, що змінюємо. За нею видно, що лагодити першим, — цим і займаються наші інженери.
Що змінюється після усунення бар'єрів на шляху клієнта
Перший вимірюваний зсув — скорочення шляху до заявки. Рахуємо не «стало зручніше», а скільки кроків і обов'язкових полів відділяє відвідувача від надсилання форми: у типових шаблонах 1С-Битрикс їх сім-вісім, після правок залишається три-чотири. Частка тих, хто дійшов до кінця форми, зростає одразу, без змін у рекламних каналах і цінах.
Другий зріз — покинуті кошики. Клієнт іде частіше не через ціну, а тому що не бачить умов доставки, термінів і способів оплати до моменту оформлення.
Піднімаємо ці блоки вище за кнопку, показуємо вартість і терміни до оплати, переписуємо тексти помилок у полях — кошик перестає бути глухим кутом, і втрати на кроці оплати помітно скорочуються.
Третій ефект — навантаження на службу підтримки. Коли статус замовлення, етап погодження і причина відмови видні в особистому кабінеті, клієнт не телефонує з питанням «що з моїм замовленням».
Зрозумілі підказки в полях знімають типові сумніви до звернення, потік однотипних листів падає, а вивільнений час іде на складні випадки.
Окремо дивимося повторні звернення клієнтів. Якщо шлях до заявки передбачуваний, а історія замовлень і документів лежить у кабінеті, людина повертається за наступною послугою в той самий інтерфейс, а не шукає заново, де залишити запит.
Усі правки перевіряємо на одному зрізі аналітики до і після — так зростання конверсії після правок юзабіліті видно окремо від сезонних коливань.
Формати розбору: експрес, повний цикл, постійний контроль
Режим розбору обирають за двома параметрами: наскільки глибоко потрібно копати і як швидко потрібен результат. Заміри знімаємо до старту робіт — інакше після правок не зрозуміти, що саме дало ефект.
Порівняння режимів
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Експрес-розбір юзабіліті | Потрібно швидко зняти явні втрати на ключових сценаріях | Не покаже причин у глибині воронки, гіпотези не перевіряються на людях |
| Повний цикл юзабіліті-аудиту | Планується переробка розділів і логіки замовлення | Потребує доступу до аналітики й участі власника продукту, триває довше |
| Розбір з тестуванням на користувачах | Є спірні гіпотези, рішення потрібне до релізу | Потрібно зібрати респондентів потрібного сегмента, термін залежить від них |
| Постійний контроль інтерфейсу | Сайт живе: релізи, акції, нові форми | Працює як регламент з регулярними замірами, а не разова акція |
Почати можна з експрес-розбору: він показує, де втрати є зараз, і дає підставу вирішувати, чи потрібен повний цикл. План і склад робіт фіксуємо до старту, тому обсяг не розповзається по ходу.
Як проходить робота: від зняття метрик до перевірки правок
Аудит юзабіліті сайту на 1С-Битрикс починається не з експертних думок, а зі зняття метрик: дивимося, на яких кроках відвідувач іде, і звіряємо це із записами поведінки користувачів.
Так отримуємо список точок втрат з фактів, а не із загальних міркувань, і вже під них формулюємо гіпотези правок.
- Зняття метрик. Фіксуємо поточні показники воронки: частку тих, хто дійшов до замовлення, глибину перегляду, джерела. Це база для порівняння — без неї ефект правок нема чим довести.
- Запис поведінки користувачів. Дивимося, де завмирає курсор, які поля форми покидають, які фільтри не помічають. Записи показують момент, у якому людина здалася, — у цифрах його не видно.
- Пріоритизація правок. Розкладаємо знахідки за впливом на цільову дію і трудомісткістю впровадження. Першими беремо те, що знімає втрати на наймасовіших сценаріях.
- Перевірка гіпотез на прототипі. Збираємо робочу версію спірного блока і даємо користувачеві завдання: чи дійшов він до мети, скільки зробив зайвих кроків. Слабкі рішення відсікаємо до розробки.
- Впровадження. Правки вносимо частинами, зберігаючи попередні версії шаблонів і можливість відкату: повна підміна інтерфейсу на працюючому сайті надто ризикована.
- Контроль після релізу. Через два тижні і місяць після виходу знімаємо ті самі метрики. Якщо показники не зрушили, повертаємося до гіпотези, а не залишаємо правку «про всяк випадок».
Що залишається у замовника: карти, звіти, регламенти
Інженерний результат аудиту — не презентація, а набір артефактів, які залишаються в репозиторії та документації проєкту. Через пів року за ними видно, чому блок влаштований саме так, і наступна правка не ламає знайдене.
- Карта шляху користувача за кожним ключовим сценарієм: від входу з пошуку до надсилання форми або оформлення замовлення, з кроками, де відвідувач іде.
- Звіт за точками втрат з пріоритетами: гіпотеза, очікуваний ефект, складність правки і спосіб перевірки — від валідації полів до порядку блоків на мобільному.
- Перелік правок за шаблонами з прив'язкою до адрес сторінок: які компоненти й правила виведення змінюємо, щоб правка не поїхала на сусідніх розділах.
- Макети правок для ключових екранів: стан до і після, поведінка полів, тексти помилок і підказок.
- Регламент перевірки релізу: список перевірок перед викладкою — сценарії, форми, цілі аналітики, поведінка кошика й авторизації.
- Документація з інтерфейсу: карта шаблонів, призначення кастомних полів і налаштувань, точки обміну з обліковою системою.
- Правила внесення змін: хто погоджує правку, у якій гілці вона живе і що перевіряється перед публікацією.
З цим набором команда замовника вносить зміни сама або віддає їх нам — в обох випадках не потрібно заново з'ясовувати, як влаштований сценарій і де він ламається.
Кейс: частка завершених замовлень і час до заявки
Що було до правок
Магазин на 1С-Битрикс зі зростаючим трафіком: частка завершених замовлень трималася близько чверті кошиків, а оформлення займало в середньому 4 хвилини 20 секунд.
Аудит воронки виявив три вузькі місця — обов'язкова реєстрація до вибору доставки, ручне введення адреси і форма оплати, яка повідомляла про помилку без зазначення проблемного поля. Підтримка отримувала понад 300 звернень на місяць, дві третини з них — «замовлення не проходить».
Що змінили і що стало
Оформлення скоротили з п'яти кроків до двох: реєстрацію перенесено в кінець і вона підтягується за номером телефону, адреса визначається за індексом, а поля з помилкою підсвічуються разом із причиною.
Окремим етапом переписали тексти кнопок і підказок — абстрактне «Продовжити» замінено на конкретну дію, статус замовлення виведено на перший екран.
Після правок частка завершених замовлень зросла з 24% до 41%, час оформлення скоротився до 1 хвилини 40 секунд, а звернень у підтримку щодо оформлення стало менше на дві третини.
Окремо пішов клас повторів: раніше 12% замовлень створювалися двічі через повторне надсилання форми, тепер дублів практично немає.
Заміри знімали на порівнянних періодах і одному джерелі трафіку, щоб не сплутати ефект правок із сезонністю.
Чим юзабіліті відрізняється від веб-аналітики
Аналітика відповідає на питання «де»: скільки людей дійшло до кошика, на якому кроці оформлення відвалилися, як змінилася частка відмов після правок. Це кількісний шар — він надійно показує масштаб втрати і її місце у воронці, але мовчить про причину.
Юзабіліті-розбір відповідає на «чому»: людина не знаходить поле, не розуміє формулювання умови, сумнівається в терміні доставки і йде до того, як система зафіксувала невдачу. Лічильник бачить факт виходу, але не бачить сумніву, який йому передував.
Спостереження й опитування дають різне. Опитування фіксує, що людина думає про свою поведінку, і часто розходиться з реальністю: вона скаже, що не знайшла кнопку, хоча тричі по ній промахнулася повз ціль.
Спостереження показує фактичний маршрут — куди вона дивиться, де завмирає, що намагається натиснути і чому покидає.
Питання «чи потрібен розбір, якщо є веб-аналітика» вирішується просто. Аналітика звужує пошук до конкретного кроку, розбір пояснює, чому крок не проходиться. Кількісні дані без якісних дають список проблем без пріоритетів, а спостереження без цифр — набір окремих думок.
Працює зв'язка: цифри вказують точку втрати, спостереження й опитування пояснюють рішення користувача.
Часті сумніви: форми, кеш, шаблони, інтеграції
Перед стартом зазвичай виринають одні й ті самі технічні питання: що потрібно від замовника, чи можна працювати на копії, чи не зачеплять правки обмін з обліковою системою. Відповідаємо до початку робіт, щоб розбір ішов без ризику для бойового контуру.
Які доступи потрібні і чи можна обійтися копією?
Для аудиту достатньо копії сайту на окремому контурі: знімаємо базу і файли шаблону, розгортаємо локально і працюємо там. Доступ до адмінки потрібен, щоб перевірити налаштування форм, правила кешування і реальні сценарії замовлення.
Бойовий контур не чіпаємо до погодження правок — обмін з обліковою системою продовжує працювати у звичайному режимі.
Чи не зламають правки обмін з обліковою системою?
Правки в шаблонах, верстці й скриптах форм обмін не зачіпають — вони живуть окремо від обробників вивантаження.
Якщо правка стосується місць, які передають замовлення в облікову систему, спочатку проганяємо сценарій на копії з тестовим вивантаженням: звіряємо склад полів, логи обміну і поведінку при повторному надсиланні. На бойовий переносимо лише після того, як склад даних збігся.
Чому після правки видно старий варіант сторінки?
Частина сторінок збирається з кешу, тому зміни можуть не відображатися одразу. Перед викладкою фіксуємо, які правила кешування й компоненти зачеплені, і чистимо адресно за розділами, а не весь сайт — інакше зросте навантаження.
Після цього перевіряємо форми й оформлення замовлення цілком: від додавання товару до підтвердження, у різних браузерах.
Обговоримо задачу: що покажемо і в якому вигляді
Розмова починається з вашої задачі, а не з шаблонного переліку послуг. Щоб повернутися з предметною оцінкою, достатньо доступу до аналітики, списку сценаріїв, де за вашими спостереженнями губляться заявки, і короткого опису того, що вже пробували змінювати в інтерфейсі.
Цього вистачає, щоб обговорити задачу з юзабіліті предметно і назвати реальні терміни розбору, а не усереднені.
Що покажемо на зустрічі і в якому вигляді повернемося з планом:
- Карту точок втрати конверсії: де саме у воронці йде користувач — за кроками оформлення заявки, формами, сторінками каталогу і кошиком.
- Розбір користувацьких шляхів на живому трафіку і записах сесій, із зазначенням, який крок ламає сценарій і на якому екрані це відбувається.
- Оцінку термінів розбору: скільки часу займе кожен етап і від яких даних залежить, щоб ви могли спланувати роботи.
- План правок після розбору — з пріоритетами за впливом на конверсію і з поділом на швидкі зміни та переробку шаблонів.
- Склад робіт з інтерфейсу: які компоненти й форми зачіпаємо, що робимо на боці шаблонів, а що на боці логіки.
- Набір метрик до і після правок, щоб ефект вимірювався, а не обговорювався на словах.
Опишіть задачу у зручному вигляді — надішліть посилання на сайт і в двох-трьох абзацах розкажіть, що не влаштовує. Повернемося з оцінкою і планом робіт: що робимо першим, що можна відкласти і який результат побачите на кожному кроці.