4.6. Ритм, внимание, пространство — мобильный UX как темпоральная композиция

На прошлом занятии мы разговаривали руками: палец, жест, досягаемость, отклик. Мы выяснили, что мобильный интерфейс — это тактильная сцена. Сегодня мы поднимаемся с уровня тела на уровень времени. Потому что приложение существует не только в пространстве экрана, но и — прежде всего — во времени чьей-то жизни.

Практический центр лекции — один фрагмент реального опыта, который уже можно пройти и измерить. Мы прикладываем понятия ритма к вашему проекту и мини-пробе, пока они ещё способны измениться.

Ключевые вопросы сегодняшней пары:

— где в вашем сценарии возникает первый полезный отклик; — в каком ритме находится пользователь в этот момент; — что приложение ускоряет, где даёт паузу, где намеренно создаёт лёгкую аритмию; — какой кусок этого ритма можно проверить до следующей встречи.

На сдвоенной паре мы реально успеваем сделать два упражнения, иногда — третье короткое. Поэтому обязательными остаются:

1. Три ритма первого полезного контакта.
2. Ритмическая разметка key flow и мини-пробы.

Третье упражнение — резервное. Таймлайн полного опыта лучше вынести в домашний чекпойнт.

Рабочий формат — таблица или Google Docs. FigJam можно использовать как источник, если у команды уже есть доска, но для занятия таблица лучше: она быстрее, плотнее, меньше соблазняет рисовать интерфейсный туман и проще собирается в общий разбор.

Когда дизайнер открывает Figma, он видит экраны. Статичные прямоугольники: один, второй, третий. Навигация, контент, кнопки. Всё неподвижно. Всё одновременно. И возникает иллюзия, что интерфейс — это пространственная конструкция: вещь, которую можно окинуть взглядом.

Но пользователь не окидывает интерфейс взглядом — он проходит его во времени, экран за экраном, секунда за секундой, действие за действием. Он открывает приложение в 8:47 в метро. Закрывает в 8:48. Возвращается в 12:15 в очереди за кофе. Снова уходит. Его опыт складывается как последовательность моментов, растянутых в повседневности.

Вывод, с которого мы сегодня начинаем: мобильный UX разворачивается как временна́я конструкция — с темпом, ритмом, паузами, ускорениями, провалами; и пока вы не проектируете время, опыт остаётся непроектированным.

Когда человек пользуется телефоном, одновременно звучат три ритма. Они не всегда совпадают — и в этом несовпадении живёт весь мобильный опыт.

Сердцебиение. Дыхание. Моргание. Усталость к вечеру, бодрость после кофе, замедление после обеда. Скорость, с которой палец может тапнуть. Время, за которое глаз находит нужный элемент. Порог терпения — те самые 400 миллисекунд, после которых ожидание начинает раздражать.

Ваш пользователь — тело с конкретной скоростью и конкретной усталостью.

Светофор переключается каждые 60 секунд. Поезд метро останавливается каждые 2–3 минуты. Очередь движется рывками. Ребёнок кричит, потом затихает. Кофейня шумит ровным гулом. Ночью тишина.

Среда задаёт такт, в котором существует пользователь; приложение, которое игнорирует этот такт, требует внимания именно тогда, когда его нет.

Скорость загрузки. Длительность анимации. Частота уведомлений. Количество шагов до результата. Время между нажатием и откликом. Ритм скролла — плавный или рваный. Пауза после отправки формы — секунда тишины или мгновенный ответ.

Это третий голос в ансамбле. И он — единственный, которым вы можете управлять.

Когда все три ритма совпадают — опыт кажется бесшовным. Пользователь не замечает интерфейса. Действие течёт.

Когда ритмы расходятся — возникает трение. Приложение требует внимания, когда тело устало. Уведомление приходит в момент, когда среда и так кричит. Анимация длится дольше, чем терпение.

Задача дизайнера — настроить ритм интерфейса так, чтобы он уживался с двумя другими (устранить расхождение невозможно: тело и среда вне вашего контроля).

Вот несколько живых сцен из разборов разных лет — они полезны как камертон, а не как список образцовых решений:

