Дизайнер, привет

Спасибо fable 5 за то, что успел сделать рефакторинг тарифов на hirehi уан шотом))) сделал с первого раза переписав плюс минус 1300 строк кода. Я даже офигел. Правда стоило это 60 баксов, которые щас висят долгом в курсоре 😂😂😂 Сегодня эту модель прикрыли и понятно почему. Она бешенная. То, что крутят внутри аи лаб я даже представить боюсь. Людям дают, думаю, не более 20% того, чем там пользуются. Получить доступ к новой модели по паспорту, биометрии и гражданству уже скоро. До этой точки недолго осталось)) Интересен ход Codex теперь.

Нужно собрать сайт на тильде. С дизайном. Дизайна нет, его нужно нарисовать. Визуально нужно сделать качественно, рефы есть. Если вы супер спец в тильде не за 1 млн рублей за страницу, напишите в лс пожалуйста сразу с примерами работ. Пока сообщение висит, значит еще актуально. @generalsupport

🚗 Интерфейс за рулём нельзя проектировать как обычное приложение Команда дизайна и исследований Делимобиля собрала гайд по безопасным интерфейсам для сервисов, которыми могут пользоваться в машине. Это не только про карты и навигацию. Сюда же попадают звонки, музыка, заправки и любые сценарии, которые человек хотя бы теоретически может открыть во время движения. Важная рамка здесь простая: сначала нужно спросить не «как сделать удобнее», а «должен ли водитель вообще делать это за рулём». Если нет, функция должна уходить в режим стоянки или автоматизироваться. Если да, интерфейс проектируется по другим правилам: меньше действий, выше читаемость, крупнее цели, понятнее состояние, меньше визуального шума. На скорости 60 км/ч одна секунда взгляда в экран это уже 16 метров без полноценного внимания к дороге. Внутри: – Почему водительский интерфейс нельзя считать упрощённой версией мобильного приложения; – Как решить, можно ли вообще оставлять сценарий доступным во время движения; – Почему лучшая функция для водителя часто та, которая не требует действия; – Какие правила помогают оценивать читаемость, контраст, шрифты и анимации; – Что разрешено делать за рулём, а какие сценарии лучше блокировать до стоянки; – Из каких компонентов собирать безопасные экраны для машины; – Почему дизайн-решения здесь оцениваются не только по удобству, но и по риску отвлечения; – На какие стандарты опирается гайд: ГОСТ, ISO, NHTSA и Android Automotive. ➡️ Читать гайд ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

💎 Митап про редизайн hh Редизайн большого продукта со стороны часто выглядит просто: обновили интерфейс, стало свежее, поехали дальше. Внутри всё обычно намного больнее. Есть старые долги, разные аудитории, метрики, бизнес-задачи, привычки пользователей и куча мест, где любое изменение может что-то сломать. 19 июня hh.ru проводит митап как раз про это. Будут разбирать редизайн hh как продуктовый процесс: как принимать решения, когда хочется сделать красиво, бизнес ждёт роста, а пользователям всё ещё должно быть понятно и удобно. Мне тут особенно интересен масштаб. hh это сервис, где есть соискатели, работодатели, личные кабинеты, b2b-страницы, важные сценарии и очень чувствительные зоны продукта. В таком редизайне нельзя просто «освежить визуал». Нужно договариваться, резать лишнее, выбирать приоритеты и понимать, какие хорошие идеи всё равно не доедут до продакшена. В программе два доклада:

Миша Пономаренко, дизайн-директор hh.ru «Редизайн продукта: что важнее обновлённого интерфейса, и нет, это не метрики»

Ксюша Зенина и Саша Ирхин «Главная не главная: совмещаем дружелюбный бренд и продуктовые метрики»

Будет полезно продуктовым дизайнерам и продактам, особенно если работаете с большими интерфейсами, где дизайн давно живёт рядом с метриками, компромиссами и внутренними ограничениями. ⏰ Когда 19 июня, сбор гостей с 18:30, старт в 19:00 Где: московский офис hh.ru, ул. 2-я Брестская, 48 🕹 Формат Офлайн и онлайн-трансляция в VK и YouTube После докладов будет афтепати, еда, напитки и разговоры про дизайн с продуктом. Офлайн-места ограничены, заявки рассмотрят заранее. 🔠Зарегистрироваться 🔠Зарегистрироваться

