Всем привет! Мы — команда Облака Mail: редактор Наташа (@Natalya_Vetrova), дизайнер Саша (@alexmoic96) и исследователь Лена.
Мы вместе работаем над улучшением сервисов Mail: проводим исследования пользовательского опыта, много дискаверим, проверяем гипотезы, проектируем интерфейсы и пишем тексты, которые помогают пользователям лучше ориентироваться в продукте.
В этой статье подробно разберём, как столкнулись с нетипичной проблемой низкой заметности элементов в интерфейсе и как через исследования, анализ поведения пользователей и системный дизайн пришли к созданию масштабируемой механики фокусировки.
Контекст и первые тесты
По мере роста количества фото и файлов в облаке пользователям становится всё сложнее ориентироваться в контенте. Мы в команде работали над функциями, которые должны были ускорить поиск нужного: добавляли фильтры, поиск, улучшали навигацию в галерее.
Логика была простой: если у пользователя тысячи фотографий, быстрые инструменты поиска должны экономить время и упрощать его жизнь.
Мы пошли проверять заметность новой функциональности на интерфейсных опросах:
где пользователи будут искать фильтры?
насколько быстро смогут их обнаружить?
какие ожидания у них возникают относительно интерфейса?
Результат оказался неожиданным: только 9% респондентов нашли нужную функцию — её узнаваемость и доступность была удручающе низкой.
В этой же итерации мы проверили восприятие иконки фильтрации и сравнили её с другими вариантами.
Оказалось, что выбранный нами вариант ассоциировался с фильтрами хуже остальных. Хотя разница между первым и вторым вариантами не достигла статистической значимости (p ≈ 0.08), выигрывал всё же второй. Учитывая результаты по тепловым картам, мы приняли решение двигаться именно с ним.
Вторая итерация и наши сомнения
Поначалу это выглядело как классическая интерфейсная проблема. Анализируя данные, я предположила, что низкая заметность может объясняться слабой ассоциацией выбранной иконки с функцией фильтрации, а также неоптимальным расположением элемента в интерфейсе. Дизайнер Саша внёс изменения: пересобрал экраны, скорректировал точку входа и заменил иконку на второй вариант. С обновлёнными макетами мы отправились в повторное тестирование.
Результаты заметно улучшились: доля пользователей, обнаруживших фильтры, выросла с 9% до 28%. Однако этот показатель всё ещё оставался недостаточно высоким для уверенных выводов.
Параллельно мы тестировали заметность функции поиска, которая должна была располагаться рядом с фильтрами. Там ситуация была схожей — только 31% участников её находили.
Контекстное интервью
Анализируя новые данные, я задалась вопросом: а что если проблема заключается не в визуальной подаче функции, а в том, что пользователи вообще не ожидают её существования в интерфейсе галереи?
Вместо очередного теста экранов я начала наблюдать, как люди ищут фотографии и файлы в повседневной жизни: в своих нативных галереях, облачных сервисах, фотоархивах. В разговоре с коллегами и друзьями просто наблюдала за ними, пока они искали свои файлы. Хотелось понять не то, как люди говорят про поиск, а как они ищут на самом деле. Это всегда начиналось одинаково: «Сейчас, погоди, я найду... так, сейчас, сейчас, где же это…»
Например, моя подруга, когда искала запись экрана, остановила поиск со словами «Ладно, я потом тебе как-нибудь скину». На вопрос, почему не воспользоваться подборками или фильтрами, она искренне удивилась — даже не думала о них.
И здесь нас ждал интересный инсайт. Большинство людей при поиске просто начинали скроллить ленту — в будущем мы подтвердили эту гипотезу через опрос.
Они листали галерею, пытаясь визуально зацепиться за нужный момент, дату, событие или знакомую фотографию. Фильтры и поиск часто даже не рассматривались как инструмент. Поэтому такой поиск не всегда заканчивался успехом.
Ключевые инсайты
Оказалось, что причин, почему люди не используют подобные инструменты, две:
многие просто не знают, что они существуют;
другие знают, но полагают, что переключение на новый способ поиска потребует значительно больше времени и когнитивных усилий, чем привычный визуальный скроллинг.
После наблюдений главный инсайт звучал так:
Новая функция не была интегрирована в существующую ментальную модель пользователей поиска в галерее. Их доминирующая поведенческая стратегия — «визуальный скроллинг» — оставалась наиболее доступной и низкозатратной с когнитивной точки зрения. Пока мы не поможем пользователю встроить новые инструменты в эту ментальную модель и не снизим барьер первого использования, любые улучшения интерфейса будут иметь ограниченный эффект.
Переход к решению
Исходя из полученных инсайтов, мы сформулировали продуктовую гипотезу:
если мы будем показывать новую функцию пользователю прямо в момент выполнения связанной задачи, то конверсия в использование этой функции существенно вырастет, а вместе с ней — и целевые продуктовые метрики, которые эта функция должна улучшать.
Нам нужен был онбординг — но не очередной оторванный от контекста экран, а механизм, который поможет встроить новые инструменты в привычную ментальную модель пользователя прямо во время сеанса.
Почему именно так?
Данные аналитики и маркетинговых исследований показывали, что знание о новых функциях в приложении оставалось низким — многие фичи знали меньше половины аудитории. Классические механики (тултипы, рассылки) работали неэффективно: пользователи быстро закрывали их, воспринимая как рекламу, включалась баннерная слепота.
Нам нужен был новый формат, который не будет похож на предыдущий и поможет растить знание. Поэтому мы вернулись к дизайну — но теперь к дизайну онбординга.
Дизайн: от инсайта к паттерну
Недостаточно было сделать фильтры заметнее — через несколько месяцев мы снова столкнулись бы с незаметностью уже на другой функции.
Нужно было найти способ рассказывать о новых возможностях так, чтобы пользователь замечал их в момент, когда они действительно нужны.
Почему не подошли привычные решения
В продукте уже существовали форматы обучения:
тултипы
промобаннеры
Но все они работали отдельно от пользовательского сценария. Человек открывал Галерею, чтобы найти фотографию, а мы — нипочему — предлагали ему прочитать сообщение про новую функцию. Такие коммуникации воспринимались как прерывание сценария и зачастую игнорировались.
Мы понимали, что обучение должно происходить внутри действия пользователя, а не рядом с ним.
Идея контекстного обучения
При проектировании нового формата мы опирались на несколько принципов.
Контекст важнее охвата
Мы отказались от идеи показывать обучение всем подряд: дать подсказку меньшему количеству пользователей, но в правильный момент сценария казалось более правильным. Например, рассказывать про фильтры, когда человек находится в Галерее и скролит её для поиска нужного объекта.
Минимальное вмешательство
Мы старались не ломать сценарий пользователя. Если механика начинает отвлекать сильнее, чем помогает, она превращается в тот же самый баннер, только в другом визуальном оформлении.
Так родилась идея «контекстной фокусировки»: вместо отдельного экрана или промобаннера интерфейс временно затемнялся, а нужный элемент получал визуальный акцент. Фокусировка должна была занимать несколько секунд и требовать минимум усилий для понимания. Пользователь видел не абстрактный рассказ о новой возможности, а сразу её расположение в интерфейсе.
Это решало сразу две задачи:
повышало знание о функции;
формировало память — пользователь запоминал, где искать инструмент в следующий раз.
Визуальная часть — только 50% успеха новой механики, другая половина зависит от текстов. Даже самый точный визуальный акцент не сработает, если сообщение окажется непонятным, слишком длинным или будет звучать в непривычном тоне.
Поэтому в следующем шаге мы занялись созданием единых правил коммуникации для фокусировок. Эту задачу взяла на себя Наташа.
Как мы писали про фильтры в галерее
Идея фокусировки в том, чтобы показать новый элемент встроенным в интерфейс приложения. Пользователь видит привычные иконки и кнопки, и среди них — фокусный элемент.
Но чтобы этот формат сработал, нужно аккуратно подходить к коммуникациям и соблюсти два правила:
понятность
достаточность
Понятность
Фокусировка — довольно деликатный формат онбординга в функцию. Он не перекрывает полностью интерфейс и лаконично доносит мысль. Но всё же он прерывает пользовательский сценарий. Поэтому важно донести мысль с первой попытки, не отрывая человека от задуманного действия. Самих экранов может быть несколько, если функция объёмная, но правило неизменно: одна мысль — один экран.
Это такой лаконичный смолтолк с коллегой на бегу: вы заняты, он занят, важную новость нужно сообщить максимально доходчиво и быстро. Поэтому стоит писать лаконично, но ёмко, чтобы пользователь сразу всё понял и пошёл с новым знанием решать свою задачу. Наша цель — сделать так, чтобы он не забыл эту задачу, пока читает текст.
Достаточность
Несмотря на тезис про лаконичные тексты, важно помнить, что эти тексты сообщают информацию, которая поможет пользователю качественно лучше достигать цели в продукте. Поэтому её должно быть достаточно. Если после прочтения текста у пользователя остаются вопросы, информации не хватило, цель онбординга не достигнута. Мы зря потратим рабочие и технические ресурсы, а пользователь — время.
Необходимо соблюсти баланс: размазывать мысль на 500 знаков, конечно, не стоит. Но если в макете предусмотрено две строчки, а вы хотите добавить третью для большей понятности — сделайте это.
Как делали мы
Нам нужно было рассказать пользователям, что в Облаке появилась сортировка при поиске файлов — и при этом остаться в контексте сценария, который проходит пользователь. А ещё любой текст — кирпичик в стене любви между продуктом и человеком. Это шанс вызвать хорошую эмоцию, и его нужно использовать.
На первом этапе мы подготовили тексты в разных тональностях. У каждого были свои преимущества — оставалось разобраться с недостатками.
Первый вариант — строгий, по делу, прямо называет функцию, подсказывает конкретное действие (нажмите). Но формулировка не поясняет, что речь про целые категории: фото, видео и избранное, а это, собственно, и есть улучшение — сам поиск был в Облаке уже давно.
Второй вариант делает акцент на новизне — и подсвечивает конкретную пользу для пользователя. Но остаётся лёгкая недосказанность: что за категории?
В третьем варианте мы применили наш любимый приём и поставили в заголовок реплику пользователя. Каждый из нас, кажется, её произносил, когда пытался найти фотографию. Знакомая реплика обеспечит узнавание — и доверие, как следствие. В тексте снова подсветили пользу и уточнили, о каких категориях говорим.
И вишенка — классная кнопка. Есть такое правило: кнопка в интерфейсе должна сочетаться с заголовком, отвечать ему. Оставалось только придумать подходящую реплику. И мы придумали такую — текст на ней озвучивает весь результат взаимодействия: мы сделали функцию, которая приведёт к фразе «О, вот, нашёл!». Это небольшая магия, которая не просто объясняет улучшение, но и работает на эмоциональную связь с продуктом.
В результате получился живой интересный текст, который способен выпасть из баннерной слепоты и зацепить человека. Легко заметить, что в третьем варианте больше строчек — это живое подтверждение правила достаточности. Чтобы объяснить суть функции, обучить и мотивировать человека прочитать текст, нам понадобилось три строчки. Небольшая плата за работающий инструмент.
Как паттерн превратился в систему
После первых запусков стало понятно, что мы нашли решение не только для фильтров.
Те же принципы можно применять для:
поиска
очистки памяти
общих альбомов
любых будущих функций
Поэтому вместо отдельных уникальных экранов под каждую задачу мы начали собирать универсальный шаблон.
В него вошли:
зона фокусировки
правила позиционирования
логика появления
ограничения по количеству текста
сценарии для разных типов экранов
В результате новая функция больше не требовала проектирования онбординга с нуля.
Команда получила готовый инструмент, который можно быстро адаптировать под новый сценарий.
Результат: что изменилось
После того, как дизайн-система и правила коммуникации были готовы, мы провели A/B-тест.
Конверсия в использование фильтров выросла на 4 п.п. Долгосрочная оценка роста составила 2,3 раза. Это подтвердило, что механика эффективно привлекает внимание пользователей именно в момент выполнения задачи и помогает встроить новый инструмент в их привычное поведение.
Через несколько месяцев после запуска маркетинговые исследования показали ещё один важный результат: фильтры вошли в топ-5 наиболее известных функций приложения. Для относительно новой фичи это сильный показатель.
Подтверждение продуктовой гипотезы и дополнительные эффекты
Успешный результат с фильтрами позволил нам масштабировать механику на другие функции. Следующим крупным экспериментом стала фокусировка на Истории в галерее и окне шаринга. В этом эксперименте мы уже увидели положительное влияние и на продуктовые метрики:
Engagement Rate Облака вырос на +1,91%
Engagement Rate Галереи вырос на +2,76%
Рост общей конверсии в шаринг файла из Облака: +6,66%
Влияние на работу команды разработки
Внедрение единого шаблона и компонента фокусировки существенно повлияло на эффективность команды разработки. Мы смогли значительно сократить время и трудозатраты на создание онбординга новых функций за счет того, что не приходится создавать каждый онбординг с нуля.
Вот что говорят сами разработчики:
«Компонент позволяет в разы сократить трудозатраты на добавление онбординга для новых функций. Сейчас, чтобы добавить фокусировку, нужно выполнить всего несколько шагов: по сути, сказать, для какого объекта показываем формат, с каким текстом и что делаем по тапу на фокусируемый объект — и компонент готов. Раньше основной проблемой выделения объектов было то, что некоторые были динамическими и могли поменять своё положение после показа фокусировки (например, фотографии в галерее). Эта проблема тоже решена: можно зафиксировать их положение в одном месте во время показа фокусировки».
«Благодаря фокусировке запуски экспериментов с новыми фичами стали более эффективными: мы можем сразу же их промить и лучше определять эффект. В коде проекта мы сделали небольшую библиотеку, которая помогает прикручивать онбординг куда угодно. Это позволяет экономить время где-то в 1.5-2 раза и не делать онбординги каждый раз с нуля. Теперь, если нужно, мы сможем затащить этот онбординг и в Почту или реализовать на Android». @sandboiii
Выводы
Работа над фокусировкой стала для нашей команды важным опытом перехода от борьбы с симптомами низкой заметности к созданию системного решения.
Этот кейс подтвердил несколько фундаментальных вещей.
Проблема низкой заметности новых функций не всегда лежит в интерфейсе, иногда проблема глубже: в ментальных моделях и устоявшихся поведенческих паттернах пользователей.
Самый эффективный онбординг — тот, который происходит внутри привычного сценария, а не прерывает его.
Переход от разовых решений к единому шаблону даёт мощный эффект как на пользовательские метрики, так и на скорость и стоимость разработки.
Стоит измерять долгосрочный эффект. Первый показ даёт всплеск, но настоящую ценность механики показывают повторные использования и устойчивый рост метрик.
