UX-эксперимент: создали впятером интерфейс беспилотного такси, чтобы переосмыслить командный дизайн

Управляющий партнер Александр Шульгин рассказывает о том, как дизайнеры Purrweb за день решили придуманную задачу и какие выводы сделали.

Сперва поделюсь условным «дано».

Участниками эксперимента стали 5 дизайнеров и 1 проектный менеджер. На все про все отвели 8 часов (главный фокус Purrweb — MVP-разработка, поэтому сжатые сраки сроки не показались нам чем-то необычным). Рабочей «песочницей» стала Figma — жутко удобный инструмент, которому мы остаемся верны уже долгое время. Ну и главное условие — разработать интерфейс в рамках дизайн-системы продуктов «Яндекса».

В качестве рабочей стратегии дизайнеры выбрали Jobs To Be Done. Это помогло ограничить «полет фантазии» и спроектировать интерфейс, фокусируясь на целях и задачах, которые ставят перед собой пользователи. Такой подход подразумевает, что условный Иван Кошкин «нанимает» беспилотник для того, чтобы тот помог с выполнением конкретной «работы». «Нужно с комфортом добраться в аэропорт», «хочу слушать Billie Eilish в дороге», «не хочу разговаривать с водителем» — эти мотивации и стали для нас jobs to be done.

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

Затем провели экспресс-анализ конкурентов: прямых (беспилотники Lyft, Uber и Waymo) и косвенных (Tesla с их контролем полосы и автопилотом). Дизайнеры изучили навигацию, элементы управления, а после выписали все плюсы и минусы. Так, например, выяснилось, что ни один из конкурентов не использует функцию «Глазами Машины» (о том, что это такое, расскажу позже).

Под конец 20-минутного брейншторма дизайнеры устроили разбор потенциального продукта, с представлением каждого действия пассажира: как он вызывает такси, садится в машину, едет, прибывает в пункт назначения. Коллективное «Сработает? Если нет, почему?» помогло отсеять ерунду и остановиться на адекватных, практически применимых гипотезах.

Теперь про задачи. Как поделили зоны ответственности? Все просто. Отталкивались от здравого смысла ключевых сценариев приложения и личных предпочтений. По итогу вышло так, что каждому достались таски, которые делать в кайф.

Подробно останавливаться на этом этапе не буду. Просто еще раз отмечу, что мы изначально поставили задачу создать интерфейс в рамках дизайн-системы «Яндекс».

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

Зачем он нужен? Вот три главные причины:

Ниже варианты, которые получились на выходе.

За голосовыми интерфейсами будущее, определенно стоило пофантазировать в этом направлении:

Допустим, пользователь вызвал беспилотник. Автомобиль прибыл. Как подсказать, куда именно, если водителя нет? Коллективный брейншторм внутри дизайн-команды и беседы с коллегами по офису помогли найти решение — им стала функция «Глазами машины», позволяющая увидеть панораму места, где припаркован автомобиль.

Почему ни у одного из конкурентов нет фичи «Глазами машины»? Причины могут быть разными, точную мы наверняка не узнаем. В 2015 году тот же Uber пытался облегчить поиски прибывшего авто для пассажиров «обычного» такси — тогда они тестировали гипотезу с мигающим дисплеем телефона и светодиодной лентой на лобовом. Уверен, решение этой же проблемы в отношении беспилотников — всего лишь вопрос времени.

Наши дизайнеры не остановились на одном решении и придумали альтернативные способы обнаружить уже прибывший беспилотник. Так, кнопка «Звуковой сигнал» помогла бы найти автомобиль по звуку. А в вечернее время выручила бы функция «Световой сигнал» — это когда по нажатию кнопки включается аварийка.

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

Выручит «Алиса»!

По статистике, на текущий момент голосовыми помощниками пользуются 24% семей в США (что уже неплохо), но на территории СНГ процент гораздо меньше. Голосовой ассистент — вариант с перспективой на будущее, стоило также проработать альтернативные варианты взаимодействия пользователя с интерфейсом.

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