🚦 Как 2ГИС превратил «зелёную волну» в интерфейс Я кайфанул от статьи, это прям продуктово покопаться в таком незначительном элементе) Даня из команды Транспорт в 2ГИС рассказывает, как в навигаторе запускали подсказку для проезда светофоров без лишних остановок. Идея звучит просто: если известны состояния светофоров по маршруту, можно подсказать водителю скорость, при которой он попадёт в зелёную волну. Но в машине простой идеи недостаточно, потому что каждый новый элемент на экране конкурирует не с красивой пустотой, а с дорогой, маршрутом, манёврами, камерами и вниманием водителя. Самое интересное в кейсе, как команда искала форму для этой подсказки. Текстовые сообщения оказались слишком тяжёлыми, одно число требовало постоянного сравнения, а зона спидометра уже была занята предупреждениями. В итоге решение собралась из двух слоёв: плашка с диапазоном скорости даёт точность, а аналоговая шкала с зелёной зоной помогает быстро понять, в потоке ты или нет. Отдельно сильная часть кейса, что дизайнер не остановился на макетах, а полез в математику стрелки, код и параметры анимаций, чтобы фича доехала до релиза в нужном виде. Внутри: – Почему «просто показать скорость» оказалось плохой постановкой задачи; – Как интерфейс навигатора ограничивает любое новое решение; – Почему зелёная волна должна ощущаться как состояние, а не как уведомление; – Как диапазон скорости оказался понятнее одного целевого числа; – Зачем в интерфейсе появился аналоговый спидометр с зелёной зоной; – Как анимации помогают дать обратную связь без лишнего шума; – Почему дизайнеру пришлось проверять техническую реализацию самому; – Что 2ГИС планирует добавить дальше: награды за серию зелёных светофоров и новые города. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Одна из самых важных задач на hirehi в ближайшее время: сделать liquid glass на тогглы и сегмент контрол Это вам не в продукте работать, где это уберут через 12 спринтов. Это вот оно, очень важное и надо сделать. Чуваки вот сделали aave.com/design/building-glass-for-the-web И да, это ликвид в ВЕБЕ, ёмае) Я пока не представляю, как это сделать, но попробую. Если получится, будут самые красивые тогглы на вебе ЕВЕР

😜 Пользователи не врут. Они просто плохо помнят, как работают Кирилл Улитин и Стася Кабанова из МойОфис разбирают проблему, с которой сталкивается почти любое исследование: человек на интервью рассказывает не сам опыт, а его отредактированную версию. Он забывает мелкие действия, упрощает сценарий, пропускает автоматические шаги и иногда сам не замечает, как на самом деле обходит неудобства продукта. Поэтому команда попробовала контекстное интервью: сначала поговорить с пользователем, а потом смотреть, как он реально выполняет задачу в живой системе. В этот момент начинают проявляться вещи, которые нельзя достать обычными вопросами. Кто-то вытаскивает фотографию через инструменты разработчика, потому что интерфейс не дает скачать ее нормально. Кто-то раскладывает окна как личный рабочий дашборд. Кто-то компенсирует неудобство продукта связкой из нескольких приложений. Внутри: – Почему обычное интервью часто показывает логичную версию опыта, а не реальную; – Как внимание, память и социальная желательность искажают ответы пользователей; – Чем контекстное интервью отличается от глубинного интервью и юзабилити-теста; – Почему наблюдение помогает находить не только боли, но и обходные практики; – Когда можно просить пользователя выполнить задачу прямо во время исследования; – Зачем заранее предупреждать участника, что нужно будет показывать экран и рабочие действия; – Как диаграмма сходства помогает разобрать разрозненные наблюдения; – Когда контекстное интервью полезно, а когда оно не даст соразмерной ценности. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Простите, но я опять похвастаюсь. Буду это делать каждый раз на рекордах, а иначе кому мне ещё это делать. Я знаю, что десяток людей уже замотивировались моими действиями и это круто. Недавно было, но теперь вот прошая неделя вновь стала самой крупной по выручке в hirehi за всё время существования сервиса (2 недели подряд получается) А да, ещё и рекорд по кликам за день из гугла был 2 дня подряд тоже за всё время. SEO заработало получше. Не зря сидел)) А ещё сегодня общался с очень умным человеком, который был CEO и CPO во всеми известными компаниями и варился в эйчартехе очень плотно) Получил тонну полезного фидбека и направления. Дальше будем с ним держать контакт и, возможно, скоро рост будет оч быстрым) Я в это верю. Спасибо всем ❤️

