Превратите впечатление в проверяемую проблему
«Сайт выглядит старым» — понятное впечатление, но оно не определяет объём работ. Причиной неудовлетворённости может быть неподходящая фотография, устаревшее предложение, сложная навигация или неудобная форма. Эти проблемы требуют разных решений. Перед обсуждением редизайна запишите, кто испытывает затруднение, на какой странице и какое действие не удаётся выполнить.
Полезная формулировка: «посетитель на телефоне не может сравнить услуги, потому что важные условия находятся в нескольких несвязанных разделах». В ней уже есть аудитория, препятствие и сценарий проверки. Формулировка «сделать современно» оставляет выбор на уровне вкуса. В материале Nielsen Norman Group о полном и постепенном обновлении выбор также связывают с подтверждёнными потребностями пользователей.
Соберите три вида свидетельств
Начните с наблюдений: попросите представителя аудитории найти нужную услугу, проверить условия и отправить обращение. Не подсказывайте названия кнопок. Отмечайте места, где человек останавливается, возвращается назад или неправильно понимает текст. Несколько таких наблюдений не дают статистического вывода обо всей аудитории, но помогают обнаружить препятствия для следующей проверки.
Затем изучите аналитику, если события настроены и данные достоверны. Отделяйте просмотры от завершённых действий, мобильные посещения от компьютерных, новые источники трафика от прежних. Наконец, соберите обращения к сотрудникам: какие вопросы повторяются, какие сведения менеджеры присылают вручную. Сопоставление этих источников полезнее, чем решение по одному показателю отказов или одному отзыву.
Пример 1: основной путь работает, мешает один участок
Условная компания получает обращения через сайт. Услуги понятны, посетители находят нужные страницы, но на телефоне клавиатура закрывает кнопку отправки. Полная смена структуры не исправляет причину сама по себе. Здесь логично проверить форму, адаптивную компоновку, валидацию и состояние после отправки.
Состав доработки можно ограничить: исправить расположение полей, показать понятные ошибки, обеспечить передачу обращения и проверить согласованные устройства. Критерий приёмки — успешно выполненный сценарий, включая неверный ввод и повторное нажатие. Если проблема действительно локальна, остальные страницы не требуют обязательного переоформления. Подробности этого пути разобраны в статье о форме заявки и передаче обращения менеджеру.
Пример 2: предложение изменилось, структура больше не соответствует ему
Другая условная компания раньше продавала одну услугу, а теперь работает с несколькими аудиториями и комплексными проектами. Старый сайт заставляет складывать несвязанные предложения в один длинный раздел. Новые пункты меню не объясняют различия, а одинаковые формы требуют разных исходных данных.
Здесь проблема затрагивает содержание и архитектуру. Нужны карта разделов, понятные названия направлений, правила переходов и отдельные сценарии обращения. Это основание для нового проектирования. Однако готовые фотографии, полезные тексты и работающие интеграции можно сохранить после проверки. Редизайн не должен означать отказ от всего существующего без разбора.
Пример 3: внешний вид раздражает команду, причина потерь неизвестна
Предположим, сотрудники хотят заменить весь сайт, потому что конкуренты используют большие видео и анимацию. При этом неизвестно, понимают ли посетители предложение, доходят ли заявки до менеджеров и откуда приходит аудитория. В такой ситуации сначала нужен разбор текущего пути и источников данных.
Можно подготовить прототип одного ключевого экрана и сравнить понимание содержания с нынешней версией. Проверяется конкретный вопрос: виден ли состав услуги, понятны ли ограничения, найден ли следующий шаг. Уместность визуального решения оценивается вместе с читаемостью и скоростью. Nielsen Norman Group показывает такой итерационный подход на обновлении собственной главной страницы: варианты проверяют до окончательного внедрения.
Отделите интерфейс от технической основы
Иногда новый дизайн обсуждают из-за медленной загрузки или невозможности редактировать каталог. Сначала определите источник ограничения: изображения, клиентский код, сервер, модель данных или инструменты управления. Замена цветов и карточек не устранит задержку сторонней интеграции. И наоборот, техническая оптимизация не сделает непонятное предложение убедительным.
Составьте два списка: препятствия в пользовательском сценарии и ограничения поддержки. Для каждого укажите необходимое изменение и зависимые части. Если небольшая задача требует постоянных обходных решений в существующей системе, новая основа может быть обоснована. Но оценить это нужно по конкретным работам, а не по возрасту технологии или желанию использовать другой инструмент.
Договоритесь о результате до начала оформления
Для выбранного пути подготовьте перечень страниц, сценариев и условий приёмки. Вместо «повысить конверсию» сначала запишите управляемые требования: информация о составе работ находится на странице услуги, форма сообщает об ошибке, обращение появляется у ответственного сотрудника. Изменение процента обращений оценивают отдельно по сопоставимым периодам и источникам трафика; его нельзя гарантировать внешним видом.
Проверьте также читаемость, клавиатурную навигацию и подписи полей. Базовые проверки доступности W3C помогают начать такой разбор, но не заменяют полноценную оценку. Визуальное обновление должно сохранять доступ к содержанию и основным действиям.
С чего начать обсуждение
Соберите текущие страницы, три главных затруднения и подтверждения для каждого. Укажите, что уже работает и должно сохраниться: адреса, содержание, формы, интеграции, порядок обработки заявок. После этого можно сравнить ограниченную доработку, обновление группы страниц и полноценный редизайн по составу работ.
Для разбора интерфейса используйте направление UI/UX-дизайна, для изменения структуры и реализации — сайты для бизнеса. Если решение о редизайне уже принято, отдельно подготовьте план сохранения адресов страниц. Это следующий этап; он не должен подменять диагностику того, что именно требуется изменить.
