Как я делаю дизайн, UI и UX Друзья, спешу поделиться с вами свежими приемчиками. Осваивал тонкое искусство производства интерфейсов и открыл для себя новый flow. Работает так - Берём какую-то идеи/задачу и описываем ее Клоду/Кодексу, просим собрать контекст. Дальше подключаем Mobbin MCP и просим агента найти релевантные интерфейсы. Изучаем что он там нашел и просим использовать генерацию картинок, для того что бы сделать прототип интерфейса. Вместе доводим до ума и дальше просим написать план по материализации проекта в код. Запускам план в ультра режиме - и готово! Намного подробнее и с примерами читайте в новом блог-посте: https://getsweat.ai/blog/from-mobbin-to-a-working-dashboard/

Есть такой раздел Instant Messaging в LinkedIn. В нем представлены четыре мессенджера на выбор, два из которых уже давно закрылись (Skype и Google Hangouts), два подходят только для китайских пользователей. Огромная компания, за которой стоит Microsoft, большие бюджеты и амбиции, а до маленького списка в настройках руки не доходят. Понятно, что удаление этих пунктов вряд ли вообще как-то повлияет на метрики. Всегда найдётся задача поважнее, но выглядит неряшливо: хочешь оставить способ связи, а тебе предлагают закрытый сервис. Такие мелочи тоже формируют впечатление от UX. Я как-то писал про "Paper Cuts" в Amazon, команды, которые специально занимаются мелкими недочётами. Потому что команды, занятые большими задачами, до них просто не добираются. Мне этот подход очень нравится. Кажется, LinkedIn такая команда тоже пригодилась бы. Чтобы кто-нибудь наконец открыл настройки и посмотрел, что там осталось.

Зелёный огонёк, что программа исправна У меня очередной пример того, как можно сделать дикий интерфейс и не заметить этого. Дизайнер работает над сложным внутренним продуктом, показывает интерфейс и говорит: — Тут просят в уголке добавить индикатор связи с сервером, какой-то зелёный огонёк. Но в наших макетах место для такого индикатора не предусмотрено. Куда его тут приделать? Я как обычно перевожу тему и спрашиваю: зачем работнику знать, есть сейчас связь с сервером или нет? Выясняется, что всё реализовано так, что если работник что-то делает, а связи нет, то его действия могут не сохраниться, и тогда потом ему придётся что-то перепроверять и переделывать. Этого нужно избежать, поэтому очень важно, чтобы всегда было видно состояние связи. И вот здесь мне интересно, дорогие читатели: вам уже очевидно, что происходит какая-то хрень, или пока рассуждение кажется логичным? Я задаю следующие вопросы. Вот работник работает, у него пропал зелёный огонёк. Допустим даже, что он это заметил. Что он должен решить тогда, какого действия мы от него ждём в этом случае? Оказывается, если связь пропала, работник должен то ли временно перестать работать, то ли что-то перезагрузить, то ли позвать старшего, то ли ещё каким-нибудь способом разобраться с проблемой. Но в нарушение принципа «Без обучения» об этом нигде не сказано! Работник должен где-то заранее, из других источников, узнать, что отсутствие зелёного огонька означает необходимость каких-то действий, и не забыть об этом: https://ilyabirman.ru/meanwhile/all/bez-obucheniya/ Допустим теперь, наш работник всё это знает и помнит. Представьте: работа кипит, экраны сменяют друг друга, работник жмёт кнопки. И вот в уголке пропадает зелёный огонёк. Но остальные-то 99,99% экрана продолжают выглядеть так, будто всё в порядке и можно работать дальше. Мы зачем-то показываем человеку рабочий интерфейс, хотя сами уже знаем, что пользоваться им сейчас не надо; надо звать старшего и вот это всё. Это какой-то издевательский тест на внимательность! Вместо того чтобы явно сказать: «стой, связь потеряна, подожди или позови старшего», мы прячем эту информацию за тоньшайший намёк и надеемся, что он его считает. Не надо так.