#14 Фигма зовёт вайбкод обратно на холст Фигма выложила майский Workflow Lab про Code to Canvas. Если коротко: прототип, который вы собрали в коде через Cursor, Codex, Claude Code или другой агент, можно затащить обратно в Фигму как редактируемые экраны. Дальше уже смотреть флоу целиком, править компоненты, токены, состояния и при желании пушить изменения обратно в код. Сама связка «дизайн-код-дизайн» не новая. Интереснее другое. Последний год все очень радостно продавали вайбкодинг как короткий путь: написал промпт, получил интерфейс, запустил, погнал дальше. Типа Фигма больше не нужна, дизайнеры мешают скорости, агент сам всё соберёт. А потом выясняется, что быстро собранный экран всё равно надо где-то нормально посмотреть.

Вайбкодинг быстро даёт экран, но плохо показывает продуктовый сценарий целиком

В браузере ты видишь один экран. Иногда пару состояний, если не лень потыкать. В коде видишь компоненты, файлы, стили, условия. А продуктовый флоу целиком обычно расползается по вкладкам, роутам и «сейчас я тебе покажу, только сначала залогинюсь». Для разработки ок, для обсуждения интерфейса так себе. У меня так постоянно. Быстро сделал фичу, локально вроде работает, в голове всё ясно. Потом открываешь рядом несколько экранов и видишь: • кнопка называется иначе • пустое состояние забыто • фильтр ведёт себя странно • мобильная версия поехала • пользователь попадёт в тупик и будет смотреть на экран как на квест от плохого диза И всё. Твоя «почти готовая» фича уже не такая готовая В доке Фигма прямо описывает похожий сценарий. Агент берёт локальный прототип, переносит уникальные экраны на холст, использует компоненты и стили из дизайн-системы, добавляет страницу с саммари. Потом дизайнеры уже могут смотреть и чинить: где лишний элемент, где лучше взять нормальный компонент, где просела иерархия, где токены уехали итд Это хорошая роль для Фигмы. Она не обязана быть местом, где всё начинается. Иногда она может быть местом, куда продукт возвращается на проверку. Быстро накидали в коде, положили на холст, посмотрели весь сценарий, привели в чувство, отправили обратно в разработку. Тут, кстати, спор «фигма или код» становится совсем уставшим. В реальной работе чаще нужен круг: 1. быстро собрать рабочий вариант 2. увидеть весь флоу рядом 3. поправить продуктовую логику 4. вернуть изменения туда, где это реально живёт Главное, чтобы этот круг не превратился в новый ритуал ради ритуала. Типа сначала агент сделал экран, потом агент перенёс его в Фигму, потом агент поправил, потом агент вернул в код, а команда всё это время сидела и смотрела на красивую автоматизацию. Дизайнерское решение всё равно кто-то должен принять. Пока что, желательно человек. Что думаете? ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

🛡 Магия ИИ работает только там, где уже есть экспертиза Карина Веласкес рассказывает историю не про то, как Claude Code «сам собрал дизайн-систему», а про то, как накопленное знание наконец получило быстрый способ материализоваться. На работе она не могла использовать Claude Code, сервер Фигма MCP и другие инструменты из-за политики безопасности, поэтому взяла личный ноутбук, пустой файл в Фигме и за один пятничный день собрала Prisme, личную дизайн-систему с токенами, темами, компонентами и плагином для синхронизации. Самое интересное здесь не скорость сама по себе, а то, почему эта скорость сработала. Карина уже понимала архитектуру токенов: где нужны глобальные значения, где живут брендовые темы, как должен работать семантический слой, почему алиасы важны и чем нативный формат переменных Фигмы отличается от Token Studio JSON. Claude Code не придумал это за неё. Он просто оказался достаточно быстрым исполнителем, чтобы описание превращалось в структуру, структуру можно было сразу проверить, а ошибки быстро поправить. Внутри: – Почему сильный результат с ИИ начинается не с промпта, а с внутренней модели; – Как Фигма MCP позволяет работать с переменными и токенами без ручного кликанья в интерфейсе; – Зачем дизайн-системе нужны глобальный, брендовый и семантический слои; – Почему токены, которые живут только в Фигме, остаются артефактом, а не инфраструктурой; – Как Prisme Bridge переводит данные между Token Studio JSON и переменными Фигмы; – Почему кнопка стала хорошей проверкой всей токенной архитектуры; – Как Claude Code помог собрать компонент с размерами, состояниями, вариантами и заменяемыми иконками; ➡️ Читать статью (EN) ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

