Глобальный редизайн приложения Uber для пассажиров: как изменить сам принцип заказа такси

Глобальный редизайн приложения Uber для пассажиров: как изменить сам принцип заказа такси

VSEPROSTO


Время чтения: 21 минута

Перевод колонки дизайнера Саймона Пана.

В 2012 году казалось, что вызвать Uber с другого конца города одним нажатием кнопки — это какая-то магия. К началу 2016 года вместо магии осталась масса разнородных функций, из-за чего процесс заказа такси стал медленным и сложным.

Я принимал участие в амбициозном проекте редизайна заказа такси в Uber, самом быстрорастущем стартапе в истории. 

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

Дизайн путём приращения

Всего за пять лет с 2011 года из сервиса автомобилей класса люкс для 100 друзей в Сан-Франциско Uber превратился в глобальную сеть перевозок. К 2016 году Uber обеспечивал более трёх миллионов поездок в день в более чем 400 городах в 70 странах.

Приложение для пассажиров, разработанное в 2012 году, пыталось поспевать за интенсивным ростом компании. Но со временем его юзабилити оказалась под угрозой. Разнородные функции и экспериментальные нововведения боролись за внимание пользователей. Проблемы с надёжностью приложения и работой с ним росли экспоненциально. 

Приложение для пассажиров превратилось в сложную организационную схему.

Задача: вернуть магию за десять месяцев

Целью проекта было возродить магию первых дней Uber. Изначальный замысел был прост: нажми на кнопку — получи поездку. Однако мы не пытались вернуться в «простое» прошлое.

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

Главное, к чему мы стремились: 

  • сделать приложение быстрым и простым в использовании везде и для всех;
  • дать пассажирам больше возможностей контролировать свои время и деньги;
  • создать платформу для инноваций и вовлечь больше пользователей.

Моя роль

Я руководил дизайном с октября 2015 по июнь 2016 года и сотрудничал с двумя другими дизайнерами в работе над стартовым экраном, поиском такси и экраном «в пути».

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

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

Новая версия была запущена 2 ноября 2016 года.

Старт: складываем картинку по кусочкам

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

Первые инсайты с мест

Мы протестировали существующее приложение Uber на восьми участниках в самых проблемных для заказа районах Сан-Франциско. Перед нами стояли две задачи: понять, с какими трудностями сталкивались водители и пассажиры, и узнать, какие обходные пути они использовали.

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

Пассажиры раздражались, когда водитель выходил на связь, чтобы уточнить, где они находятся. Они считали, что Uber должен делать свою работу, и не видели необходимости повторять одно и то же.

Водителю дали неоптимальный маршрут

Пассажирам не нравились некоторые маршруты, которые водители использовали, чтобы до них добраться. Они ожидали, что Uber строит маршруты умнее.

Остановка в неожиданном месте

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

«Кнопочники» и «булавочники»

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

Открытие: ожидания пассажиров менялись со временем

Трудности, которые мы обнаружили, меня удивили. Они были похожи скорее на привилегированных жителей Сан-Франциско, чем на ключевые проблемы нашей глобальной аудитории. Но, поразмыслив, я понял: пассажиры просто хотели, чтобы процесс работал с минимальными усилиями с их стороны. Uber вошёл в их жизнь, и ожидания пассажиров изменились.

Любопытство открыло нам способ улучшить заказ такси везде и для всех.

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

Глубокий инсайт: начинаем с «идеала» и движемся назад

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

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

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

Я объединился с нашим специалистом по обработке данных и использовал следующую таблицу, чтобы изучить, в каком состоянии находится заказ такси в разных странах мира.

Большинство заказов требовали дополнительного согласования или физических усилий

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

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

Такой занятой город, как Сан-Франциско, терпел убытки в более чем $1 млн каждую неделю из-за проблем с заказом такси.

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

Сан-Франциско терпел убытки в более чем $1 млн каждую неделю из-за проблем с заказом такси. В городах вроде Гуанчжоу и Нью-Дели дела обстояли намного хуже.

Я намеренно опустил конфиденциальные данные.

Не указано место отправления

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

Указанное пользователем место часто не является местом отправления

Лишь малый процент поездок начинается в 20 метрах от запрашиваемого места. Куда отправили водителя и откуда на самом деле заберут пассажира — это разные вещи.

Игнорируются обновления GPS

Во многих сессиях точность GPS улучшается к моменту запроса. Часто точность улучшается более чем на километр.

Некоторые пункты отправления просто не имеют смысла

Многие поездки запрашиваются из зданий. Приложение может показать разные пункты отправления в зависимости от операционной системы водителя.

Переосмыслим проблему: непродуманный план встречи вызывает трудности

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

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

Как нам помочь пассажирам и водителям сформировать более удачный план встречи?

Мы предложили рандеву — план, созданный в интересах пассажиров и водителей.