Всю жизнь я работаю с компьютерами, и главный выработанный мной скилл — не удивляться тупизне и абсурдности происходящего. В обычной жизни как? Есть важное и есть неважное, есть срочное и есть не срочное, есть сложное и есть несложное. И люди как-то эти вещи соотносят. Скажем, улетит ли рейсовый самолет, если пилот забыл дома пилотку? Скорее всего улетит. Будут ли у вас дотошно проверять билет, если ваш поезд уже отходит с перрона? Ну, скорее всего вы сначала запрыгните, а потом уже билет. Мама наказала сходить в магазин, а где деньги лежат, не сказала. Но ты в принципе все равно знаешь, где, поэтому сам нашел, взял и сходил. Логично, да? Ну вот, а в компьютерах не так. Там работает так называемая «формальная» логика, то есть все вещи имеют одинаковую бесконечно большую важность, а все процессы принципиальнее девственницы на первом свидании. Из-за этого комьпютеры ставят обычных людей в ступор: ну вот же файл лежит, почему ты сам его не мог взять, почему мне надо тебе явно на него указывать? Зачем мне нажимать на эту кнопку несколько раз, я же уже сказал, чего хочу! Почему компьютер меня не помнит, я же им пять минут назад пользовался? Почему таблицу из этой программы нельзя вставить в эту, они же одинаковые? Почему нельзя выключить подсветку клавиатуры, не зарегистрировав аккаунт? Зачем вообще клавиатуре аккаунт? Почему после установки что-то сломалось? Зачем вообще в компьютере процессы, которые что-то ломают? Почему этот сайт не открывается, хотя вчера открывался? Почему открывается на твоем телефоне, но не на моем? Почему этот провод передает данные в одну сторону, а не в другую? Он же одинаково с обоих концов выглядит. И так далее. Вооот. Так что наша ценность, как специалистов, и наша бремя как людей, это умение через этот булшит продираться, не теряя рассудок и даже не сильно ухудшая настроение. Некоторых, правда, сильно деформирует профдеформацией, и они начинают считать компьютерную логику нормальной. А потом удивляются, что она не работает. «Приходи в гости в любое время» — в смысле нельзя было приходить в любое время? Может вам еще и как дела у меня не интересно? А зачем спрашивали? Вы не поверите, но это все было вступление. Просто зафиксировать ситуацию. А теперь открытие: я понял, что в агентах/ЛЛМах ощущается как магия. ЧТО У НИХ СНОВА НОРМАЛЬНАЯ, ЧЕЛОВЕЧЕСКАЯ ЛОГИКА. Говоришь им: пойди проверь. И он идет и проверяет. Не спрашивает, что, где, куда, откуда, сколько, у кого ключи взять, а ой введи пароль, скопируй, пермишны поправь, и шелл новый создай. Просто идет и делает. По важному спрашивает. По неважному сам решает. Попросил в файле посмотреть, но в названии опечатался? Он посмотрит в нужном. ПОТОМУ ЧТО ПОНЯТНО ЖЕ ЧТО ТЫ ИМЕЛ В ВИДУ. Нужно найти информацию — найдет. Нужно сделать какой-то сайт — сделает КАКОЙ-ТО, а не вынет тебе всю душу пониманием задачи. А иногда еще и ответ оформит так, как тебе было бы удобнее всего ответ потреблять. Даже если ты его не просил. Потому что ПОНЯТНО ЖЕ, что ты хочешь удобно. Кто вообще в жизни когда-либо хотел чтобы неудобно. Короче, компьютеры из абсолютно тупого деревянного безынициативного вахтера с комплексом бога и вниманием к деталям как у Шерлока Холмса превратились в почти нормального человека, с которым можно иметь дело. Просто наконец-то хоть чуть-чуть выдохнуть можно. Но недетерминированные, да.