🔔 Inspiration #187 Подборка лендингов и сайтов для вдохновения на предстоящую неделю 🔥 – vectary.com – betternights.com – withcompound.com – typology.com ——— – strawberrybrowser.com – getnude.com – aupalevodka.com/en – tendril.studio – ousmaneballondor.fr ——— – proteanfunds.com – deux-ce.com – library.obys.agency – superstate.com – hut8.com ——— – after.design/face – ponpon-mania.com – lelezhang.design – microsoft.ai – easehealth.com ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

#13 Replit хочет дать агентам насмотренность Replit 15 мая добавил в каталог MCP новый сервер Lazyweb. Если коротко, он позволяет агенту искать по базе из 257k+ реальных экранов приложений. Replit прямо пишет: для UI-референсов и дизайн-исследований. На первый взгляд, маленькая новость из списка обновлений. Добавили ещё один MCP, ну ок. Но для вайбкодинга это довольно важная штука. Потому что сейчас у AI-интерфейсов есть очень узнаваемая болезнь. Попросил собрать сервис, личный кабинет, страницу вакансии, CRM или дашборд, и через минуту получаешь что-то аккуратное, чистенькое и до боли одинаковое. Карточки, табы, серые подписи, синий акцент, график, три метрики сверху. Всё вроде нормально. Только ощущение, что этот экран уже видел тысячу раз и ни один раз не хотел им пользоваться. Проблема часто не в том, что модель не умеет рисовать. Она рисует как среднее арифметическое интернета. А среднее арифметическое обычно выглядит как SaaS, который стесняется сказать, чем он занимается.

У агента появляется не только промпт, но и шанс посмотреть, как похожие задачи уже решили живые продукты

Это уже ближе к работе дизайнера. Перед тем как делать новый сценарий, ты смотришь, как это устроено у других. Не чтобы скопировать. Просто чтобы понять, какие паттерны вообще существуют, где люди обычно ошибаются, какие решения уже стали привычными, а где можно сделать иначе. Например, тебе надо собрать экран подписки. Вариант «сделай красиво» почти гарантированно даст три карточки с тарифами и зелёную кнопку. А если агент видит реальные примеры, он хотя бы может заметить детали: – где показывают ограничения тарифа – как объясняют пробный период – куда прячут отмену – как оформляют сравнение – где начинается тёмная сторона UX После этого уже можно спорить. Не с пустым экраном и не с абстрактным «сделай современно», а с конкретными паттернами. Это полезнее, чем бесконечно гонять модель по кругу, пока она сама случайно не попадёт в нормальное решение. Конечно, референсы не спасают от плохого дизайна. Можно насмотреться 257 тысяч экранов и всё равно собрать помойку. Особенно если агент будет просто усреднять всё подряд. Но сама идея правильная: интерфейс нельзя делать только из текста в промпте. Ему нужен визуальный и продуктовый контекст. Для дизайнеров тут есть смешной момент. Раньше насмотренность была чем-то личным: папки с референсами, скриншоты, закладки, сохранёнки, чужие продукты, которые ты руками разбирал. Теперь эта насмотренность постепенно превращается в подключаемый источник данных для агента. Референсы становятся не только материалом для дизайнера, но и частью работы инструмента. Агент может искать примеры, сравнивать паттерны, приносить варианты, а дизайнер уже решает, что из этого имеет смысл. Ну, если дизайнер вообще есть в процессе, а не где-то потом приходит чинить результат. По мне главное, чтобы такие базы не превратили всё в ещё более одинаковую массу. Если агент будет брать референсы как повод подумать, это полезно. Если как повод собрать «усреднённый лучший экран», то мы просто получим SaaS-дашборд 2.0, только теперь с доказательной базой. ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

