Угадайте нейронку 🙄😂

Села я тут смотреть прошлогоднее интервью Илона Маска с Лексом Фридманом на 8,5 часов про Нейролинк. Хочу написать пост про их апдейты. Закинула во все LLM запрос и одна из них наврала так красиво и убедительно, что уже есть и дизайн-система у них, и хакатоны, ну вы там прочитаете на скрине )) И да, никогда больше не буду использовать слово Эксклюзив в LLM 😂

Фигма выложила майский 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) ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

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

Пока у команды нет общей структуры, каждый экран собирается заново: где-то основной текст 14 px, где-то 16 px, где-то межстрочный интервал выставлен руками, где-то тот же жирный стиль выглядит иначе. В макетах это еще терпимо, а в разработке быстро превращается в хаос. Олуватосин Обалана показывает практичный подход, как собрать типографику через примитивные и семантические токены и масштабировать ее на веб, планшет и мобильный в Фигме. Ценность статьи в том, что это не просто теория про читаемость, а пошаговая схема: как назвать токены, как разложить роли текста, как связать стили с переменными и переключать режимы без дублей. Внутри: – Какие принципы держат типографику в порядке: удобство, ясность, иерархия; – Какие базовые требования по доступности стоит заложить сразу: размер текста, контраст, межстрочный интервал, масштабирование; – Что такое примитивные токены и какие свойства туда выносить: семейство, вес, размер, межстрочный и межбуквенный интервалы; – Зачем нужны семантические токены и почему они снимают ручные правки по всему продукту; – Как назвать токены по иерархии, чтобы дизайнеры и разработчики говорили на одном языке; – Как разложить роли текста: Display, Heading, Subheading, Body, Caption, Label; – Как считать межстрочный интервал через коэффициенты для крупных и мелких размеров; – Как настроить в Фигме режимы для разных экранов и не плодить отдельные стили под каждый размер. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

→ Добавляй к любому объекту, форме или тексту → Скругляй отдельные углы → Управляй рассеиванием преломления света с помощью Splay → Применяй переменные из своей дизайн-системы www.figma.com/community/file/1522715486231239473

Если в дизайн-системе у иконок ограниченный набор размеров, это почти всегда превращается в отдельную архитектурную проблему. Снаружи всё выглядит просто: ну есть 12, 16, 20 и 24 пикселя, что тут обсуждать. А потом выясняется, что один подход удобен библиотекарю, но раздражает потребителя, второй красиво выглядит в теории, но ломается на вложенных компонентах, а третий требует больше ручной поддержки, зато лучше всего ведет себя в реальной работе. Алиса Пакард очень внятно разбирает эти варианты и приходит к практичному выводу: лучший компромисс сейчас это size-свойство на каждом icon-компоненте, а не отдельные компоненты на каждый размер и не обертка для иконок. Потому что этот способ дает больше контроля там, где он нужен, не ломает опыт потребителя и лучше сочетается с preferred swaps и другими паттернами внутри библиотеки. Внутри: – Почему отдельные компоненты под каждый размер иконки быстро захламляют библиотеку; – Зачем подход с variable modes выглядит заманчиво, но плохо масштабируется; – Чем icon wrapper удобен для поддержки, но неудобен в реальном UI; – Почему вложенные иконки внутри кнопок и других компонентов всё усложняют; – Как size-свойство на каждом icon-компоненте решает проблему гибче; – Почему этот подход лучше для preferred swaps и настройки конкретных компонентов; – Какой компромисс приходится принять библиотекарю при таком решении; – Почему в управлении размерами иконок сейчас важнее опыт потребителя, чем удобство внутренней поддержки. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Поэтому сегодня в Вышке проведем лекцию на тему «Правила создания компонентов» Поговорим о том, как строятся компоненты в дизайне – как логичная, масштабируемая система, которая экономит время и упорядочивает структуру. Разберем, как проектировать компоненты так, чтобы ими было удобно пользоваться, поддерживать и развивать вместе с продуктом. 📌 На лекции обсудим: • пример компонента и массовое редактирование; • атомарность: из чего складывается система; • Auto Layout и его роль в гибкости интерфейса; • варианты компонентов и зачем они нужны; • скрытие элементов внутри компонентов; • как вложенность влияет на производительность и оперативную память. Лекцию проведет Ксения Литвак (продуктовый дизайнер, дизайнер дизайн-систем в Voximplant) ➡️ Подключайтесь сегодня в 19:00 (мск) на Boosty