● bits: человек закрывает ящик, держит мелкую вещь, спешит закончить уборку; интерфейс должен принять голосовой след быстрее, чем человек решит «потом запомню». ● Triptik: утро вылета, метро, плохой интернет, тревога; интерфейс должен сразу показать «сейчас важно», а не заставлять бродить по разделам. ● Luma: утро с комком дел и разным количеством сил; интерфейс должен принять сырой список, а не требовать таблицу продуктивности. ● Бесконтактная аренда: поздний приезд, подъезд, чемодан, закрытая дверь; интерфейс должен давать один следующий шаг и аварийную ветку. ● Сплиттинг: компания устала после игры или еды, деньги начинают портить атмосферу; интерфейс должен разложить чек до того, как организатор станет бухгалтером вечера. ● «Вовне» / «Чужой день»: привычный маршрут или привычное действие; интерфейс может намеренно создать маленькую аритмию, чтобы пользователь заметил автопилот. ● Return / Reed: материал возвращается не сразу, а в нужный момент; главный ритм здесь — задержка, созревание, повторное появление. ● Паттерн / Refloom / День как след: первый жест должен быть быстрым, почти телесным; смысл возвращается позже, когда запись остыла или набрала массу.

В каждом проекте спросите: ваш сервис должен попасть в ритм пользователя или слегка сбить его? Это разные жанры. Для Triptik, bits, аренды и сплиттинга чаще нужна эвритмия. Для «Вовне», Sonar, Паттерна и Refloom допустима управляемая аритмия, но только если она осмысленна и не ломает доверие.

Формат: таблица или Google Docs, команды. 12 минут.

Задание (8 минут):

Возьмите тот сценарий, который вы сейчас проверяете мини-пробой. Не весь продукт. Один момент: первый тревел-фрагмент, голосовой след вещи, позднее заселение, чек, сырой список задач, городская находка, пуш-отклонение, возвращение сохранёнки.

Заполните таблицу:

Разбор (4 минуты):

Смотрим 2–3 таблицы. Интересуют не красивые формулировки, а конкретика: чем занят человек руками, где он находится, сколько у него терпения, что приложение успевает дать до первой усталости.

Что это проверяет:

Видите ли вы, что первый экран существует внутри чьего-то утра, подъезда, ящика, дороги, компании, усталости и страха ошибиться?

Анри Лефевр, французский философ и социолог, в последней своей книге — «Ритмоанализ» (1992) — предложил метод изучения пространства через ритмы, которые в нём переплетаются. Город, по Лефевру, разворачивается как партитура — одновременное звучание множества циклов: транспортных, биологических, коммерческих, погодных, социальных. Лефевр наблюдал Париж из окна своей квартиры и описывал то, что слышал и видел, как музыкальную ткань.

Он ввёл три категории:

Эвритмия — ритмы согласованы, тело чувствует себя «в такт» со средой. Утренняя пробежка по знакомому маршруту. Привычная дорога на работу. Приложение, которым пользуешься каждый день, не думая.

Полиритмия — несколько ритмов звучат одновременно, но не сливаются. Вы едете в метро, слушаете подкаст, параллельно проверяете мессенджер, вагон покачивается. Четыре ритма, каждый свой. Это нормальное состояние мобильного опыта — полиритмия по умолчанию.

Аритмия — ритмы конфликтуют, тело страдает: приложение зависло в момент, когда вы спешите; уведомление разбудило ночью; интерфейс требует десяти шагов там, где терпения хватает на три. Аритмия разворачивается как телесный конфликт между вашим ритмом и ритмом интерфейса.

В прикладных проектах ваша задача, скорее всего — стремиться к эвритмии. Интерфейс должен попадать в такт повседневности. Если пользователь спешит — спешите вместе с ним: минимум шагов, мгновенный отклик, никаких лишних экранов. Если пользователь медленно листает вечером на диване — дайте ему глубину, детали, пространство для блуждания.

В исследовательских проектах, возможно, ваша цель — полиритмия или даже управляемая аритмия. Нарушить привычный ритм, чтобы человек заметил то, что обычно ускользает. Замедлить интерфейс там, где все привыкли к скорости. Поставить паузу там, где ожидается мгновенный ответ. Это рискованно — но если это осознанный проектный ход, а не баг, это может стать самой сильной чертой вашего проекта.

Вы уже слышали про когнитивную нагрузку: не давайте пользователю слишком много информации сразу, не перегружайте экран, упрощайте. Это правильно, но это только половина картины.

