UX/UI дизайн как система. Как принимать решения, работать с данными и не бояться команды

3.1. Вступление

В первых двух главах мы разобрали две ошибки: «синдром Dribbble» (когда дизайнер рисует картинку вместо решения) и «гипотезы вместо людей» (когда дизайнер гадает вместо того, чтобы исследовать). Ты научился проверять дизайн на пять секунд, формулировать гипотезы и проверять их на реальных пользователях.

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

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

Приходит задача — и дизайнер сразу открывает Figma. «Сделай попап», — говорят ему, и он делает. Без вопросов. Без попытки понять, зачем это нужно. Просто открывает макет и начинает рисовать, потому что «сказали — значит, надо».

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

И если предыдущие две ошибки (перегруженный визуал и гадание без исследований) ещё можно списать на неопытность, то слепое следование ТЗ — это уже про профессиональную позицию.

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

«Уметь аргументировать свои решения»;

«Навык работы с продуктовыми метриками»;

«Опыт участия в стратегических обсуждениях».

Потому что слепое исполнение стоит денег. И времени. И доверия команды.

3.2. История первая. Максим снова ошибается

Помнишь Максима? Он уже прошёл через две ошибки — перестал рисовать неон и научился проверять гипотезы. Он даже загордился: «Всё, теперь я настоящий профессионал».

А потом получил новое задание от продакта:

— Срочно! Заказчик хочет чат-бота с ИИ на главной. Сделай красиво, похоже на ChatGPT.

Максим открывает Figma. Начинает рисовать. А внутри уже шевелится сомнение: «Чат-бот? Зачем? У нас же есть поиск и фильтры. Зачем пользователю спрашивать у бота то, что он может найти за пару кликов?»

Но он молчит. Продакт сказал «срочно» и «заказчик хочет». Значит, надо делать.

Он рисует. Отправляет. Чат-бота запускают.

Проходит месяц. Аналитика: ботом воспользовались 3% пользователей. Остальные просто не поняли, зачем он нужен. Заказчик звонит:

— Мы потратили деньги, а результат — ноль. Почему вы не предложили другое решение?

Продакт смотрит на Максима:

— Ты же дизайнер. Почему ты не сказал, что бот — плохая идея?

Максим замирает. Он сделал, что сказали. Или он должен был спросить?

3.3. История вторая. Алиса

Пока Максим рисовал чат-бота, Алиса получила точно такое же задание:

— Срочно! Заказчик хочет чат-бота с ИИ на главной.

Но Алиса не открыла Figma. Она открыла рабочий чат и написала продакту:

— Хорошо, я сделаю, но прежде, чем начать, давай уточним: зачем нам чат-бот? Какую задачу мы решаем?

Продакт замялся:

— Ну… заказчик хочет казаться современным. Чтобыбыло как у всех.

Алиса:

— Поняла. А какая у нас цель? Мы хотим увеличить продажи? Улучшить поддержку? Сократить время поиска товара?

Продакт:

— Ну, наверное, чтобы пользователи быстрее находили товары.

Алиса:

— Отлично. А сейчас пользователи как ищут товары? Через поиск и фильтры, да?

Продакт:

— Да.

Алиса:

— Тогда давай посмотрим на данные. У нас есть аналитика по поиску и фильтрам? Сколько времени пользователи тратят на поиск? Какие фильтры используют чаще всего?

Продакт скинул данные. Алиса посмотрела и увидела:

80% пользователей находят товар через поиск за 10–15 секунд;

фильтры используют 60% пользователей;

жалоб на сложность поиска — почти нет.

Алиса сделала вывод: пользователям не нужен чат-бот. Они и так быстро находят товары.

Она написала продакту:

— Я посмотрела данные. У нас нет проблемы с поиском — пользователи находят товары быстро. Если мы добавим чат-бота, мы потратим ресурсы на фичу, которую никто не будет использовать. Но я вижу другую проблему: 20% пользователей бросают корзину на этапе оформления заказа. Может, вместо чат-бота сделаем упрощённую форму оформления?

Продакт посмотрел на данные, подумал и сказал:

— А знаешь, ты права. Давай сделаем форму.

Проект запустили через две недели. Упрощённая форма сократила число брошенных корзин на 15%. Заказчик был доволен.

