Подготовьте основание для проверки
Перед демонстрацией соберите согласованные требования, список страниц и важные сценарии. Для каждого запишите ожидаемый результат простыми словами. Например, в условном проекте посетитель выбирает услугу, отправляет форму и видит подтверждение, а менеджер находит обращение в журнале с названием выбранной услуги. Отделите проверку выполненного задания от новых идей. Если при просмотре захотелось добавить калькулятор, это не обязательно ошибка реализации. Но неработающая согласованная форма — несоответствие. Такой подход помогает обсуждать замечания предметно. Для каждой проверки сохраняйте результат, дату и версию сайта, чтобы после исправлений не спорить о том, что именно было проверено.
Пройдите путь клиента до получения обращения
Проверяйте основной сценарий целиком на тестовых данных. Недостаточно увидеть сообщение «отправлено»: нужно найти запись там, где с ней будет работать сотрудник. Сравните телефон, выбранную услугу и комментарий. Если есть отдельное уведомление, проверьте и его, понимая, где хранится само обращение. Попробуйте пустые обязательные поля, неверный формат и повторное нажатие кнопки. Ожидаемое поведение согласуйте заранее: понятная ошибка, сохранение введённого текста или защита от дублирования. Для внешних сервисов попросите продемонстрировать предусмотренный сценарий недоступности. Важно знать, как команда обнаружит проблему и сможет продолжить работу, если передача данных не завершилась.
Проверьте телефон, клавиатуру и читаемость
Откройте основные страницы на согласованных устройствах. Посмотрите, не перекрывает ли меню форму, видны ли подписи кнопок, удобно ли читать условия. Проверьте длинные названия и реальные изображения: короткий демонстрационный текст может скрывать проблемы размещения. Отдельно пройдите ключевой путь с клавиатуры и увеличьте текст. Ресурс W3C WAI Easy Checks предлагает первичные проверки доступности, включая клавиатуру, формы и читаемость, но подчёркивает, что они не заменяют полноценную оценку. Поэтому не считайте один успешный просмотр доказательством полной доступности. Если в требованиях предусмотрена углублённая проверка, запросите её отдельный результат и список оставшихся ограничений.
Сверьте содержание и языковые версии
Проверьте контакты, состав услуг, названия организации и все утверждения, которые влияют на решение клиента. Удалите демонстрационные отзывы и неподтверждённые обещания, если они попали в черновой макет. Откройте вложенные документы и убедитесь, что они относятся к текущей версии предложения. Для русского и узбекского повторите один и тот же путь. Переключатель должен приводить к ожидаемой странице, а ошибки и подтверждения — оставаться понятными на выбранном языке. Проверьте, что в переводе не исчезли ограничения услуги. Приёмку фактов лучше поручить сотруднику, который знает предложение бизнеса, а проверку языка — человеку, уверенно им владеющему.
Попросите сотрудника самостоятельно внести изменение
Если предусмотрено управление содержанием, дайте будущему редактору небольшую задачу: изменить описание услуги, заменить изображение и исправить контакт. Пусть он выполнит её по переданной инструкции. Так станет понятно, хватает ли доступа и объяснений для обычной работы без постоянного обращения к разработчику. Обсудите, какие изменения можно делать самостоятельно, а какие требуют специалиста. Проверьте доступы сотрудников с разными обязанностями. Редактору текстов не обязательно нужны настройки оплаты или управление всеми пользователями. Уточните также, как отменить неудачное изменение и кто поможет, если страница после редактирования перестанет выглядеть правильно.
Примите доступы и возможность восстановления
Составьте перечень передаваемых ресурсов: домен, размещение сайта, управление содержанием, исходные материалы и подключённые сервисы. Укажите владельца аккаунта, способ восстановления доступа и ответственного за оплату. Проверьте вход с вашей стороны; одной отправленной инструкции недостаточно. Пароли и секретные ключи передавайте через согласованный защищённый способ, не публикуя их в общем отчёте. Документация WordPress поясняет, что для полного восстановления типичного сайта на этой системе нужны и файлы, и база данных. Для вашего проекта попросите назвать конкретный состав резервной копии и показать восстановление в отдельной среде. Уточните, кто следит за копированием и какие изменения могут потеряться между копиями.
Зафиксируйте замечания и порядок работы после запуска
Описывайте проблему так, чтобы её можно было повторить: страница, устройство, шаги, ожидаемый и фактический результат. Разделите замечания по влиянию на работу: невозможность отправить заявку важнее небольшого различия отступов. Согласуйте, какие пункты препятствуют запуску и как проверяются исправления. В итоговой передаче должны быть понятны канал связи, порядок сообщения об ошибке и границы дальнейших изменений. Сохраните список принятых сценариев вместе с инструкциями. Если готовитесь к запуску, можно начать обсуждение с вашей формы обращения и перечня доступов: на их основе удобно составить конкретный план приёмки для проекта.
Вопросы заказчиков
Можно ли принять сайт только по видеодемонстрации?
Демонстрация полезна, но не заменяет самостоятельную проверку ваших сценариев и доступов. Попросите рабочую версию для проверки на согласованных устройствах и тестовых данных.
Нужно ли проверять форму после переноса на основной адрес?
Да. Проверьте отправку и получение тестового обращения уже в рабочей среде: настройки домена, уведомлений или внешних сервисов могут отличаться от демонстрационной версии.
Достаточно ли получить архив сайта?
Нет. Уточните, какие данные и настройки нужны для восстановления, кто владеет подключёнными аккаунтами и как запустить проект. Полезно подтвердить это пробным восстановлением отдельно от рабочего сайта.