Что там по передаче макетов в разработку.
В Фигме вот вернулись к традиционному)

Rogie King из Фигмы рассказал, как они делали генеративные плагины и шейдеры. Он хотел начинать каждый дизайн с рабочего прототипа: собрал с нейронкой, потыкал, поправил и показал команде. Но разработчикам, продактам и остальным участникам оказалось неудобно использовать такие прототипы как основу для обсуждения. Дизайнерам они помогали проверять идеи, а договариваться всей командой было сложнее.

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

– Запрос упал;
– Данных пока нет;
– У пользователя нет доступа;
– Вместо двух слов в названии приехала простыня.

Это уже мои примеры. Даже если дизайнер всё предусмотрел, разработчику надо как-то добраться до каждого варианта. Тут нажми, сюда введи вот это, теперь подожди. Ой, сработало, а надо было, чтобы упало)) И так по каждому экрану. На макетах можно положить состояния рядом и сразу увидеть, где забыли ошибку или куда пропала кнопка.

Меня бы тоже напрягало постоянно звать кого-то, чтобы он провёл экскурсию по прототипу. Хочется открыть файл, посмотреть нужный экран, оставить коммент и пойти дальше. А прототип уже потыкать, когда проверяешь переходы и само взаимодействие. Команда Фигмы в итоге так и стала работать.

А вы сейчас как передаёте макетики? У кого какие лайфхаки, делитесь в комментах, интересно посмотреть

———

💻 Вакансии в IT и digital
😍 Про дизайн
🔥 Вакансии дизайнерам
🎨 Референсы

🎨 Как подобрать палитру и не отдать решение нейросети

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

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

Внутри:
– Чем отличаются RGB, CMYK, HEX и HSB;
– Как использовать монохромные, аналоговые, комплементарные и триадные схемы;
– Зачем нужно правило 60–30–10;
– Как проверить контраст и понять, куда падает внимание;
– В каком порядке описывать палитру, объекты и сюжет в промпте.

➡️ Читать статью

———

💻 Вакансии в IT и digital
😍 Про дизайн
🔥 Вакансии дизайнерам
🎨 Референсы

Перенести клиентский сайт с конструктора с помощью AI 👀

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

Коля Алексеев, основатель студии Fluid, описал такой кейс. AI-агент проходил сайт страницу за страницей и собирал его заново на собственном коде. Ему удалось сохранить и внешний вид, и позиции в поиске.

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

📌 Что внутри:
• Как настроить среду и подготовить скиллы;
• Как сохранять правки в правилах, чтобы каждый раз не объяснять одно и то же;
• Claude Code или Codex: что выбрать под задачу;
• Какие инструкции и инструменты дать агенту, чтобы меньше переделывать за ним.

🙂 А 16 сентября в 18:00 мск Коля проведёт эфир и соберёт с агентами клиентский сайт по настоящему ТЗ, от дизайна до CMS. Можно будет посмотреть, как он ставит задачи и доводит сайт до рабочего состояния.

🔠 Забрать бесплатный гайд

🧱 Дизайн-система должна хранить решения, а не только компоненты

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

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

Внутри:
– Почему библиотеки компонентов сами по себе не создают единую систему;
– Какие решения чаще всего остаются только в головах и старых макетах;
– Как разложить страницу настроек на поведение, строки, группы и общий шаблон;
– Что меняется, когда правила описаны рядом с компонентами;
– Как использовать ИИ-агентов, чтобы находить места, где продукт начинает расходиться.

➡️ Читать статью

———

💻 Вакансии в IT и digital
😍 Про дизайн
🔥 Вакансии дизайнерам
🎨 Референсы

🤖 Что получилось из ИИ-продакта и команды агентов

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

За неделю система выполнила около 350 задач в четырёх направлениях. При этом быстро выяснилось, что автономность сама по себе не гарантирует эффективность: агенты начали дробить работу, придумывать лишние правила и многократно перепроверять малозначимые вещи. После ретроспективы процессные задачи сократили с 75% до 25%, а кросс-ревью и передачу задач между моделями автоматизировали.

Внутри:
– Как связаны ИИ-продакт, бэклог с контекстом и конвейер исполнителей;
– Почему агенты заходят в тупик, когда видят только свою задачу;
– Как избыточные гейты и контроль превращают автономную систему в бюрократию;
– Какие изменения помогли сократить лишнюю процессную работу;
– Где проходит граница между полезной автономностью и работой ради самой работы.

➡️ Читать статью

———

💻 Вакансии в IT и digital
😍 Про дизайн
🔥 Вакансии дизайнерам
🎨 Референсы

📈 Как измерять влияние UX-исследований

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

Единицей измерения может быть рекомендация, найденная проблема или клиентская метрика. Для каждого результата фиксируют проект, заказчика, дату и текущий статус. В 2025 году показатель влияния исследований составил 78%, но команда использует его прежде всего для разбора причин и улучшения взаимодействия с продуктом.

Внутри:
– Почему количество исследований плохо подходит для оценки их пользы;
– Как устроена трёхуровневая модель влияния;
– Какие статусы получают рекомендации и проблемы после исследования;
– Как работать с отклонёнными результатами;
– Почему исследовательская команда должна быть партнёром продукта и участвовать в Discovery.

➡️ Смотреть видео

———

💻 Вакансии в IT и digital
😍 Про дизайн
🔥 Вакансии дизайнерам
🎨 Референсы