Разработка дизайна интерфейсов и приложений, которую заказывают без торга и студий

Почему заказ дизайна мобильного приложения не может стоить 40 000 рублей и как не сжечь бюджет на красивых, но бесполезных макетах. Статья для владельцев продуктов и команд, которые хотят результат: рост метрик, ускорение TTM и дизайн, который доходит до продакшна.

За последние 16 лет я прошёл путь от дизайна логотипов и айдентики до проектирования сложных интерфейсов и продуктовых систем. Работал с командами самого разного калибра — от стартапов на коленке до экосистем вроде Telegram и Тинькофф.

В одном из конкурсов по продуктовому дизайну я сделал приложение Wallet так, что Telegram присудил первое место — из более чем 300 участников со всего мира.

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

А ещё я веду курс по дизайну приложений и интерфейсов, после которого мои ученики устраиваются в Тинькофф, Сбер, Альфу, ВК, Cuberto и к Чулакову.

Почему рассказываю это всё здесь? Потому что ты, скорее всего, ищешь не просто дизайнера, а кто сделает эффективный интерфейс, который:

• помогает бизнесу расти;
• не ломается при передаче в разработку;
• вызывает «вау» не на Dribbble, а у пользователей.

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

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

Как дизайн превращается в убытки?

Проблема процессов и методологии разработки на примере создания дизайна мессенджера

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

Мы делали дизайн, передавали разработке, они начинали в нём копаться. А потом… возвращались. Снова. И снова. И снова.

• А что делать, если пользователь закрыл пуш, но не дошёл до верификации?
• А если кнопка сужается до 180 пикселей?
• А где вариант для тёмной темы?
• А мы не можем сделать эту штуку, так как в ядре бэкенда это отсутствует.

И ладно бы один раз. Но это стало системным. Мы тратили часы (если не дни) на уточнения и доработки того, что можно было бы учесть заранее, если бы подключили технических ребят до начала дизайна, а не после. Это не UX-проблема. Это — проблема процессов.

В какой-то момент я решил просто посчитать, сколько стоит одна такая «недоговорённость»? Ответ получился неприятный: около 40 000 рублей на одну фичу. Чисто на дизайн.

Дизайнер возвращается в работу, переключается, делает новую итерацию, снова согласует, снова заливает. А потом это всё проходит тестирование, баг-репорты, фиксы. Задержка увеличивается, Time to Market растёт.

А если таких фич десять? Ну, ты понял. 400 000 рублей в воздух. Только из-за того, что мы вовремя не собрали требования. Ни с разработкой, ни с тестированием. Мы просто сделали «дизайн». Без условий. Без ограничений. Без контекста. И это — только одна фича. А что если речь не про корпоративную разработку, а про обычный веб-сайт или лендинг, где всё должно быть просто и ясно?

Лендинг с кормами для животных, который даже не попытался продать

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

Окей, я пошёл посмотреть. Зашёл на лендинг. И за 3 секунды понял, что я бы тоже ушёл, потому что нет УТП, нет изображения продукта на первом экране, кнопки «заказать» на первом экране тоже нет. Делиться скриншотами с этого кейса я не могу.

Каталог спрятан так, как будто его стесняются, на первом экране — милые мордочки собак, которые можно найти в любом стоке. А ощущение такое, что я попал в блог ветеринара, а не на сайт магазина. Это не просто слабый дизайн. Это — отсутствие смысла. В результате ты сидишь на встрече с маркетологом, обсуждаешь, почему стоимость лида выросла на 40%. А дело в том, что никто не мог найти каталог.

Сколько теряет фирма?

Потери? Давай посчитаем. Допустим, сайт получает 500 визитов в день (а у них примерно так и есть). Пусть хотя бы 30% этих людей — реальные потенциальные клиенты, то есть 150 человек. И пусть даже 10% из них готовы были бы купить. Это 15 заказов в день.

Средний чек у них — около 1500 рублей. Умножаем: 22 500 рублей в день. В месяц? Почти 700 000 рублей. И это только то, что можно было бы зарабатывать — просто поставив нормальный текст, УТП, понятную кнопку и не заставляя клиента думать, где, чёрт побери, каталог.

Но и это не всё. Решил пройти путь до конца — попробовать сделать заказ. Добавляю товар в корзину. Нажимаю «оформить». Выбираю самовывоз. И что я вижу? Адреса нет. Карты нет. Пункта нет.