Алиса потратила на анализ данных 2 часа. Максим потратил 3 дня на дизайн чат-бота и получил переделку.

В чём разница?

Алиса — профессионал, который знает, как работать с системой. Она понимает, что дизайн начинается не с Figma, а с вопросов и понимания задачи. Максим — всё ещё исполнитель. И эта разница видна в результатах.

3.4. Что такое «слепое следование ТЗ» и почему это опасно

Суть одна: ты делаешь то, что сказали, не пытаясь понять, зачем это нужно.

Перегруженный визуал или гадание без исследований — это ошибки, которые пройдут с опытом. Но слепое следование ТЗ — это не ошибка. Это выбор. Ты либо берёшь ответственность за результат, либо перекладываешь на того, кто написал ТЗ. Ты либо задаёшь вопросы и ищешь лучшее решение, либо просто делаешь, что сказали.

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

Как выглядит слепое следование ТЗ на практике:

Ты не задаёшь вопросов: «Сказали — делаю».

Ты не предлагаешь альтернатив: «Как в ТЗ написано — так и рисую».

Ты не знаешь бизнес-цели: «Мне дали задачу, я её выполняю».

Ты не вникаешь в контекст: «Какая разница, кто пользователь?»

Ты не защищаешь свои решения: «Мне так сказали».

Почему это опасно:

Ты становишься «исполнителем» — тебя не воспринимают как эксперта.

Ты теряешь время — делаешь то, что не нужно.

Ты теряешь доверие — команда не видит в тебе партнёра.

Ты подводишь команду — твой дизайн не решает реальную проблему.

Ты теряешь интерес к работе — рисовать по команде скучно.

В этой главе мы разберём:

почему дизайнеры боятся задавать вопросы;

как перевести «сделай попап» в осмысленную задачу;

как задавать правильные вопросы, чтобы не подвести команду;

как превратиться из исполнителя в партнёра.

3.5. Погружение в проблему

3.5.1. Почему дизайнеры боятся задавать вопросы

Причины те же, что и в прошлой главе — человеческие, понятные, но опасные.

Причина №1. «Я не хочу казаться глупым»

Новичок боится, что, если он задаст вопрос «А зачем мы это делаем?», то его сочтут некомпетентным. Вдруг это очевидно для всех, а я один не понимаю? Лучше промолчу и нарисую.

Как с этим справиться:

Задавать вопросы — это не слабость. Это профессионализм. Тот, кто задаёт вопросы, выглядит как человек, который вникает в суть. Тот, кто молча рисует ерунду, выглядит как исполнитель, которому всё равно.

Попробуй переформулировать свой страх. Вместо «Я боюсь показаться глупым» скажи себе: «Я хочу понять суть задачи». Вместо «Они подумают, что я не знаю» скажи: «Они увидят, что я хочу сделать хорошо».

Запомни: если ты не задаёшь вопросов — ты не управляешь процессом. Ты просто плывёшь по течению. А потом оказывается, что ты нарисовал не то.

Причина №2. «Мне дали ТЗ — я делаю»

Новичок воспринимает ТЗ как «закон». Так написал менеджер/продакт/заказчик — значит, так надо. Спорить нельзя, а то уволят.

Как с этим справиться:

ТЗ — это не закон. Это гипотеза. Это попытка решить проблему. И твоя задача — помочь найти лучшее решение, а не просто нарисовать то, что написано.

Попробуй воспринимать ТЗ как «входные данные», а не как «приказ». Спроси себя: «Какую бизнес-задачу мы решаем?», «Какая у нас цель?», «Что мы хотим изменить?». А потом уже думай, как это сделать лучше.

Ты — эксперт. Ты знаешь, как делать правильно. Твоё мнение ценно. Не бойся его предлагать.

Причина №3. «У меня нет времени»

Дедлайн через два дня, а я буду задавать вопросы и тормозить процесс. Лучше быстрее нарисую и сдам.

Как с этим справиться:

Один вопрос «Зачем?» занимает 1 минуту. Одна альтернатива — 10 минут. Переделка — дни, а иногда и недели.

пять минут на уточнение → экономит пять дней переделок.

десять минут на альтернативу → экономит неделю споров с командой.

