Как согласовать дизайн, если у проекта пять заинтересованных сторон
Макет готов и отправлен на согласование. Через день в одном треде правка от заказчика «сделайте ярче», в другом — от маркетолога «это не бьётся с брендбуком», в третьем — от разработчика «так не соберётся на мобильном», а ещё продакт просит сдвинуть акцент на другую кнопку, и пятый голос — руководитель проекта — просто хочет «побыстрее». Пять стейкхолдеров — пять версий одного макета, и ни одна правка не учитывает остальные четыре. Решить это можно не перепиской, а процессом: назначить, кто решает, развести правки по типу и держать все голоса в одном месте. Если такой процесс нужно выстроить с нуля, этим на аутсорсе занимается студия UI/UX-дизайна YuSMP Group.
Почему пять голосов дают пять разных версий одного макета
Дело не в том, что кто-то из пяти неправ или действует со зла. У каждого стейкхолдера своя зона ответственности и свой критерий «хорошо»: заказчик смотрит на бренд и ощущения, маркетолог — на конверсию, разработчик — на реализуемость, продакт — на метрики продукта. Когда у этих пяти критериев нет приоритета между собой, любая правка звучит одинаково весомо, и дизайнер остаётся один на один с задачей всех помирить. Без явного порядка решений обсуждение превращается в переговоры, а не в согласование.
Кто из пяти стейкхолдеров прав, если мнения расходятся?
Правильный ответ — не «тот, кто громче» и не «тот, кто последний написал», а тот, за кем закреплено финальное решение по проекту. На каждый проект нужен один человек (иногда два — например, заказчик и продакт), у которого есть право поставить точку, если правки конфликтуют. Остальные четверо остаются полноценными участниками обсуждения — их мнение собирается и учитывается, — но решение принимает не большинство голосов, а назначенный ответственный. Это снимает с дизайнера роль третейского судьи и превращает спор в рабочий процесс с понятным выходом.
Не все правки весят одинаково
Удобно заранее развести пятерых стейкхолдеров по весу их голоса, а не разбираться в этом в моменте каждого спора. Обычно получается три уровня: кто-то один решает окончательно, двое-трое дают содержательный совет, который стоит выслушать, а остальные просто в курсе происходящего и могут прокомментировать постфактум. Такое разделение не нужно формализовывать в сложную таблицу — достаточно проговорить его один раз в начале проекта и держаться этого порядка, когда правки начинают сыпаться одновременно.
Разделяйте правки по типу, а не по тому, кто их написал
Вторая ось, которая реально экономит время, — не «кто прислал правку», а «что эта правка меняет». Смысловые правки трогают саму задачу: другой посыл, другой сценарий использования, другая структура экрана. Визуальные и технические правки — это детали реализации в рамках уже согласованной задачи: цвет, отступ, поведение на узком экране. У этих двух типов разный путь: смысловую правку нельзя тихо внести в макет, её нужно обсудить с тем, кто отвечает за финальное решение, а визуальную — можно обработать сразу, без эскалации. По наблюдениям Nielsen Norman Group, структурированное ревью с чёткой привязкой комментария к типу и месту правки заметно снижает число повторных итераций по сравнению с обсуждением «в общем» — то же правило работает и когда голосов пять, а не один.
Три шага, чтобы собрать правки от всех в одном месте
Первый шаг — единый тред на самом макете, а не в почте, мессенджере и на созвоне одновременно: каждая правка от любого из пяти стейкхолдеров оставляется прямо на элементе, к которому относится. Второй шаг — статус по каждой правке: открыто, в работе, закрыто, чтобы не нужно было помнить, кто что уже сказал. Третий шаг — финальное решение фиксируется там же, в треде, а не пересказывается голосом на следующей встрече. Эти три шага работают с одним стейкхолдером и с пятью одинаково — просто при пяти цена их отсутствия выше.
Чек-лист перед запуском согласования с несколькими стейкхолдерами
Назначьте одного ответственного за финальное решение до того, как разошлёте макет. Сообщите всем пятерым, какой у них уровень голоса — решает, советует, в курсе. Разведите ожидаемые правки на смысловые и технические ещё до старта обсуждения. Соберите всех участников в одном треде на макете, а не в пяти разных каналах. Фиксируйте решение сразу в этом же месте, не оставляя его только в созвоне.
