Применение AI в пресейле

Как я использую AI в пресейле: путь от RFP до прототипа в Figma Make

Применение AI в пресейле

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

AI в этот процесс вписался довольно органично, не как "магическая кнопка, которая сама напишет КП и сделает все за вас", а как набор инструментов, которые:

  • экономят дни на разборе входящих документов;
  • помогают собрать контекст рынка и пользователей;
  • ускоряют переход от "сырого RFP" к прототипу, вокруг которого можно говорить по делу.

В этом своем тексте я хочу провести вас через вымышленный, но очень близкий к реальному кейс: от RFP до интерактивного прототипа в Figma Make.

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

Исходная точка

Начнем мы с того что придумаем некий абстрактный 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 немного погонял, все справляются неплохо с преимуществами в тех или иных задачах (возможно разберу позднее)

Применение AI в пресейле

1.1. Первый проход по RFP

Берем на вооружение базу промпт-инженеринга – фреймворки CRISPE + CoT

Для крупных задач я стараюсь не писать "разовый монолитный промпт", а использовать, например, CRISPE (Context, Role, Instruction, Subject, Preset, Exceptions) плюс сверху Chain-of-Thought (CoT) или просто по умному просим модель думать по шагам.

Пример промпта для первого прохода:

[C] Контекст У тебя на входе фрагменты RFP для системы записи в государственных клиниках региона MENA. Часть текста – на арабском, часть – на английском. Документ может содержать противоречия и бюрократическую "воду". [R] Роль Ты – системный аналитик и UX-архитектор, который готовит материалы для пресейла. [I] Инструкция (с CoT) 1. Подумай шаг за шагом (Chain-of-Thought): сначала пойми контекст, потом цели, потом ограничения. 2. Выдели из текста: – high-level контекст проекта; – цели заказчика; – ключевые стейкхолдеры и роли; – жесткие ограничения (регуляторы, хостинг, безопасность, доступность). 3. Сформируй вывод в виде JSON-структуры. [S] Subject Возьми контекст того что мы знаем о проекте из прикрепленных документов [P] Preset Пиши кратко, без воды, на английском. Максимум 3–4 пункта на каждый список. [E] Exceptions Если чего-то явно нет в тексте – не выдумывай, пометь это как "unknown".

Чтобы понимать более предметно о чем речь можете посмотреть примеры этих документов (сгенерированы нейронкой, но структура и некоторые формулировки близки к реальным)

Пример того, что может вернуть Qwen3-8B Сильно упрощаю формат чтобы не растянуть статью:

{ "overview": "Unified appointment and visit management system for government outpatient clinics in a MENA region.", "goals": [ "Increase share of online appointments vs. call center", "Reduce no-show rate", "Improve transparency of clinic operations for regulator" ], "stakeholders": [ "Patients and family members", "Reception staff", "Clinic administrators", "Regional health authority" ], "constraints": [ "Data must be hosted in national data centers", "Compliance with local health data protection laws", "UI must follow national design system and TDRA guidelines", "Accessibility: WCAG AAA for patient portal, AA for staff portal" ], "unknown_fields": [ "Exact SLAs for uptime and response times", "Supported channels beyond web (mobile app, call center integration)" ] }

Здесь CoT обычно проявляется в том, что модель сначала разматывает в голове "о чем вообще документ", а потом структурирует ответы – и это видно по более чистым и полным спискам по сравнению с "дай мне просто summary".

1.2. Вытаскиваем функционал и грубо приоритизируем

Следующий шаг – превратить текст в функциональные блоки и понять, что для заказчика "must-have", а что можно двигать. Для этого я подмешиваю RICE-логику – Reach, Impact, Confidence, Effort.

Пример условного промпта:

