Как Ant Colony: Wild Forest решила боль в моей игре Есть крутая игра Ant Colony: Wild Forest, которая себя отлично показывает в ГуглПлеи и готовится к релизу в Steam. Вишлистов там дофига) Игра много где сейчас светится в инди сообществах. Обратил на неё внимание, потому что жанр и управление юнитами схоже. Но у меня была боль в понятности нападения/защиты островов (управление армией). Про эту боль я знал с самого начала разработки и откладывал каждый раз. Думал привлекать крутого ГД для решения проблемы или делать брейншторм с вовлеченными плейтестерами (созвоны и обговаривать идеи). Но получилось всё намного легче. Я установил демку игры, зная что аудитория больше 1 млн игроков и значит никто не жалуется на систему управления. Прошел 3 миссии и получил от игры удовольствие (понял что и у моей игры уровень тоже достойный 😅). И как я для себя выяснил у них реализация управления армии точно такое же, как у меня. Отличие лишь только в само UI/UX. У Empires Edge - это панель слева внизу У Ant Colony: Wild Forest - это окно И у них это действительно удобно работает. И так просто решается! В итоге я решил просто сделать также. Но получилось даже интереснее для меня, потому что я обратился к совету ИИ. Тут можете посмотреть видео Показал скриншоты от обеих игр, описал свою боль и попросил сделать референс окна для моей игры. ИИ зная контекст, сделал не просто аналогичное окно, а добавил туда много разной информации, которая мне показалась очень полезной. А сама реализация окна получилось простой. Потому что уже UI в игре есть, использовался тот же стиль и оформление. Функционал тоже весь был. Где-то еще я дорисую UI вместо заглушек. Единственное что, нужно еще обучение переедать под новое окно. А туториал у меня и ввод игрока за руку - просто офигенное - все кайфуют, в том числе я - тут спасибо огромное активному тестеру, который провел около 20 сессий и постоянно предлагает улучшения) И вот такую красоту осталось дать на проверку плейтестерам и получить их фидбек. Ссылка на игру #инди | Telegram | YouTube | чат

AI Design How-to Со студентами доводим до продакшена несколько сервисов и везде стоит вопрос дизайна. Все эти нейрослоповые веб-сервисы с зелено-фиолетовыми цветами и квадратиками всплывающими уже набили оскомину. Поэтому советую им такой вариант по росту сложности, но и потенциальному эффекту. 1. Поставить дизайн-скилл. Есть несколько хороших, мне нравятся https://github.com/Leonxlnx/taste-skill https://github.com/Nutlope/hallmark https://github.com/nextlevelbuilder/ui-ux-pro-max-skill Можно ставить все 3, можно выбрать лучший для ваших задач (не только сайты, но и документы и презентации, например) 2. Использовать Stitch от гугла для дизайна https://stitch.withgoogle.com/ Очень гибкая система с огромными лимитами на постройку/переделку сайтов/приложений 3. Просить сгенерировать дизайн ChatGPT Это один из лучших генераторов картинок на текущий момент и плюс - можно сгенерировать например сотню разных вариантов и потом выбрать лучшие идеи. Лимитов практически нет. Потом просто закинуть в ИИ-ку и попросить сделать вот так 4. Claude Design Вариант скорее для продакшн и больших студий с готовым брендбуком. Старается максимально следовать вашим гайдам и делать хорошо не только сайты, но и презентации Но для маленьких сервисов и презентаций "на выкинуть" скорее оверил, жрущий лимиты. Ну и в целом советую поглядывать или закидывать свои задачи на DesignArena и выбирать модель, что работает с вашими типа графики/визуализации лучше. Вот что на текущий момент получается: Веб-девелопмент (фронтенд) - GPT Sol Веб-девелопмент (фулстек) - Fable, Opus Гейм-девелопмент - Fable Android dev - Opus React Native - Opus SVG - Fable и спец-модель Arrow ASCII-ART - Fable Слайды - Fable и Manus Картинки/графика всех видов - GPT Image и Reve 2.1 Видео - Gemini Omni Flash Аудио - Gemini Сервисы для создания приложений с нуля - Replit (неожиданно), Emergent, Anything и только потом Lovable и прочие, в том числе где-то в серединке Figma Make и Canva https://www.designarena.ai/leaderboard

