Прошли те времена, когда для создания цифрового продукта достаточно было одного технического задания. Рынок развивается, пользователи становятся всё более взыскательными, конкуренты тратят миллионы на исследования.
Всё это влияет на сложность и глубину проработки IT-решений. Теперь никто не проектирует сайт сложнее лендинга в одиночку. О мобильных приложениях и говорить нечего: там ещё более глубокий контакт с пользователем и технологиями.
Но усложнение проектирования ведёт к усложнению документации. Я уже писал о том, что нужно сделать, чтобы вашу документацию читали. Теперь пришло время как-то структурировать тот хаос, что частенько начинает творить в проекте, когда количество файлов и документов в проекте приближается к сотне.
Я предлагаю разбить всю проектную документацию на логических 4 слоя. Мало того, что это позволить разложить по полочкам тьму артефактов проектирования, так ещё и предоставит пользователям документации более удобную механику взаимодействия. Условным разработчикам не придётся прорываться через финмодели, а клиенту или CEO – через описание программных интерфейсов и баз данных.
Концепция
Её называют по-разному: проектное задание, результаты брифа. Суть одна: это краткое, но однозначное описание проекта. Основа основ, от которой растёт все остальное. Концепция должна в себя включать основные факторы, определяющие необходимость продукта и его описательную часть. Чёткого формата, разумеется, нет, все проекты индивидуальны. Но если вы стругаете типовые интернет-магазины, то со временем вполне сможете собрать себе некий шаблончик – и просто его заполнять.
Чтобы было понятнее, вот минимальный список того, что я обычно включаю в концепцию:
- Краткое описание продукта, всего несколько предложений. Например, что-то вроде "мобильное приложение для борьбы с незаконной эвакуацией автомобилей".
- Примерное описание целевой аудитории. Точной информации о ЦА на старте у вас все равно не будет, но от каких-то данных нужно отталкиваться. Например, "автовладельцы Москвы от 18 до 35 лет".
- Задачи продукта (как для пользователей, так и для бизнеса). Тут все просто: автовладельцам – избежать незаконной эвакуации, бизнесу – заработать бабла на подписках.
- Описание основной механики. Самое сложное. Здесь нужно рассказать, каким образом предполагается дать пользователям возможность решения их задачи.
- Состав продукта. То, из чего состоит ваш продукт: например, мобильное приложение, сервер, внешние интеграции.
- Технические требования. Это необязательный, но крайне желательный пункт. Здесь вы перечисляете всякие технические аспекты: мобильные приложения должны быть нативными, сервер масштабируемым, а интеграции будут как минимум с сервисом пуш-уведомлений и яндекс-картами.
Разумеется, вы можете дополнить этот список любой информацией – но помните, что концепция должна быть простой и понятной как фаундерам, заказавшим продукт, так и всем остальным: маркетингу, разработчикам и даже уборщице. Главная задача концепции – на самом старте сформировать у всех единое и однозначное понимание продукта. Погрузить всех участников процесса в единое информационное поле и потом уже не давать им выбраться оттуда.
У меня есть несколько отдельных статей по концепции, я приведу ссылки на них в конце этого поста.
Бизнес-слой
Этим слоем частенько пренебрегают. Мол, и так всё понятно, бизнесу нужны деньги. На самом деле, конечно, зря.
Бизнес-слой – самый важный в проекте. Именно он задаёт направление развития продукта, именно от него зависит то, какими функциями будет обладать разрабатываемая система.
Чаще всего я включаю сюда:
- Цели и задачи бизнеса. Если в концепции мы упоминали их вскользь, то здесь уже нужно расписать их максимально подробно. Цели раскладываются в задачи, которые, в свою очередь, уже становятся целями продуктового дизайна. Однако недостаточно просто описать такие цели. Нужно указать, как именно они будут достигаться.
- Аналитика рынка. Здесь мы смотрим на потребительский спрос, выясняем подводные камни выхода на рынок и так далее. Чаще всего, на этом этапе приходится приглашать бизнес-аналитика – все проекты разные, и знаний даже крутого продуктового дизайнера может не хватить.
- Исследования конкурентов. Не всегда конкуренты – это те, кто предоставляет такие же товары/услуги, что и ваш бизнес (рекомендую почитать про слои конкуренции по JTBD). Важно понимать, как именно наши конкуренты решают задачи пользователей, на чём зарабатывают и прочее.
- Монетизация. Она есть даже тогда, когда её, казалось бы, нет – например, на волонтёрских проектах. Однако даже здесь монетизация измерима, просто не в евро и долларах, а в сэкономленных человеко-часах.
- Метрики успешности проекта, KPI. Святая святых любого проекта. Именно от того, правильно ли вы разложите критерии успеха, будет зависеть вектор развития дизайна и продукта в целом. Например, если ваша задача – удерживать внимание пользователя максимально долго, то в дизайн нужно заложить специальные механики по формированию "состояния потока" (ниже будет ссылка).
В бизнес-слой можно ещё много чего напихать, в зависимости от открытости бизнеса и особенностей проекта. То, что перечислено выше – лишь базис, основа.
Пользовательский слой
В этой части документации обычно содержится всё, что касается пользователей нашего продукта.
Сюда обычно входят:
- Результаты исследований, если они проводились. Сюда же можно включить любые экспертные оценки и выкладки, если они касаются пользователей. Можете даже персонажей сюда впихнуть.
- Механики. В этой объёмной части я обычно расписываю основную механику продукта и всякие дополнительные механики: удержание и возврат, например. По факту, расписанная детально часть из концептуального слоя.
- Диаграммы пользовательских сценариев. Всякие Customer Journey Map и любые аналоги. Я, например, предпочитаю сиджиэмкам диаграммы функциональности в разрезе всего продукта, включая клиент, сервер, обмен данными и аналитику. Но тут на любителя. Это вообще могут быть не диаграммы, как вам угодно. Главное, чтобы их поняли разработчики и вы сами.
- Информационная архитектура. Вообще, Information Architecture не идеально вписывается в пользовательский слой, так как затрагивает большое количество соседних областей, включая техническое проектирование. Однако без грамотной IA невозможно, например, построить правильную навигацию, поэтому она именно в этом разделе. По информационной архитектуре у меня тоже есть пара статей, ссылки будут в конце.
- Навигационная модель продукта. То, как пользователь путешествует по вашему продукту: страницы, таксономии (категории), основное и вспомогательные меню. Важно, чтобы эта часть идеально ложилась на пользовательские сценарии.
- Прототипы или наброски интерфейсов. Кто-то сразу предпочитает делать интерфейсы в цвете и максимально приближенными к конечному виду, но тут многое зависит от опыта и профессионализма дизайнера, от сложности продукта. Я рекомендую начинать с простого, хотя да – серые квадратики очень часто не работают.
- Дизайн-макеты. О да, они самые. Но не просто дизайн-макеты, а разбитые на компоненты, легко изменяемые и масштабируемые.
И снова: дополняйте этот список в соответствии со своим понимаем продукта, но не забывайте о целесообразности.
Технический слой
Но если с предыдущими пунктами всё более или менее понятно, то сейчас мы переходим к более сложным вещам. К более сложным, но не более страшным. Речь о техническом слое документации.
Здесь тот же принцип, что и раньше: состав, список артефактов может существенно отличаться от дизайнера к дизайнеру и от проекта к проекту.
И всё же, от чего-то нужно отталкиваться. Давайте я просто расскажу про некий мастхэв технических артефактов:
- Компоненты. Здесь обычно описывается, из каких частей состоит сервис и какую роль выполняет каждая. Например, два мобильных приложения (iOS и Android), сервер, админпанель. Приложения, допустим, нативные, выполняют вот такие-то функции, имеют вот такие-то внешние интеграции.
- Аналитика. Уже на старте нужно понимать, какие данные вы будете собирать, какие действия пользователей отслеживать. Если нужно, советуйтесь с маркетологами. Но базовые вещи, вроде сохранения пользовательского пути или главного события продукта (типа кнопки “купить”), вы можете уверенно фиксировать сами. Данные аналитики бывают двух типов: внутренние и внешние. Внутренние – это про состояние пользователей (например, количество баллов, факты их списания или начисления). Внешние данные – это, как правило, путь пользователя, какие-то события, которые отправляются во внешние системы, вроде гугл аналитики и яндекс метрики. Если кому интересно – в конце тоже будет ссылка.
- Функциональная архитектура. Помните, что у разработчиков довольно узкий фокус. Помогите им. Разбейте ваш проект на функциональные разделы (например, регистрация, профиль, лента), и внутри каждого запилите список функций с описанием логики. Выделите общие функции (типа сообщения об отсутствии интернета) – за вас этого никто не сделает, скорее всего. В конце будет ссылка, которая подскажет, с чего можно начать.
- Обмен данными. То, как ваши компоненты обмениваются между собой и внутри себя данными. Сюда может входить дизайн данных, описание API и так далее.
- Интеграции, внешние и внутренние. Описание того, как встраиваются в проект всякие аналитики, пуши, платёжные системы и так далее.
И снова: вы вправе расширять этот список. Например, добавить описание интерфейсных компонентов, их логики (вот есть у вас выпадающий список, например, с поиском – как он работает, откуда берет данные и тп).
Обещанные статьи
Я столько понаообещал ссылок, что теперь бы не запутаться в них. Держите:
- Пример информационного проектирования на реальном проекте.
--
Все свои посты я аккумулирую в камерном телеграм-канале, подписывайтесь.