Аудит лицевой части сайта: как проверить верстку и функции, не будучи дизайнером
Почему «красиво» — не оценка
Сайт открылся, картинки на месте, шрифт читается — и первый импульс: работа принята. Но именно в этот момент легко пропустить то, что обнаружится позже: через месяц, когда менеджер добавит новый материал с длинным заголовком, или когда клиент попробует оставить заявку с телефона.
Внешний вид сайта — это только верхний слой. Под ним верстка: логика, по которой блоки держат форму при любом контенте, на любом устройстве, в любом браузере. Проверить её без навыков разработчика вполне реально — нужна правильная методика и понимание того, что именно смотреть.
Эта статья — о том, как руководитель или менеджер проекта принимает создание сайта у подрядчика: без технического бэкграунда, но со структурированным взглядом на результат.
Верстка под давлением контента
Самый частый источник проблем — верстка, сделанная под конкретный демонстрационный контент. Подрядчик собирает демо на коротких заглушках: «Название услуги», «Описание», «Категория». В этих условиях всё выглядит безупречно. Реальный сайт устроен иначе: заголовки разной длины, описания на три абзаца, изображения в разных пропорциях. При разработке интернет-магазина к этому добавляются артикулы с дефисами и длинные технические характеристики. Именно здесь хрупкая сетка начинает трещать.
Пока в блоке три слова, всё выглядит идеально. Стоит добавить реальный текст — и содержимое вылезает за границу блока, кнопка съезжает, а нужный элемент оказывается там, где его не ждут. Это называют «хрупкой» версткой: она держит форму только при заранее подобранных данных.
Тест на переполнение. Зайдите в административную панель UMI.CMS и отредактируйте несколько блоков: вставьте заголовок длиннее обычного в два-три раза, добавьте абзац туда, где стоял один. Затем откройте страницу на сайте и посмотрите, что произошло. Текст должен либо переноситься внутри контейнера, либо аккуратно обрезаться — но ни в коем случае не выходить за его границы и не перекрывать соседние элементы.
Тест на масштабирование. Нажмите Ctrl+«+» несколько раз подряд, увеличив масштаб страницы до 125–150%. Меню не должно разваливаться, тексты — наползать друг на друга, кнопки — смещаться за пределы своих контейнеров. Это тест, который большинство заказчиков никогда не проводят, хотя часть аудитории постоянно работает с увеличенным масштабом из-за настроек доступности.
Тест через Edit-in-Place. UMI.CMS позволяет редактировать контент прямо на странице — достаточно нажать F2, находясь на сайте. Замените короткий заголовок на длинный, поменяйте картинку в блоке на изображение с другими пропорциями. Если после этого макет «рассыпался» — верстка выполнена жёстко: она привязана к конкретным символам и размерам, а не к логике контента. Такой сайт будет «ломаться» каждый раз при обновлении.
Что проверять в этом блоке:
- переполнение текстом в карточках и текстовых блоках;
- поведение сетки при масштабировании браузера до 125% и 150%;
- стабильность макета после правки через встроенный редактор UMI.CMS;
- поведение блоков с изображениями при замене картинки на нестандартный формат.
Отдельного внимания заслуживают «залипшие» элементы — фиксированные хедеры, всплывающие чаты, кнопки обратного звонка. При прокрутке они остаются на экране, и в норме это удобно. Но если такой элемент перекрывает форму или кнопку целевого действия — это не декоративная проблема, это прямые потери. Проверьте каждую страницу с длинным контентом: прокрутите её до конца и убедитесь, что фиксированные элементы не закрывают ничего важного на любом этапе скроллинга.
Мобильность: правило большого пальца
Адаптивность давно перестала быть дополнительной опцией. Вопрос не в том, есть ли мобильная версия, а в том, насколько ею можно пользоваться. Разработчики иногда сжимают десктопную версию до размеров экрана смартфона — технически сайт «адаптивный», но работать с ним на телефоне неудобно.
Проверяйте мобильную версию не через DevTools в браузере, а с реального смартфона. Лучше двух: на iOS и Android, с разными размерами экрана. Ключевой критерий — правило большого пальца: все кнопки и ссылки должны нажиматься одним пальцем без риска попасть в соседний элемент. Минимально комфортный размер касаемой зоны — около 44×44 пикселей. Это не пиксельное задание подрядчику, а практический ориентир при проверке.
Что исчезает в мобильной версии
Конверсионные элементы — кнопки «Купить», «Заказать», «Позвонить», форма обратной связи, номер телефона — должны присутствовать в мобильной версии так же, как в десктопной. На практике часть блоков скрывается в мобильной теме «чтобы не загромождать», и именно там нередко оказывается главный призыв к действию. Отдельно проверьте онлайн-чат: некоторые виджеты на мобильных разворачиваются на весь экран и перекрывают контент, не оставляя возможности закрыть окно.
Таблицы, прайс-листы и сложные графики — отдельная история. Широкая таблица на узком экране или обрезается, или уходит за границу, вынуждая скроллить всю страницу вбок. Качественное решение — трансформация структуры таблицы в вертикальную или хотя бы горизонтальная прокрутка внутри блока с таблицей. Если ни того, ни другого нет — задача не закрыта.
Интерактивность на touch-экране
Слайдеры и галереи должны листаться свайпом. Выпадающие меню — открываться по тапу, а не по наведению (hover на мобильных не работает). Если иконка выглядит как кнопка, она должна быть кнопкой — кликабельной с чётким откликом. Проверьте всё это последовательно, сценарием реального пользователя: зашёл на главную, выбрал раздел, открыл нужную страницу, заполнил форму.
Именно такой сценарий выявляет скрытые разрывы в пользовательском пути. Бывает, что десктопная версия проходится без единой запинки, а в мобильной на третьем шаге обнаруживается, что кнопка подтверждения не скроллится в зону видимости из-за фиксированного баннера внизу экрана. Без сквозного теста на реальном устройстве этого не увидеть.
Функции: аудит состояния и отклика
Самая распространённая ошибка при приёмке — проверять наличие элементов, а не их поведение. Кнопка есть? Есть. Форма стоит? Стоит. Принято. Но работает ли это всё так, как ожидает посетитель?
Состояния элементов
У каждого интерактивного элемента есть несколько состояний: обычное, при наведении (hover), при нажатии и в момент ожидания ответа. Все они должны быть визуально различимы.
Наведите курсор на кнопку или ссылку — она должна как-то измениться: цвет, тень, подчёркивание. Это hover-эффект, и его отсутствие означает, что пользователь не понимает, кликабелен ли элемент. Нажмите кнопку «Отправить» в форме — если страница замирает на несколько секунд без какого-либо индикатора загрузки, это ошибка. Отсутствие лоадера создаёт ощущение, что сайт завис, и пользователь нажмёт снова — или закроет вкладку.
Особого внимания заслуживает состояние ошибки. Отправьте форму с намеренно пустым обязательным полем или с некорректным адресом email. Качественная реализация подсветит проблемное поле прямо в интерфейсе, без перезагрузки страницы. Если форма перезагружается и стирает всё введённое — это устаревший подход, создающий лишнее трение. Особенно болезненно это проявляется в многошаговых формах: пользователь заполнил три экрана данных, допустил опечатку в номере телефона — и оказался в начале.
«Мёртвые» элементы
Проверьте все элементы, которые выглядят интерактивными: иконки со стрелками, подчёркнутые слова, блоки с рамкой или тенью. Всё, что визуально намекает на кликабельность, должно на неё реагировать. Декоративные элементы в стиле кнопок — распространённая проблема шаблонной верстки.
Отдельно — слайдеры и аккордеоны. Прокрутите слайдер до последнего слайда: что происходит дальше? Он должен либо зациклиться, либо заблокировать кнопку «вперёд». Раскройте все пункты аккордеона: тексты не должны перекрывать друг друга или выходить за пределы своих блоков.
Список признаков качественной реализации форм:
- поля подсвечиваются при ошибке ввода без перезагрузки страницы;
- после успешной отправки появляется явное подтверждение — текст или модальное окно;
- кнопка отправки блокируется на время обработки, чтобы исключить двойную отправку;
- маска ввода для телефона подставляется автоматически и не мешает редактированию.
Поведение сценариев с формами и действиями
Для сайтов с многошаговыми формами — будь то корзина запись на услугу или заявка на расчёт — отдельного внимания заслуживает весь путь от первого шага до подтверждения. Если пользователь допустил ошибку на последнем шаге, он должен вернуться к нему же, а не к самому началу. Если форма сбрасывается целиком — это потеря части обращений, и подрядчик обязан закрыть это до сдачи проекта.
Для магазинов добавляется проверка корзины интернет-магазина на CMS: счётчик товаров должен обновляться без перезагрузки страницы, итоговая сумма — пересчитываться мгновенно при изменении количества. Отдельно стоит пройти сценарий «брошенная корзина»: добавьте товар, закройте вкладку, откройте сайт заново. Товар должен остаться в корзине — иначе часть незавершённых покупок будет теряться автоматически.
Красные флаги: когда акт не подписывают
Итоговый критерий приёмки — не «нравится / не нравится», а соответствие конкретным стандартам. Ниже — ситуации, при которых работу возвращают на доработку вне зависимости от того, как выглядит сайт в презентационном режиме.
Верстка разрушается при реальном контенте. Если добавление длинного заголовка или объёмного описания ломает блок — сайт не готов к эксплуатации. Контент всегда разнообразен, и верстка обязана это учитывать.
Формы не дают визуальной обратной связи. Отсутствие подсветки ошибок и индикатора отправки — это не мелочь. Для сайта с реальными заявками это означает потерянные обращения и дублирующиеся заявки из-за повторных нажатий.
Конверсионные элементы исчезают на мобильных. Кнопка целевого действия или номер телефона, скрытые в мобильной версии, — прямой ущерб для бизнеса, не дефект дизайна.
Hover-эффекты отсутствуют. Кнопки без визуального отклика при наведении — признак незавершённой верстки. Пользователь теряет ориентиры в интерфейсе.
EIP ломает макет. Если правка текста через встроенный редактор UMI.CMS разрушает дизайн блока — сайт нельзя нормально обслуживать. Это критичная несовместимость верстки с платформой.
Элементы перекрываются на мобильных. Фиксированный хедер, перекрывающий форму, или кнопки, наползающие друг на друга при уменьшении экрана — блокирующие ошибки.
Интерактивные элементы не реагируют на touch. Слайдеры без свайпа, меню без тапа, иконки-обманки — это вопрос работоспособности сайта на большинстве современных устройств.
Дополнительные сценарии для проверки перед подписанием акта:
- откройте сайт в трёх браузерах (Chrome, Safari, Firefox) и сравните отображение ключевых блоков;
- проверьте страницу с максимально заполненным контентом — длинной статьёй, подробным описанием услуги, расширенной карточкой;
- пройдите весь целевой сценарий на смартфоне от первого экрана до финального действия.
Итого
Эта методика подходит руководителю или менеджеру, принимающему сайт у подрядчика: она не требует знания кода и занимает полтора-два часа при системном подходе. Она не заменяет технический аудит, но позволяет зафиксировать критичные дефекты до подписания акта, пока есть рычаги для исправления.
Если хотите проверить, как ведёт себя UMI.CMS при реальном редактировании, — демо-версия платформы доступна на demo.umi-cms.ru. Там можно протестировать режим EIP и посмотреть, как система реагирует на правки контента в разных типах блоков.