Театр в продукте — Мгновенный результат, — похвастался основатель ИИ-стартапа по генерации картинок — Добавь театр Бухгалтерская фирма Intuit выпустила софт, который моментально считал налоги. «Мы вам доверили все свои финансы, а вы за полсекунды халтуру подсовываете», — стали возмущаться пользователи. Тогда компания пошла на хитрость: добавила 10-секундную задержку с анимацией «проверяем вашу декларацию...» и проблема решилась. Агрегаторы авиабилетов выводят на экране «проверяем рейсы Аэрофлота... сканируем Победу... смотрим S7...», хотя ответ давно готов. Даже в Claude есть 187 забитых изначально «глаголов размышления». Ценность и удовлетворенность растет, когда потребители видят процесс. Мой товарищ производит технический газ и фасует его в баллоны. В качестве эксперимента взял 10 клиентов, которые жаловались на высокую цену и хотели соскочить. И стал после заказа отправлять им письма типа «баллон проходит поверку», «газ отстаивается», «идет отгрузка со склада»... Жалобы прекратились. А через месяц поднял им стоимость на 10% — и знаете, никто не пикнул. Вывод прост: люди платят не только за результат, но и за представление. Добавь театр — повысишь удержание.

Идеальная отписка Uber Eats — красавчики! У меня на днях списался очередной платёж за подписку Uber One. Классический сценарий, когда забыл отписаться от сервиса, который уже не нужен (на Филиппинах Uber проиграл Grab и при всем желании я не могу воспользоваться их услугами). Захожу в приложение и вижу такой экран в разделе подписки. Ну, думаю, это вы специально так сделали. Дополнительный барьер перед отпиской. Писать в поддержку, ждать ответа… Но оказывается, чат-бот поддержки умеет принимать правильные решения. Описываю ситуацию, мне без всяких подтверждений сразу возвращают платеж на карту и желают всего хорошего в регионе, в котором (пока?) не работает Uber. Обязательно подпишусь назад, если будет возможность! #producteye #ux #subscribtion

Наткнулся в LinkedIn на пост чувака, который предлагает "a little more breathing room" дизайну главного экрана Революта. Объясню в чем проблема таких Dribble концептов. Этот экран генерирует миллиарды долларов выручки. Со стороны, не зная метрик этого экрана и остальных, на которые он разводит дальше, ты никогда не сможешь понять где есть проблемы и точки роста. Ты просто галлюцинируешь. Дизайн как "я нарисовал красивое" умер еще лет 5-10 назад. Сейчас это такая же инженерная профессия, как и большинство других в продуктовой разработке. Ты должен глубоко понимать метрики продукта, клиентские сегменты, конкуренцию по рынкам. В противном случае ты будешь рисовать картинки, которые никому уже не нужны.