один вопрос «А что, если?» → спасает от провала в аналитике.

Время на вопросы — это не потеря времени. Это инвестиция в то, чтобы не делать лишнюю работу.

Причина №4. «Я не знаю, какие вопросы задавать»

Это самая честная причина. Новичок не знает, с какой стороны подойти к задаче. Он просто не умеет задавать правильные вопросы.

Как с этим справиться:

Этому можно научиться. И мы сейчас научимся.

Начни с простого. Задавай 5W-вопросы (их мы разберём в следующем разделе):

Что? — Что мы делаем?

Зачем? — Какую проблему решаем?

Кто? — Для кого?

Когда? — В какой момент?

Где? — На каких устройствах?

Эти пять вопросов покрывают 80% того, что нужно знать, чтобы не нарисовать ерунду.

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

3.6. Решение и инструменты

3.6.1. Шаг 1. Задавай вопрос «Зачем?» (5W-вопросов)

Самый простой способ перестать слепо следовать ТЗ — задавать правильные вопросы. Я использую классическую схему 5W-вопросов:

What (Что?)— Что мы делаем? Что это за задача?

Why (Зачем?)— Зачем мы это делаем? Какую проблему решаем?

Who (Кто?)— Для кого мы это делаем? Кто наши пользователи?

When (Когда?)— Когда это будет использоваться? В какой момент?

Where (Где?)— Где это будет работать? На каких устройствах?

Пример. «Сделай попап с подпиской»

Разбираем её по пяти вопросам:

Что мы делаем?— Попап с подпиской на новости.

Это задача, но не цель.

Зачем мы это делаем?— Чтобы собрать базу подписчиков.

Это реальная цель, которая стоит за задачей.

Для кого мы это делаем?— Для новых пользователей, которые зашли на сайт впервые.

Это наша целевая аудитория.

Когда это будет использоваться?— Сразу после загрузки главной страницы.

Это момент, когда пользователь видит интерфейс.

Где это будет работать?— На десктопе и на мобильных устройствах.

Это технические условия использования.

Теперь задача выглядит иначе: не «нарисуй попап», а «реши задачу по сбору базы подписчиков среди новых пользователей при входе на сайт, учитывая все устройства».

3.6.2. Шаг 2. Переводи ТЗ в задачу

Простой алгоритм, который я использую:

Прочитай ТЗ.

Задай вопрос: «Какую проблему мы решаем этим функционалом?»

Переформулируй ТЗ в задачу: «Мы хотим [решить проблему] для [пользователей]».

Предложи 2–3 способа решения (не только тот, что в ТЗ).

Пример:

Было: «Нарисуй попап с подпиской».

Стало: «Собрать базу подписчиков для новых пользователей на главной странице. Варианты решения: попап, баннер, встроенная форма, текстовый блок с кнопкой в хедере».

Теперь ты — дизайнер, который предлагает решения, а не просто «рисует по команде».

3.6.3. Шаг 3. Предлагай альтернативы

Самый сильный ход, который показывает, что ты эксперт, — предлагать альтернативы.

Алгоритм:

Нарисуй вариант из ТЗ («как просили»).

Нарисуй 1–2 альтернативных наброска («а что, если сделать иначе?»).

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

Аргументированно предложи лучший вариант.

Пример для попапа:

Твой аргументированный выбор:

«Я предлагаю сделать баннер на главной, потому что он менее навязчив, чем попап, и даёт пользователю время ознакомиться с контентом. Попап я тоже нарисовал, но он может снизить конверсию на 30% по нашим данным».

3.6.4. Шаг 4. Как отстаивать своё решение перед командой

Этот навык приходит с опытом, но есть несколько проверенных приёмов.

Приём №1. «Давайте проверим гипотезу»

Вместо того чтобы спорить, предложи проверить.

«Я предлагаю сделать баннер вместо попапа. Давайте запустим А/В-тест: половине пользователей покажем попап, половине — баннер. Через неделю посмотрим, где выше конверсия и ниже отказы. Если баннер проиграет — мы всегда можем вернуться к попапу».

Это снимает напряжение и делает тебя партнёром, а не спорщиком.

Приём №2.«Давайте посмотрим на данные»

Если у тебя есть данные — ты неуязвим.