Чтобы понять, где мне забирать корм, мне нужно:

• либо вернуться на главную;
• либо искать «Контакты» где-то в футере;
• либо просто плюнуть и закрыть сайт.

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

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

Потому что дизайн — это не про красивых собак. Это про понятный путь до покупки. Без багов. Без лишних вопросов. Без ухода на сайт конкурента. А теперь представим, что проблема даже не в кнопке, а в самом основании интерфейса — в том, для кого вообще это сделано. Вот история из крипты.

Когда ты не знаешь, для кого Wallet — ты делаешь его в стол

Во время конкурса по редизайну Wallet для Telegram всем поставили конкретную задачу: сделать криптокошелёк, понятный новичкам. Не «удобный», не «в стиле Web3», не «на хайпе» — а такой, чтобы человек, который слышал про крипту только из мемов, мог зайти и разобраться без паники.

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

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

А если мы подключим новую ЦА?

И вот представь, что владельцы таких криптокошельков завтра решат расшириться и привлечь новых пользователей. Не продвинутых ребят с Binance, а обычных людей, которые просто хотят «хранить деньги, но в крипте». Что им придётся делать? Пересобрать продукт. Полностью. С нуля.

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

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

Без понимания ЦА на выходе будет пустышка

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

Когда я проектировал Wallet, я не открывал Figma, пока не собрал контекст. Я провёл ресерч, почитал отзывы, полазил по Reddit, Discord и Appstore посмотрел, что бесит людей, которые пробуют крипту впервые. Я искал не идеи, а паттерны. Поведение. Барьеры. Потому что хороший интерфейс — это не кнопки на сетке, а сценарий, в котором пользователь знает, что делать и не чувствует себя идиотом.

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

Когда за 10 миллионов ты получаешь дизайн на 40 тысяч

Я не шучу. Иногда компании заказывают дизайн у топовой студии, платят 5–10 миллионов рублей — и получают на выходе тот же уровень макетов, который мог бы сделать обычный фрилансер за 40 тысяч. Такой же визуал, такая же структура, такая же Figma. Только с логотипом студии на презе.

Почему так происходит? Потому что ты платишь не за дизайн. Ты платишь за менеджмент. За цепочку людей, которые между тобой и дизайнером.

Твоя заявка уходит к менеджеру по продажам. Потом её обрабатывает проектный менеджер. Ещё кто-то из аккаунтинга. Возможно, оператор, который забивает встречи. Потом тимлид. Потом продуктовый менеджер. И только где-то в конце — дизайнер. Один. С обычной Figma и обычным опытом. Такой же, как у того самого фрилансера.

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

Ты платишь миллионы — и думаешь, что платишь «за уровень». А на деле платишь за операционный жир, который тратится не на продуманность продукта, не на UX, не на ресерч, а на то, чтобы каждый в цепочке получил свою долю. Это как заказать кофе, в котором 80% — пена из молока, и только в самом дне — глоток эспрессо.

Что в итоге после заказа дизайна у студии?

В итоге получается тот же макет, только дороже. Не потому, что дизайнер был плох. А потому что вся система выстроена так, чтобы оправдывать цену, а не приносить результат. Ты получаешь макеты от «топовой» студии, открываешь — и думаешь: «Погодите, а за что я заплатил 10 миллионов?»

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

Когда ты ждёшь от дизайнера «всё и сразу» — продукт выходит на рынок слишком поздно

Одна из самых распространённых ошибок — строить работу последовательно: дизайнер сначала делает всё, полностью и до последнего пикселя. Только потом проект отдают в разработку. Макеты передаются как чемодан. Красивый, но без ручки. Внутри всё есть: экраны, описания, спеки, адаптивы. Но вместо ускорения это превращается в тормоз.

Так работает половина рынка — и именно это убивает TTM

Пока дизайнер корпит над визуалом, разработка просто ждёт. Потом начинается передача, и сразу же выясняется: в макетах нет нужных corner-кейсов, не проработаны ошибки, нет реакций на особенные стейты (состояния ui-элементов). Если не знакомы с тем, что такое TTM (Time To Market), рекомендую ознакомиться здесь.

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

А теперь представь, что ты ещё и фаундер

