Что учитывать планируя удаление функционала из продукта?
English
Armenian
Russian
Что учитывать планируя удаление функционала из продукта?
Копировать ссылкуСкопировано!
Поделиться
Возможные ответы (12)
. Нам следует понять как пользователи относятся к удаляемому функционалу. Наше личное мнение не имеет значения. Мы должны сверить с коллегами все наши предположения о том как изменения будут интерпретированы пользователями. Эта же информация нам понадобится для создания правильной коммуникации этих решений ().
. Особенно осторожно нам следует подходить к удалению элементов являющихся частью какого-либо процесса (workflow).
. Часто, огорчение пользователей будет непропорционально степени используемости удаленного функционала. Чтобы смягчить пользовательское негодование, мы можем в том же релизе, где удаляем функционал – что-то добавить.
. Даже если пользователь не притрагивался к какому-либо компоненту продукта, самого факта, что у него был к нему доступ достаточно, чтобы он считал этот компонент своей собственностью. Поэтому нам следует тщательно подбирать слова в объяснениях наших действий. Отсылка к статистике использования компонента может быть воспринята резко негативно. Если решение об удалении функционала было принято нами не обсудив это с пользователями, они могут назвать наши действия нечестными и несправедливыми (, ).
. Объясняя наше решение удалить какую-то часть продукта, мы можем апеллировать к стремлению полностью убрать какие-либо риски для пользователей.
. Если мы предполагаем резко негативную пользовательскую реакцию, мы можем за несколько месяцев до релиза публиковать материалы дискредитирующие тот компонент системы, который мы собираемся удалить. Идея в том, чтобы в день удаления функционала пользователи могли сослаться на какие-то «постоянно появляющиеся материалы» связанные с удаленным компонентом. Это позволит им легче рационализовать происшедшее. Этот прием активно используется в политике.
. Мы можем перенести компонент в ту часть продукта где он будет выпадать из контекста. Какое-то время спустя мы можем удалить компонент как «неудобный и раздражающих пользователей».
. Любой элемент продукта подпитывающий эго пользователя является особенно важным. Нам следует очень осторожно работать с компонентами продукта, в которых пользователи «видят себя». К примеру, нам может показаться, что приставка «Премиум» рядом с никнеймом пользователей лишняя, т.к. не несет никакой смысловой нагрузки. Однако если мы ее удалим, пользователи могут перестать продлевать подписку, либо начать массово уходить ничего нам при этом не говоря.
. Работая с консервативными пользователями нам следует держать количество изменений на минимуме.
. Иногда пользователям бывает сложно оценить последствия изменений. Особенно, если эти изменения затрагивают несколько разных компонентов продукта. Хорошей идеей может быть наглядный показ изменений на одном изображении в формате «До» и «После».
. Если мы удаляем компонент который активно использовался в наших маркетинг материалах, либо post-purchase материалах, у пользователей может появиться чувство, что их обманули.
. В некоторых случаях пользователи могут возмущаться изменениями даже не понимая их смысла. Это особенно актуально в среде B2B, где часто пользователю может быть удобно скрыть свою некомпетентность перед руководством, ссылаясь на «возмутительные изменения» в продукте.
Связанные вопросы
#46.
Как упростить наш продукт?
#55.
Какие компоненты продукта наиболее чувствительны к изменениям?
#8.
Почему пользователи остро реагириуют на изменения в продукте?
#17.
Почему пользователи не используют большинство функций нашего продукта?
#32.
Как сделать продукт максимально комфортным?
#54.
Что учитывать при добавлении нового функционала в продукт?
Насколько полезным вы нашли этот материал?
Не полезно
1
2
3
4
5
6
7
8
9
10
Не полезно
Очень полезно
Спасибо за ваш вклад в развитие проекта!
Ссылки
UX CORE GUIDE
Добавление вашего вопроса
UX CORE PERSONA
Вводная статья
UX CORE GUIDE
(UXCG - Находим решения ваших проблем)
Как пользоватьсяUXCG — это бесплатный инструмент, который помогает командам выявлять проблемы пользовательского опыта, связанные с когнитивными искажениями, на всех стадиях разработки продукта: от прототипирования и тестирования до улучшения действующего продукта.
Как использовать UXCG
- Выберите стадию вашего продукта ниже;
- Выберите интересующий вас вопрос;
- Прочтите возможные ответы.
Каждый ответ объясняет, как когнитивные искажения связаны с вашим вопросом. Поскольку вы лучше всего понимаете свой контекст, вы можете напрямую применять полученные знания. Хотя инструмент не предоставляет готовых решений из-за уникальности каждого случая, он открывает новые перспективы, подкрепленные наукой.
Описание лейблов
Вопросы связанные с кооперацией команд и лиц, работающих над продуктом.
Вопросы связанные со стадией разработки продукта (от идеи до публичного релиза).
Вопросы связанные с продажами, маркетингом, потенциальными пользователями и общей оберткой продукта.
Вопросы связанные с интеракцией пользователей с продуктом и его функционалом.
Вопросы связанные с чтением аналитики по продукту.
Выберите стадию вашего проекта
#10.
Почему пользователи жалуются на качество нашей поддержки?
#30.
Какие ошибки мы допускаем в работе с аналитическими данными по продукту?
#41.
Что делать если упрямство наших коллег наносит вред рабочему процессу?
#43.
Что учитывать при планировании релизов продукта?
#45.
Что делать если некоторые участники нашей команды не высказывают свое мнение?
#50.
Как работать с некомпетентным коллегой/начальником?
#59.
Что учитывать при упоминании политических, социальных либо экономических событий в текстах компании/продукта?
#61.
Что делать, если команда тратит слишком много времени на неважные мелочи?
Be Kind. Do Good.