👋 Привет! Мы — 12 Космонавтов, ищем дизайнера с глубоким пониманием интерфейсного дизайна для создания дизайн-концепции цифрового продукта. Кто нам нужен • UX/UI-дизайнер с опытом от 5 лет, уровень Senior • Плюс: опыт в fintech, SaaS или highload-продуктах Что надо делать • Разрабатывать UX/UI-концепции и прорабатывать пользовательские сценарии • Работать с дизайн-системами: компоненты, токены, состояния, консистентность • Проектировать интерфейсы от user flow и wireframes до финального UI • Готовить макеты к передаче в разработку и сопровождать реализацию 👉Узнать подробности и откликнуться

Когда вы кодите с LLM, проблема обычно не в том, что модель совсем ничего не умеет. Она умеет слишком правдоподобно угадывать. Поставит 12px там, где у вас должно быть 8px, выберет «почти тот» синий, придумает токен, которого в системе нет, и на каждом новом сеансе начнет делать это заново. По отдельности всё выглядит нормально. Вместе получается интерфейс, который расползается уже через несколько итераций. Здесь предлагают довольно жесткую, но рабочую схему: не надеяться на память модели, а дать ей опору в виде спецификаций, закрытого слоя токенов и автоматического аудита. То есть вынести дизайн-систему в структуру, которую LLM может читать как источник истины, а не как намек. Тогда она не выдумывает значения, а берет их из ограниченного набора, а любое отклонение ловится скриптом до ревью. Внутри: – Почему LLM плохо держат дизайн-систему в голове даже в рамках одного проекта; – Какие три ограничения модели быстрее всего разваливают консистентность интерфейса; – Зачем делать отдельные spec-файлы для foundations, tokens, components и patterns; – Почему закрытый слой токенов лучше, чем набор «примерно правильных» значений; – Как аудит по CSS ловит хардкод и не дает визуальному дрейфу копиться; – Зачем связывать инструкции для агента, токены и CI в одну систему; – Почему такой подход особенно важен для больших прототипов и длинных AI-сессий; – Как именно структура дизайн-системы превращается из знания в голове в рабочую инфраструктуру. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

www.figma.com/blog/the-figma-agent-is-here

Это очень актуальная тема, и важно слушать мнение не блогеров, цель которых запугать вас и получить просмотров, а экспертов на реальном рынке. Думаю, уже многие знают, что Ксюша (@uxrockru) больше 10-ти лет занимается продуктовым дизайном и работает с крупными продуктовыми командами. Сегодня она проведет интенсив, где подробно расскажет о своем мнении на эту тему и роли AI в реальных продуктах. Будем создавать интерфейс на Google Stitch – он бесплатный, и у вас будет возможность в нем попрактиковаться. Далее все механики, о которых расскажем на интенсиве, вы сможете применять и в других нейронках, например, Claude. Ксюша активно использует нейросети, и делает это уже давно. Например, с помощью ИИ она ускоряет процесс по созданию дизайн-систем. Об этом мы тоже в будущем вам расскажем. Стартуем в 19:00 по мск, будем рады вас видеть. ➡️ Присоединяйтесь в боте

