“Любые изменения в продукте должны внедряться отталкиваясь от полученных в ходе тестирования данных”, — достаточно простая истина, которую знает любой продуктолог. Но работают ли тесты во всех случаях?
Большинство пользователей негативно воспринимают любые изменения, которые вы делаете с продуктом. Для них это выход из зоны комфорта, который естественно вызывает отторжение. Не верите? Вспомните свою реакцию на новый интерфейс Gmail или Facebook.
А теперь представьте, что вы решили проверить гипотезу, что новый улучшенный UX повысит конверсию. И решите проверить свою гипотезу через тест. Уже догадались, какой результат вы получите? На выходе вы будете в ужасе от того, насколько эпичны будут масштабы проигрыша нового варианта.
Внедренные изменения первое время раздражают пользователей, которые успели привыкнуть ко всем “костылям” внутри вашей системы. Поэтому важно уметь внедрять изменения в продукте плавно и давать пользователю время на адаптацию. Тестирование в подобных случаях — плохая идея.
Было
Стало
Как это было в TRIONIKA — ниже на примере клиентской админки.
У нас уже был неудачный опыт внедрения новой клиентской панели. В тот раз мы решили зайти через А/Б тест и потерпели фиаско. Сейчас кажется очевидным, что подобный эксперимент был обречен на провал. Тогда мы были в полном недоумении: выкатив вполне логичные удобные изменения для пользователей мы получили множество негативного фидбека. Тест проиграл по всем ключевым метрикам. Было принято решение незамедлительно вернуть все как было.
Вернулись мы к этому вопросу практически год спустя. Здравый смысл подсказывал, что кабинет требует изменений. В этот раз мы решили подойти основательно и пересмотреть всю архитектуру кабинета, чтобы найти оптимальное решение, которое понравится пользователю. Уже на этом этапе мы понимали, что повторный тест проводить не будем. Вместо теста мы решили подготовить пользователя к этим изменениям. Остановимся подробнее на том, как мы собственно сделали новую админку, на разработку которой ушел почти год, и на какие этапы делился процесс.
Не знаешь с чего начать - начни с потребностей клиента.
Отталкиваясь от потребностей пользователя, мы разработали огромное количество макетов и делать это решили опираясь на методологию сервис-дизайн (дизайн мышления). Сервис-дизайн — это методология и набор инструментов главная цель которых — это проектирование клиентского опыта. Для работы над админкой мы привлекли UX команду, которая помогала нам понять на каком этапе в Customer Journey Map (карта путешествия клиента) находится пользователь и какие процессы в компании вызывают его действия (путем составления Service Blueprint).
По Customer Journey Map и Service Blueprint мы находили спорные моменты и решали, что по функциональности необходимо оставить в админке, а от чего избавиться.
Всего этап создания админки составил 5 этапов:
Этап 1 – “Service Blueprint”
Это по факту групповая работа, которая делится на несколько встреч, на которой присутствует группа сотрудников: IT специалисты, которые разбираются в архитектуре кода, маркетологи и продуктологи, UX специалисты и менеджеры сервисной поддержки, которые чаще всего общаются с клиентом.
Цели этапа:
- Визуализировать работу каждого из отделов на пути производства всей услуги на основе Customer Journey Map;
- Выявить пробелы и проблемные участки;
- Увидеть точки роста и оптимизации;
- Спроектировать новый улучшенный процесс производства услуги;
На встрече присутствует фасилитатор, который задает вопросы разным отделам. В ходе работы это помогло нам выявить достаточно много “костылей” и “bottle neck’ов”, которые нарабатывались годами, разрушение которых стало основой для движения дальше.
Этап 2 – “Card sorting + new structure”
Цели этапа:
- Провести аудит всех разделов админки;
- Определить статусы сущностей (что устарело, что нужно убрать, что добавить);
- Спроектировать новую структуру.
Если по итогам первого этапа мы получили большое количество листов, на которых были расписаны разные разделы новой админки, то на втором этапе мы пытались понять, какие из этих разделов будут приняты в работу и станут основополагающими для нужного функционала, а какие будут добавляться позже либо вовсе окажутся лишними.
Этап 3 – Lo-Fi прототип + спецификации
Цель этапа:
Перенос структуры в прототип низкой детализации. В процессе переноса вам потребуется несколько раундов обсуждения и внесения правок с командой. Стоит сразу понимать, что подобного рода объемная задача не может быть выполнена за один подход. Количество правок и изменений будет большим. Будьте морально к этому готовы.
Кроме этого, уже на этом этапе есть смысл подумать про живые интервью, на которых вы можете показывать свои наработки (прототипы) пользователям. Это необходимо, чтобы собрать их фидбэк и понять насколько продукт, который вы создаете будет им понятным и удобным.
Этап 4 – Hi-fi прототип (прототип высокой детализации)
Цель этапа:
На этом этапе работы речь уже идет про детализированные прототипы. Фокусировка на проработке дизайна продукта, тактильности интерфейса, валидации графических решений.
Этап 5 – Чистовая отрисовка интерфейса
Цель этого этапа получить набор чистовых макетов интерфейса продукта во всех необходимых для адаптивного дизайна разрешениях и со всеми дополнительными состояниями интерактивных элементов.
И когда, казалось бы, все самое страшное уже позади и у вас на руках есть согласованные макеты, начинается самый интересный этап. Реализация и вылив на прод.
Реализация
Для того, чтобы внедрить эти изменения с минимальным дискомфортом для пользователя, был составлен план плавного перехода к новому интерфейсу. Согласно плану новый кабинет был сразу доступен новым пользователям, которые ранее не были зарегистрированы в системе. Эти пользователи ранее не были знакомы со старым интерфейсом, а следовательно, на них мы могли сделать чистый срез по показателям эффективности внедренных изменений.
Для старых же пользователей появилась возможность добровольного переключения между старым и новым кабинетом. Это позволило им ознакомиться с предстоящими изменениями, а нам — получить от них дополнительный фидбек. В таком состоянии кабинет у пользователей был доступен в течение месяца. Пользователь получал уведомление, что вскоре функционал старого кабинета будет отключен.
Самое сложное произошло именно в тот момент, когда старую версию интерфейса отключили: все показатели в течение нескольких недель говорили о том, что мы совершаем ошибку. Но на самом деле пользователю просто нужно было время на адаптацию. Уже спустя месяц мы получили данные, которые говорили о правильности принятого нами решения. Если бы это был тест — вариант А стабильно бы показывал результаты лучше и на основании данных вы были бы вынуждены принять неверное решение.
Анастасия Кононова, СМО TRIONIKA