Техническое задание должно начинаться не с экрана, а с задачи.
До выбора платформы и подрядчика полезно зафиксировать услуги,
сущности, подтверждения и пользовательские маршруты, которые
обязана поддержать новая версия. Тогда приёмка опирается не на
вкусовое «нравится», а на проверяемые требования.
СейчасКакие факты и противоречия уже видит пользователь
ТребованиеЧто новая версия должна подтвердить или устранить
ПриёмкаКак повторить маршрут после запуска
Что войдёт в короткий аудит
Основание для ТЗ, которое можно передать своей команде.
01
Сущности
Название, услуги, география, контакты и подтверждения, которые нельзя потерять.
02
Маршруты
Где текущий путь обрывается или создаёт сомнение у пользователя.
03
Требования
Что должно быть реализовано без привязки к конкретному подрядчику.
04
Проверка
Какие шаги повторить при приёмке новой версии.
Границы результата
Это не дизайн-концепция, не смета разработки и не обещание роста
конверсии. Результат можно передать своему разработчику или студии;
заказ дальнейшего внедрения у проекта не обязателен.
Формат проверки
Посмотрите, что входит в разбор до создания или переделки сайта.