Как встраивать ИИ в продукт Полезно продактам, CPO и тем, кто сейчас автоматизирует команды и процессы. 1. ИИ может ухудшить ваш продукт. Он может быть медленным и ненадежным, или же решать проблему, которой ни у кого нет. Тот факт, что это ИИ, еще не означает, что его стоит разрабатывать. 2. Подумайте, нужно ли вам вообще разрабатывать ИИ. Зачастую лучше сначала создать что-то для ИИ, например, сервер MCP. Их проще создавать и поддерживать. 3. Ищите jobs to be done, а не демо. Лучшие возможности для ИИ — это задачи, выполнение которых занимает более 30 секунд, использующие код или интерфейсы, которые пользователи не знают (например, SQL), или задачи, которые пользователи повторяют более 20 раз 4. Онбординг — отличная первая цель. Визард установки с ИИ выполняет работу, занимающую два часа, за 8 минут. 5. Не спрашивайте: «Как добавить ИИ в это?» Спрашивайте: «Как выглядит agent-first-версия этого?» Такой вопрос заставляет переосмыслить jobs to be done для agent-first-будущего и помогает не быть разрушенным ИИ-native конкурентом. 6. Создание продуктов «формата 2030 года» может потребовать начать с нуля и отказаться от накопленных за годы UI-решений и допущений, которые больше не актуальны. 7. Следите за клиентами, которые пересобирают ваш продукт с помощью ИИ. Это показывает, какие функции им действительно нужны. Когда клиенты создают собственный прототип вашего продукта с помощью MCP и Claude Code, — нужно добавить в продукт больше настраиваемых «canvas»-артефактов. 8. Валидируйте ИИ-концепты также, как новые продукты. Запишите, по каким критериям будет оцениваться результат и какой runway у инициативы. Спросите, насколько команда будет разочарована, если её потеряет (PMF-опрос). 9. Опишите, как ваш продукт проигрывает ИИ-native угрозе, а затем профинансируйте собственную версию этого «атакующего». Даже лучший продукт поддержки проиграет продукту, где ИИ отвечает на все тикеты, — вероятно, поэтому Intercom так сильно развернулась в сторону Fin. 10. Ответьте на вопрос: чем это лучше Claude? Именно к нему люди обращаются по умолчанию. Ваш moat — это контекст: функциональность продукта, данные пользователей, а также инструменты и skills, которые вы построили. 11. Сосредоточьтесь на общей ИИ-инфраструктуре. Сделайте примитивы — промпты, стриминг, согласия, evals, задачи и аналитику, — которые продуктовые команды смогут расширять и встраивать в свои продукты. Выберите единый UX-паттерн, чтобы избежать «смерти от тысячи виджетов», а затем не мешайте командам. Продуктовые команды лучше знают своих пользователей, а не ИИ-команда. 12. Позвольте агентам запускать код. Исполнение кода даёт агентам возможности beyond predefined tools. 13. Позвольте агентам делать всё, что могут делать пользователи. Если есть инструмент создания эксперимента, но нет инструмента его запуска, агент сделает всё остальное и остановится, чтобы попросить вас кликнуть по UI. Это ограничивает возможности агентов. 14. Тестируйте продукт headlessly, чтобы развить «эмпатию к агентам». Проверяйте агентные фичи через CLI, чтобы сталкиваться с теми же точками трения, что и они. 15. ИИ не убивает ваш UI — он меняет его назначение. Меньше экранов для выполнения действий, больше — для одобрения, проверки и отмены действий агентов. Стройте UI, когда текста недостаточно. 16. Управляйте агентами на их уровне абстракции. Агенты работают лучше, если позволить им гибко писать и рассуждать. Перестаньте заставлять агентов использовать предустановленные query-инструменты и разрешили им писать собственный SQL. 17. Настройте ИИ-observability с первого дня: - Трейсите LLM-вызовы: входы, выходы, latency и стоимость. Это выявляет ошибки и проблемы, исправление которых даёт быстрый рост качества. - Отслеживайте использование агентами так же, как использование людьми. Агенты не генерируют pageviews или rageclicks, но можно отслеживать вызовы MCP-инструментов, запросы страниц и другое. - Используйте evals, но начинайте с малого. Вручную читайте трейсы, чтобы найти места, где ИИ ошибается. Создайте eval для проверки этой проблемы и улучшайте продукт, чтобы улучшить результат eval. Даже небольшие golden- или синтетические датасеты давали огромный прирост качества по сравнению с обычным циклом разработки. 18. Изучите unit-экономику ИИ-продукта. Наш визард стоит $6,67 за запуск, но улучшенная активация и retention стоят дороже. Переход трейс-саммари со стандартного gpt-4.1-nano на flex-уровень gpt-5-nano вдвое снизил затраты. 19. Многие сбои агентов — на самом деле сбои контекста. Добавление агенту значительно большего объёма контекста улучшило эффективность визарда сильнее, чем улучшенное reasoning, многошаговое планирование, субагенты, pruning и compaction. И Сделайте так, чтобы люди могли легко создавать контекст, которого агент не знает. 20. Прозрачная компания полезна для агентов. Ваши Агенты и агенты клиентов могут смотреть в кодовую базу, handbook и документацию, чтобы лучше понимать, как работает ваш продукт.

