Мой обычный флоу: в ChatGPT - спросить и подумать, в Work - отдать задачу посложнее, в Codex - идти с проектом, файлами и агентами.

Теперь появился Dot, который может работать в фоне, писать первым и ставить реакции на сообщения. Последнее забавно: понимаешь, что это интерфейс, но всё равно замечаешь, как он отреагировал. Мне было интереснее попробовать его на работе с дизайн-системами и ревью. Начал с трёх сценариев. Примеры ниже условные, не дословные ответы из чата.

1. Что мы обсуждаем на каждом ревью

Попросил собрать повторяющиеся замечания: отступы, состояния, поведение компонентов. По отдельности это мелкие правки, но вместе они могут показать проблему в самой системе. Например, в нескольких формах возникает один вопрос: когда показывать ошибку - при вводе, после потери фокуса или после отправки? Дизайнеры каждый раз принимают решение заново, потому что в документации есть внешний вид ошибки, а её поведение никто толком не описал.

Полезная находка здесь могла бы выглядеть так: «Вопрос о моменте валидации повторяется в нескольких обсуждениях. В документации нет общего правила». Дальше уже можно разбираться: правило действительно отсутствует, его сложно найти или им почему-то не пользуются? От этого зависит, нужно ли принимать решение, менять документацию или обсуждать с командой, почему она не помогает. Иначе будем бесконечно исправлять одни и те же вещи в макетах.

2. На чём остановились перед ревью

Открываешь новую версию и вспоминаешь: эту кнопку перенесли по договорённости или это новая идея? Почему здесь старый компонент и что решили насчёт мобильной версии? Попробовал собирать контекст заранее: что изменилось, что согласовано, какие вопросы остались. Для таблицы с массовыми действиями это, например, такая сводка: «Панель появляется после выбора строк — это учтено. Остался вопрос, сохраняется ли выбор при смене фильтра. Его стоит проверить на ревью».

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

3. Что пора добавить в дизайн-систему

Ещё попробовал собрать похожие решения из разных задач. Одна команда сделала фильтры, другая - почти такие же, третья скопировала и доработала. Хочется увидеть их рядом и понять, нужен ли общий компонент. При этом внешнего сходства недостаточно: в одном фильтре изменения применяются сразу, в другом - по кнопке «Применить», а значит, отличаются состояния, сброс и поведение при закрытии.

Полезный результат здесь примерно такой: «Структура похожа, логика применения разная. Можно выделить общие элементы, но объединять весь блок пока рано». С этим уже можно идти к разработке и обсуждать конкретные варианты. Иногда после разбора лучше оставить решения отдельно, потому что компонент с пятнадцатью настройками тоже кому-то придётся поддерживать.

После этих проб мне стало понятнее, зачем чату писать первым. Во всех трёх случаях речь о работе, до которой постоянно не доходят руки. Обычно садишься за неё, когда замечания уже раздражают, решения забыты, а похожие компоненты расползлись по продукту. Хочется получать такие находки раньше, с примерами и ссылками, пока ещё можно спокойно в них разобраться.

Правда, если каждый день будут прилетать десять предложений улучшить дизайн-систему, получится ещё один бэклог. Поэтому дальше хочу проверить, насколько уместно Dot выбирает повод написать. Если перед ревью он поможет вспомнить договорённости и заметить открытый вопрос — отлично. Если после него принесёт ещё двадцать задач, я, скорее всего, просто отключу уведомления.