🌩 Дизайн становится новым способом собирать продукт Дилан Филд говорит о дизайне не как о финальной упаковке интерфейса, а как о новом рабочем слое между идеей, кодом и продуктом. В эпоху ИИ важнее становится не просто написать промпт, а уметь визуально управлять намерением: быстро пробовать варианты, смотреть на результат, отбрасывать лишнее и сходиться к решению. Главная мысль в том, что дизайнер не исчезает из процесса. Наоборот, его роль становится шире: нужен вкус, ремесло, точка зрения, понимание пользователей, умение работать с прототипами, кодом, агентами и обратной связью от реальных клиентов. ИИ может ускорить перебор вариантов, но выбор направления, качество решения и ответственность за продукт всё равно остаются за человеком. Внутри: – Почему «дизайн как новый код» не означает замену дизайнеров; – Как Фигма пытается соединить canvas, код, прототипы и продуктовую разработку; – Почему прямые визуальные манипуляции могут быть сильнее одних промптов; – Зачем дизайнерам и лидерам быстрее включаться в прототипирование; – Как агенты ИИ помогают исследовать варианты, но не принимают продуктовые решения; – Почему процесс разработки всё меньше похож на линейную цепочку; – Как слияние ролей может быть полезнее гиперспециализации; – Почему вкус, ремесло и точка зрения становятся важнее в эпоху доступных инструментов. ➡️ Смотреть видос (EN) ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

😰 Вау-презентации в Фигме Я не умею делать красивые презы быстро и это прям моя боль. Мне вот сейчас для проекта нужна, а я не знаю как подступиться к этому. Ну вот не умею и всё( Презентации давно перестали быть просто набором слайдов с заголовком, картинкой и буллетами. Сейчас это почти отдельный визуальный жанр: стекло, glow, 3D, бенто-сетки, дашборды, нейросети, сложная инфографика и всё это желательно собрать так, чтобы не умереть в Фигме по дороге) 8 июня у ребят из Кроны стартует вау-марафон по трендовым презентациям 2026-2027. За 5 дней участники соберут полноценный проект в портфолио и разберут, как делать слайды, которые выглядят сильно, современно и не как шаблон из первого попавшегося конструктора. Что пройдёте ✦ glass / liquid / fractal glass ✦ светящиеся градиенты ✦ glow-эффекты ✦ неоморфизм ✦ физические объекты ✦ продуктовые генерации в нейросетях ✦ дофаминовую инфографику ✦ бенто-сетки и дашборды. По формату всё практично 10+ трендовых слайдов, работа в Фигме, нейросети и плагины для ускорения, упаковка данных без скучных таблиц, записи и материалы. Плюс сертификат при сдаче домашек, закрытая статья про тренды дизайна 2026, эфир про монетизацию и нейросети, доступ в закрытый канал дизайнеров. У Кроны уже 2573 человека прошли марафоны, а работы участников потом разлетаются по Pinterest и Behance. Если у вас тоже есть проблемы с презами и вы не умеете их делать, как я, приходите к ребятам. Ценник приятный. Для самых быстрых, кто вписывается сейчас цена всего 1999 ₽(последний марафон по такой цене) 🔠 Записаться на марафон 🔠 Записаться на марафон 🔠 Записаться на марафон

💕 Автономия дизайнера начинается с доступа к информации Сара Пол из NNG разбирает важную вещь: дизайнерская автономия это не когда дизайнер сам принимает все решения. Это когда у него достаточно контекста, чтобы влиять на продуктовую повестку, приоритизацию и roadmap, а не только двигать кнопки в уже утвержденном решении. Главная проблема больших организаций в том, что знание расползается по командам. Аналитика лежит у одних, саппорт слышит боль пользователей, исследования делались в соседнем продукте, roadmap меняется в другом канале, а дизайнеру часто прилетает только обрывок задачи. Автор предлагает собирать из этого информационный пайплайн: искать данные, строить отношения, создавать места для обмена контекстом и превращать разрозненные сигналы в понятную рекомендацию. Внутри: – Почему автономия дизайнера зависит не от должности, а от качества контекста; – Как саппорт, аналитика, прошлые исследования и roadmap помогают увидеть проблему целиком; – Зачем дизайнеру строить отношения с экспертами и соседними командами; – Почему важно понимать upstream и downstream зависимости своего решения; – Как дизайн-операционный гайд снижает поток задач «просто отполировать макет»; – Зачем создавать кросс-функциональные встречи и каналы, если тебя не зовут в нужные обсуждения; – Почему сильная рекомендация должна показывать trade-off, а не просто продавать один вариант; – Как поддерживать информационный пайплайн, чтобы он не превратился в кладбище старых заметок. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