Не заставляйте меня думать Claude раньше на стартовом экране выводил текстовое поле с заголовком «Опишите, что создадим сегодня». Предполагалось, я расскажу — ИИшка сделает за меня. За 2 года ни разу не воспользовался этой функцией. А сегодня наткнулся на исследование: ребята показали три разных версии стартовых страниц 10.000 пользователей. На первой было текстовое поле с заголовком «Объясните, что хотите получить, и наш ИИ-агент сделает это»; на второй — кнопка «Зарегистрироваться с Google»; третьей — ссылка «Зарегистрируйся бесплатно». Остальное было одинаково. Победил вариант с кнопкой Google; а проиграл (причем по всем показателям — регистрациям, активациям, покупкам) — вариант с ИИ. Казалось, объясни и получишь результат. Но нет — думать неохота, а вот нажать кнопку — легко.

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

Если вам тоже решительно нечем заняться этой ночью, то вот вам идеальный способ убить время и заодно сжечь пару миллионов нервных клеток. Кто-то запилил гениальную в своей мерзости браузерку, где ваша единственная задача это отменить подписку. Сначала кажется, что всё просто, но сайт постоянно достаёт из широких штанин буквально все ублюдские дарк-паттерны, которые маркетологи придумали за последние двадцать лет: кнопка отмены закопана где-то на девятом круге ада, интерфейс давит на жалость, агрессивно спамит баннерами со скидками в 99%, а если вы чудом пробрались через весь этот ад, на вас натравливают финального босса (оператора техподдержки по имени Деннис в чате). А ещё веселит статистика на сайте: из 5400 попыток почти 2000 человек даже не смогли найти нужную кнопку, 2270 дожили до переписки с Деннисом, и только 1950 смогли отменить подписку. Короче, если спать не хочется, а сжечь себе жопу желание есть — вэлкам: https://www.fundrstudio.com/games/cancel-your-subscription/

Пробежал Heavy Rain Или "у нас есть механика гуляющих раздражающих NPC, мещающих пройти главному персонажу, и это настолько удачно, что мы её вставим в игру как можно чаще" (сарказм, само собой). Сначала я хотел написать, что "прошёл, чтобы вам не пришлось", но думаю, всё-таки можно посоветовать игру с некоторыми оговорками, о чём напишу чуть ниже. Пройдя игру я понял, как сильно и в лучшую стороны изменился UX за прошедшее десятилетие. Это одна из самых раздражающих по механике игр, в которые я играл за последние, наверное, лет 15. Но при этом, это одновременно одна из самых любопытных по истории игр, в которые я играл за это же время. Здесь не всё идеально по истории, на мой взгляд, есть лишние персонажи, которые очень слабо раскрыты, тот же агент ФБР, и его концовки тоже не так интересны, особенно по сравнению с концовкой основного героя (постараюсь тут без лишних спойлеров, поэтому без имён). Однако, сама история всё ещё довольно хорошая, крепко сбитый детектив, где есть все основные элементы хорошей приключенческой истории. И отдельный лайк за минимум мистики и потусторонней ерунды, особенно в сравнении с Фаренгейтом. По механикам игра мне показалась очень слабой. Управление персонажем адски неудобное, область взаимодействия с предметами это прямо отдельная боль. Ну и направляют персонажей здесь, ну, почти никак. Это кстати к вопросу о том, что в таких проектах левел дизайн не особо нужен. Ещё как нужен) Плюс ко всему, у меня частично не заработал DualSense, игра просто отказывалась регистрировать некоторые движения правым стиком, по итогу я частично управлял с клавиатуры и мышки. В итоге справился, но этот момент преследовал вплоть до самого конца игры. Понятно, что проекту уже много лет, но учитывая, что он довольно культовый, грустно, что не подружили с последним актуальным контроллером и не починили вылеты. Ну и время загрузки удивило, такое впечатление, что там стоит какой-то искусственный дилей на это всё, чтобы было время насладиться крупными лицами персонажей) В итоге прошёл на почти самую лучшую концовку и думаю, что могу порекомендовать проект, если любите хорошие детективы и интересных персонажей, но в современных условиях придётся пострадать: механики здесь во многом чтобы быть, а не чтобы игроку было интересно. Ну и UI/UX прям плох. Я редко такое говорю про отдельный аспект игры, но здесь можно) Игру часто отдают по скидкам на разных распродажах. Если соберётесь, лучше всё-таки играть с клавиатуры и мышки. #HeavyRain #пробежал #мнение