Ты ждёшь результата, чтобы показать инвесторам или партнёрам. А команда копает в сторону, потому что интерфейс ещё не финален. И каждый день задержки стоит тебе денег — зарплаты, аренды, трафика, выгорания. Time to Market увеличивается. Бюджет — тоже. И всё из-за того, что работа шла не параллельно, а «сначала это, потом это».

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

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

Дизайн — не этап, а часть системы

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

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

Перед началом любого дизайна я спрашиваю: Кто будет разрабатывать? Как устроен процесс? Есть ли техлид? Будет ли QA? Какие сроки, какая методология, есть ли у команды опыт внедрения дизайна? Потому что если дизайнер не вписан в разработку — он будет мешать. Он не ускорит процесс. Он его остановит.

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

Красиво — не значит прибыльно: что бизнес должен понять до начала работ

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

До того как дизайнер откроет Figma, бизнесу важно ответить на два простых вопроса:

• Что мы хотим изменить с помощью дизайна?
• Как мы поймём, что это сработало?

Метрики — то, что превращает красивый макет в работающий инструмент

У разных продуктов — разный набор метрик. Например, если у тебя продуктовая команда, твоя главная боль — это Time to Market. Чем позже ты выходишь на рынок, тем выше твои издержки: зарплаты, багфиксы, контекстные переключения команды.

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

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

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

Я вижу, насколько важно, как человек взаимодействует с текстом: остался он до конца статьи или ушёл после первого заголовка? Возвращается ли он завтра? Читает ли он другие материалы? На основе этого мы уже переделали часть интерфейсов, адаптировали структуру и шлифуем сценарии взаимодействия.

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

Но метрики — это только половина уравнения. Вторая часть — это люди и процессы, которые будут превращать дизайн в живой продукт. Кто занимается разработкой? Какой у вас стек? Есть ли техлид и QA? Будет ли методология вроде Scrum или Kanban? Или вы планируете работать в духе «нарисуем всё, а потом начнём делать»?

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

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

Что бывает, если этого не сделать?

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

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

Если ты дочитал до этого места, у тебя, скорее всего, уже есть один из трёх выводов:

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

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

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

Так, чтобы дизайнер был не тормозом, а рычагом. Не декоратором, а частью команды. Не поставщиком пикселей, а проводником между идеей и результатом.

Что происходит после «давайте сделаем дизайн интерфейса»

Окей, ты всё понял. Вопросы заданы. Цели зафиксированы. Метрики определены. Команда есть, стек понятен, сроки обозначены. Самое время начать делать. Вот только если начать неправильно — даже с этим всем можно наломать дров.

Потому что дизайн — это не файл с макетами, который отдают ссылкой на «Фигму». Это процесс. Многослойный, цикличный и живой. Где всё взаимосвязано: исследование влияет на сценарий, сценарий — на архитектуру, архитектура — на дизайн-систему, а система — на то, насколько легко будет поддерживать продукт через полгода.

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

Шаг 1: не знаешь платформу — не знаешь, что проектировать

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

Дизайн, который не учитывает платформу, работает против продукта. Он создаёт макеты, которые невозможно натянуть на реальность — потому что у iOS, Android, десктопа и веба совершенно разные правила игры.

Если ты делаешь интерфейс под iOS, то автоматически подчиняешься Human Interface Guidelines. Это касается не только внешнего вида, но и логики поведения компонентов: как открываются модалки, какие анимации считаются «нормой», где должны быть табы, как работают свайпы. В AppStore даже требования, что попасть туда можно только при соблюдении гайдлайнов.

Android, в свою очередь, строится на принципах Material Design: там свои карточки, другие навигационные паттерны, своя логика работы с UI-состояниями. Делать один макет и «как-нибудь адаптировать» — не получится. Придётся понимать платформенные принципы и учитывать их заранее. Хотя, бывают исключения, когда лучше сделать кастомизированный дизайн.

А если к мобильной версии добавляется ещё и веб? Тут появляются новые требования: адаптивность, изменение поведения интерфейса при повороте устройства, горизонтальные и вертикальные ориентации на планшетах, масштабирование в браузерах.

На десктопе — свои нюансы: ресайз окна, работа с клавиатурой и модалками, курсорные взаимодействия, стейты вроде hover, focus, active, pressed. Всё это — отдельные сценарии и состояния.

Пример: мессенджер, где всё работало по-разному