[C] Контекст У тебя есть RFP на систему записи в гос-клиниках. Ты уже понимаешь цели и роли (см. контекст ниже). [R] Роль Ты – системный аналитик, который готовит список фич для пресейла и хочет грубо приоритизировать их по RICE. [I] Инструкция (с CoT) 1. Подумай шаг за шагом: – какие крупные функциональные блоки явно следуют из RFP; – какие фичи внутри блоков поддерживают цели заказчика. 2. Для каждого feature оцени: – Reach: % пользователей, которых это затронет (по пятибалльной шкале 1–5), – Impact: насколько сильно это влияет на цели (1–5), – Confidence: насколько ты уверен в оценках (0.5 / 0.8 / 1.0), – Effort: относительную сложность реализации (1–5, где 5 – дорого). 3. Посчитай черновой RICE score = (Reach * Impact * Confidence) / Effort. 4. Верни результат в JSON. [S] Subject Краткое описание требований из RFP: <<< [сюда краткая выжимка требований: порталы, интеграции, аналитика и т.д.] >>> [P] Preset Сфокусируйся на 5–7 ключевых фичах. Пиши на английском. Не придумывай сложные числа – работай с целыми. [E] Exceptions Если данных не хватает для Confidence или Effort – ставь Confidence = 0.5 и помечай feature как "needs clarification".

Пример ответа, опять же чисто фрагмент, для общего понимания повествования:

{ "features": [ { "id": "F1", "block": "patient_portal", "name": "Online appointment booking", "description": "Patients can search doctors and book appointments without calling.", "rice": { "reach": 5, "impact": 5, "confidence": 0.8, "effort": 3, "score": 6.67 } }, { "id": "F2", "block": "notifications", "name": "SMS reminders", "description": "Automated reminders 24h and 1h before visit.", "rice": { "reach": 5, "impact": 4, "confidence": 1.0, "effort": 2, "score": 10 } }, { "id": "F3", "block": "reporting", "name": "Advanced no-show analytics", "description": "Detailed reports on no-show patterns by clinic/doctor.", "rice": { "reach": 3, "impact": 4, "confidence": 0.5, "effort": 4, "score": 1.5 } } ] }

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

1.3. Из черновика в… более надежный черновик

Даже локальная модель может наплодить уверенной ерунды. Чтобы снизить шанс этого я часто использую паттерн Chain-of-Verification (CoV): сначала модель делает черновик, потом сама придумывает проверочные вопросы, отвечает на них и только потом уточняет ответ.

Промпт-надстройка к предыдущему:

[CoV STEP 1] Draft Сначала сделай черновой список features с RICE как раньше. [CoV STEP 2] Plan verification Потом сформулируй 5–7 конкретных вопросов, которые помогут проверить твой черновой список на здравый смысл (например: "Не дублируются ли F1 и F4?", "Не завышен ли Effort у F3?"). [CoV STEP 3] Verify Ответь на эти вопросы отдельно, кратко, по одному-двум предложениям на вопрос. [CoV STEP 4] Revise С учетом ответов пересмотри RICE-оценки и пометь те фичи, которые требуют обсуждения с командой. Верни только финальный, пересмотренный JSON.

Пример того, как это может выглядеть в ответе (сильно сокращаю):

{ "features": [ { "id": "F2", "name": "SMS reminders", "rice": { "reach": 5, "impact": 4, "confidence": 1.0, "effort": 2, "score": 10 }, "verification_notes": [ "High reach and impact confirmed; depends on SMS gateway but typical implementation is standard." ] }, { "id": "F3", "name": "Advanced no-show analytics", "rice": { "reach": 3, "impact": 4, "confidence": 0.5, "effort": 4, "score": 1.5 }, "verification_notes": [ "High effort and medium reach; mark as 'needs clarification' for presale discussion." ], "needs_clarification": true } ], "meta": { "notes": [ "Some features were merged due to duplication (F4 collapsed into F1).", "Effort for reporting features was reduced from 5 to 4 after verification." ] } }

