При редизайне исходная точка — существующий сайт. На нём могут работать полезные сценарии, находиться актуальные тексты и сохраняться важные адреса. Описать только новый внешний вид недостаточно. Нужно договориться и о том, что изменять не следует.
Ниже — редакционная структура рабочего ТЗ. Это не обязательная юридическая форма, не ГОСТ и не замена договору. Её задача — сделать обсуждение конкретным и оставить меньше решений, которые случайно всплывут при вёрстке.
Начните с причины, а не с пожелания к стилю
Опишите, кому предназначена страница и что человек должен на ней сделать. Затем назовите препятствие. Если причина редизайна пока звучит как «выглядит устаревшим», сначала проверьте её по материалу о необходимости изменений.
У задачи должен быть наблюдаемый результат. Например, посетитель может найти условия услуги, сравнить подходящие варианты и понять следующий шаг. Это полезнее, чем требование сделать интерфейс красивым и интуитивным: такие слова не объясняют, что именно проверять.
Отделяйте подтверждённые наблюдения от предположений. Если считаете, что мешает навигация, напишите, как это выяснили и что ещё собираетесь проверить. Предположение допустимо в задании, когда оно подписано, а не представлено готовым выводом.
Перечислите изменяемое и сохраняемое
Составьте список страниц или типов страниц. Рядом укажите, что должно измениться и какие части остаются. Не ограничивайтесь названиями разделов: для оценки важны различия в содержимом и поведении.
| Область задания | Что зафиксировать |
|---|---|
| Страница или шаблон | Назначение, существующий адрес, отличие от соседних |
| Содержание | Какие тексты актуальны, кто готовит недостающее |
| Изменение | Подтверждённая проблема и предполагаемая граница решения |
| Сохранение | Адреса, сведения, действия и узнаваемые элементы |
| Зависимость | Кто принимает решение и какие данные ещё нужны |
Отдельный список сохранений помогает заметить незаметные на макете вещи: файл для скачивания, ссылку из старой публикации, понятное название услуги. Вопрос смены адресов вынесите в контроль поискового риска, а не оставляйте на момент размещения.
Дайте содержимое для проверки макета
Короткие заглушки плохо показывают, как будет вести себя будущая страница. Приложите настоящий текст или обозначьте, кто его подготовит. Покажите длинное название, нестандартную характеристику и другие варианты содержания, которые действительно встречаются в вашей задаче.
Для изображений укажите происхождение и то, что важно сохранить в кадре. Для документов — сам файл и условия его обновления. Запишите известные условия использования; спорные материалы оставьте на отдельную проверку или замените до выпуска.
Если содержание ещё не готово, не называйте весь текст финальным. Отметьте зависимость и способ приёмки: например, сначала структура на представительных примерах, затем проверка с подготовленным наполнением. Это описание процесса, а не разрешение публиковать заглушки.
Опишите поведение на телефоне и состояния
Назовите элементы, которым нужно менять расположение или поведение: навигация, таблица, карточки, формы, крупные схемы. Для промежуточной ширины полезно записать правило, а не прикладывать только большой и маленький снимки.
Интерактивные элементы требуют отдельных условий. Что происходит при фокусе с клавиатуры? Как выглядит ошибка? Что остаётся доступным, если часть сценария ещё загружается? Не все состояния нужно превращать в новые страницы макета, но их результат должен быть понятен.
Для проверяемых требований к доступности можно использовать WCAG 2.2. В этом документе есть отдельные критерии для клавиатурного управления и обозначения полей. Не пишите просто «соответствует всем стандартам»: укажите согласованный набор проверок и способ проверки. Такая ссылка в ТЗ сама по себе не доказывает соответствие готового сайта.
Разведите интерфейс и техническую функцию
Поле на макете — не работающий процесс получения обращения. Если в задаче есть форма, запишите, кто отвечает за вёрстку, проверку ввода, приём, доставку и поведение при сбое. Уточните, какая часть уже существует в текущей системе.
Не включайте неизвестную интеграцию в обещание по умолчанию. Для страницы на действующей CMS нужны сведения о способе внедрения и ограничениях. Если их пока нет, в задании должно остаться открытое решение, а не фраза «доработать при необходимости» без владельца.
В услуге редизайна KEIVO основой являются дизайн и вёрстка. Задачи backend, CRM и конкретной CMS рассматриваются отдельно; готовность выполнять их нельзя выводить из красивого прототипа.
Заранее договоритесь о приёмке
У каждого существенного требования должен быть способ проверки. Условия доступны на странице — их находят и читают на согласованных экранах. Кнопка сохраняет назначение — переход проверяют. Документ скачивается — открывают именно этот файл и сверяют содержимое.
Учебный фрагмент задания: «При увеличении текста название услуги не обрезается. Клавиатурный фокус заметен. Ссылка на условия ведёт на актуальный документ. Проверяем на согласованных узком и широком экранах».
Уточните, кто собирает замечания и как фиксируется новая версия задания. Иначе полезное обсуждение легко превратится в несколько расходящихся списков. Последовательность этих решений разобрана в этапах редизайна.
Если требуется оценка работы, отправляйте всем участникам одинаковую версию вводных. Разбор состава стоимости поможет увидеть, где сравниваются разные результаты, а не разные цены одной задачи.
Источники и границы
- WCAG 2.2: Keyboard и Labels or Instructions — примеры формальных критериев, которые можно превратить в согласованные проверки.
- W3C: планирование доступности — распределение ответственности и включение проверок в процесс.
Состав ТЗ, учебный фрагмент и порядок обсуждения предложены редакцией. Юридическая достаточность документа и соответствие конкретного проекта стандартам этой статьёй не подтверждаются.