Как структурировать продукт для ИИ: 6 элементов Новая точка ценности возникает в создании интерфейса-протокола-API, который позволяет ИИ понимать ваш продукт и действовать в нём (назовём это AIX вдобавок к привычному UX).

AIX, как и UX, ломается не на сложных, а на неявных действиях

Чтобы продукт стал более удобным для ИИ, его можно разложить на несколько элементов: 1) Структурированный контекст, чтобы ИИ-агент мог видеть то же, что видит пользователь. Но ИИ-агенту нужен не весь контекст продукта, а нужный слой на нужном действии, так как избыточный контекст так же ломает агента, как недостаточный (ибо разнообразие должно соответствовать, а не максимизироваться). 2) Типизированные действия, чтобы ИИ-агент знал, какие действия доступны в процессах а) пользователя; б) продукта и бизнеса.

Типизированное действие = предусловие (срез контекста, при котором действие применимо) + действие + постусловие + альтернативный поток (эскалация на человека).

3) Правила эскалации с версионируемой схемой политик поломок и явным владельцем, чтобы ИИ-агент (и человек) знали, при какой ситуации необходимо предпринять действия коррекции и кому. У каждого типизированного действия должна быть задана стоимость отката. Если откат действия дороже самого действия (необратимые операции: отправка, платёж, удаление), эскалация к человеку должна быть предусловием, а не постусловием. 4) Как только продукт структурирован, его частям нужен ИИ-контракт ИИ-контракт определяет, как фича работает на системном уровне, её связь с каждым компонентом, объектом и правила их взаимодействия внутри продукта, чтобы разные продуктовые области могли подключаться и заставлять своих ИИ-агентов выполнять желаемое поведение. И да, версионируйте контракты ВСЁ, иначе без этого ИИ-агенты молча начинают действовать на устаревшей модели продукта. 5) Цикл. Цикл призван улучшать Систему в времени. Примером ценного цикла может служить захват сигнала коррекции: разницы между тем, что сделал ИИ-агент, и тем, исправил ли это пользователь. Например, когда пользователь редактирует текст, сгенеренный ИИ или отменяет предложенный вариант, это разные по силе сигналы. Первый про качество ответа ИИ, второй про доверие/уместность действия со стороны ИИ в глазах юзера, поэтому разделяйте постусловие на «успех» и «частичный успех». Поэтому каждый цикл коррекции должен иметь владельца (ИИ или человек?), который решает, применять ли исправление системно или считать его исключением.

Исправления пользователя — это размеченные им же несостыковки в реальности продукта

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

Онбординг это не тур по продукту, а последовательность убеждения. Порядок экранов решает больше, чем их количество Мне попался разбор онбординга одного подписочного приложения: после переделки 94% тех, кто начал онбординг, доходят до пейволла. Не покупают, а именно доходят, то есть их не теряют по дороге. Подход показался интересным и применимым почти к любому продукту с подпиской, поэтому делюсь. Старая версия открывалась туром по фичам: welcome, три-четыре экрана про то, что умеет приложение, и только потом вопросы. По сути питч-дек, и люди отваливались ещё до оффера. Идея переделки простая: человеку плевать на ваши фичи, пока он не почувствовал, что его понимают. Поэтому логику перевернули. Сначала спрашиваем про его проблему, потом показываем решение. Каркас нового флоу: 1. Идентичность первой. Имя и пара базовых вопросов до всего остального. Это запускает ощущение, что продукт делают под меня, с первого экрана. 2. Контекст. Как часто у человека возникает проблема. Это калибрует, как дальше лягут копирайт и цифры. 3. Желание до фич. Спрашиваем, что человек хочет получить, ещё не показав ни одной фичи. Ищем работу, которую он нанимает продукт сделать. 4. Инвестиция. Экраны предпочтений как будто настраивают продукт под ответы. Человек уже вложился, хотя ничего ещё не построено. 5. Доверие. Отзывы и social proof идут после шагов вовлечения, а не на втором экране. Доверие заходит лучше, когда уже есть чувство собственности. 6. Разрешения. Пуши просим после того, как ценность уже почувствована, и никогда не блокируем прогресс из-за отказа. 7. Усиление боли. Четыре вопроса про одну и ту же проблему с разных сторон, включая эмоциональный: как это ощущается. Боль проговаривается словами пользователя, а не вашим копирайтом. 8. Мы вас услышали. Экран с надписью персонализируем на пару секунд закрывает петлю после вопросов про боль. 9. Доказательство боли. Статистика прямо перед оффером, пока проблема максимально свежая: это не только ваша беда, это распространено. 10. Оффер. Paywall ровно в тот момент, когда проблема максимально выпуклая. 11. Аккаунт последним. Регистрация только после покупки, а не до неё. #PG_education @productgames

/btw на максималках или Codex side chat Продолжаем рубрику подборка лучших UX решений. Когда кодишь с агентом довольно часто возникает ситуация, когда из одного чата нужно быстро форкнуться в новый чат, чтобы исправить что-то, возникшее по пути, не прерывая работы в старом чате. Раньше мы использовали fork для этих целей, но форк довольно тяжеловесный + не из всех состояний он доступен. В общем, если выделить текст в прямо чате Codex App'а, то сверху можно увидеть всплывающее меню с разными действмия, в т. ч. Ask in side chat. Наверное, видели. Можно подумать, что это старый добрый /btw а-ля клод код. Но нет, на деле у этого сайд чата тоже есть полноценный write доступ и из него действительно можно делать небольшие правки (например, в скиллах, как на скрине) прямо по ходу основной задачи, вообще никак в нее не вмешиваясь. Не знаю как вам, но мне не хватало такой возможности - настолько, что решил и вам рассказать. Напомню, что ранее я уже рассказывал про неочевидную удобную возможность реордеринга (как это по русски подскажите в комментариях) очереди сообщений в Codex App. Если не видели - посмотрите. А еще, теперь можно попросить Codex App запустить какую-то задачу в новом диалоге и он прям из текущего чата спавнет вам новый диалог. И читать сторонние или текущий диалог Codex App теперь тоже умеет. Подробнее про то, как это работает рассказывал Тимур. И да, в Claude Code Desktop тоже есть подобный side chat, но он readonly, что не так интересно, хоть и удобно иногда что-то доспросить. @ai_driven

На фотографии – пульт от моего телевизора. Ему лет десять, он похож на предыдущий и, надеюсь, он не будет похож на следующий.   Сейчас, к счастью, эра классических ТВ-пультов уходит. Я держал их в руках годами, но если быть честным - понятия не имею, зачем нужны 80% этих кнопочек. Тем более, всегда можно выйти в меню и там натыкать, что угодно.   Этот вопрос волновал не только меня, но и Мартина Линдстрома, которому однажды повезло путешествовать вместе с инженером компании, разрабатывающей пульты. Разгадка оказалась не в эргономике, а в психологии корпоративных войн.   Пульт один, и он маленький. А телевизор — это не просто экран, а конгломерат сервисов: кабельное, стриминг, интернет, приложения, игры и т.д.   Каждая из этих фич приносят деньги. Каждой занимается отдельный дивизион внутри корпорации. И для руководителей этих направлений пульт не средство управления, а самая дорогая недвижимость в мире. Все хотят иметь свой, пусть и маленький кусочек.   Поэтому инженеры, отвечающие за разработку пультов, искренне гордятся результатом: «Смотрите, как виртуозно мы впихнули и поделили пространство между всеми игроками!». Потому что пользователь далеко, а всякие вице-президенты весьма близко.   Пульт - это такая овеществленная иллюстрация закона Конвея: "организации проектируют системы, копирующие структуру коммуникаций внутри этой организации".   Я стал специально проверять – и да, в каждой компании можно найти собственный «пульт». Такой памятник корпоративным интригам, условностям и амбициям. Эти объекты имеют глубокий смысл внутри конкретного ООО, но абсолютно чужды и даже враждебны для покупателей.   (пульт от Apple TV хвалим в комментах 😉) | MAX | подкаст | | Личная жизнь и мысли - Молчанов.Life |

🧨 Появился набор скиллов, которые мешают ИИ-агентам делать глупости и сжигать токены — ру дизайнер выкатил nodumbmode для фикса типичных ошибок. Внутри лежат 4 скилла: → nodumb — манифест здравого смысла для агента и набор главных рекомендаций. → changelog-discipline — ведёт журнал решений и записывает, что поменялось, почему и что отвергли. → system-feedback — проверяет, понятно ли юзеру, что произошло после действия и что делать при ошибке. → ask-nodumb — дизайнер-консультант, который разбирает продуктовую или UX-задачу до проектирования решения. Самое крутое — все скиллы собраны из реальных ошибок в проектах и новый скилл появляется только после конкретного фейла. Ставится за одну команду:

npx skills@latest add hronicasync/nodumbmode

Сохраняем — тут. @notboring_tech

Июльский дайджест продактов звучит жарой и светом её Солнца – От лошадей к стартапам – Цена фичи – Contextual Product Management – Про «чтобы что» – Закон Фолкленда – Закон Брукса – Правило 7% – 3 Истины Систем – Главное из AEO – Зачем продукту видение – Be NICE – Diff-in-Diff: A/B-тест невозможен – Process Communication Model – Как перестать быть незаменимым – The truth about being a manager – Что проверять в AI-продуктах – Немного про контрольные карты – Scream-тест продукта – Суперпозиция продукта – Токен ↔ Человек – Метод CRISP для PRD – Валидация — мираж – Культура загнивает незаметно – Как проектировать UX AI – Чатоцентричный интерфейс – Играем в «Оракл» с продуктом – ИИ внушает ложную уверенность – Book: Product Design Psychology – Гайд: Метрики UX – The Layers of AI experience – Симулятор сотрудника FAANG – Каталог когнитивных искажений – ИИ о человеческих страданиях – 3 ways people respond to a problem – What AI can tell us about human suffering – The Laws of this World (Game Theory) – По вере вашей дано будет вам 🌞 Yoshiko Sai ～ Taiji no Yume 🔭 Chiemi Manabe - Untotooku

Однажды, лет десять назад, Эпл придумал в Файндере обозначать файлы, сохранённые из писем, вот таким вот конвертиком. Зачем и нахрена — никто не знает. В этом нет ни смысла, ни пользы, ни радости, ни удобства. Видимо, в том году в появилась какая-то фича файловой системы, которая позволила это хранить, вот они и прикрутили. При этом файлы из каких-либо других источников никак специально не помечаются. Чем именно почта заслужила такого особого отношения? Ну просто что-то сделали, чтобы использовать новую фичу, не знаю. И теперь эта грязь рядом со случайными файлами повсюду таскается, и никак он неё не избавиться. Да, окей, файл из письма, я понял, но мне пофиг, отвали.

Где возникают ошибки Можно предложить следующую модель получения результата: цель → намерение → действие → система → результат Все это находится в окружении, которое влияет на наши действия. 1. Намерение Насколько намерение помогает достичь цели, или насколько у меня правильный образ действия, того, что я хочу сделать. Дон Норман называл эту стадию понимание «концептуальной модели системы». В ряде случаев концептуальная модель простая: если нажать на педаль тормоза, то машина остановиться. Но в ряде случаев концептуальная модель может быть запутанной: чтобы открыть дверь — её надо толкнуть или потянуть на себя? Я уже не говорю про более сложные системы. Насколько система представляет собой ясную схему, что и как надо сделать, чтобы получить желаемый результат? 2. Действие Несовпадение намерения и действия — действительно ошибка человека. Я хотел повернуть налево, но повернул направо. Я хотел нажать на тормоз, а нажал на газ. Насколько система позволяет сделать неправильное действие. Кроме этого важную роль начинают играть другие факторы: усталость исполнителя, отвлекали ли исполнителя во время важных действий и т.д. 3. Система или черный ящик. Сама система может работать с ошибками. Люди могут неправильно понять, то что мы им говорим, информация передается с ошибками. Механизмы могут быть спроектированы с ошибками, софт ошибается. 4. Окружение Это та обстановка, в которой мы действуем. Либо это культура организации, это социоэкономические факторы и т.д. Окружение может влиять на ошибки, которые возникают в процессе. Есть ли давление, чтобы добиться хороших результатов. Насколько система требует не ошибаться или система требует достичь цели любой ценой. Это культура компании, тон сверху, психологическая безопасность и все подобные вещи. Сюда же относятся ошибки, которые можно называть «внешними событиями». Мы ехали по правилам, в нас врезалась машина. Но мы же все сделали правильно. ;) Как видно, отклонения или ошибки могут возникать на любом уровне в этой модели. Но на каждом уровне ошибки возникают по разными причинами и требуют разных методов для предотвращения. #ЧФ #ошибки