Отношения между сценарием и навигацией в интерфейсе При проектировании интерфейса важно проанализировать сценарии, то есть хорошо представить, как именно, в какой ситуации, с какими знаниями, целями и ожиданиями человек будет пользоваться интерфейсом. Многие забывают про это подумать, и у них получается ерунда. Но иногда ерунда получается, даже если про это подумать, а затем просто положить сценарии в основу навигации. Что будет, если просто положить сценарии в основу навигации? Когда сценариев очень мало, может получиться неплохой интерфейс. Если есть всего три-пять действий, за которыми человек приходит в интерфейс, и мы просто делаем для них кнопки, то всё будет понятно и удобно. Это то, что я предлагал для ПВЗ «Яндекс-маркета»: https://ilyabirman.ru/meanwhile/all/interfeys-pvz-yandeks-marketa/ Но такие интерфейсы встречаются редко. Даже в небольшом продукте есть множество связей между функциями, и число сценариев огромно. Если в таком случае начать строить навигационную модель вокруг сценариев, в интерфейсе станет невозможно разобраться. В заметке об архиве вакансий я как раз указываю на эту проблему: https://ilyabirman.ru/meanwhile/all/arhiv-vakansiy-ne-mozhet-byt-podrazdelom-sozdaniya-vakansii/ Когда я говорю про огромное число сценариев, необязательно представлять что-то необъятное вроде Фотошопа. Даже календарь — это уже целый мир разных сценариев. Ну вот, например: Иван понял, что не успевает на регулярную встречу, и хочет предупредить других участников о переносе. Кому-то из них удобнее написать, кому-то позвонить. В ходе одного из звонков Пётр говорит, что давайте тогда уж вообще перенесём эту встречу на час позже, потому что ему самому трудно на неё успевать всё время. Иван смутно помнит, что где-то через пару недель у него запись к зубному, и хочет убедиться, что перенос не конфликтует с ней, идёт проверяет. Выясняется, что конфликтует, но договариваются всё же перенести на час позже, а там, через две недели, просто сделать исключение. Ну и что, как построить навигационную модель вокруг этого сценария? Да никак. Во-первых, если вы хорошо провели анализ, то даже тех сценариев, которые вы рассмотрели и выделили как ключевые, будет довольно много. То есть даже если для каждого из них есть прям готовая кнопка или раздел в интерфейсе, найти их будет не так просто. Во-вторых, остальные сценарии, которых несравнимо больше, вообще непонятно, где надо будет искать. Развивать такой продукт и поддерживать растущее число сценариев — боль. Хороший интерфейс не ведёт по сценариям, он лишь создаёт для них возможности. Он даёт пользователю свободу, чувство контроля, ту самую «агентность», а не просто направляет его по одной из нескольких заранее проложенных дорожек. Разумеется, в календаре нет готовой кнопки или даже «мастера» для того, что описано в сценарии выше. Календарь просто так устроен, чтобы пройти по этому сценарию не составляет труда. Это похоже на вопрос о том, зачем нужны карты и схемы, когда в телефоне и так есть навигатор. Навигатор очень полезен, но с ним ты не чувствуешь себя хозяином положения, не можешь отклониться от пути. Карта же даёт общее понимание того, как устроен мир, и ты уже можешь сам принимать решения. На карте нет специальной секции для сценария «по пути с ребёнком из школы заехать погулять в парк», но она делает этот сценарий возможным без проблем. В навигаторе можно предусмотреть функцию «заехать по пути», но её ещё нужно будет найти, а также десятки других сценариев останутся непокрытыми. Поэтому в основу навигации в интерфейсе нужно закладывать некую модель того, как мы хотим, чтобы человек представлял себе устройство нашего продукта: какие у нас есть сущности, как они связаны, организованы, что они умеют. Эта модель должна помогать нам реализовывать все важные сценарии, а пользователю — находить способы их реализации. И эта модель должна выдерживать развитие продукта.

Ребята поплейтестили 2000+ инди-игр и поделились типичными ошибками. - Почти у половины ужасный онбординг/туториал. Это, к слову, не только к играм относится. У приложений/сервисов тоже часто вижу эту проблему. - Неясны цели игрока. Пункт связан с предыдущим, и ещё сильнее ухудшает воспринятие от проекта. - Метрики в UI без пояснений. Иконки валют, статов и прочего. Даже добавление базового тултипа бы очень помогло. - Проблемы со звуком. У кого-то дефолтная громкость задрана, у кого-то не разделены ползунки в настройках для фоновой музыки и эффектов, а у кого-то и вовсе нельзя громкость регулировать. - У 25% игр нет фидбека на действия игрока. Он что-то делает, но игра никак не сигнализирует, что это даёт и к чему приведёт. - Повальная проблема с UX/UI. У множество игр кривое масштабирование, на большом разрешение UI слишком мелкий. И т.д. По каждому пункту они поделились своим видением того, как можно улучшить. Рекомендую почитать.

