Про расстановку приоритетов в результатах UX-исследования
Заметка о том, как мы на проекте сортировали результаты интервью так, чтобы расставить приоритеты и упростить себе работу. Написано в 2021.
Про то, что так просто взять один из методов приоритизации не вышло, и мы изобретали велосипед.
Итак, на проекте мы собрали в кучу требования и начали сортировать их.
Зачем нужна сортировка? Затем, что не все собранные требования стоит внедрять тут же, некоторые стоит обсудить с командой до показа заказчику и так далее. Кроме того, из анализа интервью вы можете выйти не только со списком требований, но и со списком вопросов, которые нужно обсудить с клиентом ещё раз.
Есть множество разных подходов к решению задачи о сортировке требований. Вот пара ссылок по данной теме:
• 5 техник определения приоритетов для IT команд
• 20 Техник Приоритизации в Продукте: Карта и Руководство
В UX самая популярная тема, как мне кажется, это User Story Mapping от Джеффа Паттона: строите путь пользователя по оси х, а ниже под каждым этапом клеите стикеры с идеями для реализации. Затем стикеры сортируются по приоритетности — что внедряем по данному шагу сразу, что потом, а что, пожалуй, надо просто отметить как рассматривавшуюся идею и забыть.
Все просто? Да ни разу! Дело в том, что нельзя просто взять один из инструментов и работать с ним — например, User Story Mapping подходит в первую очередь для продуктов с пользовательским путем (у нас такого нет), а модель Кано фокусируется на удовлетворенности, что удобно когда вам нужно порадовать пользователя своим продуктом (у нас такой задачи тоже нет).
Т.е. нельзя взять инструмент и работать с ним, как нельзя запихать ногу 42 размера в ботинок 37.
Поэтому мы искали и прошли на этом пути две итерации.
Наша первая сортировка была придумана моей коллегой. Сортировали вот на такие группы:
• insight — инсайты (нет, я не могу точно сказать что тут)
• opportunity — возможности (и тут тоже не понятно о чем речь)
Она не сработала: разница между проблемой интерфейса, возможностями улучшения и «инсайтом» практически незаметна. Поэтому одна и та же задача могла одновременно быть инсайтом, ишьей и возможностью. Единственное, что мы получили — четкий список плюсов интерфейса.
Плюсы — это важно, ведь перед нами стояла задача доказать, что наш продукт нужен. Но даже если нет такой задачи важно отмечать то, что пользователь ценит, чтобы точно знать, какие элементы продукта важнее других.
Но что делать с остальными артефактами? Я подумала и предложила новый вариант сортировки:
• must do — делаем в первый релиз
• next steps — делаем во второй-третий релиз
• maybe — делаем только если у нас есть под это время
• advantages — преимущества, которые мы сохраняем
• to discuss — идеи и вопросы для обсуждения
• another — прочее — сюда пошли заметки и комментарии по UX, которые были просто напоминалками о некоторых моментах работы, и все, что просто не хочется удалять из списка находок.
Эта сортировка для нас сработала. Сработает ли она на другом проекте? Вполне может и нет, поэтому для себя я построила следующую инструкцию:
- описать хаотично «теги» для списка — что-то идёт в «обсудить», что-то в «первый релиз», а что-то можно отметить как «интересная идея».
- очевидно, что «обсудить», «первый релиз» и «интересная идея» — это как «кислое», «зеленое» и «вкусно пахнет» в одном ряду. Поэтому если теги бьются на группы — делаем это: «обсудить с заказчиком», «обсудить с командой», «обсудить с Джо»; «первый релиз», «второй релиз», «забудьте об этой задаче»; «преимущество», «недостаток», «нейтральный функционал».
- смотрим нет ли похожих на нужный нам принцип инструментов сортировки — например, User Story Mapping, чтобы дополнить теги, если необходимо.
- под каждую группу тегов — своя колонка.
Один и тот же список сортируем двумя-тремя подходами: одна колонка под одну оценку, другая — под другую, например в одной тип артефакта, а в другой — время, в которое вы к нему планируете обратиться. Тогда можно и сразу посмотреть весь список критических задач — на первый релиз, вопросов для обсуждения — на второй релиз и т.д.