Discovery — это вам не канал про животных. Это один из самых важных этапов работы над проектом

Представьте: компания решила сделать новый сервис. Руководитель хочет сократить расходы, сотрудники — избавиться от ручной работы, пользователям нужен удобный личный кабинет. У команды уже есть десятки идей, но пока непонятно, какие проблемы решать в первую очередь, как должен работать будущий продукт и во сколько всё это обойдётся.

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

Немного об AffArts и нашем подходе

Привет, мы AffArts — дизайн-центричное агентство. Проектируем и разрабатываем сайты, сервисы и цифровые продукты, создаём айдентику, бренд-системы и коммуникационный дизайн.

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

По версии Рейтинга Рунета мы занимаем:

1. 14 место среди дизайн-студий России;
2. 19 место среди креативных агентств;
3. 17 место среди студий в продуктовом дизайне;
4. 15 место среди студий по веб-дизайну.

Discovery помогает определить объём работы на проекте, построить план развития продукта и посчитать бюджеты

Discovery  — это исследовательский этап перед созданием или обновлением продукта. На нём команда собирает контекст, изучает проблемы и формирует требования к будущему решению.

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

По итогам исследования у команды и заказчика появляется общее представление о проекте: 

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

В этой статье разберём, как мы проводим Discovery на примере проекта для «Опека Дома».

«Опека Дома» обратилась к нам за технической поддержкой

«Опека Дома» помогает подобрать сиделку для человека, которому нужен уход. Родственник оставляет заявку, команда уточняет условия, подбирает специалиста и сопровождает заказ. Подбор и оплата проводятся через сервис.

В этом процессе участвуют несколько сторон:

1. Клиент — заказывает услугу. 
2. Сиделка — ухаживает за подопечным.
3. Куратор — помогает им договориться и следит за выполнением заказа.
4. Финансовая команда — занимается расчётами и выплатами.

Команда «Опеки Дома» обратилась к нам с запросом на техническую поддержку их действующего продукта. Заказчик хотел сменить подрядчика и передать дальнейшую работу над сервисом новой команде.

Поддерживать текущий сервис оказалось дороже, чем создать новый

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

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

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

После оплаты к работе подключалась финансовая команда. Финансистам нужно было проверить поступление денег, учесть платёж в расчётах, определить сумму выплаты сиделке, рассчитать и удержать комиссию сервиса. Если по заказу требовался возврат, его тоже приходилось учитывать.

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

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

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

На этапе брифинга мы сравнили два сценария: 

1. продолжать поддерживать и постепенно дорабатывать текущий сервис, 
2. спроектировать новый продукт. 

Расчёты показали, что идти по первому сценарию будет сложнее и сильно дороже. Поэтому мы предложили пойти по второму пути и начать с Discovery. 

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

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

Начали с интервью и разбора текущих процессов

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

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

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

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

1. Финансы и расчёты. Проследили, что происходит с деньгами после оплаты клиента: как платёж учитывают в системе, как рассчитывают комиссию и выплаты сиделке, как обрабатывают возвраты и сверяют данные с внутренней ERP.

1. Планы развития. Обсудили изменения, которые команда уже хотела внедрить в ближайшие месяцы. Сверяли эти планы с тем, что увидели в текущих процессах: какие операции стоит автоматизировать в первую очередь, что перенести во внутреннюю систему и в какой последовательности менять сервис.

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

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

Изучили конкурентов и их решения

Параллельно в исследовании рассматривали прямых конкурентов и продукты из смежных сфер. Среди референсов были Skyeng, «Ясно», «Профи.ру» и YouDo.

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

Отдельно рассматривали сервис Papa Pal, который заказчик назвал ориентиром на стратегическом интервью. В нём нас интересовали механики для разовых и более лёгких задач — помочь с бытовыми делами или сопроводить в определённое место.

Для каждой механики нужно было понять, подходит ли она конкретным сценариям «Опека Дома», какую проблему может решить и как её адаптировать под текущую модель сервиса.

Сформулировали гипотезы и продумали пользовательские сценарии

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

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

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

Рассмотрим пример с идеей общего баланса:

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

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

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

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

Собрали результаты Discovery в план развития продукта

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

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

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

Презентация итогов в формате сайта. Собрали основные проблемы, выводы и решения в компактную презентацию. Показали состав первого запуска, возможное развитие после MVP и ориентиры по стоимости и срокам. Такой формат помогает обсудить проект с руководством, не погружаясь сразу во все подробности исследования.

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

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

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

Discovery может быть самостоятельным проектом

Обычно Discovery — один из первых этапов создания или обновления продукта. Но его можно проводить и как самостоятельную работу. По итогам заказчик получает достаточно данных, чтобы спланировать дальнейшие шаги: понимает объём проекта, приоритеты, сроки, бюджет и экономику будущей разработки.

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

Discovery позволяет разобраться с такими вопросами заранее и собрать дальнейшую работу в понятный план.

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

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

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

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

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

Если вам интересны темы продуктового дизайна, UX, исследований и онлайн-сервисов — подписывайтесь на Telegram-канал AffArts и читайте материалы на странице агентства в Workspace. Там мы регулярно делимся кейсами, исследованиями и практическими рекомендациями для бизнеса.

А также следите за нами здесь: VK, Dribbble, Dprofile, Pinterest.