, . Если мы не уверены понравится ли функционал пользователям или нет, тогда нам следует поместить его в неявное место. Идея в следующем: если мы поместим функционал на видное место, а позже окажется, что большинству пользователей он не нужен – его будет гораздо сложнее убрать, не вызвав негативной реакции пользователей.

. Функционал должен гармонично вписываться в контекст как продукта, так и той страницы, куда мы его помещаем.

. То, как мы презентуем новый функционал задает тон для будущих апдейтов. Чем высокопарнее мы перзентуем функционал, тем более высокая планка ожиданий формируется у пользователей ().

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

. Если новый функционал затрагивает устоявшиеся процессы продукта (workflows), нам желательно сделать его использование опциональным, давая пользователям возможность использовать все так, как было до релиза.

. Нам следует максимально понятно объяснить все преимущества нового функционала, даже если нам кажется, что все совершенно очевидно.

. Мы можем сильно переоценить наши способности по запуску функционала в оговоренные сроки.

. Если запуск нового функционала сильно изменяет продукт, не давая возможности пользователям отказаться от обновления – это может вызвать резко негативную реакцию пользователей.

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

. Если беспокоясь за запуск функционала мы все время ищем дополнительную информацию, нам следует заранее определить как именно эта информация повлияет на наше решение. Иными словами, нам следует определить критерии по которым информация окажется полезной.