Мечта любой команды разработки сейчас — автоматизировать сборку дизайна с помощью LLM, чтобы ускорить delivery-процесс. Я видел несколько разных подходов, но в итоге пришёл к чему-то, что, как мне кажется, должно сработать удобно Рассказываю на примере проекта, где я на фрилансе (oversecured.com) Дано: - legacy-архитектура фронта, которую сложно масштабировать с LLM-кой - отсутствие части макетов в Figma + неактуальность макетов Что хотим: - заиметь макеты в Figma, которые выступают как источник правды - можно дать ссылку на макет, и LLM (Codex/Claude) его соберёт - UI-kit/дизайн-система, которая полностью совпадает в Figma/code Как мы решили это сделать: 1. Подключаем для кода open-source библиотеку компонентов shadcn (https://ui.shadcn.com/create). Компонентов там достаточно много + они гибкие (можно внутрь прокидывать много свойств). Это наша база, из которой мы будем собирать весь фронт 2. Берём для этой же библиотеки какой-то из Figma-файлов (вот здесь (https://ui.shadcn.com/docs/figma) есть несколько ссылок на файлы community, на них ссылается сам shadcn). Это наша вторая база, из которой мы будем собирать все макеты в Figma Мы пока не придумываем дизайн и не собираем компоненты с нуля, чтобы ускориться на старте, — просто берём готовое решение. 3. Начинаем собирать макеты в Figma из компонентов, которые мы взяли в community. На скрине — дизайн 4. Дальше через Figma MCP мы можем отдавать нашему AI-агенту ссылку на макет и просить собрать дизайн с помощью компонентов shadcn (можно также использовать shadcn MCP (https://ui.shadcn.com/docs/mcp)) Для тех, кто еще не знает: MCP — это протокол, через который LLM общается с внешними тулами вроде Figma. Важно здесь отловить одну вещь: AI-агент должен вытаскивать из Figma не скриншот макета, а структуру страницы (для этого используются разные методы). И всё — это работает. Простые страницы уже собираются верно на 95–100%, страницы посложнее пока тестируем Первая задача — актуализировать весь фронт на новых гибких компонентах. Во второй части (когда я к ней подойду) я хочу иметь возможность стилизовать компонент в Figma и стащить дизайн на фронт, чтобы в коде он тоже стилизовался В теории, проблемы тут быть не должно, потому что мы взяли в коде и в Figma одинаковую семантику токенов (и там и там shadcn) — то есть цвет в коде и цвет в Figma называются одинаково, например surface-default-100 Я уже предвижу некоторую сложность со стилизацией и со сборкой сложных экранов, так как в Figma компонент не всегда соответствует по пропсам тому, что есть на фронте в библиотеке shadcn (часть свойств может отсутствовать, часть — называться иначе). Тут потребуется немного ручной настройки и тюнинга компонентов в Figma Часть 2 напишу, когда подойду к ней!

На днях наткнулся на цифру: 94% компаний в мире жалуются на нехватку людей с AI-навыками. И, судя по прогнозам, к 2028 году сильно легче не станет. Для дизайна это тоже важный сигнал. Просто уметь делать нормальные макеты уже мало. Бизнесу всё чаще нужны люди, которые понимают, как работать с AI не точечно, а системно: поставить задачу, собрать контекст, проверить результат и отвечать за итог. Проблема в том, что большинство дизайнеров пока используют AI кусками. Тут текст поправить, там референсы собрать, где-то экран накидать. А на реальной задаче всё быстро ломается: AI не помнит бриф, не понимает дизайн-систему, теряет контекст и выдаёт что-то, что потом всё равно приходится руками пересобирать. И вот тут интересная мысль. Возможно, дело уже не в конкретном инструменте, а в том, как вокруг него собрана рабочая среда: папки, скиллы, директивы, дизайн-система, правила проекта. То есть AI не как отдельный помощник сбоку, а как среда, внутри которой ты проектируешь. 13 мая в 18:00 мск Даниил Шишко из Pixel Perfect покажет, как у него устроена такая агентская система. Возьмёт размытое ТЗ в одну строчку от крупного зелёного банка и за 90 минут соберёт концепт банковского дашборда. Будет весь процесс через одного агента в Claude Code: бриф, ресерч, структура экранов, макеты в Фигме по настоящей дизайн-системе и кликабельный прототип. Плюс покажет стек Claude Code, Figma MCP и дизайн-систему, а ещё конкретные шаги, как собрать AI-агента под свои проекты. Если хотите понять, как AI может закрывать не отдельные куски работы, а весь дизайн-процесс — нужно приходить обязательно 🔠 Эфир в канале Даниила 🔠 Эфир в канале Даниила 🔠 Эфир в канале Даниила

AI в дизайне это уже не про отдельные тулзы На днях наткнулся на цифру: 94% компаний в мире жалуются на нехватку людей с AI-навыками. И, судя по прогнозам, к 2028 году сильно легче не станет. Для дизайна это тоже важный сигнал. Просто уметь делать нормальные макеты уже мало. Бизнесу всё чаще нужны люди, которые понимают, как работать с AI не точечно, а системно: поставить задачу, собрать контекст, проверить результат и отвечать за итог. Проблема в том, что большинство дизайнеров пока используют AI кусками. Тут текст поправить, там референсы собрать, где-то экран накидать. А на реальной задаче всё быстро ломается: AI не помнит бриф, не понимает дизайн-систему, теряет контекст и выдаёт что-то, что потом всё равно приходится руками пересобирать. Дело не в инструментах. У AI должна быть архитектура (папки, скиллы, директивы, дс, правила проекта). Он не помощник, а среда, в которой ты работаешь. 😎 13 мая в 18:00 мск Даниил Шишко из Pixel Perfect впервые покажет свою агентскую систему изнутри. Возьмет размытое ТЗ в одну строчку от крупного зеленого банка и за 90 мин соберет полный концепт банковского дашборда. Все этапы работы дизайнера через одного агента в Claude Code: бриф, ресерч, макеты в Figma по дизайн-системе, кликабельный прототип. Что заберешь с эфира: • рабочий стек: Claude Code, Figma MCP и дизайн-система • конкретные шаги, как собрать AI-агента под свои проекты • подход, где AI закрывает весь дизайн-процесс, а не отдельные задачи ➡ Эфир пройдет в тг-канале Даниила: Подписывайся

Но по факту у многих всё выглядит примерно так: ChatGPT помогает с текстом, Midjourney делает картинки, ещё пара вкладок открыта для ресерча, а макеты, структуру экранов и финальную сборку всё равно делаешь руками. Вроде AI уже в работе, но рутины меньше не стало. Просто вкладок стало больше) И вот тут мне интересен подход Даниила Шишко из Pixel Perfect. Он перестроил процесс так, что один агент в Claude Code проходит всю цепочку дизайнера: от брифа и ресерча до структуры экранов, макетов в Фигме и кликабельного прототипа. 13 мая в 18:00 мск Даниил проведёт эфир и покажет это на реальной задаче. Возьмёт ТЗ в одну строчку от крупного зелёного банка и за 90 минут соберёт концепт банковского дашборда через одного AI-агента. Внутри будет рабочий стек: Claude Code, Figma MCP и настоящая дизайн-система. Плюс конкретные шаги, как собрать такого агента под свои проекты, чтобы AI закрывал не отдельные куски, а весь дизайн-процесс. Если у вас AI пока живёт на уровне «тут текст, там картинка» — приходите обязательно. Хотя бы чтобы понять, как может выглядеть следующий уровень работы дизайнера. 🔠 Эфир в канале Даниила 🔠 Эфир в канале Даниила 🔠 Эфир в канале Даниила

