Сайт есть, а заявки непонятные: семь проверок перед редизайном
Когда заявок с сайта мало или в них не хватает данных, первым решением часто становится редизайн. Но новый цвет кнопки не исправит непонятное предложение, сломанную форму или ситуацию, когда человек не видит подтверждения после отправки. Прежде чем заказывать большой проект, пройдите путь посетителя от первого экрана до результата формы.
Этот разбор касается того, что происходит на сайте до и во время отправки заявки. Работа менеджера после получения обращения — отдельная задача. Проверки ниже можно провести на существующем сайте и записать конкретные дефекты для разработчика, дизайнера или редактора.
1. Проверьте, понятно ли предложение без знакомства с компанией
Откройте важную страницу в приватном окне и ответьте на три вопроса: что здесь предлагают, кому это подходит и какой следующий шаг доступен? Не ищите ответы в разделе «О нас». Посетитель может прийти сразу на страницу услуги из поиска или по ссылке.
Фразы «комплексные решения» и «индивидуальный подход» не объясняют предмет работы. Конкретнее: «Разрабатываем личные кабинеты для B2B-клиентов» и ниже — какие задачи можно обсудить, какие исходные данные нужны и как связаться. Не обещайте сроки, цену или результат, если они определяются только после разбора задачи.
Запишите в таблицу URL, ожидаемую аудиторию, формулировку предложения и место основного действия. Если для одной страницы пришлось написать несколько несовместимых ответов, сначала уточните структуру предложения, а потом меняйте оформление.
2. Пройдите путь до действия с телефона
Посмотрите страницу на обычном смартфоне, а не только в уменьшенном окне дизайнера. Можно ли без увеличения текста прочитать условия, открыть меню, увидеть контакт и нажать основную кнопку? Не перекрывают ли её баннер, всплывающее окно или закреплённая панель?
Для этого этапа полезен простой сценарий: «Я впервые попал на страницу услуги; хочу оставить вопрос и понять, что произойдёт дальше». Отмечайте не субъективное «некрасиво», а препятствие: не видно действия, ссылка ведёт не туда, поле закрывает клавиатура, текст обрезан. Список таких наблюдений уже можно отдавать в работу.
3. Уберите неопределённость из формы
У каждого поля должна быть понятная подпись. Если нужно описание задачи, подскажите, что именно написать: цель, текущий процесс, желаемый результат. Не просите лишние сведения «на всякий случай» до первого разговора. Для проекта, где нужен подробный бриф, можно дать его после первичного контакта.
Проверьте несколько типичных ошибок на собственных тестовых данных: пустое обязательное поле, неверный формат контакта, слишком длинный текст. WCAG 2.2 требует описывать обнаруженную ошибку текстом и указывать проблемное поле; отдельный критерий касается подписей и инструкций. Красная рамка без объяснения не даёт человеку понять, как завершить отправку.
4. Убедитесь, что отправка действительно завершилась
После нажатия на кнопку человеку нужен однозначный ответ: заявка принята или нет. Если сайт только очистил поля, посетитель может отправить её ещё раз или уйти, решив, что форма не работает. Если произошла ошибка, её нельзя маскировать сообщением об успехе.
Пройдите два сценария: успешную отправку тестовой заявки и контролируемую ошибку в поле. При успехе покажите, что обращение принято и чего ждать дальше, не обещая срок ответа, который команда не согласовала. Запишите дату теста, страницу и результат. Проверку доставки сообщения ответственному сотруднику проводите отдельно — это уже следующий участок пути заявки.
5. Проверьте ссылки и контакты как посетитель
На страницах услуг откройте все основные кнопки и контактные ссылки. Убедитесь, что они ведут на нужную форму, актуальный номер, почту или мессенджер, а не на старый проект и не на пустую страницу. Особенно легко пропустить мобильные кнопки и ссылки в подвале сайта.
Сделайте короткий список: страница → элемент → ожидаемое назначение → фактический результат. Такая проверка не требует полной переделки сайта, но даёт задачи, которые можно исправить и затем перепроверить по тем же пунктам.
6. Измерьте скорость без магии одного балла
PageSpeed Insights показывает диагностику для мобильной и настольной версии и, когда данных достаточно, опыт реальных пользователей. Среди Core Web Vitals — загрузка основного содержимого (LCP), отклик на действие (INP) и устойчивость расположения элементов (CLS). Если полевых данных для конкретной страницы нет, это не означает нулевую посещаемость или хорошую скорость: может не хватать выборки.
Проверяйте прежде всего страницы, с которых начинается обращение. Сравните отчёт с собственным опытом на телефоне: видно ли предложение до тяжёлой анимации, не прыгает ли кнопка во время загрузки, реагирует ли форма на ввод. Не объявляйте редизайн решением любой проблемы скорости: иногда нужно исправить отдельное изображение, скрипт или способ загрузки.
7. Отделите показ страницы от полученной заявки
Просмотр страницы, клик по кнопке и успешная отправка формы — разные события. Если считать их одним числом, невозможно понять, где именно возникла проблема. Для сайта с настроенной аналитикой проверьте, фиксируется ли завершённая отправка и не считается ли она дважды при обновлении страницы. В документации Google Analytics для этого предусмотрено рекомендованное событие generate_lead; его наличие в отчёте само по себе ещё не доказывает, что сообщение дошло до команды.
Не называйте каждый клик лидом. Если учёт пока не настроен, начните с ручной проверки формы и фактически полученных тестовых сообщений. Затем согласуйте с разработчиком точку, в которой событие действительно означает успешную отправку.
Как решить, нужен ли редизайн
Сведите результаты в один список и разделите задачи по причине:
Предложение неясно, но путь и форма работают → перепишите заголовок, условия и подписи; форма или контактная ссылка не работает → исправьте дефект и повторите тест; на телефоне невозможно пройти основной сценарий → переработайте проблемный экран или поток; страницы дублируют друг друга, услуги смешаны → пересоберите структуру сайта; не хватает измерения результата → настройте и проверьте событие успешной отправки.
Большой редизайн оправдан, когда отдельные исправления не решают проблему структуры, сценариев или технической основы. Чтобы принять решение, достаточно короткого документа: страницы, факты проверки, ожидаемый результат, приоритет и способ повторной проверки. Так у проекта появляется задача, которую можно оценить, а не просьба «сделать современнее».
House of Jarvis разрабатывает лендинги, корпоративные сайты и личные кабинеты под согласованную задачу. Если хочешь обсудить сайт, напиши Сергею Смирнову, какая страница вызывает вопросы и что посетитель должен на ней сделать. Состав, сроки и стоимость разработки обсуждаются отдельно. Бесплатное базовое внедрение относится только к MetaJarvis CRM; подписка, интеграции и сопровождение обсуждаются отдельно. CRM можно открыть в Telegram.