Программа при запуске хочет, чтобы я открыл файл Один из паттернов в интерфейсе, который меня бесит — это когда запускаешь программу на Маке, а она тут же открывает диалог открытия файла. Ну типа, думает она, пользователю же я низачем не нужна без файлов, ему же по-любому нужно будет открыть? — вот я и помогу! Это, как и кнопка «наверх» внизу страницы и кнопка «На главную» на пустом экране — тоже пример того, когда мне протягивают костыль, а я не хромой. Во-первых, я сам решу, открывать мне файл или нет. Может, я зашёл просто версию посмотреть или обновление установить? Или я звпустил программу впрок, но прямо сейчас не собираюсь ничего с ней делать. Просто не лезь со своим диалогом и не мешай мне пользоваться компьютером! Во-вторых, даже если я и собираюсь открыть файл, ну не через диалог открытия файла же я это буду делать! Это самый неудобный способ открыть файл в мире. Файл почти наверняка у меня где-то и так под рукой: в письме, в телеге, на рабочем столе, в папке, в веере Downloads в доке. Я его просто оттуда затащу да и всё. Нафиг мне твой диалог сдался вообще? Если программа пытается по-умному что-то предусмотреть или предугадать — это хорошо. Но важно, чтобы результат этого предугадывания не был помехой пользователю.

Я уже писал про мои мечты о «правильном» визивиге. Первой идеей было поведение на границе регионов с разной разметкой. Идея в том, что к курсору прилипает стиль того, откуда он пришел. Пришел на границу из жирного? Будешь писать жирным. Пришел, наоборот, из обычного? Будешь писать обычным. В том же самом месте, на той же самой границе. Есть еще идея делать в одном месте два шага, но она мне нравится меньше. Сегодня вторая идея. Я посмотрел на списки. Для меня это всегда дичь. Например, я зашел сейчас в Ноутс. Сделал ненумерованый список. Написал первый пункт. Нажал Энтер. Создался второй пункт, автоматически, с маркером. Пока все хорошо. И вот я стою на пустом элементе. Как мне закончить список? Скажем, я набрал три пункта, стою на четвертом, а он мне уже не нужен. В обычном тексте ты видишь слева от курсора маркер, значит бэкспейс должен его удалить. Так? Так. А в визивиге не так! Бэкспейс вернет тебя в предыдущий пункт! То есть удалит и маркер, и перенос строки. Зачем? Не знаю. Как тогда закончить список? Нажать ЭНТЕР. То есть то, что обычно создает новый пункт, тут ничего не создает, а удаляет маркер слева!!! Как создать пустой пункт, если энтер его удаляет? А никак. Кстати, это поведение еще и разнится от программы к программе. Например, в Гуглдоках бэкспейс удалит маркер слева, но оставит оступ. Так можно сделать элемент списка без маркера. Зачем? Прост. Неудивительно, что люди не любят визивиг! Обычные кнопки ведут себя совсем не так, как в обычном тексте. Выделение работает не так: можно выделить строку от начала до конца, и признак «элемент списка» скопируется вместе с ним, хотя ты вроде бы об этом не просил. Сами маркеры списка тоже ни выделить нельзя, ни даже курсором на них встать. Почему? Что в них такого особенного? Короче, думал я, думал, и пришел вот к какому выводу. Маркеры списка нужно интерпретировать как обычный текст. Давать ходить в них курсором, выделять, копировать, вставлять, удалять бэкспейсом. Это будет самое простое, предсказуемое, интуитивное поведение. По сути, главная причина, почему мы все так любим плейнтекст и не любим визивиг в том, что в плейнтексте все работает понятно и предсказуемо: что выделил, то и скопировалось. Ну вот, нет причин, почему в визивиге оно не может работать так же. Если у вас совершенно случайно есть программа iA Writer, там списки рабоают почти правильно. Т.е. можно выделять/копировать/удалять маркеры так же легко, как обычный текст. Вот списки я хочу сделать так же, а bold/italic все-таки визивигом. Отдельно интересно, кто придумал конвенции вот эти, что энтер завершает список, например, или что бэкспейс склеивает элементы. Потому что это явно все друг у друга копируют, но как будто никто ни в какой момент не остановился и не подумал, зачем.

