Худший дизайнер в компании — это я. И вот почему это помогает продукту

Неожиданная польза от работы в роли худшего дизайнера

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

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

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

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

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

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

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

Что разработчик видит, а дизайнер — нет

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

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

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

Быстро, грубо, но по делу: сила 'временных' решений

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

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

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

Когда дизайн мешает, а простота спасает

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

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

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

Как плохой старт приводит к хорошему продукту

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

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

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

Вопросы и ответы

Автор · Разработчик

Виолетта Кармышева

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

Профиль эксперта на ExpertRank →