Персонализация мобильных приложений — один из самых заметных трендов последних лет. Индивидуальный подход к потребителю начинает восприниматься как норма. Как сделать интерфейс приложения наиболее удобным для пользователей, рассказал руководитель отдела UX компании MOVER, спикер курса Product Design Weekend в Binary District Василий Гордеев.

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

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

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

Определять паттерны

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

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

Третий этап — анализ собранной по меткам статистики. На этом этапе пользователей разбивают на различные группы. Некоторые аналитические сервисы сами предлагают такие группы: например, «девушки между 20 и 30 годами» или «мужчины за 40 лет». Обычно для этого используют самые простые признаки: пол, возраст и так далее. Анализ позволяет узнать, какой паттерн характерен для реальных клиентов компании.

Пример: после запуска первой версии приложения MOVER мы выяснили, что чаще всего им пользуются девушки, которые работают в офисе. Таких клиентов было больше 60%: однажды мы ради шутки даже изменили цвет приложения на розовый. Обычно они заказывали перевозку в конце рабочей недели, по пятницам. Девушки проходили пользовательский путь внутри приложения намного быстрее, чем мужчины. Это было связано с тем, что в начале они обращали внимание на меньшее число деталей. Для них было неважно, «Газель» повезет груз или Porter (грузовики «Газель» и Hyundai Porter — предмет постоянного обсуждения и сравнения на автомобильных форумах — прим. ред.). Главное, чтобы в эту машину все влезло и перед заказом можно было посмотреть, сколько стоит каждая отдельная услуга.

Василий Гордеев

Внедрять изменения

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

После того, как новые элементы внедрены, на них ставят метки и смотрят, что получится. По-хорошему, надо также делать А/В-тестирование. Разбивать клиентов на две группы: для одной вводить изменения, для другой — нет, и изучать, насколько быстро они будут проходить пользовательский путь. Цель — чтобы они провели в приложении меньше времени, но потратили больше денег.

Мелкие изменения в любом приложении нужны постоянно. У нас они делаются раз в неделю-две. Заметные изменения — раз в три месяца. Например, сейчас у нас изменился основной пользовательский паттерн: услугами грузоперевозок стали пользоваться юрлица, которые выдают себя за обычных юзеров. Исходя из этого, мы разрабатываем обновления и скоро будем апдейтить приложение.

Отслеживать реакцию на апдейты

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

Сколько времени понадобится для того, чтобы понять, что изменения были неэффективными, зависит от количества пользователей. Facebook или Google может хватить нескольких минут, чтобы принять решение. Условно — перекрасят их дизайнеры кнопку в зеленый цвет для 1% пользователей в Азии, и практически сразу увидят, хорошая ли это идея. Им не нужно долго ждать, потому что у них миллиард пользователей.

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

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

Сокращать расстояние между дизайном и разработкой

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

Раньше работа строилась так: был проектировщик, UI-разработчик, который рисовал интерфейсы, и разработчики бэкенда и фронтенда, которые все это верстали. Вы делали продукт — непонятно, хороший или плохой. А сейчас можно протестировать его и отдельные элементы интерфейса еще до выпуска.

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

Источник