Как мы ускорили discovery-процесс с помощью skills

Привет! Мы Катя Халитова и Саша Иванов, UX-исследователь и продакт из Контур.Фокуса.Про skills сейчас пишут много, но почти всегда со стороны разработки. Материалов о том, как встроить их в исследовательский процесс, мы не нашли — разбирались сами. Поэтому в статье рассказываем, что у нас получилось: показываем skills, которые мы собрали под задачи discovery, и разбираем, как собрать свой — под свою задачу и свою методологию. Наши лежат в открытом репозитории на Github..

Что такое skills и почему обычных промптов становится мало

Если говорить просто, skill — это алгоритм решения задачи, упакованный в файл. В нём можно зафиксировать роль, метод, ограничения, формат результата, критерии качества, заложить этап валидации.

На раннем этапе работы с ИИ почти все начинают с промптов. Но у skills есть несколько преимуществ.

Во-первых, skills удобны для командной работы. Если один исследователь хорошо разобрался в методе или собрал удачный алгоритм для типовой задачи, это знание можно не держать только у себя. Его можно упаковать в skill и передать коллегам: продактам, дизайнерам, менеджерам проектов или другим исследователям.

Например, недавно исследователь из нашей команды передал менеджеру проекта skill с алгоритмом того, как составить качественный сценарий юзабилити-тестирования. Вместо того чтобы тратить время на объяснение и ревью, менеджер проекта просто запустил в Сlaude skill и сразу получил готовый качественный результат.

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

Пример вызова skill в Claude для создания сценария опроса:

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

Ценность skills в discovery-процессе

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

Например, в skill для подготовки сценария интервью с пользователем можно положить принципы построения интервью или юзабилити-тестирования, правила перехода к зондированию, запрет на наводящие вопросы и тд.

Тогда исследователю или продакту не нужно каждый раз писать: «Не задавай наводящие вопросы, начни с разогрева, двигайся от прошлого опыта ^[1] к текущим проблемам, раздели вопросы по блокам». Это уже часть skill. Остаётся только передать вводные данные: цель исследования, аудиторию, продуктовый контекст, ограничения, гипотезы. Skill забирает на себя выполнение рутинной задачи.

В этом смысле skill — это способ формализовать часть профессионального мышления ^[2] и сделать её доступной в моменте.

Skills позволили нашей команде ускорить исследования. Например, удалось в количественном исследовании сократить затраты рабочего времени с 5 дней до 1,5 дней.

Наши skills для исследовательской работы и ускорения discovery

Мы собрали несколько skills под типовые задачи discovery: подготовить гайд, спроектировать опрос, стандартизировать анализ интервью и быстро разобрать количественные данные. Их можно использовать как исследователям, так и продактам, дизайнерам или менеджерам проектов.

Skills для обработки информации

design-guide ^[3]

Когда использовать: нужно подготовить гайд для интервью или UX-теста.

Что дать на вход нейросети: цель исследования, аудиторию, гипотезы, продуктовый контекст.

Что получится: структура интервью/UX-теста, блоки вопросов, probes, чек-лист качества.

Главная польза для Discovery — меньше риска получить гайд, который подталкивает респондента к нужному ответу или слишком рано уводит разговор в продукт. Также этот skill очень удобно передать коллеге и не тратить время на объяснение всей методологии.

survey ^[4]

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

Что дать на вход: цель, гипотезы, контекст продукта, ограничения по выборке.

Что получится: черновик опроса со скринингом, вопросами, шкалами и логикой ^[5] ветвлений.

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

Важная часть этого skill — проверка вопросов по когнитивной модели Д.Рогозина: понимает ли респондент формулировку, может ли вспомнить нужную информацию, не подталкиваем ли мы его к социально желательному ответу, корректно ли устроены варианты ответа.

qualitative-analysis-rules ^[6]

Когда использовать: нужно проанализировать интервью или UX-тесты в таблице.

Что дать на вход: транскрипты, цель гипотезы исследования, контекст продукта.

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

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

analyze-visualize-quant-data ^[7]

Когда использовать: есть CSV/XLSX с результатами опроса.

Что дать на вход: файл с данными, цель исследования, описание вопросов и гипотезы.

Что получится: расчёты, графики, статусы гипотез и продуктовые выводы.

Что внутри skill:

• Рабочий процесс по анализу выстроен следующим образом: сначала понять цель и логику опроса → изучить датасет → построить рамку гипотеза → метрика → вопрос → база → расчёт → интерпретация → продуктовый вывод → посчитать → присвоить статусы ( подтверждена / частично / не подтверждена / неоднозначно ).

