Состав и структура концепции цифрового продукта

Все статьи цикла:
Почему вашему проекту нужна концепция
Состав и структура концепции цифрового продукта (вы здесь)

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

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

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

Состав концепции

Есть шесть обязательных моментов, которые я прорабатываю на каждом проекте. У вас их может быть больше, но вот меньше – вряд ли. Не могу себе представить проекта, на котором позволил бы себе хоть что-то отсюда исключить.

Краткое описание проекта

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

Эта часть нужна для того, чтобы:

отбросить всё лишнее, сформулировать ядро проекта;
обеспечить плавное погружение читателей в вашу документацию;

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

Цели и задачи бизнеса

Цели бизнеса (или кто там у вас вместо него на проекте) всегда про деньги, но не всегда напрямую. Даже если вы создаёте исключительно волонтёрский продукт, всё равно польза от него может быть выведена метрически (например, в количестве сэкономленных человеко-часов).

Но и у классического бизнеса цели не всегда явно материальны. Например: «укрепить имидж бренда в молодежной среде», «увеличить лояльность пожилых клиентов». Вот тут важно: вы должны вытащить эти цели из бизнеса, хотя он (особенно некрупный) зачастую отмахивается фразами типа «да что тут непонятного, нам бы бабла заработать». Конкретизируйте.

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

Потребности пользователей

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

Описание основной механики

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

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

Состав продукта и его технические особенности

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

Кроме того, именно здесь прорабатывается примерный состав компонентов и интеграций (внешних и внутренних): сервер, базы данных, системы аналитики, пуш-уведомления, платёжный агрегатор и так далее. Желательно кратко описать каждый компонент – это сильно упростит дальнейшую работу аналитикам и инженерам.

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

Ограничения

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

Например, в сервисе категорически нельзя использовать персональные данные пользователей, так как это сервис по анонимайзингу (услуги географически распределенных VPN, например). Или наоборот: у вас в сервисе хранятся сканы личных документов пользователей – а это значит, что серверы должны находиться на территории РФ.

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

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

Структура концепции

Обычно здесь у меня четыре ключевых слоя: проект, бизнес, пользователи и техническая экспертиза. Я предпочитаю вести документацию в Confluence, завожу там раздел «Концепция», а в нём 4 подраздела:

Проект

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

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

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

Бизнес

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

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

Пользователи

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

Техническая экспертиза

Это именно «экспертиза», а не полноценное техническое проектирование – на этапе концепции на него обычно нет проектных ресурсов. Однако даже базовая экспертиза позволяет уберечь дальнейший процесс от неверных (и подчас довольно дорогих) шагов.

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

В заключение

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

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

Откуда это всё?

Идея концепции в том виде, которую я здесь изложил, родилась в стенах Цифровой Артели Eleven. Если интересно подробнее узнать о нашем подходе – можете полистать книгу моего партнёра по артели, Вадима Митякина, там много интересного.