Как я проектирую UI/UX (с и без ИИ) 0. Не проектируй интерфейс раньше, чем язык и слова, которыми он будет описан 1. Всегда учитывай Целое Процесс дизайна состоит из трёх шагов: 1) Перечислить все ограничения, под которые проектируется диз; 2) Рассмотреть множество решений, удовлетворяющих этим ограничениям; 3) Если понимаешь, что нужно добавить ограничение или одно можно убрать, вернуться к шагу 1.

ИИ хорошо генерирует варианты, но плохо держит ограничения, поэтому дизайни ограничения раньше, чем экраны

2. Убирай лишнее Убирай ненужное, что все (ты сам, коллеги, ИИ) так любят добавлять. Простой вопрос: "Юзер сможет без этого решить свою задачу?". Ответ в 80%: "да"

Проверяй дизайн на скорость понимания, а не на красоту

3. Дизайни только с живыми данными, ибо они отображают реальность в которой ваш красивый дизайн будет ломаться об длинные тексты. 4. Используйте компоненты, библиотеки и переиспользуемые компоненты. Унификация позволяет систематизировать интерфейс для вас, для пользоателя и для ИИ (помни про ограничения для ИИ).

Проектируй UI для повторного использования UX Гибкость системы = гибкость интерфейса. И наоборот

А если решение работает только для одного экрана, то скорее всего, оно временное. Ищи где UI/UX должен(!) всплывать ещё 5. Заимствовать чужие дизайн-решения не глупо, глупо их не заимствовать, потому что большинство UX-проблем и паттернов уже давно решены. Всё что нужно это опознать ваши, найти подходящее решение и собрать всё вместе. Собранные вначале работы удачные скриншоты от конкурентов/смежных проектов дают более чистое видение проблем и вам и снова полезны для ИИ. 6. Исследуй вкус Предпочтение = это «мне нравится» Вкус = это понимание, почему нравится

Вкус – это рефлексия над собственной реакцией на что-то

7. Никогда не торопись c дизайном 😌

Немного про диегетический UI Просто небольшое, но очень хорошее решение с диегетическим UI из ReStory. Если кто не знает, это такой интерфейс, который существует внутри мира игры. В данном случае это индикатор уровня сжатого воздуха в баллончике для чистки, который находится на самом баллончике. То есть это элемент на предмете, который видим как мы, так и наш персонаж в мире игры. Это классно придумано, потому что повышает иммерсивность и погружение в игру, люблю такие решения. Диегетическим может быть не только интерфейс, это может быть и звук (например, звук, который слышит персонаж в мире игры диегетический, а звук нажатия на элемент недиегетического интерфейса — только игрок). Музыка тоже может быть диегетическая, если она из магнитофона или плеера в игре, и недиегетическая, если это просто фоновая музыка, или это закадровый комментарий кого-то, не нашего персонажа. Хотя если это другой персонаж из мира игры, который рассказывает историю, это уже будет диегетическая штука (диегетический нарратор, если быть максимально точным). Думаю, смысл понятен. По большей части, если что-то можно сделать диегетическим без ущерба для удобства использования и понимания игрока, и если мы не целимся в казуальную аудиторию — лучше так и сделать. Но не всегда разработчики об этом думают, и это чаще чуть сложнее реализовать, поэтому часто отмечаю такие штуки, особенно когда это реализовано хорошо. Здесь, поскольку у нас жанр симулятор, мы стремимся больше к реализму в решениях, в том числе в UI, даже если это чуть сложнее, потому что иммерсивность во многом даже важнее удобства использования (в разумных пределах, разумеется, у нас нет цели делать максимально неудобную игру лишь бы это было максимально реалистично). В симуляторах это довольно тонкая черта между реализмом и условностями, которую не всегда так уж просто провести разработчикам. В Рестори это сделано достаточно хорошо: тут много деталей, но они не переусложнённые и UX вполне удобный, можно быстро делать все основные действия в рамках основного игрового цикла игры. #Restory #gamedesign #narrative #анализ

Ответ на предыдущий вопрос. На реализацию фичи у кодекса ушло 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

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

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

Как 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

Monogram AI Визуальный интерактивный интерфейс для работы с AI агентами. Вместо привычного чата с текстом ребята делают ставку на UI. Задаешь свой запрос "Поесть суши", получаешь карту с адресами, хочешь приготовить печеньку, пожалуйста, красивенький рецепт. Посмотрите фотки. Прикольно наблюдать как классические чат-боты постепенно превращаются в полноценные интерфейсы, супераппы, если хотите. Те самые, настоящие, подстраивающиеся под контекст, а не вываливающие на тебя доски объявлений с плашками сервисов. В каком-то смысле переизобретение поисковиков только без лишних переходов. Удобно, быстро. Думаю тренд подхватят и другие, а ребятам успехов, молодцы. Не зря в июльском топе Product Hunt засветились. Источник #рекомендуетсяизучить

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

