12 ноября — Всемирный день юзабилити. В этом году организаторы предложили тему Designing a Sustainable Future with Ethical AI — проектирование устойчивого будущего с этичным использованием искусственного интеллекта. Для меня это повод посмотреть на собственные сервисы глазами человека, который открыл их впервые. Официальный сайт Всемирного дня юзабилити.
Что случилось после нажатия
Когда сам пишешь сервис, легко мысленно дополнять интерфейс знанием о его устройстве. Я знаю, что кнопка поставила задачу в очередь и обработчик возьмёт её позже. Человек видит кнопку, нажимает и ждёт понятного результата.
Поэтому мне полезно проходить простой сценарий целиком. Опубликовать запись, проверить, куда ушёл анонс, и разобраться с ошибкой, если она возникла. На каждом шаге нужен ответ на практический вопрос. Что сейчас происходит? Где посмотреть результат? Как исправить сбой?
Пример из ThreadTandem
В ThreadTandem статья может уже быть опубликована в WordPress, а анонс ещё ждать отправки в Telegram. В редакторе есть отдельный переключатель для отправки, а на странице диагностики видна очередь. Эти элементы отвечают за разные моменты одного сценария — выбор автора и результат доставки.
Самый показательный случай возникает при тайм-ауте. Telegram мог принять сообщение, пока сайт ждал ответа. Если автоматически повторить отправку, в канале могут появиться два анонса. Поэтому в плагине есть отдельный статус «Результат неизвестен». Автор может проверить канал и решить, нужна ли повторная попытка. Подробнее о ThreadTandem.
Те же вопросы к AI
Когда в сервисе появляется AI, человеку нужно видеть, какую часть работы система выполнила и на что опиралась. Если помощник предлагает заголовок и отрывок для статьи, я хочу видеть оба текста до публикации и иметь возможность поправить любой из них.
Я бы проверял такой сценарий на обычных задачах. Можно ли понять предложение с первого раза? Где исправить ошибку? Какие данные нужны помощнику для этой операции? Кто подтверждает отправку? Особенно важно, чтобы человек мог продолжить работу, когда результат модели оказался спорным.
Проверка на незнакомом сценарии
Для собственных проектов хочу чаще проверять интерфейс с позиции новичка. Открыть экран с телефона. Дать человеку одну задачу без объяснения кнопок. Посмотреть, где он остановился и какой информации ему не хватило. Иногда полезнее переписать название статуса или перенести ссылку ближе к результату, чем добавлять ещё один экран настроек.
Хорошая проверка для меня — попросить автора опубликовать запись и найти её анонс. По тому, где он задержится, уже можно выбрать следующую доработку.