Красивее — не значит понятнее

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

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

Сначала ищем поломку

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

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

Как понять, что нужен именно редизайн

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

В остальных случаях лучше начать с короткого исследования и прототипа. Это дешевле полной перерисовки и быстрее показывает, где находится реальная проблема.

Практический вывод

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

Почему нельзя честно назвать цену за минуту

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

Из чего складывается полный цикл

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

Если один из этапов исчезает из предложения, работа не пропадает. Она просто переезжает к клиенту или всплывает дорогой переделкой ближе к запуску.

Что сильнее всего влияет на бюджет

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

Как сравнивать предложения

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

Макет показывает состояние, продукт — систему

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

Что разработчик замечает раньше

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

Совместная работа не убивает смелые решения

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

Минимальный рабочий ритуал

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