Одного статуса для интерфейса AI-продукта недостаточно

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

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

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

Если свести всё к одному статусу «Можно объединить», интерфейс перестанет различать факт, предложение и результат будущего действия. Для продуктов с AI-функциями это особенно опасно: система умеет находить подходящий вариант, но её рекомендация ещё не означает, что операция уже выполнена.

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

AI появляется внутри существующего интерфейса

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

Похожие механики уже есть в продуктовой доставке. Во ВкусВилле можно открыть оформленный заказ, выбрать «Добавить товары» и подтвердить дозаказ. Если условия объединения соблюдены, покупки привезёт один курьер. А «Самокат» в сентябре 2024 года описывал другой путь: до начала доставки покупатель мог нажать «Изменить заказ», подтвердить отмену и повтор, а затем поправить сохранённый состав корзины. За знакомым словом «изменить» здесь стоит создание нового заказа.

Из зарубежных примеров – DoubleDash у DoorDash. В ограниченное время после оформления можно добавить покупку из другого доступного магазина без второй платы за доставку. При этом сервисный сбор сохраняется, а совместный приезд не гарантирован: иногда покупки доставляют отдельно.

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

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

AI добавляет новый вариант продолжения, но не отменяет состояния, которые существовали до него.

Где нужен AI, а где достаточно правил

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

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

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

Такое разделение полезно зафиксировать ещё до макетов:

• правила определяют, разрешена ли операция;

• AI ищет и ранжирует полезные варианты;

• интерфейс объясняет условия и последствия;

• покупатель выбирает продолжение;

• операционные системы подтверждают и выполняют действие.

AI может найти полезную возможность. Её доступность и выполнение подтверждают системы, которые отвечают за операцию.

Одновременно верны несколько состояний

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

В момент появления предложения интерфейс должен удерживать как минимум такую картину:

Эти состояния нельзя заменить общим «AI подобрал вариант». Покупателю важно понимать, что доставка первого заказа пока не изменена. Новое время ещё не принято. Экономия относится только к одному из вариантов. Вторую корзину можно оформить отдельно.

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

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

Предложение ещё не стало действием

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

Полная цепочка выглядит так:

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

Если проверка не прошла до оформления второго заказа, первая доставка остаётся прежней, а вторая корзина – доступной для отдельного оформления. Если второй заказ уже принят, он остаётся заказом: покупки можно получить раздельно. Интерфейс показывает, что объединение не выполнено, и подтверждённые условия каждой доставки.

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

• когда теперь приедут продукты;

• сколько стоят общая и раздельные доставки;

• что изменится в доставке первого заказа;

• оформлен ли второй заказ;

• можно ли сохранить раздельную доставку или вернуться к ней.

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

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

Согласие запускает действие. Доставка меняется только после подтверждённого выполнения.

Одного макета тоже недостаточно

В Figma-макетах AI-функция часто заканчивается на самом привлекательном состоянии: система нашла возможность и показала персональное предложение. Для реального продукта это только начало работы.

Как минимум нужны три связанных экрана или состояния одного экрана:

1. Предложение. Два варианта доставки, новое время, разница в стоимости и понятный выбор.

2. Проверка и выполнение. Система уточняет доступность объединения, не блокируя доступ к уже подтверждённому заказу.

3. Результат. Подтверждённая общая доставка с условиями её отмены либо ясный статус каждого заказа и доставки, если объединение не выполнено.

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

С чего начать

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

1. Какой объект меняется: заказ, корзина, доставка, платёж или отдельная позиция?

2. Какой источник подтверждает текущее состояние объекта?

3. Что AI предлагает, но ещё не выполнил?

4. Кто владеет следующим шагом: система, человек или сотрудник магазина?

5. Какие последствия выбора нужно показать до подтверждения?

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

Одного статуса для интерфейса AI-продукта недостаточно, когда система одновременно хранит факт, предложение, условие и возможное последствие.