Сегодня всё меньше места для роли дизайнера как «оформителя» в разработке цифровых продуктов. Вместо этого дизайнер становится ключевым участником проектной команды — тем, кто влияет на темп разработки, формирует сценарии взаимодействия и помогает бизнесу не просто красиво или стилистически правильно, но и осмысленно решать задачи. Обсудим, как именно дизайнер становится точкой сборки продукта, и что это меняет в командах.
Эта статья – адаптация подкаста «Дизайн и люди», в котором продуктовый дизайнер Саша Ефремов и директор по развитию fuse8 Вениамин Мустафин с разной степенью серьёзности и юмора поговорили о том, как дизайнер задает темп с самого начала работы над продуктом и почему ему всё чаще выпадает роль продуктового игрока, а не просто специалиста.
Подскаст можно послушать на нескольких площадках
📚 Литрес
Мы в fuse8 разрабатываем цифровые продукты на заказ, и именно на этом контексте — агентской модели — построен весь разговор. Несмотря на то, что fuse8 свои продукты не делает, принципы проектной работы, описанные здесь, во многом универсальны.
Дизайнер задает направление, а не просто украшает интерфейс
Есть проекты, которые начинаются не с ТЗ, а с бизнес-проблемы. И часто такая проблема описана размыто, а возможно и вовсе недопонята заказчиком: «что-то чеки упали», «хотим повысить конверсию», «нужно что-то, чтобы конкурент не ушёл вперёд». Тут ноль осуждения заказчиков – ситуация базовая и вполне рабочая. Суть в другом. При таких вводных дизайнер — это точка входа в проект. Он способен задать направление, синхронизировать смыслы и вовремя задать вопрос, к которому другие могут не прийти. В таких условиях дизайнер уже не просто исполнитель, а соавтор стратегии.
Если дизайнер работает в отрыве от понимания целей бизнеса, он не сможет принять обоснованные интерфейсные решения. Вот пример: аналитик написал документацию, дизайнер получил её и начал проектировать, не зная, зачем вообще нужен экран. Итог — красивая, но неработающая фича. Спустя месяцы клиент может остаться недоволен, хотя вроде всё было как надо. Красивые экраны не работают, если дизайнер (и команда) не понимает цели бизнеса и контекста решений.
Важно, чтобы дизайнер не стеснялся задавать вопросы бизнесу, даже если это кажется не его зоной ответственности. Иногда именно дизайнер первым замечает, что условные 30 видов уведомлений, которые просит реализовать клиент — это не решение, а симптом другой, более серьезной проблемы, для которой еще только предстоит спроектировать решение. Зрелый дизайнер — это тот, кто работает не по брифу, а над гипотезой вместе с командой. Он — один из тех, кто превращает разрозненные требования в связную пользовательскую логику.
Дизайнер как хранитель темпа: от первых экранов до MVP
Темп — это не только про сроки. Это про то, насколько команда синхронизирована, как быстро переходит от идеи к реализации, насколько последовательно и реалистично раскладывает работу на этапы. И здесь дизайнеру под силу определить, по какой логике и с какой скоростью пойдёт развитие продукта. Вместе с аналитиком и продюсером он формирует дорожную карту: какие сценарии прорабатывать первыми, как разбивать на спринты, где возможна гибкость. Использование UI-библиотек, компонентный подход, ранняя сверка с разработкой — всё это инструменты сохранения темпа.
Интересный момент — распределение ролей. У нас на проектах есть роль продуктового аналитика — это гибрид между BA, дизайнером и продактом. Этот человек вместе с дизайнером формирует видение продукта, разбивает его создание на итерации. А уже затем дизайнер в тандеме с разработкой начинает проработку конкретных сценариев.
Сценарии прогоняются в UI-библиотеках, дизайнеры используют уже существующие компоненты. Это снижает порог входа для разработки, но требует от дизайнера внимания к ограничениям, без которых, кажется, ни один продукт обойтись не может.
Пересечение ролей — норма, если команда понимает, кто за что отвечает
Любой продукт требует плана, но он не должен быть высечен в камне. В командной работе важна гибкость. Не должно быть жёсткого деления, где чуть только смежная область – сразу расстрел. Наоборот, в сработанной продуктовой команде дизайнер может подсобить с аналитикой, тестировщик — с документацией, а продюсер — с формулировкой задач. Тут важно не переборщить, разумеется. Не стоит залезать на чужую зону ответственности просто по приколу или потому, что ты уверен, что знаешь, как лучше. Все это должно быть через диалог и взаимное согласование. Такая вот тонкая грань между проактивностью и хаосом.
Но это не анархия. Например, у нас во fuse8 держится структура из 5–6 ключевых ролей. Подробнее о них можно узнать в другой нашей статье. Просто важно, чтобы команда сама могла вносить поправки по ходу дела. Иногда дизайнер и аналитик пишут документацию параллельно, иногда команда договаривается, кто ведёт ту или иную фичу. Главное — чтобы было доверие.
Дизайн и разработка: из чего соберем интерфейс, и как не перегреть команду
Проектировать в отрыве от технологий — дорога в никуда. Тем более в условиях сжатых сроков. Да и без сжатых сроков не нужно отлетать от контекста (или работать без него) просто потому, что очень захотелось. Дизайнер должен понимать, какие компоненты доступны, какие ограничения есть у разработки, и как эти ограничения сделать опорой, а не тормозом.
Проблема рассинхрона дизайна и разработки не в сверхамбициях или их отсутствии, а в недостатке коммуникации. В идеале дизайнер приносит макеты в разработку, сверяется с техническими возможностями (например, UI-библиотекой), обсуждает с тимлидом и только после этого отрисовывает итог. А еще идеальнее, если все технические ограничения, способные повлиять на дизайн, сразу формулируются в ходе проработки решения. В обоих случаях, конечно, может понадобиться время на синхронизацию, но потом все станет понятно обоим юнитам.
У нас разработчики не обладают правом вето, как и дизайнеры. Все спорные решения принимаются с привлечением продакта или заказчика. Если фича требует много времени, а её ценность не очевидна — её двигают в бэклог. Такой подход помогает команде не перегреваться и не терять контроль над сложностью.
Приемка результата: дизайнер тоже участвует в проверке, не только тестировщик
Запуск интерфейса — не всегда автоматическое соответствие макету. Дизайнер способен заметить, где поведение отклоняется от задуманного, где сценарий начинает буксовать. Поэтому на этапе приёмки дизайнер вовлечен наравне с тестировщиком. Там, где QA проверит корректность данных, дизайнер увидит разрыв в логике, который не фиксируется тест-кейсами.
У нас в разных командах дизайн-ревью встроено в разные процессы: где-то это часть спринта, где-то — отдельный этап. В любом случае, дизайнер и тестировщик — это последние инстанции перед показом клиенту. И в этом их большая ответственность.
С заказчиком не защищаемся, а партнёримся
Вот мы сделали очередной функциональный блок, и настало время показывать результат клиенту: организовываем демо. Правильно выстроенные демо — это не театр одного актёра. Это момент, когда команда делится прогрессом, признаётся в сложностях, собирает уточнения и вместе с заказчиком двигается дальше. Дизайнер здесь — полноценный участник диалогов, а не фоновый исполнитель.
Важно фокусироваться не на том, чтобы продать или продавить решение, а на том, чтобы обсуждать смысл тех или иных внедрений. Так демо очередной релизной итерации не становится стрессом. Не воспринимайте клиентские демо как «судилище» над командой – это просто совместный разговор.
Даже бэкендер может показывать клиенту код, если это помогает выстроить доверие и прояснить возникшие вопросы. А дизайнер — не просто демонстрирует макеты, а помогает понять, какие продуктовые компромиссы были сделаны и почему.
Формат демо — это скорее «репорт за неделю» с открытыми вопросами, чем презентация «как всё идеально». Такой подход снижает тревожность и укрепляет связь с заказчиком.
Work-life balance и процессы
Один из признаков зрелости команды — умение не выгорать. В культуре, где дизайнер — движущая сила, особенно важно не требовать от него 12 часов у монитора. Тем более, если в этих часах он не проектирует, а «договаривается с собой» через стресс.
Здоровые границы внутри команды и с заказчиками — это не слабость, а инвестиция в устойчивость. У нас есть правило: не писать в нерабочее время. У некоторых есть два профиля в Telegram — рабочий и личный. А если что-то важное из задач вспомнилось под вечер — оно автомотический улетает в личный to-do лист на утро.
Вместо заключения
В командах, которые стремятся к скорости, качеству и осмысленной работе, дизайнер должен вступать в игру не в конце, а в начале. Он не обслуживает задачи, а помогает их формулировать. Не просто двигает пиксели, а выстраивает пользовательский путь. Не только оформляет интерфейс, но и держит темп.
И, возможно, именно такая роль дизайнера сегодня становится новой нормой. Конечно, нет универсальных рецептов, но зато есть живые подходы:
-
давать дизайнеру голос с самого начала,
-
не бояться пересечений ролей,
-
превращать ограничения в точки опоры реализации,
-
делать демо с клиентом, а не для клиента,
-
сохранять темп, но не перегревать(ся),
-
беречь себя и команду.
И если эти идеи находят отклик — возможно, и в вашей команде дизайнер станет не просто исполнителем, а тем, кто задаёт направление и смысл всему продукту.
