Дизайн

Latent-to-4D Генерация динамических 4D-сцен из текста и картинок без промежуточного RGB-декодинга. Вместо RGB-декодинга берет финальный латент видео-DiT и поднимает его сразу в явную 4D-сцену На выходе камеры и динамические карты точек в мировых координатах. • Text-to-4D - сцена из текста, 81 кадр с камерами и динамической геометрией • Image-to-4D - первый кадр задаёт внешний вид и композицию • Audio-driven 4D - аудио управляет лицом, телом и камерой • Video-as-prompt 4D - перенос стиля/трансформации из демо-видео • Pose-controlled и motion-controlled анимация - скелет или траектории точек ведут движение • 4D-симуляция для робоманипуляций Гитхаб ждем #textto4d #imageto4d #4d

Онбординг это не тур по продукту, а последовательность убеждения. Порядок экранов решает больше, чем их количество Мне попался разбор онбординга одного подписочного приложения: после переделки 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

Нашел очень полезную статью про то, как исопльзовать цвет и градиенты в научной коммуникации. В ней рассказывается, как "красивые" градиенты могут менять смысл данных из-за особенностей восприятия цветов глазом. Ну и, конечно, какие градиенты остаются видны для людей с особенностями восприятия цвета. https://www.nature.com/articles/s41467-020-19160-7 Там много полезных советов, в частности гайд по выбору правильного градиента в зависимости от типа данных. Некоторые вещи мне были совсем не очевидны! Кстати, последнюю нашу статью я проверял специально, что все иллюстрации доступны людям с дальтонизмом и прочими особенностями цветового восприятия: https://mariechatfield.com/simple-pdf-viewer/ Было сложно! Пришлось поменять довольно много цветов, чтобы оно было как-то видно. Но в конечном итоге было ок.

Часто в искусстве используют оч сложные технологические решения, забывая, что главное - это не перезадротить всех задротов, а ✨ эмоции зрителя ✨ Зритель либо испытывает что-то, либо ему скучно. В последнее время у меня вообще появился любимый вопрос ко всем проектам, которые я делаю или консультирую: "почему людям на это не будет похуй?" Неважно, это арт проект, игра, да даже пост в телеге. Оч полезный и очень емкий вопрос, всем советую! Часто кучу эмоций у аудитории вызывают какие-то простые вещи. Как тут. Ну магия же! А на самом деле это просто трекеры (крепко подозреваю, что виар трекеры от Vive), которые приспособили управлять прожекторами.

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

«Похмельная Мона Лиза» и суд, который решил, что ИИ убивает авторское право Только недавно обсудили, как одну мадам уволили за "слив данных в DeepSeek", как появилось свежее решение Пресненского районного суда Москвы (дело № 02-4220/2025) по ИИ и творческий вклад. Речь о производных работах: «Мона Лиза с вином» и «Статуя Свободы с вином». Дизайнер взял известные изображения, внес изменения с помощью ИИ (бокал вместо факела, растрепанные волосы, мешки под глазами, патчи и т.д.) и назвал результат своими арт-объектами. Предприниматель начал продавать мерч (футболки) с этими изображениями. Дизайнер пошел в суд за компенсацией. И суд ему отказал. Ключевая фраза: изменения внесены с помощью искусственного интеллекта БЕЗ творческого вклада —> поэтому объекты не могут быть самостоятельными объектами авторских прав. Что именно не так с этой логикой? Суд выстроил рассуждение вокруг трех критериев авторского права (база типа): 👉 авторское право есть когда = есть человек (автор), результат выражен в объективной форме и есть творческий фактор. Структура в целом правильная. Проблема - в наполнении и логике суда на мой взгляд. 1. Про «значительную роль» программы Суд написал, что если компьютерная программа играет значительную роль, то творчества нет. В законе такого критерия нет. Пленум Верховного суда прямо говорит: творческий характер не зависит от того, создано произведение собственноручно или с использованием технических средств. Автоматическая камера видеонаблюдения - да, не творчество. Но генеративный ИИ - совсем другая история. Раньше в фотошопе и до ИИ можно было очень сильно что-то преобразить - программа сама по себе НЕ критерий 2. Про «просто механические команды» Суд назвал работу с промптами простыми механическими действиями. Без исследования самих промптов, итераций и того, как именно отбирался результат. В других юрисдикциях суды как раз смотрят на этот процесс детально. 3. Про новизну и уникальность Суд подробно объясняет, что идея «похмельной Моны Лизы» и «Статуи Свободы с бокалом» не нова. Но требование новизны и оригинальности - это критерии патентного права, а не авторского. В авторском праве отсутствие новизны само по себе не лишает охраны. Это тоже прямо написано в разъяснениях Пленума. Суд этот абзац процитировал частично и как будто не заметил. 4. Презумпция творчества Сначала суд ссылается на презумпцию (результаты предполагаются творческими, пока не доказано иное), а потом говорит, что истец сам должен доказать творческую составляющую. Логический кульбит получился красивый - но бестолковый. В итоге Суд фактически приравнял работу с генеративным ИИ к отсутствию творчества. При этом не исследовал, как именно создавались объекты, какие были промпты, сколько итераций, какой вклад вносил человек. Позиция спорная и надеюсь будет изменена вышестоящими инстанциями. А как вы считаете: где проходит граница между «использовал инструмент» и «ИИ все сделал сам»? И должен ли суд вообще требовать доказательств творчества, если есть презумпция?

Ответ на предыдущий вопрос. На реализацию фичи у кодекса ушло 12 минут и меньше процента подписки (как было 89, так 89 и осталось). Я не за компом, поэтому пришлось попросить Codex сделать и прислать скриншоты. Вложу их в комментарии. В коде много оверинжиниринга не заметил, только не понравилось, как сделана работа с выкачкой архивов. Но я все равно сейчас откачу назад все изменения! Фишка в том, что в этом проекте у Codex-a есть возможность создавать переиспользуемые UI компоненты в едином стиле. И этот прототип нужен был, чтобы понять то, как эти компоненты должны выглядеть. Поэтому следующий шаг:

I want to manage UI complexity. Load piecemeal mentality and suggest which high level UI components would you implement and pull into the component library

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

🧨 Появился набор скиллов, которые мешают ИИ-агентам делать глупости и сжигать токены — ру дизайнер выкатил 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