{ "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\/reference-all\/", "feed_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/reference-all\/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": "6846", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/reference\/", "title": "Словарь-справочник проектировщика пользовательского интерфейса", "content_html": "

Представляю новый раздел на моём сайте — Словарь-справочник проектировщика пользовательского интерфейса<\/a>. Мы запускаем его небольшой редакцией, состоящей из Александры Озкан, Настасьи Тулаевой и меня в роли главреда.<\/p>\n

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

Это не просто перечень определений — их и так можно найти в интернете. К каждому термину в справочнике мы предъявляли простое требование: от его наличия должна быть польза. В редких случаях определение полезно само по себе, но чаще всего мы задавали вопрос к каждому термину так: что проектировщику нужно знать об этом? И старались дать качественный ответ.<\/p>\n

Сегодня открывается предварительное издание. В нём уже больше двухсот терминов, но к первому изданию будет больше, часть ещё в работе. Мы приглашаем вас начать пользоваться справочником и сказать, в чём вы видите наши упущения, чего недостаёт или что вам представляется ошибкой.<\/p>\n", "summary": "Представляю новый раздел на моём сайте — Словарь-справочник проектировщика пользовательского интерфейса", "date_published": "2026-10-13T00:26:19+05:00", "date_modified": "2026-10-13T00:34:02+05:00", "tags": [ "интерфейс", "проекты", "релиз", "ССППИ", "студентам" ], "_date_published_rfc2822": "Tue, 13 Oct 2026 00:26:19 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6846", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6834", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/ui-completeness\/", "title": "Замкнутость интерфейса", "content_html": "

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

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

Самое интересное и сложное — это то, что переход должен полностью определяться состоянием и событием. Он не может зависеть от истории предыдущих состояний (если только это не буквально переход по истории состояний типа «Назад» или «Анду»). Если переход из некоторого состояния S при событии E зависит от того, попали мы в S из Q или R, то это значит, что нет никакого состояния S, а есть состояния S1 (S после Q) и S2 (S после R), и важно это осознать. Может показаться, что это какая-то заумь и вообще, какая разница. Но если не обращать внимания на это, то в интерфейсе возникают неявные состояния, в которых вид и переходы не определены. Дизайнер-то думает, что рассмотрел состояние S, да вот только это мифическое состояние, а настоящие состояния S1 и S2 он не рассмотрел.<\/p>\n

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

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

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

Я приводил примеры вопросов<\/a>, которые помогают проверить интерфейс, но понятно, что ответы даже на все вопросы сами по себе не гарантируют замкнутость.<\/p>\n

О замкнутости следует думать как о математическом качестве. Возьмём такую теорему: «Число 60 делится на все числа». Это легко проверить: на 1 делится, на 2 делится, на 3 делится, на 4 делится. Мне продолжать? Ну на 5 делится, на 6 делится, сколько ещё примеров надо? Какое число ни возьми — на всё делится: 10, 15, 20... Так ведь? Но нет, это ничего не доказывает. Чтобы доказать теорему, нужно искать не удачные примеры в большом количестве, а саму фундаментальную причину, по которой она неизбежно верна. В данном случае такой причины нет.<\/p>\n

При проектировании интерфейса сложно требовать от дизайнеров рисования полного графа состояний и переходов. Не уверен, что делал такое хоть раз в жизни. Но всё же полезно хотя бы понять, что это такое. Полезен и опыт программирования — оно развивает интуицию на такие вещи. Смотришь на проект интерфейса, и чутьё подсказывает: что-то не то, сейчас найду дыры. И дыры находятся. Вообще, чем больше для описания интерфейса приходится придумывать частных исключений, тем больше возникает подозрений в том, что общее правило плохое или вообще не придумано.<\/p>\n", "summary": "Замкнутость интерфейса — это полнота и непротиворечивость правил, определяющих его состояния и переходы между ними при всех допустимых сочетаниях данных", "date_published": "2026-09-24T11:19:10+05:00", "date_modified": "2026-10-10T10:51:24+05:00", "tags": [ "замкнутость интерфейса", "интерфейс", "ССППИ" ], "_date_published_rfc2822": "Thu, 24 Sep 2026 11:19:10 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6834", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } }, { "id": "6187", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/reversibility\/", "title": "Обратимость элемента интерфейса", "content_html": "

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

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

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

Другой пример необратимости — обозначение незаполненных обязательных полей красной рамкой после расфокуса. Изначально поле выглядит просто пустым; пользователь заходит в него, а потом выходит, так и не заполнив (или заполняет, но потом стирает то, что ввёл). Система обводит поле красной рамкой, подсказывая, что оставить его пустым нельзя. После этого невозможно вернуть поле в начальное «чистое» состояние. Решением могло бы быть плавное затухание красной рамки, чтобы поле вернулось в начальное состояние через секунду.<\/p>\n", "summary": "Обратимость — свойство элемента управления в интерфейсе, при котором пользователь может в любой момент вернуть его в начальное состояние, а в общем случае — свободно переключать между всеми доступными", "date_published": "2023-12-29T18:58:39+05:00", "date_modified": "2026-10-09T20:00:39+05:00", "tags": [ "интерфейс", "радиокнопки", "ССППИ", "элементы интерфейса" ], "_date_published_rfc2822": "Fri, 29 Dec 2023 18:58:39 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6187", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } } ], "_e2_version": 4309, "_e2_ua_string": "Aegea 12.0a (v4309e)" }