Когда я проектировал интерфейс мессенджера, продукт должен был работать одновременно в вебе, на мобильных и в десктоп-приложении.

Уже на этапе проектирования стало ясно: делать «одну универсальную версию» бессмысленно. То, что отлично ощущается на десктопе — выпадашки, наведение, сочетания клавиш — на мобильных просто не работает. И наоборот: жесты и свайпы, которые интуитивны на смартфоне, в вебе и на десктопе теряются.

Если бы мы не определили платформенные требования на старте, команда бы утонула в бесконечных правках. Каждый баг превращался бы в уточнение: «а как это должно работать тут?», а у дизайнеров и разработчиков горели сроки, потому что архитектура макетов не предусматривала гибкости.

От выбора платформы зависит структура всей дизайн-системы

Платформа влияет не только на макеты и UX-дизайн, но и на то, как будут организованы сами файлы и папки в Figma, особенно если речь идёт о дизайн-системе. В зависимости от того, под какие платформы ты работаешь, по-разному строится:

• архитектура файлов и папок (например, отдельный кат под мобайл, отдельный под веб);
• логика связей между компонентами (включая разветвления по платформам и breakpoints);
• структура библиотек (в одной — токены, в другой — мобильные кнопки, в третьей — десктопные компоненты);
• логика версионирования и обновлений с помощью Change Logs.

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

Пример: лендинг, который не пережил адаптив

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

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

Пример: как itsets.ru подстраивается под разное использование

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

Именно поэтому чтение комфортно и на десктопе, и в Safari на айфоне, и в горизонтальной ориентации на планшете. А навигация по статьям работает на любом девайсе.

Что происходит, если этого не учесть?

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

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

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

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

Шаг 2: открыть глаза, а не «Фигму»

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

Вот почему прежде, чем нарисовать хоть один экран, нужно задать вопрос: а что вообще нужно сделать? И для кого?

Без исследования ты просто дёргаешься в темноте

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

Мы говорим о классических инструментах:

• анализ конкурентов — чтобы не наступить на те же грабли;
• Jobs To Be Done — чтобы понять, какие «работы» пользователь хочет выполнить через твой продукт;
• коридорные тестирования — чтобы увидеть, где интерфейс рассыпается ещё до кода;
• формирование user flow и user story — чтобы понимать не только, что должен делать пользователь, но и в каком порядке, почему, с каким контекстом.

Пример исследования для Wallet для Telegram — как выиграть конкурс, а не просто поучаствовать

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

Перед стартом я почитал RoadMap проекта The Open Network. Установил десятки криптокошельков. Посмотрел, как они устроены. Сколько экранов до пополнения. Где пользователь путается. Где ему становится страшно. Почитал отзывы на Reddit, комментарии в сторах, покопался в обсуждениях. И понял: 80% интерфейсов сделаны для тех, кто уже в теме. А новичкам там делать нечего.

Именно это исследование показало мне, где можно отстроиться, где упростить путь, какие паттерны взять у Telegram, чтобы кошелёк ощущался как продолжение мессенджера, а не инородное приложение.

В итоге — первое место среди 300+ участников. Не потому что пиксели были круче. А потому что интерфейс был понятен и естественен. Потому что я начал не с Figma, а с людей. Почитать кейс стади по проекту вы можете здесь.

Jobs to be done: не одна потребность — а целый контекст

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

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

Кейс: как коридорное тестирование спасло логику мессенджера

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

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

Решение? Мы вынесли процесс создания канала в боковую панель, которая не перекрывает основной интерфейс. Это дало возможность многозадачности: ты можешь настраивать канал и параллельно шариться по чатам. Вроде мелочь, а UX-паттерн получился уникальным. Его бы просто не было — если бы не тестирование.

User Flow и User Story — это не просто блок-схемы, это каркас продукта

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

User Flow помогает описать путь, а User Story — мотивацию. Вместе они создают логичную структуру будущего интерфейса. Без неё ты просто раскидаешь кнопки по экрану. С ней — ты проектируешь навигацию, поведение, последовательность, реакцию интерфейса.

Итог простой

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

Именно исследование показывает тебе слабые места до того, как ты их нарисуешь. А значит — до того, как ты их оплатишь.

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

Шаг 3: прототип и дизайн логики без визуала

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

