Как дизайнеру делегировать задачи ИИ и проверять результат

ИИ подготовил пять аккуратных вариантов. Какой из них помогает принять решение? С этого вопроса начинается полезное делегирование: цель, критерии и проверка результата.

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

Для меня качество делегирования определяется тем, насколько результат помогает сделать следующий осмысленный шаг. Можно получить небольшой список противоречий в исследовании и сдвинуть задачу с места. Можно получить десятки экранов и потратить остаток дня на выяснение, какую проблему они решают.

В статье о том, как меняется работа продуктового дизайнера с ИИ, я разбирал роль профессионального выбора. Здесь — семь приёмов, которые помогают организовать саму работу: от постановки задачи до принятия результата. Они применимы к исследованиям, проектированию, прототипам и дизайн-системам. Все примеры ниже — условные рабочие ситуации.

1. Сформулируйте результат и ограничения

Запрос «проанализируй интервью» описывает действие, но оставляет открытым вопрос о результате. Нужны темы для обсуждения, объяснение отказов, проверка гипотезы или материал для выбора следующего исследования? Для каждой цели полезен свой ответ.

Допустим, команда решает, стоит ли менять поиск в продукте. Тогда задачу можно сформулировать так:

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

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

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

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

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

2. Разделяйте работу по решениям, которые предстоит принять

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

Представим задачу настройки уведомлений. Сначала нужно понять, что пользователь должен контролировать: тип события, канал доставки, частоту или всё сразу. Пока это не решено, подробная отрисовка переключателей преждевременна.

Разумная последовательность выглядит так: перечень сценариев и ограничений → варианты организации настроек → выбранная структура → состояния и тексты → прототип для проверки поведения. После сравнения структур может выясниться, что сложный редактор правил вообще не нужен. Тогда последующие этапы изменятся.

У каждого этапа стоит назвать результат и вопрос для принятия решения. Например: «Две схемы группировки с преимуществами и ограничениями; после сравнения выбираем, какой принцип организации проверять». Число вариантов здесь задаётся задачей, а не привычкой просить модель выдать десять идей.

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

Такой порядок не обязан быть линейным. Обнаруженный в прототипе конфликт может вернуть работу к структуре. Важна видимость этого перехода: нужно понимать, какое предположение пересмотрено и почему.

3. Заранее определите, что будете проверять

Фраза «выглядит хорошо» подходит для первой реакции. Для принятия результата нужны более точные основания. Я бы разделял их на три группы: соответствие задаче, качество представления и поведение в реальных условиях.

Возьмём сравнение двух вариантов списка документов. Оба могут быть аккуратными, но по-разному поддерживать работу: один помогает быстро просматривать названия, другой — сравнивать статусы и владельцев. Оценивать их нужно через действие, которое человек собирается выполнить.

Сначала выровняйте условия сравнения: одинаковые данные, размер окна и состояние интерфейса. Если в одном варианте три коротких названия, а в другом двадцать длинных, часть впечатления создаёт содержимое. Полезно заранее подготовить небольшой набор сложных примеров: длинный заголовок, отсутствие результата, несколько одинаковых имён, недоступное действие.

ИИ может помочь составить такой набор и выполнить часть проверок. Но его уверенное объяснение не подтверждает, что человек найдёт нужный документ или правильно поймёт обозначение. Для вопросов о понимании и поведении пользователей нужны соответствующие исследования.

Выбирайте форму проверки под вопрос. Для сравнения группировки может хватить схемы; для поведения выбора и отмены нужен интерактивный прототип. Такой выбор уровня детализации описан в руководстве GOV.UK по прототипированию. Готовность прототипа к проверке идеи также не означает готовность продукта к выпуску.

Практический приём: к каждому значимому замечанию прикладывайте наблюдение и ожидаемое поведение. «При длинном названии исчезает статус; статус должен оставаться видимым» даёт больше направления, чем «сделай список удобнее». Вопросы клавиатурного управления подробнее разобраны в статье «Клавиатура важнее мыши».

4. Сохраняйте решения вместе с причинами

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

Полезно различать постоянные правила, решения текущего проекта и временные предположения. Например, название сущности в продукте — правило для согласованного употребления. Выбор группировки в одном сценарии — решение с определённой областью действия. Идея проверить сокращённую форму — пока гипотеза.

Если всё это записать как равнозначные инструкции, частное решение легко станет случайным стандартом. Отказ от всплывающей подсказки в одном месте ещё не означает запрет подсказок во всём продукте.

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

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