Проблема залегает глубже количества — в темпе подачи информации.

Один и тот же объём информации может быть лёгким или невыносимым — в зависимости от того, как он распределён во времени.

Пример 1: Приложение для бронирования авиабилетов. Вы выбрали рейс, нажали «оплатить» — и вам показали экран с двадцатью полями: имя, фамилия, паспорт, срок действия, номер карты, CVV, адрес, телефон, email, промокод, страховка, багаж, место, питание, трансфер… Это аритмия. Всё навалилось одновременно.

Пример 2: То же приложение, но поля разбиты на 4 экрана по 3–5 полей: данные пассажира → выбор услуг → оплата → подтверждение. Каждый шаг — маленький, завершённый. Между шагами — микропауза: прогресс-бар, подтверждение «✓ Данные сохранены». Тот же объём информации, но другой ритм. Вы дышите между шагами.

Ритм служит инструментом управления нагрузкой.

Три приёма ритмического проектирования:

1. Прогрессивное раскрытие. Не показывайте всё сразу. Показывайте столько, сколько нужно прямо сейчас. Следующий слой — по запросу или по действию.

2. Дыхание между экранами. Микропауза после действия: анимация подтверждения, секунда тишины, визуальный «выдох» — ритмическая необходимость, та же пауза между фразами в речи.

3. Предсказуемый темп. Если каждый шаг занимает примерно одинаковое время — пользователь входит в ритм. Если один шаг — секунда, а следующий — тридцать секунд, ритм сломан.

Формат: таблица или Google Docs, команды. 18 минут.

Задание (12 минут):

Возьмите текущий key flow и план мини-пробы. Разметьте не только экраны, но и действия в реальности: что человек делает, что сервис делает, что команда подделывает руками.

Используйте метки:

⏩ Ускорение — пользователь хочет быстрее, интерфейс не должен тормозить. ⏸️ Пауза — пользователю нужен момент для решения, осмысления, выдоха. ⏳ Ожидание — пользователь вынужден ждать: распознавание, расчёт, обработка, ответ команды в Wizard of Oz. ⚡ Пик — момент максимальной концентрации: оплатить, выбрать, подтвердить, открыть дверь, поверить сумме, свернуть с маршрута. 💨 Облегчение — действие совершено, результат получен, напряжение спало. 🎷 Свинг — повторяющееся действие меняется под контекст: сегодня мало сил, сегодня дождь, сегодня рейс ночью, сегодня пользователь отказался.

Таблица:

Под таблицей две строки:

Самое слабое место ритма: переход от __ к __, потому что __. Что мы проверим до следующей пары: __.

Разбор (6 минут):

Смотрим 2–3 команды. Ищем:

● Есть ли пауза перед пиком? (Если нет — пик не ощущается как пик.)

● Есть ли облегчение после пика? (Если нет — пользователь не чувствует, что действие завершено.)

● Где ожидание, которое команда пока подделывает руками, — и что видит пользователь?

● Где сервис первым делает полезный жест, вместо того чтобы ждать, пока его накормят данными?

Что это проверяет:

Видите ли вы свой key flow как ритмическую партитуру мини-пробы, а не как список экранов?

Теперь сдвинем фокус с временно́й оси на пространственную — имея в виду реальное физическое пространство, в котором человек пользуется телефоном.

В 1967 году Ги Дебор, главный теоретик ситуационизма, написал «Общество спектакля» — одну из самых радикальных книг XX века. Его тезис: в современном обществе непосредственный опыт подменяется пассивным потреблением образов. Мы не живём — мы смотрим, как живут. Лента новостей. Сторис. Бесконечный скролл. Дебор написал это за полвека до смартфонов — но описал именно их.

Ситуационисты противопоставили спектаклю конструирование ситуаций — создание уникальных моментов жизни, намеренно спроектированных для провокации подлинного опыта. По формуле Дебора, «ситуация — это совместная реализация единства времени и места». Не потребление контента, а производство своей реальности. В этом стремлении «жить иначе» чувствуется влияние сюрреализма и Батаевской концепции «суверенности» — но если сюрреалисты делали ставку на высвобождение бессознательного, ситуационисты апеллировали к рациональному проекту преобразования повседневности.

