Цикл разработки продуктового дизайна
Переход от точки А к точке В иногда бывает сложным, важно не сбиться с нужного направления. Но когда точка A является проблемой пользователя, а точка B — реализованная функция, это похоже на навигацию в открытом море со старой картой и неисправным компасом. Справится с этим поможет правильно выстроенный цикл разработки продуктового дизайна.
1. Понимание проблемы
Необходимо понять, как сформировался запрос? Было ли это пожелание пользователей или идея генерального директора? А также где находится конкретная проблема, является ли она частью взаимодействия с продуктом и на каком этапе. Отказ от фактической проблемы, вызвавшей запрос к внесению изменений, часто может привести к работе в неверном направлении.
Возвращаясь к начальной точке проблемы, причине, которая вызвала ее, означает, что исходной точкой дизайна является именно фактическая проблема, а не одно из возможных решений.
2. Изучение проблемы и сбор данных
После определения проблемной точки настало время получить как можно больше информации.
Как другие люди справляются с этой проблемой? Это широко распространенная проблема или проблема ниши? Есть ли способ разбить эту проблему на более мелкие проблемы? И, самое главное, собирать данные по ней.
Даже если мы говорим о совершенно новой функции и / или продукт все еще должен быть разработан, есть методики, которые применимы к нему, которые могут быть использованы. Если это улучшение существующей функции, нужно будет проще использовать данные из аналитики или любые показатели, которые должны были быть реализованы, также можно прибегнуть к A/B тестированию.
3. Переосмыслите проблему
Со всей собранной информацией к настоящему времени должно быть легко получить более полную картину проблемы и ее контекста. Переосмысление проблемы означает рассмотрение ее с других сторон и позиций, тем самым избавляя ее от любых предшествующих предвзятостей или интерпретаций, которые могли появиться при сборе информации о ней.
Таким образом, первоначальный запрос мог быть: «Нам нужна функция, которая позволяет переводить деньги пользователю при низком балансе» (такой запрос уже содержит решение), а реальная проблема могла быть иной, например: «перевод денег требует много времени и постоянной проверки баланса от пользователя».
Это новое определение проблемы открывает новые пути к решению.
4. Разработайте решение
Теперь проблема идентифицирована и доступны данные, чтобы включить ее в более широкий контекст продукта. Настало время выбрать решение.
Для этого может быть полезно сформировать решения в форме вопросов, о том какие функции приводят к решению. Например: «должен ли пользователь установить автоматическое напоминание?» «Должен ли пользователь иметь возможность импортировать события?» — и создать список возможных подходов к решению. Цель состоит в том, чтобы сузить варианты и сформировать предположение, которое будет проверено прототипом.
Поскольку целью является тестирование предположения, прототип в идеале был бы ориентированным на предположение, изолированное от всех ненужных деталей, которые могли бы отвлечь пользователя при тестировании.
На этом этапе также идеально пообщаться с разработчиками и с кем-либо еще, кто будет участвовать в этом процессе, чтобы собрать свои идеи по решению с их точки зрения.
5. Протестируйте решение
В зависимости от имеющихся ресурсов и времени, тестирование пользователями всегда является сложным и необходимым.
Даже при малых ресурсах и ограниченном времени, тестирование, которое будет являться представителем большей пользовательской базы продукта, чрезвычайно важно. Также необходимо проводить интервью с пользователями и учитывать их эмоции, чтобы достичь более качественного UX.
6. Реализуйте решение
Итак, работает ли решение? Если да, то каковы его более сильные и слабые стороны? Если тестирование прошло успешно, прототип должен быть превращен в реальные экраны и требования к разработчикам. Для того, чтобы избежать дальнейшего возникновения проблем, определение ключевых индикаторов эффективности и показателей успеха является обязательной задачей, которая может потребовать помощи от других членов команды (специалистов по маркетингу и разработчиков).
Если тестирование предложного решения не показало его эффективность, цикл разработки продуктового дизайна запускается заново.
При разработке комплексного решения — одна из возможных стратегий может начинаться с реализации простейшей версии и ее постепенного усложнения.
7. Отслеживайте успешность решения
При реализации решения предусмотрите каналы оценки его будущей успешности.
Оповестите пользователей о введении новой функции и снабдите их инструкцией по взаимодействию, а также организуйте возможносте по сбору отзывов и работе с клиентами, чтобы получить более обширное представление о ситуации.
8. Проверьте решена ли проблема
Оценивайте работу функции и впечатления по взаимодействию с ней по временным срезам. В зависимости от ее сложности это могут быть недели или месяцы. Смотрите на сколько она решает поставленную проблему. Если все успешно, то цикл разработки продуктового дизайна, на этом заканчивается, и открывается возможность поиска новых проблем пользователей и их устранения, и тем самым ваше приложения улучшается.