На этом этапе я не «рисую дизайн». Я собираю интерактивный скелет — страницы, экраны, базовые переходы. Всё максимально просто: без цветов, шрифтов, визуала. Только структура. Цель — проверить, работает ли логика. Достигает ли пользователь нужной цели? Не запутался ли он? Нет ли провалов, тупиков, петлей и странностей?

Именно на этом этапе всплывает большинство логических ошибок. Их сложно поймать, когда смотришь на flow в виде схемы. Но стоит пройти его вживую, как будто ты — пользователь, и сразу всё видно. Это также можно сделать на смартфоне с помощью Figma Mirror.

Примеры, как помогали прототипы

Проектировал платформу с созданием мероприятий. По сценарию сначала заполняешь карточку, потом зовёшь участников. Но в процессе кликанья по интерактивному прототипу оказалось: многим удобнее звать людей заранее. Сценарий начал разваливаться. Пришлось перестроить флоу. Хорошо, что не в UI. Не в коде. Не в проде.

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

Что даёт интерактивный прототип

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

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

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

Шаг 4: не нарисовать, а собрать архитектуру: как начинается UI-дизайн

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

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

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

Дизайн фичи = начало библиотеки

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

В этот момент начинается двойная работа:

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

Что значит «не просто нарисовать кнопку»

У любой ui-кнопки (если делать по уму) есть светлая и тёмная тема. Есть обычное состояние, наведённое, нажатое, неактивное. Есть размеры: маленькая, средняя, широкая. Есть типы: primary, secondary, destructive, link. И всё это должно быть не просто в макете, а в структуре библиотеки, чтобы завтра другой дизайнер или разработчик не гадал: «а как эта кнопка себя ведёт, если пользователь нажал на неё с телефона ночью?»

Та же история с аватаркой. В корпоративном мессенджере, который я делал, аватарка — это не просто фотка. Это может быть:

• просто фото;
• фото с зелёным кружочком (онлайн);
• фото с серым кружочком (офлайн);
• аватарка в списке;
• аватарка в шапке;
• аватарка при создании канала;
• аватарка с загрузкой.

Если не учесть все эти состояния, разработка будет либо спрашивать бесконечно, либо придумывать сама. И, как правило, не в ту сторону.

Архитектура начинается сверху: токены и уровни

Я всегда начинаю библиотеку с верхнего уровня — с того, что влияет на всю систему. Это:

• цвета;
• шрифты;
• спейсеры (отступы);
• брейкпойнты (адаптив);
• радиусы скруглений;
• иконки;
• графические паттерны.

Это основа. Это то, на чём держатся все остальные компоненты. Если здесь будет бардак — дальше будет только хуже.

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

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

Почему это важно?

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

Я много раз видел, как команды работали без компонентов. Сначала всё идёт бодро, макеты летят, фичи собираются. А через полгода — хаос. Интерфейсы не похожи друг на друга. Кнопки разные. Цвета не совпадают. Никто не понимает, что уже готово, а что надо рисовать. В итоге — дорого, медленно и больно.

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

Шаг 5: корнер-кейсы и подготовка документации

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

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

Что может пойти не так?

Например:

• Пользователь начинает оформление заказа, и у него отваливается интернет. Что тогда?
• Сервер присылает ошибку. Что видит пользователь? Ошибка 500? Или понятное сообщение?
• Пользователь нажал «назад», потом снова «вперёд», и данные сбросились. Почему?
• Он открыл экран, а нужных данных ещё нет — они грузятся. Что на экране в этот момент?
• Окно ресайзится, блоки расползаются. Всё ещё нормально?

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

Как я это решаю

Я собираю флоу в прототип. Не просто кликабельную картинку, а интерактив, через который можно пройти. А потом начинаю тестировать — как пользователь, как идиот, как разработчик, как QA. Смотрю, где всё рассыпается.

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

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

Из прототипа — в спецификацию

После того как я проработал корнер-кейсы, начинается этап описания флоу и технических спецификаций. Это значит, что:

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

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

Когда спецификации готовы, наступает этап QA-ревью и технического ревью перед передачей в разработку. Это предпоследний шаг.

Шаг 6: QA-ревью, техревью и зачем дизайнеру возвращаться в проект после разработки

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

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

Почему дизайнер — не бог, и ошибки бывают у всех