• Типы вопросов, которые можно обрабатывать, разные: single choice, multiple choice, шкалы (top-2-box), числовые поля, открытые ответы.

• Статистические методы: проценты от ответивших (не от всей выборки), доверительные интервалы Wilson 95%, z-тест для сравнения сегментов (p<0.05), флаг малой базы n<30.

• Графики: строгий визуальный стиль (по дефолту зелёная палитра, но вы можете установить свой цвет графиков).

Skills для создания прототипов

Всё, о чём мы говорили выше, живёт в пространстве работы с текстовыми артефактами и обработки информации: подготовить гайд, собрать опрос, проанализировать транскрипты и данные. Но discovery на этом не заканчивается — в какой-то момент нужно проверить решение. И здесь у исследователя обычно два варианта: статичный макет в Figma (а это очередь к дизайнеру) или ожидание, пока у разработки дойдут руки до создания MVP.

Мы попробовали третий путь: собирать работающие прототипы в Claude Code — агентной версии Claude, которая пишет код, запускает сборку и деплоит результат на сервер. Разница с диалоговым режимом принципиальная: вы описываете, что нужно, а агент сам создаёт файлы, проверяет, что всё собирается, и исправляет свои ошибки ^[8]. Порог входа ниже, чем кажется — мы не написали руками ни строчки кода.

Зачем прототип в коде, если есть привычная Figma?

• Можно быстро заложить ветвящиеся сценарии. В нашем прототипе ИИ-ассистента около тридцати веток диалога с уточняющими вопросами и честными отказами. В Figma такое дерево собрать почти невозможно, а если и возможно, то очень долго.

• Не нужны дизайнер и разработчик. Даже одноэкранный макет в Figma — это чья-то очередь задач. Здесь исследователь или продакт собирает экран сам, а правки по итогам интервью агент вносит быстрее, чем вы успеете завести задачу в трекер.

• Интеграционные сценарии. «Ассистент открывается прямо из CRM» можно не рассказывать, а показать — настоящим встраиванием одного окна в другое.

По ходу работы над проектом мы заметили ту же закономерность, что и с текстовыми артефактами: одни и те же задачи повторяются от прототипа к прототипу и от показа к показу. Так появились три skilsl — они повторяют ^[9] жизненный цикл прототипа: собрать в фирменном стиле → подготовить к исследованию → подготовить показ.

Этими skills мы поделиться, к сожалению, не можем. Но, переосмыслив наш опыт, вы можете создать такие skills для своих команд. 

Skill для сбора прототипа в фирменном стиле

Когда использовать: собираете или дорабатываете прототип продукта и хотите, чтобы он выглядел как настоящий, а не как демо.

Что дать на вход: ничего, кроме ответов на вопросы анкеты (или скриншот продукта). Дальше — обычные задачи на вёрстку и интерфейс.

Что получится: прототип, который респонденты не отличают от продукта: фирменная сетка и радиусы, правильная типографика, цвет вашего продукта в акцентах и семантические цвета отдельно, плюс чек-лист соответствия гайдам.

Первая проблема любого прототипа — «сырой» вид. Если интерфейс не похож на продукт компании, респондент оценивает не концепцию, а качество картинки, и половина интервью уходит на «а почему тут так странно выглядит». Мы собрали выжимку официальных гайдлайнов Контура — модульная сетка, радиусы, типографика, правила цвета, поведение ^[10] компонентов — и упаковали её в skill.

Ключевое решение — параметризация. Например, зелёный — это цвет Контур.Фокуса. У других продуктов Контура свои цвета, поэтому skill нельзя «прибить» к одному продукту. 

При первом запуске в проекте он задаёт несколько вопросов: как называется продукт, к какому сегменту он относится (и сам предлагает официальный цвет из палитры Контура), как выглядит логотип. Если вы не знаете токенов — достаточно прислать скриншот продукта, палитру skill извлечёт из него. Ответы сохраняются в файл бренд-профиля рядом с кодом, и дальше skill их не переспрашивает.

Skill для подготовки прототипа к исследованию

Когда использовать: прототип готов, впереди интервью или демо c пользователем.

Что дать на вход: код прототипа; в идеале — ещё гайд исследования.

Что получится: отчёт с находками и правками, чистый прототип и легенда достоверности для модератора.

