Разработка продуктов, изначально ориентированных на ИИ: как создавать продукты, которые в первую очередь созданы с использованием ИИ, а не просто дополнены им.

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

Самый простой тест — это тест на удаление. Откройте продукт, мысленно удалите каждый вызов модели, каждую панель чата, каждую кнопку, каждую строку «сводка по ИИ». Что останется? Если ответ — полностью функциональный продукт, потерявший несколько важных элементов, то это продукт, «прикрепленный» к существующей архитектуре. Если ответ — пустая оболочка, потерявшая свою основную структуру, то это продукт, «настроенный» с использованием ИИ. Linear проходит тест на удаление только в отношении своих более новых элементов. Cursor мгновенно проваливает тест на удаление, потому что без модели ничего не остается. Большинство корпоративных SaaS-продуктов, выпустивших боковую панель чата в 2024 году, проходят тест на удаление, не теряя ничего важного, что и является обвинением.

Этот материал — рабочая версия этого теста. Шесть принципов, отличающих нативный ИИ от ИИ, добавленного в пользовательский интерфейс, пять реальных разборов продуктов от Linear, Cursor, Granola, Perplexity и Arc Search, демонстрирующих, как работает каждый принцип, две поучительные истории о продуктах, в которых ИИ был добавлен в боковую панель и от этого ничего не выиграно, а также контрольный список перед выпуском, который любая команда может запустить на работающей сборке перед релизом.

Нативный ИИ означает, что продуктом является модель, а не функция

Фраза «нативный ИИ» используется для обозначения каждого продукта с ключом OpenAI и эффектом свечения, что обесценило этот термин. Рабочее определение более четкое. Продукт, нативный ИИ, — это продукт, в котором модель является основной поверхностью, а остальная часть пользовательского интерфейса существует для того, чтобы сделать модель удобной, подотчетной и быстрой. Чат-панель, поля форм, панели мониторинга, боковые панели — всё это лишь каркас. Модель — это несущая стена.

Это звучит очевидно, пока вы не посмотрите, как продукты на самом деле выпускаются. Стандартный шаблон для корпоративных решений 2024 года заключался в сохранении существующей панели мониторинга и добавлении чат-панели к правому краю. Модель присутствует в продукте, но продукт не построен вокруг неё. Пользователь может игнорировать чат-панель и выполнять все задачи, за которыми он пришёл, используя исходный пользовательский интерфейс. Это и есть определение «прикрепленного ИИ», независимо от того, насколько заметен значок «блестки».

Версия того же продукта, изначально созданная для ИИ, перестроила бы основной рабочий процесс вокруг модели. Панель мониторинга становится подсказкой. Форма становится диалогом. Экспорт становится генерацией. Модель больше не то, что можно игнорировать, это сама поверхность. Такой продукт гораздо сложнее в выпуске, поэтому большинство команд довольствуются прикреплением «прикрепленного ИИ».

Шесть принципов проектирования продуктов, изначально ориентированных на ИИ

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

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

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

Модель как основная поверхность, а не боковая панель

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

Основная поверхность означает, что модель — это то, к чему пользователь обращается в первую очередь при открытии продукта. Боковая панель означает, что модель расположена рядом с существующим пользовательским интерфейсом, доступна по запросу и игнорируется по умолчанию. Perplexity — это основная поверхность. Notion — это команда слэша в AI, которая в основном является основной поверхностью в контексте написания. Cluely — это основная поверхность в виде наложения на весь экран. Значок «блестки» чата, закрепленный справа от любой стандартной панели мониторинга SaaS, является идеальным воплощением боковой панели.

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

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

Подсказка как ввод заменяет форму как ввод

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

Подсказка как ввод означает, что пользователь вводит то, что хочет, своими словами, а модель определяет структуру. Форма как ввод означает, что пользователь заполняет структурированные поля, которые продукт предопределил, и модели ничего не нужно делать. Комбинация клавиш Cmd-K в Cursor — это подсказка как ввод. Linear — это палитра команд плюс ИИ, использующая подсказку в качестве ввода. Perplexity — это весь продукт в виде подсказки. Поле ввода изображения в Krea — это подсказка в качестве ввода, дополненная эталонными изображениями. Lovable — это подсказка в качестве ввода, которая строит всё приложение из предложения.

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

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

Свобода действий по умолчанию означает, что продукт действует, а не запрашивает

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

Свобода действий по умолчанию означает, что продукт выполняет действие, когда пользователь выражает намерение, затем показывает, что он сделал, и позволяет пользователю отменить действие. Разрешение по умолчанию означает, что продукт предлагает выполнить действие, пользователь нажимает «подтвердить», продукт запрашивает подтверждение снова, и пользователь отказывается. Агент Cursor редактирует файлы без запроса. Granola расшифровывает и дополняет заметки без запроса. Arc Поиск просматривает, обобщает и представляет ответ без запроса. Продукт действует, а не ведет переговоры.

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

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