Как ИИ агент будет пользоваться вашим продуктом? Я видела много статей о том, как улучшить/упростить свою работу с использованием ИИ. Но вот вопрос - как ИИ будет пользоваться вашим продуктом, чтобы упростить чью-то чужую работу? Интерфейсы b2c продуктов простые и доступные. Продакты и дизайнеры потратили много времени, чтобы порог вхождения был минимальным, а путь максимально простой. А что происходит в дизайне b2b продуктов? Домены, где конкуренция крайне высокая, а продукты востребованы вне зависимости от масштаба и зрелости бизнеса, ИИ агенту разобраться вообще не проблема. В разработке или поддержке для ключевых продуктов есть и внятная тех документация, и понятные интерфейсы и множество инструкций. А в некоторых доменах всеми этими параметрами пренебрегают. Продукт разрабатывается экспертами для экспертов. Вместе с продуктом идет не инструкция, а обучение от вендора или "метод тыка". Тех дока хорошо, если хотя бы частично соотносится с актуальным релизом. Порог вхождения получается высокий. И возвращаясь к вопросу - что сейчас могут сделать продакты, чтобы их продуктом без проблем смог пользоваться ИИ, когда внедрение агентов станет активнее? По своему домену у меня нет конкретного понимания. Частично обучение может быть закрыто большим количеством видео использования продукта экспертом для решений разных задач. Частично - детальной документацией. Но я бы смотрела на задачу на шаг назад - по какой причине получается такой высокий порог вхождения и как его можно упростить. Чтобы с новыми релизами и апдейтами не приходилось в том числе переучитывать агентов В целом, я пока не видела по отрасли рассуждений на тему, как ИИшечка будет помогать работать пользаку в моем продукте. Заранее не согласна с идеей "пусть пользак сам разберется, как использовать агента". Адаптация под ИИ в какой-то момент скорее станет УТП, а потом и базовым минимумом. Во-о-от. Расскажите, чтоль, держите ли вы в голове, что вашим продуктом рано или поздно начнет пользоваться ИИ. И что делаете, чтобы агент влился в использование продукта максимально быстро

Несколько мыслей про AI 1. Лучший способ изучать AI- решать свою настоящую проблему Возьмите реальную задачу. И попробуйте решить её AI. Потому что именно реальная боль заставляет менять привычки. 2. Разговор становится новым интерфейсом Раньше интерфейс проектировали. Теперь проектируют диалог. И это новая дисциплина. Фактически появляется UX нового поколения - Conversation Design, а также голос как способ взаимодействия. И тут важно, что входящий поток сознания нужно уметь структурировать. 3. Будущее - не универсальные модели. Будут вертикальные AI. Visual AI. Legal AI. Medical AI. Financial AI. То есть отраслевые модели. 4. Конкурентное преимущество возникает не из доступа к модели, а из накопленного доменного знания. Выигрывает тот, кто лучше знает отраслевой процесс 5. AI резко снижает стоимость межфункционального взаимодействия и уничтожает координаторов, но резко повышает ценность людей с глубоким пониманием предметной области. 6. AI требует другого отношения к продукту Сегодня продукт одинаков для всех. Завтра каждый клиент будет получать свою версию продукта. Не сегмент, не тариф, а персональную конфигурацию. AI постепенно разрушает саму идею массового продукта.

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

Скилл, сэкономивший мне несколько часов в неделю Я часто говорю, что в продуктовой аналитике нужно комбинировать количественный и качественный подходы. Один из инструментов, который сидит где-то посередине между ними: просмотр записей сессий юзеров (clarity, веб визор и иже с ними). В лучших традициях эмпатического проектирования, когда вы наблюдаете за пользователем в естественной среде. НО этот инструмент очень требователен к времени продакта: даже в ускоренном режиме на такую работу приходится тратить часы в неделю, причем это не самое классное времяпрепровождение, если уж быть честным. Хотя там регулярно встречаются прямо уж "золотые инсайты". Собственно, дружбан, вооруженный браузером, мог бы это делать - не так ли? Собственно, такой скилл я и запилил; обкатал на просмотре 500 сессий через clarity mcp. Как работает: 1) Сначала определяем вопросы, на которые хотим получить ответ: например, почему юзеры не подключают LinkedIn 2) На основе вопросов определяется какие сессии взять на "просмотр" 3) Триаж сессий: по таймлайну сессии отбираем насколько она "интересна" для анализа 4) Далее для каждой сессии берем все евенты, в определенные моменты в том числе берем скриншот и анализируем 5) Триангулируем выводы: по базе данных, по исходникам. 6) Анализируем мертвые клики (dead clicks), так как зачастую это классный источник UX проблем 7) Получаем отчет Из неожиданного: отчет для каждого вывода дает ссылки на исходные сесси и в ходе "человеческого" просмотра одной из них я понял, что важно смотреть не только фреймы перед кликами и тп, но и без оных. Потому что тогда можно поймать проблемы типа "непонятная надпись" или "отсутствует call to action". https://github.com/BayramAnnakov/clarity-session-review Юзайте на здоровье и присылайте улучшения/принципы по мотивам ваших инсайтов

