Почему хорошего UX недостаточно: дизайнеру нужно уметь объяснять свои решения

Долгое время мне казалось, что сильное дизайн‑решение должно говорить само за себя. Если сценарий логичный, интерфейс понятный, состояния продуманы, а решение опирается на исследования — зачем дополнительно его «продавать»? Но когда я оказалась в продуктовой команде, а не на проектах фриланса, оказалось, что качество самого макета — только часть задачи.

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

Не защищать интерфейс. Объяснять проблему

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

Первая реакция дизайнера может быть такой: «Нет. Чем больше полей, тем больше когнитивная нагрузка».

Формально аргумент понятен, но разговор уже начинает превращаться в «моё решение против твоего». Можно зайти иначе: для чего именно нам нужна эта информация и в какой момент мы собираемся её использовать? Допустим, выясняется, что эти данные нужны отделу продаж только после того, как пользователь становится лидом.

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

• спросить при регистрации;

• запросить позже;

• получить из других данных;

• сделать поле необязательным.

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

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

«Мне кажется» — слишком слабая единица аргументации

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

• экран перегружен;

• действие потерялось;

• иерархия сломана;

• слишком много конкурирующих элементов;

• сценарий требует лишних шагов.

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

Например, дизайнер говорит: «Эта кнопка должна быть выше». Почему? Потому что сейчас она теряется. Почему это проблема? Пользователь не понимает, какое действие на экране основное. Что произойдёт? Ему приходится дополнительно сканировать интерфейс и сравнивать несколько действий. Что мы пытаемся изменить? Сделать следующий шаг очевидным.

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

То же самое может происходить с карточкой. Например, дизайнер говорит: «Статус нужно сделать ярче». Сам по себе такой аргумент почти ничего не объясняет. Но если пользователь работает со списком из десятков записей и его задача — быстро находить те, которые требуют внимания, появляется другая логика: статус нужно выделить не потому, что так «красивее», а потому, что он помогает быстрее отличать обычные записи от проблемных и снижает время на изучение списка.

Один интерфейс приходится объяснять разным людям по‑разному

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

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

Решение одно. Но ценность этого решения для каждого человека разная. Поэтому хорошая защита дизайна — это не заученный монолог. Это перевод одной и той же логики на язык собеседника.

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

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

Фидбэк — это не всегда требование

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

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

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

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

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

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

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

Самое неприятное здесь даже не в том, что первоначальное решение оказалось неудачным. Ошибка произошла гораздо раньше. Когда мне сказали «слишком много белого пространства», я сразу услышала «нужно убрать белое пространство». Хотя стоило сначала спросить: Пользователям не хватает информации на первом экране? Они не понимают, куда смотреть? Интерфейс кажется незавершённым только владельцам продукта? Есть ли вообще пользовательская или бизнес‑проблема, которую мы хотим решить?

Вполне возможно, что после этих вопросов мы вообще не стали бы переделывать интерфейс. Поэтому сейчас комментарий вроде «здесь слишком много белого пространства» для меня ещё не задача. Это только сигнал, который нужно расшифровать. За ним может стоять реальная проблема, ограничение продукта или просто личное предпочтение человека. И только после того, как понятна причина, стоит принимать дизайн‑решение.

Не доказывать, что решение идеальное

Мне всё меньше нравится формулировка «защищать дизайн». Она словно предполагает, что одна сторона нападает, а дизайнер должен отстоять свой макет. Но дизайн почти всегда состоит из компромиссов.

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

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

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

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

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

Вопрос не в том, какой вариант «правильный» сам по себе. Вопрос в том, что пользователь делает чаще: быстро сравнивает множество объектов или подробно работает с каждым из них.

Иногда лучший ответ дизайнера: «нужно проверить»

Не на каждый вопрос нужно отвечать прямо во время встречи.

Например, кто‑то спрашивает: «А пользователи вообще понимают эту иконку?» Худший вариант: «Конечно понимают, она стандартная». Чуть лучше: «Думаю, понимают». Ещё лучше: «Сейчас у нас нет данных, чтобы уверенно это утверждать. Можно проверить на ближайшем usability‑тесте».

Способность сказать «я не знаю» не делает дизайнера слабее. Особенно если за этим следует: «Вот как мы можем это узнать».

Например, команда спорит, нужен ли пользователю поиск внутри большого списка. Один человек говорит, что список маленький и поиск только усложнит интерфейс. Другой уверен, что без поиска пользователю будет неудобно.

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

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

Сильная аргументация для меня теперь выглядит примерно так

Не: «Мы сделали так, потому что это удобнее».

А: «Сейчас пользователь сталкивается с X. Мы хотим получить Y. Поэтому предлагаем Z. Это решение уменьшает/увеличивает/позволяет... Мы рассматривали альтернативу A. Если сомневаемся в предположении — можем проверить его через B».

Например: «Сейчас оператору приходится открывать каждую запись, чтобы понять её статус. Мы хотим сократить количество таких открытий, поэтому выносим статус на карточку. Это позволит быстрее сканировать список. Мы рассматривали вариант показывать статус только внутри карточки, но тогда основная проблема остаётся. Если сомневаемся, насколько статус действительно важен при сканировании, можно проверить это через наблюдение или usability‑тест».

Или: «Сейчас пользователь видит восемь одинаково заметных действий. Мы хотим сделать основной следующий шаг понятнее, поэтому одно действие становится primary, остальные — secondary. Если окажется, что пользователи одинаково часто используют несколько действий, иерархию стоит пересмотреть».

И ещё один вывод: макет — не твоя собственность

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

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

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

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

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