Кастомный фичеринг Катите какую-то новую штуку в продукте, подумайте как о ней узнает пользователь. Но не все фичи нужно сопровождать попапами, всплывахами и рассылками. Одна из таких в Яндекс Навигаторе попалась мне на днях. Ребята подсвечивают куда смотрят камеры. Синее поле - если ты в допустимом скоростном режиме и красное, если превышаешь. Узнал об этой функции нативно, стоял на светофоре, смотрю какое-то поле показывают. Думаю о как круто, вау эффект и лояльность продукту. То есть, мне, как водителю, не нужно дополнительно объяснять, что это и зачем. Очевидная функциональность без доп.промо, кайф. Выбор делать фичеринг или нет решается через простые ux тесты на небольших выборках. Дал целевым респондентам задачку с новой функцией, посмотрел справляются или нет, принял решение. Хорошо же❤️ #юиксюайное

Знаете, от чего прям противно? Вот эти вот прогрессбары, которые движутся не от настоящего прогресса, а с предзаданной скоростью. Типа, чтобы пользователь не пугался. В чем вообще идея прогрессбара? Вот у тебя есть N файлов, ты скопировал M из них, и показал на прогрессбаре M / N × 100%. Ну и ты видишь, сколько работы сделано, а сколько осталось. Некоторые прогрессбары даже время примерное до конца показывали! Потом люди заметили, что иногда прогресс неравномерен. Например, с теми же файлами, большой файл копируется дольше, а прогресс мы считаем по количеству. Тогда на большом файле 1% прогресса будет продвигаться дольше, чем на маленьких. Или скачивание из интренета, там вообще непредсказуемо. Если ты начнешь тут считать время, оставшееся до конца, оно у тебя будет плясать — 30 секунд, полдня, неделя, о, снова 30! Пошли сразу шутки, про 99%, про квантовую природу прогрессбаров и так далее. Но — что важно — отображаемый прогресс был связан хоть с чем-то реальным! Можно было поставить курсор мыши на текущее положение, и если оно через 15 минут сдвинулось, значит программа еще что-то делает, а не зависла. Понятно, что прогресс можно предсказать не всегда. Какая-нибудь установка софта, или, не знаю, обработка фотки плагином, короче, какая-то операция, которая не бьется так легко на N шагов, и в которой не всегда понятно, что такое прогресс. Для таких случаев придумали крутилки и недетерменированные прогресс-бары — это такие, в которых полосы нет, а просто все закрашено паттерном и крутится бесконечно по циклу. Типа, идея та же, операция делается, но сколько там прошло и сколько осталось мы фиг его знает. Это все нормальные идеи. Пока что все хорошо. Элементы используются по назначению, коммуникация честная, претензий нет. А потом какой-то маркетолог, или, может, таролог или астролог, в общем, человек с выдуманной профессией, подумал: смотрите. Допустим, мы логиним пользователя. Это сколько-то времени займет. Сколько? Никто не знает. Может, секунду. Может, десять. Вряд ли больше десяти. Но и не мнгновенно. То есть подождать придется. Так? Так. Это значит что? Что пользователь будет переживать. Надо ему что-то показать. Давайте покажем ему детерменированный прогресс-бар! Программисты сразу такие: ну нет, мы прогресс не посчитаем, там сложно, или еще какое-то му-хрю, расписались в беспомощности. И тут мораль/сила воли/система ценностей, которой ни у кого из присуствующих и не было, дала слабину. «Давайте рисовать прогресс от балды!» — сказали они. За первую секунду закрасим 25%. Равномерно, будем добавлять 1% каждые 40 мс. За вторую закрасим, условно, 20%, за третью 15% и так далее. Как только загрузимся, то сразу дорисовываем до 100%, все же радуются, когда кажется, что куча времени еще осталась, а тут хоба и все сразу сделано! Ну а если не загрузимся за 10 секунд, то последние 5% будем тянуть сколько сможем, по какой-нибудь бесконечно приближающейся асимптоте (я уверен, что на том митинге, где это решили, прозвучало слово асимптота, мне нужно хоть что-то приятное про него представлять, иначе хана). Так родилось самое противное изобретение современного интерфейсостроения — лживый прогрессбар. По сути своей он недетерменированный. Но выглядит как детерменированный. Он намеренно лжет и о совершенном прогрессе, и об оставшемся времени. Лжет прямо вам в лицо и не стесняется этого. Еще и выдает это под соусом заботы о пользователе. А ничо тот факт, что мне, как пользователю, нравилось знать, что происходит? Что мне настоящий прогресс, сколь угодно неравновномерный, дороже любых лживых ваших мультфильмов? К настоящему можно было приспособиться, можно было выводы какие-то делать. Им можно было ПОЛЬЗОВАТЬСЯ. А со лживым можно только пить водку, грустно смотреть и плакать. Хватит прятать от меня компьютер! Хватит кормить меня пустыми обещаниями! Я взрослый человек, я хочу знать, что происходит! Я готов принять любой прогресс, пока он правдивый. А обещаниями своими в веб-интерфейсах друг друга кормите.