Зачем это дизайнеру? Затем, что вы стоите на развилке: ваше приложение — это ещё один спектакль (лента, в которой листают чужие образы) или инструмент для создания ситуации (продукт, через который человек активно производит свою жизнь — вызывает машину, бронирует поездку, принимает решение)?

Различие в ритме: спектакль — это ровный, убаюкивающий поток; ситуация — это прерывание, момент концентрации, в котором человек перестаёт быть зрителем.

Ещё до «Общества спектакля», в 1956 году, Дебор опубликовал «Теорию дрейфа» и предложил практику психогеографии — изучения того, как городская среда влияет на эмоции и поведение людей. Его метод: dérive (дрейф) — преднамеренное блуждание по городу, при котором человек отдаётся потоку среды, а не следует привычному маршруту. Через практику дрейфа ситуационисты картографировали зоны притяжения и отталкивания, разрывы и переходы в ткани городской повседневности — те невидимые потоки, которые структурируют территорию.

Важное различие: дрейф принципиально отличается от прогулки. Беньяминовский фланёр наслаждается городом как театром, сохраняя дистанцию наблюдателя и коллекционируя впечатления; ситуационистский деривьё — активный исследователь, который переписывает пространство, конструируя новые ситуации.

В терминах нашего модуля: фланёр требует ленты для скроллинга, деривьё — среды для действия.

Вторая ситуационистская тактика — détournement (отклонение, угон, перекодирование). Это заимствование элементов существующей культуры и их творческое перемонтирование в новый контекст. Ситуационисты меняли подписи в комиксах на цитаты из Маркса, переделывали рекламные плакаты в политические манифесты. Détournement — это «интегрирование настоящих или прошлых произведений в более совершенную конструкцию среды» (Дебор).

Какое отношение это имеет к мобильному UX? Самое прямое: каждый пользователь занимается détournement вашего интерфейса. Он использует функции «не по назначению». Он сохраняет посты в закладки как список покупок. Он пишет в заметки то, для чего вы предусмотрели специальный экран. Он перекодирует ваш продукт под свою жизнь.

Для прикладного проекта: оставляйте зазоры, в которых возможно присвоение. Не закрывайте все пути — дайте пользователю материал для его собственного détournement.

Для исследовательского проекта détournement может стать методом: что если ваш интерфейс намеренно искажает привычные паттерны взаимодействия, открывая пространство для нового опыта? Можно ли вообразить интерфейсы, которые не просто воспроизводят привычные паттерны, но творчески их деформируют — как ситуационисты деформировали карту Парижа?

Делёз и Гваттари в «Тысяче плато» различают два способа работы с территорией: калька (calque) и карта (carte). Калька — снимок, копия, воспроизведение существующих структур. Карта — эксперимент, открытие новых связей и траекторий. Калькирование нацелено на результат. Картографирование — на процесс.

Большинство мобильных приложений занимаются калькированием: алгоритмы рекомендаций воспроизводят ваши прошлые паттерны, «пузыри фильтров» замыкают вас в привычном круге. Приложение знает, что вы смотрели, и показывает то же самое. Это калька вашего поведения, возведённая в абсолют.

Альтернатива — приложение как картографическая машина: продукт, который трансформирует повседневность и показывает то, что пользователь мог бы узнать, а не только то, что уже знает. Концепт «анти-ленты» — ленты, выводящей за пределы сложившихся интересов в нечто постороннее, — разворачивается как ситуационистский навигатор в цифровом пространстве: информационный дрейф, прокалывающий «пузырь фильтров».

Для прикладных проектов: спросите себя — ваш интерфейс калькирует или картографирует? Даже в утилитарном продукте может быть момент «карты» — случайная рекомендация, неожиданный маршрут, показ того, чего пользователь не искал.

Для исследовательских проектов: это ваша территория. «Ситуационистский навигатор», который строит маршрут через незнакомые районы и предлагает неожиданные точки интереса. «Радикальный таймер», который отсчитывает время ситуационистскими лозунгами: «Ещё 15 минут отчуждённого труда! Пора устроить дрейф!» — приложения как инструменты творческого беспокойства, сознательно трущие против привычного.

Вернёмся к телу. Ваш пользователь — психогеограф, который этого не знает.

