Этап Discovery: как сохранить бюджет проекта, пока не стало слишком поздно

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

Но действительно ли это экономия?

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

Что такое этап исследования проекта?

Исследование проекта (Discovery Phase) — это стратегический этап, который предшествует дизайну и разработке. Его главная цель — согласовать бизнес-цели, потребности пользователей и технические возможности, чтобы четко понять, что именно нужно создать или изменить, и почему.

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

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

Ответив на эти вопросы еще на старте, этап Discovery предотвращает неконтролируемое разрастание масштаба проекта (scope creep), отсекает ненужные функции и дает максимально реалистичную оценку стоимости и сроков еще до начала работ. В результате ваш бюджет тратится только на то, что действительно приносит ценность.

5 шагов Discovery Phase, которые помогают избежать месяцев дорогостоящих доработок

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

1. Обсуждение: синхронизируйте команды и отбросьте все лишнее

Спросите Product Owner-а, стейкхолдеров, разработчиков, UX/UI-дизайнеров и CMO, как должен работать и выглядеть продукт, и, скорее всего, услышите пять разных ответов.

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

Именно для этого существует этап стратегического позиционирования и этап определения уникального торгового предложения (УТП). Он помогает командам определить: кто является ключевой аудиторией, какая проблема действительно имеет значение, какой флоу приносит наибольшую ценность для бизнеса, и что продукту на самом деле нужно в первой версии (или что нужно исправить в первую очередь, если проект уже существует).

Без этого шага списки фич растут бесконечно, ведь каждая функция кажется «крайне важной». Discovery помогает командам сузить фокус, а не пытаться построить все и сразу.

Хороший пример — CRM-платформа для логистики с несколькими ролями пользователей, операционными процессами, админ-панелями и разнообразными внутренними бизнес-требованиями. Задача заключалась не только в том, чтобы сделать систему функциональной, но и интуитивно понятной для совершенно разных типов пользователей.

Благодаря Discovery удалось отделить критически важный функционал от второстепенного, сфокусироваться на основных сценариях пользователей и значительно сократить время выхода продукта на рынок.

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

{{block}}

2. Исследование рынка и конкурентов: пользователи всегда сравнивают

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

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

Рассмотрим пример RPC Fast, SaaS-стартапа по развертыванию блокчейн-узлов со сложным функционалом и сильными конкурентами. Продукт запускался в крайне конкурентной среде Web3, где уже работали такие гиганты, как QuickNode и Alchemy.

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

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

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

3. Оптимизация информационной архитектуры: красивый UI не спасет сломанную структуру

Большинство UX-проблем связаны не с визуалом, а со структурой.

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

Именно поэтому во время Discovery создаются Customer Journey Mapping (CJM) и информационная архитектура продукта. Аналитика показывает, куда идут пользователи, а вот Discovery помогает разобраться, почему они идут и что вызывает неуверенность или негативные эмоции еще до момента конверсии.

Именно это помогло сделать редизайн Samsung Experience Store эффективным, а не просто визуально красивым. Перед тем, как перейти к дизайну, проект прошел полноценный этап Discovery с аудитом юзабилити, воркшопами и интервью, чтобы понять, как пользователи взаимодействуют с брендом в онлайн и офлайн.

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

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

4. Прототипирование: ошибки в вайрфреймах обходятся дешевле, чем в продакшене

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

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

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

Возьмем, к примеру, такую сложную платформу, как NFTrends, которая объединила блокчейн, товары класса «люкс» и цифровое искусство, но не имела ни одного аналога на рынке, на который можно было бы ориентироваться. 

Задача заключалась не только в том, чтобы спроектировать четыре разных флоу (для владельцев бизнеса, менеджеров по управлению запасами, дилеров и покупателей), но и в том, чтобы сделать технически сложный продукт понятным для аудитории, далекой от Web3.

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

5. Стратегия развития: эффективные продукты создают с мыслью о будущем

Roadmap — это не просто график релизов. Это план развития продукта, который определяет, что нужно реализовать сейчас, а что стоит отложить до того момента, когда базовая ценность уже подтверждена. И так вы добавляете новые фичи не потому, что конкуренты что-то выпустили, или потому, что это звучит как «хорошая идея», а потому что это действительно нужно.

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

Что получает бизнес после Discovery Phase? И почему этот этап настолько важен для сокращения затрат на проект?

Результатом Discovery становятся не презентации, диаграммы, прототипы или набор документов.

Бизнес получает четкое видение продукта, согласованный MVP или объем редизайна, проверенные пользовательские флоу, прототипы, информационную архитектуру, UX-рекомендации и roadmap развития. 

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

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

Что происходит после Discovery Phase?

Что дальше? Дизайн и разработка, но уже не с набором предположений, а с проверенным планом действий.

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

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

{{block}}

Discovery Phase: что этот этап на самом деле дает бизнесу?

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

Но на самом деле в жизненном цикле продукта есть только один этап, когда исправлять ошибки дешево. Это Discovery. Каждый следующий этап будет обходиться дороже.

На практике этап исследования:

• Для новых продуктов — это способ проверить гипотезы до того, как они превратятся в дорогостоящие решения;
• Для существующих проектов — возможность найти реальные причины проблем и сформулировать четкую задачу для редизайна или развития, вместо расплывчатого «сделайте, чтобы было лучше».

И хотя Discovery не гарантирует успех проекта, но он существенно снижает риск создать продукт, который никому не нужен или которым просто невозможно пользоваться.