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