Эффект Кинопоиска. Какие исследования обязательно нужно сделать перед редизайном

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

Здесь можно объединить такие сценарии, как «дизайн приложения был отрисован в 2015, а на дворе 2022», «мы решили переписать приложение с кроссплатформы на натив и хотим сделать собственный дизайн для iOS и для Android с учетом особенностей каждой из платформ», «первая версия приложения была сделана на скорую руку» и так далее.

Внешняя — негативные отзывы со стороны пользователей по поводу внешнего вида и удобства приложения.

Внутренняя — обратная связь от различных групп стейкхолдеров (руководство, партнеры, коллеги) по поводу UX/UI приложения.

3. Обновление приложения в рамках ребрендинга

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

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

Когда команда продукта сталкивается с одной из вышеописанных проблем, велик соблазн позвать дизайнера (а лучше двух) и быстро приступить к переработке ненавистного интерфейса, чтобы в кратчайшие сроки сделать из него конфетку. Однако несмотря на стойкое ощущение, что редизайн был нужен еще вчера, в этот момент важно взять время на проведение небольшого исследования. Чтобы не получилось, как при перезапуске Кинопоиска в 2015.

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

Однако без более четких критериев успеха и метрик для их измерения обойтись все же не получится, так как:

• В случае глобального редизайна оценки в сторах с большой долей вероятности пойдут вниз.
• Удобство приложения — понятие относительное, а любые значительные изменения уже сами по себе ему противоречат. Как минимум в краткосрочной перспективе.
• Без метрик едва ли получится провести A/B тестирование.

Примерами правильно сформулированных метрик могут быть:

• Метрики, измеряющие Engagement пользователей — средняя длина пользовательской сессии в приложении, количество сессий в день и др.
• Метрики, измеряющие конверсии — конверсия бесплатных пользователей в подписчиков и др.

Если сформулированная для дизайнера задача будет звучать как «сделать из плохого интерфейса хороший», существуют риски, что:

а) в новый дизайн переедут старые баги/пробелы в логике,

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

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

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

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

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

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

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

Необходимо приобщить к исследованию (если мы говорим о внутренней команде) или составить (в случае внешнего подрядчика) следующие артефакты:

• Структурная схема приложения (например, в формате mind map или макетов в Figma с обозначением пользовательских путей). Может учитывать не только текущую версию, но и бэклог ближайших релизов.
• Актуальный список проблем/возможных улучшений. В этот список могут войти частотные баги, самые популярные запросы со стороны пользователей и другие задачи из бэклога вашего продукта с высоким приоритетом.

Если время позволяет, в качестве третьего артефакта можно составить Customer Journey Map. Это поможет выйти за рамки текущего интерфейса и понять, какие из болей ваших пользователей можно потенциально закрыть с помощью новых фичей в мобильном приложении.

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

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

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

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

Данные аналитики могут помочь:

• Доработать список метрик успеха и зафиксировать их состояния на текущий день.
• Обнаружить новые проблемы/точки роста, о которых не удалось узнать на предыдущих этапах исследования. Например, низкий % пользователей, использующих определенную функциональность.
• Провалидировать уже озвученные кем-либо цели или проблемы. Условно говоря, необходимо проверить, действительно ли существует проблема А («Пользователи не знают, что можно добавлять товары в Избранное») и достижима ли цель Б («Увеличить и без того высокую конверсию»).

Общение с пользователями может дать много пищи для размышлений. Что важно помнить при проведении подобных интервью:

• Постарайтесь собрать репрезентативную выборку респондентов. Важно избежать ситуации, когда все опрошенные представляют одну и ту же группу пользователей. Например, выборка из лояльных к компании пользователей вряд ли будет щедра на фидбек о том, что в приложении им совсем не по душе.
• Сконцентрируйтесь на получении новой информации, а не на валидации того, что уже удалось выяснить на предыдущих этапах исследования.
• Основная цель — выявить то, что для пользователей ценно и что нужно сохранить в ходе редизайна. А также — обнаружить дополнительные источники их недовольства. Например, огрехи в UX, которые причиняют неудобство, но не являются настолько критичными, чтобы пользователь обратился в техническую поддержку или воспользовался другим способом обратной связи.

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

С помощью тестирования можно:

• Проверить гипотезы относительно UX приложения (удобство, интуитивность и др.) на пользователях, еще не знакомых с ним.

• Определить какие пользовательские сценарии вызывают наибольшие трудности у новых пользователей. Это поможет при расставлении приоритетов для будущих изменений (см. «Формирование бэклога улучшений»).
• Проверить гипотезы на той ЦА, которая еще не пользуется приложением, но которую вы бы хотели охватить в рамках нового релиза.

Анализ конкурентов, скорее всего, будет тем этапом, к которому придется возвращаться снова и снова.

Основные его задачи:

• Анализ референсов от стейкхолдеров и пользователей. Важно детально изучить, что именно нравится людям у конкурентов, и почему в самом худшем случае они выполняют свою работу (job-to-be-done) в приложении конкурента, а не в вашем.
• Бенчмаркинг. Для редизайна (особенно если его причина — моральная устарелость текущего интерфейса) важно посмотреть лучшие практики по решению тех или иных задач в лучших приложениях на рынке. Ориентироваться здесь можно как на непосредственных конкурентов, так и на рынок мобильных приложений в целом, если речь идет о таких фичах, как, например, регистрация и авторизация.
• Сравнительный анализ с непосредственными конкурентами. Здесь важно вычленить и перенести в новый интерфейс ключевые преимущества текущего приложения относительно конкурентов (если есть), а также выделить потенциальные точки роста для успеха в конкурентной борьбе. Например, рассмотреть возможности добавления той функциональности, что пользуется успехом у пользователей конкурентов. Или, еще хуже, мотивирует их уйти от вас к ним.

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

Этот список важно превратить в полноценный бэклог, где для каждой задачи будет указан тип (баг, новая функциональность, изменение логики старой и др.), приоритет, метрика успеха, на которую должно повлиять изменение, и необходимость A/B тестирования. Оно может понадобиться для изменений на самых критичных экранах мобильного приложения — например, на экране покупки платной подписки.

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

Автор: Тимофей Мостивенко

Редактор: Елена Майорова

Иллюстрации: Александр Юдин