Технический баг или UX-проблема: как отличить и почему важно знать

Звучит очевидно. На практике почти не работает: владельцы и руководители магазинов плохо различают эти две категории проблем, потому что симптомы у них одинаковые.

Пользователь не оформляет заказ. Конверсия падает. Корзины бросают. Со стороны бизнеса это выглядит как одна большая «проблема с сайтом», и непонятно, кому её отдавать, разработчикам или дизайнерам.

Симптом «пользователь не дошёл до оплаты» в обоих случаях — это уход с сайта. И когда вы смотрите на воронку в Метрике или GA4, вы видите одно и то же: на шаге N был такой-то процент пользователей, на шаге N+1 — гораздо меньше. Куда они делись и почему, аналитика напрямую не отвечает.

Между тем причины могут быть принципиально разными.

Возьмём типичную ситуацию: на странице оформления заказа отказ 65%. Это плохо, но что именно плохо?

Сценарий первый: страница загружается за 8 секунд на мобильном, потому что в коде неоптимизированные изображения и пять блокирующих скриптов. Половина пользователей не дожидается. Это технический баг, и его правит разработчик.

Сценарий второй: страница грузится мгновенно, но в форме 15 полей, обязательная регистрация и неочевидный выбор способа доставки. Пользователи начинают её заполнять, упираются в очередное препятствие и уходят. Это UX-проблема, и её правит дизайнер с аналитиком.

Сценарий третий: страница быстрая, форма короткая, но в моменте оформления цена в корзине неожиданно меняется из-за стоимости доставки, которую раньше нигде не показывали. Это бизнес-логика и UX одновременно — работает, как задумано, но задумано плохо.

Каждый сценарий лечится своим способом.
Если вы перепутаете и закажете UX-аудит для первого сценария, получите красивый документ с рекомендациями, который не сдвинет вашу конверсию ни на один процент, потому что страница так и продолжит грузиться 8 секунд.

Хорошая новость, для первичной диагностики вам не нужен ни специалист, ни дорогие инструменты. Достаточно несколько раз пройти по сайту с холодной головой и проверить четыре вещи.

Первое: страницы вообще открываются? Звучит смешно, но это вскрывает больше проблем, чем кажется. Проверьте: нажмите на 20−30 случайных ссылок в каталоге, в карточках, в подвале сайта. Считайте, сколько раз вы получили ошибку 404, белый экран, бесконечную загрузку, неработающий поиск, обрывающуюся корзину при добавлении третьего товара. Если таких ситуаций больше двух-трёх, у вас не проблема юзабилити, у вас проблема стабильности.

Второе: что происходит на формах? Откройте каждую форму на сайте: заявка, подписка, регистрация, оформление заказа. Заполните половину полей, нажмите «отправить». Посмотрите, что произошло: ушла заявка? пришло подтверждение? сохранились введённые данные при ошибке валидации? Если форма «съедает» ввод и не реагирует — это техничка. Если форма работает, но в ней непонятно, какое поле обязательное и почему ошибка «неверный формат» появилась без объяснений — это UX.

Третье: насколько быстро всё работает? Запустите бесплатный тест в PageSpeed Insights от Google для главной страницы, страницы категории, карточки товара и страницы оформления заказа. Обратите внимание на показатели Core Web Vitals: LCP (время до отрисовки основного контента), INP (отзывчивость на действия пользователя), CLS (визуальная стабильность). Если по любому из них показатель в красной зоне на мобильном — это технический долг, и никакой UX-аудит не вылечит его за вас.

Четвёртое: ведёт ли ваш сайт себя одинаково на разных устройствах и браузерах? Откройте магазин с iPhone, с Android, на старом ноутбуке с Firefox, на Windows-планшете. Если на одном из устройств кнопки уезжают за край экрана, текст налезает на изображения, а попап нельзя закрыть — это кросс-браузерные баги или сломанная адаптивная вёрстка. Это разработка, не дизайн.

Если по всем четырём пунктам у вас «всё нормально», значит, проблема, скорее всего, в юзабилити, и UX-аудит будет работать. Если хотя бы по двум, нет, аудит интерфейса вам пока не нужен, нужен технический специалист.

Помимо ручной проверки, есть несколько маркеров в данных, которые с большой вероятностью указывают именно на технику.

Резкие провалы по конкретным устройствам или браузерам. Если у вас в GA4 показатель отказов на условном Safari mobile 78%, а на Chrome desktop 35% — это не значит, что у вас «плохой UX для пользователей iPhone». Это значит, что на iOS что-то ломается. UX в большинстве случаев влияет на показатели плавно и пропорционально; технические баги дают ступеньки.

Аномальные паттерны на отдельных страницах. Один товар или одна категория показывает отказы 90% при средних 50% по магазину. Скорее всего, на этой странице что-то конкретное сломано — карточка не загружается, изображение битое, цена не подтягивается. Это проверяется не аудитом, а руками разработчика, который открывает консоль браузера.