Память проекта нуждается и в уборке. Заменённое решение следует пометить как устаревшее, а временное ограничение снять, когда исчезла его причина. Иначе агент получает противоречивые указания и вынужден выбирать между ними.

5. Проверьте, что ИИ работает с актуальными материалами

Когда ответ выглядит странно, хочется улучшить формулировку запроса. Сначала стоит проверить исходные данные. Возможно, агент открыл старый макет, использовал прежнее описание компонента или видит прототип до последних изменений.

Это особенно важно при работе между несколькими инструментами. В документе уже принято новое название, в библиотеке остался прежний компонент, а в прототипе показано переходное состояние. Из такой смеси трудно получить последовательный результат даже при хорошем задании.

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

Практический приём: если агент сообщает о завершении, запросите подтверждение, подходящее результату. Для исследования — ссылки на рассмотренные материалы. Для компонента — его состояния. Для прототипа — выполнение согласованного сценария. Объяснение сделанных изменений должно совпадать с тем, что можно открыть и проверить.

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

6. Параллельная работа требует общих критериев

Нескольким агентам можно поручить независимые части исследования или разные направления поиска решения. Но результаты придётся сопоставлять, и условия этого сравнения лучше задать заранее.

Допустим, вы изучаете подходы к сложным фильтрам. Один агент разбирает выбор нескольких значений, другой — сохранение наборов, третий — объяснение активных ограничений. Всем нужны общий сценарий и одинаковые вопросы: что делает пользователь, какие состояния предусмотрены, где возникают ограничения, чем подтверждён вывод.

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

Сравнивать результаты можно по короткой схеме: задача пользователя → наблюдаемое решение → преимущества → ограничения → источник. Отсутствующие сведения следует отмечать. Достраивать поведение продукта по одному скриншоту слишком легко.

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

После сбора материалов нужен отдельный проход: убрать повторы, разрешить противоречия и выбрать, что относится к вашей задаче. Совпадение ответов нескольких моделей само по себе не подтверждает вывод: они могут опираться на одинаковые материалы или повторять одну ошибку. Для небольшой задачи один последовательный проход часто проще в организации; необходимость нескольких агентов стоит обосновывать объёмом независимой работы.

7. Договоритесь о самостоятельности и моменте остановки

Полезная автономность начинается с понимания, какие решения агент может принимать сам. Подобрать формулировки, собрать варианты на копии макета и изменить общий компонент — действия с разными последствиями. Им подходят разные способы контроля.

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

Подготовка вариантов → сравнение
Правка прототипа → проверка сценария
Изменение библиотеки → ревью команды

Нужно определить и момент остановки. «Улучшай, пока не станет идеально» не объясняет, как закончить работу. Лучше назвать признаки готовности и условие возврата к дизайнеру: критерии противоречат друг другу, не хватает данных, несколько попыток не устраняют проблему или дальнейшее изменение выходит за согласованный объём.

В описании подходов к агентам Anthropic отдельно выделяет обратную связь от среды и условия остановки. Для дизайнера это можно выразить просто: помощник должен видеть результат своих действий и понимать, когда продолжение требует нового решения. Конкретный предел попыток зависит от задачи; универсального числа здесь нет.

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

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

Короткая заготовка для следующей задачи

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

Цель: какое решение я хочу принять или какой результат получить.

Материалы: актуальные источники и правила, на которые нужно опираться.

Ограничения: что должно сохраниться и что не входит в задачу.

Результат: что именно нужно подготовить и насколько подробно.

Проверка: по каким критериям принять работу и чем их подтвердить.

Самостоятельность: что можно менять без моего участия и когда нужно остановиться.

Затем попросите сохранить принятое решение и открытые вопросы там, откуда будет начинаться следующий этап.

Я бы начинал с одного повторяющегося типа задач: подготовки сравнения, описания состояний компонента или проверки прототипа. После нескольких выполнений станет виднее, где не хватает контекста, какие критерии действительно помогают и на что уходит внимание дизайнера. Эти наблюдения дадут основание постепенно расширять самостоятельность ИИ и убирать лишние действия из собственного процесса.

Ссылки

• Anthropic: Building effective agents — принципы организации агентной работы, обратной связи и остановки.
• GOV.UK: Making prototypes — выбор формы прототипа под задачу проверки.
• Как меняется работа продуктового дизайнера с ИИ — профессиональный выбор при работе с генеративными инструментами.
• Клавиатура важнее мыши — отдельный взгляд на управление интерфейсом.