Мобильная версия корпоративного сайта: что проверять на телефоне до запуска

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

Что именно проверяем в мобильной версии корпоративного сайта

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

Границы задачи: сайт компании с услугами, направлениями, филиалами, редактором, формами и аналитикой обращений. Это не торговый B2B-портал, не личный кабинет и не мобильное приложение. Мы проверяем публичную часть и маршрутизацию заявки до ответственного сотрудника.

Что входит в проверку:

• ключевые страницы: услуга, направление, филиал, контакты, форма;
• навигация: меню, хлебные крошки, возврат назад;
• контент: читаемость текста, таблицы, изображения, документы;
• действия: звонок, заявка, маршрут, почта;
• техническая сторона: скорость загрузки, поведение при слабой сети, отсутствие горизонтальной прокрутки.

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

Ответственный за проверку — руководитель проекта со стороны заказчика вместе с представителем подрядчика. Технические правки вносит разработчик, контентные — редактор, маршрутизацию заявок — владелец процесса обработки обращений. Без назначенного ответственного проверка превращается в список пожеланий.

Исходные данные и ответственные до старта проверки

Прежде чем открывать сайт на телефоне, соберите входные данные. Без них проверка будет субъективной.

Что нужно подготовить:

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

Ответственные роли:

• заказчик — формулирует бизнес-сценарии и принимает результат;
• руководитель проекта — сводит проверки в единый план и следит за сроками;
• разработчик — устраняет технические дефекты;
• редактор — приводит тексты и подписи к читаемому виду;
• владелец процесса обработки — подтверждает, что заявка доходит и обрабатывается.

Важно заранее договориться, на каких устройствах проверяем. Не «на телефоне вообще», а на конкретных моделях и версиях операционных систем, которые есть у вашей аудитории. Если данных о моделях нет, возьмите несколько распространённых устройств разного размера экрана и разные браузеры. Способ проверки: откройте сайт на каждом устройстве и пройдите сценарий от входа до целевого действия.

Варианты мобильного представления и критерии выбора

Существует несколько подходов к мобильному представлению. Выбор влияет на объём работ и на то, что именно проверять.

Адаптивная вёрстка: один сайт, который перестраивается под ширину экрана. Плюс — единый контент и адреса страниц. Минус — сложнее добиться идеального вида на всех устройствах.

Отдельная мобильная версия: своя папка или поддомен с упрощённым интерфейсом. В документации 1С-Битрикс для решения «Сайт медицинской организации» описан параметр «Папка мобильной версии»: при открытии сайта с телефона вызов перенаправляется в указанную папку, а если путь пустой, перенаправления не будет. Там же упоминается «Папка мобильного приложения», внутри которой редирект на мобильную версию не срабатывает. Это подтверждает, что отдельная мобильная версия — реальный сценарий, но он требует настройки и отдельной проверки на целевом решении. Требуется проверка совместимости с текущей версией CMS.

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

Критерии выбора:

• объём контента и частота обновлений;
• наличие ресурсов на поддержку двух версий;
• требования к адресам страниц и перелинковке;
• необходимость сохранить единую аналитику;
• бюджет и сроки.

Если сайт небольшой и контент обновляется редко, адаптивная вёрстка обычно проще в поддержке. Если есть специфические мобильные сценарии, например запись или подбор филиала, отдельная версия может дать больше контроля, но потребует отдельной приёмки. Решение принимайте по критериям, а не по привычке.

Предметная последовательность действий при проверке

Проверку ведите по сценариям, а не по страницам. Так вы поймаете помехи, которые не видны при беглом осмотре.

Сценарий 1. Чтение информации об услуге. Откройте страницу услуги на телефоне. Проверьте: заголовок виден без масштабирования, основной текст читается, таблицы не вылезают за экран, изображения не перекрывают текст, кнопка действия доступна без прокрутки в самый низ. Если на странице есть документы для скачивания, проверьте, открываются ли они на телефоне.

Сценарий 2. Поиск филиала. Найдите раздел с филиалами. Проверьте: список адресов читается, телефоны кликабельны, карта не перекрывает контент, маршрут открывается в картографическом приложении. Убедитесь, что адреса реальные и совпадают с фактическими.