Прозрачность делает модель подотчетной

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

Прозрачность — это не то же самое, что отображение системного запроса. Прозрачность означает, что пользователь может ответить на три вопроса по запросу. К какому контексту имела доступ модель? Какое действие предприняла модель? Что модель создала и откуда она это взяла? Perplexity поставляется с ссылками на каждое утверждение. Cursor поставляется с различиями в каждом редактировании. Granola поставляется с исходной расшифровкой рядом с дополненными заметками. Пользователь никогда не задается вопросом, придумала ли модель что-то, потому что источник находится в одном клике.

Противоположностью является шаблон «волшебной коробки», когда модель выдает результат, а у пользователя нет возможности его проверить. Notion Старая функция сводки ИИ некоторое время работала именно так: сводка появлялась, и пользователю приходилось ей доверять. Решением стало добавление ссылок и возможности увидеть, какой контент был резюмирован. Урок заключается в том, что прозрачность не является необязательной в продукте, созданном на основе ИИ, это механизм доверия, который не позволяет продукту превратиться в машину для иллюзий.

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

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

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

Пользователю не важно, какой вариант модели запущен. Ему важно, чтобы ответ был хорошим, быстрым и проверяемым. Отображение названия модели на основном интерфейсе — это утечка информации из ментальной модели команды разработчиков в ментальную модель пользователя, и это сигнализирует о том, что команда еще не определилась с тем, что представляет собой продукт на самом деле. ChatGPT раньше размещал средство выбора модели на видном месте, а затем незаметно понизил его статус, потому что большинство пользователей не знали, что означает GPT-4-Turbo по отношению к GPT-4o, и этот выбор создавал паралич принятия решений вместо ценности.

Исключение составляет опытный пользовательский интерфейс. Cursor предоставляет возможность выбора модели, потому что его пользователи — разработчики, которым нужен выбор. Claude Code предоставляет возможность выбора модели по той же причине. Krea предоставляет параметры генерации, потому что его пользователи хотят их настраивать. Схема такова: по умолчанию детали модели скрываются на пользовательском интерфейсе, а затем отображаются в панели настроек или расширенном режиме для пользователей, которые явно хотят контролировать процесс.

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

Задержка — первостепенное ограничение проектирования

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

Задержка — это не просто показатель производительности, это ритм продукта. Двухсекундная пауза перед первым токеном — это пустое пространство, и пользователь заполняет его сомнениями. Решение заключается в сочетании потоковой передачи токенов ответа по одному (чтобы пользователь сразу видел движение), показа скелетного или мерцающего состояния, которое обещает скорый ответ, и отображения частичных результатов, как только они становятся доступны. Perplexity делает все три. Курсор делает все три. Большинство боковых панелей чата в корпоративных SaaS-приложениях не делают ничего из этого и кажутся неработоспособными при каждом взаимодействии.

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

Пять продуктов, изначально созданных с использованием ИИ, с комментариями

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

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

Linear, ИИ как тихая панель управления

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

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

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

Курсор, встроенный в ИИ редактор

Курсор — это результат того, что вы перестаёте прикреплять ИИ к VS Code и перестраиваете редактор вокруг модели, и в результате получается самый чистый инструмент разработчика, встроенный в ИИ, выпущенный на сегодняшний день.

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

Где Cursor упускает возможности. Пользовательский интерфейс в режиме агента по-прежнему ощущается как панель чата, прикрепленная к редактору в некоторых потоках, тогда как он должен быть более интегрирован в встроенный интерфейс. Улучшение этой интеграции вывело бы Cursor дальше в область «основа-поверхность».

Granola, ИИ-нативный подход как бесшумная транскрипция с мозгом

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

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

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

Perplexity, поисковая система, изначально созданная на основе ИИ

Perplexity перестроил поиск вокруг модели и ответа, где входные данные — это модель, поверхность — это модель, а результат — это модель.

Поверхность: максимальная основная поверхность, весь продукт — это модель. Запрос: запрос в качестве входных данных — единственная модель взаимодействия. Агентность: средняя, ​​модель отвечает на вопрос, не задавая его, но пользователь по-прежнему явно управляет каждым взаимодействием. Прозрачность: ссылки на каждое утверждение, источники отображаются непосредственно, появляются дополнительные вопросы. Раскрытие: детали модели в основном скрыты на пользовательском интерфейсе, отображаются в профессиональных настройках. Задержка: потоковая передача, быстрый первый токен, частичные результаты при более глубоких запросах.

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

Arc Поиск, встроенный ИИ в качестве вкладки браузера

