Вы показываете макет, а в ответ слышите: «Нормально, но как-то не цепляет. Сделайте покрасивее». Или хуже: «А давайте как у них». Спорить о вкусе бесполезно, и каждый такой разговор съедает время и доверие. Выход один: перестать защищать экраны и начать защищать бизнес-задачу, которую эти экраны решают. Ниже — как я это делаю на практике и что советую дизайнерам и тем, кто дизайн заказывает.
Почему «красиво» не работает как аргумент
Когда дизайнер говорит «так удобнее», руководитель слышит «мне так нравится». Оба используют слова о вкусе, и выигрывает тот, кто главнее. Обычно это не дизайнер.
У бизнеса другая оптика. Ему нужно, чтобы покупали, возвращались, не засыпали поддержку и не уходили к конкурентам. Интерфейс для него — способ получить эти результаты, а не самоцель. Поэтому любое дизайн-решение нужно уметь довести до цепочки: что изменили → что делает пользователь → как это отражается на деньгах или издержках.
Это не значит, что эстетика не важна. Аккуратный, цельный интерфейс повышает доверие, особенно в финансах, медицине и онлайн-оплате. Но и этот довод нужно привязывать к задаче: «клиент вводит данные карты, ему должно быть спокойно».
Если вы заказчик, то те же вопросы стоит задавать дизайнеру: какую задачу решает этот экран и по чему мы поймём, что решил? Если ответа нет, макет пока просто картинка.
Переведите дизайн на язык денег
Хорошая привычка: к каждому решению дописывать «чтобы…». Не «я сделал крупнее кнопку», а «я сделал главное действие заметным, чтобы больше людей доходило до заявки». Теперь у решения есть цель, и её можно проверить.
Вот как та же мысль звучит с разных сторон.
| Как говорят дизайнеры | Как это слышит бизнес | Как сказать лучше |
|---|---|---|
| «Я улучшил юзабилити формы» | «Что-то поправили, непонятно зачем» | «Сократил форму до необходимых полей, чтобы меньше людей бросало заявку на середине» |
| «Старый интерфейс устарел» | «Хочется нового, это дорого» | «Люди не находят нужный раздел и пишут в поддержку. Предлагаю упростить навигацию и сравнить число обращений» |
| «Так не принято по гайдлайнам» | «Дизайнер упрямится» | «Это решение непривычно для пользователей, они будут тратить больше времени на задачу и чаще ошибаться» |
| «Нужно провести исследование» | «Затянем сроки» | «Три коротких интервью за неделю снимут главный риск: мы не потратим месяц разработки на то, что не нужно» |
| «Сделал красивую анимацию» | «Лишняя работа для разработки» | «Анимация показывает, что заказ принят. Без неё люди нажимают кнопку повторно» |
Видно, что дело не в красивых словах. В правом столбце всегда есть пользователь, его действие и последствие для бизнеса.
Метрики, которые понимает бизнес
Не нужно знать всю аналитику. Достаточно четырёх-пяти показателей и понимания, какой из них двигает ваше решение.
- Конверсия — доля людей, дошедших до целевого действия: оплата, заявка, регистрация. Подходит, когда вы меняете путь к покупке, форму, карточку товара.
- Удержание — возвращаются ли люди через неделю, месяц. Важно для сервисов и приложений, где ценность появляется со временем. Дизайн влияет через онбординг, понятность первых шагов, уведомления.
- Нагрузка на поддержку — сколько обращений приходит по конкретной теме. Хорошая метрика для дизайнера: если люди массово спрашивают, как сделать что-то в интерфейсе, это сигнал, что экран непонятен.
- Время на задачу — за сколько человек выполняет типовое действие: оформить заказ, найти документ, создать отчёт. Для внутренних систем это почти прямые деньги: время сотрудников стоит зарплаты.
- Доля ошибок — как часто пользователь спотыкается: пустые поля, возвраты на шаг назад, отказы валидации.
Показатель всегда нужно привязать к конкретному месту продукта. «Поднять конверсию» — пожелание. «Увеличить долю тех, кто дошёл от корзины до оплаты» — задача, с которой можно работать. Где именно продукт теряет людей, я описывал в статье «Где продукт теряет клиентов: 7 мест для проверки».
Условный пример арифметики
Условный пример: в корзину заходит 1000 человек в месяц, оплачивает 300. Средний чек — 5000 рублей. Если после правок оплачивать будет на 30 человек больше, это 150 000 рублей в месяц дополнительной выручки. Цифры выдуманные, важен принцип: так любое решение превращается в деньги, и спорить уже можно о допущениях, а не о вкусе.
Если не знаете текущих цифр, начните с вопроса «а сколько их сейчас?». Часто выясняется, что никто не считает. Тогда первый результат дизайнера — предложить, что и как измерять.
Гипотезы и A/B-тесты
Гипотеза — это способ договориться без споров. Формат простой: если мы сделаем [изменение], то [метрика] изменится, потому что [причина]. Причина важнее всего: именно она показывает, что вы опираетесь на наблюдения, а не на интуицию.
Пример: «Если показать стоимость доставки на странице товара, меньше людей уйдёт в корзине, потому что в записях сессий видно, что многие уходят, увидев итоговую сумму».
Когда A/B-тест нужен, а когда нет
A/B-тест хорош, когда есть вариант спорный и трафика достаточно, чтобы увидеть разницу. Если посетителей мало, тест будет идти месяцами и ничего не покажет. Тогда выручают другие способы: интервью с несколькими клиентами, тестирование прототипа на пяти-шести людях, сравнение показателей до и после запуска.
Не нужно тестировать очевидные вещи: нечитаемый серый текст, сломанную кнопку на мобильном, форму, которая падает с ошибкой. Это просто исправляется.
И ещё: договоритесь о критерии успеха до теста. Если после результата начинается «а давайте посмотрим другую метрику», вы тестируете не дизайн, а терпение команды.
Как проверять быстрее, в том числе с помощью нейросетей, я рассказывал в статье «Как я использую AI в работе над интерфейсом».
Как презентовать макеты руководителю
Руководителю не нужно проходить путь, который прошли вы. Ему нужно решение и основание для него. Я строю презентацию так:
- Задача бизнеса одной фразой. «Хотим, чтобы больше людей оформляло заказ с телефона».
- Что мы увидели. Две-три находки: данные аналитики, записи сессий, цитаты клиентов.
- Что предлагаем. Макет и короткое объяснение, почему он устроен так.
- Как поймём, что сработало. Метрика, срок, порог.
- Риски и стоимость. Что потребуется от разработки, что может пойти не так.
- Чего нужно от руководителя. Решение, ресурс, доступ к данным.
Несколько правил, которые экономят нервы.
- Показывайте не все варианты, а один-два с вашей рекомендацией. Пять равноправных вариантов превращают встречу в голосование по вкусу.
- Начинайте с проблемы, а не с картинки. Пока человек не понял, зачем всё это, он будет оценивать цвета.
- Покажите сценарий, а не набор экранов: путь клиента от входа до результата.
- Заранее подготовьте ответы на вопросы про сроки и стоимость. Они прозвучат всегда.
Перед встречей пришлите руководителю одну-две строки: цель встречи и какое решение вам нужно. Тогда он придёт готовым принять решение, а не знакомиться с темой.
«Сделайте красивее» и «давайте как у конкурента»
Эти две фразы звучат в каждом проекте. Это не атака на дизайнера, это нормальный язык человека, который чувствует, что что-то не так, но не может назвать что.
«Сделайте красивее»
Я не спорю и не оправдываюсь. Я задаю уточняющие вопросы:
- Что именно в этом экране вас смущает?
- Какое впечатление он должен производить на клиента?
- Есть ли примеры, которые вам нравятся? Что именно в них нравится?
Обычно за «некрасиво» прячется конкретное: «выглядит дёшево», «слишком много всего», «не чувствуется премиальность», «скучно». С этим уже можно работать. Если же причина вкусовая, я прямо говорю: «Это вопрос предпочтений, давайте проверим на клиентах, а не будем гадать».
«Давайте как у конкурента»
Вместо «нет, это копирование» говорю: «Давайте посмотрим, что именно там работает для их аудитории и задач, и подойдёт ли это нам». Решение у конкурента могло появиться из других ограничений, другой аудитории или просто быть ошибкой, которую ещё не успели заметить.
Что делаю на деле:
- Прошу назвать, что именно понравилось: структура, цвет, конкретный приём.
- Разбираю, какую задачу этот элемент решает у них.
- Проверяю, есть ли такая же задача у нас.
- Если есть, беру принцип, а не внешний вид. Если нет, объясняю почему.
Анализ конкурентов полезен. Он показывает, к чему привыкли пользователи в вашей нише. Но копировать решения без понимания причин означает перенять и чужие ошибки.
Спор о вкусе нельзя выиграть. Спор о задаче и проверке — можно.
Как оценивать результат редизайна
Самая частая ошибка: запустить обновление и не вернуться к цифрам. Через полгода никто не помнит, что было до, и «стало лучше» превращается в мнение.
Что нужно сделать:
- Зафиксировать «до». Значения выбранных метрик за период до запуска. Без этого сравнивать не с чем.
- Выбрать окно «после». Достаточно длинное, чтобы пережить обычные колебания: сезонность, акции, праздники.
- Учесть другие причины. Если одновременно шла рекламная кампания или менялись цены, изменение метрик нельзя целиком приписать дизайну. Честно говорите об этом.
- Смотреть и на качественные сигналы. Что пишут в поддержку, что говорят клиенты, как ведут себя люди в записях сессий.
- Показать результат команде. Даже если цифры скромные или хуже ожиданий: из этого рождается следующая гипотеза.
Для оценки до запуска хорошо подходит UX-аудит: он даёт стартовую точку и список проблем в порядке приоритета. А если вы хотите быстро понять, на что смотреть в вашем продукте, у меня есть страница про аудит.
Если результата нет, это тоже результат. Гипотеза не подтвердилась, значит, вы узнали о пользователях что-то новое, и это дешевле, чем узнать через год.
Чек-лист: как защитить дизайн перед бизнесом
Перед встречей я проверяю себя по этому списку.
- Могу ли я назвать задачу бизнеса одной фразой?
- Понимаю ли я, какую метрику должно сдвинуть решение?
- Знаю ли я текущее значение этой метрики или хотя бы как его получить?
- Есть ли у меня хотя бы одно наблюдение за реальными пользователями: запись, интервью, обращение в поддержку?
- Сформулирована ли гипотеза в формате «если…, то…, потому что…»?
- Показываю ли я рекомендацию, а не россыпь вариантов?
- Подготовлены ответы про сроки, стоимость и риски?
- Договорено ли, как и когда мы оценим результат?
- Нет ли в моей речи слов «красиво», «удобно», «современно» без пояснения для кого и зачем?
Если дизайн-система в команде уже есть, часть аргументов становится проще: единые компоненты ускоряют разработку и сокращают число ошибок. Об этом я писал в статье «Дизайн-система для небольшой команды». А примеры того, как я подхожу к задачам, собраны в разделе «Работы».
Частые вопросы
Как обосновать дизайн заказчику, если нет данных?
Начните с того, что есть: обращения в поддержку, отзывы, записи сессий, пять коротких интервью с клиентами. Этого достаточно, чтобы сформулировать гипотезу и договориться о том, что будем измерять после запуска. Если совсем ничего нет, первым шагом предложите настроить сбор простых метрик.
Какие метрики нужны дизайнеру?
Для большинства задач хватает конверсии в целевое действие, удержания, числа обращений в поддержку, времени на задачу и доли ошибок. Выбирайте те, на которые решение может повлиять напрямую, и фиксируйте значения до запуска.
Что ответить на «сделайте красивее»?
Уточните, что именно смущает и какое впечатление должен производить экран. Чаще всего за этой фразой стоит конкретная проблема: перегруженность, ощущение дешевизны, непонятная иерархия. С ней можно работать. Если причина во вкусе, предложите проверить на пользователях.
Как ответить на «давайте как у конкурента»?
Не отказывайтесь сразу. Выясните, что именно понравилось, какую задачу этот элемент решает у конкурента и есть ли такая же задача у вас. Берите принцип, если он подходит, а не внешний вид.
Всегда ли нужен A/B-тест?
Нет. Он имеет смысл при спорном решении и достаточном трафике. При небольшом числе посетителей лучше использовать интервью, тесты прототипа и сравнение показателей до и после запуска. Очевидные исправления тестировать не нужно.
Как оценить результат редизайна?
Сравните выбранные метрики до и после на достаточно длинном периоде, учтите другие факторы вроде рекламы и сезонности и добавьте качественные сигналы: обращения в поддержку и поведение пользователей. Результат стоит показать команде в любом случае.
Если коротко: говорите о задаче, привязывайте решения к метрикам, предлагайте проверку вместо спора и возвращайтесь с результатом. Если хотите разобрать свой продукт на этом языке, посмотрите, как устроен аудит, или напишите мне.