{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Пользовательский интерфейс", "_rss_description": "Принципы и методы Решение по-эпловски Ховер из овер", "_rss_language": "ru", "_itunes_email": "ilyabirman@ilyabirman.ru", "_itunes_categories_xml": "<\/itunes:category>\r\n<\/itunes:category>\r\n\r\n", "_itunes_image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic-square@2x.jpg?1573933764", "_itunes_explicit": "no", "home_page_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/ui\/", "feed_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/ui\/json\/", "icon": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764", "authors": [ { "name": "Илья Бирман", "url": "https:\/\/ilyabirman.ru\/meanwhile\/", "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764" } ], "items": [ { "id": "6777", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/scenario-and-ui-navigation\/", "title": "Отношения между сценарием и навигацией в интерфейсе", "content_html": "

При проектировании интерфейса важно проанализировать сценарии, то есть хорошо представить, как именно, в какой ситуации, с какими знаниями, целями и ожиданиями человек будет пользоваться интерфейсом. Многие забывают про это подумать, и у них получается ерунда. Но иногда ерунда получается, даже если про это подумать, а затем просто положить сценарии в основу навигации.<\/p>\n

Что будет, если просто положить сценарии в основу навигации?<\/p>\n

Когда сценариев очень мало, может получиться неплохой интерфейс. Если есть всего три-пять действий, за которыми человек приходит в интерфейс, и мы просто делаем для них кнопки, то всё будет понятно и удобно. Это то, что я предлагал для ПВЗ «Яндекс-маркета»<\/a>.<\/p>\n

Но такие интерфейсы встречаются редко. Даже в небольшом продукте есть множество связей между функциями, и число сценариев огромно. Если в таком случае начать строить навигационную модель вокруг сценариев, в интерфейсе станет невозможно разобраться. В заметке об архиве вакансий<\/a> я как раз указываю на эту проблему.<\/p>\n

Когда я говорю про огромное число сценариев, необязательно представлять что-то необъятное вроде Фотошопа. Даже календарь — это уже целый мир разных сценариев. Ну вот, например:<\/p>\n

\n

Иван понял, что не успевает на регулярную встречу, и хочет предупредить других участников о переносе. Кому-то из них удобнее написать, кому-то позвонить. В ходе одного из звонков Пётр говорит, что давайте тогда уж вообще перенесём эту встречу на час позже, потому что ему самому трудно на неё успевать всё время. Иван смутно помнит, что где-то через пару недель у него запись к зубному, и хочет убедиться, что перенос не конфликтует с ней, идёт проверяет. Выясняется, что конфликтует, но договариваются всё же перенести на час позже, а там, через две недели, просто сделать исключение.<\/p>\n<\/blockquote>\n

Ну и что, как построить навигационную модель вокруг этого сценария? Да никак.<\/p>\n

Во-первых, если вы хорошо провели анализ, то даже тех сценариев, которые вы рассмотрели и выделили как ключевые, будет довольно много. То есть даже если для каждого из них есть прям готовая кнопка или раздел в интерфейсе, найти их будет не так просто. Во-вторых, остальные сценарии, которых несравнимо больше, вообще непонятно, где надо будет искать. Развивать такой продукт и поддерживать растущее число сценариев — боль.<\/p>\n

Хороший интерфейс не ведёт по сценариям, он лишь создаёт для них возможности. Он даёт пользователю свободу, чувство контроля, ту самую «агентность», а не просто направляет его по одной из нескольких заранее проложенных дорожек. Разумеется, в календаре нет готовой кнопки или даже «мастера» для того, что описано в сценарии выше. Календарь просто так устроен, чтобы пройти по этому сценарию не составляет труда.<\/p>\n

Это похоже на вопрос о том, зачем нужны карты и схемы, когда в телефоне и так есть навигатор. Навигатор очень полезен, но с ним ты не чувствуешь себя хозяином положения, не можешь отклониться от пути. Карта же даёт общее понимание того, как устроен мир, и ты уже можешь сам принимать решения. На карте нет специальной секции для сценария «по пути с ребёнком из школы заехать погулять в парк», но она делает этот сценарий возможным без проблем. В навигаторе можно предусмотреть функцию «заехать по пути», но её ещё нужно будет найти, а также десятки других сценариев останутся непокрытыми.<\/p>\n

Поэтому в основу навигации в интерфейсе нужно закладывать некую модель того, как мы хотим, чтобы человек представлял себе устройство нашего продукта: какие у нас есть сущности, как они связаны, организованы, что они умеют. Эта модель должна помогать нам реализовывать все важные сценарии, а пользователю — находить способы их реализации. И эта модель должна выдерживать развитие продукта.<\/p>\n", "summary": "При проектировании интерфейса важно проанализировать сценарии, то есть хорошо представить, как именно, в какой ситуации, с какими знаниями, целями и ожиданиями человек будет пользоваться интерфейсом", "date_published": "2026-07-20T18:13:27+05:00", "date_modified": "2026-07-20T18:12:44+05:00", "tags": [ "метод", "навигация", "пользовательский интерфейс", "сценарный подход" ], "_date_published_rfc2822": "Mon, 20 Jul 2026 18:13:27 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6777", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6775", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/arhiv-vakansiy-ne-mozhet-byt-podrazdelom-sozdaniya-vakansii\/", "title": "Архив вакансий не может быть подразделом создания вакансии", "content_html": "

Обсуждаем интерфейс по работе — сервис, где руководитель управляет вакансиями. В нём есть разделы «Вакансии», «Отклики», а также кнопка создания вакансии.<\/p>\n

Дизайнер показывает страницу создания вакансии. В ней вкладки «Новая вакансия» и «Архив». В первой, понятно, форма, а во второй — список ранее опубликованных, но уже закрытых вакансий.<\/p>\n

Я спрашиваю: почему архив находится вдруг на странице создания вакансий? Он же должен быть в разделе «Вакансии». Дизайнер объясняет, что частый сценарий — перепубликация ранее закрытых вакансий. То есть руководитель хочет создать вакансию, а мы ему удобно прямо под рукой даём архив, чтобы он мог старую вакансию перепубликовать.<\/p>\n

Ну уж нет, это неудобно и непонятно. Даже если предположить, что такой сценарий частый и руководитель так хочет, в голове этого руководителя неоткуда взяться мысли, что архив вакансий будет поджидать его в форме создания. Он пойдёт искать вакансию в разделе «Вакансии».<\/p>\n

В навигации должна быть логика, отражающая структуру продукта и связей сущностей внутри него, чтобы человек представлял, что где искать. А если мы хотим подсказать какой-то сценарий, то можно всегда предусмотреть кроссссылку (любимое слово). Например, в начале формы новой вакансии можно написать: «Чтобы повторить ранее опубликованную вакансию, вот вам в архив» — и ссылочку. Кликов столько же, зато всё понятно. А главное, если человек не прочитает это, он всё равно сможет всё найти.<\/p>\n", "summary": "Обсуждаем интерфейс по работе — сервис, где руководитель управляет вакансиями. В нём есть разделы «Вакансии», «Отклики», а также кнопка создания вакансии", "date_published": "2026-07-14T15:46:14+05:00", "date_modified": "2026-07-20T14:45:51+05:00", "tags": [ "навигация в интерфейсе", "пользовательский интерфейс", "сценарный подход" ], "_date_published_rfc2822": "Tue, 14 Jul 2026 15:46:14 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6775", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6771", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/think-on-65\/", "title": "Думаем дальше № 65 — «Никто не пользуется стеклянными сферами» с Никитой Прокоповым", "content_html": "

С Никитой Прокоповым обсуждаем ВВДЦ 2026 и дизайн программ для ЭВМ.<\/p>\n

Все выпуски подкаста:
\nЭпл<\/a> · Ютюб<\/a> · Я.Музыка<\/a> · Спотифай<\/a> · Мейв<\/a> · РСС для подкастного приложения<\/a><\/p>\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
0:00<\/td>\n Какой сигнал мы получили на ВВДЦ 2026 и чего ждём через год<\/td>\n <\/tr>\n
4:38<\/td>\n Предзаписанные и живые презентации<\/td>\n <\/tr>\n
6:26<\/td>\n Полировка и скучающие журналисты<\/td>\n <\/tr>\n
11:08<\/td>\n Золотые ворота: иконки в меню и в Доке<\/td>\n <\/tr>\n
17:33<\/td>\n Скругления углов окон. Историческая справка<\/td>\n <\/tr>\n
26:27<\/td>\n Выбеление интерфейса, возвращение тулбаров и наведение резкости<\/td>\n <\/tr>\n
32:52<\/td>\n Мнение Никиты о прозрачности в интерфейсе и теория Ильи о прозрачности в реальной жизни<\/td>\n <\/tr>\n
40:03<\/td>\n Двигунок жидкости стекла<\/td>\n <\/tr>\n
44:38<\/td>\n Пружинистые кнопки<\/td>\n <\/tr>\n
48:25<\/td>\n Тулбары и группы кнопок на них<\/td>\n <\/tr>\n
51:49<\/td>\n Синхронизация фоток<\/td>\n <\/tr>\n
54:45<\/td>\n Всё не так тормозит, но зачем оно вообще тормозит?<\/td>\n <\/tr>\n
1:06:54<\/td>\n Ощущение качества и надёжности от софта<\/td>\n <\/tr>\n
1:10:32<\/td>\n Каким должен быть редизайн и путь к эталонному решению<\/td>\n <\/tr>\n
1:15:34<\/td>\n Красота и привлекательность интерфейса. Ортопедический дизайн<\/td>\n <\/tr>\n
1:17:56<\/td>\n Все хотят оторвать боковые панели, а зря<\/td>\n <\/tr>\n<\/table>\n", "summary": "С Никитой Прокоповым обсуждаем ВВДЦ 2026 и дизайн программ для ЭВМ", "date_published": "2026-07-10T11:42:22+05:00", "date_modified": "2026-07-10T11:45:54+05:00", "tags": [ "дизайн", "Думаем дальше", "Мак", "пользовательский интерфейс", "Эпл" ], "_date_published_rfc2822": "Fri, 10 Jul 2026 11:42:22 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6771", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6770", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/lag-theorem\/", "title": "Теорема о тормозах", "content_html": "

Поговорим о ситуациях, когда компьютер тормозит.<\/p>\n

Под тормозами понимается медлительность, мешающая свободному взаимодействию и тем самым вызывающая фрустрацию и раздражение. Если компьютер скачивает пять гигабайт данных, компилирует сложный проект или рендерит видео, это занимает ощутимое время, но это не тормоза: мы дали компьютеру задачу, и он работает, выполняет. Теперь допустим, что видео рендерилось час, потом отобразился статус «Завершено», а через секунду готовый файл отобразился на рабочем столе. Первый час компьютер не тормозил, но следующую секунду — тормозил.<\/p>\n

Теорема:<\/b> все тормоза являются ошибками и исправимы.<\/p>\n

Технически даже своевременное отображение статуса или реакции не действие пользователя — это такая же «работа», как и рендеринг видео. Однако такая работа должна быть выполнена за время, которое человек не способен ощутить. Будем называть это «мгновенно».<\/p>\n

Примеры тормозов в современно софте:<\/p>\n