Он идёт по городу. Он не следует карте — он следует привычке, настроению, усталости. Он сворачивает в переулок, потому что там тише. Он заходит в кофейню, потому что устал. Он достаёт телефон, потому что в этом месте, в это мгновение возник зазор — промежуток, в который можно войти.

Мы уже говорили об этом в лекции 4.3, когда обсуждали ма (間) — значимый промежуток. Сейчас добавим ещё один слой: этот промежуток привязан к месту. Телефон достаётся не «вообще», а здесь — на этой остановке, в этом лифте, в этой очереди. И место влияет на опыт: шум, свет, температура, люди, ощущение безопасности или тревоги.

Не в пустоте ли между «было» и «стало», между нажатием и результатом, кроется суть Dasein im Internet — бытия-в-интернете? Каждый сбой, каждая «пустота» в потоке цифровых взаимодействий — это момент, который выбивает из привычной колеи. «Телеологическая авария» цифровой системы — своего рода «сконструированная ситуация» в негативном ключе. Структурно она работает так же: вносит разрыв в автоматизм, заставляя острее ощутить условность и хрупкость онлайн-бытия.

Для прикладных проектов: ваш интерфейс должен учитывать не только когда, но и где. Приложение для навигации в метро работает иначе, чем на улице: под землёй нет GPS, экран бликует от ламп, одна рука держит поручень. Приложение для доставки еды используется иначе дома на диване и на скамейке в парке.

Для исследовательских проектов: психогеография — это прямой ресурс. Если ваш проект работает с городом, пространством, вниманием, движением — dérive Дебора может стать не метафорой, а методом исследования. Пройдите маршрут, который должен обслуживать ваш интерфейс — дрейфуйте, не планируйте; записывайте то, что чувствуете в каждой точке. Это и есть материал для проектирования.

Мы привыкли думать об UX как о партитуре: дизайнер пишет ноты, пользователь играет. Но реальный мобильный опыт ближе к джазу, чем к концерту классической музыки.

В джазе есть тема — но нет жёсткого текста. Есть гармоническая структура — но внутри неё музыкант импровизирует. Есть ритм-секция, которая держит пульс, — но солист может сместить акцент, задержать фразу, вставить паузу там, где её не ожидали. И именно эта свобода внутри структуры делает джаз живым.

Мобильный интерфейс работает так же. Вы задаёте структуру — навигацию, ключевой путь, экраны, кнопки. Но пользователь импровизирует: скроллит мимо того, что вы считали важным. Нажимает «назад» вместо «далее». Закрывает приложение на середине. Возвращается через три дня и начинает с другого места. Его пальцы играют вашу тему — но по-своему.

Что это значит для проектирования?

1. Проектируйте структуру — lead sheet, а не партитуру. Ваш wireflow задаёт гармонию, но не предписывает каждый жест; оставляйте пространство для того, чтобы пользователь двигался внутри вашей структуры своим путём.

2. Проектируйте возвраты наравне с продвижением. В джазе музыкант возвращается к теме после импровизации; в интерфейсе пользователь возвращается после отвлечения, перерыва, ошибки — и момент возврата становится одним из самых важных в ритме мобильного опыта. Что он видит, когда открывает приложение снова? Где он оказался? Помнит ли приложение, что он делал?

3. Проектируйте паузы так же тщательно, как действия. В джазе пауза — полноценный элемент фразы; Майлз Дэвис знаменит тем, что не играл, и его тишина говорила больше, чем чужой поток нот. В интерфейсе пауза — это пустой экран, который даёт выдохнуть; экран подтверждения, на котором ничего не нужно делать; момент между отправкой и ответом, в котором напряжение работает на вас, если вы его спроектировали.

Формат: индивидуально, телефон + короткая таблица / Google Docs. 10 минут.

Этот блок делаем только если осталось время. В обычной сдвоенной паре его лучше отдать в резерв или в самостоятельное наблюдение после занятия.

Задание (6 минут):

Откройте на своём телефоне любое приложение, которым вы пользуетесь регулярно. Но сейчас — не делайте то, зачем обычно его открываете. Дрейфуйте. Нажимайте на то, что раньше не замечали. Зайдите в настройки. Откройте раздел, который никогда не открывали. Найдите экран, который не знали.

Заполните три строки:

