«Сайт устарел» — повод разобраться, что мешает работе компании. Эта формулировка ещё не определяет нужный объём разработки. Иногда достаточно исправить форму или объяснить предложение на странице. Иногда новые аудитории, каталог и редакционные процессы требуют пересмотреть структуру и основу сайта.
Решение о редизайне сайта стоит принимать после сопоставления проблемы, вариантов и ограничений. Возраст сайта, новая мода или чужой внешний вид сами по себе не доказывают необходимость полной замены. Ни один вариант не гарантирует рост продаж без проверки предложения и спроса.
Начните с бизнес-причины
Назовите конкретную задачу: посетитель должен найти подходящую услугу, сравнить оборудование, отправить запрос или получить актуальную информацию. Затем опишите наблюдение, которое показывает препятствие. Например: «В карточке нет характеристик, нужных для подбора», а не «Каталог выглядит старым».
Разделите факт и предположение. Обращений мало — наблюдение за определённый период. «Причина в дизайне» — гипотеза, пока не проверены источники посетителей, предложение, форма и обработка. При малой аудитории полезнее пройти сценарии и собрать конкретные проблемы, чем обещать статистически надёжный вывод по нескольким визитам.
Зафиксируйте период, страницы, устройства и затронутую аудиторию. Отсутствие доступа к аналитике или задержка отчёта не означают нулевой спрос. Собственные проверки исключайте из оценки посетителей и обращений.
Разделите UX, содержание и техническую основу
Для одной проблемы проверьте три уровня. Понятно ли пользователю, что делать? Достаточно ли информации для решения? Позволяет ли текущая система реализовать и поддерживать нужное поведение?
| Наблюдение | Что проверить сначала | Возможный масштаб |
|---|---|---|
| Посетитель не понимает состав услуги | Условия, результат, ограничения, доказательства и следующий шаг | Обновление содержания и блоков страницы |
| Запрос не появляется у получателя | Поля, ответ сервера, обработку и доступ к записи | Исправление пути заявки |
| Нельзя сравнить продукцию | Характеристики, структуру данных, фильтры и карточки | Переработка каталога как раздела |
| Редактор не может поддерживать новые языки | Модель контента, роли, переводы и предпросмотр | Изменение CMS и связанных шаблонов |
| Новая аудитория не находит нужный раздел | Структуру, названия, навигацию и соответствие предложения | Пересмотр структуры и ключевых маршрутов |
| Изменения постоянно ломают соседние страницы | Причины регрессий, зависимости, тесты и процесс выпуска | Техническая доработка или замена части основы после диагностики |
Таблица содержит учебные варианты, а не автоматический диагноз. Один симптом может иметь несколько причин. Например, каталог может нуждаться в качественных данных раньше, чем в новом интерфейсе.
Дерево выбора
Пройдите вопросы по порядку и запишите основание каждого перехода.
- Есть конкретная проблема и подтверждение? Если нет, начните с диагностики: сценарий посетителя, состояние контента, проверка формы и доступные данные. Итог этого шага — описание проблемы, а не решение «перерисовать всё».
- Она ограничена одной функцией или страницей? Если да, проверьте локальное исправление и затронутые соседние сценарии. Если проблема повторяется по сайту, переходите к структуре и общим компонентам.
- Текущая основа поддерживает нужное поведение? Если да, сравните доработку или обновление раздела. Если нет, выясните точное ограничение и возможность заменить отдельный компонент. Название технологии само по себе не является ограничением.
- Меняются одновременно аудитория, структура, предложение и редакционные процессы? Если да, рассмотрите системный редизайн с планом перехода. Если изменения частичные, сравните поэтапную переработку с полной заменой на одинаковом составе результата.
- Есть материалы, ответственные и условия перехода? Если нет, сначала устраните эти зависимости или согласуйте меньший этап. Если да, зафиксируйте выбранный объём, критерии приёмки, наблюдение и условия возврата.
Результат дерева — вариант для оценки, а не готовый диагноз или денежный расчёт. Срочную потерю обращений исправляют отдельно от длительного решения о новой версии, если эти работы можно безопасно разделить.
Сравните стоимость изменений целиком
Запросите оценку нескольких вариантов на одних требованиях. Включите обследование, проектирование, подготовку материалов, разработку, перенос, проверку, выпуск и дальнейшую поддержку. Цена только за макеты не сопоставима со стоимостью работающего сайта.
У локальных доработок могут быть зависимости и повторные расходы. У новой версии — перенос данных, обучение редактора и период параллельной работы. Не считайте всё старое бесполезным: сохранение подходящих URL, контента и проверенных процессов может входить в новый проект.
Отдельно запишите неизвестное и условие уточнения оценки. Не назначайте универсальный процент, после которого редизайн «выгоднее»: стоимость и риск зависят от конкретной системы. Для регулярных расходов используйте разбор стоимости владения.
Учтите ограничения и порядок перехода
Проверьте доступы, лицензии, готовность контента, сезонные события, внешние интеграции и способность компании согласовывать работу. Если срок связан с выставкой, это не делает неподготовленный полный перенос безопасным. Возможен согласованный первый этап с ограниченным составом.
При замене версии заранее составьте карту переноса страниц. Не меняйте адреса только ради нового оформления. Определите, как сохраняются новые обращения и изменения контента между копированием и переключением, кто проверяет результат и когда запуск останавливают.
Карточка решения
Заполните документ для своего проекта. Учебный пример: компания расширяет каталог, но пока не имеет единых характеристик товаров. Первоочередная работа — согласовать модель и подготовить пробные записи, затем проверить фильтры и карточку. Полный редизайн главной не устраняет нехватку этих данных.
В карточке укажите проблему и доказательство, затронутые сценарии, варианты решения, сохраняемые части, ограничения, оценку состава работ и неизвестное. Затем выберите первый результат: что изменится, чем это проверить, кто принимает и какие данные будут доступны после выпуска.
Если новое наблюдение противоречит исходной гипотезе, пересмотрите объём. Хороший план позволяет остановить ненужную работу и перенести усилия на подтверждённую проблему. Для предметного обсуждения с CoreWeb подготовьте текущие страницы, сценарий, ограничения и желаемый результат; разработку мы выполняем своими силами.
Чтобы перейти от сравнения вариантов к ближайшей работе, выполните урок выбора следующего улучшения: сравните три проблемы и подготовьте одну проверяемую задачу.