Карта процесса заказа такси, поделённого на два этапа: формирование и выполнение плана встречи. Слева направо: предложение, оценка, поручение, движение, ожидание, рукопожатие. В кружок обведён проблемный этап согласования

Редизайн заказа такси: внедрение рандеву

В век, когда всё вокруг требует вашего времени, Uber возвращает вам его, позволяя заказать такси быстро, легко и спокойно. Uber принимает разумные решения, чтобы защитить вас — информируя так, чтобы вы понимали, что делать.

С вас запрос, с нас всё остальное

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

Разработанные для людей пешеходные инструкции помогают лучше понять, где найти и как обозначить место встречи. Больше никаких бессмысленных адресов.

Вперёд и быстрее

Иногда существует более быстрый путь, для которого нужно немного пройти пешком. Uber распознаёт такие ситуации и предлагает вам способ сэкономить время.

Мы вас прикроем

Если Uber не уверен, где вы находитесь, он попросит вас помочь уточнить. Со временем Uber узнает больше о вас и вашем городе, и ваша поездка всегда будет начинаться в нужном месте.

Гибкость и последнее слово

Иногда нужно, чтобы вас забрали из точно определённого вами места. Uber даёт вам полный контроль, когда он нужен.

Пройденный путь: как усовершенствовать заказ такси везде и для всех

Три первостепенных вопроса формировали мою дизайн-стратегию:

  • Как сделать дизайн для всех, повсюду?
  • Какие контексты нужно учитывать?
  • Как выглядит идеальный заказ такси?

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

Контекст среды, персональный, технологический, социальный и культурный, временной контексты, бизнес-контекст

Инклюзивный дизайн

Существующее приложение Uber было разработано для таких пользователей, как сотрудники Uber в Сан-Франциско, и плохо работало для тех, кто на них не походил. Чтобы выйти за рамки сложившихся предубеждений, я попытался научить команду создавать дизайн для всех, повсюду. 

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

«Ситуации» — это попытка выделить ситуационные задачи, с которыми сталкивается каждый. Ситуация — это временный контекст, который влияет на то, как человек какое-то время взаимодействует с Uber.

Исторически Uber не предназначался для пользователей, отличающихся от сотрудников офиса Uber в Сан-Франциско.

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

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

Ситуации: зависимость от времени, зависимость от цены, подключение и пропускная способность, угроза безопасности, точность GPS, анализ местности, попутчики, нормы и правила, пространственная среда.

От упрощения к адаптации

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

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

Схема помогла перейти от непродуктивных вопросов вроде «Как упростить это для Найроби?» к «Как нам сделать дизайн "сначала пункт назначения" для городов без традиционной системы адресов?»

↑ ­­­Приземлённость (сосредоточиться на практическом решении человеческих проблем)

↓ Движение вперёд (начать с желаемого будущего для людей и городов)

Снизу вверх:

Открывает возможности (инклюзивный, чуткий, искренний, открытый, честный).

Вдохновляет (ожидаемый, эмоционально умный, лёгкий, рациональный, полезный).

Возвышает (магический, значимый, ценный, радостный).

Начинаем с «идеала» и движемся назад

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

  • Как нам лучше понять, где находится пассажир?
  • Как сформировать план встречи водителя и пассажира, который минимизирует затраченные усилия и сэкономит время?
  • Как полностью избавиться от карты?
  • Как лучше адаптироваться к динамической природе городов и людских ошибок?

Неточный > Точный; Нерациональный > Оптимальный; Неясный > Очевидный; Неизменяемый > Гибкий.

От неточного к точному: как лучше понять, где находится пассажир

Главная причина проблем с заказом такси Uber была в том, что успешность заказа сильно зависела от способности пассажира конкретно указать место, откуда его нужно забрать. Если этого не сделать, водителя отправят по адресу автоматически определённого местоположения устройства, а это в половине случаев совсем другое место.

По нашим данным:

  • 50% пассажиров во всём мире не указывают конкретно, откуда их забрать.
  • Половина всех сессий неточные по меньшей мере на 100 метров.
  • В 45% сессий точность GPS улучшается к моменту запроса. Мы ничего не делаем с этой информацией.

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

  • Перестать полагаться на пассажира, когда нужно указать, откуда его забрать. Сделать эту часть работы за пассажира.
  • Дать GPS больше времени на «разогрев».
  • Как можно дольше извлекать пользу из обновлений GPS.

Начинаем с конца

Чтобы оптимизировать процесс заказа такси, нам нужно было знать только одно — куда пассажир едет.

Без особых споров все члены команды согласились, что вопрос «Куда поедем?» при запуске приложения соответствовал желаниям пассажира. Он был полезен и тем, что давал новые преимущества: сообщить пользователю предварительный тариф, указать ожидаемое время прибытия и дать больше времени на «разогрев» GPS устройства, что шло на пользу всему процессу.

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