Даже если дизайнер опытный, внимательный и всё продумал — он человек. А значит, какие-то детали можно было пропустить. Где-то забыли про стейт ошибки. Где-то не описали поведение при обрыве связи. Где-то компонент есть в макете, но его состояния не задокументированы. Всё это выясняется на этом этапе.

Если QA или разработка находят такие места, они не делают «ау, у нас баг». Они просто возвращают фичу на доработку. И дизайнер снова подключается — дополняет спецификацию, фиксит макеты, добавляет описания. Это не баг. Это нормальный цикл. Без него — фичи в проде превращаются в лотерею.

Когда фронт и бэк готовы — начинается финальный акт: дизайн-ревью

Этот этап обычно упускают. Типа, «макеты были», «всё по ним сделали», «что там дизайнеру проверять?». И это огромная ошибка. Потому что именно на дизайн-ревью становится видно, где макеты развалились при разработке.

Что происходит? Разработчики заливают фичу на тестовый сервер. И теперь — внимание — дизайнер сам личнооткрывает это решение на тех устройствах, под которые делался дизайн. Не просто смотрит скриншоты. А проверяет живой продукт.

Потому что только вживую видно:

• совпадают ли отступы;
• ведёт ли себя компонент так, как задумывалось;
• нет ли багов в стейтах;
• как работает адаптив;
• не поехала ли типографика;
• не превратился ли аккуратный интерфейс в компот из костылей.

Что делать, если что-то пошло не так?

Если фича выглядит не так, как было задумано — не паниковать и не ссориться. Дизайнер просто составляет список доработок: что не так, как должно быть, что нужно поправить, что критично, а что — можно отложить. Это может быть простой документ или даже отдельная доска задач.

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

Почему без дизайн-ревью ты теряешь деньги

Если ты пропускаешь этот этап — ты заливаешь продукт в прод с багами. Да, не техническими, а смысловыми. Дизайн становится «примерно как задумывалось». И вся работа, которую ты оплатил на старте — UI, UX, библиотека компонентов, тестирования, спецификации — вылетает в трубу.

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

Дизайн-ревью — это финальный фильтр

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

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

В следующей части покажу, как понять, может ли дизайнер пройти через всё это, не сгорев и не испортив систему — и что стоит проверить, прежде чем нанимать кого-то на проект.

Проверка на прочность: что должен уметь дизайнер, чтобы не сжечь бюджеты компании

Много где можно встретить дизайнеров, которые классно делают шотики на Dribbble. Но когда дело доходит до реального продукта, бюджета, сроков и разработки — всё разваливается.

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

Если ты хочешь, чтобы дизайн не горел вместе с деньгами — проверь, умеет ли дизайнер делать следующие вещи.

Дизайнер, который не думает о стейтах — ставит мины для разработки

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

Если дизайнер этого не предусмотрел — разработка либо задаёт сто вопросов, либо делает «по-своему». В первом случае срываются сроки. Во втором — срывается логика.

Проверь: дизайнер умеет мыслить не экранами, а компонентами в живом окружении? Может ли объяснить, как кнопка работает не только в хедере, но и в футере? Что будет с карточкой, если её воткнуть в сетку на три колонки? Лучший способ проверить дизайнера или студию — попросить показать какой-либо рабочий файл.

Дизайнер без спеки — как инженер без чертежа

Токены — это не «новомодная штука». Это стандарт. Если в макете нет токенов спейсингов, размеров, цветов, типографики — это не макет, а картинка.

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

Всё это превращается в документацию, которую потом читает не дизайнер, а разработчик. Если документации нет — разработка фантазирует. А фантазии в проде стоят дорого.

Баланс между «хочу» и «могу»: зрелость в работе с ограничениями

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

Если дизайнер не понимает, что из его идей стоит x2 в разработке, он просто не видит бизнесовую сторону задачи. А значит, он не поможет тебе сэкономить. Он не подскажет, где можно упростить, чтобы не потерять смысл. И не предложит компромисс, когда фича нужна срочно, а разработка горит.

Хороший дизайнер всегда работает на грани между «круто» и «целесообразно». И если сейчас дорого — он спокойно отложит идею в бэклог. Без истерик. Без обид. Потому что понимает: результат важнее понтов.

Версионирование — или «где чёрт возьми последняя версия макета?»

Ты не поверишь, сколько компаний теряют время просто потому, что никто не знает, какая версия макета актуальна. Особенно если дизайнер не умеет вести change log, не подписывает версии, не ведёт структуру обновлений.

