Продуктовый дизайн помогает создать цифровой продукт, в котором задачи пользователей связаны с целями бизнеса и возможностями разработки. Чтобы определить, как он будет работать, команда исследует существующие процессы, проектирует и проверяет сценарии, разрабатывает интерфейс и сопровождает его реализацию. В статье разбираем этапы этой работы, инструменты специалистов и результаты, которые получает заказчик.
Что такое продуктовый дизайн
Продуктовый дизайн — это процесс создания и развития продукта с учётом потребностей пользователей, целей бизнеса и технических ограничений. В цифровой среде он охватывает логику работы сервиса, взаимодействие с интерфейсом и его визуальное оформление, помогая связать эти решения в единую систему.
Продуктовый подход применяют при разработке приложений, веб-сервисов, личных кабинетов, порталов и других цифровых систем. Например, при создании кабинета оптового клиента нужно выяснить, какие сведения необходимы для повторного заказа, как показать индивидуальные условия и что произойдёт, если часть товаров окажется недоступна. Ответы на эти вопросы влияют на функции продукта, последовательность действий и содержание экранов.
UX-дизайн охватывает проектирование пользовательского опыта, а UI-дизайн — интерфейса, через который человек взаимодействует с продуктом. В продуктовой работе эти направления связаны с исследованием потребностей, выбором приоритетов и проверкой гипотез. Поскольку границы ролей в командах различаются, состав работ лучше уточнять по конкретным задачам и ожидаемым результатам. Подробнее о понятиях можно прочитать в разборе UX, UI и других терминов.
Продуктовый дизайнер работает вместе с руководителем продукта, аналитиком, разработчиками и представителями заказчика, поэтому в начале проекта важно распределить ответственность. Команда договаривается, кто определяет приоритеты, утверждает требования и принимает результаты, чтобы решения о продукте учитывали интересы бизнеса и условия реализации.
Когда бизнесу нужен продуктовый дизайн
Продуктовый дизайн нужен, когда компания планирует запуск цифрового сервиса или хочет изменить то, как пользователи решают задачи в существующей системе. Объём работы зависит от ситуации: в одном случае предстоит определить устройство нового продукта, в другом — разобраться в затруднениях на конкретном участке.
Рассмотрим условный пример компании, чьи оптовые клиенты передают заказы менеджерам по электронной почте. Чтобы перенести повторные закупки в личный кабинет, сначала нужно понять, как рассчитываются индивидуальные цены, кто согласует заказ и где клиент получает документы. Эти условия определяют структуру кабинета и состав функций, которые потребуются для запуска.
Если кабинет уже существует, но пользователи регулярно обращаются за помощью при оформлении, исследование можно сосредоточить на этом сценарии. Команда изучит действия клиентов и доступные данные, чтобы выяснить причину затруднений и определить необходимые изменения. В зависимости от выводов может оказаться достаточно переработки отдельного участка интерфейса.
Глубину исследования выбирают с учётом неопределённости и риска ошибки. Новому сервису может потребоваться проверка потребностей аудитории, тогда как для знакомого процесса с подтверждённой проблемой бывает достаточно проверки конкретного решения.
Из каких этапов состоит продуктовый дизайн
Работа над продуктовым дизайном включает исследование, постановку задачи, проектирование и проверку сценариев, визуальный дизайн и сопровождение реализации. При этом результаты каждого этапа могут уточнять предыдущие решения: пользовательское тестирование — показать проблему в сценарии, а обсуждение с разработчиками — выявить ограничения, которые нужно учесть в интерфейсе.
Такой порядок согласуется с моделью Double Diamond от Design Council, в которой исследование и уточнение проблемы предшествуют разработке и проверке вариантов решения. Авторы модели подчёркивают, что команда может возвращаться к предыдущим этапам и продолжать улучшение продукта после запуска.
1. Исследование бизнеса и пользователей
Работу начинают с изучения задач бизнеса, потребностей аудитории и существующих процессов. Команда анализирует доступную статистику, обращения в поддержку и внутренние регламенты, проводит интервью и наблюдает за тем, как пользователи выполняют свою работу.
В проекте B2B-кабинета исследование может показать, что закупщик собирает заказ, руководитель согласует сумму, а бухгалтер получает закрывающие документы. Если объединить их в общую категорию «клиенты компании», при проектировании можно упустить различия в действиях, информации и правах доступа.
По итогам команда готовит выводы с указанием оснований, описывает задачи и ограничения, а также отмечает вопросы, которые требуют дополнительной проверки. Заказчик помогает уточнить бизнес-процесс и получить недостающие сведения, чтобы дальнейшие решения опирались на корректные данные.
2. Постановка задачи и выбор приоритетов
Собранные данные помогают сформулировать проблему и определить, какие изменения войдут в ближайшую версию продукта. Команда предлагает гипотезы, объясняет назначение каждого решения и договаривается, по каким признакам будет оценивать результат.
Например, для первой версии B2B-кабинета можно выбрать сценарий повторной закупки, в котором клиент открывает прошлый заказ, меняет его состав и отправляет на согласование. Сохранённые подборки и рекомендации товаров можно отложить, если их необходимость пока не подтверждена и они не требуются для выполнения основной задачи.
После обсуждения заказчик и команда согласуют приоритетные сценарии, требования и ограничения, а также определяют, какие данные понадобятся для проверки решения после запуска. Эти договорённости задают границы ближайшего этапа и помогают оценивать новые предложения по ходу проекта.
3. Проектирование структуры и пользовательских сценариев
На этапе проектирования команда определяет разделы продукта, связи между ними и действия, доступные каждой роли. Затем описывает пользовательские сценарии, чтобы показать путь к конкретной цели с учётом альтернативных действий и возможных ошибок.
В кабинете оптового клиента необходимо продумать, откуда начинается повторный заказ, когда пересчитываются цены и как пользователь узнаёт об изменении условий. В тот же сценарий включают ситуации, когда товар закончился, руководитель отклонил заявку или сотруднику не хватает прав для выполнения действия.
Структуру, схемы сценариев и предварительные экраны обсуждают с заказчиком и разработчиками. Заказчик проверяет соответствие бизнес-правилам, а техническая команда уточняет, какие данные, интеграции и функции нужны для реализации.
4. Создание и проверка прототипов
Прототип позволяет рассмотреть будущий сценарий до разработки, а его детализацию выбирают в зависимости от того, что требуется проверить. Для обсуждения структуры может быть достаточно схемы, тогда как для проверки взаимодействия понадобится последовательность экранов с доступными переходами и действиями.
Во время пользовательского тестирования участнику предлагают выполнить задачу и наблюдают за его действиями. Nielsen Norman Group рекомендует формулировать задания на основе реальных ситуаций, не подсказывая, куда нажимать и в какой последовательности действовать. В примере с кабинетом участника можно попросить повторить прошлую закупку, изменив количество товаров, чтобы проверить, найдёт ли он подходящий путь самостоятельно.
Наблюдения помогают описать затруднения, предположить их причины и подготовить изменения для следующей проверки.
5. Визуальный дизайн интерфейса
Когда логика основных сценариев уточнена, команда разрабатывает визуальное решение: выбирает типографику и цвета, оформляет компоненты, определяет правила размещения информации и адаптирует экраны под согласованные условия использования. Действующую айдентику применяют с учётом читаемости, различимости элементов и удобства взаимодействия.
В B2B-кабинете визуальные решения должны помогать различать статусы заказа, замечать изменение цены и понимать, почему действие недоступно. Поэтому вместе с основными экранами прорабатывают состояния кнопок, полей и уведомлений при загрузке, ошибке и успешном завершении операции.
По итогам заказчик получает согласованные макеты и компоненты с пояснениями, необходимыми для реализации. Если проект предполагает дальнейшее развитие интерфейса, в состав работ могут входить правила их использования и обновления.
6. Сопровождение разработки и развитие после запуска
При передаче дизайна в разработку команда объясняет поведение элементов, переходы между экранами и реакции системы на действия пользователя. По ходу реализации дизайнер участвует в обсуждении вопросов и проверяет, соответствует ли работающий интерфейс согласованным решениям.
Например, макет может предполагать мгновенное обновление индивидуальной цены, хотя учётная система возвращает данные с задержкой. В этом случае нужно определить, что увидит пользователь во время ожидания и как сможет продолжить работу, если получить цену не удастся.
После запуска команда собирает обратную связь и анализирует выполнение целевых действий, чтобы выбрать следующие изменения на основании наблюдений и данных. Состав сопровождения, порядок проверок и ответственность за дальнейшее развитие продукта согласуют заранее, поскольку эти работы могут выходить за рамки разработки макетов.
Какие инструменты используют в продуктовом дизайне
Инструменты продуктового дизайна выбирают в зависимости от задачи и доступных данных. Если команда изучает процесс согласования заказа, ей потребуются сведения о работе сотрудников и правилах компании, а для проверки навигации — наблюдение за действиями пользователей в интерфейсе.
Исследование потребностей и процессов. Интервью, наблюдение, анализ обращений и статистики помогают понять, в каких условиях люди пользуются продуктом и какие затруднения возникают. Подход Jobs to Be Done позволяет рассматривать обстоятельства выбора продукта и результат, к которому стремится человек. Для оптового клиента таким результатом может быть своевременная закупка с подтверждёнными условиями.
Описание опыта и логики. Карты пользовательского пути показывают взаимодействие человека с компанией, включая действия за пределами интерфейса, а схемы процессов и сценариев уточняют последовательность шагов внутри продукта.
Проектирование и прототипирование. Редакторы интерфейсов позволяют подготовить макеты и связать их в интерактивные сценарии. Например, в Figma можно настроить переходы между экранами, представить решение заказчику и проверить взаимодействие с пользователями.
Оценка работающего продукта. Событийная аналитика, анализ последовательности действий и обратная связь помогают изучать использование продукта после запуска. Чтобы данные отвечали на вопросы команды, до настройки нужно определить начало и завершение задачи, различать роли пользователей и выбрать ошибки, которые необходимо фиксировать.
При выборе сервисов также учитывают требования компании к работе с данными и доступам. Независимо от набора программ итоговые материалы должны позволять понять, какие выводы сделала команда, на какие сведения она опиралась и как это повлияло на решения.
Что получает заказчик по итогам продуктового дизайна
По итогам продуктового дизайна заказчик получает согласованные решения о работе продукта и материалы для их реализации и проверки. Комплект определяют под задачу проекта.
В состав результатов могут входить:
- выводы исследования с основаниями, ограничениями и рекомендациями;
- требования к продукту и согласованный состав ближайшей версии;
- структура, роли, права доступа и пользовательские сценарии;
- прототипы с результатами проверки и внесёнными изменениями;
- макеты экранов с необходимыми состояниями и адаптацией;
- библиотека компонентов с правилами применения;
- описание взаимодействий для разработки и план измерения результата.
Чтобы оценить изменения в поведении пользователей или бизнес-показателях, после запуска потребуется собрать и проанализировать данные.
Как оценить результат продуктового дизайна
До разработки результат оценивают по согласованным требованиям, полноте материалов и результатам проверки сценариев. После запуска к этому добавляют наблюдения за использованием продукта и показатели, связанные с исходной задачей.
При приёмке полезно проверить:
- охвачены ли согласованные роли и приоритетные сценарии;
- описаны ли альтернативные действия, ограничения и ошибки;
- понятны ли содержание экранов и дальнейшие шаги пользователя;
- проработаны ли необходимые состояния и варианты отображения;
- достаточно ли разработчикам материалов для реализации поведения;
- какие гипотезы проверили и какие вопросы пока остаются открытыми.
В примере с B2B-кабинетом после запуска можно отслеживать долю завершённых повторных заказов, время их подготовки и обращения за помощью. Для каждого показателя необходимо определить событие и способ расчёта, поскольку отправка заявки на согласование и подтверждение заказа поставщиком отражают разные этапы процесса.
При сравнении результатов учитывают период наблюдения, роли пользователей и сопутствующие изменения. Если вместе с интерфейсом компания поменяла цены или условия поставки, рост заказов нельзя автоматически отнести к дизайну. Когда данных недостаточно, их дополняют интервью и наблюдениями.
Что влияет на сроки и стоимость продуктового дизайна
Сроки и стоимость продуктового дизайна зависят от неопределённости задачи, количества сценариев и ролей, глубины исследования и состава результатов. Оценивать сложность только по числу экранов недостаточно, поскольку один экран согласования может включать несколько уровней доступа, условий и состояний.
При подготовке оценки учитывают:
- наличие исходных требований, аналитики и доступа к пользователям;
- сложность бизнес-правил, интеграций и структуры данных;
- количество платформ и условий использования;
- объём прототипирования и пользовательских проверок;
- необходимость создания или развития дизайн-системы;
- порядок согласований и доступность специалистов заказчика;
- состав сопровождения разработки и работы после запуска.
Сравнивая предложения подрядчиков, стоит проверить, одинаковый ли объём работ заложен в стоимость. Исследование, привлечение участников тестирования, лицензии, сопровождение реализации и последующие улучшения нужно обозначить отдельно, если они не входят в предложенную оценку.
Какие ошибки осложняют работу над продуктом
Начало дизайна без согласованной задачи. Когда команда не определила проблему и ожидаемое изменение, обсуждение может свестись к внешнему виду экранов. Поэтому перед проектированием нужно договориться, для кого создаётся решение, какую задачу оно помогает выполнить и по каким признакам его будут оценивать.
Проверка только основного сценария. Повторный заказ может работать, пока доступны все товары и не требуется дополнительное согласование, но затруднения появятся при первом отклонении от этих условий. Чтобы учесть такие ситуации, альтернативные действия, ограничения и ошибки включают в состав проектирования и проверок вместе с основным путём.
Позднее подключение разработчиков. Если техническая команда знакомится с решением после утверждения макетов, ограничения интеграций или структуры данных могут потребовать пересмотра дизайна. Их обсуждение на этапе проектирования позволяет уточнить поведение интерфейса до детальной проработки экранов.
Приёмка без критериев. Формулировка «удобный современный кабинет» не объясняет, что именно предстоит проверить. Критерии должны описывать согласованные сценарии, материалы и условия выполнения действий, чтобы заказчик и команда могли одинаково оценить результат.
Отсутствие проверки после запуска. Если заранее не определить, какие данные понадобятся для оценки продукта, к моменту анализа их может не оказаться. Поэтому ещё до реализации стоит выбрать события и обращения для наблюдения, назначить ответственного за анализ и договориться, как будут приниматься решения о следующих изменениях.
Перед началом проекта согласуйте задачу, приоритетные сценарии, результаты этапов и критерии приёмки, а также порядок оформления изменений. Эти договорённости помогут связать исследование, дизайн и разработку так, чтобы каждый следующий этап опирался на понятный и проверенный результат предыдущего.
Если вы планируете запуск или обновление цифрового продукта, расскажите нам о задаче. Обсудим исходные материалы, ограничения и ожидаемый результат, чтобы предложить подходящий состав работ и определить, с чего начать.