AI‑спейс для дизайнеров

Три проблемы работы с AI в команде

В конце концов, это было неизбежно — мои дизайнеры, исследователи и UX‑писательница призвали на помощь нейросети. Я был таким же как они. Я вообще помешался на AI, мне бы порадоваться—но вместо этого я напрягся. По трём причинам.

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

Ограниченная память AI. Обычное окно с LLM напоминало мне джуна, который каждое утро приходил на работу с амнезией. Недостаточно было создать проект в Claude и загрузить в него кучу файлов. У B2B‑холдинга из 12 продуктов куча контекста, и ни одна Memory с ним не справлялась.

И, да — санкции. Я прилежно оформлял проекты в Claude, пока однажды мой аккаунт не забанили. Все наработки пропали. Тогда мне понадобилось решение, которое выдержало бы быструю смену Claude на Codex. Или вообще переезд на open‑source сервис с корпоративным API-ключом для LLM.

Тода я вооружился знаниями git, фронтенда, AI — и создал место, которое стало для моей команды новой точкой входа в задачи.

Как устроен спейс

Это обычный git‑репозиторий. Или, если уйти от языка разработчиков (на котором мы, по мнению HR-ов, должны разговаривать fluently), то это папка. Её можно открыть в любом агенте, будь то Claude Code, Cursor, Codex или OpenCode.

В корне лежит файл AGENTS.md. В файле — карта проекта и основные правила работы. Агент автоматически читает его, как только вы начинаете новый чат. Он узнаёт, что в спейсе есть:

# Источники по дизайн-системам

## Каталоги дизайн-систем

- [designsystems.surf/design-systems](https://designsystems.surf/design-systems)
- [component.gallery](https://component.gallery/)
- [designsystemsclub.ru](https://designsystemsclub.ru/)

## Дизайн-системы

- [Apple HIG](https://developer.apple.com/design/)
- [Google Material Design](https://m3.material.io/)
- [Carbon by IBM](https://carbondesignsystem.com/)
- [Primer by Github](https://primer.style/)
- [UK Government DS](https://design-system.service.gov.uk/)

< … >

## Хорошие примеры

- [Принципы государственных систем России](http://gov.design)

< … >

## Материалы

- [Cloudscape Design tokens](https://cloudscape.design/foundation/visual-foundation/design-tokens/)
- [Style Dictionary Design Tokens](https://styledictionary.com/info/tokens/#category--type--item)
- [Orion Nebula (Nessgrixti, портфолио)](https://nessgrixti.com/portfolio/orion-nebula)

< … >

## Принципы

- **Width и height обычно не бывают семантическими.** Высота шапки или ширина
  зоны — решение одного компонента, поэтому такие размеры живут на уровне
  component и ссылаются прямо на raw-шкалу. Исключение — повторяющиеся размеры
  элементов управления (у Primer `control-medium-size: 32px` — одна высота
  для всех кнопок и инпутов).
- **У компонента нет внешних маргинов.** Расстояние между компонентами задаёт
  родитель через `gap` или `padding`. Иначе компонент нельзя переставить в
  другое место, не поправив его самого. Поэтому в шкале есть `padding` и
  `gap`, а `margin` почти нет.
- **Должно ли значение расти вместе с размером шрифта у пользователя?** Перед
  каждым размерным значением задавать себе этот вопрос (Josh W. Comeau,
  «The Surprising Truth About Pixels and Accessibility») — от него зависит,
  задавать величину в `rem` (растёт с пользовательским масштабом шрифта,
  нужна для доступности — текст, отступы вокруг текста, размеры иконок рядом
  с текстом) или в `px` (фиксирована — толщина бордера, тени, что-то
  привязанное к физическому пикселю экрана).

# Задача
Напиши текст для пустого состояния списка задач.

# Тон коммуникации
- Спокойный и конкретный
- Объясняем, что можно сделать дальше
- Не обвиняем пользователя

# Задача
Напиши текст для пустого состояния списка задач.

# Контекст продукта
- Это корпоративный таск-трекер
- Список появится после создания первой задачи

# Правила UX-письма
- Спокойный и конкретный тон
- Подсказываем следующий шаг
- Используем терминологию продукта

К спейсу подключены MCP Figma и Metabase. Агенты умеют анализировать цифры, смотреть макеты и сравнивать их с дизайн‑системой, отрисовывать макеты по коду и писать код по макетам.

Туда же легли 40 скиллов для ревью визуалки, анимаций и конкурентного анализа. Наши любимые — скиллы дизайн‑инженера Эмиля Ковальски и Lazyweb. Есть локальные скиллы для лидов: уборка спейса, вливание обновлений, логирование изменений. Спейс помнит, кто, что и когда в нём изменил.

Пример: автоматизация UX‑письма

UX‑писательница тратила очень много времени на рутину. Я решил её разгрузить. Мы взяли объёмный файл редактуры с принципами, tone of voice и примерами «плохо/хорошо» — и прикрутили его к скиллу uxw-review. Скилл смотрит на текст и проверяет его строго по нашим правилам. Затем присылает отчёт: что изменил бы, какой вариант лучше и какое правило применил.

Довольно быстро стало ясно, что продактам и дизайнерам иногда тяжело написать даже черновик. Так появился скилл uxw-research. Он:

• принимает ссылку на Figma или задачу в вольном формате
• анализирует задачу
• изучает 12 редактур ведущих IT‑компаний (например, Контура, Mailchimp, UK Gov, Райффайзена, etc.)
• пишет усреднённо хороший текст по общепринятым стандартам UX‑райтинга

Два скилла собраны в один воркфлоу. Агенту можно скинуть ссылку на макет или просто написать пару мыслей: он запустит сначала uxw-research, затем черновик уйдёт на uxw-review. При необходимости агент заглянет в UX‑паттерны, дизайн‑систему, прошлые отчёты, информацию о продуктах или результаты исследований.

Как я отдал спейс команде

Все дизайнеры получили доступ в корпоративный GitHub и научились скачивать изменения из репозитория. Проще всего это делать через GitHub Desktop.

У каждого дизайнера своя рабочая ветка, она называется по фамилии. Если дизайнер хочет внести вклад в общую ветку main, он пушит изменения, а я одобряю или отклоняю запрос. Так мы коллективно пополняем спейс скиллами, шаблонами, исследованиями и паттернами.

Результаты

Что я узнал и понял

Shit-in-shit-out. Контекст важнее всего. Один и тот же запрос в пустом чате и в полноценном спейсе даёт разные результаты.

Разослать ссылку на папку недостаточно. Нужен процесс для коллективной и системной работы.

Нагрузка на дизайнеров сначала вырастет. Придётся многому научиться: освоить Git, разобраться в скиллах и агентах, понять, как устроены репозитории для прототипирования, etc.