Фича уходит в прод, в Figma уже другая версия, разработка работает по третьей. Макеты начинают расходиться с реальностью. Возникают баги. Все нервничают. Продукт — в бардаке.

Хороший дизайнер ведёт документацию. Фиксирует изменения. Подписывает версии. Держит систему в порядке. Потому что понимает: Figma — это не для него одного, это — для всей команды.

Владеет Figma на уровне? Значит, онбординг будет быстрым, а проект — масштабируемым

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

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

Настоящий профи работает в Figma так, чтобы через два месяца другой дизайнер открыл файл и понял, как тут всё устроено. Это значит:

• правильные названия компонентов;
• структура файлов;
• переиспользование токенов;
• документация прямо в макетах;
• онбординг для новых участников проекта.

Если этого нет — каждый новый дизайнер будет начинать с нуля. А каждый новый разработчик — с догадок. И вместо продукта ты получишь лоскутное одеяло из чужих решений.

В следующей части расскажу, почему нормальный дизайн не может стоить 40 000 рублей и что на самом деле включает в себя работа, если ты хочешь, чтобы она приносила деньги, а не просто занимала место в Figma.

Дизайн мобильного приложения или веб-интерфейса стоит не 40 000 рублей и вот, почему

Если ты слышал фразу «30 экранов за сорок тысяч рублей» — просто улыбайся и уходи. Не потому, что ты сноб. А потому, что в 99% случаев это не работа — это косплей на дизайн. Без смысла, без стратегии, без понимания, как интерфейс живёт после отрисовки.

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

Цена — это не про количество экранов

Хочешь знать, сколько стоит дизайн? Спроси сначала: что именно ты хочешь получить. Если цель — «мне просто нужно, чтобы было красиво» — да, можно найти студента за 40 тысяч. Он скинет тебе Figma-файл с десятком кнопок и скажет: «всё готово». А дальше — как получится.

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

Что входит в нормальный дизайн?

Я сейчас не про «красоту» и не про «подбор цвета по чакрам». Я про процессы. Вот из чего складывается настоящая работа:

• Погружение в бизнес. Без него ты рисуешь абстракцию.
• Исследования и аналитика. Кто ЦА? Что уже есть на рынке? Где слабые места конкурентов?
• Прототипирование. Без логики — любой визуал превращается в головную боль.
• UI-дизайн: компоненты, токены, стили, тёмная тема, интерактив.
• Спецификации: чтобы не было догадок у разработчиков.
• Внедрение: фича доходит до продакшна, а не заканчивается на слайде в презентации.
• Поддержка: итерации, правки, ревью, масштабирование.

Это не значит, что всё это нужно всегда. Но чтобы понять, что именно нужно — надо в это погрузиться. Узнать, на какой ты стадии. Кто в команде. Какие цели. Какие риски. И только потом можно говорить про цену.

Почему дизайн за 40 тысяч — это не про результат

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

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

Почему студия за 10 миллионов тоже не всегда лучше

Другая крайность — «топовая студия». Цена — как за разработку ракеты. А на выходе — те же экраны, что мог бы сделать дизайнер с фриланса за 40 тысяч.

Разница в чём? В счёте. Потому что ты платишь за менеджмент. За встречи. За отчётность. За репутацию. А не за качество дизайна. И если не задать правильные вопросы в начале — ты не заметишь подмену.

Дизайн — это не стоимость экрана, а стоимость результата

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

Вот как может выглядеть работа:

• Если у тебя стадия идеи — мы ищем структуру, смыслы, гипотезы.
• Если у тебя есть MVP — усиливаем UX, находим слабые места, делаем редизайн под цели.
• Если ты в активной разработке — встраиваемся в процесс, делаем по фичам, без остановок.

Хочешь точную оценку — напиши. Расскажи, на какой стадии проект, кто в команде, чего хочешь достичь. Я подскажу, что важно сейчас, а что можно отложить.

Я не за то, чтобы брать дорого. Я за то, чтобы результат был не в макете, а в метриках. И именно поэтому мои клиенты платят без торга. Потому что знают, что я не рисую — я проектирую то, что будет работать.

Ситуации, в которых я отказываюсь от проекта

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