Здесь мне важно не то, что модель внезапно дала идеальный ответ, а то, что она сама подсветила спорные зоны – это считай готовый список редфлагов к пресейл-встрече.

Шаг 2. Облачный контур: ChatGPT, Gemini, Perplexity как внешний контекст

Применение AI в пресейле

Локальная модель прекрасно разбирает документы, но живет в границах того, что я ей скормил и ограничена в производительности (по крайней мере у меня не слишком производительное железо). Чтобы не продумывать все с нуля, а свободно пользоваться благами человечества и интеллектом всего интернета я все же подключаю облачные обычные модели:

  • ChatGPT – для структурирования гипотез, списков, удобной работы со structured outputs;
  • Gemini – когда нужен более плотный web-ресерч и работа с разными типами данных;
  • Perplexity – как "тяжелый ресерчер": строит отчеты с ссылками и объяснениями.

Здесь важно: ни один из этих сервисов не видит исходный RFP. В облако уезжает только:

  • обезличенный домен (government appointment & visit management system);
  • функциональные блоки и NFR без названий систем и инфраструктуры.

2.1. Картина рынка и паттерны

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

Помогут нам в этом “три кита” хорошего исследования – CRISPE + CoT + CoV

Пример промпта к ChatGPT/Gemini в с использованием этого подхода:

[C] Context We are designing an appointment & visit management system for government outpatient clinics. Data in the original RFP is sensitive; you only see an anonymized skeleton of requirements. [R] Role You are a product analyst with strong knowledge of healthcare and digital appointment systems. [I] Instruction (with CoT + CoV) First, think step by step (Chain-of-Thought): 1) Identify main market segments where such systems are used. 2) Describe 5–7 typical solution types (product classes), not specific vendors. 3) For each solution type, outline common UX patterns and differentiation levers. Then apply Chain-of-Verification: 4) Draft your answer. 5) Generate 5 verification questions that would help you check your own draft. 6) Answer those questions briefly. 7) Refine your draft based on verification. Return only the refined result as structured JSON. [S] Subject Anonymized requirements overview: <<< [сюда выжимка: patient portal, staff portal, scheduling, notifications, reporting, admin console] >>> [P] Preset Focus on patterns relevant to MENA public healthcare context, but do not mention any country or city names. [E] Exceptions If you are not sure about something, mark it as "low_confidence": true.

На выходе получается что-то такого вида, но, понятное дело, сильно большего объема:

{ "segments": [ { "id": "public_clinics", "description": "Government-owned outpatient and primary care clinics", "typical_objectives": [ "Reduce pressure on call centers", "Increase online booking adoption", "Improve visibility for regulators" ] }, { "id": "private_networks", "description": "Private clinic chains and hospitals", "typical_objectives": [ "Increase patient loyalty", "Cross-sell services", "Optimize resource utilization" ] } ], "solution_classes": [ { "id": "self_service_portal", "description": "Web and mobile portals where patients manage appointments", "common_patterns": [ "Dashboard with upcoming visits", "Family profile management", "Omnichannel notifications (SMS, email, sometimes WhatsApp)" ], "differentiation": [ "Depth of integration with clinical systems", "Quality of UX and accessibility", "Support for multi-language and RTL" ] } ], "meta": { "low_confidence_areas": [ "Adoption metrics for specific regions" ] } }

Здесь CoV работает как встроенный фильтр: модель сама придумала проверочные вопросы, прошлась по ним и немного подчистила вывод.

2.2. Приоритизация болей и возможностей

Полезный трюк – попросить модель приоритизировать боли и возможности тоже через RICE: не для финального roadmap, а чтобы понять, куда стоит вложиться в прототипе. Это валидно, потому что если у целевой аудитории и конкурентов что-то болит, то вероятнее всего ваш потенциальный заказчик знает об этом или у него тоже болит, а значит прототип попадет что называется “в самое сердечко”

Пример промпта:

[C] Context We are preparing a presale prototype for an appointment system in public clinics. We want to focus on the most impactful user problems and opportunities. [R] Role You are a product manager. You know the RICE framework (Reach, Impact, Confidence, Effort). [I] Instruction (with CoT) 1) For each role (patient, family_member, receptionist, clinic_admin): – list 3–5 key pains, – propose 1–2 solution ideas for each pain (feature-level, not UI pixels). 2) For each solution idea, estimate: – Reach: how many users it affects (1–5), – Impact: effect on user outcomes (1–5), – Confidence: 0.5/0.8/1.0, – Effort: relative complexity (1–5). 3) Compute a rough RICE score and sort ideas per role. [S] Subject Short role descriptions: <<< [сюда кратко: кто пациент, кто регистратор, кто админ и т.д.] >>> [P] Preset Return concise JSON per role. Use English. [E] Exceptions If you are very unsure about Effort, set Confidence=0.5 and flag the idea with "needs_product_team_review": true.

Небольшой фрагмент ответа:

{ "role": "patient", "ideas": [ { "pain": "Hard to reschedule or cancel appointments without calling.", "solution": "Self-service rescheduling and cancellation with clear rules and limits.", "rice": { "reach": 5, "impact": 4, "confidence": 0.8, "effort": 3, "score": 5.33 } }, { "pain": "Unclear preparation instructions before visit.", "solution": "Pre-visit checklist and reminders per appointment type.", "rice": { "reach": 4, "impact": 3, "confidence": 0.5, "effort": 2, "score": 3.0 }, "needs_product_team_review": true } ] }

Это уже не просто "боли", а карта, к чему стоит привязать сценарии в прототипе.

Шаг 3. Обратно в локальный контур за юзкейсам

Применение AI в пресейле

На этом шаге внешний мир для меня снова отключается – я возвращаюсь в локальный контур с Qwen и работаю только с тем, что уже собрал:

  • структурированный RFP;
  • список фич с RICE;
  • роли, боли, возможности;
  • типовые UX-паттерны.

На этом этапе перед нами и ИИ стоит задача – собрать черновой набор юзкейсов и пользовательских потоков, из которых потом родится и структура системы, и прототип.

Здесь поверх CoT имеет смысл использовать что-то из мира causal chain-of-thought (CauCoT). Идея в том, чтобы строить сценарий как цепочку причинно-следственных связей, а не просто последовательность шагов.

3.1. Триггер → условие → действие → результат

Пример запроса к локальной Qwen3-14B упрощенно:

[C] Контекст У тебя есть: – структура требований из RFP, – роли и их боли, – карта продуктовых идей с RICE. [R] Роль Ты – системный аналитик и UX-архитектор. [I] Инструкция (CoT + CauCoT) 1) Для ролей patient, family_member, receptionist, clinic_admin выбери по 3–5 ключевых сценариев, которые критичны для успеха системы (ориентируйся на RICE-оценки). 2) Для каждого сценария опиши его в формате causal chain-of-thought: – Trigger: что запускает сценарий, – Preconditions: что должно быть верно перед началом, – Action steps: шаги пользователя и системы (по очереди), – Outcomes: что должно произойти в конце, – Failure modes: что может пойти не так и почему. 3) На основе causal-описания сформируй use case в виде JSON. [E] Exceptions Не выдумывай технические детали (конкретные API, названия систем). Фокусируйся на поведении пользователей и системе в терминах "что", а не "как".

Очень сильно упрощенный фрагмент ответа:

