Дизайн Домашка

Подход Intent-Driven Interface. В предыдущем посте закинул вам тему на подумать, как быть когда в работе исчезают привычные этапы создания макетов, а ваша роль — описание системы в которой дизайнер фактически создает визуальный язык. А сами шаги и элементы на странице собираются уже под подребность при помощи AI... Ловите короткое видео с деталями: в чем суть подхода и как это работает в примерах. #edu Не стесняемся лайкать, если соскучились по коротким и полезным видео в канале 😌

Роль дизайнера меняется на глазах. Рисовать каждый экран руками постепенно перестает быть основной работой. Сейчас задача дизайнера – это задать систему и направить агента, который собирает интерфейсы по ней 😎 Речь не о том, что AI заменит дизайнера. А о том, что происходит апгрейд роли: из того, кто рисует экраны руками ➡️ в того, кто проектирует систему и ведет процесс. А вместе с этим расширяется и сам круг задач. Дизайнер все ближе подходит к продукту и берет на себя то, что раньше делили между собой несколько человек. Бизнесу такой специалист ценнее, и спрос постепенно смещается в эту сторону. В первую очередь, это касается работы с большими дизайн-системами, где руками уже не вытянуть. 😎 24 июня в 18:00 мск Даниил Шишко из Pixel Perfect покажет, как заставить агента работать строго по твоей дизайн-системе, а не придумывать свое. Возьмет одну из самых больших публичных ДС, подключит ее к агенту и соберет из нее экраны прямо на эфире. Тем, кто будет онлайн, отдаст скилл, который подготовит дизайн-систему к работе с агентом. Берешь свою ДС и повторяешь. 🥹 Эфир пройдет в тг-канале Даниила. Подписывайся

Я конечно очень хочу написать вам пост в котором расскажу, как мы нейронки в дизайн внедряли… и как это все изменило (или нет). Но это позже... Просто сейчас приходится разбираться с гораздо более сложно штукой. Представьте проект, в котором дизайнер не проектирует сценарии напрямую. Внутри проекта огромное количество функционала и ролей, есть дизайн система, но нет вообще макетов. AI во время взаимодействия с пользователем динамически собирает интерфейс под задачу, контекст и состояние пользователя. Один и тот же запрос может приводить к появлению разных пользовательских путей, которые никогда не были нарисованы вручную. В такой модели роль UX-дизайнера — аудит всего нового, что появилось в системе. Основная работа смещается от проектирования сценариев к исследованию и управлению их генерацией. Нужно анализировать возникающие пользовательские пути, выявлять неэффективные паттерны, корректировать правила системы и контролировать качество решений, которые принимает AI. Объектом проектирования становится уже не интерфейс, а система, порождающая интерфейсы. Мы видим сколько система создала новых связей, зависимостей, как они превратились в интерфейс (который видит пользователь), с какой частотой это произошло, какие есть вариативности. Как это повлияло на визуализацию? Можно ли какие-то созданные паттерны объединить и сделать базовыми? Чтобы было понятнее, вспомните как работает навигатор — даже если вы проезжаете мимо своего поворота он перестраивает путь и подсказывает, что изменилось. Такой же подход с системой, которая собирает макет в момент перехода на следующий шаг. Вместо вопроса:"На какой экран перейти?»… система задает вопрос: "Что пользователь хочет получить?», после чего сама строит путь. Этот подход называется Intent-Driven Interface — концепция, в которой основой интерфейса становится не набор функций или экранов, а намерение пользователя (intent). Напоминает Чемпионат Мира по футболу: все игроки определены, цели понятны, правила заданы, но как пойдет каждый конкретный матч мы не знаем. А когда все случится, нужно сесть и проанализировать "что это вообще было и почему". Я сталкивался с таким подходом лет пять назад, но тогда это все уперлось в то, что система плохо понимала намерение и команда отказалась от реализации. А с LLM это уже не выглядит rocket science. Тут дальше можно спорить стоит ли игра свеч, если вы ставите, что любой интерфейс через 5 лет будет выглядеть как chatgpt… но если ваш прогноз другой, то навык определения уровня качества реализованного нейросетью результата становится вашей базой. 🧡 Лайк, если стоит рассказать детальнее.

На старт, внимание… скоро начинается RDC 2026! Конкурс-легенда. В 2019 у нас работал победитель очередного тура — я даже не представляю как нам удалось выиграть эту гонку среди HR, которые кружили вокруг его портфолио. И тогда же я вел оффлайн-батл, финал RDC, когда дизайнеры создавали дизайн сайтов в прямом эфире, прямо за мониторами на сцене. Сейчас участие онлайн и есть возможность пройтись по всем задачам. Три тура — три шанса получить денежный приз и пройти в финал. Классный опыт и возможность засветиться перед работодателем. Думаю, что после конкурса сделаю свой разбор задачек. Тем более, что они устроены по принципу тестовых заданий при приеме на работу UIX-дизайнера. Работы на первый тур принимаются до 5 июля. Регистрируйтесь — russiandesigncup.ru