Иногда ты открываешь описание проекта — и всё понятно с первых строк. Хорошие люди, добрые цели. Но сделать что-то путное просто не получится. Потому что сроки нереальные. Или задачи неадекватные. Или проект изначально построен на костылях, которые никто не хочет переделывать. В таких случаях я честно говорю «нет».

Не потому что капризничаю. А потому что знаю: если сейчас промолчать — потом всё равно прилетит. И мне, и тебе. А оно нам надо? Вот три самые частые причины, по которым я отказываюсь от работы:

Если за 2 рубля надо добавить третий вид кнопок

Ты смеёшься, но такие запросы прилетают. «Нам просто надо быстро вставить ещё одну кнопочку, мы сами нарисовали». Звучит просто. Только за ней тянется флоу, UI-система, состояния, поведение. И в итоге ты переделываешь полинтерфейса ради одной «простой» кнопки. Нет уж.

Если задача — просто нарисовать макет в Фигме

Без логики, без флоу, без понимания, кто и как это будет реализовывать. Типа, «ты просто нарисуй, а там мы сами разберёмся». Опыт показывает: не разберутся. Потом будет боль. И претензии. Я так не работаю.

Если всё нужно вчера

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

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

Часто задаваемые вопросы

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

Сколько времени занимает проект?

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

Поэтому, если тебе сразу называют точные сроки (без погружения в бизнес, продукт и процессы), скорее всего, тебе просто хотят продать коробку. Я так не работаю. Я сначала вникаю, потом считаю. И только после этого называю сроки.

Работаешь ли ты в команде клиента?

Да, если нужно. Я могу встраиваться в процессы команды — как внешний специалист, не оформляясь в штат. Если тебе важно, чтобы я был на всех синках, в Notion, Jira, Miro, Telegram и любом другом месте под названием «рабочий процесс» — не вопрос, обсудим. Всё зависит от формата и договора.

Можно ли сделать только аудит?

Можно. Если у тебя уже есть интерфейс, и ты хочешь понять, что с ним не так — я подключаюсь, провожу аудит, показываю, где дыры и чем они опасны. Определяем точку А, фиксируем точку B, составляем план. Сколько будет стоить, кто нужен, какие этапы не избежать. Без воды и презентаций на 100 слайдов.

Ты делаешь только приложения или сайты тоже?

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

А вот если ты хочешь креативный лендинг с красивыми буквами, неоновыми тиграми и формой «оставь e-mail, и мы перезвоним» — это не ко мне. Я не арт-директор с дриббла. Я системный дизайнер. И беру в работу то, где могу принести результат, а не просто повтыкать в фигму с фоном под видео.

Всегда ли процесс такой сложный или есть исключения?

Бывает проще. Если ты на старте, у тебя MVP, нет команды, нет бюджета, и нужен быстрый результат — мы можем урезать процесс. Пропустить некоторые этапы. Или сделать их короче. Главное — понимать, что в результате ты получишь не арт-объект, а решение, готовое к тестированию.

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

Хочешь задать другой вопрос? Просто напиши мне в Telegram. Я не бот, отвечаю лично.

Если коротко: почему со мной стоит работать

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

• Встраиваюсь в продукт, а не рисую в вакууме. Понимаю процессы, команды, ограничения и задачи бизнеса.
• Думаю про метрики и рост. Не просто «красиво», а «эффективно» — чтобы рос retention, падал TTM и продукт зарабатывал.
• Работаю быстро, но с головой. Без тяп-ляпа и переделок.
• Вижу риски заранее. И заранее показываю, где будут дыры, если сейчас не подумать.
• Ко мне возвращаются. Потому что я не делаю картинку — я делаю интерфейс, который работает.

Что делать дальше с этой информацией?

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

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

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

Но если ты читаешь всё это и понимаешь: «Да, мне нужен такой подход. Мне нужен не декоратор, а человек, который вытащит мой продукт из хаоса и доведёт до результата» — просто напиши мне в Telegram.

Расскажи, на какой стадии проект, что за команда, чего хочешь достичь. Я посмотрю, что у тебя сейчас, предложу подход, помогу с планом и скажу честно — где стоит заморочиться, а где можно сэкономить.

Мне интересны проекты на разных стадиях — от MVP до крупных B2B-систем. Главное, чтобы у нас совпал фокус: сделать не красиво, а по делу. Если ты готов — пиши. Я отвечаю сам. И, если всё сойдётся, договоримся, когда обсудим твой проект.