Arc Поиск сводит весь цикл просмотра и суммирования к одному касанию, а ИИ представляет собой саму вкладку, а не панель, прикрепленную к ней.

Поверхность: модель заменяет страницу, «Найдите для меня» возвращает ответ, а не список ссылок. Подсказка: подсказка в качестве ввода через адресную строку, что является наиболее естественной поверхностью подсказки в браузере. Агентность: очень высокая, продукт посещает несколько страниц, суммирует их и представляет один синтезированный результат без запроса. Прозрачность: ссылки на источники находятся внизу синтезированного результата. Раскрытие: детали модели полностью скрыты, ИИ невидим как инфраструктура. Задержка: удивительно быстрая для многостраничного действия агента, восприятие улучшается благодаря быстрой загрузке.

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

Хотите продукт, где ИИ — это лишь поверхность, а не блестящая иконка в углу? Нанимайте Brainy. UXBrainy предлагает аудит стратегии и дизайна продуктов, ориентированных на ИИ. AppBrainy предлагает полноценный пользовательский интерфейс для продуктов, изначально ориентированных на ИИ, для команд, создающих инструменты уровня Cursor. ClaudeBrainy предлагает набор навыков и библиотеку подсказок для команд, которые хотят, чтобы функции ИИ были реализованы как в продуктах из этого списка, а не как боковая панель чата 2024 года.

Две поучительные истории об ИИ, прикрепленном к боковой панели

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

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

Боковая панель чата, которую никто не открывает

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

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

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

Кнопка-блеск, которая суммирует то, что никто не просил суммировать

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

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

Решение аналогично исправлению боковой панели чата, но в меньшем масштабе. Выберите два или три текстовых поля, где ИИ действительно помогает (длинный контент, извлечение структурированных данных, суммирование больших документов), и внедрите в них глубоко интегрированный с ИИ интерфейс. Удалите кнопку с эффектом блеска из всех остальных полей. Теперь продукт интегрирован с ИИ в тех областях, которые имеют значение, и лишние элементы удалены.

Контрольный список перед выпуском продуктов, интегрированных с ИИ

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

1. Тест на удаление. Мысленно удалите все вызовы моделей из продукта. Что останется? Если останется полноценный, функциональный продукт, значит, в продукте используется ИИ. Если остается пустая оболочка, продукт является изначально разработанным для ИИ.

2. Тест холодного открытия. Откройте продукт без использования ИИ. На какую поверхность попадает пользователь в первую очередь? Если это поле ввода запроса, поверхность ответа или основное представление, управляемое моделью, принцип поверхности остается в силе. Если это исходный пользовательский интерфейс со значком чата в углу, принцип поверхности не выполняется.

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

4. Позиция субъектности. Подсчитайте количество модальных окон подтверждения между выражением намерения пользователя и действием модели. Если их больше одного, принцип субъектности слишком осторожен. Переместите больше действий в режим «действие-отмена».

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

6. Продемонстрируйте дисциплину. Посмотрите на основной интерфейс. Видно ли название модели, температура или системное сообщение? Если да, и аудитория не разбирается в технике, скройте это. Если да, и аудитория разбирается в технике, оставьте это.

7. Ритм задержки. Измерьте время от намерения пользователя до первого ответа модели. Если прошло более двух секунд без какой-либо обратной связи, восприятие задержки нарушено. Добавьте потоковую передачу, состояния скелета или частичные результаты, пока ритм не станет ощутимым.

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

9. Тестирование адаптации. Посмотрите, как пользователь, впервые использующий продукт, выполняет основную задачу. Модель обеспечила пользовательский опыт, или пользователь выполнил задачу, используя исходный интерфейс? Если последнее, ИИ будет добавлен, независимо от того, что говорят маркетологи.

10. Восстановление после сбоя доверия. Заставьте модель выдать неправильный ответ. Что делает продукт? Если нет четкой поверхности восстановления, цикл доверия неполный, и продукт потеряет пользователей из-за своей первой иллюзии.

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

Часто задаваемые вопросы

Что означает дизайн продукта, изначально разработанный с использованием ИИ?

Дизайн продукта, изначально разработанный с использованием ИИ, означает, что модель является основной поверхностью, а остальная часть пользовательского интерфейса существует для того, чтобы сделать модель удобной, подотчетной и быстрой. Самый простой тест — это тест удаления: если вы удалите все вызовы модели из продукта, и останется полностью функциональный продукт, то продукт является продуктом, на который ИИ был добавлен. Если останется только пустая оболочка, то продукт является продуктом, изначально разработанным с использованием ИИ. Linear, Cursor, Granola, Perplexity и Arc Search проходят этот тест на своих основных поверхностях. Большинство корпоративных SaaS-продуктов, выпустивших боковую панель чата в 2024 году, его не проходят.

