Внедрить искусственный интеллект в дизайн приложения ресторана

Перевод материала разработчика Хаммада Махбуба.

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

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

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

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

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

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

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

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

Ситуация становится понятнее, если посмотреть на бизнес-модели компаний, которые занимаются доставкой еды. В большинстве случаев сервисы построены на линейных транзакциях. И с покупателей, и с продавцов берётся комиссия, которая в общей сложности может составлять 60% от заказа (обычно в соотношении 50 на 50, за исключением сервиса Doordash), что составляет 75-80% текущих доходов (как в случае с Just-Eat, GrubHub).

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

• Ресторан, где пользователь сделал заказ в прошлый раз, размещается в самом верху. А также добавлена возможность в один клик повторить предыдущий заказ.
• Использование технологии совместной фильтрации (и других техник машинного обучения) для обнаружения пользователей с похожей историей покупок (конкретные блюда, рестораны).
• Заключение партнёрского соглашения с сетью ресторанов, чтобы поддерживать постоянный спрос и предложение. Этот метод популяризировали сервисы GrubHub и Seamless в конце 2000-х годов, а сегодня реализован в Doordash и Uber Eats.
• Взимание платы с продавца за повышение его рейтинга в списке ресторанов.
• Геймификация — чаще всего используется в программах лояльности.
• Создание визуально более привлекательной рекламы и предложений, чем у соседей по списку.
• Появление «наиболее популярных» блюд в начале списка.

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

Допустим, бизнес-цели, затрагивающие ИИ, достаточно простые. Если давать много качественной рекламы — люди будут делать заказы. Собранные данные это покажут. Но как UI и UX могут повлиять на то, чему научится ИИ? Чтобы объяснить это, нужно сначала посмотреть, как мы выбираем еду без приложения.

Достаточно бегло взглянуть, чтобы понять, что все эти меню подобраны с учётом различной аудитории. Но при всём разнообразии меню люди почти всегда полагаются на одно и то же:

• Личный вкус и предпочтения.
• Что показалось знакомым в меню.
• Общая стоимость, впишется ли это в бюджет на месяц.
• Любая ограничивающая диета или проблемы со здоровьем покупателя (диабет, артериальное давление, аллергия и так далее).
• Закончится ли на каком-либо блюде диета.
• Хочет ли покупатель чего-то холодного и освежающего в жаркий летний день или, наоборот, чего-то согревающего в зимние месяцы.
• Какой напиток будет лучше всего сочетаться с выбранной едой.
• Покупатель в компании других людей. Он не только принимает во внимание всё вышеперечисленное, но и то, какое блюдо можно разделить в группе, какова аудитория, ситуация и так далее.

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

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

Почти все приложения делают одно и то же. Они предлагают одинаковые базовые элементы с несущественными отличиями:

• основная страница;
• предложение дня, реклама;
• поиск;
• фильтр;
• напоминание поделиться приложением с друзьями, чтобы получить $5-10 на свой счёт.

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

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

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

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

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

• Uber Eats создает определённые группы внутри ранжированного списка, куда попадают самые популярные блюда в конкретных категориях.
• Doordash отслеживает совпадения по кухне в ресторанах, где пользователь уже заказывал еду, какие рестораны были показаны (какие из них были проигнорировали в прошлом и настоящем), ценовой диапазон, тип еды, размер заказа, сумму заказа, время доставки, данные продавца. Положительные баллы будут присваиваться тем характеристикам, которые есть в вашем заказе, а отрицательные баллы присваиваются тем ресторанам, которые вы увидели и проигнорировали. А затем с помощью технологии машинного обучения будет рассчитана вероятность вашего взаимодействия с любым другим рестораном, с конкретным набором блюд и сервисов (подробнее об этом).
• Другие системы классификации и рекомендаций (дерево принятия решений, совместная фильтрация и так далее).

• Алгоритм используется миллиарды раз в день каждый день во всём: начиная с компрессии MP3-файлов и заканчивая диагностической визуализацией.
• Преимущественно работает, разбивая любые последовательно передаваемые данные, а также данные временного ряда на составляющие синусоиды или косинусоиды.
• Выделяет тренды, сезонные данные, так как повторяющиеся сигналы будут соответствовать всплескам с определённой частотой. Затем это может быть представлено в виде конкретного решения.
• Хоть это и действенный метод, его лучше всего использовать только для всенаправленных и периодически повторяющихся данных.
• Не подходит для новых вводных (погоды, времени дня, спортивных игр) и не может адаптироваться к переменам в состоянии окружающей среды.

Чтобы больше узнать об алгоритме, посмотрите видео от 3blue1brown и презентацию.

• Очевидно, существуют миллиарды способов применить машинное обучение, технологию глубокого обучения, ИИ. Однако то, как платформы собирают данные и что мы хотим предсказать с их помощью, можно описать как проблему временных рядов. Я считаю, что Seq2Seq — модель глубокого обучения от Google как раз для этого подходит.
• Сначала нужно разделить предложение на несколько словосочетаний небольшого размера. Seq2Seq их уже может использовать: преобразовать кусочки информации для единого ввода (input) и со временем понять, какой единый выход (output) — самый правильный, подходящий ответ на любой ввод информации.
• Особый интерес представляет способность Seq2Seq учиться, как переводить фразы с английского на французский, с французского на японский и затем экстраполировать данные на перевод между английским и японским. Больше об использовании и внедрении технологии компанией Google. Подробнее о самой технологии Zero-Shot Learning.
• Мы можем больше, чем просто полагаться на скрытое состояние (hidden state), созданное кодировщиком. Мы можем добавить понятие «внимания» к вводимым данным, позволяя Seq2Seq понимать, что определённые слова (вводимые данные) в предложении (последовательности) имеют большее или меньшее значение и влияют на выходные данные больше остальных. Например, в каком-нибудь предложении значение слова «поживаете» будет выше, чем значение «как» или «вы». Гийом Жантьяль написал об в этом подробнее в своей статье.
• С его помощью можно выбрать гораздо больше нюансов и шаблонов, которые возникают нерегулярно. А также его проще внедрить и учитывать с его помощью погоду, время суток и так далее.

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

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

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

