В последние несколько лет крупные веб-сервисы (Google, Яндекс, Amazon и т.д.), целенаправленно идут в сторону предоставления пользователям персонализированного контента на основе анализа истории запросов и некоторых других метрик, например, геопозиционирования. Вместе с недавними событиями, связанными с проектом PRISM, Сноуденом и безопасностью персональных данных, в определенных кругах такой подход даже начал провоцировать истерию, главные тезисы которой можно свести к следующим:
- интернет перестал быть для всех одинаковым;
- пользователям теперь можно показать только то, что нужно, без права выбора;
- за всеми нами следят.
Компании и жертвы истерии все чаще говорят о персонализированном контенте, когда каждому из пользователей предлагается информация наиболее релевантная к его потребностям, которые были проанализированы системой. Следующим шагом в этом направлении с точки зрения customer experience должна стать модель предиктивных интерфейсов, в которой персонализируется не только контент, но и сам способ его подачи. В итоге, для двух разных пользователей одно и то же ПО может выглядеть по-разному.
Об этом и поговорим.
Для начала, хочу поделиться с хабра-сообществом одной интересной заметкой: PREDICTIVE APPS ARE THE NEXT BIG THING IN APP DEVELOPMENT
Абстрагируемся от громких слов. Не будем бить себя в грудь и говорить, что предиктивные интерфейсы — это будущее. Это просто еще один вариант решения задач и достижения целей, который имеет как преимущества, так и недостатки. Попробуем немного порассуждать, как же это может работать.
Классическая структура ПО (десктопной программы, интернет-ресурса, мобильного приложения и т.д.) статична и, как правило, отображает иерархию разделов по своей функциональности. Например, в Microsoft Word разделы программы делятся на:
- Основной для работы с текстом
- Шрифт
- Абзац
- Стили
- и т.д.
- Вставка контента
- Таблицы
- Иллюстрации
- МУльтимедиа
- Ссылки
- и т.д.
- Разметка страницы
- Параметры страницы
- Абзац
- Упорядочение
- и т.д.
- Рабочая область с документом
- и т.д.
Любые интерфейсные блоки также статичны. Меню всегда будет сверху, рабочая область — по середине, строка состояния документа — внизу. Сам интерфейс «интуитивно понятен», т.к. вы видели его на множестве другого ПО аналогичного типа: центральная рабочая область и многоуровневое иерархическое меню сверху (хотя к тому же ленточному меню многие изначально не могли привыкнуть, т.к. оно-то как раз и отличалось от классических выпадающих списков). Вне зависимости от того, кто является пользователем, для всех Microsoft Word выглядит одинаково, если пользователь сам только не будет кастомизировать его под себя. Но много ли вы знаете бухгалтеров или секретарш, которые персонализируют настройки офисных программ под себя?! Основная мысль здесь — что для всего такого ПО пользователям приходится под него приспосабливаться, а не наоборот.
Статичный интерфейс в таком ПО — тоже самое, что и магазин с товарными полками и фиксированными ценами. Он предназначен для обслуживания большого трафика покупателей, которым приходится подстраиваться под внутренний распорядок магазина, даже если они пришли купить один только журнал. Все равно бедным покупателям придется пройти сквозь все отделы с рыбой, мясом, вином, промтоварами, чтобы выйти на кассу и купить свой любимый журнальчик, участвуя по пути в великом таинстве потребления, стимулированном приемами продаж владельца бизнеса. И никто не спросит клиента такого магазина, что ему нужно: журнальчик или пройти сквозь весь магазин, авось чего еще прихватит?! В таком супермаркете, клиент сам должен себя обслужить: пойти в него, найти необходимое, донести до кассы и купить. Звучит не очень приятно, но такова наша реальность. Другой мы пока не знаем.
Представим другую картину. Вы входите в магазин, к вам подбегает вежливый работник магазина и ненавязчиво спрашивает что вас интересует. Вы отвечаете ему, что хотели бы купить свой любимый журнальчик. А он такой — «Как же! Как же! Конечно, я помню, Иван Иваныч, только вчера новый номер вышел! Кстати, на эту же тему то же издательство стало выпускать новый журнальчик, но только с более научной подачей материала!». А вы такой: «Надо же! Большое спасибо, приятель! Заверни сразу два — другу подарю». И уходите счастливый и удовлетворенный. Получивший, что хотел сразу. Без различных прелюдий, вроде сдачи вещей в камеру хранения, путешествия по огромному комплексу с полками товаров и ожиданием в очереди кассы. Улыбчивый работник всегда с вами рядом. Он не навязчив, но готов ответить на любой ваш вопрос и выполнить любую вашу прихоть. Где лояльность клиента будет выше? А где будет выше конверсия?
Здесь должны многие возразить — ну как же? Ведь смысл лабиринтов IKEA в том и состоит, чтобы клиент купил не только то, что ему нужно, но и еще чего-нибудь. А мы и спорить не будем. Это две разных модели. Одна эффективна в одном случае, другая — в другом. Но точно одно. Магазин должен работать на клиента, и тогда клиент будет работать на магазин. Любое ПО — всего лишь средство достижения определенных целей пользователей, инструмент реализации бизнес-требований, мост для связи покупателя с продавцом. Текущее ПО пытается быть «всем для всех», из версии в версию оно расширяет свой функционал, увеличивая свои возможности, и, как следствие, усложняя интерфейс. Получаются весьма перегруженные вещи, в которых не разобраться сразу, а 90% функционала которых пользователи просто не используют, потому что он им не нужен. В итоге, мы получаем нечто подобное:
Итак, у нас есть два совершенно различных подхода: функционально-ориентированный, когда структура интерфейса задается жестко и не может быть изменена, или может быть изменена в очень узком смысле, и клиенто-ориентированный, когда структура интерфейса динамична, зависит от контекста и полностью определена целями пользователя. Истина, как всегда, находится по середине.
Вернемся к примеру с магазинами. Во втором случае с ненавязчивым, но услужливым продавцом-консультантом, многие покупатели, как правило, не могут определиться. Когда покупателю предлагаешь самому выбирать, он не может сделать этот выбор. Потому что средний покупатель не знает, чего он хочет, пока это не увидит. Так работает человеческая психика и от этого никуда не деться. Это вам скажет как любой дизайнер, пятый раз перерисовывающий логотип, так и любой продавец, демонстрирующий седьмую модель туфель. Человеку нужно за что-то «зацепляться», ему нужен якорь, отправная точка, от которой он будет идти.
Предиктивный интерфейс таким же образом должен предоставлять своему пользователю минимальный набор функций, от которого пользователь будет отталкиваться. Этот минимальный интерфейс предназначен для ввода пользователя в контекст. Допустим, мы хотим реализовать некоторый бизнес и приняли решение, что для этого нам необходимо некоторое ПО. Т.к. мы знаем немножко о бизнес-анализе, то определили основные группы пользователей и их характеристики и цели. Для каждой из цели мы определили, какой именно функциональностью она будет закрываться, а также провели шаги использования этой функциональности для достижения целей пользователей. Функциональность представлена в виде некоторого набора различных интерфейсных примитивов, будь то формы, области с информацией, меню, подсказки и т.д. В итоге, мы получили некоторое множество интерфейсов и дорожную карту его предоставления в зависимости от выбранной цели. Заметьте, мы не сделали интерфейсную структуру ПО, мы сделали наборы интерфейсов и последовательности их показа пользователю.
В начале работы приложения, мы предоставляем пользователю только те интерфейсные формы, которые являются вводными по каждой из его цели. Взаимодействуя с первичными формами, пользователь обозначает свои потребности и цели, которые система должна распознать на основе ранее проведенного анализа профилей пользователей и предложить дальнейший набор интерфейсов согласно дорожной карте выявленной цели. Так может строиться основной путь пользователя ПО. На этот путь уже навешиваются дополнительные наборы интерфейсов для повышения тех или иных микроконверсий, вроде примера с журнальчиком аналогичной тематики.
Почему это может работать? Например, у нас есть сайт по поиску ресторанов. Мы знаем, что наши пользователи в первую очередь интересуются где рядом с ними есть рестораны, топом ресторанов, а также акциями ресторанов. Как вы думаете, действительно ли им нужен интерфейс, аналогичный сайту restoclub.ru?! Я уверен, что нет. Многие разработчики ПО, этого не понимают. В итоге, многие пользователи меняют ПО, возможно, на худшее по функционалу, но более отзывчивое к их целям и требованиям. Это есть смысл UX. Это философия бизнеса. Сначала ты работаешь на клиента, потом — он на тебя.
Предиктивный подход особенно актуален в ПО со сложным интерфейсом и/или несколькими группами пользователей с различными целями. Предоставляя функционал по контексту мы экономим время пользователя на работу с функционалом, уменьшаем время на его изучение и повышаем лояльность клиента к нам на долгое время. Я предполагаю, что с развитием big data вместе с социальными сетями, количество приложений, придерживающихся клиенто-ориентированному подходу будет только повышаться. Вероятно, предиктивные интерфейсы могут повлиять на саму концепцию удовлетворения требований пользователей, поменяв модель с program-as-a-product на function-as-a-product.
Автор: termoyad_121
