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

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

Продуктовый дизайн и веб-дизайн: сходства и различия

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

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

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

Пример: компания-заказчик хочет увеличить повторные заказы дилеров. Веб-дизайнер изучает навигацию в личном кабинете и предлагает добавить фичу: кнопку «Повторить заказ». Продуктовый дизайнер предлагает сначала выяснить, что мешает покупке: неактуальные остатки, непонятные цены или отсутствие опции для быстрого заказа; затем внести изменения и проверить, увеличилось ли число повторных заявок. Если метрика не растет, он перейдет к тестированию новой гипотезы, и так пока проблема не решится.

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

На что уходят деньги в бюджете продуктового дизайна

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

Цена растет нелинейно. Влияют на нее те факторы, которые определяют сложность продукта:

• число ролей и сегментов пользователей;

• число критичных сценариев;

• количество гипотез на проверку;

• требования к консистентности на нескольких платформах.

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

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

Исследования: этап, который избавит от дорогих доработок в будущем

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

За что платим до первого макета

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

Пример из нашей практики — ГИС «Энергоэффективность» (цифровая система учета выбросов CO₂) продуктовая разработка госсервиса с большой подготовительной аналитической работой. До её запуска организации заполняли отчеты вручную, а нам после проведенной аналитики удалось создать удобные онлайн-формы и учесть при этом все действующие нормы законодательства.

Контекст, который рождается из практики

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

Яркий пример — приложение «Плавсостав», которое мы в Uplab делали для Русской рыбопромышленной компании. Его аудитория — экипаж судна в рейсе: до 100 человек на борту и более 40 специальностей, от капитанов до поваров. Контекст использования определил архитектуру продукта:

• связь в море нестабильна, поэтому приложение синхронизируется с CMS по расписанию и продолжает работать офлайн;

• информацию смотрят на мониторе или ТВ-экране, а не на личном смартфоне, поэтому данные подаются анимированными слайдами;

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

Бенчмарки и аудит: дешевая часть исследований

Бенчмаркинг и аудит текущего продукта обходятся дешевле полевых исследований и быстро дают список проблем. Как это делаем мы, описано в статье «Проводим бенчмаркинг».

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

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

Почему в смету входят варианты, которые не попадут в продукт

Генерация и отбор гипотез — это закупка вариантов. Часть из них отбросят после тестов, и оплаченные отброшенные варианты входят в цену решения, а не в потери. Продакт-менеджеру эта логика знакома по A/B-тестам: проигравшая ветка тоже стоила денег.

Как отбор работает на критически важном сценарии, видно по проекту для «Авиакода». Мы проектировали интерфейс киосков самообслуживания для регистрации на рейс и сдачи багажа. По исходным данным, регистрация занимала около четырех минут на пассажира, а очередь в час пик доходила до 40 минут. Целевую метрику заказчик сформулировал жестко: вся процедура регистрации и сдачи багажа должна занимать меньше одной минуты.

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

Дизайн-система. Выгодна, но окупается не сразу

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

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

Экономику дизайн-системы мы подробно разбирали в статье «Одинаковое, но разное»: как устроен и как работает атомарный дизайн.

Выгода от внедрения дизайн-системы особенно видна в мультиплатформенных продуктах, например, в сервисе GAZ Connect для управления автопарком, который мы в Uplab разработали для «Группы ГАЗ». Этот продукт работает на смартфонах, планшетах и в вебе: пользователь следит за местоположением машины с телефона, а статистику автопарка смотрит в браузере. Без единой системы компонентов интерфейсы разных версий стали бы различаться уже после нескольких обновлений, и пользователи испытывали бы неудобство при переходе из одной версии в другую.

Вывод: как читать смету продуктового дизайна

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