Вопросы и ответы
С 29 апреля по 25 августа 2026 года я провёл круг дизайн-ревью — по одной встрече с каждым продуктовым дизайнером, всего пятнадцать разговоров, тринадцать из них с записью и расшифровкой.
Ты был на одной такой встрече. Этот документ — про то, что было на всех остальных.
Разговоры получились похожими сильнее, чем я ожидал. Одни и те же вопросы задавали разные люди в разных продуктах, не сговариваясь: самый частый прозвучал на двенадцати встречах из тринадцати. Поэтому здесь собраны темы, которые беспокоили всех, — с ответами.
💬 Если тебе казалось, что твой вопрос был неловким или слишком базовым — почти наверняка его задали ещё восемь человек. Ничего из этого не очевидно, и почти ничего не описано в документации. Это и есть главный вывод круга.
Ответы даны в самой свежей редакции: там, где за четыре месяца позиция менялась, написан последний вариант, а не тот, что звучал в мае. Такие места отмечены отдельно.
Часть 1. О чём я рассказывал на каждой встрече
Это блок, который повторялся у всех примерно одинаково. Если на твоей встрече мы что-то из этого пропустили — вот кратко, о чём шла речь у остальных.
Уровни библиотек. Библиотеки уложены от абстрактного к конкретному: Astra DS — общая база, она обслуживает не только «Свои Финансы»; Astra FinTech UI — общий продуктовый уровень; FinTech Products UI — то, что нужно одной команде; Astra FinTech UI Icons — все иконки. Имя компонента работает как адрес: по тегу видно, на каком уровне он должен лежать.
Библиотека как витрина. Единое хранилище нужно не только технически. По нему видно, что уже сделали соседи и что можно взять готовым вместо того, чтобы придумывать заново. Компонент, лежащий в личном макете, этой роли не выполняет.
Слоты вместо локальных компонентов. Слот — это дырка в компоненте, куда можно бросить любой фрейм. Раньше, чтобы вложить меняющийся контент, приходилось делать локальный компонент; теперь он не нужен.
Страница как компонент. Страница собирается компонентом со слотами: неизменная часть остаётся внутри, меняющаяся уходит в слот. Тогда правка делается в одном месте, а не на каждом экране флоу. Важная оговорка: это не панацея и не для всего подряд. Так имеет смысл собирать главные и разводящие страницы — те, у которых повторяется структура и много состояний. Обычные экраны флоу компонентом делать не надо: выигрыша не будет, а сложности добавится.
Чужие макеты — картинкой. Перетаскивая фрейм из соседнего файла, ты забираешь и его проблемы. Точку входа показываем скриншотом, а сверху кладём прозрачный кликабельный слой, чтобы прототип продолжал работать.
Пересборка вместо свапа. Там, где в макете много ручных правок поверх компонентов, свап не помогает. Быстрее собрать экран заново на актуальных компонентах, чем искать, где что разошлось.
Storybook как критерий сдачи. Компонент считается сданным, когда он лежит в Storybook и прошёл ревью Core-команды. Показ на стенде — не сдача. Конкретно: ваши компоненты из FinTech Products UI должны лежать в React-библиотеке core-ui-local — её Storybook и есть то место, где вы принимаете работу.
Гигиена файла. Черновик и архив рядом с продом — главная причина, по которой Figma лагает и обновления не доезжают. Песочницу выносим в отдельный файл, архив сохраняем контрольной точкой и удаляем.
Переиспользование. Есть базовые кирпичи. Если каждый раз собирать свои похожие элементы, то в момент общего изменения оно до них не дойдёт — придётся править руками во всех местах сразу.
Часть 2. Вопросы дизайнеров
По убыванию: сколько встреч из тринадцати тема заняла.
1. Старые библиотеки в макете — 12 встреч из 13
Самая частая тема круга. Не поднималась только на одной встрече, и то потому, что она была целиком про анимацию.
«Почему изменения дизайн-системы до моего макета не доезжают?»
Потому что макет ссылается на старое пространство. Когда дизайн-систему переносили, файлы выгружали и загружали обратно, и макеты запомнили ссылку на исходную библиотеку. В одном файле спокойно живут сразу две дизайн-системы: старая Astra Design System и новая Astra DS. Пока подключена старая, обновления идут мимо, и дело не в компонентах — дело в списке библиотек.
Что делать: открыть список подключённых библиотек, убрать оттуда старые, перевести компоненты на актуальные.
«Как отличить старую библиотеку от новой?»
По списку подключённых библиотек — это основной способ. Astra Design System и Astra Base — старое, Astra DS и Astra DS Base — актуальное. Версия дизайн-системы в навбаре макета (11.40 против 11.21 и 11.30) — быстрая подсказка, но она не всегда показывает реальное положение дел, так что окончательный вывод делай по списку библиотек.
«Может, переименовать старую библиотеку, чтобы не путаться?»
Не получится: старое пространство заблокировано на публикацию, переименование туда не уедет. Различать придётся по исходным именам в списке подключённых библиотек.
«Есть инструмент, который покажет, где у меня используется старая библиотека?»
Нет. Только вручную или пересборкой файла. Плагины показывают неполную картину: правки, внесённые поверх компонента вручную, они не видят.
«Я нахожу старые компоненты, переключая тёмную тему. Этого достаточно?»
Нет, и это важный момент. Так находятся только цвета. Правки, которые кто-то внёс поверх компонента руками, и картинки таким способом не ловятся — они переживают и переключение темы, и свап.
«Стоит ли переносить старые компоненты, названные через дефис?»
Не стоит, это наследие ещё более раннего периода. Новое сразу делать в FinTech Products UI с описанием.
2. Где хранить компонент — 12 встреч из 13
Вторая по частоте и, вместе с первой, съевшая примерно две трети всего круга.
«Куда положить свой компонент?»
Смотри на тег в имени. Трёхсоставный тег означает, что компонент нужен одной команде, — ему место в FinTech Products UI, в своей папке. Суффикс AF означает общий продуктовый компонент — он живёт в Astra FinTech UI. Без суффикса — это общая дизайн-система.
«Чем Astra DS отличается от Astra FinTech UI?»
Astra DS абстрактна: она не знает про наш бэк и обслуживает не только «Свои Финансы». Astra FinTech UI завязан на продукт. Поэтому всё продуктовое уходит вниз по уровням, а не наверх в базу.
«Можно ли держать локальные компоненты в продуктовом файле?»
Практически никогда. Всё, что реализуется в коде, должно лежать в FinTech Products UI со своей папкой и тегом. В продуктовом файле остаются только экраны.
«А мастер-компоненты можно оставить в макете?»
Нет, и это чаще всего оказывается корнем чужих проблем. Пока мастер лежит в макете, соседи ссылаются на макет, а не на библиотеку, — и чистка их файлов ничего не даёт. Самый показательный случай круга: «ПиП Главную» копируют себе все ПиП-команды вместе с мастер-компонентами внутри.
«Мне нужен компонент из чужого флоу. Отцепить его и доделать у себя?»
Есть два законных пути: сделать дубль в своей библиотеке под своим тегом либо поднять компонент до уровня AF. Просто отцепить и оставить у себя в макете нельзя — так плодятся копии, за которыми никто не следит.
«Мне не хватает в DS-компоненте одного свойства. Можно обернуть его своим компонентом?»
Нет. Разработчик так сделать не сможет: обёртка не даёт ему точки входа в чужой компонент. Правильный путь — скопировать компонент из DS в свою библиотеку, дать свой тег и менять уже копию. Разработчик у себя делает то же самое.
«А если меня не устраивает, как компонент выглядит в DS?»
Писать в общий чат и чинить в DS. Локальный обход даёт ещё одну копию, за которой никто не следит, и не решает проблему для остальных команд.
«Какой отступ ставить между несколькими полями ввода, если рядом нет Basic List?»
Дизайн-система здесь ничего не диктует — это зона продуктовой команды и лида. Договаривайтесь внутри продукта.
3. Слоты — 9 встреч из 13
Единственная тема круга, на которую реакция бывала радостной. Многие просто не знали, что слоты появились.
«Что такое слот?»
Дырка в компоненте, куда можно бросить любой фрейм. Берёшь фрейм, кладёшь внутрь компонента — и дальше собираешь в нём что угодно. Раньше, чтобы вложить меняющийся контент в Bottom Sheet или Basic List, приходилось делать отдельный локальный компонент. Теперь не нужно. Convert to slot работает на фреймы.
«Где слоты нужны, а где нет?»
Там, где содержимое меняется непредсказуемо. Если набор состояний известен заранее и конечен — это вариант компонента, а не слот.
«Что такое default и modification у слота?»
default значит, что слот берёт содержимое из основного компонента и обновляется вместе с ним. Как только ты правишь содержимое руками, слот переходит в modification и тянуть из основного перестаёт. Отсюда, кстати, растёт частая жалоба «этот экран не принимает обновления».
«Что внутри слота можно менять, а что нет?»
Отступы и gap — можно. Направление раскладки — нет, оно задаётся в основном компоненте.
«Как вообще понять, можно перебивать значение или нельзя?»
По тому, что стоит в поле. Если проброшен токен — перебивать можно. Если стоят голые числа, нули, — трогать нельзя: у разработчика в этом месте просто нет параметра, и он такую настройку не примет. Простое правило, но за весь круг его не знал никто.
«Старые локальные компоненты надо удалять?»
Да. Они были нужны до появления слотов, а сейчас только держат ссылки на старые библиотеки.
4. Страница как компонент — 9 встреч из 13
⚠️ Самая тяжёлая тема круга. Я объяснял её трижды, и трижды объяснение не зашло — так что если у тебя после разговора осталось ощущение каши, это не про тебя, это про то, как я объяснял. На слух тема не берётся, нужен текст с картинками. Он в работе.
«Зачем вообще собирать страницу компонентом?»
Чтобы одинаковые правки не повторять на каждом экране флоу вручную. Собранная компонентом страница правится в одном месте и меняется везде, где стоит.
Как это устроено на примере, который я показываю чаще всего. Есть страница Travel Page. Она состоит из отдельных продуктовых компонентов: задний градиент, заголовок страницы, форма с данными, у которой есть состояние загрузки и состояние ошибки. Из этих деталей собирается страница. Дальше её кладёшь во флоу — и в каждом экране стоит один и тот же компонент, просто с разным содержимым слотов.
«Для какой страницы компонент нужен, а для какой нет?»
Это главный вопрос по теме, и ответ на него — «не для всех». Компонентом имеет смысл собирать главные и разводящие страницы: те, что открываются часто, повторяются по структуре и имеют много состояний. Именно там правка в одном месте окупается.
Обычные экраны внутри флоу так собирать не надо. Разовый экран без состояний компонентом делать незачем — выигрыша не будет, а разбираться в конструкции придётся и тебе, и тому, кто придёт после.
Это не панацея. Если после разговора со мной осталось ощущение, что теперь всё надо переводить на компоненты-страницы, — нет, не надо. Начни с одной разводящей и посмотри, окупается ли.
«Где хранить саму страницу-компонент?»
Сама страница — в продуктовом макете, чтобы обновления дизайн-системы ты принимал руками и видел, что изменилось. Кирпичи, из которых она собрана, — в FinTech Products UI.
«Как сделать несколько вариантов страницы?»
Через слэш в имени, а не через варианты внутри одного компонента. Так Figma не будет держать в памяти весь набор при каждом обращении.
«Как показывать состояния — загрузку, пустой экран, ошибку?»
Через слоты: скелетон → обычное состояние → пусто → ошибка. Для загрузки есть готовый ленивый скелетон-контейнер в Layer, детализированные скелетоны рисовать не надо.
«Будет ли единый шаблон страницы открытого продукта на все команды?»
Нет, решение принято: любая команда захочет отличий, и единый шаблон не приживётся. Вместо шаблона будет заготовка, которую копируют и меняют под себя. (Позиция августа, раньше вопрос считался открытым.)
5. Ссылки на соседние макеты — 9 встреч из 13
«Можно перетащить компонент или экран из соседнего файла?»
Нет. Вместе с ним приезжают его проблемы: чужие локальные компоненты, старые токены, ссылки на мёртвые библиотеки. И появляется копия, за которой никто не следит.
Главная причина даже не в этом, а в поддержке: когда один и тот же экран лежит в трёх файлах, потом невозможно понять, где из них правда.
Как правильно: положить скриншот, а сверху — прозрачный кликабельный слой. Прототип продолжает работать, чужие проблемы не приходят.
«А если я беру чужой макет просто как референс?»
То же правило. Референс в виде живой копии — это та же копия.
«Как тогда хранить точки входа из чужих флоу?»
Гиперссылкой на файл соседа или инфо-блоком с описанием. Если точка входа нужна в прототипе — картинкой-компонентом, чтобы обновлять её в одном месте.
«Неужели вес файла важнее, чем консистентность?»
Честный ответ: вопрос не закрыт. Аргумент про вес файла реальный, но встречный аргумент — что консистентность важнее — я не снял. Обсуждали промежуточный вариант с мастер-экраном, от которого делается легальный детач. Решения пока нет, и я не буду делать вид, что оно есть.
6. Передача в разработку — 7 встреч из 13
«Когда работа разработчика считается сданной?»
Когда компонент лежит в Storybook. Только там его смотрит Core-команда и только там проверяются общие механики вроде скейла. Показ на стенде сдачей не считается: то, чего нет в Storybook, для дизайн-системы не существует.
📍 Конкретный адрес: то, что вы завели в Figma в FinTech Products UI, в коде должно оказаться в React-библиотеке core-ui-local. Её Storybook — то место, куда вы заходите сами, тыкаете компонент и принимаете работу. Если компонента там нет, работа не сдана, даже если на стенде всё выглядит правильно.
«Почему разработчики делают дубли и рисуют свои фоны с нуля?»
Потому что компонент не прошёл ревью и не попал в Storybook — разработчик не знает, что готовое уже есть, и собирает своё. Второе: дизайнер часто не просит явно использовать готовый компонент, а надеется, что его найдут. Просить надо прямо.
«Почему просят делать меньше компонентов, но с более широкими настройками?»
Потому что два похожих компонента в двух командах меняются вдвое дороже. Чем меньше компонентов и чем шире их набор параметров, тем дешевле это стоит продукту.
«Я меняю компонент — надо заводить вторую версию?»
Если компонента ещё нет в коде — правь на месте. Если есть — заводится новая версия, мажорная или минорная в зависимости от того, насколько сильно меняется поведение.
«Как правильно передать замечание к поведению общего компонента?»
Только через issue. Устные замечания и сообщения в чате не отрабатываются.
«Нужного мне компонента нет — точно нет?»
Проверь, прежде чем делать обходное решение. За круг несколько раз выяснялось, что готовое уже есть, просто про него не знали: большой календарь давно распилен на выбор дня, месяца, года и недели; навигационная панель облегчена; в Product Selector лежат готовые анимации индикатора карусели.
7. Тёмная тема и картинки — 6 встреч из 13
«Нужно ли держать в макетах тёмную тему отдельно?»
Не нужно. Если токены назначены правильно, тёмная тема отработает сама. Отдельная вкладка «Прод тёмная тема» только утяжеляет файл, а необходимость её держать обычно означает, что где-то вместо токена стоит жёстко заданный цвет. (Это позиция на конец круга — в мае формулировка была мягче.)
«Почему при переключении темы часть элементов не меняется?»
Причин две. Либо старая библиотека не отдаёт обновлённые токены — тогда это вопрос списка библиотек. Либо это картинка, а не цвет: картинка на тему не реагирует в принципе.
«Как сделать, чтобы картинка переключалась вместе с темой?»
Сделать компонент с двумя вариациями, светлой и тёмной, и завести строковую переменную со значениями light и dark по модам темы. Дальше картинка переключается сама.
«Как хранить фоны экранов?»
Компонентом-картинкой, поставив точку в начале имени. Такой компонент не публикуется, но обновляется в одном месте.
8. Свап или пересборка — 6 встреч из 13
«Я свапнул компонент, а цвет остался старый. Почему?»
Потому что где-то поверх компонента внесли правку руками. Figma запоминает её как модификацию и тащит через свап — свап её не перетирает. Найти такое место послойно можно, но обычно это дольше, чем собрать экран заново.
«Свап виснет и не срабатывает»
Если в файле в этот момент сидят несколько человек, Figma держит несколько состояний файла и свап на них не сходится. Свапать лучше в одиночку и небольшими частями.
«Что сделать перед большим свапом?»
Поставить точку сохранения в истории версий. За круг был случай: свап шаблона статусного экрана на 169 компонентов сломал состояния по умолчанию и подписи кнопок, откатывались через историю.
«Так свапать или пересобирать?»
К концу круга ответ стал однозначнее, чем в начале: пересобирать. Свап оправдан только на чистых макетах без ручных правок. Во всех остальных случаях быстрее завести новый файл и перенести флоу по одному экрану — заодно выкидывается лишнее. Так сделали несколько человек, и это оказалось быстрее, чем чинить.
9. Теги и префиксы в имени — 6 встреч из 13
«Что означает DP перед именем?»
Что это дизайнерская сборка из существующих компонентов, а не компонент для кода. У неё нет своей цепочки релизов: разработчик собирает её из тех же кирпичей, а не подключает готовым элементом. Хранить её всё равно нужно в библиотеке, а не в макете.
«Какие ещё бывают пометки?»
DP — дизайн-паттерн, Dev Example — пример для разработки, Template — заготовка, Page — страница, Deprecate — выведено из обращения, использовать нельзя. Точка в начале имени означает служебный компонент, который не публикуется.
«Как компонент попадает на уровень AF и кто это решает?»
Инициатор договаривается с автором компонента, ревью даёт DS-команда, а делает любая из трёх сторон — в зависимости от того, у кого есть время.
«Достаточно ли, что компонент выглядит так же, как чужой?»
Нет. Нужно, чтобы он был нужен минимум двум командам и чтобы разработка подтвердила, что в него приходят одинаковые данные. Одинаковый внешний вид при разных данных — это разные компоненты. (Формулировка августа, самая строгая за круг.)
10. Гигиена файла — 5 встреч из 13
«Figma лагает, файл тяжёлый»
Почти всегда причина в том, что черновик и архив лежат в одном файле с продом. Песочницу — в отдельный файл или личные драфты, архив — сохранить контрольной точкой и удалить. В рабочем файле должен остаться только актуальный флоу.
«Что будет с историей версий, если выгрузить файл локально?»
Она потеряется, и восстановить её нельзя. Перед выгрузкой обязательно ставь контрольные точки.
11. Анимация — 4 встречи из 13
«Как делать анимацию, чтобы её воспроизвели в коде?»
Длительности брать кратными стандарту, 200–300 мс, дробные значения не использовать. Кривая — cubic-bezier(0.42, 0, 0.58, 1). Кривые, которые предлагает Jitter по умолчанию, брать нельзя: в коде они воспроизводятся дорого. Нажатие — уменьшение до 0.95 из готового пресета, с отдельной анимацией возврата.
«У нас есть токены анимации?»
Есть, они лежат на странице Motion Tokens и появились ещё до перехода на Figma Motion.
«Как называть слои в анимации?»
Так же, как компоненты в Figma. Разработчик читает по названиям, что именно двигается.
«Что входит в сдачу анимации?»
Ссылка на файл анимации, выгруженное видео и описание в блоке «Интерактив» — с разделением на начало и конец события и с типом действия: тап, свайп.
«Можно взять готовую библиотеку анимации, например Lottie?»
Нет. В веб-модули такие библиотеки не помещаются — там борьба за килобайты. Только нативный CSS.
12. Иконки — 3 встречи из 13
«Где должны лежать иконки?»
Все SVG — в Astra FinTech UI Icons, а не в продуктовом файле. Иконка — это картинка с именем, на которое ссылается разработчик, а не настроенный компонент.
«Нужной иконки нет. Можно положить временную?»
Можно, пока идёт заказ. Но когда придёт настоящая, старую нужно удалить, и это важнее, чем кажется: вес библиотеки иконок напрямую влияет на скорость загрузки веб-модуля.
«Что означают красные кресты на иконках?»
Что иконка выведена из обращения. Использовать нельзя, при необходимости — перезаказывать через процесс.
«Цветные SVG надо приводить к токенам?»
Нет, цветной SVG — нормальная сущность. Кладём как есть и отдаём разработчику через Icon Container Color.
13. Версия дизайн-системы — 3 встречи из 13
«Как понять, что мой файл принимает обновления?»
Надёжный способ один — открыть список подключённых библиотек и посмотреть, что в нём стоит. Если рядом с актуальными висят старые пространства, файл обновления не примет, и никакие косвенные признаки этого не отменят. По списку же видно, что именно надо отключать.
Версия дизайн-системы в навбаре макета — вспомогательная подсказка: 11.40 актуально, 11.21 и 11.30 нет. Но полагаться только на неё не стоит: она не всегда даёт понять, на какой версии ты на самом деле сидишь. Считай её быстрым сигналом «что-то не так», а проверяй по библиотекам.
Если нужно подробнее
Здесь короткие ответы. За деталями:
-
Запись и расшифровка твоей встречи — в таблице «Core-ревью по продуктовым макетам», в карточке с твоим именем. Там же краткое саммари разговора.
-
Просто спроси. Половина вопросов из этого документа возникла потому, что нужного документа не существовало. Если твой вопрос сюда не попал — это не значит, что он редкий, это значит, что его пока никто не задал вслух.
Документ будет пополняться после следующих кругов ревью.