Работа над редизайном не всегда идёт по одной прямой линии. Проверка текста может вернуть команду к структуре, а техническое ограничение — изменить выбранный способ внедрения. Поэтому полезнее договориться о решениях и результатах, чем пообещать одинаковую цепочку для любого сайта.
В этой статье предложен рабочий порядок для обновления существующих страниц. Это редакционная модель, а не описание обязательного процесса всех агентств. Её можно сократить для небольшой правки или уточнить под более сложную систему.
Исходная точка: что не работает и что сохраняем
Соберите наблюдения о текущем сайте. Кому предназначены страницы? Какое действие важно? Где обнаруживается препятствие? Если ответов пока нет, не подменяйте их коллекцией понравившихся экранов. Начните с проверки необходимости редизайна.
Одновременно перечислите то, что работает: содержание, адреса, документы, понятные названия, действующие сценарии. Участникам нужен общий исходник. Иначе один будет проектировать новую страницу услуги, другой — переносить старую структуру, а третий — ожидать замену всей системы.
Результат этого этапа — короткое описание проблемы и границ первого изменения. Не обязательно заранее исследовать каждый экран сайта, если задача ограничена одной страницей. Но ограничения такой проверки должны быть видны.
Объём и ответственность до детального дизайна
Зафиксируйте изменяемые страницы, подготовку содержания, вёрстку и технические зависимости. Для этого подойдёт рабочая структура ТЗ. Здесь важны не формальности, а общий ответ на вопрос, что именно будет сдано.
Отдельно назовите ответственных за незакрытые вопросы. Кто предоставляет тексты? Кто проверяет условия услуги? Кто знает действующую CMS? Кто подтверждает фактический приём обращения, если он входит в задачу?
В руководстве W3C по планированию доступности ответственность и регулярная оценка включены в процесс работы. Для редизайна мы используем тот же организационный принцип: не оставлять все проверки одному финальному просмотру.
Сначала проверка структуры, затем оформление
На черновой структуре проверьте порядок ответов: понятно ли предложение, есть ли необходимые условия, можно ли перейти к действию. Для такого обсуждения не всегда нужна детальная картинка. Нужны настоящие или представительные тексты и понятные сценарии.
Референс помогает обсудить подачу, но не подтверждает, что чужая композиция подходит вашему содержанию. Покажите её с длинным названием, реальной таблицей и теми ограничениями, которые встретятся в проекте. Если ответ приходится прятать ради композиции, вернитесь к структуре.
После проверки переходите к деталям оформления: типографике, компонентам, состояниям, изображениям. Вопросы на этом шаге уже конкретные: как выглядит выбранное действие, чем отличаются типы карточек, как сохраняется порядок чтения на телефоне.
Передача в разработку — самостоятельный шаг
Макет нужно передать с правилами поведения и материалами. Вёрстка не должна начинаться с догадок о состояниях или поиском того, какой текст считать финальным. Подготовку этой передачи мы подробно разобрали в гайде о макете и вёрстке.
Назовите зависимости, которые дизайн не реализует сам: работу формы, данные каталога, подключение к CMS, размещение на сервере. Для них нужны собственные вводные и проверки. Если какая-то функция остаётся вне работ, это должно быть известно до приёмки.
В описании редизайна KEIVO дизайн и вёрстка отделены от неутверждённых интеграций. Такая граница не отменяет техническую часть проекта; она позволяет явно назначить её владельца и не обещать результат без проверки.
Принимайте сценарий, а не только сходство со снимком
Сравните страницу с согласованным макетом, затем пройдите её действия. Откройте узкий экран, используйте клавиатуру, проверьте ссылки и материалы. Для действующей формы отдельно проверяется получение обращения, а не только появление сообщения об успехе.
Полезен небольшой протокол, в котором замечание связано с ожидаемым результатом:
| Что проверяем | Что записываем |
|---|---|
| Содержание | Какой текст или условие отсутствует либо отличается |
| Поведение | Шаги, ожидаемый результат и то, что получилось |
| Экран | Условия просмотра, при которых заметно расхождение |
| Исправление | Кто отвечает и как повторить проверку |
Автоматический инструмент может обнаружить часть ошибок, но не заменяет согласованные сценарии. Даже предварительные проверки W3C прямо ограничены по охвату. Не превращайте один зелёный отчёт в заявление о полной готовности всех функций.
Выпуск и наблюдение после него
До размещения подготовьте способ вернуть проверенную предыдущую версию. Если меняются адреса или содержание важных страниц, используйте отдельный чек-лист поискового риска. В день выпуска проверяется уже публичный ответ, а не только локальный макет.
После выпуска сопоставляйте наблюдения с исходной задачей. Если данные ещё не накопились, так и отмечайте. Нельзя автоматически приписывать изменение обращений новому дизайну: одновременно могли измениться источники посетителей, предложение или способ измерения.
У этого процесса нет универсального календаря. Последовательность и ресурс зависят от согласованного объёма; состав оценки разобран в статье о стоимости редизайна. Закройте этап записью принятого решения и оставшихся вопросов. После этого следующий участник сможет продолжить с той же версией вводных.
Источники и границы
- W3C: Planning and Managing Web Accessibility — ответственность и проверки в процессе.
- W3C: Easy Checks — границы предварительного осмотра.
Порядок этапов и протокол предложены редакцией KEIVO. Это не отчёт о выполненном клиентском проекте, обещание сроков или доказательство роста конверсии.