Тапнув кнопку «Добавить Остановку» (+), пользователю будет предложена возможность выбрать остановку на карте (иконка «Яндекс.Карт») или вбить адрес вручную, используя экранную клавиатуру.

Почему темная тема важна для приложений такси? Потому что за рулем слепящий экран телефона отвлекает человека, ответственного за перевозку.

Добраться до аэропорта в 3 утра, уехать домой после ночи в баре — это никакие не исключения, а ежедневная реальность. Темный фон поможет пассажиру остаться в «зоне комфорта» и снимет напряжение с глаз в условиях низкой освещенности.

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

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

Чтобы создать ощущение безопасности, дизайнеры визуализировали работу датчиков (лидаров), построение маршрута и объектов, которые встречаются на пути. Показать то, как «мыслит» машина на ходу — отличный способ снять страх и тревогу у пассажиров.

Если в такси у пользователя освобождаются руки, его можно нужно развлекать.

Как не дать пассажиру заскучать? Можно предложить залипнуть в социальных сетях, подкинуть контент с YouTube или stories от «Яндекса». Такие плюшки помогают отвлечься и расслабиться — человеку, который в первый раз сел в беспилотник, это и нужно.

Дизайн-команда предпочла развить тему с музыкой. Почему? Да потому что водителя нет, а кайфовать от песен, которые тебе по душе, приятно всегда. Особенно в дороге!

Для удобства пользователей приложение берет данные из аккаунта «Яндекса» (он привязан к номеру телефона) и включает медиатеку. Пассажир может собрать музыкальную подборку самостоятельно, используя «Яндекс.Музыку».

Пока дизайнеры проектировали плеер, появилась гипотеза: «Должны ли элементы управления медиа визуально отличаться от элементов навигации?»

«Добраться» до правды помог открытый вопрос. Ответить односложное «Да» или «Нет» невозможно — это и позволило выяснить, что заходит хорошо, а что не очень.

Когда пользователь «Яндекс.Музыки» попадает на главную страницу, он видит баннер «Создать плейлист дня». На его месте появился баннер в стиле «Яндекс.Беспилотник», с приглашением создать треклист для поездок в беспилотном такси.

А это вариант точки доступа в офлайн-режиме.

Что это дало нам? Объяснять действительность, вбрасывая пафосные и высокопарные фразы, совсем не хочется. Просто отмечу, что было сложно. А еще полезно: такой эксперимент помог сплотить дизайнеров и переосмыслить текущие дизайн-процессы — недавно мы начали тестировать гипотезу «Один проект — два дизайнера». Расскажу, как получим первые результаты.

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

1. Появился опыт внедрения нового функционала в существующее приложение. Итогом такого эксперимента стал интерфейс, который можно тестировать и показывать пользователям. Поставленная на старте цель достигнута — молодцы же.

2. Методология JTBD больше подходит для продуктовых спринтов, потому что фокус идет не на создание Customer Journey Map (карты следования пользователей), а на выявление проблем и поиск решений.

3. Проектируя интерфейс в команде, нельзя сделать так, чтобы работа одного участника не зависела от результатов другого — например, поиск машины тесно связан с подачей и заказом. Из-за того, что мы не уделили достаточно времени коммуникации и ревью, результат вышел разрозненным.

4. Для командного дизайна нужен человек, который выступит в роли продукт оунера. Такой участник не закопается в проработку своего дизайн-кусочка и возьмет на себя ответственность за ревью и постановку задач. Будет вести команду, опираясь на ограничения (например, коммерческие) и в соответствии со своим видением.

Порекомендовал бы я кому-нибудь такой формат? Аутсорс-командам — определенно. Такой эксперимент — это как минимум рабочий способ поддерживать тонус процессов взаимодействия. Каждый участник на день вылезает из-за своего моника и фокусируется на решении одной и той же проблемы. Больше совместной работы → больше идей извне → круче выхлоп на финише.

#ux #ui #дизайн #яндекс #беспилотник