Дизайн система для создания приложения в тематике «Медитация» Install ️

Готовим сейчас план развития ДС Nova, созданой для Сбола, но востребованной шире финтеха, и решил поделиться нашей внутренней красотой. Год назад Ваня, Савва, Женя, Никита запилили кайфовый промо ролик внутренними силами. Посмотреть промо можно на Vimeo 📱 А сама команда ДС на вебинаре BBE поделилась внутрянкой, рассказала как всё устроено, где приколы и секреты зарыты, ну и зачем это всё. Посомтреть 31 минуту про ДС Nova можно здесь 📱 @nice2mitya_chuk

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

Мы сейчас в поиске новых дизайнеров для работы с сайтами, приложениями и брендингом. Мы делаем большие екомы, удобные приложения и помогаем с дизайном крупным компаниям. Среди наших клиентов Дефиле, Х5, СкайРом, Архитектор Групп... Для нас дизайнер — это не только про устойчивый визуал. Это про умение принимать решения на уровне логики продукта и понимания бизнеса. Ты наш идеальный кандидат, если... ☑️У тебя большая насмотренность. Без неё никуда. ☑️Осознанно работаешь с композицией, типографикой и визуальной иерархией. ☑️Умеешь в нейросети и доработку результата до максимально возможного. ☑️Понимаешь, как устроен дизайн-продакшн и как макеты превращаются в работающий продукт. ☑️Можешь объяснить и защитить свои решения через логику и здравый смысл. Хотя бы внутри команды. Будет большим плюсом умением в AE и люстру. Основные задачи: — Проектировать пользовательские сценарии для мобильных приложений, e-commerce и корпоративных сайтов; — Собирать интерактивные прототипы, которые понятны и заказчику, и разработке; — Выстраивать визуальные концепции под задачи, а не «просто красиво»; — Работать с гайдлайнами: применять и адаптировать без потери смысла; — Делать адаптивы, работать с компонентами и дизайн-системами (UI kit, атомарный подход — всё это не должно быть новостью). — Создавать визуал для кейсов, которые будут получать награды. Как откликнуться: Пришли резюме и короткое сопроводительное на team@ancora.agency Расскажи о 3 ключевых кейсах и своей роли в них — по делу, без воды. И приложи ссылки на 1–2 сильных проекта в Figma. Больше не надо. Если мэтч по сивишке — сразу же ответим. Будет супер, если добавишь свой ник в ТГ для связи.