Bullshit-бинго: От оператора Figma к соавтору фичи

Это — вторая статья из серии Bullshit-бинго. Здесь я фокусируюсь на процессе ведения задачи и какая роль дизайнера во всём этом. Первую часть — про когнитивные искажения — можно почитать здесь.

«Сколько ещё будет правок?», «Когда уже будет финал_финальный.fig?» или «Опять полгода что-то делали, но работа ушла в стол».

Знакомо? В Bullshit-бинго, кажется, сыграл каждый дизайнер. Часто после этого приходит выгорание и чувство, что твой вклад обесценен. У меня было так же, когда я работала линейным дизайнером. Когда стала дизайн-лидом и начала регулярно наблюдать за работой команд, я пришла к тому, что дизайн — это не только макеты и юзабилити. Это также люди и принимаемые ими решения. Умение задавать вопросы, влиять на вектор, быть внутри процесса.

В этой статье:

1. Теория. Путь задачи в продукте

2. На практике всё немного иначе. Роль дизайнера

3. Основная мысль

В продуктовых командах задачи часто движутся по HADI-циклам — коротким экспериментам из четырёх этапов: Hypothesis → Action → Data → Insights (гипотеза → действие → данные → выводы). Каждый этап раскладывается на привычные шаги: постановка задачи, ресёрч, генерация идей, концепт, подготовка макетов, разработка, запуск и анализ результата.

Циклов может быть один или несколько: каждый — это небольшой, обратимый эксперимент, который при необходимости можно откатить без ущерба для всей системы. В идеале процесс идёт в два витка: сначала проверяем гипотезу в «лабораторных» условиях (например, на качественных интервью, тестировании прототипов или fake-door-экспериментах), затем — «на бою», на настоящих пользователях. Это снижает риск негативного влияния на метрики и помогает не тратить дорогой ресурс разработки впустую. Ниже на схеме — пример классического набора этапов.

Если говорить честно, — в реальной работе над задачами не всё так красиво и складно, как в теории. Сроки горят, «сделать надо было вчера», и процесс неизбежно подстраивается под быстрый результат. В такой обстановке и случается типичная ошибка: дизайнера подключают слишком поздно — на этапе «двигаем пиксели», без погружения в контекст вначале и участия в подведении итогов. Это может происходить по разным причинам: продакт или заказчик приходят с готовым решением — у дизайнера банально не было шанса включиться раньше; либо сам дизайнер, получив задачу, не задаёт уточняющих вопросов и сразу уходит в Фигму.

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

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

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

Как быть дизайнеру?

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

👉 Попроси сформулировать Definition of Done (DoD). Это набор критериев, на которые согласны все участники и по которым понятно, что цель достигнута. Не ко всем творческим задачам подходит, но часто выручает.

👉 Проговорите ожидания. Уточни у заказчика, каким он видит финальный результат и на какие компромиссы готов пойти.

👉 Задавай уточняющие вопросы. Даже если всё кажется очевидным: что именно улучшаем, почему сейчас, как поймём, что получилось?

👉 Зафиксируй роли (если заказчиков несколько). Кто принимает решение, кто консультирует, кто делает, кого просто информируем. Это помогает держать фокус и не пытаться угодить всем и сразу.

Этот этап возникает в двух случаях: когда мы проверяем концепт на прототипах в «лаборатории» и когда выкатываем изменения на продовую аудиторию. В обоих сценариях часто повторяются одни и те же проблемы: этап просто пропускают; нет единого источника истины (в Figma одно, в Jira другое, в Notion третье); отсутствует сегментация — мы смотрим на «среднюю температуру по больнице» и делаем выводы уровня «кажется».

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

Как быть дизайнеру?

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

👉 Если сбор данных не проводился – инициируй. Объясни заказчику, что для развития функционала важно понять, как показала себя первая версия.

👉 Если нет возможности проводить большие исследования, запусти «корридорку». Даже быстрые проверки дают полезные инсайты.

На этом этапе задача либо закрывается с флагом «гипотеза сработала», либо застревает в цикле бесконечных доработок. Основные ошибки: выводы подменяются мнениями без опоры на данные и критерии успеха, следующий шаг не продуман (команда обсудила выводы и закрыла вопрос).

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

Как быть дизайнеру?

👉 Фиксируй результаты фичи. После запуска обсуди, что получилось, а что нет вместе с командой. Даже короткий разбор — уже вклад в общий контекст.

👉 Связывай выводы с критериями успеха. Уточни у заказчика/продакта: Подтвердилась ли первоначальная гипотеза? Достигли ли мы ожидаемых результатов? Какие наши дальнейшие шаги?

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

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