Редакция DDRW ·

Приёмка сайта: что проверить перед публикацией

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

Стеклянная панель сайта с галочкой и карточками проверок перед запуском

Проверяйте готовую версию по сценариям

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

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

Отправьте настоящее проверочное обращение

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

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

Прочитайте содержание как новый посетитель

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

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

Пройдите сайт на телефоне и с клавиатуры

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

В первичных проверках W3C WAI отдельно рассматриваются клавиатурная навигация, видимый фокус, подписи полей и ошибки. Пройдите основные сценарии клавишами Tab, Shift+Tab и Enter. Это полезная ручная проверка, но она не заменяет полную оценку доступности. Автоматический отчёт тоже следует читать вместе с наблюдениями человека: число найденных ошибок само по себе не показывает, удобно ли завершать задачу.

Дайте редактору выполнить рабочую задачу

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

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

Записывайте замечание так, чтобы его можно было повторить

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

Рекомендуем разделить замечания на блокирующие запуск, важные исправления и улучшения следующей версии. Неработающая отправка заявки относится к первой группе; новое пожелание к анимации обычно требует отдельного обсуждения. Приоритет определяется влиянием на согласованный сценарий, а не размером элемента на экране.

Перед решением о запуске проверьте:

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

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

Услуги и проекты по теме

Обсудим вашу задачу

Пришлите описание продукта, текущий сайт или список вопросов. Уточним состав работ и предложим следующий шаг для оценки проекта.

Связаться с DDRW
Все материалы