«По данным наших аналитиков, 70% пользователей закрывают попап, не читая. Баннер на главной даёт больше вовлечения. Поэтому я предлагаю его».

Приём №3.«Давайте спросим у пользователей»

Если данных нет — проведи мини-исследование.

«Давайте спросим у пять пользователей, что им больше нравится — попап или баннер. Это займёт пятнадцать минут, а мы примем решение на основе фактов, а не догадок».

3.6.5. Шаг 5. Скрипт для диалога с заказчиком

Вот готовый скрипт, который я рекомендую использовать, когда получаешь ТЗ (техническое задание), с которым не согласен.

Пример диалога:

Заказчик: «Нарисуй попап для подписки на главной».

Ты: «Хорошо, я нарисую, но, прежде чем начать, давай уточним: зачем нам попап? Какую задачу мы решаем?»

Заказчик: «Мы хотим собрать базу подписчиков».

Ты: «Понял. А для кого мы это делаем? Какие пользователи заходят на главную?»

Заказчик: «Новые пользователи, которые впервые на сайте».

Ты: «Я вижу два решения. Первое — попап, как ты просил. Второе — баннер на главной, который не перекрывает контент и даёт пользователю время ознакомиться с сайтом. Давай я нарисую оба варианта, и мы выберем лучший. Или, если хочешь, мы можем провести А/В-тест и посмотреть, что работает лучше. Что ты думаешь?»

Заказчик: «Звучит разумно. Давай оба варианта».

Разница заметна? Ты не просто «рисуй попап» — ты стал частью процесса принятия решения. Ты — партнёр, а не исполнитель.

3.6.6. Шпаргалка: что спросить у заказчика перед тем, как начать

Держи эту памятку под рукой — она экономит часы.

Какую проблему мы решаем?Без этого ты рисуешь фичи, а не решения.

Кто наша целевая аудитория?Без этого ты рисуешь для себя, а не для пользователей.

Какие у нас есть данные?Опираться на факты лучше, чем на догадки.

Какие есть ограничения?По времени, бюджету, технологиям.

Как мы будем измерять успех?Метрики — твоя защита и доказательство.

3.6.7. Шаг 6. Что делать, если заказчик настаивает на своём

Иногда заказчик категоричен. Он сказал «попап» — и будет попап.

Что делать в таком случае:

Сделай как он просит.

Но добавь параллельный тест: «Я нарисую попап, как ты просишь. Но давай параллельно протестируем альтернативный вариант — баннер. Через неделю сравним результаты».

Если тест невозможен — сделай как просят, но в портфолио этот проект можешь не показывать.

Пример Алисы в такой ситуации:

Заказчик настаивал на чат-боте на главной странице, чтобы собирать контакты пользователей. Алиса сказала:

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

Заказчик согласился. Чат-бота запустили, он показал низкие цифры. Через месяц запустили форму в корзине — и она собрала в 3 раза больше контактов, потому что пользователи уже были вовлечены в процесс покупки.

Алиса не спорила, но показала альтернативу, которая решала ту же бизнес-задачу. И в итоге оказалась права.

3.7. Итог: алгоритм действий

Вот чёткая последовательность шагов, которая поможет тебе перестать быть исполнителем и стать партнёром:

Прочитай ТЗ.

Задай вопрос «Зачем?» — какую проблему мы решаем?

Переформулируй ТЗ в задачу — «Мы хотим решить проблему Х для пользователей Y».

Предложи 2–3 альтернативы — не только ту, что в ТЗ.

Аргументированно предложи лучший вариант — с данными, если они есть.

Если заказчик настаивает — сделай как просит, но предложи параллельный тест.

3.8. Резюме

ТЗ — не закон. Это гипотеза. Твоя задача — проверить её и предложить лучшее решение.

Задавай вопрос «Зачем?». Это превращает тебя из исполнителя в партнёра.

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

Умей отстаивать своё решение. Используй данные, гипотезы и А/В-тесты.

Ты — дизайнер-стратег, а не «рисовальщик». И команда относится к тебе соответственно.

3.9. Практическое задание

Возьми свой текущий проект (или любой старый макет) и сделай три вещи.

Задание 1. Проанализируй ТЗ

