Новости и разборы
AI в дизайн-системе: кто принимает изменение компонента
Figma описывает поддержку библиотек и опыт продуктовых команд. Как проверить токены, состояния и передачу изменений в приложение.
В продукте несколько похожих кнопок, но у каждой свои отступы и поведение. Агент может быстро привести макеты к общему виду. Однако после такой правки остаётся вопрос: изменился только рисунок или правило для всего продукта? Два материала Figma от 6 октября помогают разделить поддерживающую работу и решение владельца дизайн-системы.
Библиотеке нужен понятный контекст
В материале о поддержке дизайн-системы Figma описывает задачи документации, проверки названий и токенов, поиска отклонений от библиотеки. Производитель связывает полезность результата с переданным контекстом дизайна. Этот контекст нужно подготовить: агенту требуется знать, какие компоненты и правила команда действительно считает актуальными.
Для клиентского кабинета можно начать с одного часто используемого элемента, например поля ввода. Уточните состояния: обычное, фокус, ошибка, недоступное действие. Затем определите, какие значения берутся из токенов и что допустимо менять на уровне конкретного экрана. Иначе внешне аккуратная правка может закрепить разные правила для одной задачи.
История команды не заменяет вашу приёмку
Второй материал Figma приводит истории продуктовых дизайнеров Uber, Granola и Atlassian, включая документацию, работу с системой компонентов и motion. Это опыт команд в изложении производителя, а не независимая гарантия качества или сэкономленного времени.
Связь двух публикаций состоит в повторяемом процессе: правила библиотеки передаются агенту, он подготавливает изменение, а ответственная команда принимает результат. Массовая замена компонента затрагивает больше экранов, чем видимый исходный макет. Поэтому проверяющему полезен список изменённых экземпляров и причина каждой замены.
Проверить компонент в живом сценарии
Возьмите форму с ошибкой ввода и длинным текстом. Проверьте изменение в макете, затем в реализации на узком экране и с клавиатуры. Убедитесь, что сообщение ошибки связано с полем, фокус остаётся видимым, а кнопка сообщает допустимое действие.
Если меняется движение, согласуйте его роль: подтверждение действия, переход или раскрытие дополнительной информации. Проверьте поведение при reduced motion и отсутствие помех чтению. Соответствие токенам само по себе не доказывает доступность и удобство.
После приёмки обновите описание компонента и зафиксируйте передачу разработчику. Из сопоставления следует проектный вывод: поддержка библиотеки имеет ценность, когда следующий экран использует принятое правило, а не новую локальную интерпретацию. Для небольшой команды такой цикл можно начать без переработки всей системы.
Первый выпуск клиентского кабинета помогает выбрать проверяемый сценарий. Проект приложения для аренды даёт контекст продукта без утверждения об использовании Figma agent. Для вашего клиентского продукта обсудите компонент и критерии его приёмки.