• Мы будем вынуждены присваивать положительные баллы тем блюдам, на которые пользователь нажал, и предполагать, что все другие варианты были хуже.
• Почему пользователь предпочёл одно блюдо другому?
• Что, если пользователь хочет что-то новое, не то, что он выбирает обычно, но это блюдо не было выведено в предложения.
• Пользователь предпочёл комбинацию блюд x-y-z блюдам a-b-c, потому что они ему действительно нравятся, или просто потому, что он не представлял, что такая комбинация была возможна?

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

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

Компания DeepMind внедрила в систему AlphaGo технологии, которые быстро обучались и интуитивно давали решения для абстрактных проблем. Подробнее прочитать об этом в блоге DeepMind.

Меня вдохновил такой подход, ориентированный на цель. Тогда почти не существовало данных в их нынешнем виде, которые подкрепили бы мою идею, но я создал так называемые карточки с блюдом (Meal Cards).

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

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

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

• Три основные ситуации: заказ блюд для ужина в ресторане (из одного меню), заказ еды навынос, доставка.
• Лёгкое переключение между сценариями и тематическими списками.
• Уменьшение шансов на возникновение любой потенциальной «запрограммированности».
• Уменьшение загрузки краткосрочной памяти пользователей.
• Создание интерактивной настройки карточек с блюдами.

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

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

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

«Привет, (имя пользователя)» — приятное и дружелюбное приветствие для приложения. Кликнув на своё имя, вы сможете посмотреть общий обзор (overview). Я подробнее расскажу об этой секции ниже.

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

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

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

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

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

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

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

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

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

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

Так как у нас есть платформа с большим количеством сценариев, — она способна самостоятельно составлять меню. Мы можем больше, чем просто предоставлять краткосрочные рекомендации.

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

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

Почему я не опубликовал дизайн? Я считаю, что лучше передать большую часть этой функциональности централизованным приложениям, которые следят за здоровьем пользователей, будь то Apple, Samsung или Google Health.

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

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

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

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

Я знаю, что у нас уже есть hrecipe — микроформат XHTML-разметки кулинарных рецептов на сайтах. Но что, если бы вы могли зайти на блог о питании, где каждому блюду, на которое сделан обзор, присвоена карточка. И эту карточку вы можете добавить в свои личные рекомендации?

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

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

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

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

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

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

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

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

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

Да, я понимаю, что это исследование не более чем разбор меню для еды. Это простой обзор UI-дизайна или UX-исследования. Может даже хуже — плохая статья в блоге на тему ИИ. Но я считаю, что сейчас самое время сделать шаг назад и убедиться, что мы создаём ИИ, который будет по-настоящему нам служить.

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

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

Но мы видели, как быстро киоски самообслуживания в McDonald’s заменили кассиров-людей. Пройдёт не так уж много времени, и всё заменят на один небольшой, размещённый в центре стола, планшет.

Как бы там ни было, это первая часть — приблизительный обзор проблем и решений, которые мы могли бы внедрить, чтобы улучшить меню. Рад сообщить, что записался на курсы глубокого обучения и искусственного интеллекта на Udacity.com. Пытаясь лучше понять, как работают внутренние механизмы инструментов, которые однажды начнут управлять нашими жизнями.

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

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

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

Если вы нашли у меня ошибки, если у вас есть предложения, вы не поняли о чём я пишу, хотите поздороваться, вы всегда можете написать мне по адресу: [email protected].

Смело скачивайте этот прототип и пробуйте. Я сделал его какое-то время назад — до того, как Framer добавил поддержку всех устройств новее iPhone 6 Plus, поэтому код кажется слегка недоработанным:

• Самое очевидное, что я сделал — наслоил все страницы друг на друга, вместо того, чтобы создавать отдельные страницы для каждого раздела прототипа. Если я правильно помню, основная причина в том, что Framer.js использовал фиксированные движения либо влево, либо в право для перехода между страницами. Я хотел сделать плавный переход между главной страницей и страницей сложного поиска.
• Многоуровневый скроллинг (parallax) определённо выиграл бы от более спланированного подхода с простой математикой и отслеживанием изменений в положении прокрутки, от форматирования фона каждой карточки с едой, а также от одинакового размера карточек и относительно одинаковой позиции.
• Что-то странное происходило при попытке свайпнуть карточку с едой во время скроллинга и после нажатия. Она могла вернуться к своему первоначальному виду, не застряв в той точке, где вы на неё нажали или начали перетаскивать. На самом деле первая карточка до сих пор временно исчезает или прокручивается с разной скоростью. Я думаю, проблема в том, что когда вы нажимаете по карточке или начинаете её легонько двигать, и в то же самое время передвигать экран, начинается возврат к первоначальной анимации.
• И многое другое, что прямо сейчас я не могу вспомнить.

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

Я выпускаю схему, описанную выше, под лицензией CC BY-SA 4.0. Инструменты для её создания, будут выпущены под лицензией GNU GPL v3.0 или похожей, как только у меня будет нормальный исходный код, которым можно будет поделиться.

#дизайн