#12 Фигма Make лезет в реальный код Фигма 28 мая выкатила важный апдейт Make: теперь инструмент можно подключить к локальной кодовой базе. Открываешь существующий проект, выбираешь элемент на экране, правишь свойства, отступы, цвет, размер, раскладку, а агент уже находит нужное место в коде и вносит изменения. Пока это ограниченная бета в десктопном приложении для Mac. И сама Фигма честно пишет, что лучше всего это подойдёт дизайнерам, у которых уже есть доступ к кодовой базе компании. Раньше вайбкодинг в дизайне чаще был про быстрый черновик. Собрал экран, показал идею, выбросил половину, что-то утащил в работу. Вроде полезно, но всё равно чуть отдельно от настоящего продукта. А теперь Фигма Make пытается работать с тем местом, где продукт уже живёт.

Самый важный вопрос теперь: кто имеет право двигать кнопку, если эта кнопка уже в коде?

Потому что визуальная правка реального интерфейса звучит очень соблазнительно. Увидел, что отступ кривой, выбрал блок, поправил. Текст не тот, поменял. Цвет уехал, вернул. Не надо писать разработчику «можешь тут 8 пикселей вместо 12», ждать, объяснять, показывать скрин, потом снова смотреть, что получилось. Но чем ближе дизайнер подходит к коду, тем быстрее появляются взрослые вопросы: 1. кто проверяет такие изменения 2. что считается безопасной правкой 3. где начинается логика, а где просто внешний вид 4. кто отвечает, если агент поменял не тот компонент 5. как откатиться, если всё поехало Фигма это понимает, поэтому делает не «пуш в прод», а нормальный путь через разработку. Изменения сначала лежат как локальные коммиты. Можно создавать ветки, смотреть историю, откатываться, а потом открыть пулл-реквест, чтобы инженеры проверили правку как обычное изменение в коде. И это, по-моему, правильная часть новости. Не сам факт, что дизайнер может подвигать блок в живом проекте. А то, что Фигма пытается встроить это в нормальный процесс разработки. Через ветки, коммиты, проверку и возможность отката. Потому что без этого будет весело примерно два дня. Потом кто-то визуально поправит карточку, агент заденет общий компонент, уедет ещё десять экранов, разработчик откроет код и спросит, кто вообще это сделал. Но я бы не хотел, чтобы это стало режимом «дизайнеры теперь сами чинят фронт». Скорее это должно быть как быстрый слой для понятных UI-правок. Поправить отступ. Проверить состояние. Подкинуть вариант. Открыть пулл-реквест. Дальше уже обычная проверка. Ещё важная штука: Фигма разрешает копировать экраны из Make обратно на холст как слои, обсуждать с командой и потом приносить решения назад в код. Это уже похоже на нормальный круг: продукт живёт в коде, команда думает на холсте, изменения возвращаются через понятный процесс. Если Фигма сможет удержать этот круг без бардака, будет сильно. Потому что дизайнеру часто не нужен ещё один генератор красивого прототипа. А вот дизайн-ревью проводить и за качеством прода следить гуд, ибо разработчики лажают оч часто.

