Главное за минуту
- Вёрстка собирает внешний вид страниц по макету: сетку, типографику, адаптив и состояния элементов.
- Фронтенд добавляет сценарии: валидацию формы, отправку данных, личный кабинет, фильтры и ошибки.
- Если заявка должна попасть в Битрикс24 с UTM, одной HTML-формы недостаточно — нужен фронтенд и интеграция.
- Принимайте работу не только по совпадению с макетом, но и по пути данных от посетителя до CRM.
01
Граница между HTML/CSS и логикой интерфейса
Вёрстка — это перевод утверждённого макета в структуру страницы. Специалист собирает HTML-разметку, подключает стили CSS, настраивает адаптацию под экран и воспроизводит состояния, которые уже предусмотрел дизайнер: обычная и активная кнопка, раскрытое меню, ошибка в поле, карточка товара без фотографии. Результат можно открыть в браузере, прочитать контент и пройти по ссылкам.
Фронтенд-разработка начинается там, где интерфейс должен принять решение или обменяться данными с системой. Нажатие на кнопку отправляет запрос, фильтр меняет выдачу без перезагрузки, корзина хранит состав заказа, форма показывает ошибку от сервера, а личный кабинет обновляет статус. Для этого фронтенд-разработчик использует JavaScript, работает с API, событиями и состояниями интерфейса.
Для маркетолога разница важна не названием роли, а границей ответственности. Задача «сверстать форму» означает поля и внешний вид. Задача «получать лиды в Битрикс24» включает правила проверки, защиту от повторной отправки, передачу полей, UTM-меток, обработку ошибок и тестирование в CRM. Если описать второй сценарий как обычную вёрстку, подрядчик либо оценит только экран, либо заложит риски отдельной строкой позже.
Практический ориентир
Если пользовательский клик меняет данные, получает ответ от сервера или влияет на следующий шаг воронки, это уже не только вёрстка.
02
Событие отправки формы
Именно оно связывает видимые поля сайта с проверкой данных и созданием сущности в CRM.
03
Вёрстка и фронтенд: отличие на типовых задачах
Одинаковый экран может требовать разного набора работ. Например, на лендинге есть форма с полями «Имя» и «Телефон». Вёрстка создаст поля, подписи, маску ввода и понятное сообщение об обязательности. Но правило «создать лид, назначить источник, передать рекламную кампанию и показать результат без повторной отправки» относится к фронтенду и серверной части.
Не стоит требовать от одного специалиста всё автоматически или, наоборот, дробить простую работу на лишние роли. Состав команды зависит от сценария. Статичный промо-блок по готовому макету часто делает верстальщик. Интерактивный калькулятор, каталог с динамическими фильтрами или личный кабинет требует фронтенд-разработчика. Когда данные должны записаться в 1С-Битрикс или Битрикс24, обычно подключается бэкенд-разработчик: он настраивает безопасную обработку и интеграцию.
В смете полезно разделить работу на три слоя: отображение, поведение и данные. Тогда маркетинг видит, за что платит, а разработчики не спорят, входит ли «отправить форму» в уже согласованную вёрстку.
Достаточно вёрстки
- Собрать адаптивную страницу по макету.
- Оформить статичные карточки и таблицы.
- Настроить меню, якоря и простые CSS-состояния.
- Подготовить шаблон страницы для CMS.
Нужен фронтенд
- Проверить поля до и после отправки.
- Подгрузить данные или изменить выдачу.
- Рассчитать стоимость по введённым параметрам.
- Передать форму, UTM и страницу входа в CRM.
04
Как определить роль по формулировке задачи
Слова «сделать форму» или «добавить фильтр» не помогают оценить работу. Они описывают элемент интерфейса, но не результат. До постановки задачи зафиксируйте: откуда пользователь приходит, что вводит, какое действие выполняет система, что увидит посетитель при успехе и ошибке, куда попадут данные.
Особенно внимательно нужно описывать формы в рекламных кампаниях. Если сайт принимает только телефон, а отдел продаж хочет понимать канал обращения, фронтенд должен собрать параметры из URL или cookie и передать их вместе с заявкой. Если данные очищаются при переходе между страницами либо перезаписываются пустым значением, отчёт Битрикс24 покажет неполную картину.
Техническая документация по REST-интеграциям Битрикс24 доступна в официальном справочнике API. Маркетологу не нужно писать запросы самостоятельно, но необходимо согласовать, какие поля и статусы проверять в CRM.
| Формулировка | Что входит | Кого подключать |
|---|---|---|
| Собрать блок по макету | HTML, CSS, адаптив | Верстальщик |
| Сделать умный фильтр | События, запросы, состояния | Фронтенд-разработчик |
| Передать заявку в CRM | Форма, API, поля, ошибки | Фронтенд и бэкенд |
| Показать данные клиента | Авторизация, права, API | Фронтенд и бэкенд |
05
Сценарий формы: где появляется фронтенд
Рассмотрим форму «Получить расчёт» на сайте. Посетитель пришёл из рекламы по ссылке с UTM, открыл страницу на телефоне, ввёл телефон и комментарий. Визуальная часть формы — результат вёрстки. Но полезный для бизнеса сценарий гораздо шире: номер нужно проверить, кнопку заблокировать на время запроса, сохранить рекламные параметры, отправить данные и показать честное сообщение о результате.
После нажатия фронтенд формирует запрос. Серверная часть сайта на 1С-Битрикс или отдельный обработчик проверяет данные, создаёт лид или сделку через Битрикс24 и возвращает статус. Фронтенд интерпретирует его для человека: «заявка принята» либо «не удалось отправить, попробуйте позже». Не следует выводить техническую ошибку API в интерфейс посетителя.
Проверьте и обратный маршрут. Менеджер должен открыть запись в CRM и увидеть телефон, комментарий, URL страницы, дату, источник и кампанию. Если в форме есть согласие на обработку данных, его текст и факт отправки также должны соответствовать принятому в компании процессу.
Готовое сообщение
Тема: доработка формы расчёта на сайте.
Нужно сохранить текущий дизайн формы и реализовать отправку в Битрикс24. Передавать поля: имя, телефон, email, комментарий, URL страницы, utm_source, utm_medium, utm_campaign, utm_content, utm_term.
До отправки проверять обязательные поля и формат телефона. На время запроса блокировать повторное нажатие. При успешном ответе показывать сообщение без перезагрузки; при ошибке — понятный текст и возможность повторить отправку.
Критерии приёмки: тестовая заявка создаётся в нужной сущности CRM; значения UTM совпадают с URL тестовой ссылки; повторное нажатие не создаёт дубль; ошибка интеграции фиксируется в журнале, а посетитель не видит технических деталей.
06
Чек-лист приёмки: не ограничивайтесь пиксельным совпадением
Макет может быть воспроизведён точно, но интерфейс при этом теряет заявки, ломается на мобильном экране или неверно сообщает об успехе. Поэтому приёмку лучше проводить по заранее подготовленным сценариям, а не только по скриншоту. Маркетолог проверяет путь пользователя; ответственный за CRM — результат в карточке лида или сделки; разработчик — технические журналы и ошибки.
Для проверки UTM создайте отдельную тестовую ссылку с заметными значениями, например utm_source=test_iconica и utm_campaign=frontend_check. Не используйте настоящие персональные данные: достаточно служебного телефона или почты, согласованных с командой. После теста удалите тестовую сущность либо пометьте её соответствующим тегом.
Если в проекте нужен визуальный ориентир, используйте реальные примеры реализации из портфолио ICONICA, а не вымышленные скриншоты интерфейсов или CRM.
- 1
Откройте разные экраны. Проверьте страницу на телефоне, планшете и десктопе, включая длинные значения в полях.
- 2
Проверьте обязательность. Отправьте пустую форму и неверный телефон: подсказки должны быть понятными и стоять у нужного поля.
- 3
Используйте UTM-ссылку. Перейдите по тестовому URL, заполните форму и не меняйте значения меток вручную.
- 4
Найдите запись в CRM. Сверьте поля, источник, кампанию, страницу входа и ответственного менеджера.
- 5
Сымитируйте сбой. Убедитесь, что повторная отправка доступна, а заявка не дублируется при двойном клике.
08
Ошибки в оценке, которые увеличивают бюджет
Самая частая ошибка — передать разработчику только макет и фразу «форма должна работать». У команды нет ответа, куда отправлять данные, какие поля обязательны, как обрабатывать дубли и кто подтвердит результат в CRM. В процессе появляются уточнения, дополнительные часы и риск, что готовый экран не решит задачу маркетинга.
Другая ошибка — считать любую JavaScript-анимацию фронтендом, а любую форму интеграцией. Простое раскрытие аккордеона может входить в вёрстку. Но даже визуально простая отправка формы требует продуманного сценария. Граница определяется не количеством кода, а тем, меняет ли интерфейс данные и зависит ли от ответа системы.
Третья ошибка — проверять только успешный путь. На практике посетитель ошибается в номере, закрывает страницу при медленном интернете, повторно нажимает кнопку, приходит без UTM или сталкивается с временной недоступностью CRM. Эти случаи должны быть частью задачи и приёмки.
Не обещайте «сразу в CRM» без уточнений
До оценки согласуйте сущность CRM, список полей, правила дублей, источник, ответственного, статусы и способ диагностики ошибок. Иначе цена интеграции будет предположением.
Макет утверждён; адаптив проверен; поля и обязательность согласованы; UTM передаются; тестовая заявка видна в CRM; дубль при повторном клике не создаётся; ошибки понятны пользователю; ответственный подтвердил результат
09
Какое решение принять перед стартом работ
Заказывайте вёрстку, когда нужен предсказуемый интерфейс по готовому макету и без сложных пользовательских сценариев. В техническом задании достаточно описать страницы, брейкпоинты, состояния элементов, браузеры и правила размещения в CMS. Но не подменяйте этим задачу на работающий сервис.
Подключайте фронтенд-разработку, когда интерфейс должен реагировать на действия пользователя, получать или сохранять данные, работать без перезагрузки, учитывать авторизацию либо зависеть от внешней системы. Для сайта на 1С-Битрикс отдельного внимания требуют формы, каталог, корзина, личный кабинет и связка с Битрикс24.
Перед стартом соберите маршрут: рекламная ссылка или другой вход, страница, действие пользователя, поля, ответ сайта, сущность CRM, ответственный менеджер и отчёт. Если хотя бы один этап не определён, сначала проведите короткое проектирование. Подрядчика стоит подключать, когда нужно разделить зоны фронтенда и бэкенда, оценить интеграцию или подготовить проверяемые критерии приёмки.
FAQ
Частые вопросы
Может ли один специалист делать и вёрстку, и фронтенд?
Да, на небольших задачах это распространённо. Важно заранее подтвердить, что в оценку входят не только страницы, но и логика, запросы, обработка ошибок и тестирование.
Нужен ли фронтенд, если форма встроена штатным компонентом?
Зависит от требований. Стандартного компонента может быть достаточно, но доработка проверки, UTM, поведения после отправки или аналитики обычно требует фронтенд-работ.
Кто отвечает за создание лида в Битрикс24?
Фронтенд отправляет данные, а безопасное создание записи чаще реализует бэкенд или готовый интеграционный механизм. Ответственность фиксируют в задаче.
Что важнее проверить после запуска формы?
Не только сообщение на сайте: откройте тестовую запись в CRM и сверяйте поля, UTM, страницу входа, источник, отсутствие дублей и назначенного ответственного.
Входит ли скорость сайта во фронтенд-разработку?
Частично: фронтенд влияет на объём скриптов, загрузку компонентов и работу интерфейса. Но оптимизация сервера, кеширования и базы данных требует отдельной технической оценки.