Снижаем риски новой схемы

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

Чтобы снизить предполагавшиеся риски, мы объехали Бангалор, Дели, Ахмадабад, Гуанчжоу и Шанхай, где протестировали первый прототип дизайна.

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

Живые локации

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

Вместо того, чтобы зафиксировать местоположение пассажира после запуска приложения (примерно 12-15 секунд для точного определения), приложение продолжает поиск, асинхронно обновляясь, пока обновляется GPS. Наиболее точно местоположение по GPS определяется в самый последний момент — в момент запроса такси.

Это потребовало большой перемены в самом процессе заказа. Задача изменилась с «укажите, откуда вас забрать» на «куда и как вы хотите добраться?»

Экран подтверждения должен внушать уверенность

Если теперь Uber взял всю «тяжёлую» часть работы на себя, то экран подтверждения заказа должен был внушить пассажиру уверенность в том, что его заберут без проблем, и приложение об этом позаботится.

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

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

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

Беспокойство усложняет дизайн

Целью этих вариантов дизайна было показать точность местоположения по GPS, как только оно определится. Я предположил, что открытость — ключ к доверию пассажиров. Однако, тестируя разные варианты дизайна, мы снова и снова наблюдали следующее:

  • Пассажиры в основном не понимали, что приложение некоторое время «колеблется» при поиске их местоположения, а потом устраняет эту неопределённость.
  • Пассажиры считали, что приложение знает их местоположение, и не проверяли его.

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

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

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

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

Система должна была стать достаточно умной, чтобы просто работать, когда может, и достаточно скромной, чтобы в её работу можно было вмешаться, когда она не справляется. Эта система (адаптация) однозначно была самой сложной задачей этого проекта.

Основополагающими для схемы адаптации были следующие идеи:

  • Такой показатель, как степень уверенности, должен был определять, выбрать ли место за пользователя или устранить неопределённость его местоположения. Как рассчитать эту уверенность — это стало бы текущим проектом для доработки.
  • Нужно уважать свободу воли пассажира. Элементы дизайна должны были позволять пассажиру согласиться, отказаться или взять полный контроль на себя.
  • Система должна была стать достаточно гибкой, чтобы знать о выборе пассажира. Нельзя разрабатывать дизайн, основываясь на предположении, что нам будет известен верный ответ.

Умный выбор пункта отправления

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

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

Адаптация — гибкая архитектура

Я разработал систему, основанную на степени уверенности в местоположении пассажира. Если Uber уверен в том, где находится пассажир, он берёт всю работу на себя. В противном случае приложение просит пассажира подтвердить его местоположение.

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

От неясного к очевидному: интуитивное описание местоположения

Для успешной встречи пассажира и водителя важно, чтобы они чётко представляли себе, где должны встретиться и как туда добраться. Существующее приложение Uber плохо поддерживало ориентирование, полагаясь в основном на адрес и карту.

Во время нашей исследовательской поездки в Индию мы увидели много проблем с ориентированием. Из-за ограниченного числа уличных указателей, интенсивного движения на дорогах и тротуарах, а также низкой точности GPS пассажиры и водители использовали достопримечательности, чтобы согласовать место отправления (что бы ни было указано в приложении).

Мы обнаружили, что их общение строилось на структурных шаблонах, что и вдохновило нас на создание функции Geotalker.

«Я перед (положение в пространстве) Ситибанком (место) на MG Road (устраняет неоднозначность) рядом с Forum Mall (локация-якорь)»

Geotalker

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

Я начал с создания концепт-модели для поиска пути и ориентации в пространстве. Это помогло мне прийти к мысли, что объекты городской среды могли быть более или менее «заметными» с точки зрения пассажира или водителя.

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

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

Geotalker снизил неопределённость места отправления

Первые эксперименты показали, что расстояние между запрошенным и реальным пунктом отправления существенно уменьшилась, а частота выхода на связь (созвоны) снизилась. Мы решили, что Geotalker помог уменьшить неопределённость места отправления.

Этого было достаточно, чтобы использовать идею в редизайне.

Запуск: самое радикальное обновление с 2012 года

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

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

Эффект: позитивные результаты и задачи на будущее

Редизайн приложения Uber для iOS и Android позитивно повлиял на процесс заказ такси к моменту написания этой статьи (спустя три месяца после запуска).

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

  • Ошибочное расстояние между запрашиваемым и реальным местом отправления уменьшилось на 34%.
  • Время ожидания водителя уменьшилось на 20%.
  • Показатель точного определения места отправления вырос на 17%.
  • Частота многократного выхода на связь снизилась на 3%.

Для соблюдения конфиденциальности я опустил реальные значения этих метрик.

Автор: Саймон Пан, дизайнер

Перевод: Skyeng


Report Page