🐤🐤🐤 Разбор, первая часть. UIX Задача про расставание с коллегами. Эта задача про роль и функцию, которые закреплены за отдельным человеком (интересно, мы также будем переживать когда будут отключать твой любимый бот?)... Наша проблема не в том, что человек покидает компанию, а в том, что функция/роль может перераспределяться на кого-то нового, на нескольких людей, и даже лично на вас как пользователя. Круто, если решая задачу вы добрались до самого сложного: спрогнозировать уход — самое простое, а вот ответить на вопрос "Что Делать Дальше?", если человек уже ушел или это событие так близко, что вы не успеете среагировать. Интерфейс может помочь тут в очень многих местах и сэкономить тонну нервных клеток. Интересно, если бы выходили на работу — вам было бы интересно глянуть сколько запросов и реакций пришло в ответ на карточку про уход из компании того, кто был до вас 😅 ? Смотрим видео #razbor

✅ UIX Задача про расставание с коллегами / решения. Файл с решениями участников тут. В среднем на задачу участники потратили времени примерно одинаково — 2-3 часа, но уровень проработки довольно разный. Видно, что некоторые участники довольно эмоционально восприняли тему 😅💀 — "ушел так ушел, отпуская- отпусти"... что несомненно отразилось на копирайте и выборе цветовой темы. 1) смотрим задачу 2) прикидываем в голове как бы вы решили ее 3) смотрим решения участников и сравниваем со своим решением "которое было в голове" 4) ждем разбора, который выложу на днях ⚡️

🌞 UX-задача мая (2026) 🌞 Спроектируйте mobile flow для HR-сервиса внутри компании. Суть сервиса: он показывает сотрудникам, кто и когда покидает компанию навсегда (например, решил уволиться) или на длительный период (например, уходит в отпуск на месяц). Система должна помочь коллегам не потерять важные договоренности, задачи, контекст и зависимости, связанные с этим человеком. Продумайте: • зачем компании нужен такой сервис; • почему такой сценарий оповещения может быть полезен сотрудникам. На примере главного экрана покажите максимально насыщенный информацией сценарий. Также уточните, для каких сценариев и задач этот экран может быть точкой входа. Чтобы лучше раскрыть идею, вы можете показать несколько состояний одного и того же экрана в зависимости от контекста. Достаточно low-fi wireframes/prototype без детальной визуальной проработки. Визуальный дизайн не важен — важны логика и то, как вы мыслите о сценарии. Дедлайн: воскресенье (24 мая) 23:30 Присылайите решения

Итак, UX-сценарий победил в этой неравной борьбе 😅 так что начнем... Итак, достаем листочки и разминаемся для решения задачи. Как обычно, большая часть решения будет у вас в голове — подумайте над текстом задачи пока едете на работу или бродите по магазину. Задача уровня midddle+ Предыдущие задачки можно посмотреть в figma-файле. 🚀🚀🚀 Ссылка для приема решений — тут.

(Продолжение поста) … Если не можете переделать сценарий совсем, повышайте Fault-tolerant UX. Это подход, когда система предполагает, что будет все плохо или даже хуже (все зависнет, часть данных будет недоступна, сервер затупит, интернет закончится, скрипт сломается)... но даже так, пользовательский сценарий не должен разрушаться полностью. В чем проблема чаще всего? Есть сценарии завязанные на ресурсы, которые закончатся или изменят свои свойства пока вы ждете синхронизации… Все ваши танцы с бубном последние 40 минут будут бессмысленны, если товар закончился, или прошел период доступности (концерт прошел, самолет улетел). Прикиньте, какой из знакомых вам сценариев, с которыми сталкиваетесь в приложениях каждый день. можно было бы переделать под такой фоормат? Теперь смотрю на интерфейсы из Fallout совсем иначе. Хороший пример эффективности системы даже в условиях постапокалипсиса.

Дизайнеры, у вас появилось много работы в ваших проектах. Поздравляю. Четыре из пяти приложений, с которыми сейчас работаем в России, переделывают приложения под Offline-first. UX-Система перепроектируется так, будто интернета обычно нет, а не наоборот. Звучит немного дико, когда у тебя есть установка, что сеть становится «улучшением», а не обязательным условием работы. Зато это позволит не превращать телефон в кирпич: юзер продолжает выполнять ключевые действия, данные будут сохраняться локально, а синхронизация будет как только появится интернет. Забываем про плашки «у вас нет интернета» на весь экран, которые блокируют выполнение сценария, а просто продолжаем работать с системой. Получается эдакий Graceful degradation здорового приложения — частичная деградация UX вместо падения системы или блокировки. Ваша Figma отличный пример. Вы работаете даже если хомяк перегрыз провод. Синхронизируетесь, когда будет связь.