Сценарий 3. Звонок. Нажмите на номер телефона. Должно открыться приложение звонка с подставленным номером. Проверьте на разных устройствах: где-то номер может не распознаваться, если он оформлен нестандартно.

Сценарий 4. Отправка заявки. Заполните форму на телефоне. Проверьте: поля не перекрываются клавиатурой, подсказки понятны, обязательные поля отмечены, после отправки появляется подтверждение. Затем убедитесь, что заявка дошла до ответственного (или в указанный ящик/систему) и обработана по регламенту.

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

Каждый сценарий фиксируйте: устройство, браузер, шаг, ожидаемый результат, фактический результат. Это основа для правок и приёмки.

Матрица проверок: что и как оцениваем

Матрица помогает не потерять сценарии и заранее договориться о критериях. Если по какому-то пункту критерий не согласован, проверка превращается в спор. Лучше зафиксировать критерии до начала работ.

Учебный пример: проверка мобильной версии сайта компании

Учебный пример. Компания «Пример» имеет корпоративный сайт с услугами, направлениями и четырьмя филиалами. Условные данные: сайт на адаптивной вёрстке, формы отправляют заявки на почту отдела продаж, аналитика обращений ведётся во внешней системе. Задача — проверить мобильную версию до запуска. Интеграция с внешней системой требует уточнения условий.

Входные условия: карта страниц включает 12 услуг, 4 филиала, страницу контактов и форму заявки. Ответственные: руководитель проекта со стороны заказчика, разработчик подрядчика, редактор, владелец процесса обработки заявок. Устройства для проверки: три модели телефонов разного размера экрана, два браузера.

Действия. Проверяющий открывает страницу услуги на каждом устройстве. На одном из телефонов таблица с ценами вылезает за пределы экрана — горизонтальная прокрутка. На другом изображение перекрывает кнопку «Оставить заявку». В разделе филиалов телефон одного из адресов не кликабелен, потому что номер оформлен текстом. Форма заявки при открытии клавиатуры перекрывает поле «Комментарий». После отправки подтверждение появляется, но заявка приходит на общий ящик, а не ответственному.

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

Проверка: критерии приёмки из матрицы. Если таблица не вылезает за экран, кнопка доступна, телефон кликабелен, форма заполняется и заявка доходит до ответственного (или в согласованный канал) — сценарий принят. Учебный пример показывает, что проверка на реальных устройствах выявляет помехи, которые не видны на десктопе. Требуется верификация сценария на тестовом стенде.

Чек-лист приёмки мобильной версии

• Проверены ключевые сценарии: услуга, филиал, звонок, заявка, навигация.
• Проверка выполнена на реальных устройствах разного размера экрана и в разных браузерах.
• Текст читается без масштабирования, нет горизонтальной прокрутки.
• Таблицы и изображения не перекрывают контент и кнопки действия.
• Телефоны кликабельны и открывают приложение звонка с верным номером.
• Адреса филиалов реальные, совпадают с фактическими, маршрут открывается.
• Форма заявки заполняется, клавиатура не перекрывает поля, подтверждение появляется.
• Заявка доходит до ответственного и обрабатывается по регламенту.
• Навигация не приводит в тупик, возврат назад работает.
• Страница открывается при слабой сети, контент не пропадает.
• Все дефекты зафиксированы с указанием устройства, браузера и шага.
• Критерии приёмки согласованы с заказчиком до начала проверки.

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

Ограничения, типичные ошибки и следующий шаг

Ограничения. Проверка на нескольких устройствах не гарантирует, что сайт будет одинаково работать на всех моделях. Если у вас есть данные о популярных устройствах аудитории, используйте их. Если данных нет, это повод настроить аналитику и вернуться к проверке позже. Юридические тексты, согласия на обработку данных и требования к персональным данным проверяет профильный специалист, а не руководитель проекта.

Типичные ошибки:

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