😊 Дизайнеру уже мало просто хорошо рисовать В этом разговоре Брайан Ловин из Ноушн очень точно описывает, куда вообще сдвигается роль дизайнера. Границы между дисциплинами размываются, и все меньше смысла делить работу на «это дизайн», «это код», «это продукт». Если хочешь влиять на результат, приходится понимать, как устроены инструменты, как думают инженеры, где заканчиваются возможности моделей и почему одни идеи в проде разваливаются, а другие нет. Самое важное здесь не в очередном наборе AI-инструментов. Главное, что дизайнеру теперь нужно уметь выходить за пределы макета: собирать прототипы в коде, разбираться в ограничениях Фигмы, понимать, как ИИ читает структуру интерфейса, и держать в голове не только красивую картинку, но и всю систему целиком. Не ради моды, а потому что иначе влияние на продукт быстро заканчивается. Внутри: – Почему дизайнеру уже недостаточно оставаться только в рамках интерфейсов; – Как в Notion прототипы все чаще уходят из Фигмы в рабочую кодовую базу; – Почему общение с инженерами стало частью нормального дизайн-процесса; – Зачем понимать реальные ограничения AI-моделей, а не фантазировать про их будущее; – Как хорошие примитивы, имена слоев и структура помогают ИИ работать точнее; – Почему доработка в IDE часто полезнее, чем бесконечные промпты; – Как непоследовательность ИИ одновременно ускоряет работу и создает хаос; – Почему способность глубоко сосредоточиться становится отдельным конкурентным преимуществом. ➡️ Смотреть видос (EN) ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Прошлая неделя была рекордной по выручке для HireHi за все время существования проекта ❤️ Безумно счастлив делать этот сервис и получать такие отзывы Продолжаем!

Дизайн-система через Claude Code Я никогда не любил работать с ДС и компонентами, особенно, когда АИ ещё не было в целом. Дизайн-система это такая штука, которая никогда не заканчивается. Сегодня добавили новый компонент, завтра поменяли состояние, потом где-то в продукте уже уехала версия, а в библиотеке всё ещё живёт старый вариант. И начинается обычная рутина. Проверить состояния. Сверить компоненты. Понять, что отстало от продакшна. Поправить в нескольких местах. Убедиться, что дизайнеры не разнесли всё по разным файлам. Работа важная, но максимально не самая весёлая) И вот это как раз очень похоже на задачу, которую можно отдавать AI-агенту. Не творческую часть, где надо думать головой, а именно поддержку порядка: сверять, находить расхождения, подтягивать правила, дополнять состояния, помогать не превращать ДС в свалку. Даниил из Pixel Perfect 3 июня в 18:00 мск покажет, как это работает на практике. Будет не учебный кейс, а живой AI SaaS-стартап для голосовых агентов. Он соберёт дизайн-систему через Claude Code и Figma MCP, а потом на её базе сверстает экраны продукта. 😎 Что будет полезного Покажет, как собирать ДС через Claude Code и Figma MCP, даст 4 скилла для Claude Code под сборку и поддержку своей дизайн-системы, и разберёт, какую рутину реально можно отдать агенту. Если работаете с дизайн-системами или просто устали руками вылавливать одни и те же расхождения залетайте посмотреть. Ща отставать уже не модно, нужно быть в трендах инструментов и снимать с себя кучу рутины ✨ Эфир пройдёт в канале, приходите Кстати, кто уже занимается ДС через клод, какой у вас пайплайн? Как работаете? 🔠 Подписаться на канал Даниила 🔠 Подписаться на канал Даниила 🔠 Подписаться на канал Даниила

🌸 Т-образный дизайнер это не про «уметь всё понемногу» Юрий Ветров в отрывке из «Паттернов дизайн-менеджмента» разбирает T-образного специалиста как ответ на реальную проблему продуктовых команд. Чем сложнее продукт, тем дороже становится конвейер, где один человек собирает требования, второй рисует, третий исследует, четвертый объясняет разработке, а пятый пытается вернуть всё обратно в продукт без потерь. Главная мысль в том, что современному дизайнеру недостаточно хорошо делать макеты. Ему нужно понимать бизнес, продуктовые требования, пользователей, разработку, аналитику, ограничения платформы и процесс запуска. Не на уровне «я теперь продукт-менеджер и фронтендер», а на уровне, который позволяет брать ответственность за результат, договариваться с командой и проводить решение до живого продукта. Внутри: – Почему сложные дизайн-задачи почти всегда лежат на стыке ролей; – Как узкая специализация увеличивает транзакционные издержки; – Почему дизайнеру важно отвечать не только за макет, но и за продукт; – Зачем продуктовый дизайнер должен понимать менеджеров, разработчиков и бизнес; – Почему лучшая спецификация часто не документ, а работающий продукт; – Какие hard skills и soft skills формируют T-образного специалиста; – Чем отличаются осведомленность, умение, экспертиза и лидерство; – Почему автоматизация и работа руками становятся частью современной дизайн-практики. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы