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