Когда в прошлом году мы выпустили наш новый мессенджер, мы добавили возможность для клиентов создавать расширенные личные профили, чтобы пользователи всегда чувствовали, что по ту сторона экрана — реальный человек.
В чем проблема? Никто не пользовался этой фичей. Вскоре после выпуска только 13-15% клиентов полностью заполнили свои профили. Большинство профилей частично заполнялись, в то время как остальные были и вовсе нетронуты.
Пример частично и полностью заполненного профиля
Обсудив это с коллегами из наших исследовательских и аналитических групп, мы обнаружили две основные причины такого низкого принятия новинки:
Профили были внедрены во многие части продукта Intercom, что означало, что нам пришлось задействовать много команд, чтобы увеличить их принятие пользователями. Команда по развитию интегрировала создание профиля в наше руководство по использованию приложения, в то время как продуктовая команда сделала редактирование профиля более видимым внутри самого Intercom.
Тем не менее, у нас была огромная возможность увеличить вовлечение, воспользовавшись нашими мобильными приложениями. Около 45% участников группы, которые общаются с клиентами (используя наш продукт Resolve), делают это через приложение в Android или iOS.
Для каждого нового проекта дизайнеры в Intercom создают простой список целей высокого уровня, которые связаны с проблемой, которую они берутся разрешить. Это дает направление при разработке решений высокого уровня. Наши цели выглядели примерно так:
Для начала мы отделили профили, чтобы помочь команде понять систему и решить, какие именно компоненты должны быть первоочередными. Это подразумевало составление описания всех частей, конфигураций, свода правил и тд. Вот пример того, что было на стене в нашей комнате сражений.
Эти системные документы помогли команде обсудить технические ограничения на раннем этапе, и уже тогда команда разработчиков предполагала, что команда дизайнеров могла об этом не подумать. Например, кто-то упомянул, что мы можем брать информацию из существующих источников, чтобы предварительно заполнять определенные компоненты в профиле. Поскольку у нас есть имя человека, когда он регистрируется в мобильном приложении, почему бы не перенести его в профиль автоматически и сэкономить время пользователя, когда он вводит его вручную?
После того, как мы набросали несколько направлений, мы встретились с Эмметом, нашим главным продуктовым дизайнером, чтобы получить обратную связь и принять решение о следующих шагах. Вот четыре варианта, которые были представлены:
Важнейшими составляющими здесь были фрагментация и объяснения. Мы не хотели, чтобы этот этап было легко проскочить, и нам нужно было место, чтобы доступно объяснить пользователям важность их профиля и каждого его компонента. Тем не менее, мы знали, что сильное дробление повлечет менее охотное принятие (то есть пользователи захотят пропустить этот этап), поэтому мы хотели, чтобы количество шагов в обучении было как можно меньше. В конце концов, мы решили обойтиcь простым руководством по регистрации (walkthrough прим.ред.). Ниже приведены решения нашей встречи. Прогресс!
На тот момент мы приняли два решения. Мы добавим простое пошаговое руководство к нашему приложению при запуске, которое бы запрашивало заполнить все отсутствующие компоненты профиля (фрагментация и объяснение). Третьей целью было добавление возможности «редактировать свой профиль из любого места». Мы решили работать в нашем текущем паттерне навигации и добавить простой значок редактирования в навигационной панеле, который бы ускорил бы процесс ознакомления.
Примечание. Одна из наших основных ценностей здесь, в Интеркоме, — «думать глобально, начинать с малого». На тот момент мы уже какое-то время планировали обновление навигации. Перемещение от панели навигации к панели вкладок было бы отличным решением по целому ряду причин, но в то время это требовало огромного количества тонкой инженерной разработки, а мы нуждались в быстром запуске.
Навигация на данный момент (слева) и навигация, которую мы планируем внедрить (справа).
На системном уровне мы установили для пользователей три состояния (states прим.ред), которые определяли бы их позицию в пошаговом руководстве. Из выбранного высокоуровневого направления мы знали, что юзер флоу будет состоять из трех основных шагов (см. диаграмму ниже), которые мы хотели сделать максимально простыми и легкими.
Пошаговые руководства довольно просты в плане дизайна. Это фиксированный путь от начала до конца, но логика усложняется при учете пользовательских состояний. Мы хотели перейти сразу к наиболее актуальной части, вместо того, чтобы заставлять пользователя пройти все пошаговое руководство. Также очень важно учитывать особые этапы самой платформы, такие как разрешение на использование камеры. Не на каждый шаг выделялось новое окно.
Опять же, эти диаграммы были распечатаны и вывешены в нашей комнате сражений. Инженеры часто стояли у стены, прочесывая весь процесс, и несколько раз обнаружили пограничные случаи, которые требовали внесение изменений от нас вместе.
Финальный флоу для ознакомительного руководства
К тому времени у нас уже был скелет, чтобы начать наращивать каждую часть отдельно. Визуальный и интерактивный дизайн создавался одновременно, с пониманием того, что мы будем продолжать настраивать визуальные эффекты по мере разработки приложения. Мы поняли, что окончательная доработка деталей в плане любых сложных взаимодействий или анимаций должна быть выполнена как можно скорее (именно поэтому high fidelity prototypes (прототипы высокой точности прим.ред.) выглядят отлично). Их гораздо сложнее изменить позже, в отличие от настроек визуального дизайна, таких как обновленные объекты, цвета и т.д.
Мы использовали Framer JS, чтобы построить прототип идей раннего взаимодействия, обсудить его с командой инженеров и договориться о том, что можно сделать. Ниже приведен пример нашего финального процесса для iOS, на котором мы сошлись после 12 прототипов.
С точки зрения визуального дизайна наши мобильные приложения уже приближались к нашему бренду. Любые новые разработки должны были говорить на том же языке и, если потребуется, использовать те же паттерны. Мы работали с нашей выдающейся командой бренд дизайнеров для иллюстраций на экраны ввода и подтверждения.
Контент был определяющим для проблемы объяснения. Нам нужно было кратко объяснить, почему профили были важными. Дизайнерская команда работала в тесном сотрудничестве с Элизабет МакГуайн , нашим контент-стратегом, чтобы разработать наиболее убедительный опыт и помочь пользователям понять, почему хороший профиль имеет такое значение.
Пример нашей контент-стратегии doc
Мы осознавали дробленность пошагового руководства и то, что многие люди, скорее всего, пропустят его, даже добавления опции напоминания пользователям заполнить профиль позже. Ключевыми были установка показателей для компонента и общее завершение работ, также как и возможность внесение поправок, основанных на полученных результатах, во время бета-периода.
Для нашей первой бета-версии процент выполненных действий (заполненных профилей прим. ред.) был довольно низкий, особенно на Android. Мы внесли различные изменения в дизайн, такие как удаление приоритетности с кнопки напоминания позже, изменение макета и настройки содержания, чтобы сделать их в более игривой и менее поучительной форме.
За неделю быстрых настроек и мониторинга процент выполненных дейтсвий значительно вырос. Благодаря вкладу нескольких команд, мы увидели, что в течение месяца наш общий коэффициент заполнения профиля вырос с 14% до 46%. Мобильное прохождение руководства сыграло огромную роль в этом рывке.
Также мы остались с конкретным набором уроков, который мы можем применить к нашему следующему проекту:
После четкого, логичного процесса, подобного этому, мы значительно увеличили наши шансы создать фичу, которой люди реально пользуются. Сначала это может показаться, что здесь слишком много деталей, но как только это входит в привычку, то становится частью естественного процесса.
Оригинал статьи можно прочитать здесь.