Какие риски несут большие изменения в идеологии или функциональности продукта?

Какие риски несут большие изменения в идеологии или функциональности продукта?

Возможные ответы (11)

. Изменения в популярных процессах (workflows) продукта могут вызвать резко-негативную реакцию. Чтобы этого избежать, нам следует заранее подготавливать пользователей к изменениям. Так, чтобы это не стало для них неожиданностью ().
. Если наши конкуренты в момент наших масштабных изменений запустят рекламные кампании с «мгновенными бонусами» - мы рискуем потерять часть наших пользователей. Это одна из причин по которой не следует где попало говорить о датах ключевых релизов.
. Нам не следует объяснять изменения в продукте одним лишь фактом новизны функционала, либо используемых методов. Всегда будут те, кто посчитает этот аргумент недостаточным для крупных изменений.
. Чтобы свести пользовательский дискомфорт к минимуму, мы можем раздробить наши изменения на части, и публиковать их постепенно, позволяя пользователям привыкнуть к новому контексту.
. Если изменения касаются идеологических концепций либо терминологии используемой в продукте, нам следует сверить их с верованиями и убеждениями нашей аудитории. Простейший пример: если группа разработчиков open source software начнет продавать лицензии на использование своего ПО, это пойдет вразрез с ценностями их аудитории.
. Пользователи могут захотеть увидеть разницу в виде «до» изменений и «после». Если мы считаем подобный запрос уместным, тогда мы можем показать готовящиеся изменения в виде таблицы «до» - «после». Если же мы считаем, что подобное сравнение не пойдет нам на пользу, тогда мы можем показать изменения частями, сознательно создав неудобство для сравнивания.
. Мы можем опубликовать несколько статей связанных с грядущими изменениями с целью анализа реакции нашей аудитории. По реакции мы поймем что больше всего беспокоит пользователей. Следующим шагом мы разработаем механизмы смягчения негативной реакции.
. Нам следует создать простые инструкции по использованию нового функционала. Мы должны упростить интерфейс настолько, насколько это возможно. Если специфика продукта позволяет, мы можем создать два типа визуальной репрезентации функционала (типа Standard view и Advanced view). Это может быть временным решением, пока пользователи не привкнут к основным концептам.
. Даже те компоненты продукта, которые пользователи используют очень редко, они считают своей «собственностью». Необоснованные изменения этих компонентов могут спровоцировать резкую реакцию, которая может нам показаться не пропорциональной популярности компонента ().
. На интуитивном уровне мы все понимаем риски крупных изменений. Обычно, если мы на них все же решаемся, будущее продукта сводится к игре с нулевой суммой, где мы либо получаем все, либо ничего. В таких случаях особенно важно сверять любые предположения и гипотезы с коллегами по команде.
Наши предположения могут быть искажены из-за непонимания «мира» нашей аудитории (, ), нашего высокомерия (, ), либо нашей слепой веры, типа «Нашими стараниями мы заслужили успех!» ().

Связанные вопросы

Насколько полезным вы нашли этот материал?
Не полезно
1
2
3
4
5
6
7
8
9
10
Не полезно
Очень полезно
Спасибо за ваш вклад в развитие проекта!
previous bias
next bias
keepsimple logo
picВойти
Мой профильНастройкиВыйти

UX CORE GUIDE

arrow downКак пользоваться

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

Как использовать UXCG

  1. Выберите стадию вашего продукта ниже;
  2. Выберите интересующий вас вопрос;
  3. Прочтите возможные ответы.

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

Описание лейблов
Вопросы связанные с кооперацией команд и лиц, работающих над продуктом.
Вопросы связанные со стадией разработки продукта (от идеи до публичного релиза).
Вопросы связанные с продажами, маркетингом, потенциальными пользователями и общей оберткой продукта.
Вопросы связанные с интеракцией пользователей с продуктом и его функционалом.
Вопросы связанные с чтением аналитики по продукту.
search icon
Выберите стадию вашего проекта
#10.

Почему пользователи жалуются на качество нашей поддержки?

#30.

Какие ошибки мы допускаем в работе с аналитическими данными по продукту?

#41.

Что делать если упрямство наших коллег наносит вред рабочему процессу?

#43.

Что учитывать при планировании релизов продукта?

#45.

Что делать если некоторые участники нашей команды не высказывают свое мнение?

#50.

Как работать с некомпетентным коллегой/начальником?

#59.

Что учитывать при упоминании политических, социальных либо экономических событий в текстах компании/продукта?

#61.

Что делать, если команда тратит слишком много времени на неважные мелочи?

Be Kind. Do Good.