Разбор (4 минуты):

2–3 примера: что нашли, где потерялись, что удивило. Обращаю внимание на «не-места» — экраны, которые существуют по инерции, но не имеют ритмического смысла.

Что это проверяет:

Можете ли вы физически пережить ритм чужого интерфейса, а не только анализировать его по скриншотам?

Три философских хода, которые делают разговор о ритме глубже, чем стандартный UX-учебник.

Анри Лефевр разрабатывал ритмоанализ в поздних текстах, собранных в книге «Элементы ритмоанализа» (1992). В эссе «Увиденное из окна» наблюдатель смотрит с балкона на парижский перекрёсток и различает повторы, циклы, внезапные события, городской шум и движение тел. Однако ритмоаналитик не бесплотная камера: собственное дыхание, пульс и усталость служат ему метрономом. Чтобы услышать ритм снаружи, приходится слушать тело, уже включённое в происходящее.

Это радикально непривычная позиция для дизайнера. Дизайнер привык вмешиваться: формулировать, проектировать, решать. Лефевр предлагает другое: сначала послушай.

Прежде чем рисовать wireflow, побудьте ритмоаналитиком контекста, в котором живёт ваш пользователь. Не проектируйте — наблюдайте. Сколько длится его поездка в метро? Как часто он проверяет телефон? Когда отвлекается? Когда концентрируется? Какой ритм у его утра, обеда, вечера?

Это наблюдение за временем — за ритмом, а не за воронкой действий; и оно даёт другой материал, отвечая на вопрос «в каком ритме существует пользователь», а не «чего он хочет».

Практический вывод: Попробуйте описать один день вашего пользователя как партитуру ритмов — ускорений, замедлений, пауз, разрывов. Вы обнаружите, что ваше приложение входит в эту партитуру только в определённых тактах. Найдите их.

Вопрос к проекту: какой внешний ритм — тела, транспорта, работы, тревоги — ваш сервис пока не слышит?

Вмешательство: добавьте его в ритмическую таблицу отдельной строкой и измените один момент отклика, паузы или уведомления в соответствии с наблюдаемым тактом.

В «Различии и повторении» (1968) Жиль Делёз спорит с моделью повторения как вторичного воспроизведения одного и того же. Повторение производит различие, поскольку возвращается в иной серии сил, привычек и интенсивностей. Это трудная онтологическая конструкция, которую нельзя свести к совету «слегка варьируйте интерфейс», но она позволяет увидеть: второе открытие приложения уже происходит с другим телом и памятью первого открытия.

Джазовый свинг — наша поясняющая модель, у Делёза такого примера нет. И сам свинг сложнее механического «чуть раньше или позже»: он возникает из отношения пульса, фразировки и ансамблевого времени, которое невозможно полностью записать сеткой. Музыкант не просто портит часы; он удерживает общий такт, превращая микрорасхождения в телесную упругость. В проектной аналогии интерфейс становится машиной различия, когда узнаваемая структура допускает контекстуальную вариацию, не рассыпаясь в случайность.

Какое отношение это имеет к мобильному интерфейсу?

Пользователь повторяет: открывает приложение каждое утро, скроллит ленту, делает заказ, проверяет статус. Конвенциональный UX обращается с этими повторениями как с тождественными событиями: один и тот же экран, один и тот же путь, одна и та же кнопка. Метроном.

Но контекст повторения каждый раз другой. Утром в метро — одна скорость, одно терпение, один уровень тревоги. Вечером на диване — совершенно другой. В очереди за кофе — третий. Повторение никогда не тождественно себе, потому что тело, среда и настроение — разные.

Интерфейс, который это понимает, — это интерфейс со свингом. Он сохраняет узнаваемую структуру (сильные доли), но вводит микровариации, настроенные на контекст: сокращённый путь для повторного действия, адаптивная плотность контента, мягкое «вспоминание» незавершённого. Не хаос — а управляемое отклонение от метронома, которое делает каждое повторение живым.

А интерфейс, который обращается с каждым сеансом как с идентичным, — это прямой ритм без грува. Он функционален. Но в нём нет дыхания. Нет того парадокса различия-в-повторении, который превращает механическое воспроизведение в источник новизны.

