Как устроена работа продуктового дизайнера. Гайд для создания лучшего решения

Зачем нужны продуктовые дизайнеры и в чем их ценность — в колонке Никиты Денисенко, тимлида дизайн-студии Ростелекома.

«На небе только и разговоров, что о море...».

Равно так же ИТ-сообщество в России продолжает обсуждать, кто же такой этот продуктовый дизайнер и какова его роль в продукте. Ряд компаний просто использует модный термин для развития своего бренда работодателя, другие подразумевают под этим просто UI-дизайнера. И лишь единицы понимают ценность этого специалиста и истинный смысл его работы. Давайте вместе разберемся, кто же такой этот продуктовый дизайнер и как он работает.

Поле действия дизайнера цифровых интерфейсов со времени появления этой профессии в нашей стране постоянно расширяется.

Веб-дизайнер занимался отрисовкой сайтиков в фотошопе.

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

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

UX/UI, UI/UX и прочие комбинации по сути являются мультистаночниками, но с определенным уклоном — приоритетное направление ставится до /.

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

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

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

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

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

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

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

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

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

Итак, вот из каких этапов состоит работа.

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

Макеты должны в нужное время оказаться у разработки для реализации запланированных бизнесом функций продукта. Дизайнеру нужно понимать объем и сложность задач по дизайну заранее, чтобы рассчитать емкость и ресурсы для реализации в необходимые сроки (как самого дизайнера, так и команды при её наличии).

Естественно, это будет приближенное планирование, которое надо уточнять в ходе проекта и после завершения спринта.

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

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

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

Вайрфреймы (от англ. wireframe — каркас) экономят ресурсы: дизайнер может сразу обсудить реализацию сценариев с аналитиками, бизнесом и разработчиками, не тратя времени на отрисовку красивого UI. Есть и второй плюс — при согласовании никто не будет обсуждать цвет кнопок, все будут сконцентрированы именно на спроектированной логике продукта. На этом этапе структура интерфейса и последовательность экранов могут несколько раз кардинально измениться.

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

После утверждения с командой вайрфреймов дизайнер приступает к поиску визуального решения, подготовке референсов (если не сделал этого на этапе конкурентного анализа) и концептов. Для проверки выбранного визуального стиля используется плэйбук — сильно отличающиеся вайрфреймы, на которые накатывается UI. При согласовании визуальной концепции дизайнер начинает отрисовывать подробные макеты по сценариям, на основе которых разработка сможет верстать интерфейс, а сам дизайнер — собрать прототип для UX-тестирования. Из-за высокой детализации макеты рисуются гораздо дольше вайрфреймов, поэтому внесение изменений на этом этапе требует гораздо больше времени и денег.
Рекомендуется при наличии свободных (ха-ха) рук запустить процесс поиска визуального стиля параллельно с проектированием вайров.

Внесение изменений в макеты всё же дешевле, чем повторная верстка в коде, поэтому рекомендуем тестировать на кликабельных прототипах качество проектирования интерфейса. Для этого дизайнер может использовать список составленных ранее гипотез и отрисованные макеты. Также понадобится фокус-группа пользователей. По результатам UX-исследования можно внести корректировки в макеты и передать их разработке.
Важно понимать, что при составлении сценариев для тестирования пользователем нельзя указывать шаги с конкретными UI-элементами. То есть «нажмите на кнопку "создать"...» — неправильно. «Создайте...» — правильно. Пользователь должен самостоятельно найти решение в интерфейсе, а не выполнять задачу по поиску геометрических фигур.

Основной артефакт дизайна — макеты. Они должны быть подробно описаны и основаны на задокументированных пользовательских сценариях и утвержденных вайрфреймах. Без консолидации этой информации в едином центре будет сложно вести историю изменений продукта и принятых решений. Также на этом этапе формируется бэклог по дизайну — элементы или сценарии, которые потенциально будут полезны в продукте, но команда пока решила не реализовывать их.
Переданные в разработку макеты нужно согласовать с командой. Очень неприятно потом будет переправлять большую функциональность (да еще и в коде), потому что оунер не видел макеты и иначе представлял себе реализацию.
И не забывайте про UI Kit, если у вас нет дизайн-системы, на которую вы опираетесь. Очень часто UI Kit в итоге перерастает в огромный комплексный гайдлайн (если не в целую дизайн-систему), созданный на вопросах от разработки.

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

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

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

Подготовили:
Иван Манжулов (ТГ: @john_smthn) и Никита Денисенко (ТГ: @nikdenisenko)
Тимлиды направления профинтерфейсов центра компетенций UX/UI Ростелеком ИТ