Цикл разработки продуктового дизайна

Цикл разработки продуктового дизайна

Переход от точки А к точке В иногда бывает сложным, важно не сбиться с нужного направления. Но когда точка A является проблемой пользователя, а точка B — реализованная функция, это похоже на навигацию в открытом море со старой картой и неисправным компасом. Справится с этим поможет правильно выстроенный цикл разработки продуктового дизайна.

1. Понимание проблемы

Понимание проблемы

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

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

2. Изучение проблемы и сбор данных

После определения проблемной точки настало время получить как можно больше информации.

Как другие люди справляются с этой проблемой? Это широко распространенная проблема или проблема ниши? Есть ли способ разбить эту проблему на более мелкие проблемы? И, самое главное, собирать данные по ней.

Даже если мы говорим о совершенно новой функции и / или продукт все еще должен быть разработан, есть методики, которые применимы к нему, которые могут быть использованы. Если это улучшение существующей функции, нужно будет проще использовать данные из аналитики или любые показатели, которые должны были быть реализованы, также можно прибегнуть к A/B тестированию.

3. Переосмыслите проблему

Переосмыслите проблему

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

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

Это новое определение проблемы открывает новые пути к решению.

4. Разработайте решение

Разработайте решение

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

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

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

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

5. Протестируйте решение

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

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

6. Реализуйте решение

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

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

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

7. Отслеживайте успешность решения

При реализации решения предусмотрите каналы оценки его будущей успешности.

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

8. Проверьте решена ли проблема

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

 
Источник

Похожие темы