Гайд по дизайну продукта

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

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

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

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

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

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

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

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

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

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

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

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

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