Етап 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-стартап для розгортання blockchain-вузлів зі складним функціоналом та сильними конкурентами. Продукт запускався у надконкурентному середовищі Web3, де вже працювали такі гіганти, як QuickNode та Alchemy.

Дослідження показало, що більшість конкурентів мають складні інтерфейси, заплутану логіку ціноутворення, використовують технічну лексику та орієнтуються виключно на підкованих юзерів. Водночас RPC Fast мав донести суть технічно складного продукту до дуже різної аудиторії: від розробників до стартапів та enterprise-клієнтів.

Тому замість чергового «складного продукту для технічних спеціалістів» було обрано інший підхід: спростити навігацію, зробити ключові переваги очевидними та пояснити складні речі зрозумілою мовою. Навіть калькулятор цін став частиною 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-проєкт, розробка нового софту або e-commerce продукт, Discovery часто сприймають як «необов'язковий» крок, який можна пропустити, щоб запуститися швидше.

Але насправді у життєвого циклу продукту є лише один етап, коли помилки виправляти дешево. Це Discovery. Кожен наступний етап обходитиметься дорожче.

На практиці етап дослідження:

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

І хоч Discovery не гарантує успіх порєкту, але він суттєво зменшує ризик створити продукт, який нікому не потрібен або яким просто неможливо користуватися.