Пользовательский опыт (UX) UX — это впечатление, которое человек получает от взаимодействия с продуктом: насколько всё понятно, удобно и приятно. Чем легче пользоваться сервисом, тем охотнее клиент остаётся и возвращается. Что формирует хороший UX? Минимум действий — чем быстрее пользователь достигает цели, тем лучше Быстрая загрузка — медленные платформы отталкивают Понятный интерфейс — всё должно быть логично и не вызывать вопросов Приятное оформление — гармоничные цвета, удобочитаемые шрифты и заметные кнопки увеличивают вовлечённость Компании вроде Airbnb или Notion инвестируют в UX, потому что довольные пользователи — это не только продажи, но и повторные визиты. Фаундер | Бизнес и Стартапы

Интерфейсы для людей больше не нужны? Я вот делаю админку у себя на сайте с курсами. Там есть всякие поля, которые раньше я заполнял вручную. Название курса, описание, обложку (картинку) курса. И вот уже в который раз замечаю, что поля эти есть. Но их я не трогаю руками. Проще открыть Claude или Codex и сказать, давай на сайт добавим вот такой-то курс, там будут вот эти уроки, вот описание для уроков, на основе содержания курса, сгенерируй обложку и поставь ее для курса. И всё. Нейронка дальше создаст на платформе курс, заполнит поля и поставит обложку. Мне остается записать видеоурок и выложить его на платформу. Получается, что эти поля нужны «на всякий случай», когда под рукой нет нейронки, а поправить что-то нужно.

Лайфхак для вайб-кодеров в 2026 году. SaaS, который не снимет ответственность за принятие решений с пользователя в 2026 году, пойдет ко дну. Что я имею ввиду? Большинство людей все больше ответственности отдают ИИ, даже не смотря на качество. Цифровое пространство разогналось сейчас с такой скоростью, что человеческая психика не способна работать на таких скоростях. И каждый вопрос к пользователю убивает конверсию в целевое действие и пользовательский опыт. Я как-то писал, что убрал из Lovarus MCP сервера. Точнее, я взял на себя их подключение, то есть забрал ответственность с пользователя. Сегодня я решил забрать еще одну ответственность - убрать режимы работы агента. Пользователь не должен думать какой ему режим выбрать, я могу сам это решить за него, основываясь на сложности его промпта. Это кажется очевидно, но я вижу сотни стартапов, которые на старте задалбывают юзеров кнопочками и формочками из доИИшной эпохи. Следующий этап - по выражению лица понимать, когда пользователь хочет нажать на кнопку «Собрать» и делать это за него 😂

Заметка из 2015, но всё ещё актуальна. И вместо Мака ещё можно подставить Сафари с тем же успехом Поддержка Мака обязательна для хорошего дизайна Предположим, вы обратились к хорошему дизайнеру за помощью с вашим веб-продуктом, а ваша аудитория использует Виндоус. На этапе разработки выясняется, что на Маке у вас всё глючит и тормозит. Дизайнер жалуется и просит поправить. Но оптимизация под Мак требует дополнительных ресурсов. Вы считаете, что эффективнее тратить ресурсы на полировку того, что видят ваши пользователи, а не ваш дизайнер. У вас не будет хорошего дизайна. Большинство хороших дизайнеров сидят на Маке. Если дизайнер постоянно будет видеть говно, и вы не будете его чинить, веря, что на Виндоусе-то у вас всё хорошо, то вы даже никогда не узнаете, хорошо ли у вас на Виндоусе. Проверять качество будут ваши программисты, а не дизайнер, и дизайн получится на их уровне. Нанимать дизайнера, который даже не может посмотреть, что получается — вот где неэффективная трата ресурсов. Тут может возникнуть вопрос: не должен ли дизайнер поглядывать из-под Виндоуса сам, раз делает продукт для его пользователей? Хорошо бы, чтобы поглядывал. Но дизайнер — не тестировщик. Если он будет сидеть и внимательно прокликивать свои интерфейсы, запустив фаерфоксы и обложившись андроидами, то у него не останется времени на основную работу. Поэтому важно, чтобы дизайнер мог видеть продукт в том браузере, который у него и так открыт. При этом, когда дизайнер объясняет разработчикам, что и как починить, у разработчиков повышается разрешение и понимание того, как всё должно быть, поэтому они сами лучше реализуют во всех браузерах. Если вы позвали дизайнера и хотите дизайн, то считайте, что с этого момента важная часть вашей аудитории использует Мак.