Мы все привыкли к новым версиям сайтов, программ и приложений — зачастую они меняются быстрее, чем в них успевают разобраться пользователи. Я убеждён, что этот подход устарел и имеет множество недостатков.
1. Пользователям нужно привыкать к новой версии
Со временем пользователи вырабатывают свою модель взаимодействия с продуктом. У них возникает привычка.
Когда продукт резко меняется, эта схема рушится — возникает некий барьер, требуется время на изучение и перестройку.
Часть пользователей может просто отказаться от новой версии, часть будет думать: «Зачем это было сделано? Ради чего меняли?».
2. Изменения ради изменений
Когда затевают новую версию, в ней собирают некий пул улучшений и функций. Они могут быть на основе тестов, гипотез и обратной связи от пользователей. Но если её сделать похожей на старую, это не устроит инициатора процесса и пиарщика. Виной тому их завышенные ожидания. К тому же пользователям, вероятно, уже пообещали, что «всё будет круто».
И тогда в новую версию вносятся изменения ради того, чтобы она выглядела как новая: новый дизайн, ненужные функции и прочие «эффектные» фичи. Такой подход может привести к отрицательному результату — когда полезные новинки будут перекрыты изменениями ради изменений.
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
3. Понять эффективность практически невозможно
Как правило, в новой версии такое количество изменений, что понять эффективность отдельного крайне сложно. Даже если как таковые новые фичи или улучшения хороши, вместе с другими опциями они могут работать некорректно. Невозможно провести чистый сплит-тест, который покажет, почему новая версия лучше старой и, главное, что именно на это повлияло.
4. Неизбежные потери при переходе
При запуске новой версии потери есть всегда. Это может быть трафик, страницы в индексе, контент. Или долгое переключение DNS между версиями, потери куков пользователей и залогиненных состояний. Список можно продолжать бесконечно, предусмотреть размер этих потерь нельзя, их списывают по факту.
5. Текущие важные изменения откладывают до новой версии
Когда становится известно о том, что готовится новая версия, сложные и важные изменения разработчики с удовольствием откладывают до неё (читай: до лучших времён).
«Вот в новой версии мы всё и сделаем по уму» (на самом деле нет).
Если сроки новой версии переносятся, то и изменения откладываются вместе с ней. Из-за неготовности новой версии тормозится и сбивается весь процесс разработки. В таком нервозном режиме возникает серия никому не нужных авралов.
6. Подключаются любители освоить бюджет
Новая версия — любимое детище разного рода начинающих маркетологов и новых сотрудников, отвечающих за сайт. Они с удовольствием этим занимаются, а зачастую начинают работу в новой должности именно с изменения сайта. На это есть простая причина — возможность подключить серьёзный бюджет и освоить его. Вопросы эффективности таких любителей волнуют мало, важнее показать себя и сделать нечто выдающееся. Будет ли новая версия таковой, выяснится позже, когда бюджет потрачен, а назад дороги нет.
Также эту ситуацию любят IT-директоры. Самое время запросить обновление ПО, серверной инфраструктуры и добавить сотрудников. Ввиду сложности определения отдачи от таких мероприятий их обычно записывают в некие инвестиции на будущее. Стандартная и лукавая фраза: «закладываемся на рост».
7. Велик риск потерять что-то важное
В больших компаниях и проектах взаимодействие с пользователями складывается годами, иногда десятилетиями. Это тонкий и очень сложный механизм. Уже все забыли, почему какие-то вещи работают, просто работают — и всё. Во время запуска новой версии может оказаться, что что-то потеряно и работать перестало. Технически всё в порядке: кроссбраузерность, технологичность, дизайн — всё на высоте. Но показатели продуктивности не те. Найти, что именно пошло в ухудшение, а не улучшение, в данной ситуации очень сложно — всё смешалось.
8. Новая версия всегда запускается с недоработками
Ни один тест не позволит проверить продукт на наличие всех ошибок и глюков.
Это можно сделать только на реальной работе и нагрузке. То есть после запуска так или иначе пройдёт процесс зачистки от разных недоработок. Привычный режим работы компании сбивается, возникают непредвиденные задачи. К чему это приводит? К потерям.
И с этими потерями все будут мириться, ведь откатить версию назад — большой и негативный шаг, на него вряд ли кто-то решится.
9. Двойные затраты — создание новой версии, поддержка текущей
Во время создания новой версии идёт двойная работа: и текущую надо поддерживать, и заниматься новой. Это сложный и напряжённый режим для всей команды проекта, и длиться он может очень долго. Эти же усилия, направленные на улучшение текущей версии, могут дать значительно бо́льший результат. Я даже не говорю о рисках, связанных с неправильным проектированием новой версии, в результате которого она может оказаться просто неработоспособной. Опять же, правильная работа с текущей версией этого риска лишена.
А как же концепты?
Все мы видели концепты новых автомобилей. Они красивы и привлекательны, но в серию обычно идут только детали, фрагменты. Именно такова роль концептов — дать новую мысль, идею, проверить её жизнеспособность. Поэтому концепты нужны и важны, но не как прямое указание к действию.
А как же прототипы?
Прототип — самая правильная схема работы и управления изменениями, особенно когда он полный или UX-интерактивный. Я считаю, что прототип должен развиваться параллельно с любой версией продукта, и именно на нём нужно обкатывать и тестировать большие и малые изменения.
Пример проекта с постепенными изменениями
Самый яркий пример, который я всегда привожу, — сайт Booking.com. Он существует более 15 лет и меняется постоянно. Счёт изменений идёт на тысячи, но все они не сильно заметны пользователям. Можно зайти на сайт через несколько лет и не увидеть большой разницы.
Но если мы сравним версию 2007-го с 2017 годом, увидим, что они совсем разные.
При этом никаких новых версий компания не анонсировала. Это и есть концепция постепенных изменений в действии!
Итого
Вышеперечисленные минусы с лихвой покрывают все плюсы, которые есть у новой версии. Чего стоят релизы совершенно неузнаваемых версий без предупреждения, без опции открыть старую, исчезновение привычного пользователю функционала и прочие коллизии? Примеров на нашем веку не перечесть.
Да, есть ситуации, когда подход с новыми версиями оправдан: ребрендинг, коллапс текущей системы по производительности, объединение и так далее. Но и в этом случае призываю задуматься: не можем ли мы обойтись без глобальных обновлений и сделать всё постепенно?
Читать по теме: 5 причин, почему вам не стоит прототипировать
Мнение редакции может не совпадать с мнением автора. Если у вас есть, что дополнить — будем рады вашим комментариям. Если вы хотите написать статью с вашей точкой зрения — прочитайте правила публикации на Cossa.
Источник:
