Применение AI в пресейле
Как я использую AI в пресейле: путь от RFP до прототипа в Figma Make
Меня зовут Никита, я дизайнер интерфейсов и дизайн-лид. Последние годы я много времени провожу не только в продукте, но и на пресейле: помогаю команде разбирать RFP, формулировать решение и упаковывать его так, чтобы заказчику было понятно, что именно мы предлагаем и почему это имеет смысл. Статья будет не совсем про дизайн в его чистом виде, но про то как наш дизайн вообще может появиться и как он участвует в процессе продажи услуг по разработке софта.
AI в этот процесс вписался довольно органично, не как "магическая кнопка, которая сама напишет КП и сделает все за вас", а как набор инструментов, которые:
- экономят дни на разборе входящих документов;
- помогают собрать контекст рынка и пользователей;
- ускоряют переход от "сырого RFP" к прототипу, вокруг которого можно говорить по делу.
В этом своем тексте я хочу провести вас через вымышленный, но очень близкий к реальному кейс: от RFP до интерактивного прототипа в Figma Make.
- Названия, цифры, данные – обезличены.
- Структура процесса – почти такая же, как в живых пресейлах.
- Подготовку полноценного коммерческого предложения я сознательно оставляю за скобками: там слишком много сенситив инфы о подходе к оценке и ценообразованию. Здесь фокус именно на пути: от входящих документов до понимания задачи и прототипа, который это понимание показывает.
Исходная точка
Начнем мы с того что придумаем некий абстрактный RFP над которым мог работать я или вы. Допустим что это будет система для записи пациентов в гос-клиниках
Структурируем сеттинг:
- B2G в регионе MENA;
- система записи и управления визитами в государственных клиниках;
- два документа: часть RFP на арабском, часть – на английском (по структуре похожи на реальный DoH-RFP на appointment system).
Тут мы можем столкнуться с типичными проблемами:
- десятки страниц текста, где половина – бюрократическая вода;
- часть требований противоречат друг другу;
- часть – на арабском, часть – на английском;
- куча ограничений по безопасности, регуляторике и доступности (локальное законодательство, гос ДСка, WCAG).
Сейчас я все чаще вижу что в linkedin и других соцсетах часто говорят о использовании LLM для автоматизации первичного анализа RFP: модели выжимают требования, подсвечивают риски и формируют вопросы.
Но тут у нас сразу два ограничения:
- В RFP обычно полно сенситив инфы – реальные системы, внутренние процессы, инфраструктура.
- Мне как дизайнеру и продуктовику нужно не только "что заказали", но и контекст: пользователи, их задачи, рынок, паттерны.
Чтобы решить обе этих задачи я делю свой процесс на два контура:
- локальный – все, что связано с реальными документами и любыми сенситив данными;
- облачный – все, что связано с внешним контекстом: рынок, паттерны, рефы, проверка гипотез.
Шаг 1. Локальный контур или введение в безопасную работу с ИИ
Железо и модели
В локальном контуре у меня два основных варианта:
- MacBook Pro с локальной Qwen3-8B через Ollama – когда нужно быстро и мобильно;
- стационарный ПК помощнее, где крутится Qwen3-14B – если объем сложнее или нужно больше запаса по рассуждению и контексту.
Обе модели из семейства Qwen3:
- поддерживают длинный контекст и мультиязычность (что критично для арабского + английского);
- заточены под рассуждение и instruction-following, что хорошо ложится на задачи системного анализа.
Но на самом деле вы можете развернуть у себя все что угодно из современных моделей. Я также пробовал glm, deepseek и t-lite немного погонял, все справляются неплохо с преимуществами в тех или иных задачах (возможно разберу позднее)
1.1. Первый проход по RFP
Берем на вооружение базу промпт-инженеринга – фреймворки CRISPE + CoT
Для крупных задач я стараюсь не писать "разовый монолитный промпт", а использовать, например, CRISPE (Context, Role, Instruction, Subject, Preset, Exceptions) плюс сверху Chain-of-Thought (CoT) или просто по умному просим модель думать по шагам.
Пример промпта для первого прохода:
Чтобы понимать более предметно о чем речь можете посмотреть примеры этих документов (сгенерированы нейронкой, но структура и некоторые формулировки близки к реальным)
Пример того, что может вернуть Qwen3-8B Сильно упрощаю формат чтобы не растянуть статью:
Здесь CoT обычно проявляется в том, что модель сначала разматывает в голове "о чем вообще документ", а потом структурирует ответы – и это видно по более чистым и полным спискам по сравнению с "дай мне просто summary".
1.2. Вытаскиваем функционал и грубо приоритизируем
Следующий шаг – превратить текст в функциональные блоки и понять, что для заказчика "must-have", а что можно двигать. Для этого я подмешиваю RICE-логику – Reach, Impact, Confidence, Effort.
Пример условного промпта:
Пример ответа, опять же чисто фрагмент, для общего понимания повествования:
То что вы тут получите это будет не "истина в последней инстанции", но хороший старт для обсуждения, что точно попадает в прототип и "первую фазу", а что может ждать. Естественно никто не принимает оценки ИИ за факт и не берет в работу)
1.3. Из черновика в… более надежный черновик
Даже локальная модель может наплодить уверенной ерунды. Чтобы снизить шанс этого я часто использую паттерн Chain-of-Verification (CoV): сначала модель делает черновик, потом сама придумывает проверочные вопросы, отвечает на них и только потом уточняет ответ.
Промпт-надстройка к предыдущему:
Пример того, как это может выглядеть в ответе (сильно сокращаю):
Здесь мне важно не то, что модель внезапно дала идеальный ответ, а то, что она сама подсветила спорные зоны – это считай готовый список редфлагов к пресейл-встрече.
Шаг 2. Облачный контур: ChatGPT, Gemini, Perplexity как внешний контекст
Локальная модель прекрасно разбирает документы, но живет в границах того, что я ей скормил и ограничена в производительности (по крайней мере у меня не слишком производительное железо). Чтобы не продумывать все с нуля, а свободно пользоваться благами человечества и интеллектом всего интернета я все же подключаю облачные обычные модели:
- ChatGPT – для структурирования гипотез, списков, удобной работы со structured outputs;
- Gemini – когда нужен более плотный web-ресерч и работа с разными типами данных;
- Perplexity – как "тяжелый ресерчер": строит отчеты с ссылками и объяснениями.
Здесь важно: ни один из этих сервисов не видит исходный RFP. В облако уезжает только:
- обезличенный домен (government appointment & visit management system);
- функциональные блоки и NFR без названий систем и инфраструктуры.
2.1. Картина рынка и паттерны
Еще пару-тройку лет назад изучение рынка и конкурентов требовало просто коллосальное количество времени, но сейчас достаточно большую часть рутинных процессов мы можем переложить на плечи ИИ.
Помогут нам в этом “три кита” хорошего исследования – CRISPE + CoT + CoV
Пример промпта к ChatGPT/Gemini в с использованием этого подхода:
На выходе получается что-то такого вида, но, понятное дело, сильно большего объема:
Здесь CoV работает как встроенный фильтр: модель сама придумала проверочные вопросы, прошлась по ним и немного подчистила вывод.
2.2. Приоритизация болей и возможностей
Полезный трюк – попросить модель приоритизировать боли и возможности тоже через RICE: не для финального roadmap, а чтобы понять, куда стоит вложиться в прототипе. Это валидно, потому что если у целевой аудитории и конкурентов что-то болит, то вероятнее всего ваш потенциальный заказчик знает об этом или у него тоже болит, а значит прототип попадет что называется “в самое сердечко”
Пример промпта:
Небольшой фрагмент ответа:
Это уже не просто "боли", а карта, к чему стоит привязать сценарии в прототипе.
Шаг 3. Обратно в локальный контур за юзкейсам
На этом шаге внешний мир для меня снова отключается – я возвращаюсь в локальный контур с Qwen и работаю только с тем, что уже собрал:
- структурированный RFP;
- список фич с RICE;
- роли, боли, возможности;
- типовые UX-паттерны.
На этом этапе перед нами и ИИ стоит задача – собрать черновой набор юзкейсов и пользовательских потоков, из которых потом родится и структура системы, и прототип.
Здесь поверх CoT имеет смысл использовать что-то из мира causal chain-of-thought (CauCoT). Идея в том, чтобы строить сценарий как цепочку причинно-следственных связей, а не просто последовательность шагов.
3.1. Триггер → условие → действие → результат
Пример запроса к локальной Qwen3-14B упрощенно:
Очень сильно упрощенный фрагмент ответа:
Дальше я уже руками:
- проверяю, не забыл ли AI важные ветки (такое бывает, но все реже);
- добавляю опыт из прошлых проектов (когда делаешь не первый десяток таких ком предложений примерно представляешь что от тебя хотят);
- связываю это с оценками, фазами и общим контекстом.
Шаг 4. От юзкейсов к прототипу
К этому моменту у нас есть:
- разложенный по полочкам RFP;
- очень грубая приоритизация фич;
- роли и их боли;
- набор юзкейсов и causal-флоу.
Дальше моя задача как дизайнера – собрать из этого все то, что можно показать заказчику, и превратить в прототип.
Здесь в ход идет Figma Make: я использую ее не как "нарисуй мне красивый UI из воздуха", а как ускоритель, который из детального текстового описания может собрать:
- каркас интерфейсов по ролям;
- ключевые флоу;
- состояние экранов и edge cases.
Тут мы все еще находясь в локальном контуре просим помочь модель с генерацией промпта для ее собрата. Сейчас упрощаю, но будет что-то похожее на:
Результат – обычно, гигантский промпт, типа такого (добавил файлом потому что тут точно не уберется)
В нем описаны:
- лендинг с выбором роли;
- сценарии пациента (поиск врача, запись, перенос, отмена, семья);
- сценарии регистратуры (check-in, очередь, walk-in, статусы визитов);
- админка (расписания, аналитика, управление клиниками и пользователями);
- edge cases и ошибки.
Этот промпт пойдет в Figma Make → на выходе получается первый вариант прототипа, который:
- визуализирует сценарии из RFP и наших юзкейсов,
- для заказчика выглядит чуть ли не как "живое приложение", а не абстрактные вайрфреймы,
- при этом не раскрывает ничего сенситив.
Дальше чаще всего идут несколько “веселых” часов за уточнением прототипа. Обычно я правлю:
- подгоняю общий лейаут под требования и под свой вижн того как оно должно быть;
- убираю лишнее и усиливаю ключевые сценарии.
- дорабатываю edge кейсы, так как с ними объективно make справляется спорно, но это связанно с тем что мы не можем писать излишне детализированный промпт
Посмотреть что получилось можно вот тут: тык
Не сказал бы что это пример какого-то идеального прототипа и уж тем более не пример дизайна, но уверяю вас что это уже значительно больше чем сделают 80% ваших конкурентов на бидах
Где я сознательно нажимаю стоп
В реальном пресейле на этом история естественно не заканчивается:
- к прототипу прикручиваются оценки по командам и срокам;
- строится роадмап с описанием какие роли на каких этапах жизненного цикла нужны;
- собираются варианты фаз и сценарии внедрения;
- все это превращается в полноценное коммерческое и техническое предложения.
Но это уже территория с большим количеством сенситив данных конкретных клиентов и нашей внутренней кухни, да и не так она полезна вам будет, так как завязанна на конкретные бизнес-процессы.
В этом тексте мне хотелось показать именно дизайнерский и продуктовый кусок процесса:
- как разделить контуры так, чтобы сенситив данные никогда не покидали локальный периметр;
- как использовать ChatGPT, Gemini и Perplexity не как "оракул", а как еще один слой ресерча, который нужно перепроверять;
- как локальная Qwen3-8B/14B может быть автором драфтов для структур, юзкейсов и даже помощником при формировании промптов для Figma Make или аналогов;
- и как прототип в итоге становится аргументом в диалоге с заказчиком, а не просто красивой картинкой.
Если вы участвуете в пресейлах как дизайнер, PM или BA, многие штуки из этого пайплайна можно аккуратно адаптировать под ваши задачи или обсудить какие-то вопросы в комментах.
Надеюсь было интересно и не слишком нудно)