Практический вывод: Найдите в вашем приложении одно повторяющееся действие — то, которое пользователь делает каждый день. Спросите себя: вы обращаетесь с этим повторением как с тождественным событием — или в нём есть свинг? Что могло бы меняться от контекста к контексту, чтобы каждое «то же самое» ощущалось чуть иначе? Не ломайте структуру — сместите акцент на слабую долю.

Вопрос к проекту: какое повторяющееся действие ошибочно считается одинаковым утром, ночью, впервые и в сотый раз?

Вмешательство: сделайте одну контекстную вариацию, сохранив узнаваемую структуру: сократите повторный путь, верните незавершённое или измените плотность ответа.

Буддийское учение об анатмане, по-японски муга (無我), отрицает неизменное самостоятельное «я»; оно не описывает специальный пик производительности. Образ каллиграфа, у которого кисть словно действует сама, ближе к японскому мусин — практике действия без цепляющейся рефлексии. Михай Чиксентмихайи значительно позднее описал flow как глубокую вовлечённость при соответствии сложности задачи навыку. Эти понятия исторически и философски различны. Мы ставим их рядом как оптические приборы, чтобы разглядеть опыт, где контроль перестаёт ощущаться отдельной командой субъекта.

Такой ритм может быть желателен для одного короткого мобильного действия — например, привычной фиксации мысли или вызова машины, — но его нельзя объявить идеалом всего опыта. Оплата, согласие на передачу данных и необратимое удаление иногда обязаны вернуть человеку рефлексию.

Когда человек заказывает такси за 8 секунд — он не думает ни о себе, ни об интерфейсе. Палец двигается, экран откликается, машина вызвана. Ни одного момента рефлексии. Муга. Интерфейс достиг высшей точки — он исчез.

Хайдеггеровская подручность даёт ещё одну, отдельную генеалогию прозрачного действия: работающий молоток отступает в практическую связность дела. Муга не является «следующим шагом» Хайдеггера. Их авторское сближение задаёт вопрос о границе полезной прозрачности: когда исчезает лишнее внимание к инструменту, а когда вместе с ним исчезает возможность остановиться?

Муга возникает далеко не везде — и это нормально. Регистрация, оплата, экран ошибки по природе своей выдёргивают из потока; муга рождается только там, где ритм настроен точно: действие → отклик → следующее действие, без зазоров, без ожидания, без сомнения. Проектировать весь интерфейс как поток — иллюзия; проектировать ключевое действие как поток — обязанность.

Для исследовательских проектов: муга способна стать предметом исследования — вопросом о том, что происходит, когда поток намеренно разрывается; когда интерфейс заставляет вас заметить себя и задуматься. Эта антимуга для экспериментального проекта может оказаться ценнее плавности.

Один авторский инструмент для работы с антимугой — хронотопограмма, карта пространственно-временных процессов восприятия. В ней отмечаются ускорения, замедления и петли обратной связи, а также чёрные дыры внимания: точки, где субъективное время сжимается и интерфейс затягивает действие в повтор. Сравнение с бартовским пунктумом здесь метафорично. У Ролана Барта в «Camera Lucida» пунктум — деталь фотографии, которая «уязвляет» зрителя и нарушает культурно читаемый studium; он не писал о UX и не называл точкой то, что «смотрит на вас». Перенос позволяет спросить: может ли интерфейс прервать предсказуемую траекторию взглядом-уколом, после которого человек замечает собственное время?

Практический вывод: Определите одно действие в вашем приложении, которое должно происходить в состоянии потока. Уберите из него всё, что заставляет пользователя думать о том, что он делает: лишние подтверждения, неожиданные переходы, визуальный шум. Проверьте: сколько секунд от намерения до результата? Если больше 5 — ищите, что лишнее.

Вопрос к проекту: какое действие должно исчезнуть из сознания, а где исчезновение уже становится ловушкой внимания?

Вмешательство: снимите один лишний когнитивный стоп внутри полезного действия и добавьте ответственную точку выхода там, где поток может присвоить человека.

Передайте модели таймлайн, журнал событий или расшифровку прохождения прототипа и попросите собрать несколько монтажей одного сценария: сжатый; с намеренными паузами; прерванный уведомлением; оборванный потерей сети; повторный вход через сутки. Модель должна менять длительность и порядок, объясняя, какой ритм тела и среды она предполагает.