Цена — это не только про деньги При разработке клиентского опыта важно учитывать не только прямые затраты, но и так называемые поведенческие издержки — время, усилия и сложность, с которыми сталкивается человек, чтобы получить ваш продукт или услугу. Особое значение имеет восприятие времени. Если клиент уже включился в процесс, он будет терпимее к ожиданию, особенно если это ожидание организовано с комфортом. Хороший пример — автосервис, где клиенты могут скоротать время в уютной зоне с Wi-Fi и напитками. Это превращает «время ожидания» в «время с пользой». Неопределённость тоже играет роль: когда клиент чётко понимает, сколько займет процесс и к какому результату он придёт, он легче переносит даже длительные этапы. Возьмём интернет-магазин: после того как компания убрала обязательную регистрацию перед покупкой, количество заказов выросло на 45%. Чем проще и прозрачнее взаимодействие, тем легче человеку принять решение о покупке. Удаляя лишние шаги, вы снижаете нагрузку на клиента и повышаете конверсию. Фаундер | Бизнес и Стартапы

Как перестать галлюцинировать про хотелки юзера с помощью эмпатической карты Несу вариант, как переосмыслить результаты старого-доброго пользовательского интервью с командой с помощью эмпатической карты. Как выглядит финалочка - на картинке. Для контекста: эмпатическая карта (Empathy Map) - это фреймворк, который собирает качественные данные о пользователе в 4 квадрата вокруг его личности: что он говорит, делает, думает и чувствует. Инструмент нужен, чтобы перестать спорить о продукте из личного опыта и увидеть живой контекст конкретного сегмента. 4 момента, которые нужно помнить при ее создании: 1. Каждый стикер только с пруфом. Не можете показать ссылку на цитату из интервью или тикет поддержки? Это фантазия команды, а не позиция пользователя. Все гипотезы клеим строго отдельным цветом. 2. Жестко разделяйте "делает" и "думает". "Делает" - это наблюдаемое поведение в аналитике или на видео сессий. "Думает" - домыслы команды. Половина провальных фич рождается из проектирования под придуманные мысли вместо реальных действий. 3. В блоке "чувствует" фиксируйте точный триггер. Не просто "тревожится", а "тревожится, потому что не понимает, прошёл ли платёж". Эмоция с понятной причиной - это сразу готовая задача в бэклог. 4. Финал карты - это решение, а не красивая доска. На выходе должно быть четко зафиксировано: что меняем в онбординге, какой вопрос несём в следующее интервью, какую фичу режем. Без решения упражнение было бессмысленным. Пример из практики: B2B-сервис терял пользователей на импорте базы. Команда собиралась перекрашивать кнопки. Разложили звонки на карту и увидели главный страх: клиенты боялись сломать свой текущий учет. Починили не UI, а чувство безопасности, добавив режим "песочницы". Итог: рост конверсии в активацию в 2.5 раза. Источник: https://www.nngroup.com/articles/empathy-mapping/ #PG_education @productgames