Редизайн сайта, с которого удобно обратиться

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

Пример маршрута
  • Структура
  • Контент
  • Интерфейс
UXПуть посетителя
  • Навигация
  • Телефон
  • Заявка

На телефоне сложно найти услугу и оставить заявку.

Проверка новой версии

Страница
Понятная услуга и действие
Перенос
Адреса и перенаправления
Заявка
Форма и доставка обращения

Проверка до публикации новой версии

Когда редизайн действительно нужен

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

Когда задача изменилась

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

Когда достаточно локальной правки

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

Что изучаем до первого макета

  1. Разобрать назначение страниц

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

  2. Посмотреть путь посетителя

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

  3. Зафиксировать, что сохранить

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

Как меняется структура и содержание

Вопрос и действие
Для каждой ключевой страницы определяем вопрос посетителя и следующий шаг. Например, человеку, выбирающему разработчика сайта, нужны состав работ, подходящие примеры, условия оценки и понимание дальнейшего процесса. Если страница содержит только общие обещания качества, её расширение начинается с этих ответов. Новый дизайн должен помогать найти их в удобном порядке.
Порядок сведений
Разделяем сведения, которые нужны сразу, и подробности для сравнения. Короткое предложение на первом экране может вести к описанию работ, кейсам и условиям ниже. В длинной странице полезно оглавление. Необязательно убирать подробные тексты ради минималистичного вида: важнее сделать ясные заголовки, читаемую ширину строки и заметные переходы между смысловыми частями.
Материалы и ответственность
При работе с существующим контентом отмечаем, что сохраняется, что переписывается и кто подтверждает факты. Фотографии проектов, названия клиентов, цены и результаты требуют проверки владельцем материалов или по доступным источникам. Отсутствующее доказательство нельзя заменить красивым числом. Если реальных данных о росте продаж нет, кейс может честно показать задачу, принятое решение и созданные материалы.

Визуальная система и мобильный сценарий

  • Разобрать референсы

    Референсы разбираем по конкретным признакам: типографика, плотность страницы, работа с фотографиями, движение, организация меню. Один пример может нравиться цветом, другой — тем, как объясняется процесс. Из этого собирается направление для вашего предложения. Копирование чужого экрана целиком часто переносит и чужие ограничения: другой объём текста, аудиторию или продукт.

  • Проверить систему элементов

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

  • Пройти путь на телефоне

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

Когда менять платформу

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

Сохранение платформы

Иногда можно сохранить платформу и обновить структуру, шаблоны и оформление. Это уменьшает объём переноса и помогает команде продолжить работу в знакомом редакторе. В другом случае ограничения оказываются существенными, и переход становится частью проекта. Выбор делаем по задачам, навыкам редакторов и расходам на обслуживание, а не по обещанию, что одна технология подходит любому бизнесу.

Владение и размещение

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

Адреса страниц и поисковые переходы

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

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

С чем сравнивать после запуска

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

Как проверяем и передаём новую версию

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

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

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

От чего зависят стоимость и срок

Что влияет на оценку

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

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

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

Стоимость и первый этап

Стоимость — после разбора текущего сайта

Сначала определяем, какие части нужно изменить. Утверждённые цены новых сайтов доступны в общем прайсе.

Связанные проекты

Примеры сайтов, которые мы создали. Это не замеры роста после редизайна.

Вопросы

Перед началом работы

Вы гарантируете рост заявок?

Нет. Мы можем проверить путь обращения и убрать конкретные препятствия. Результат зависит также от спроса, трафика и предложения компании.

Нужно ли менять домен?

Обычно нет. Если смена действительно нужна, план переноса и перенаправления обсуждаем отдельно.

Можно оставить существующий дизайн?

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

Пришлите адрес сайта и опишите, что не работает

В ответ обсудим состав первого этапа, нужные подключения и критерии готовности.