Если у тебя есть ТЗ — выпиши из него все требования. Теперь задай по каждому пункту вопрос «Зачем?». Что ты узнал? Запиши свои выводы.

Задание 2. Предложи альтернативу

Для одного из пунктов ТЗ предложи 2 альтернативных решения. Опиши, почему они лучше или хуже. Запиши свои аргументы.

Задание 3. Разыграй диалог

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

3.10. Чек-лист для самопроверки

□ Я задал вопрос «Зачем?» и понял, какую проблему мы решаем.

□ Я знаю, кто моя целевая аудитория.

□ Я знаю, какие данные у нас есть по этой задаче.

□ Я предложил альтернативы, а не просто сделал «как в ТЗ».

□ Я могу аргументировать, почему выбрал именно это решение.

□ Я готов защищать своё решение перед командой.

3.11. FAQ

— А если заказчик не хочет слушать альтернативы и просто говорит «делай как я сказал»?

Если заказчик категоричен — сделай как он сказал. Но добавь к своему ответу фразу: «Я нарисую, как ты просишь, но параллельно предлагаю протестировать и альтернативный вариант. Через неделю мы сравним результаты». Иногда заказчики соглашаются на параллельный тест, потому что это безопасно.

— А если у меня нет времени на вопросы и альтернативы?

Один вопрос «Зачем?» занимает одну минуту. Альтернатива — десять минут. Переделка — день. Считай сам.

— А если я задаю вопросы, а коллеги раздражаются, что я торможу процесс?

Если коллеги раздражаются — значит, они не привыкли к такому подходу. Объясни им: «Я задаю вопросы, чтобы мы сделали правильно с первого раза. Это сэкономит нам время и нервы». Обычно это снимает раздражение.

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

— А что, если я не знаю, какую альтернативу предложить?

Используй ChatGPT или почитай, как делают у конкурентов. Или спроси у продакта: «А какие ещё варианты ты видишь?». Обычно они сами подсказывают, если их спросить.

— А если я предложил альтернативу, но команда всё равно выбрала вариант из ТЗ? Как быть, если я знаю, что это неправильно?

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

В большинстве случаев лучшее, что можно сделать — это предложить параллельный тест: «Давайте запустим оба варианта и посмотрим, что покажут данные». Это снимает напряжение и переводит спор в конструктивное русло. Если тест невозможен, а команда всё равно настаивает на своём — прими решение большинства.

Запись несогласия в протоколе имеет смысл только в двух случаях:

Когда цена ошибки критически высока (например, юридические или финансовые риски).

Когда это входит в твои прямые обязанности (например, если ты архитектор решения или тимлид).

В остальных случаях главное — ты не промолчал. Ты предложил альтернативу, аргументировал, предложил проверить. Дальше — доверяй команде. Иногда они видят контекст, который не виден тебе.

3.12. Связка с другими материалами

Мы разобрали третью ошибку. Теперь ты знаешь, как не быть слепым исполнителем, как задавать вопрос «Зачем?» и предлагать альтернативы. Ты научился смотреть на ТЗ не как на приказ, а как на гипотезу, которую можно и нужно проверять.

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

Но есть ещё одна проблема.

Он всё ещё слишком много рисует. Слишком детально. Слишком продуманно. Слишком идеально.

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

И это — четвёртая ошибка. Она называется «Замок вместо MVP» (или «дворец вместо дома», как мы будем её называть в этой книге). Это про перфекционизм, который убивает продукты. Про страх показать сырой прототип. Про неумение вовремя остановиться и спросить: «А что, если мы проверим гипотезу на самом простом решении?»

В следующей главе мы разберём, как перестать строить дворцы и начать с простого. Как понять, что такое MVP и почему он спасает продукты. И как убедить команду, что «просто» — это нормально.

А пока — подумай: не строишь ли ты дворец там, где достаточно дома?

4.1. Вступление

В первых главах мы разобрали три ошибки: «синдром Dribbble» (когда дизайнер рисует картинку вместо решения), «гипотезы вместо людей» (когда дизайнер гадает вместо того, чтобы исследовать) и «слепое следование ТЗ» (когда дизайнер просто исполняет, не задавая вопросов). Ты научился проверять дизайн за пять секунд, формулировать гипотезы и превращать ТЗ в осмысленные задачи.