От промпта до интерфейса: почему я больше не отдаю макеты дизайнеру

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

Граница между «нарисовать» и «закодить» стирается быстрее, чем я ожидала

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

Что я потеряла, отказавшись от отдельного этапа макетирования

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

Инструмент понимает форму хуже, чем вам кажется

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

Как я теперь формулирую задачу, чтобы получить не шаблон, а решение

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

Кому этот гибридный путь действительно подходит

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

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

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

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

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

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