Прототип, собранный «для себя», нельзя показывать респонденту как есть — и это не про красоту. В интерфейсе остаются технический жаргон («RAG», «семантический поиск»), ссылки на пункты внутренних требований, пометки «заглушка». Хуже того — прототип может подсказывать ответы: если вы собираетесь спросить «чего вам здесь не хватает?», а интерфейс уже подсвечивает нужную функцию баннером, данные интервью испорчены. Skill проводит аудит по четырём направлениям и выдаёт отчёт с находками по степени критичности:

1. Техгигиена — ищет внутренний жаргон, номера требований, служебные пометки и остатки тестового контента в видимых текстах.

2. Прайминг — если дать skill гайд исследования, он сверит темы вопросов с тем, что прототип подсвечивает заранее, и покажет, где интерфейс «подсказывает» респонденту.

3. Достоверность данных — найдёт фактические утверждения (нормы, номера, реквизиты), разделит проверенное и синтетическое, проверит согласованность выдуманных данных между собой и соберёт для модератора «легенду достоверности»

4. Прогон сценариев (опционально) — если в проекте настроены автотесты, прогонит сценарии демо и убедится, что ни одна ветка не сломана.

Skill для создания гайда перед показом прототипа

Когда использовать: впереди показ прототипа — интервью, демо стейкхолдерам, презентация.

Что дать на вход: ссылку на прототип и список сценариев, которые хотите показать (или попросите skill самого составить опись веток по коду).

Что получится: HTML-документ с планом показа: тезисы, чек-лист подготовки, сценарии с точными фразами и скриншотами, сводная таблица всех веток, ответы на каверзные вопросы и раздел «чего не показывать».

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

Как создать свой skill

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

Методология от Кати

1. Создание skill начинается не с промпта, а с понимания задачи, которую вы хотите регулярно решать. Лучше всего подходят задачи, которые повторяются из проекта в проект. Порефлексируйте, что в вашей работе вы делаете больше 1 раза в день / в неделю / в месяц.

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

3. Добавьте реальные примеры выполненной задачи, либо сгенерируйте тестовые примеры.

4. Попросите нейросеть упаковать это всё в skill.

5. После этого skill нужно протестировать на реальной задаче. Я тестирую скиллы сначала на тестовых данных, потом на своих реальных задачах.

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

Лайфхаки по созданию качественных skills:

• Попросите нейросеть проанализировать книгу или практические статьи по теме. Это помогает сделать дополнительную опору на хорошую практику в выполнении конкретной задачи.

• Попросите другую нейросеть проанализировать skill и выявить в нем слабые места.

Главное в создании skills — не пытаться сразу упаковать в skill всё знание. Лучше начать с атомарной задачи, которую вы часто повторяете, и довести её до стабильного результата. Потом его можно расширять или собрать несколько отдельных skills под разные этапы discovery.

Методология от Саши

Катя рассказала, как упаковать повторяющуюся задачу в skill. Мой опыт — про смежные задачи: как вести с агентом долгий проект на десятки итераций (например, прототип), чтобы он не расползся.

1. Начинайте с документа требований. Лучший старт — не «сделай прототип», а готовый документ: функциональные требования, PRD, даже структурированные заметки. Агент проектирует по нему и сам находит противоречия.

2. Сначала план, потом код. Теперь перед любой крупной доработкой я прошу агента сначала показать план и задать вопросы. Обычно в этих вопросах всплывает что-то, о чём я сам не подумал. Обсудить план — минут десять, переделывать готовое — день; мы сравнивали, к сожалению, не по своей воле.

3. Система быстро забывает ^[11] договорённости, фиксируйте их на старте. Договорились о легенде, ролях в данных, границах прототипа — попросите агента записать это в файл проекта. Иначе через двадцать итераций он предложит пересмотреть то, что вы уже решили.

4. Принимайте работу сценариями, а не «посмотрю глазами». Мы просили агента прогонять каждый сценарий демо автотестом — это ловило сломанные ветки до того, как их ловил респондент.

5. Итерация после каждого показа. Прототип — расходный материал исследования: показали → собрали правки → закинули агенту списком → на следующем интервью версия уже новая.

6. Не приносите респонденту кухню. Последний шаг перед любым показом — шлифовка. Заведите это как ритуал, как проверку звука перед созвоном.

Вывод

Skills снимают рутину, при этом методология остаётся вашей, просто теперь она зафиксирована в файле, а не в голове одного человека.

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

Если у вас остались вопросы или возникнут предложения для обмена опытом, пишите авторам статьи — Кате ^[12] или Саше ^[13].

А если представленные нами скиллы понравятся в работе — поставьте репозиторию звёздочку GitHub 🐸

---

Больше интересного про UX-исследования в телеграм-канале «Сдоба ^[14]»🥨