Почему старый макет иногда нравится заказчику больше новой версии

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

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

Сначала я воспринимал это как обычное сопротивление изменениям. Потом заметил, что причины почти всегда повторяются.

И самое интересное — проблема часто вообще не в дизайне.

Старый макет уже знаком

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

Он знает:

где находится кнопка;

какого размера заголовок;

какой цвет используется;

где стоит фотография;

как выглядит первый экран.

Новая версия заставляет заново читать интерфейс.

Даже если она лучше, первое ощущение может быть хуже просто потому, что старый вариант уже не требует усилий.

У нас был проект, где дизайнер полностью переработал первый экран сайта.

В старой версии слева стоял большой текст, справа — фотография продукта. Ниже шли две кнопки.

В новой версии дизайнер убрал одну кнопку, сократил текст и увеличил изображение.

Команда считала новый вариант сильнее.

Клиент посмотрел и сразу сказал, что старая версия выглядит понятнее.

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

То есть спор изначально шёл не о качестве дизайна.

Заказчик сравнивает не результат, а ощущение

Внутри команды мы обычно смотрим на макет через задачи.

Например:

понятно ли главное действие;

видна ли иерархия;

не конкурируют ли элементы между собой;

легко ли читать текст;

не перегружен ли экран.

Клиент часто оценивает иначе.

Для него макет может быть:

слишком пустым;

слишком простым;

слишком спокойным;

слишком необычным;

не таким солидным.

Такие оценки звучат субъективно, но игнорировать их нельзя.

Ошибка менеджера — начать доказывать, что новый вариант правильнее.

Полезнее разобраться, что именно стоит за реакцией.

Когда клиент говорит, что старый макет выглядел богаче, я обычно уточняю, что именно создавало это ощущение.

Иногда выясняется, что дело в более крупной фотографии.

Иногда — в тёмном фоне.

Иногда — просто в количестве элементов.

После этого уже можно обсуждать конкретное решение.

Иногда новая версия слишком сильно отличается

Один из самых неудачных сценариев — показать клиенту сразу полностью переработанный экран.

Для команды путь понятен.

Мы видели промежуточные варианты.

Обсуждали проблемы.

Сравнивали решения.

Постепенно пришли к новой версии.

Клиент этого пути не видел.

Для него вчера существовал один сайт, а сегодня появился другой.

У меня был проект, где изменили:

шрифт;

цвет кнопок;

композицию первого экрана;

форму карточек;

структуру меню;

порядок блоков.

Каждое изменение отдельно было обоснованным.

Но вместе они создали ощущение, что старую работу просто выбросили.

Клиент начал защищать предыдущую версию целиком.

После этого я стараюсь не показывать большое количество изменений без объяснения логики.

Если переделывается несколько вещей сразу, полезно разделить их на причины.

Например:

здесь изменили структуру, потому что пользователи не замечали нужный раздел;

здесь сократили текст, потому что первый экран был перегружен;

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

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

Старый макет часто защищают из-за вложенного времени

Это особенно заметно в длинных проектах.

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

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

У нас был случай, когда клиент особенно упорно защищал блок, который команда хотела убрать.

Сам блок почти не давал полезной информации.

Но до этого он обсуждался несколько раз.

Для него убрать его означало признать, что несколько встреч и правок не дали результата.

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

После этого сопротивление исчезло.

Иногда правильное решение — не удалить старое полностью, а сохранить узнаваемую часть.

Дизайнер видит систему, заказчик — отдельные элементы

Ещё одна частая проблема.

Команда делает новый макет ради общей логики страницы.

Например, меняет сетку, сокращает количество цветов и уменьшает количество акцентов.

Заказчик замечает совсем другое.

В старой версии кнопка была ярче.

Заголовок был крупнее.

Фотография была больше.

И начинает сравнивать элементы по отдельности.

На одном проекте клиент долго просил вернуть красную кнопку.

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

Сам по себе красный вариант действительно выглядел заметнее.

Но когда мы вернули его в макет, сразу стало видно, что кнопка начинает спорить с другим ключевым элементом.

Я показал оба варианта рядом, но не отдельные кнопки, а весь экран.

После этого решение стало очевиднее.

Очень часто сравнивать нужно не элемент, а влияние элемента на всю страницу.

Иногда старый макет действительно лучше

Это тоже случается.

Не каждая новая версия автоматически становится улучшением.

Иногда команда слишком увлекается трендами.

Иногда дизайнер упрощает страницу сильнее, чем нужно.

Иногда новый вариант выглядит аккуратнее, но теряет характер.

Один раз мы переделывали страницу сервиса и слишком сильно очистили первый экран.

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

Внутри команды всё выглядело современно.

Клиент сказал, что страница стала похожа на десятки других сайтов.

После нескольких сравнений пришлось признать, что в старой версии действительно был более выраженный характер бренда.

Мы не вернули старый макет целиком, но часть деталей восстановили.

Это был полезный случай.

Если менеджер заранее считает, что клиент просто боится нового, легко пропустить реальную проблему.

Лучше сравнивать не макеты, а задачи

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

Например:

пользователь должен быстро понять услугу;

увидеть стоимость;

найти нужный тариф;

оставить заявку;

перейти в каталог;

понять отличие продукта от конкурентов.

После этого можно сравнивать две версии по одинаковым критериям.

Старый макет может оказаться красивее.

Новый — понятнее.

Или наоборот.

Главное, что обсуждение перестаёт строиться только на нравится или не нравится.

Один приём сильно сократил количество откатов

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

Не начинаю презентацию с самого макета.

Сначала коротко возвращаю контекст.

Например:

в прошлой версии пользователи не замечали основную кнопку;

в первом экране было слишком много текста;

две услуги выглядели одинаково важными;

на мобильной версии часть контента уходила слишком далеко вниз.

После этого показываю, что изменилось.

Так клиент сравнивает новую версию не с привычной картинкой, а с конкретной проблемой.

Это совсем другой разговор.

Что я теперь считаю хорошим согласованием

Раньше успешным согласованием для меня было получить ответ всё нравится.

Сейчас это не самый полезный критерий.

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

Если он говорит, что старый вариант нравился больше, я стараюсь не спорить сразу.

Сначала выясняю:

что именно нравилось;

какая деталь пропала;

какое ощущение изменилось;

не потерялась ли действительно важная часть.

Иногда после этого мы оставляем новую версию.

Иногда возвращаем элемент из старой.

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

Самая большая ошибка здесь — воспринимать старый макет как уже проигравший вариант.

Для клиента он может быть точкой опоры.

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