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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
Источник

Другие наши материалы