Для того чтобы пользователь достиг ключевых функций продукта, нам необходимо провести его нужной дорогой и чем сложнее будет путь, тем сложнее пользователю будет дойти до главного функционала.
Как облегчить дорогу?
В попытках сделать это, сам того не замечая, в последние годы я начал использовать совсем другую парадигму интерфейсов и как мне кажется главное их преимущество - снижение трений пользователя т.е. снижение Friction. Отсюда и родилось название No Friction UI.
Небольшая ремарка
Сразу хочу обратить ваше внимание — этот паттерн не подходит для тех мест приложения, где важна 100% гарантия точности(банковские переводы, медицина и тд) или когда сопоставление выходит слишком дорогой операцией — например когда данных для сопоставления больше 1 000 000 то нам придется сделать около 5–10 шагов сужения(об этом ниже), а это 10 обращений к ИИ и на каждом шаге мы увеличиваем коэффициент погрешности вычислений. Именно поэтому, я отношу этот паттерн к UI несмотря на использование внешнего API так как в большинстве случаев, по моему мнению, недетерминированный результат работы ИИ при использовании в главных фичах продукта может привести к катастрофическим последствиям для бизнеса и исходя из этого мы используем NF UI лишь для облегчения дороги пользователя к основному функционалу.
Продолжим
Почему я считаю, что использовать NF UI нужно? Конкуренция растет, SaaS растут как грибы после дождя, теперь продукту мало «быть» и решать проблему пользователя тоже мало, ему надо делать это филигранно, оставляя пользователя с мыслями «Хм, а ничего такой сервис». Если у пользователя возникла эта мысль — он ваш. Он вероятно еще друзьям расскажет о вашем продукте, а это — лучшая реклама и потенциальный рост прибыли.
Как готовить NF UI и чего хочет пользователь?
Короткий блиц:
Пользователь хочет получить пользу здесь и сейчас. Желательно с минимальными затратами усилий.
Что является затратой усилий на его пути к получению ценности?
Когнитивная нагрузка. Именно она очень сильно влияет на то, дойдет ли пользователь до ценности или нет.
Как снизить когнитивную нагрузку?
Снизить «трение».
Что создает трение?
Вопросы. Чем больше вы задаете пользователю вопросов — тем выше его когнитивная нагрузка, тем сложнее и хуже он ощущает ваше приложение. Модальные окна, селекты, чекбоксы, варианты ответов — как бы удобно вы это не упаковывали — это когнитивная нагрузка.
Как снизить трение? Три шага к NF UI
Шаг 1 — Анализ действий пользователя
Шаг 2 — Использование анализа для принятие решений
Шаг 3 — Визуальное представление результатов решений
Конкретные примеры
Начнем с самого простого примера — Todo. Пример очень банален, но он самый наглядный на мой взгляд.
Шаг 1 — получаем от пользователя какие либо данные которые можно использовать для анализа того, что хочет пользователь.
Вместо выбора даты, заголовков, описания — 1 кнопка и заголовок «Скажите что и когда планируете сделать?». При ее нажатии пользователь просто говорит голосом: «позвонить маме завтра». Все. Никаких инпутов, селектов, дейтпикеров и тд.
Шаг 2 — Используем анализ действий для принятия решений
Скармливаем нейронке входные данные, просим проанализировать и выдать нам готовый результат в виде объекта. Результат валидируемый заранее заготовленной схемой. В случае неудачи делаем повторные попытки пока результат не будет успешен. Если превышен лимит попыток возвращаем пользователю ошибку(ни разу в моей практике) или показываем нативные интерфейсы. На моем опыте грамотно составленный промпт + схема практически исключают неправильные результаты. Изредка в логах можно увидеть, что система прибегла к повторной попытке. Я не проводил аналитику, но по моим прикидкам, что то около 1 неудачного дубля на 300–400 попыток. Тестировал я это на генерации статей в JSON виде по заданным мной схемам. Сгенерировал для сервиса X(NDA) более 40 000 статей на разных языках по известным заранее данным.
Возвращаясь к нашей Todo
На выходе получаем что то вроде
task.type = "reminder"task.date = "2026-04-22"
task.title = “call mom”
task.description = "call my mom"
Но что если пользователь не любит говорить голосом?
Тут мы должны работать в паре с продуктовым аналитиком или хотя бы нейросетью в этой роли, чтобы принять приблизительно правильное решение, а также понимать — какую продукт имеет репутацию на рынке и что может себе позволить, но это уже совсем другая тема достойная отдельной статьи.
Но что если нейросеть ошиблась? Ведь даже если пришедшие из ИИ данные проходят схему валидации, данные могут быть неверными так как галлюцинации никто не отменял.
Шаг 3 — пользователь должен видеть результат решений
После того, как с помощью нейросетей или математических операция было принято решение, пользователю необходимо показать результат. В данном случае — показать окно в котором он видит созданную Todo карточку и может ее отредактировать уже нативными средствами если ему что то не понравится.
Рассмотрим пример посложнее — сайт по поиску работы.
Пользователь заполняет профиль на сайте по поиску работы. Вместо графы «должность» и типичного селекта с выбором из списка, а также отдельного выбора скилов, дайте ему одно текстовое поле с заголовком «Перечислите основные инструменты, которые используете в работе». Условный бекенд разработчик на TS напишет что то типа «Node.js, Nestjs, Postgresql, RabbitMQ, MongoDB, Redis, Socket.io, Docker, CI/CD».
Под капотом же, при сохранении, закидываем в нейронку какие вообще есть скилы в нашей системе, какие есть должности, а также закидываем текст который ввел юзер и просим соотнести. Опять же валидируем выход заранее заготовленной схемой. В итоге в хранилище получаем юзера с прикрепленными БД сущностями скиллов и должностью.
Сужение
Если в вашей системе слишком много данных к которым нужно соотносить юзера — например, для данного кейса, у вас больше 10 000 скилов, тогда необходимо сузить выборку — разделяем скилы на подкатегории, и делаем 2 запроса в ИИ — сначала определение категории, а затем уже подходящих скилов из определенной ранее категории. Конкретно для данного функционала это может быть избыточно, это всего лишь пример, хотя как мы знаем — дьявол кроется в деталях.
Погрешности
Но что если это будет фронтенд разработчик? Что если в поле будет введено «React, Figma»?
Вероятно ИИ поймет, что это фронтендер, но может и к дизайнерам занести.
Возвращаемся к шагу 3 — мы всегда показываем пользователю уже сделанный за него выбор.
Мы не афишируем «смотрите, мы выбрали за вас!», не просим проверить данные, а просто позволяем пользователю увидеть их и исправить их уже классическими интерфейсами в случае ошибок. Но при правильно построенном NF UI предполагаемое кол‑во ошибок будет стремится к 0
Обыграть шаг 3 можно по разному — тут уже полет фантазии команды.
Главное помнить — каждое действие, переключение языка, открытие селектов, поиск нужной должности — все это когнитивная нагрузка и мы избавляемся от нее.
Еще немного примеров
Поиск билетов. Вы наверняка видели, что некоторые компании уже ввели помимо основного поиска, ИИ поиск - когда ты вместо выбора дат и опций просто пишешь “дешевый билет до франции без пересадок”. Система сама извлекает параметры из обычной речи с помощью ИИ для составления запроса к серверу и предоставления соответствующей выдаче результатов пользователю. Это и есть наш NF UI.
Чуть менее очевидный пример: написание статьи на каких либо площадках. Тут можно было бы сделать определение с помощью ИИ, к какой категории/подкатегории относится статья еще во время ее написания пользователем. И такое думаю, уже где то используется.
В целом ИИ иногда можно заменить математикой и это даже более выгодное решение, хотя по затратам часто более дорогое. Тут уже думаю каждый сам додумает где, что использовать.