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

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

Перевод подготовлен командой онлайн-школы английского Skyeng.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снизу вверх:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перевод подготовлен командой онлайн-школы английского Skyeng.

#дизайн