# Техническое задание на редизайн: что записать до макетов

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

Автор: Редакция KEIVO
Дата публикации: 2026-10-28
Канонический URL: https://keivo.ru/blog/tehnicheskoe-zadanie-na-redizayn/

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

Ниже — редакционная структура рабочего ТЗ. Это не обязательная юридическая форма, не ГОСТ и не замена договору. Её задача — сделать обсуждение конкретным и оставить меньше решений, которые случайно всплывут при вёрстке.

Редакционная схема KEIVO. [Открыть схему в PNG](/blog/_media/p3-20261028/a03-268551591108.png).

## Начните с причины, а не с пожелания к стилю

Опишите, кому предназначена страница и что человек должен на ней сделать. Затем назовите препятствие. Если причина редизайна пока звучит как «выглядит устаревшим», сначала проверьте её по [материалу о необходимости изменений](/blog/kogda-nuzhen-redizayn-sayta/).

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

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

## Перечислите изменяемое и сохраняемое

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

| Область задания | Что зафиксировать |
| --- | --- |
| Страница или шаблон | Назначение, существующий адрес, отличие от соседних |
| Содержание | Какие тексты актуальны, кто готовит недостающее |
| Изменение | Подтверждённая проблема и предполагаемая граница решения |
| Сохранение | Адреса, сведения, действия и узнаваемые элементы |
| Зависимость | Кто принимает решение и какие данные ещё нужны |

Отдельный список сохранений помогает заметить незаметные на макете вещи: файл для скачивания, ссылку из старой публикации, понятное название услуги. Вопрос смены адресов вынесите в [контроль поискового риска](/blog/redizayn-i-poiskovyy-trafik/), а не оставляйте на момент размещения.

## Дайте содержимое для проверки макета

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

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

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

## Опишите поведение на телефоне и состояния

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

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

Для проверяемых требований к доступности можно использовать [WCAG 2.2](https://www.w3.org/TR/WCAG22/). В этом документе есть отдельные критерии для клавиатурного управления и обозначения полей. Не пишите просто «соответствует всем стандартам»: укажите согласованный набор проверок и способ проверки. Такая ссылка в ТЗ сама по себе не доказывает соответствие готового сайта.

## Разведите интерфейс и техническую функцию

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

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

В [услуге редизайна KEIVO](/services/redesign/) основой являются дизайн и вёрстка. Задачи backend, CRM и конкретной CMS рассматриваются отдельно; готовность выполнять их нельзя выводить из красивого прототипа.

## Заранее договоритесь о приёмке

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

> Учебный фрагмент задания: «При увеличении текста название услуги не обрезается. Клавиатурный фокус заметен. Ссылка на условия ведёт на актуальный документ. Проверяем на согласованных узком и широком экранах».

Уточните, кто собирает замечания и как фиксируется новая версия задания. Иначе полезное обсуждение легко превратится в несколько расходящихся списков. Последовательность этих решений разобрана в [этапах редизайна](/blog/etapy-redizayna-sayta/).

Если требуется оценка работы, отправляйте всем участникам одинаковую версию вводных. [Разбор состава стоимости](/blog/stoimost-redizayna-sayta/) поможет увидеть, где сравниваются разные результаты, а не разные цены одной задачи.

## Источники и границы

- [WCAG 2.2: Keyboard](https://www.w3.org/TR/WCAG22/#keyboard) и [Labels or Instructions](https://www.w3.org/TR/WCAG22/#labels-or-instructions) — примеры формальных критериев, которые можно превратить в согласованные проверки.
- [W3C: планирование доступности](https://www.w3.org/WAI/planning-and-managing/) — распределение ответственности и включение проверок в процесс.

Состав ТЗ, учебный фрагмент и порядок обсуждения предложены редакцией. Юридическая достаточность документа и соответствие конкретного проекта стандартам этой статьёй не подтверждаются.