Как составить техническое задание на редизайн интернет-магазина

Как составить техническое задание на редизайн интернет-магазина без потери рабочих процессов

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

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

1. Опишите границы редизайна и зафиксируйте, что должно остаться без изменений

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

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

• Меняется: внешний вид меню, расположение характеристик или порядок блоков на странице категории.

• Сохраняется: интеграция со складом, логика скидок или обязательные поля заказа.

• Требует решения: фильтр, который сейчас создаёт отдельный адрес и попадает в поисковую выдачу.

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

Границы редизайна удобно закрепить в таблице ТЗ с колонками «раздел», «текущее поведение», «новое поведение», «что не менять» и «как проверить». Например, для корзины укажите: сохранить пересчёт суммы при изменении количества, изменить оформление блока доставки, проверить корректность суммы после обновления страницы.

2. Зафиксируйте требования к каталогу и товарным карточкам

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

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

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

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

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

Не ограничивайтесь списком блоков. Уточните, какие поля редактирует контент-менеджер, где показываются длинные характеристики и как выглядят карточки без изображения. Такая фиксация помогает дизайнеру и разработчику не придумывать поведение пустых полей уже во время сборки.

3. Пропишите путь покупателя от выбора товара до заказа

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

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

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

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

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

4. Определите, как редизайн должен работать с SEO-настройками магазина

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

Опишите, где редактор меняет title, description, заголовок страницы и текст категории. Уточните, какие метаданные должны переноситься из старой CMS и что показывать, если поле не заполнено. Для карточек товара укажите, откуда берутся название и описание, чтобы редизайн не привёл к пустым метатегам на страницах с сохранёнными товарами.

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

Добавьте проверку структурированных данных и канонических адресов для шаблонов категорий и карточек. В ТЗ полезно указать, какие поля должны попасть в разметку товара: название, цена, валюта и наличие. Если магазин использует специальные SEO-модули, назовите их и зафиксируйте, какие настройки нужно сохранить при обновлении шаблона.

5. Зафиксируйте интеграции и источники данных

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

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

Для доставки перечислите данные, нужные интерфейсу: доступные способы, адреса пунктов выдачи, сроки или стоимость, если сервис их передаёт. Уточните, где редактируются тексты и ограничения, например список регионов, куда курьерская доставка не доступна. Такие правила не должны зависеть от текста, вручную вставленного в макет.

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

6. Задайте критерии приёмки для ключевых сценариев

Критерий приёмки описывает результат, который можно повторить и проверить. Вместо фразы «каталог удобный» напишите: покупатель выбирает категорию, включает фильтр по размеру, открывает карточку и видит выбранный размер в доступных вариантах. Для корзины добавьте проверку, что изменение количества обновляет сумму и сохраняется после перехода к оформлению.

Проверки разделите для мобильной и десктопной версий. Укажите конкретные ширины экранов, которые команда должна поддержать, и согласуйте значения до вёрстки. Если макеты заданы для выбранных разрешений, зафиксируйте их в ТЗ; между ними интерфейс должен сохранять доступ к фильтрам, кнопке покупки и полям заказа.

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

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

7. Спланируйте проверку перед запуском и действия при сбое

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

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

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

До переключения домена или публикации шаблонов согласуйте окно запуска и порядок действий: кто включает новую версию, кто проверяет тестовый заказ, кто следит за оплатой и складскими остатками. Приёмку проводите по списку сценариев из ТЗ, а обнаруженные ошибки фиксируйте с адресом страницы, устройством и шагом, на котором они появились.