Как продакт-менеджеры описывают свои проблемы vs что они имеют в виду на самом деле. Продолжение

В студии вторая часть перевода статьи Ричарда Бэнфилда из InVision про самые распространенные проблемы в продукте глазами продакт-менеджеров. Первую часть перевода можно прочитать здесь.

«Наша продуктовая линейка стала громоздкой и нелогичной в плане UX/UI. Нам нужна дизайн-система которую наша команда разработчиков сможет легко внедрить»

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

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

Возможные пути решения

1. В этом случае идеальное решение — универсальная дизайн-система, которой руководствуются все члены команды независимо от роли, когда они решают что нужно включить или исключить в создании новых элементов. Создание и проектирование дизайна повторно используемых UX/UI-элементов требует немного больше предварительной работы, но намного увеличивает скорость и эффективность работы в дальнейшем.
2. Переход на любой новомодный фронтенд-фреймворк может помешать универсальной дизайн-системе. Это спорная тема, но не следует позволять разработчикам выбирать фреймворк до определения и проверки UX-решения. Все мы знаем, как трудно иногда бывает переходить с одного фреймворка на другой. Выберите правильный инструмент для работы. Не выбирайте инструмент, пока не знаете, для каких задач он нужен. Взгляните, как Titleist использует кодифицированный стилистический гайд по для того, чтобы создавать больше эффективных страниц и экономить время.

«Наш продукт вырос и мы добавили в него больше фичей и элементов. Он стал беспорядочным сборищем разрозненных элементов, как Франкенштейн»

Возможно, имеется в виду: «Нам нужна ревизия от человека с незамыленным взглядом на продукт. Затем порекомендуйте нам изменения в UX, сначала с точки зрения лучших и проверенных практик, а потом после детального изучения нашей отрасли/пользователей».

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

Другой вопрос из той же оперы: «Нам не нужен полный пересмотр, а только небольшая помощь с масштабированием ключевых областей с наибольшей отдачей. С чего начать?» На последний вопрос невозможно ответить без контекста. Лучше всего начинать с места, которое приносит клиентам больше всего боли.

Возможные пути решения

1. Иногда сложно увидеть лес за деревьями, когда вы очень долго работаете над продуктом.
2. Как и следовало ожидать, параллельная реализация нескольких подходов может быть лучшим способом достичь самых поверхностных результатов, одновременно покоряя вершины более серьезных возможностей. Это можно сделать с помощью составления карты лучших UX-практик и качественного исследования пользователей, чтобы сопоставить их и увидеть пересекающиеся слабые места. К примеру, если боль клиента связана с онбордингом, можно внедрить сразу несколько гипотез, которые немедленно улучшат user flow. Команда дизайна Metalab использовала лучшие практики игровой индустрии для Slack, чтобы моментально доносить ценность для клиента и отделять Slack от конкурентов.

«Мы знаем, что у наших пользователей/клиентов есть проблемы с [место для любой распространенной ситуации], но не знаем, как четко определить боль и найти решение для ее устранения»

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

В такие проблемы попадают все новаторские продукты в существующих индустриях. Это может быть уже существующая компания с новым видением или стартап с потенциально прорывными идеями, пути решения проблем будут похожими.

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

Возможные пути решения

1. Мозговой штурм — это практика, которая используется в начале дизайн-спринтов, но может использоваться отдельно для снижения рисков. Смысл в том, чтобы определить, что в проекте можно отнести к фактам, а что к гипотезам. Затем можно будет предположить, какая из гипотез может оказаться рискованной для проекта. Другими словами, если хорошенько в этом не разобраться, можно влипнуть в неприятности.
2. Как только вы устанете придумывать гипотезы (вы никогда не сможете перечислить их все), нужно выбрать одну или две для запуска и тестирования. Это значит переход к действиям. Вам предстоит вывести эти гипотезы на бой и и изучить их. Они действительно такие рискованные, как вам казалось? Расширяют ли эти гипотезы ваши перспективы или наоборот, порождают еще больше вопросов? Исследование может быть качественным, количественным или комбинированным. Смысл в том, чтобы подтвердить гипотезу или понять, что пошло не так, чтобы это не сбивало вас с толку в дальнейшем.
3. Создать прототип и показать его потенциальным пользователям — лучший способ проверить гипотезу. Они не обязательно должны быть полностью завершенными, но этого должно быть достаточно для того, чтобы получить инсайты от пользователей.

«Мы хотим сместить фокус компании с технологий на пользовательский опыт»

Возможно, имеется в виду: «Мне нужна помощь, чтобы обучить команду и сделать компанию клиентоориентированной. Я знаю, что это важно, но очень сложно понять, с чего начать. Как инициировать изменения в компании в сторону фокуса на UX/UI?».

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

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

Когда руководители компании определилась с видением продукта и продуктовой стратегией (подробнее об этом здесь и здесь), тимлиды должны поддержать это с помощью возможностей и ресурсов на уровне компании. Причина в том, что руководство компании может быть недостаточно близко к клиентам.

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