Следующий шаг. После устранения дефектов проведите повторную проверку по тем же сценариям и устройствам. Зафиксируйте результат в чек-листе. Если сайт уже запущен, проверку можно провести на копии, чтобы не влиять на работающий ресурс. Для изменений сначала копия, резервирование, тест и план возврата (рекомендуется согласовать с заказчиком).

Если вы планируете доработку мобильного представления, полезно свериться с тем, как устроена разработка корпоративных сайтов на 1С-Битрикс и какие разделы обычно входят в структуру корпоративного сайта. Дизайн мобильных экранов стоит оценивать вместе с общим направлением, о котором подробнее в материале про дизайн корпоративного сайта.

Как проверить мобильную версию при слабой сети и на разных скоростях

Мобильный сценарий часто протекает в условиях нестабильного соединения: в лифте, на объекте, за городом. Поэтому проверка только на быстром Wi-Fi даёт неполную картину. Нужно понять, как ведёт себя страница, когда сигнал слабый, и не теряется ли при этом ключевая информация.

Что смотреть при слабой сети:

• успевает ли посетитель увидеть заголовок услуги и кнопку действия до того, как соединение прервётся;
• не пропадает ли текст, если часть изображений не загрузилась;
• остаётся ли форма заявки работоспособной, когда подгрузка идёт медленно;
• появляется ли понятное сообщение, если отправка не удалась, и можно ли повторить попытку без потери введённых данных.

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

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

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

Проверка доступности: масштабирование, контраст и работа с клавиатурой

Мобильная версия корпоративного сайта должна оставаться usable для людей с разными возможностями восприятия. Это не отдельная юридическая экспертиза, а часть предметной проверки удобства.

Что проверяем:

• можно ли увеличить текст без потери структуры: при масштабировании страница не должна расползаться и требовать горизонтальной прокрутки;
• читается ли текст на солнце: контраст подписей, кнопок и полей формы;
• достаточно ли крупные элементы нажатия, чтобы по ним можно было попасть пальцем без промаха;
• работает ли навигация с внешней клавиатуры или экранного диктофона: подписи полей и кнопок должны быть понятны вне визуального контекста.

Способ проверки: увеличьте масштаб страницы на телефоне и пройдите сценарий чтения услуги. Затем включите экранный диктофон и попробуйте заполнить форму заявки, не глядя на экран. Если поле не озвучивается или кнопка не имеет понятной подписи, это дефект, который фиксируется с указанием устройства и шага.

Развилка: если сайт использует отдельную мобильную версию, проверку доступности нужно проводить именно на ней, а не на десктопной копии. В документации 1С-Битрикс для решения «Сайт медицинской организации» описан параметр «Папка мобильной версии»: при открытии сайта с телефона вызов перенаправляется в указанную папку, а если путь пустой, перенаправления не будет. Там же упоминается «Папка мобильного приложения», внутри которой редирект на мобильную версию не срабатывает. Это значит, что при отдельной мобильной версии проверять нужно тот адрес, куда реально попадает посетитель с телефона, и убедиться, что перенаправление не уводит его на устаревшую или неполную копию на целевом решении.

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

Что делать с найденными дефектами: приоритеты и повторная проверка

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

Как распределить приоритеты:

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

Развилка по маршрутизации заявки. Если форма технически работает, но заявка приходит не тому сотруднику или теряется, это не косметика и не «потом». Такой дефект блокирует бизнес-сценарий, даже если внешне всё выглядит исправно. Ответственный — владелец процесса обработки обращений; он подтверждает, что заявка доходит и обрабатывается по регламенту.

Порядок действий после правок:

• разработчик и редактор вносят изменения на копии, а не на работающем сайте;
• перед изменениями делается резервная копия и план возврата;
• повторная проверка проводится по тем же сценариям и на тех же устройствах, что и первая;
• результат фиксируется в чек-листе с пометкой, какой дефект закрыт и на каком устройстве подтверждён.

Ограничение: повторная проверка на тех же устройствах не гарантирует, что дефект исчез на всех моделях. Если есть данные о популярных устройствах аудитории, используйте их; если данных нет, это повод настроить аналитику и вернуться к проверке позже. Юридические тексты и согласия на обработку данных проверяет профильный специалист, а не руководитель проекта.

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