Когда бизнесу необходимо сломать шаблон UX

Ульяна Кривицкая, менеджер по продукту IT-компании PlantIn, которая занимается приложением для идентификации и определения стоимости монет CoinIn, рассказывает в колонке для AIN, когда обратная связь вашей целевой аудитории будет важнее сложившейся на рынке модели.

То есть это смесь правил с:

Формальные руководства. Например, Apple Store, Google Play — если говорить в контексте приложений.

Эвристики от Nielsen Norman Group, которые были сформированы на основе многолетних исследований аудитории.

Практический опыт многих компаний и продуктов, которые на собственных ошибках показали, что работает, а что нет.

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

Например, мы все знаем, как должен работать поиск или как должна выглядеть кнопка подтверждения или отмены. На подсознательном уровне мы уже знаем, куда нажать и чего ожидать в этих случаях.

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

Навигация. Без четкой навигации пользователи потеряются: например, если вы не предоставите возможность вернуться назад, продукт просто станет непригодным для использования.

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

Когда шаблоны можно (и нужно) сломать и почему

Для начала вам нужно определиться со своей целью: что она для вас? Менять узоры только ради творчества или желания выделиться – плохая идея.

В то же время нарушение шаблона может быть целесообразным, если оно:

Не соответствует ожиданиям вашей целевой аудитории;

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

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

Среди основных триггеров, которые могут указывать на то, что пора пересмотреть привычные закономерности, можно выделить:

Стагнация или падение показателей.

Исследование пользователей.

Совместимость с платформой. Шаблон «Интернет/десктоп» не работает на мобильных устройствах и наоборот.

Соблюдение локализации. Форма имени: имя/фамилия или метод чтения: слева направо или справа налево.

Нормативные требования. Иногда они могут усложнять привычные узоры, но их использование обязательно.

Появление ИИ/новых технологий. Они могут улучшить/упростить знакомые шаблоны и создать новые.

Кейс: согласованность кнопок и соответствие действий.

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

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

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

Поэтому возник вопрос: как помочь пользователям найти нужное им действие и сделать это быстро, четко и с минимальными усилиями? Вот здесь-то и пришли на помощь UX-паттерны, а точнее, их нарушения.

Мы сформировали гипотезу:

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

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

Таким образом, появилось несколько вариантов названий кнопок с префиксом Sell, таких как Save&Sell, Collect&Sell и т.д. В данном случае мы начали ломать даже несколько привычных шаблонов:

у одного элемента интерфейса должно быть только одно понятное действие — мы добавили 2 действия для названия кнопки;

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

Конечно, такие решения рискованны, поэтому, даже понимая, что это нужно аудитории, мы все равно решили провести A/B-тест. В качестве основной метрики для анализа мы взяли конверсию в листинг монеты, так как это было ключевым действием. Кроме того, мы отслеживали прямой CTR на кнопку, конверсию в добавление монеты в коллекцию, а также бизнес-метрики (конверсию в покупку подписки, удержание, LTV). Мы решили протестировать на новых пользователях и тех, кто еще не добавил монету в коллекцию, так как не взаимодействовал с предыдущим потоком.

Результаты

Добившись подходящей выборки и статистически значимой разницы, мы получили следующие результаты:

Конверсия в листинг монеты на продажу выросла на 32%.

Конверсия в добавление монеты в коллекцию выросла на 3,7% (это показывает, что мы не только не нарушили основной поток, но и улучшили его).

Удержание 1d выросло на 4,1%.

Конверсия в покупку подписки выросла на 2,5%.

После этого мы масштабировали результаты тестирования на всю аудиторию и дополнительно убедились, что показатели не ухудшились после релиза.

На основании этого случая мы поняли

Намерение пользователя важнее шаблонов — необходимо решать реальные потребности пользователей, а не следовать строгим правилам;

Сообщайте о ценности, а не о следующем шаге — в определенных случаях лучше показать конечную выгоду для пользователей;

Двойное имя может работать — два действия в одном элементе могут сработать, если они отражают мотивацию пользователей;

Рискованные изменения стоит протестировать — Само собой разумеется, что вам всегда следует проводить A/B-тестирование своих гипотез, особенно если они нарушают закономерности.

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

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

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

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