Рынок IT меняется с такой скоростью, что за ним иногда трудно угнаться: новые технологии, методологии, роли — всё постоянно меняется. Из-за этого границы между профессиями часто становятся размазанными. Если разработчики чётко знают свой стек, задачи и техдолг, то у дизайнеров и аналитиков всё гораздо более гибко, потому что их работа опирается на коммуникацию, логику и потребности людей. Часто дизайнеры и аналитики начинают работать вместе еще на самых ранних стадиях проекта — именно там, где чаще всего царит хаос.
И вот здесь начинается путаница. Часто не совсем ясно, кто за что отвечает. В одной команде UX-дизайнер делает всё: от сбора требований до создания прототипов, а в другой — он ждет четкого ТЗ от аналитика. И тогда возникает вопрос: где заканчивается аналитика и начинается дизайн? Давайте разберемся.
Обозначим условия
В этой статье речь пойдет об аутсорс-разработке, где чаще всего работают UX/UI-дизайнеры и аналитики. Под «аналитиком» мы будем понимать нечто среднее между бизнес- и системным аналитиком. Разделение этих ролей — тема для отдельной статьи, поэтому здесь мы углубляться в неё не будем.
Что касается UX/UI-дизайнера, то его роль понятнее. Это человек, который работает над пользовательским опытом: он решает, что будет написано на кнопке, как она будет выглядеть, где она появится — и появится ли вообще.
Какие подходы существуют к совместной работе дизайнера и аналитика
В IT-компаниях взаимодействие дизайнера и аналитика может выстраиваться по-разному. Всё зависит от проекта, состава команды, уровня специалистов и текущих процессов. Но в целом можно выделить три основных подхода:
Регулярные синки, брейнштормы, доверие и критика без боли — всё это часть процесса при совместной работе дизайнера и аналитика. Расхождения будут, но их проще решать в диалоге: где-то пожертвовать фичей, где-то изменить подход.
Следует признать, что у такого подхода существуют и минусы, так как он может работать только в определенных условиях — без них процесс может пойти вразнос. Вот с какими трудностями можно столкнуться:
Требуется высокий уровень ответственности и доверия
Если один из специалистов пассивен, не выходит на связь или уходит в глухую оборону, команда превращается в лебедя, рака и щуку. Вместо синергии — лишние созвоны и переделки.
Трудно планировать и считать время
Кто сколько сделал? Сколько уйдёт времени на задачу? Ответы расплывчатые, потому что работа ведётся в паре, а не строго по ролям. Это может напрягать менеджеров, особенно в аутсорсе.
Такой тандем сложно распараллелить на несколько проектов
Когда дизайнер и аналитик глубоко погружены в продукт и сильно друг от друга зависят, переключение на другой проект может привести к потере контекста или завалу сроков.
Нужен баланс ролей в команде
Если дизайнеров много, а аналитиков не хватает, или наоборот, начинается перетягивание одеяла. Один делает не свою работу, а это — прямой путь к выгоранию и падению качества решений.
Какой подход выбрала наша компания
В KozhinDev мы стараемся строить работу по третьему сценарию — когда аналитик и дизайнер работают в тесной связке с самого начала. Это особенно важно для сложных и долгоиграющих проектов, где нельзя чётко разделить зоны ответственности и просто «передать задачу дальше по конвейеру».
Такой подход отлично зарекомендовал себя на одном из наших ключевых проектов — медицинской ERP-системе, над которой мы работаем уже больше года. Это большая B2B-система с множеством сущностей, сценариев и ролей. Чтобы проект оставался жизнеспособным и масштабируемым, дизайнер и аналитик на каждом этапе работают в паре: обсуждают, спорят, предлагают идеи и вместе решают, как будет работать продукт.
Как это выглядит на практике? Весь процесс можно разбить на несколько шагов.
Сбор требований
Аналитик общается с клиентом, собирает требования, раскладывает их по полочкам, выявляет ограничения, описывает бизнес-логику. Он видит картину сверху.Передача требований дизайнеру
Когда есть контекст — цели, роли, сценарии — к задаче подключается дизайнер. Вместе с аналитиком они валидируют пользовательские потоки, обсуждают архитектуру экранов и возможные варианты подачи информации.Создание wireframes
Дизайнер переводит сценарии в интерфейс: расставляет акценты, упрощает путь, делает систему понятной и логичной.Обсуждение с аналитиком
Дизайнер показывает черновой вариант аналитику. Вместе они проходят по ключевым сценариям: не упущена ли логика, всё ли соответствует бизнес-целям, где могут быть риски. Аналитик проверяет, не нарушились ли ограничения, которые обсуждались с клиентом. Иногда на этом этапе появляется новая информация — приходится возвращаться и дорабатывать.Обсуждение с командой и клиентом
Затем wireframes презентуются команде и клиенту. Важно проговорить, как работает система, почему решения именно такие, где возможны альтернативы. Все участники дают обратную связь: клиент — по бизнесу, разработчики — по технической реализуемости, аналитик — по логике. В аутсорсе особенно важно это взаимодействие: клиент часто непоследователен, сроки сжатые, и именно связка «аналитик + дизайнер» может быстро принимать решения и двигать проект вперёд.Передача в разработку
После финального апрува дизайнер делает чистовые макеты, аналитик дополняет описания сценариев, пограничных условий, бизнес-правил. Всё это собирается в одну точку — чтобы у разработчиков не возникало лишних вопросов и не было пробелов между макетом и логикой.
Кто и когда общается с клиентом
Мы уже описали, как в нашей компании слаженно работают аналитики и дизайнеры на разных этапах разработки. Но один из ключевых моментов — это понимание, кто и как общается с клиентом. Сбор требований в аутсорсе чаще всего лежит на бизнес-аналитике. Он формализует пожелания клиента, вытаскивает цели, ограничения, проверяет, насколько задачи реализуемы.
Однако, даже если аналитик тщательно проработал начальную информацию, дизайнеру всё равно важно подключаться к общению с клиентом. Почему?
Во-первых, в сложных или нестандартных проектах, таких как наша ERP-система, важно выявить нюансы, которые могут быть упущены при передаче информации между аналитиком и дизайнером.
Во-вторых, если клиент сам не до конца понимает, чего хочет, именно дизайнер может задать вопросы, которые помогут раскрыть потребности более полно.
Даже после первичного сбора дизайнеру полезно пообщаться с клиентом напрямую, чтобы услышать интонации, увидеть приоритеты, задать уточняющие вопросы, которые аналитик мог не задать — просто потому что у него другой фокус.
Кто и когда общается с командой
В процессе работы дизайнер и аналитик взаимодействуют с командой в разные моменты и по разным вопросам.
Аналитик общается с командой на протяжении всего периода разработки: он проговаривает с командой реалистичность требований, уточняет ограничения и оценивает сложность разработки..
Дизайнер в свою очередь активнее включается на этапе проработки интерфейса. Он представляет свои решения, собирает фидбэк по их осуществимости и уточняет, какие компоненты или паттерны уже существуют и могут быть использованы.
Иногда их общение с командой может происходить по отдельности:
когда обсуждаются исключительно бизнес-требования — здесь аналитик тесно взаимодействует с разработчиками;
когда решаются вопросы, касающиеся UI — дизайнер взаимодействует с фронтенд-разработчиками.
Но есть моменты, когда их сотрудничество обязательно:
когда возникают спорные UX-моменты, где важно, чтобы логика и визуальные решения были согласованы;
когда нужно оперативно принять решение по изменению сценария;
если команда не до конца понимает, «почему так», и требуется общий контекст для принятия решения.
Идеальный вариант, когда дизайнер и аналитик работают вместе: они оба должны участвовать в презентации решения команде, присутствовать на грумингах и в целом отвечать за функциональность решений.
Кто рисует прототипы и в каком виде
Основную работу по созданию прототипов выполняет дизайнер. Его задача — трансформировать абстрактные требования в конкретные визуальные решения, чтобы проект обрел четкие контуры. Это могут быть разные виды прототипов в зависимости от стадии и цели.
Wireframes — используются на ранней стадии проекта. Они помогают согласовать логику и основные сценарии без глубокой детализации, позволяя всем участникам увидеть структуру.
Прототипы в Figma — кликабельные модели интерфейса, показывающие, как пользователь будет взаимодействовать с системой. Это помогает проверить и продемонстрировать весь путь пользователя.
Быстрые схемы/блоки — часто создаются прямо на бумаге или в FigJam для набросков идей на лету. Эти схемы полезны, когда нужно быстро визуализировать концепцию или обсудить направления.
В некоторых случаях аналитик может сделать грубый скетч или набросок, если у него есть четкое представление о том, как должно выглядеть решение. Это нормальная отправная точка, но дальнейший «перевод» в полноценный UX всегда ложится на плечи дизайнера. Он будет упрощать, расставлять акценты, учитывать существующие паттерны и адаптировать решения под нужды пользователя и бизнеса.
Какие данные аналитик передает дизайнеру
Аналитик передает дизайнеру не просто список экранов, а полный контекст, который необходим для того, чтобы создать осмысленный и эффективный UX. В идеале это включает:
цели пользователей и их роли — кто что делает и зачем: важно понимать, кто будет взаимодействовать с продуктом, чтобы дизайн соответствовал их потребностям и ожиданиям;
сценарии и бизнес-процессы — описания или схемы, которые показывают, как пользователи будут двигаться по системе, какие шаги им предстоят;
ограничения — технические, юридические и временные, которые могут повлиять на возможные решения и дизайн интерфейса;
структура данных — информация о том, что будет отображаться на экране, откуда данные берутся, как они организованы и как должны быть показаны пользователю;
ключевые правила и условия — например, кто может увидеть кнопку, когда поле обязательно для заполнения, какие действия происходят при ошибке или успешной операции;
артефакты — mind map, BPMN, user flows, таблицы требований и даже скриншоты из старых систем, которые могут помочь понять контекст и требования на более глубоком уровне.
Чем более детально и ясно передан этот контекст, тем меньше дизайнеру придется додумывать и «вытаскивать» недостающие куски. Хорошая передача данных экономит время и силы и помогает избежать ошибок на более поздних этапах.
Кто отвечает за логику
Ответственность за логику лежит на обоих специалистах, но с разным фокусом:
Аналитик продумывает бизнес-логику: как работает система, какие сценарии, условия, роли и процессы важны для достижения целей. Он смотрит сверху, исходя из бизнес-целей и задач проекта.
Дизайнер фокусируется на пользовательской логике: как человек будет двигаться по интерфейсу, что он увидит, что он должен сделать на каждом шаге, и будет ли ему понятно, что происходит. Он смотрит с точки зрения пользовательского опыта.
Обычно процесс выглядит так: аналитик формирует основу, описывая сценарий и бизнес-логику, а дизайнер проверяет, насколько это логично и понятно для пользователя. Часто процесс проходит через несколько итераций: дизайнер может предложить упростить путь пользователя, а аналитик проверит, не нарушит ли это бизнес-процесс или не вызовет ли конфликт с другими требованиями.
Идеально, когда аналитик и дизайнер работают с самого начала в тесном взаимодействии. Так они не накладывают UX на уже готовую схему, а создают её вместе, обеспечивая более гармоничное и эффективное решение.
В каких случаях один специалист может подменить другого
Подмена возможна, если у специалиста есть нужный опыт и насмотренность, но это скорее временное решение, а не норма.
Аналитик может подменить дизайнера, если:
нужно быстро накидать черновой прототип для обсуждения;
типовой экран, и интерфейс достаточно понятен без глубокой проработки;
дизайнер ещё не подключён.
Дизайнер может подменить аналитика, если:
аналитика еще не подключили, но надо уже начать работать с сырыми требованиями — их может начать собирать дизайнер, но нужно учитывать, что они будут проработаны достаточно поверхностно;
задача срочная, и нет времени ждать формализации;
дизайнер умеет мыслить сценариями и самостоятельно валидирует логику.
Однако такие случаи работают только на простых проектах. В более сложных системах, особенно B2B, подмена ведёт к ошибкам: кто-то может упустить важное бизнес-правило, а кто-то усложнит интерфейс. В таких случаях гораздо эффективнее работать вместе, чем на подмене.
Когда на проекте хватит дизайнера, а когда нужен аналитик
Так случилось, что на нашем проекте ERP-системы какое-то время в роли аналитика выступал только дизайнер. Это решение было временным, и, как оказалось, не совсем удачным. Без четко сформулированной бизнес-логики и структурированной информации от аналитика, возникали проблемы с пониманием процессов и целей системы. Мы поняли, что важно разделять эти роли, чтобы каждый специалист фокусировался на своей области и эффективно дополнял работу друг друга.
Для себя мы выработали такое понимание, когда стоит привлекать аналитика, а когда на проекте хватит только дизайнера:
Дизайнера будет достаточно, если:
проект достаточно простой: например, лендинг, промо-страница или стандартный интерфейс;
задачи ориентированы на визуальные изменения: улучшение UI, создание адаптивного дизайна или обновление элементов интерфейса;
клиент точно знает, что он хочет, и нет сложных логических связей.
А вот аналитик становится необходим, если:
проект масштабный, включает в себя множество ролей, прав доступа и бизнес-правил;
требуется проработка множества сценариев, условий и переходов;
клиент сам не всегда уверен в своих требованиях и порой не совсем чётко понимает, что именно ему нужно;
в проекте присутствуют интеграции, сложные процессы или нестандартные кейсы.
Если система не просто отображает информацию, а активно с ней работает, учитывая множество переменных и условий — без аналитика не обойтись. В таких случаях его роль становится критически важной для того, чтобы всё работало правильно и логично.
Когда же все-таки заканчивается аналитика и начинается дизайн?
На первый взгляд, может показаться, что эти два этапа работы — линейный процесс, где один специалист передает эстафету другому. Но на практике всё не так однозначно. В нашем подходе аналитика и дизайн не разделены четкой границей — они переплетаются, дополняют друг друга и работают параллельно.
Аналитик занимается созданием каркаса: он определяет цели, разрабатывает сценарии, выявляет ограничения. Дизайнер же «обтягивает» этот каркас, превращая его в функциональный и удобный интерфейс, который будет понятен пользователю. Важно понимать, что оба специалиста одинаково работают с логикой, оба взаимодействуют с командой и клиентом, и оба влияют на конечный результат.
Разница заключается в подходе: аналитик фокусируется на бизнес-логике и процессе, дизайнер — на восприятии и взаимодействии пользователя с системой. Несмотря на эти различия, для успешного проекта важно, чтобы аналитик и дизайнер не просто выполняли свои задачи по очереди, а работали в тесной связке с самого начала.
Резюме
Идеальный процесс работы над сложным проектом — это не передача «эстафеты» между аналитиком и дизайнером, а их совместная работа, где каждый привносит свою экспертизу и вместе создают продукт, который соответствует как бизнес-целям, так и потребностям пользователей.