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

О том, как презентовать дизайн людям, которые не говорят на языке UX и интерфейсов, как реагировать на критику и превращать обсуждение в конструктивный диалог, рассказал Никита Полубояров, тимлид отдела UX/UI студии AkademiaDev.

Почему дизайнеру важно уметь презентовать свои решения

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

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

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

Кому и как дизайнер объясняет решение

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

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

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

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

Показательный случай произошел во время работы над внутренним аналитическим продуктом AkademiaDev — отделы разошлись во мнениях о том, как пользователь должен переходить между разделами. У каждой стороны были убедительные аргументы, основанные на собственном опыте, поэтому обсуждение снова и снова заходило в тупик. Ситуация изменилась после того, как спор перестали вести на уровне мнений. Вместо этого команда построила подробный user flow и разложила весь сценарий на последовательность действий пользователя. Сразу стало видно, где сценарий рвется, а где путь пользователя оказывается короче. Затем мы собрали кликабельный прототип и проверили гипотезу на юзабилити‑тестировании. Результаты подтвердили предложенный вариант, и это поставило точку в споре. Команда согласилась не потому, что дизайнер оказался убедительнее остальных, а потому, что решение было подтверждено реальными цифрами.

Какие инструменты помогают объяснять идеи

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

Customer Journey Map используется не для проектирования, а для синхронизации команды: с картой команды видят картину в целом, а не только свой участок пути. Это позволяет предотвратить ненужные споры и недопонимания.

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

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

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

Формула успешной презентации

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

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

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

Несколько вариантов диаграммы 42 инициатив

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

Как реагировать на критику

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

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

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

Отличие начинающего дизайнера от опытного специалиста проявляется как раз в реакции на критику: джун принимает ее на свой счет и подробно рассказывает процесс, потому что процесс кажется главным доказательством проделанной работы. Мидл переходит на сценарии, появляется аргументация: задача пользователя, консистентность, данные исследований. Защищается уже не макет, а логика. А сеньор сразу показывает несколько возможных путей и объясняет, какой вариант считает наиболее удачным и почему. Большинство ожидаемых вопросов он закрывает еще во время презентации.

Когда говорят «Мне просто не нравится»

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

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

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

Выводы

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

Как презентовать дизайнерские решения не дизайнерам