Время загрузки страниц в виде «полки» в правом конце графика. Когда у вас в распределении времени загрузки большая доля сессий со временем 10+ секунд — это не «пользователи на медленном интернете», это бэкенд, который не справляется с нагрузкой в моменте, или интерфейс, который не оптимизирован.

Записи сессий в Microsoft Clarity или Hotjar с rage clicks. Это автоматически распознаваемый паттерн, когда пользователь много раз быстро кликает в одну точку — обычно по кнопке, которая визуально активна, но не реагирует. Если в записях вы видите rage clicks по элементам интерфейса — это не работает кнопка или работает с задержкой. Если rage clicks разбросаны по разным некликабельным областям — это UX, пользователь думает, что эти элементы должны быть кликабельными, а они не активны.

Microsoft Clarity, кстати, в этом смысле — мощный бесплатный инструмент, который многие магазины недооценивают. Записи сессий, тепловые карты и автоматическое распознавание rage clicks и dead clicks доступны без лимитов и без оплаты. Для первичной диагностики — какого характера у магазина проблемы, технические или интерфейсные, этого набора более чем достаточно.

Не всё чёрно-белое. Есть три категории проблем, которые находятся на стыке и в одиночку не решаются ни той, ни другой стороной.

Производительность как часть UX. Технически медленная страница это не только баг, это ещё и плохой пользовательский опыт. Условный пользователь, который ждёт загрузки карточки товара 6 секунд, не различает «у магазина перегружен бэкенд» и «магазин не уважает моё время» — для него это одно и то же. Поэтому в современных UX-аудитах производительность часто проверяется как минимум на уровне Core Web Vitals, и в рекомендациях появляется пункт «оптимизировать LCP до 2,5 секунд», который потом передаётся разработчику.

Адаптивная вёрстка. Здесь история ещё запутаннее: «кнопка уехала за экран» это баг разработки, но «на мобильном фильтры занимают всю высоту экрана и пользователю тяжело до них дотянуться» уже UX. Часто решение требует совместной работы дизайнера (новый паттерн отображения) и разработчика (новая логика поведения).

Нелогичная бизнес-логика. Когда товар можно положить в корзину, но при оформлении выясняется, что его нет в наличии. Когда после авторизации система забывает корзину. Когда в каталоге показана одна цена, а на странице товара другая.
Технически всё работает «по спецификации», но спецификация была написана без учёта реального поведения пользователя. Это правится через постановку задач разработке, но дизайнер с аналитиком должны её сначала сформулировать.

В наших проектах эти пограничные случаи мы относим в отчёт UX-аудита как «рекомендации с технической составляющей», отдельной категорией, потому что от их формулировки зависит, кто и как будет их внедрять.

Если в магазине «что-то не так с конверсией», прежде чем заказывать аудит, потратьте полдня на самодиагностику.

Пройдите вручную по основным сценариям: добавление в корзину, оформление, регистрация, поиск, использование фильтров. Зафиксируйте всё, что не сработало с первого раза или сработало странно. Запустите PageSpeed Insights по ключевым страницам. Поставьте Microsoft Clarity и посмотрите 20−30 записей сессий, этого хватит, чтобы увидеть, что вообще происходит у пользователей на сайте.

Если в этой выборке доминируют технические проблемы, отдавайте их разработке и не тратьтесь на UX-аудит сейчас. Сначала почините, потом измерьте, как изменилось поведение пользователей, и только после этого решайте, нужен ли вам аудит интерфейса.

Если технически всё работает, а конверсия всё равно низкая, значит, проблема действительно в юзабилити, и аудит даст вам конкретные ответы.

И есть ещё одна важная тонкость, о которой стоит сказать прямо: если вы не уверены, что у вас — техничка или UX, заказ комплексного UX-аудита, часто как раз и помогает разделить эти два слоя.
В рамках такого аудита проверяется в том числе техническая сторона: скорость загрузки, кросс-браузерность, корректность отслеживания, чистота данных в аналитике.
Это первая фаза, без которой все последующие выводы будут опираться на испорченную базу. Если вы попадаете в эту ситуацию, не делайте вид, что разберётесь сами, позовите кого-то с опытом, чтобы он за пару дней проанализировал поведение пользователей на сайте, проверил состояние данных в аналитике и сказал, в какую сторону копать.

Если самодиагностика показала смесь технических и интерфейсных проблем — начните с аудита, который проверит обе стороны. Экспресс-аудит даст вам понимание, где именно у магазина болит и в каком порядке это лечить, без необходимости сразу заказывать большой проект.
Обсудить экспресс-аудит →

В следующей статье мы сравним три формата, которые мы в агенстве предлагаем: чем они отличаются по глубине, срокам, результатам и для каких ситуаций каждый из них оптимален. После первых двух статей этот выбор перестаёт быть произвольным — он становится логическим следствием того, что вы уже знаете о состоянии своего магазина.