[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "create", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-158433683", "adfox_url": "//ads.adfox.ru/228129/getCode?p1=bxbwd&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid21=&puid22=&puid31=&fmt=1&pr=" } } ]
{ "author_name": "Alexander Lashkov", "author_type": "self", "tags": ["\u0441\u0442\u0430\u0440\u0442\u0430\u043f\u044b","\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0438","\u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f_\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439","\u043f\u0440\u0438\u043e\u0440\u0438\u0442\u0435\u0442_\u0437\u0430\u0434\u0430\u0447"], "comments": 17, "likes": 14, "favorites": 0, "is_advertisement": false, "section_name": "default", "id": "5001" }
Alexander Lashkov
5 585

Как работать только над важными требованиями пользователей: 7 методов приоритезации

UX-эксперт и основатель компании Measuring Usability Джефф Сауро в своем блоге опубликовал материал, в котором перечислил семь способов определения приоритета требований, выдвигаемых пользователями.

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

Определение главных задач пользователей продукта

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

Джефф Сауро

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

Подробнее данная техника описана в книге 'Customer Analytics For Dummies'.

Анализ важности и удовлетворенности

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

Данная схема работает следующим образом: в ходе теста пользователям дается список ранее отобранных требований по нововведениям, а затем их просят по семибальной шкале проранжировать данные задачи по степени важности и удовлетворения, которое принесет реализация этих функций. Затем используется формула: «важность» + («важность» - «удовлетворенность»). С её помощью можно определить наиболее перспективные для реализации нововведения в проекте.

Более подробно тема анализа важности и удовлетворенности пользователей раскрыта в другой статье Джеффа Сауро.

Выявление wow-функций

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

Для проведения моделирования необходимо наличие репрезентативной выборки пользователей, которые должны рассказывать о своем эмоциональном состоянии, когда они видят какую-то функцию в продукте, и когда она в нем отсутствует. С помощью этого метода можно определить функции, без которых пользователи смогут прожить и очень важные для них. Также моделирование по методу Кано позволит выяснить, какие нововведения очень понравились бы клиентам — сегодня примером такой функции является в Wi-Fi в самолетах, а в 1980-х это были подстаканники в автомобилях.

Более подробно о модели Кано рассказывается в материалах UX Magazine и Userfocus.

Сопоставление желаний клиента и компании

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

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

Джефф Сауро публиковал в блоге отдельный материал, посвященный методу QFD.

Анализ по методу Парето: выявление важных и легко реализуемых функций

Знаменитый закон Парето («20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата») используется для выделения наиболее перспективных задач. С помощью этой техники решения принимаются на основе сортировки задач согласно различным признакам.

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

Подробнее о законе Парето.

Причинно-следственные диаграммы: определение причин основных проблем

Причинно-следственные диаграммы (диаграммы Исикавы или «диаграмма рыбьей кости») помогают определить возможные причины возникновения тех или иных проблем. При разработке продуктов, как правило, у каждой проблемы не одна причина, говорит Сауро. Метом диаграмм Исикавы позволяет определять наиболее существенные связи между различными элементами системы.

Метод работает по следующей схеме: сначала выписываются проблемы, которых необходимо избежать. Затем определяются возможные причины таких проблем («пользователям нужно регистрироваться для совершения покупки», «цена слишком высока», «отсутствует реклама»), эти причины группируются по определенным критериям, а затем с помощью вопроса «почему?» ищется корень проблемы («почему на странице с описанием продукта маленькая посещаемость»).

Подробнее о диаграммах Исикавы.

Определение частоты, масштабов и влияния возникающих проблем

Анализ видов и последствий отказов (Failure Mode and Effects Analysis, FMEA) помогает разработчикам понять, каков негативный эффект тех или иных действий. С помощью данного метода можно выяснить, в каких случаях эффективнее исправлять существующие баги, чем добавлять новую функциональность в продукт.

В ходе проведения анализа выписываются все возможные проблемы, а затем каждой присваивается максимальный уровень опасности. Кроме того, разработчики выясняют, как часто возникают подобные проблемы и какое число пользователей они затрагивают. Также учитывается сложность обнаружения проблемы. В конечном итоге подсчитывается коэффициент приоритета риска (Risk Priority Number), который зависит от частоты, масштабов и сложности выявления проблемы.

Подробнее об FMEA.

#стартапы #пользователи #требования_пользователей #приоритет_задач

Статьи по теме
Как выбрать приоритет в расстановке задач между «срочным» и «важным»
Плохая выгода: что делать бизнесу, когда платящие клиенты недовольны продуктом
На какие вопросы нужно ответить перед началом юзабилити-тестирования
Популярные материалы
Показать еще
{ "is_needs_advanced_access": false }

Комментарии Комм.

0 новых

Популярные

По порядку

Прямой эфир

Приложение-плацебо скачали
больше миллиона раз
Подписаться на push-уведомления