Эффект Кинопоиска. Какие исследования обязательно нужно сделать перед редизайном
Какие изначально бывают стимулы поскорее все переделать
Все мы, как минимум как пользователи, хотя бы раз ловили себя на мысли, что тому или иному мобильному приложению срочно требуется обновление дизайна. В рамках этой статьи мы предлагаем поставить себя на место людей, ответственных за развитие продукта. С их точки зрения различные причины для редизайна приложения можно сгруппировать в несколько основных.
1. Текущий дизайн устарел / приложение устарело в целом
Здесь можно объединить такие сценарии, как «дизайн приложения был отрисован в 2015, а на дворе 2022», «мы решили переписать приложение с кроссплатформы на натив и хотим сделать собственный дизайн для iOS и для Android с учетом особенностей каждой из платформ», «первая версия приложения была сделана на скорую руку» и так далее.
2. Обратная связь по поводу приложения (внешняя и внутренняя)
Внешняя — негативные отзывы со стороны пользователей по поводу внешнего вида и удобства приложения.
Внутренняя — обратная связь от различных групп стейкхолдеров (руководство, партнеры, коллеги) по поводу UX/UI приложения.
Темная сторона редизайна — негативные отзывы. Каким бы замечательным ни получился новый продукт, людям придется заново учиться им пользоваться. И не все относятся к этому процессу как к возможности стать лучше себя предыдущего.
Поэтому нужно заранее решить, как именно мы будем информировать людей, продумать процесс онбординга и обучения.
3. Обновление приложения в рамках ребрендинга
В случае глобального обновления бренда компании или разработки новой айдентики непосредственно мобильного приложения также потребуется редизайн.
4. Проблемы с дальнейшим масштабированием
Если в приложении увеличивается количество пользовательских сценариев или они значительно усложняются, продуктовая команда может столкнуться с тем, что добавление новых фичей без ущерба общему удобству работы с приложением станет невыполнимой задачей.
Парадоксов не избежать. Не всегда редизайн приложения нацелен на улучшение опыта пользователя. Достижение бизнес-целей может, наоборот, негативно сказываться на удобстве интерфейса.
Почему нельзя сразу сесть и спешно все перерисовать
Когда команда продукта сталкивается с одной из вышеописанных проблем, велик соблазн позвать дизайнера (а лучше двух) и быстро приступить к переработке ненавистного интерфейса, чтобы в кратчайшие сроки сделать из него конфетку. Однако несмотря на стойкое ощущение, что редизайн был нужен еще вчера, в этот момент важно взять время на проведение небольшого исследования. Чтобы не получилось, как при перезапуске Кинопоиска в 2015.
1. Определить критерии и метрики для измерения успеха
На первый взгляд может показаться, что критерии успеха редизайна достаточно типичны. А именно — приложение должно стать более удобным и красивым, должны вырасти оценки в сторах и прийти положительные отзывы от пользователей.
Однако без более четких критериев успеха и метрик для их измерения обойтись все же не получится, так как:
- В случае глобального редизайна оценки в сторах с большой долей вероятности пойдут вниз.
- Удобство приложения — понятие относительное, а любые значительные изменения уже сами по себе ему противоречат. Как минимум в краткосрочной перспективе.
- Без метрик едва ли получится провести A/B тестирование.
Примерами правильно сформулированных метрик могут быть:
- Метрики, измеряющие Engagement пользователей — средняя длина пользовательской сессии в приложении, количество сессий в день и др.
- Метрики, измеряющие конверсии — конверсия бесплатных пользователей в подписчиков и др.
2. Составить бэклог необходимых улучшений/исправлений
Если сформулированная для дизайнера задача будет звучать как «сделать из плохого интерфейса хороший», существуют риски, что:
а) в новый дизайн переедут старые баги/пробелы в логике,
б) в новом дизайне будет покрыта лишь часть того, что уже годами просят ваши пользователи,
в) в процессе переработки интерфейса будет утрачена или сильно переработана та функциональность, которая была очень важна для пользователей.
Как итог, вместо улучшения все может стать хуже с точки зрения не только реакции пользователей (что, как мы уже знаем из пункта 1, неизбежно), но и сформулированных нами критериев успеха.
Возможные этапы исследования
Ниже приведен список этапов исследования для подготовки к редизайну. Он не является исчерпывающим, равно как и его этапы не являются обязательными. Вполне возможно, что некоторые из них уже были проведены вами или вашей командой в рамках повседневной активности или других проектов.
Опрос внутренних стейкхолдеров
Вне зависимости от того, отвечает ли за редизайн сторонняя команда, или внутренняя команда продукта делает его своими силами, начать исследование стоит с брифа внутренних стейкхолдеров.
В ходе данного процесса можно сформулировать основные цели и ожидания от редизайна и собрать список тех проблем в текущем интерфейсе, которые находятся на поверхности.
Также можно составить первичный список метрик, с помощью которых будет измеряться потенциальный успех. Однако недостаточно просто перечислить все текущие продуктовые метрики, за которыми следит команда. Они должны соответствовать принципу MECE. Например, нельзя поставить задачу, чтобы редизайн помог одновременно увеличить долю заказов с доставкой и самовывозом или единоразовых покупок и подписок.
Аудит текущего решения
Необходимо приобщить к исследованию (если мы говорим о внутренней команде) или составить (в случае внешнего подрядчика) следующие артефакты:
- Структурная схема приложения (например, в формате mind map или макетов в Figma с обозначением пользовательских путей). Может учитывать не только текущую версию, но и бэклог ближайших релизов.
- Актуальный список проблем/возможных улучшений. В этот список могут войти частотные баги, самые популярные запросы со стороны пользователей и другие задачи из бэклога вашего продукта с высоким приоритетом.
Если время позволяет, в качестве третьего артефакта можно составить Customer Journey Map. Это поможет выйти за рамки текущего интерфейса и понять, какие из болей ваших пользователей можно потенциально закрыть с помощью новых фичей в мобильном приложении.
Анализ обратной связи от пользователей
В ходе исследования необходимо по максимуму охватить всю доступную обратную связь, не ограничивая себе отзывами в App Store и Google Play. Ценная информация может содержаться в ответах пользователей на опросы, в их отзывах в соцсетях, в старых записях интервью и других источниках.
Настоящим кладом может оказаться история обращений пользователей в техническую поддержку. Вы можете даже и не подозревать, какое количество вопросов о том, как сделать что-либо в приложении, получают ваши специалисты. Именно эта функциональность, возможно, требует улучшения с точки зрения usability.
При работе с обратной связью стоит помнить, что в большинстве своем она будет посвящена тому, что пользователям не нравится. Однако, как мы уже говорили ранее, не менее важной задачей является понимание того, что им нравится в приложении. Для получения этой информации, скорее всего, потребуется пообщаться с пользователями вживую (см. пункт «Интервью с пользователями»).
Изучение данных аналитики
В рамках данного пункта будем исходить из того, что аналитика в приложении настроена. В противном случае сбор аналитики должен быть добавлен в приложение вместе с обновлением интерфейса. Это даст возможность анализировать метрики, которые мы определили как критерии успеха.
Данные аналитики могут помочь:
- Доработать список метрик успеха и зафиксировать их состояния на текущий день.
- Обнаружить новые проблемы/точки роста, о которых не удалось узнать на предыдущих этапах исследования. Например, низкий % пользователей, использующих определенную функциональность.
- Провалидировать уже озвученные кем-либо цели или проблемы. Условно говоря, необходимо проверить, действительно ли существует проблема А («Пользователи не знают, что можно добавлять товары в Избранное») и достижима ли цель Б («Увеличить и без того высокую конверсию»).
Интервью с пользователями
Общение с пользователями может дать много пищи для размышлений. Что важно помнить при проведении подобных интервью:
- Постарайтесь собрать репрезентативную выборку респондентов. Важно избежать ситуации, когда все опрошенные представляют одну и ту же группу пользователей. Например, выборка из лояльных к компании пользователей вряд ли будет щедра на фидбек о том, что в приложении им совсем не по душе.
- Сконцентрируйтесь на получении новой информации, а не на валидации того, что уже удалось выяснить на предыдущих этапах исследования.
- Основная цель — выявить то, что для пользователей ценно и что нужно сохранить в ходе редизайна. А также — обнаружить дополнительные источники их недовольства. Например, огрехи в UX, которые причиняют неудобство, но не являются настолько критичными, чтобы пользователь обратился в техническую поддержку или воспользовался другим способом обратной связи.
Юзабилити тестирование
Юзабилити тестированию и методологии его проведения можно посвятить отдельную статью. Но в рамках текущей темы важно отметить, какую дополнительную пользу может принести эта активность.
С помощью тестирования можно:
- Проверить гипотезы относительно UX приложения (удобство, интуитивность и др.) на пользователях, еще не знакомых с ним.
- Определить какие пользовательские сценарии вызывают наибольшие трудности у новых пользователей. Это поможет при расставлении приоритетов для будущих изменений (см. «Формирование бэклога улучшений»).
- Проверить гипотезы на той ЦА, которая еще не пользуется приложением, но которую вы бы хотели охватить в рамках нового релиза.
Анализ конкурентов
Анализ конкурентов, скорее всего, будет тем этапом, к которому придется возвращаться снова и снова.
Основные его задачи:
- Анализ референсов от стейкхолдеров и пользователей. Важно детально изучить, что именно нравится людям у конкурентов, и почему в самом худшем случае они выполняют свою работу (job-to-be-done) в приложении конкурента, а не в вашем.
- Бенчмаркинг. Для редизайна (особенно если его причина — моральная устарелость текущего интерфейса) важно посмотреть лучшие практики по решению тех или иных задач в лучших приложениях на рынке. Ориентироваться здесь можно как на непосредственных конкурентов, так и на рынок мобильных приложений в целом, если речь идет о таких фичах, как, например, регистрация и авторизация.
- Сравнительный анализ с непосредственными конкурентами. Здесь важно вычленить и перенести в новый интерфейс ключевые преимущества текущего приложения относительно конкурентов (если есть), а также выделить потенциальные точки роста для успеха в конкурентной борьбе. Например, рассмотреть возможности добавления той функциональности, что пользуется успехом у пользователей конкурентов. Или, еще хуже, мотивирует их уйти от вас к ним.
Формирование бэклога улучшений с приоритетами
По итогу всех вышеперечисленных этапов исследования у вас на руках должны оказаться артефакты, которые пригодятся дизайнеру при работе над новым интерфейсом, а также список того, что надо исправить/можно добавить/было бы здорово поменять в новом интерфейсе. Иными словами, огромный список хотелок от разных групп пользователей.
Этот список важно превратить в полноценный бэклог, где для каждой задачи будет указан тип (баг, новая функциональность, изменение логики старой и др.), приоритет, метрика успеха, на которую должно повлиять изменение, и необходимость A/B тестирования. Оно может понадобиться для изменений на самых критичных экранах мобильного приложения — например, на экране покупки платной подписки.
По итогам составления бэклога можно приступать к работе. В ней важно соблюдать итерационный подход и не сводить все к одному резкому обновлению приложения. Это поможет снизить градус реакции пользователей на неожиданные изменения, собрать обратную связь на новую концепцию дизайна до того, как вы отрисовали в ней все экраны, а также при необходимости поменять приоритеты в вашем бэклоге.
Под редизайном, как правило, понимается что-то масштабное и сложное. И это действительно так, если браться за всё и сразу. По этой причине клиенты иногда приходят с запросом на «Давайте просто фейслифтинг сделаем, не нужно ничего переделывать, просто дизайн актуализируйте и норм, это же быстро?». И звучит это достаточно логично, но, на деле, времени и денег уходит ещё больше, а выхлоп нулевой. Современный цифровой продукт – это не набор цветов, картинок и тенюшек. Это совокупность различных сервисов, омниканальный опыт взаимодействия, коммуникация с пользователем и куча всего, что вообще никак не связано с цветом кнопок. И именно это определяет качество продукта.
Поэтому, если речь заходит про фейслифтинг с целью экономии, нужно убедить клиента просто не замахиваться на полноценный редизайн, а начать переделывать приложение с наиболее болезненных мест.
Автор: Тимофей Мостивенко
Редактор: Елена Майорова
Иллюстрации: Александр Юдин
Нечего не добавить, только лишь:
Срочно фэйслифтинг этому господину!
Крч надо просто редезигн, как и другие серьёзные изменения, выкатывать небольшой части юзеров. Причём с дезигном это как раз сделать обычно сильно легче чем с фичами которые там ещё и бэкенд сильно цепляют.
Половина редизайнов мне не нравится и я считаю что они откровенно говенные. У того же ФБ стало сильно хуже все. Ещё хуже.
«Дизайн устарел» это отвратительный аргумент. Старое не значит плохое, новое не значит автоматически лучшее.
Иногда мне кажется что много редизайнов делаются тупо потому что дизайнерам и прочим причастным нужно просто оправдывать свою зарплату. Типа не просто так якобы штаны просиживаем.
UX другая история, там изменения могут быть оправданными, но там тоже часто лютый трэш творится (опять привет ФБ)
Как по мне, изменять дизайн нужно постепенно, не сразу.
Сначала новую концепцию можно прописать, а далее внедрять ее поэтапно, дабы пользователь мог привыкнуть к новым изменениям. Так например делают крупные соц. сети, внедряя новинки (например, вк раньше все поэтапно вводил, из-за чего было удобно привыкать, а потом он сразу обновы фигачить начал)
"Отзывы в сторе — кладезь полезной информации" - спасибо кэп)
Не хватает "после того как продуктовая компания "СУПЕРБАНКИВАНОФФ" отсмотрела отзывы, они добавили вот это, и стало круто и классно)
В большинстве своём игнорируют же, либо отзывы пишут фейки и гасят ваш рейт (привет Тануки/ЦИАН)