Проектирование автономных агентов представляет собой уникальное разочарование. Мы передаем ИИ сложную задачу, он пропадает на 30 секунд (или 30 минут), а потом возвращается с результатом. Мы смотрим на экран. Это сработало? Это были галлюцинации? Проверил ли он базу данных соответствия или пропустил этот шаг? Обычно мы реагируем на это беспокойство одной из двух крайностей. Мы либо сохраняем систему как черный ящик, скрывая все для сохранения простоты, либо паникуем и предоставляем дамп данных, передавая пользователю каждую строку журнала и вызов API. Ни один из подходов напрямую не учитывает нюансы, необходимые для предоставления пользователям идеального уровня прозрачности. Черный ящик заставляет пользователей чувствовать себя бессильными. Дамп данных создает слепоту к уведомлениям, разрушая эффективность, которую обещал обеспечить агент. Пользователи игнорируют постоянный поток информации до тех пор, пока что-то не сломается, и в этот момент у них не хватает контекста, чтобы это исправить. Нам нужен организованный способ найти баланс. В моей предыдущей статье «Проектирование агентного ИИ» мы рассмотрели элементы интерфейса, которые повышают доверие, например, предварительное отображение предполагаемых действий ИИ (предварительный просмотр намерений) и предоставление пользователям контроля над тем, сколько ИИ делает самостоятельно (шкалы автономии). Но знать, какие элементы использовать, — это только часть проблемы. Более сложный вопрос для дизайнеров — знать, когда их использовать. Как узнать, какой конкретный момент 30-секундного рабочего процесса требует предварительного просмотра намерения, а какой можно обработать с помощью простой записи в журнале? В этой статье представлен способ ответить на этот вопрос. Мы пройдем аудит узла принятия решений. Этот процесс позволяет дизайнерам и инженерам находиться в одной комнате, чтобы сопоставить внутреннюю логику с пользовательским интерфейсом. Вы узнаете, как точно определить моменты, когда пользователю нужна обновленная информация о том, что делает ИИ. Мы также рассмотрим матрицу воздействия/риска, которая поможет расставить приоритеты, какие узлы решений отображать, и любой связанный шаблон проектирования, который будет сочетаться с этим решением. Моменты прозрачности: пример тематического исследования Возьмем, к примеру, Meridian (имя изменено), страховую компанию, которая использует агентный искусственный интеллект для обработки первоначальных претензий в результате несчастных случаев. Пользователь загружает фотографии повреждений автомобиля и протокол полиции. Затем агент исчезает на минуту, а затем возвращается с оценкой риска и предлагаемым диапазоном выплат. Первоначально в интерфейсе Meridian просто отображался расчет статуса претензии. Пользователи разочаровались. Они представили несколько подробных документов и не были уверены в том, что МА вообще рассмотрела полицейский отчет, в котором содержались смягчающие обстоятельства. Черный ящик породил недоверие. Чтобы исправить это, команда разработчиков провела аудит узла принятия решений. Они обнаружили, что ИИ выполнил три отдельных, основанных на вероятности шага, в которые было встроено множество более мелких шагов:
Анализ изображенийАгент сравнил фотографии повреждений с базой данных типичных сценариев автомобильных аварий, чтобы оценить стоимость ремонта. Это включало оценку уверенности. Textual ReviewIt просканировал полицейский отчет на предмет ключевых слов, влияющих на ответственность (например, вина, погодные условия, трезвость). Это включало оценку вероятности правового статуса. Перекрестная ссылка на политикуОн сопоставлял детали претензии с конкретными условиями политики пользователя, осуществляя поиск исключений или ограничений покрытия. Это также включало вероятностное сопоставление.
Команда превратила эти шаги в моменты прозрачности. Последовательность интерфейса была обновлена:
Оценка фотографий повреждений: сравнение с 500 профилями ударов транспортных средств. Рассмотрение полицейского отчета: анализ ключевых слов об ответственности и правового прецедента. Проверка покрытия полиса: проверка наличия конкретных исключений в вашем плане.
Система по-прежнему занимала то же время, но подробное информирование о внутренней работе агента восстановило доверие пользователей. Пользователи понимали, что ИИ выполняет сложную задачу, для которой он был разработан, и точно знали, на чем сосредоточить свое внимание, если окончательная оценка показалась неточной. Этот выбор дизайна превратил момент беспокойства в момент связи с пользователем. Применение матрицы воздействия/риска: что мы решили скрыть В большинстве случаев искусственного интеллекта нет недостатка в событиях и узлах принятия решений, которые потенциально могут отображаться во время обработки. Одним из наиболее важных результатов аудита было решение о том, что следует оставить невидимым. В примере с Меридианом серверные журналы генерировали более 50 событий на заявку. Мы могли бы по умолчанию отображать каждое событие по мере его обработки как часть пользовательского интерфейса. Вместо этого мы применили матрицу рисков, чтобы сократить их:
Событие журнала: проверка связи с серверомЗапад-2 для проверки резервирования. Вердикт фильтра: Скрыть. (Низкие ставки, высокая техничность).
Событие журнала: сравнение оценки ремонта со значением BlueBook. Вердикт фильтра: Показать. (Высокие ставки влияют на выплаты пользователя).
За счет исключения ненужных деталей важная информация, например проверка покрытия, стала более эффективной. Мы создали открытый интерфейс и разработали открытый опыт. В этом подходе используется идея о том, что люди чувствуют себя лучше, когда видят, как выполняется работа. Показывая конкретные шаги (оценка, анализ, проверка), мы заменили 30-секундное ожидание с момента беспокойства («Оно сломано?») на время ощущения, будто создается что-то ценное («Он думает»). Давайте теперь подробнее рассмотрим, как мы можем проанализировать процесс принятия решений в наших продуктах, чтобы выявить ключевые моменты, требующие четкой информации. Аудит узла принятия решений Прозрачность терпит неудачу, когда мы рассматриваем ее как выбор стиля, а не как функциональное требование. У нас есть тенденция спрашивать: «Как должен выглядеть пользовательский интерфейс?» прежде чем мы спросим: «Что на самом деле решает агент?» Аудит узла принятия решений — это простой способ облегчить понимание систем искусственного интеллекта. Он работает путем тщательного планирования внутренних процессов системы. Основная цель — найти и четко определить точные моменты, когда система перестает следовать установленным правилам и вместо этого делает выбор, основанный на случайности или оценке. Сопоставляя эту структуру, создатели могут показать эти точки неопределенности непосредственно людям, использующим систему. Это превращает системные обновления из расплывчатых утверждений в конкретные, достоверные отчеты о том, как ИИ пришел к своему выводу. Помимо приведенного выше исследования страхового случая, я недавно работал с командой, формирующей агента по закупкам. Система проверяла контракты с поставщиками и отмечала риски. Первоначально на экране отображался простой индикатор выполнения: «Просмотр контрактов». Пользователи это возненавидели. Наше исследование показало, что они обеспокоены юридическими последствиями отсутствующего пункта. Мы исправили это, проведя аудит узла принятия решений. В заключение этой статьи я включил пошаговый контрольный список для проведения этого аудита. Мы провели беседу с инженерами и рассказали, как работает система. Мы определили «точки принятия решения» — моменты, когда ИИ должен был выбирать между двумя хорошими вариантами. В стандартных компьютерных программах процесс ясен: если произойдет А, то всегда произойдет Б. В системах искусственного интеллекта этот процесс часто основан на случайности. ИИ считает, что А, вероятно, лучший выбор, но вероятность этого может быть только 65%. В контрактной системе мы нашли момент, когда ИИ сверял условия ответственности с правилами нашей компании. Это редко было идеальное совпадение. ИИ должен был решить, достаточно ли совпадения на 90%. Это был ключевой момент принятия решения.
Как только мы определили этот узел, мы предоставили его пользователю. Вместо «Просмотра контрактов» в интерфейсе появилось сообщение: «Условие об ответственности отличается от стандартного шаблона. Анализ уровня риска». Это конкретное обновление вселило в пользователей уверенность. Они знали, что агент проверил пункт об ответственности. Они поняли причину задержки и убедились, что желаемое действие происходит на сервере. Они также знали, где копнуть глубже, как только агент подготовил контракт. Чтобы проверить, как ИИ принимает решения, вам необходимо тесно сотрудничать со своими инженерами, менеджерами по продуктам, бизнес-аналитиками и ключевыми людьми, которые делают выбор (часто скрытый), влияющий на функционирование инструмента ИИ. Нарисуйте шаги, которые выполняет инструмент. Отметьте каждое место, где процесс меняет направление из-за реализации вероятности. Это те места, где вам следует сосредоточиться на большей прозрачности. Как показано на рисунке 2 ниже, аудит узла принятия решений включает в себя следующие этапы:
Соберите команду: привлеките владельцев продуктов, бизнес-аналитиков, дизайнеров, ключевых лиц, принимающих решения, и инженеров, создавших ИИ. Например, Подумайте о команде разработчиков, создающей инструмент искусственного интеллекта, предназначенный для проверки запутанных юридических контрактов. В команду входят UX-дизайнер, менеджер по продукту, UX-исследователь, практикующий юрист, выступающий в роли профильного эксперта, и бэкенд-инженер, написавший код для анализа текста.
Нарисуйте весь процесс: документируйте каждый шаг, который делает ИИ, от первого действия пользователя до конечного результата. Команда стоит у доски и рисует всю последовательность ключевого рабочего процесса, в котором ИИ ищет пункт об ответственности в сложном контракте. Адвокат загружаетPDF-файл на пятьдесят страниц → Система преобразует документ в читаемый текст. → ИИ сканирует страницы на предмет положений об ответственности. → Пользователь ждет. → Спустя несколько мгновений или минут инструмент выделяет найденные абзацы желтым цветом в пользовательском интерфейсе. Они делают это для многих других рабочих процессов, которые также поддерживает этот инструмент.
Найдите места, где что-то неясно: посмотрите на карту процесса на предмет любого места, где ИИ сравнивает варианты или входные данные, которые не имеют ни одного идеального совпадения. Команда смотрит на доску, чтобы обнаружить неоднозначные шаги. Преобразование изображения в текст следует строгим правилам. Поиск конкретного пункта об ответственности требует догадок. Каждая фирма пишет эти положения по-своему, поэтому ИИ приходится взвешивать несколько вариантов и делать прогнозы, а не находить точное совпадение слов.
Определите шаги «наилучшего предположения». Для каждого неясного места проверьте, использует ли система показатель достоверности (например, уверен ли он на 85 %?). Это моменты, когда ИИ делает окончательный выбор. Система должна угадать (дать вероятность), какой параграф(ы) очень похож на стандартное положение об ответственности. Он присваивает оценку достоверности своему лучшему предположению. Это предположение является узлом принятия решения. Интерфейс должен сообщать юристу, что он выделяет потенциальное совпадение, а не констатирует, что найдено окончательное предложение.
Изучите выбор: для каждого пункта выбора выясните конкретную внутреннюю математику или сравнение (например, сопоставление части контракта с полисом или сравнение изображения сломанной машины с библиотекой фотографий поврежденных автомобилей). Инженер объясняет, что система сравнивает различные параграфы с базой данных стандартных положений об ответственности из прошлых судебных дел. Он вычисляет показатель сходства текста, чтобы принять решение о совпадении на основе вероятностей.
Напишите четкие объяснения: создавайте сообщения для пользователя, которые четко описывают конкретное внутреннее действие, происходящее, когда ИИ делает выбор. Контент-дизайнер пишет конкретное сообщение именно для этого момента. Текст гласит: Сравнение текста документа со стандартными твердыми положениями для выявления потенциальных рисков ответственности.
Обновите экран: поместите эти новые, четкие пояснения в пользовательский интерфейс, заменив расплывчатые сообщения типа «Просмотр контрактов». Команда разработчиков удалила стандартный индикатор загрузки PDF-файлов «Обработка». Они вставляют новое объяснение в строку состояния, расположенную прямо над средством просмотра документов, пока ИИ думает.
Проверьте доверие. Убедитесь, что новые сообщения на экране дают пользователям простую причину любого времени ожидания или результата, что должно заставить их чувствовать себя более уверенно и доверчиво.
Матрица воздействия/риска Если вы внимательно посмотрите на процесс ИИ, вы, скорее всего, обнаружите множество моментов, в которых он делает выбор. ИИ может сделать десятки мелких решений для одной сложной задачи. Показ их всех создает слишком много ненужной информации. Вам нужно сгруппировать эти варианты. Вы можете использовать матрицу воздействия/риска, чтобы отсортировать эти варианты в зависимости от типов действий, которые предпринимает ИИ. Вот примеры матриц воздействия/риска: Во-первых, ищите решения с низкими ставками и низкими последствиями. Низкие ставки/низкое воздействие
Пример: организация файловой структуры или переименование документа. Потребность в прозрачности: минимальная. Достаточно незаметного всплывающего уведомления или записи в журнале. Пользователи могут легко отменить эти действия.
Затем определите важные решения и важные решения. Высокие ставки/большое влияние
Пример: отклонение заявки на получение кредита или совершение сделки с акциями. Потребность в прозрачности: высокая. Эти действия требуют доказательства работы. Система должна продемонстрировать обоснование до или сразу же в ходе действия.
Рассмотрим финансового торгового бота, который одинаково обрабатывает все ордера на покупку/продажу. Он совершает сделку на 5 долларов с той же непрозрачностью, что и сделка на 50 000 долларов. Пользователи могут задаться вопросом, учитывает ли инструмент потенциальное влияние прозрачности на торговлю на большие суммы в долларах. Им нужно, чтобы система сделала паузу и продемонстрировала свою работу в сделках с высокими ставками. Решение состоит в том, чтобы ввести состояние логики проверки для любой транзакции, превышающей определенную сумму в долларах, что позволяет пользователю видеть факторы, влияющие на решение, перед его выполнением. Сопоставление узлов с шаблонами: рубрика выбора шаблона проектирования После того как вы определили ключевые узлы принятия решений, вы должны решить, какой шаблон пользовательского интерфейса применим к каждому из них, который вы будете отображать. В разделе «Проектирование агентного ИИ» мы представили такие шаблоны, как предварительный просмотр намерения (для контроля важных задач) и аудит действий (для ретроспективной безопасности). Решающим фактором при выборе между ними является обратимость. Мы фильтруем каждыйузел принятия решения через матрицу воздействия, чтобы назначить правильный шаблон: Высокие ставки и необратимость: эти узлы требуют предварительной проверки намерения. Поскольку пользователь не может легко отменить действие (например, окончательное удаление базы данных), момент прозрачности должен наступить перед выполнением. Система должна сделать паузу, объяснить свое намерение и потребовать подтверждения. Высокие ставки и обратимость: эти узлы могут полагаться на шаблон Action Audit & Undo. Если торговый агент с помощью искусственного интеллекта перемещает лида в другой конвейер, он может сделать это автономно, если уведомит пользователя и предложит немедленную кнопку «Отменить». Строго классифицируя узлы таким образом, мы избегаем «усталости от оповещений». Мы оставляем предварительный просмотр намерений с высокими требованиями только для действительно необратимых моментов, полагаясь при этом на аудит действий, чтобы поддерживать скорость во всем остальном.
Двусторонний необратимый Низкое воздействие Тип: Auto-ExecuteUI: пассивное всплывающее уведомление/LogEx: переименование файла Тип: ConfirmUI: Простая опция отмены. Пример: Архивирование электронной почты. Высокое воздействие Тип: ReviewUI: Уведомление + Обзор TrailEx: Отправка черновика клиенту. Тип: Предварительный просмотр намеренияUI: Модальное/явное разрешениеEx: Удаление сервера
Таблица 1. Матрицу воздействия и обратимости можно затем использовать для сопоставления моментов прозрачности с шаблонами проектирования. Качественная валидация: «Ожидание, почему?» Тест Вы можете идентифицировать потенциальные узлы на доске, но вы должны подтвердить их поведением человека. Вам необходимо проверить, соответствует ли ваша карта ментальной модели пользователя. Я использую протокол под названием «Подожди, почему?» Тест. Попросите пользователя посмотреть, как агент выполняет задачу. Попросите их говорить вслух. Всякий раз, когда они задают вопрос: «Подожди, почему он это сделал?» или «Он застрял?» или «Оно меня услышало?» — вы отмечаете временную метку. Эти вопросы сигнализируют о замешательстве пользователя. Пользователь чувствует, что его контроль ускользает. Например, в исследовании помощника по планированию медицинского обслуживания пользователи наблюдали, как агент записывался на прием. Экран оставался неподвижным четыре секунды. Участники постоянно спрашивали: «Он проверяет мой календарь или календарь врача?»
Этот вопрос выявил отсутствие Момента Прозрачности. Системе необходимо было разделить это четырехсекундное ожидание на два отдельных этапа: «Проверка доступности», а затем «Синхронизация с расписанием провайдера». Это небольшое изменение снизило выраженный уровень беспокойства пользователей. Прозрачность терпит неудачу, когда она описывает только действие системы. Интерфейс должен связывать технический процесс с конкретной целью пользователя. Экран с надписью «Проверка доступности» не работает, потому что ему не хватает контекста. Пользователь понимает, что ИИ смотрит на календарь, но не знает почему. Мы должны сопоставить действие с результатом. Системе необходимо разделить это четырехсекундное ожидание на два отдельных этапа. Сначала в интерфейсе отображается сообщение «Проверяем календарь, чтобы узнать время работы». Затем он обновляется до «Синхронизация с расписанием поставщика услуг для обеспечения вашей встречи». Это обосновывает технический процесс в реальной жизни пользователя. Рассмотрим ИИ, управляющий запасами в местном кафе. Система сталкивается с нехваткой поставок. Интерфейс с надписью «связаться с поставщиком» или «рассмотреть варианты» вызывает беспокойство. Менеджер задается вопросом, отменяет ли система заказ или покупает дорогую альтернативу. Лучший подход — объяснить предполагаемый результат: «Оценка альтернативных поставщиков для соблюдения графика поставок по пятницам». Это сообщает пользователю, чего именно пытается достичь ИИ. Проведение аудита Вы завершили аудит узла принятия решений и отфильтровали свой список с помощью матрицы воздействия и рисков. Теперь у вас есть список важных моментов для обеспечения прозрачности. Далее вам нужно создать их в пользовательском интерфейсе. Этот шаг требует совместной работы разных отделов. Вы не можете создать прозрачность самостоятельно, используя инструмент дизайна. Вам необходимо понимать, как система работает за кулисами. Начните с логического обзора. Встретьтесь со своим ведущим проектировщиком системы. Принесите свою карту узлов принятия решений. Вам необходимо подтвердить, что система действительно может использовать эти состояния. Я часто обнаруживаю, что техническая система не отображает именно то состояние, которое я хочу показать. Инженер может сказать, что система просто возвращает общее «рабочее» состояние. Вы должны настаивать на подробном обновлении. Вам нужна система для отправки конкретного уведомлениякогда он переключается с чтения текста на проверку правил. Без этой технической связи ваш проект невозможно построить. Затем привлеките команду дизайнеров контента. У вас есть техническая причина действий ИИ, но вам нужно четкое, понятное для человека объяснение. Инженеры обеспечивают базовый процесс, а дизайнеры контента обеспечивают способ его передачи. Не пишите эти сообщения в одиночку. Разработчик может написать «Выполнение функции 402», что технически правильно, но бессмысленно для пользователя. Дизайнер может написать «Мышление» — дружелюбно, но слишком расплывчато. Контент-стратег находит правильную золотую середину. Они создают специальные фразы, такие как «Сканирование рисков ответственности», которые показывают, что ИИ работает, не сбивая пользователя с толку. Наконец, проверьте прозрачность ваших сообщений. Не ждите, пока будет создан конечный продукт, чтобы проверить, работает ли текст. Я провожу сравнительные тесты на простых прототипах, где меняется только сообщение о состоянии. Например, я показываю одной группе (группа А) сообщение с надписью «Проверка личности», а другой группе (группа Б) сообщение с надписью «Проверка государственных баз данных» (это вымышленные примеры, но суть вы понимаете). Затем я спрашиваю их, какой ИИ чувствует себя безопаснее. Вы часто обнаружите, что одни слова вызывают беспокойство, а другие вызывают доверие. Вы должны относиться к этой формулировке как к чему-то, что вам нужно проверить и доказать ее эффективность. Как это меняет процесс проектирования Проведение таких аудитов может улучшить совместную работу команды. Мы перестаем раздавать отточенные файлы дизайна. Мы начинаем использовать беспорядочные прототипы и общие таблицы. Основным инструментом становится матрица прозрачности. Инженеры и дизайнеры контента редактируют эту таблицу вместе. Они сопоставляют точные технические коды со словами, которые будет читать пользователь. Во время проверки логики команды будут испытывать разногласия. Представьте себе, что дизайнер спрашивает инженера, как ИИ решает отклонить транзакцию, представленную в отчете о расходах. Инженер может сказать, что серверная часть выводит только общий код состояния, например «Ошибка: отсутствуют данные». Дизайнер утверждает, что на экране это недействительная информация. Дизайнер договаривается с инженером о создании конкретной технической зацепки. Инженер пишет новое правило, чтобы система сообщала именно о том, чего не хватает, например об отсутствующем изображении квитанции. Контент-дизайнеры выступают в роли переводчиков на этом этапе. Разработчик может написать технически точную строку, например «Расчет порога достоверности для сопоставления поставщиков». Дизайнер контента переводит эту строку во фразу, которая вызывает доверие к конкретному результату. Стратег переписывает это как «Сравнение цен местных поставщиков, чтобы обеспечить доставку в пятницу». Пользователь понимает действие и результат. Вся межфункциональная команда участвует в сеансах пользовательского тестирования. Они наблюдают, как реальный человек реагирует на различные статусные сообщения. Паника пользователей из-за того, что на экране написано «Выполнение сделки», заставляет команду переосмыслить свой подход. Инженеры и дизайнеры пришли к единому мнению по поводу более удачной формулировки. Перед покупкой акций они меняют текст на «Проверка достаточных средств». Совместное тестирование гарантирует, что окончательный интерфейс будет соответствовать как системной логике, так и душевному спокойствию пользователя. Требуется время, чтобы включить эти дополнительные мероприятия в календарь команды. Однако конечным результатом должна стать команда, которая общается более открыто, и пользователи, которые лучше понимают, что их инструменты на базе искусственного интеллекта делают от их имени (и почему). Этот интегрированный подход является краеугольным камнем разработки действительно заслуживающих доверия решений в области искусственного интеллекта. Доверие — это выбор дизайна Мы часто рассматриваем доверие как эмоциональный побочный продукт хорошего пользовательского опыта. Легче рассматривать доверие как механический результат предсказуемого общения. Мы укрепляем доверие, показывая нужную информацию в нужное время. Мы уничтожаем его, подавляя пользователя или полностью скрывая оборудование. Начните с аудита узла принятия решений, особенно для агентных инструментов и продуктов искусственного интеллекта. Найдите моменты, когда система принимает решение. Сопоставьте эти моменты с матрицей рисков. Если ставки высоки, откройте коробку. Покажите работу. В следующей статье мы рассмотрим, как спроектировать эти моменты: как написать текст, структурировать пользовательский интерфейс и справиться с неизбежными ошибками, когда агент ошибается. Приложение: Контрольный список аудита узла принятия решений Этап 1: Настройка и сопоставление ✅ Соберите команду: пригласите владельцев продуктов, бизнес-аналитиков, дизайнеров,ключевые лица, принимающие решения, и инженеры, создавшие ИИ. Подсказка: вам нужны инженеры, чтобы объяснить реальную логику серверной части. Не пытайтесь выполнить этот шаг в одиночку. ✅ Нарисуйте весь процесс: документируйте каждый шаг, который делает ИИ, от первого действия пользователя до конечного результата. Подсказка: физический сеанс работы с доской часто лучше всего подходит для рисования этих начальных шагов. Этап 2: Обнаружение скрытой логики ✅ Найдите места, где что-то неясно: посмотрите на карту процесса на предмет любого места, где ИИ сравнивает варианты или входные данные, которые не имеют ни одного идеального совпадения. ✅ Определите наилучшие шаги предположения: для каждого неясного места проверьте, использует ли система оценку достоверности. Например, спросите, уверена ли система на 85 процентов. Это моменты, когда ИИ делает окончательный выбор. ✅ Изучите выбор: для каждого пункта выбора выясните конкретную внутреннюю математику или сравнение. Примером является сопоставление части контракта с политикой. Другой пример предполагает сравнение фотографии сломанной машины с библиотекой фотографий поврежденных машин. Этап 3: Создание пользовательского опыта ✅ Напишите четкие объяснения: создавайте сообщения для пользователя, которые четко описывают конкретное внутреннее действие, происходящее, когда ИИ делает выбор. Подсказка: обосновывайте свои сообщения конкретной реальностью. Если ИИ назначает встречу с клиентом в местном кафе, сообщите пользователю, что система проверяет систему бронирования кафе. ✅ Обновите экран: поместите эти новые, понятные объяснения в пользовательский интерфейс. Замените расплывчатые сообщения, такие как «Просмотр контрактов», своими конкретными пояснениями. ✅ Проверьте доверие. Убедитесь, что новые сообщения на экране дают пользователям простую причину времени ожидания или результата. Это должно вселить в них уверенность и доверие. Подсказка: протестируйте эти сообщения на реальных пользователях, чтобы убедиться, что они понимают конкретный желаемый результат.