Обновление Яндекс Музыки, которое вызвало шквал возмущения в соцсетях, критиковали внутри самого Яндекса перед релизом, но эффективным менеджерам было плевать Яндекс Музыка выкатила большое обновление в конце мая. Само обновление было давно, но мне попал в руки скриншот из внутреннего мессенджера с обсуждением этого релиза. Расскажу контекст. Яндекс предлложил юзерам новый инновационный сценарий взаимодействия с приложением — это выбор настроения треков. То есть не свои подборки или определённый жанр музыки, а именно настроение, сформулированное долбоёбскими AI-слопными формулировками: «неделя до диплома (ааа)», «свидание 10 из 10» или «секс под грустную музыку». Вдобавок дизайнеры накрутили некоторые спорные решения, например, кнопки «вперёд/назад» убрали с экрана трека, потому что по задумке перелистывание настроения важнее. Прило стало лагать на слабых девайсах, а некоторые любимые пользователями функции переместили подальше так, что их не найти. Пользователи были в ярости. Вот цитата самого популярного отзыва на Пикабу (орфография автора сохранена): Яндекс.Музыка, хотите отзыв? Идите НА ХУЙ с такими обновлениями. Вот реально, я максимально лояльный пользователь, по жизни вежливый и культурный, но ваше приложение, а точнее — ее обновление, просто вывело меня из себя и сдерживаться я не буду. Вы делаете ГАВНО! И за мои же деньги, мать вашу, вы меня им кормите! Сотрудники Яндекса, которые тестировали приложение до релиза, говорили, что получается плохо, но руководство Я.Музыки отвечало на это примерно так: вы просто не понимаете проблематику и внутреннюю кухню сервиса, а мы понимаем. Релиз обсуждали долго, сотрудники несколько раз пытались донести, что сервис совершает ошибку. Пипл схавает. Какая разница? Последствий всё равно не будет, аудитории некуда переходить. Яндекс монополист с более чем половиной российского рынка стриминга. Тем более по инфе из официального пресс-релиза новый интерфейс повысил такие важные метрики для пользователя, как переход на страницу артиста на 11% и уменьшил количество дизлайков в «Моей волне» на 4%. К посту приложил скрин из корпоративного мессенджера Яндекса с хронологией внутреннего спора о новом дизайне Я.Музыки от одного из сотрудников. И вот самое интересное там: 0. Зацените этот пассивно-агрессивный тон вкупе с корпоративно-ебланским языком. Это владение на уровне мастера. 1. Вы удивитесь, но в самом Яндексе признают агрессивную монетизацию своих сервисов, их перегруженность и неудобство, рекламу на каждом квадратном сантиметре и дарк-паттерны. 2. В Яндексе тоже считают, что в подписку Яндекс Плюс в нагрузку включены ненужные сервисы. Подписка дорожает, а качество этих сервисов ухудшается. 3. Ну и вишенка — работники Яндекса НЕИРОНИЧНО на серьёзных щщах называют себя «яндексойдами».

Помните я радовался, что подключил MCP в Lovarus.ru?

MCP - это протокол благодаря которому нейросеть может взаимодействовать с внешними системами.

Так вот, сегодня я проснулся, и меня озарило - это все дешевые понты. Какой MCP для сервиса, у которого целевая аудитория - люди без технического опыта?! Кто в здравом уме пойдет тратить время на регистрацию в каком-то Context7, а потом тащиться в Lovarus с API ключом?! Сервисы типа Lovarus должны сами на себя брать подключение нужных MCP, и пользователь даже не должен знать ничего о них. Короче, решил выпилить эту штуку в ближайших релизах, а точнее скрыть для юзеров. Тоже самое с кнопкой «Исправить», для прогера это прикольно, он привык видеть ошибки, и когда они исправляются по клику на кнопку - это прикольно. Для предпринимателя, фрилансера, кнопка «исправить» - это лишняя фрикция, трата денег и времени. Короче две ближайшие цели, упростить сервис, скрыть технарщину под капот, на выходе только готовый рабочий результат.