. Нам следует понять как пользователи относятся к удаляемому функционалу. Наше личное мнение не имеет значения. Мы должны сверить с коллегами все наши предположения о том как изменения будут интерпретированы пользователями. Эта же информация нам понадобится для создания правильной коммуникации этих решений ().

. Особенно осторожно нам следует подходить к удалению элементов являющихся частью какого-либо процесса (workflow).

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

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

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

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

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

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

. Работая с консервативными пользователями нам следует держать количество изменений на минимуме.

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

. Если мы удаляем компонент который активно использовался в наших маркетинг материалах, либо post-purchase материалах, у пользователей может появиться чувство, что их обманули.

. В некоторых случаях пользователи могут возмущаться изменениями даже не понимая их смысла. Это особенно актуально в среде B2B, где часто пользователю может быть удобно скрыть свою некомпетентность перед руководством, ссылаясь на «возмутительные изменения» в продукте.