Затем пройдите варианты на устройстве с секундомером. Сравните объективное время с субъективным: короткий путь может ощущаться долгим из-за неопределённости, долгая пауза — почти исчезнуть, если понятно, что происходит и данные сохранены. Машина переставляет такты, но не переживает ожидание.

Артефакт занятия: таймлайн v0; две машинные или ручные вариации; замеры реального прохождения; выбранные изменения; один отвергнутый случай, где ускорение разрушало смысл, доверие или телесный ритм.

Формат: таблица / Google Docs. В классе не делаем, если уже выполнены первые два упражнения.

Задание:

Соберите таймлайн опыта пользователя для одного полного цикла использования приложения: от момента, когда возникает потребность, до момента, когда результат получен или сценарий ломается.

В таблице должны быть минимум 6–8 моментов.

Отметьте:

⏩ ускорения, ⏸️ паузы, ⏳ ожидания, ⚡ пики, 💨 облегчения, 🎷 свинг, 🌊 поток.

Отдельно подпишите:

— одно место, где вы намеренно замедляете ритм, и зачем; — одно место, где есть свинг — микровариация повторяющегося действия; — одно действие, которое должно проходить в потоке, без размышления пользователя; — одно место, где мини-проба должна поймать сбой.

Что это проверяет:

Можете ли вы видеть свой проект как временну́ю композицию — со своими crescendo, паузами, каденциями?

● Понимание того, что мобильный UX разворачивается как временна́я конструкция со своим темпом, ритмом и паузами.

● Умение видеть три одновременных ритма — тела, среды и интерфейса — и их совпадения/расхождения.

● Ритмическую разметку текущей мини-пробы: ускорение, пауза, ожидание, пик, облегчение.

● Один первый полезный отклик, привязанный к телу и среде пользователя.

● Хотя бы один «свинг» — микровариацию повторяющегося действия, которая не даёт интерфейсу стать метрономом.

● Таймлайн, проверенный на физическом устройстве и сопоставленный с субъективным ощущением времени.

Таймлайн опыта пользователя с пометками ритма, контекста и мини-пробы.

Часть 1. Таймлайн (визуальная схема)

Соберите полный таймлайн одного цикла использования вашего приложения. Минимум 6–8 моментов. Делайте в таблице или Google Docs; FigJam можно приложить дополнительно, если он уже есть, но сдаваемый рабочий артефакт должен читаться как таблица.

Для каждого момента укажите:

Часть 2. Три ритмических решения

Опишите три осознанных ритмических решения в вашем проекте:

● Одно ускорение — где и почему вы сокращаете путь до минимума.

● Одна пауза — где и почему вы намеренно замедляете. Что пользователь должен почувствовать в этот момент.

● Один «свинг» — повторяющееся действие, в которое вы вводите микровариацию. Что меняется от контекста к контексту и почему это делает опыт живым.

Часть 3. Одна зона потока

Выделите одно действие, которое должно происходить в состоянии потока (муга). Запишите:

● Что это за действие.

● Сколько шагов от намерения до результата.

● Что вы убрали, чтобы поток не прерывался.

Часть 4. Два монтажа

Приложите две альтернативные версии темпа, машинные или ручные, и замер прохождения на устройстве. Назовите одну рекомендацию ускорить сценарий, которую вы отвергли, потому что пауза здесь выполняет работу.

Формат сдачи: Google Docs / таблица. Figma или FigJam можно приложить как дополнительный материал, но они не заменяют ритмическую таблицу.

Мобильный UX разворачивается как темпоральная (временна́я) композиция, встроенная в полиритмию чьей-то повседневности.

У этой композиции есть темп — и он должен совпадать с телом. У неё есть паузы — и они должны быть спроектированы так же тщательно, как действия. У неё есть свинг — микровариации, которые делают каждое повторение живым, а не механическим. У неё есть моменты потока — и в этих моментах интерфейс достигает своей высшей точки: он исчезает.

Дизайнер мобильного интерфейса — композитор: он работает со временем, а материалом ему служат такты, паузы и ритм чьего-то дня.

На следующем занятии мы возьмём то, что накопили — гипотезу, сценарий, аффордансы, ритм — и переведём это на визуальный язык: дизайн-система, платформенные паттерны, типографика, компоненты.