{ "use_cases": [ { "id": "UC1", "role": "patient", "name": "Book a new appointment for self", "causal_chain": { "trigger": "Patient decides to book a visit instead of calling the clinic.", "preconditions": [ "Patient has a valid digital identity", "Clinic has published available slots" ], "action_steps": [ "Patient opens the portal and logs in.", "System loads patient profile and existing appointments.", "Patient chooses 'Book new appointment'.", "Patient selects clinic and specialty.", "System shows available doctors and slots.", "Patient picks doctor and time slot.", "System temporarily reserves the slot.", "Patient reviews summary and confirms booking.", "System finalizes appointment and sends confirmation." ], "outcomes": [ "Appointment created with status 'Scheduled'", "Patient receives confirmation via portal and SMS" ], "failure_modes": [ "Selected slot becomes unavailable before confirmation (race condition)", "Integration with clinic system fails (temporary error)", "Patient does not complete flow within timeout (reservation expires)" ] } } ] }

Дальше я уже руками:

  • проверяю, не забыл ли AI важные ветки (такое бывает, но все реже);
  • добавляю опыт из прошлых проектов (когда делаешь не первый десяток таких ком предложений примерно представляешь что от тебя хотят);
  • связываю это с оценками, фазами и общим контекстом.

Шаг 4. От юзкейсов к прототипу

К этому моменту у нас есть:

  • разложенный по полочкам RFP;
  • очень грубая приоритизация фич;
  • роли и их боли;
  • набор юзкейсов и causal-флоу.

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

Здесь в ход идет Figma Make: я использую ее не как "нарисуй мне красивый UI из воздуха", а как ускоритель, который из детального текстового описания может собрать:

  • каркас интерфейсов по ролям;
  • ключевые флоу;
  • состояние экранов и edge cases.

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

Сгенерируй для меня подробный промпт для Figma Make, который: – покроет все ключевые сценарии по ролям (patient, receptionist, clinic admin, system admin), – учтет двуязычность (AR/EN), RTL, WCAG AAA/AA, – будет использовать только обезличенные мок-данные, – не будет содержать ни одной сенситив ссылки на реального заказчика или инфраструктуру

Результат – обычно, гигантский промпт, типа такого (добавил файлом потому что тут точно не уберется)

В нем описаны:

  • лендинг с выбором роли;
  • сценарии пациента (поиск врача, запись, перенос, отмена, семья);
  • сценарии регистратуры (check-in, очередь, walk-in, статусы визитов);
  • админка (расписания, аналитика, управление клиниками и пользователями);
  • edge cases и ошибки.

Этот промпт пойдет в Figma Make → на выходе получается первый вариант прототипа, который:

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

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

  • подгоняю общий лейаут под требования и под свой вижн того как оно должно быть;
  • убираю лишнее и усиливаю ключевые сценарии.
  • дорабатываю edge кейсы, так как с ними объективно make справляется спорно, но это связанно с тем что мы не можем писать излишне детализированный промпт
Применение AI в пресейле

Посмотреть что получилось можно вот тут: тык

Не сказал бы что это пример какого-то идеального прототипа и уж тем более не пример дизайна, но уверяю вас что это уже значительно больше чем сделают 80% ваших конкурентов на бидах

Где я сознательно нажимаю стоп

В реальном пресейле на этом история естественно не заканчивается:

  • к прототипу прикручиваются оценки по командам и срокам;
  • строится роадмап с описанием какие роли на каких этапах жизненного цикла нужны;
  • собираются варианты фаз и сценарии внедрения;
  • все это превращается в полноценное коммерческое и техническое предложения.

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

В этом тексте мне хотелось показать именно дизайнерский и продуктовый кусок процесса:

  • как разделить контуры так, чтобы сенситив данные никогда не покидали локальный периметр;
  • как использовать ChatGPT, Gemini и Perplexity не как "оракул", а как еще один слой ресерча, который нужно перепроверять;
  • как локальная Qwen3-8B/14B может быть автором драфтов для структур, юзкейсов и даже помощником при формировании промптов для Figma Make или аналогов;
  • и как прототип в итоге становится аргументом в диалоге с заказчиком, а не просто красивой картинкой.

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

Надеюсь было интересно и не слишком нудно)

Начать дискуссию