Чем отличается разработка на основе ИИ от добавления ИИ?

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

Каковы принципы проектирования продуктов, ориентированных на ИИ?

Шесть принципов отличают разработку на основе ИИ от добавления ИИ. Модель как основная поверхность, а не боковая панель. Подсказка как ввод, а не форма как ввод. По умолчанию — свобода действий, а не разрешение. Прозрачные поверхности, обеспечивающие подотчетность модели. Скрытие деталей модели по умолчанию, их отображение при получении намерения. Задержка как первостепенное ограничение проектирования при потоковой передаче, состояниях скелета и частичных результатах. Каждый достойный изучения продукт, созданный на основе ИИ, включает в себя комбинацию этих шести элементов.

Какой лучший пример продукта, созданного на основе ИИ?

Курсор — самый чистый пример дизайна продукта, созданного на основе ИИ, выпущенного на сегодняшний день для инструментов разработчиков. Perplexity — самый чистый пример для потребительского поиска. Linear — самый чистый пример встроенного интерфейса, созданного на основе ИИ, в существующую поверхность повышения производительности. Granola — самый чистый пример продукта, созданного на основе ИИ, где модель работает в фоновом режиме. Arc Поиск — самый чистый пример взаимодействия с браузером, созданного на основе ИИ. Каждый из них перестраивал свой основной рабочий процесс вокруг модели, а не просто добавлял ИИ к существующему пользовательскому интерфейсу.

Как разработать пользовательский интерфейс для ИИ в продукте, изначально созданном на основе ИИ?

Начните с проверки удаления на каждом экране. Замените формы подсказками, где модель может структурировать данные лучше, чем пользователь. Установите режим работы по умолчанию «действие-отмена», а не «спрос-действие», и добавьте поверхность отмены вместе с действием. Добавьте поверхность прозрачности для каждого выходного параметра модели. Скройте детали модели от пользовательского интерфейса. Разрабатывайте каждое взаимодействие с учетом реальной задержки модели, а не имитированной, и используйте потоковые или скелетные состояния, когда первый токен приходит с задержкой более одного такта. Тот же принцип применим и к более широкому переходу Тенденции веб-дизайна 2026 года к макетам, которые адаптируются к модели, а не обворачивают её.

Изменения, которые на самом деле открывают продукты, изначально созданные с помощью ИИ

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

Бренды, выпускающие продукты с ИИ (Linear на новых платформах, курсор повсюду, Granola в слое дополненной реальности, Perplexity сквозное решение, Arc поиск как целостная модель взаимодействия), все это усвоили. Они не просто добавили ИИ в продукт, они создали продукт вокруг ИИ. Архитектурное решение предшествует каждому дизайнерскому решению и проявляется во всем, от модели ввода до ритма задержки и поверхности восстановления. Продукты, которые пытаются внедрить ИИ в существующую платформу, в итоге получают боковую панель чата, которую никто не открывает, и кнопку-индикатор, на которую никто не нажимает, независимо от того, насколько маркетинговый сайт настаивает на том, что они ориентированы на ИИ.

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

Более глубокий сдвиг заключается в изменении ментальной модели пользователя в отношении программного обеспечения. Они больше не ожидают, что будут изучать инструмент, они ожидают выразить намерение и получить ответ от инструмента. Продукты, созданные для старой ментальной модели (формы, панели управления, многошаговые мастера), через два года будут казаться медленными, формальными и устаревшими. Продукты, созданные для новой ментальной модели (подсказка, ответ, действие, отмена), будут восприниматься как нечто современное. Команды, которые первыми начнут действовать, определят, что значит «ИИ-ориентированный» в их категории, а команды, которые просто добавят боковую панель чата к существующему интерфейсу, потратят остаток десятилетия на объяснения, почему их показатель вовлеченности в использование ИИ так низок.

Если ваша команда разрабатывает функцию ИИ, продукт на основе ИИ или пытается понять, что именно вы действительно собираетесь выпустить, принципы на этой странице — это руководство по эксплуатации. Если вам нужна помощь в применении их к вашему конкретному продукту, перейдите по ссылке нанять Brainy. UXBrainy предлагает стратегию продукта, ориентированную на ИИ, и полные аудиты дизайна на основе этой структуры. AppBrainy предлагает ИИ-ориентированный пользовательский интерфейс для команд, создающих инструменты, которые, по их мнению, пользователи действительно будут использовать. ClaudeBrainy предлагает Claude Навыки и библиотеку подсказок для команд, которые хотят, чтобы функции ИИ были построены как курсор, а не как боковая панель чата 2024 года. Структура, представленная на этой странице, — это то, что мы используем в каждом проекте, на каждом экране, перед выпуском продукта.