АВТОР
Даниил Акерман
ДАТА ПУБЛИКАЦИИ
5 июля 2026 г.
КАТЕГОРИЯ
BUSINESS
ВРЕМЯ ЧТЕНИЯ
20 минут


Даниил Акерман
CEO & Founder
CEO и основатель МАЙПЛ. Эксперт в области AI/ML, веб-разработки и CRM-систем с 5+ летним опытом. Руководит командой из 10+ специалистов. Реализовал более 80 IT-проектов для бизнеса. Специализируется на внедрении нейросетей и автоматизации бизнес-процессов.
t.me/myplnews
Наша команда готова взяться за ваш проект. Оставьте заявку — мы свяжемся с вами и обсудим детали.
Похожие статьи
Все статьи

Разработка ERP-системы на заказ в 2026 году стоит от 300 000 рублей за простейший MVP до 100 млн рублей и выше за крупные Enterprise-проекты.
Читать полностью

Стоимость разработки CRM-системы на заказ в 2026 году начинается от 300 000 ₽ для типовых low-code инструментов и превышает 2 000 000 ₽ за сложные full-code архитектуры.
Читать полностью

Выбор подрядчика для внедрения CRM в 2026 году требует оценки отраслевой экспертизы, прозрачного договора с фиксированной стоимостью и готовности команды…
Читать полностью
Телеграмм
Делимся визуально привлекательными фрагментами наших последних веб-проектов.
ВКонтакте
Пишем о интересных технических решениях и вызовах в разработке.
MAX
Демонстрируем дизайнерские элементы наших веб-проектов.
TenChat
Деловые связи, кейсы и экспертные публикации.
Рассылка
© 2025-2026 МАЙПЛ. Все права защищены.
| Тип документа | Research memo (аналитический меморандум) |
| Предмет | Пересечение проверенных временем принципов HCI, актуальных подходов к проектированию enterprise-интерфейсов и научно обоснованных теорий интерфейса будущего |
| Дата | 5 июля 2026 |
| Горизонт данных | Источники верифицированы на июль 2026; спорные атрибуции и ограничения доказательности помечены отдельно (см. §9) |
Проектирование enterprise-интерфейсов — это не «искусство вкуса», а инженерная дисциплина с воспроизводимой доказательной базой. Ниже — сжатая выжимка выводов, каждый из которых раскрыт и подкреплён источниками в теле документа.
Фундамент устойчив, потому что описывает человека, а не технологию. Законы Фиттса (1954), Хика–Хаймана (1952–53) и ограничения рабочей памяти (Miller 1956; уточнение Cowan 2001) описывают биологию восприятия и моторики — она не устаревает вместе с фреймворками. Их надо применять корректно: половина «народных» трактовок (например, «≤7 пунктов в меню») — методологические ошибки (см. §1.1).
Своды принципов сходятся к одному ядру. 10 эвристик Нильсена, 8 правил Шнайдермана, принципы Нормана и Рамса независимо приходят к одному: консистентность, предотвращение ошибок, обратная связь, минимализм, узнавание вместо припоминания. Это ядро — операциональный чек-лист, а не философия; в нормативной форме оно закреплено в ISO 9241-110 (§2). Красота в этой системе — не украшение, а беглость обработки: измеримое ремесло поверх того же ядра (§3.8).
Дизайн-системы стали инфраструктурой, а дизайн-токены — её стандартом. В октябре 2025 формат W3C DTCG достиг первой стабильной версии, что впервые дало vendor-neutral контракт «дизайн ↔ код» (W3C DTCG, 2025.10). Трёхуровневая архитектура токенов (primitive → semantic → component) — новая норма; следующий потребитель системы после человека и рендерера — AI-агент (§3.1–3.2). Материальный сдвиг Apple Liquid Glass (2025) подтверждает вектор: конкурируют системы, а не стили, — но его же критика и коррекция WWDC 2026 показывают предел переноса эстетики в плотные данные (§3.7).
AI сдвигает парадигму взаимодействия. Генеративный AI — «третья UX-парадигма» за 60 лет: переход от «команд» к «спецификации намерения и результата» (Nielsen, NN/g, 2023). Но выигрывают гибриды «intent + GUI», а не чистый чат; ключевые паттерны — прозрачность возможностей, human-in-the-loop, обработка галлюцинаций (Amershi et al., CHI 2019) (§3.3).
Правовое давление на интерфейс стало двойным: доступность + AI. WCAG 2.2 — рекомендация W3C с октября 2023 (мин. размер цели 24×24 px и др.); European Accessibility Act действует с 28 июня 2025 с экстерриториальными штрафами. WCAG 3.0 остаётся черновиком до ~2030, а APCA не входит в его текущую версию — частое заблуждение. Параллельно EU AI Act (Reg. 2024/1689): запреты (включая распознавание эмоций на рабочем месте) — с февраля 2025, прозрачность AI-взаимодействия (Art. 50) — со 2 августа 2026; обязательства для high-risk систем (включая HR-модули) перенесены Digital Omnibus на 2 декабря 2027, но требование human oversight (Art. 14) уже задаёт дизайн-рамку агентных функций (§3.4, §7.4).
Специфика enterprise — это управление сложностью, а не её устранение. Закон Теслера: неустранимый минимум сложности кто-то несёт — либо система, либо пользователь. Задача — снять с пользователя extraneous когнитивную нагрузку (Sweller, 1988), оставив ему только сложность предметной области (§4.1). Экономический корень исторически плохого enterprise-UX — разрыв «покупатель ≠ пользователь»: решение о покупке принимает комитет, который в системе не работает, и обратная связь от боли пользователя до денег вендора рвётся (§4.9).
Плотные данные требуют дисциплины, а не «богатого UI». Для таблиц есть измеримые нормы: высоты строк 32–48 px, числа выравниваются вправо табличными цифрами, freeze шапки/первой колонки, пагинация предпочтительнее бесконечного скролла для рабочих данных (NN/g; Carbon) (§4.2).
Формы и отклик системы — недооценённые рычаги enterprise-UX. Формы — главная поверхность ввода ERP/CRM: верхние лейблы ускоряют заполнение (Penzo, 2006), валидация — по потере фокуса, ввод никогда не теряется. Пороги отклика 0.1 / 1 / 10 с (Miller 1968; Nielsen 1993) и порог Доэрти ~400 мс (1982) делают скорость продуктовой метрикой, а не «внутренним делом бэкенда» (§4.3–4.4).
Ведущие enterprise-вендоры конвергентны. SAP Fiori, Salesforce SLDS, Workday Canvas, ServiceNow Horizon, Microsoft Fluent ставят в ядро ясность, согласованность и роль-ориентированность. SAP делает «role-based» первым принципом (§4.16).
Виджет — единица проектирования, поставки и надзора. Enterprise-интерфейс собирается не из экранов, а из виджетов с фиксированным контрактом: обязательные состояния (загрузка/пусто/ошибка/частичные данные — Harel, 1987), один tab-stop с внутренней клавиатурной навигацией (W3C APG), связи drill-down и cross-filtering (Shneiderman, 1996; Becker & Cleveland, 1987), поставка через дизайн-систему с версионированием. Ошибка в виджете — системная, а не локальная (§5).
Детализация прототипа почти не влияет на результаты тестов. Эмпирика 1989–2002 гг. (Virzi; Walker, Takayama & Landay 2002): lo-fi и hi-fi выявляют сопоставимое число и тяжесть проблем — различается лишь их тип. Вывод: тестировать раньше и дешевле (§6.2).
Тестируйте итеративно, а не «монструозно». Модель Нильсена–Ландауэра N·(1−(1−L)ⁿ) при L≈31% даёт ~85% проблем на 5 пользователях. Три цикла по 5 пользователей ценнее одного теста на 15 — с оговоркой о критике «правила пяти» для количественных исследований. Для продуктовых метрик масштаба — фреймворк HEART (Rodden et al., 2010) (§6.5).
Будущее — перераспределение инициативы, а не «смерть GUI». Post-GUI, calm technology, anticipatory, агентные, генеративные, пространственные и мультимодальные интерфейсы описаны исследовательскими программами десятилетия назад (Weiser 1991; Horvitz 1999; Bolt 1980; Gajos & Weld 2004). Для enterprise это означает сдвиг GUI от «места выполнения работы» к «месту надзора и верификации», а ключевой компетенцией становится инженерная психология автоматизации: иронии автоматизации (Bainbridge 1983), ситуационная осведомлённость (Endsley 1995), калибровка доверия (Lee & See 2004) (§7).
Сквозная рекомендация: стройте enterprise-продукт на трёх опорах одновременно — (а) доказательный фундамент HCI как «физика» интерфейса, (б) дизайн-система на токенах как инфраструктура, (в) итеративное тестирование гипотез как метод. Отсутствие любой из трёх опор системно воспроизводит одни и те же дефекты. Четвёртое измерение — время: §7 задаёт рамку, как встраивать агентные и пост-GUI подходы, не разрушая первые три опоры.
Фундаментальные принципы устойчивы, потому что описывают инварианты человека — перцепцию, моторику, память, — а не преходящие технологии. Ниже — доказательная база с точными атрибуциями.
Закон Фиттса. Время наведения на цель растёт логарифмически с отношением дистанции к размеру цели. Формула индекса сложности: ID = log₂(2D/W), время движения MT = a + b·log₂(2D/W) (Fitts, 1954, Journal of Experimental Psychology, 47(6)). В HCI чаще применяется шенноновская формулировка МакКензи ID = log₂(D/W + 1) — она даёт лучшее соответствие эмпирическим данным и корректна при D→0 (MacKenzie, 1992, Human-Computer Interaction, 7(1)). Практические следствия для UI сформулировал Bruce Tognazzini: края и углы экрана имеют «бесконечную» ширину (курсор в них упирается), поэтому меню-бар у кромки быстрее «плавающих» панелей, а угловые «magic corners» — самые быстрые мишени (Tognazzini, First Principles of Interaction Design). Enterprise-вывод: первичные действия — крупные и близкие к курсору/фокусу; глобальные команды выносить к краям; не ставить критичные цели в мелкие плотные кластеры.
Закон Хика–Хаймана. Время выбора растёт логарифмически с числом равновероятных альтернатив: RT = a + b·log₂(n+1) (Hick, 1952, QJEP, 4(1), 11–26; Hyman, 1953, JEP, 45(3), 188–196). Важное ограничение: закон описывает выбор из равновероятных опций при первичном сканировании. Для заученной навигации эксперта поиск заменяется прямым моторным действием (ближе к Фиттсу), и логарифм исчезает. Поэтому дробить сложный enterprise-флоу на множество мелких экранов «ради Хика» — ошибка: это увеличивает общее число шагов (Proctor & Schneider, 2018, review).
Закон Миллера и его злоупотребление. George Miller показал, что объём непосредственной памяти ограничен ~7 ± 2 «единицами», расширяемыми чанкингом (Miller, 1956, Psychological Review, 63(2)). Сам Miller иронизировал: «I have been persecuted by an integer». Типичная ошибка — трактовать это как «≤7 пунктов меню»: видимый список не нужно удерживать в памяти, его можно перечитать (это область принципа «recognition over recall», а не закона Миллера). Более того, при контроле репетиции реальный предел рабочей памяти ближе к 4 ± 1 (Cowan, 2001, Behavioral and Brain Sciences, 24(1)). Enterprise-вывод: ограничивайте не число видимых опций, а число единиц, которые пользователь обязан держать в голове между шагами (параметры фильтра, контекст мастера, незакоммиченные правки).
Немецкая школа гештальта (Wertheimer, Koffka, Köhler, 1910–20-е) установила: восприятие организует элементы в целостные структуры на уровне мозга, а не сенсора (Wertheimer, 1923, Psychologische Forschung). Ключевые законы группировки и их применение:
| Принцип | Суть | Применение в enterprise-UI |
|---|---|---|
| Близость (proximity) | Близкие объекты = группа | Отступы объединяют поля формы без разделителей |
| Сходство (similarity) | Похожие по стилю = группа | Единый стиль всех кликабельных элементов |
| Замкнутость (closure) | Мозг достраивает контур | Иконки и логотипы из неполных форм |
| Непрерывность (continuity) | Элементы вдоль линии связаны | Выравнивание по сетке, «линии чтения» таблиц |
| Общая судьба (common fate) | Движущиеся вместе = группа | Совместная анимация связанных элементов |
| Фигура/фон (figure-ground) | Разделение плана и фона | Модалки, оверлеи, затемнение подложки |
| Общая область (common region) | Общая рамка = группа | Карточки, панели, секции дашборда |
| Prägnanz (простота) | Тяга к простейшей трактовке | Зонтичный принцип минимализма |
Гештальт — теоретический фундамент «группировки без линий»: правильные отступы и выравнивание заменяют бордюры и снижают визуальный шум.
Card, Moran & Newell (1983) превратили HCI из ремесла в предсказательную науку в труде The Psychology of Human-Computer Interaction (Erlbaum, 1983). Три вклада: Model Human Processor (перцептивная/когнитивная/моторная подсистемы с эмпирическими временами цикла); GOMS (Goals, Operators, Methods, Selection rules — модель безошибочного экспертного поведения); KLM (Keystroke-Level Model — оценка времени задачи по сумме элементарных операций). Enterprise-вывод: для высокочастотных рабочих сценариев (оператор колл-центра, бухгалтер, диспетчер) время задачи можно считать заранее по KLM и оптимизировать до внедрения — экономия миллисекунд на операции кратно окупается на объёме.
Bauhaus (школа Вальтера Гропиуса, Веймар, 1919–1933) соединил искусство, ремесло и промышленное производство, задав идеологию функционального минимализма (MoMA, Bauhaus). Две важные атрибуционные поправки: фраза «form follows function» принадлежит Луису Салливану (1896), а не Баухаусу; «less is more» приписывается Мису ван дер Роэ (по традиции, восходит к Петеру Беренсу). Наследники Баухауса создали International Typographic Style (швейцарский стиль) 1950-х — модульные сетки, санс-серифы, объективность; ключевой теоретик — Josef Müller-Brockmann, чей учебник Grid Systems in Graphic Design / Rastersysteme für die visuelle Gestaltung (Niggli, 1981) остаётся печатным первоисточником дисциплины сеток. Именно отсюда — модульные сетки, лежащие в основе современных layout-систем.
Dieter Rams (главный дизайнер Braun) сформулировал в конце 1970-х 10 принципов хорошего дизайна под девизом «Weniger, aber besser» («меньше, но лучше») (Design Museum): хороший дизайн инновационен, полезен, эстетичен, понятен, ненавязчив, честен, долговечен, тщателен до детали, экологичен и минимален. Философия Рамса прямо повлияла на Джони Айва и язык Apple. Enterprise-вывод: принцип «as little design as possible» — прямое противоядие против «feature-creep UI», типичного для ERP.
Технологический фундамент прямого манипулирования сложился в три шага:
Дуглас Энгельбарт на Fall Joint Computer Conference 9 декабря 1968 впервые публично показал мышь, гипертекст и оконную работу (The Mother of All Demos). Xerox PARC на компьютере Alto (1973) в среде Smalltalk реализовал WIMP (Windows, Icons, Menus, Pointer) и метафору рабочего стола, а Xerox Star (1981) стал первым коммерческим продуктом с целостным GUI — ретроспективу его дизайн-решений написали сами создатели (Johnson et al., 1989, IEEE Computer, 22(9)). После визита команды Apple в PARC (1979) идеи легли в основу Lisa и Macintosh. Первый систематизированный публичный свод — Apple Human Interface Guidelines: The Apple Desktop Interface (Addison-Wesley, 1987) — закрепил метафоры реального мира, прямое манипулирование, консистентность, «see-and-point вместо remember-and-type», обратную связь и «прощение» (undo). Важно для §7: GUI сам когда-то был «интерфейсом будущего» — и вытеснил командную строку не полностью, а перераспределил её в нишу экспертов. Тот же сценарий сосуществования следует ожидать и от следующих парадигм.
Четыре канонических свода созданы независимо, в разные десятилетия, разными людьми — и сходятся к одному операциональному ядру. Это сильный аргумент: пересечение — не мода, а инвариант.
Сформулированы в Nielsen, 1994, Proc. CHI'94 (развитие Nielsen & Molich, 1990); актуальные определения — на NN/g. С 1994 года список не менялся — в 2020 уточнены лишь определения.
Из Designing the User Interface (1987); авторская формулировка — на странице Шнайдермана, Univ. of Maryland: (1) стремиться к консистентности; (2) обеспечивать универсальную доступность / ускорители для частых пользователей; (3) давать информативную обратную связь; (4) проектировать диалоги с завершением; (5) предотвращать ошибки; (6) допускать лёгкую отмену; (7) сохранять у пользователя чувство контроля; (8) снижать нагрузку на кратковременную память. (Атрибуционная точность: формулировка 2-го правила «seek universal usability» — из поздних изданий; в оригинале 1987 г. — «enable frequent users to use shortcuts».)
В The Design of Everyday Things (1-е изд. 1988; Revised & Expanded — Basic Books, 2013) Норман закрепил словарь дизайна: аффордансы (возможности действия, понятие из Гибсона), сигнификаторы (воспринимаемые указатели, где и как действовать — введены во 2-м издании, чтобы исправить массовое неверное употребление слова «affordance»), маппинг, обратная связь, ограничения (constraints). Два «залива», которые дизайн обязан перекрывать:
Gulf of Execution — разрыв между намерением и доступным способом его реализовать; Gulf of Evaluation — между состоянием системы и лёгкостью его понять. Хороший интерфейс «наводит мосты» через оба (термины развиты в Hutchins, Hollan & Norman, 1985). Эта пара понятий переживёт GUI: для голосовых, агентных и «невидимых» интерфейсов оба залива не исчезают, а расширяются — см. §7.1 и §7.4.
| Общий принцип | Nielsen | Shneiderman | Norman | Rams |
|---|---|---|---|---|
| Консистентность | №4 | №1 | маппинг | «понятность» |
| Предотвращение / отмена ошибок | №5, №9 | №5, №6 | constraints | «честность» |
| Обратная связь / видимость статуса | №1 | №3 | feedback | — |
| Контроль пользователя | №3 | №7 | — | «ненавязчивость» |
| Минимализм | №8 | — | — | «as little design as possible» |
| Снижение нагрузки на память | №6 | №8 | signifiers | «понятность» |
| Эффективность для экспертов | №7 | №2 | — | — |
Практический смысл таблицы: это готовый heuristic-evaluation чек-лист. Любой экран enterprise-продукта прогоняется по семи строкам — каждая «дыра» в строке есть измеримый дефект, а не «вкусовщина».
То же ядро зафиксировано в международном стандарте ISO 9241-110:2020 «Interaction principles» — семь принципов взаимодействия: пригодность для задач пользователя, самоописательность, соответствие ожиданиям, обучаемость, управляемость, устойчивость к ошибкам использования, вовлечённость (ISO 9241-110:2020). Для enterprise это практично вдвойне: на ISO удобно ссылаться в корпоративных требованиях, тендерах и договорах на разработку — «соответствие ISO 9241-110» проверяемо, в отличие от «удобного интерфейса». Дополняющий эмпирический аргумент в пользу консистентности — закон Джейкоба: пользователи бóльшую часть времени проводят в других продуктах и переносят оттуда ожидания, поэтому «стандарты» из эвристики №4 включают и внешние конвенции, а не только внутренний стайлгайд (Nielsen, 2000).
Дизайн-система в 2026 — не «библиотека кнопок», а инфраструктурный слой: токены + компоненты + гайдлайны + код. Сравнение ведущих систем по верифицированным данным их вендоров:
| Система | Версия / дата (2025–26) | Открытость | Платформы | Архитектура токенов | Философия |
|---|---|---|---|---|---|
| Material 3 (Expressive) | Stable c Android 16 QPR1, 03.09.2025 | Open-source | Android/Web/Flutter/Wear | 3 уровня, dynamic color | Expressive, spring-моторика |
| Salesforce SLDS 2 | Beta c 25.02.2025 | Open (Salesforce) | Lightning/web | Styling hooks (CSS vars) | Decoupled, «agentic-ready» |
| Adobe Spectrum 2 | Анонс 12.2023, выкатка 2024+ | Публичная спека | Web/iOS/desktop | Токенизирован | Functional & joyful |
| Microsoft Fluent 2 | Актуальна | Open-source | Web/Windows/Apple/cross | 2 слоя (global/alias) | OS-native темизация |
| IBM Carbon v11 | v11 | Open-source (Apache-2.0) | Web (React и др.) | 3 уровня + component | Enterprise, IBM Design Language |
| Shopify Polaris | 2025-10, Web Components | Open-source | Все surface Shopify | Токены | Web-components, unified |
| Atlassian | Актуальна | Публичная | Web/React | Token-first, семантич. | Semantic-first |
| Ant Design v6 | Ноябрь 2025 | Open-source (MIT) | Web/React | CSS Variables | Enterprise-class |
Ключевой сдвиг 2025 года — отделение стиля от компонента через CSS-переменные (Salesforce SLDS 2 «styling hooks», Ant Design v6 CSS-variables mode, Carbon v11 «все цветовые токены как CSS Custom Properties»). Это делает возможными динамическую темизацию (light/dark/high-contrast), брендирование и — в перспективе Salesforce — «агентные» темы (SLDS 2; Carbon v11). Отдельно значим Material 3 Expressive: самый исследованный апдейт Google (46 исследований, >18 000 участников), заявляющий распознавание ключевых элементов до 4× быстрее и переход на физический spring-движок анимации (Google, 2025).
У дизайн-системы появляется и третий потребитель — после дизайнера и рендерера — AI-агент: машиночитаемые токены (DTCG JSON) и формальные компонентные контракты позволяют генеративным инструментам собирать интерфейс из легитимных «кирпичей», а не рисовать произвольный UI (SLDS 2 «agentic-ready»; MCP-интеграция Penpot). Подробно о generative UI — §7.5.
Главное событие инфраструктуры: 28 октября 2025 W3C Design Tokens Community Group выпустила первую стабильную версию спецификации — Design Tokens 2025.10 (W3C DTCG). Это vendor-neutral JSON-формат (application/design-tokens+json, расширения .tokens/.tokens.json) с поддержкой темизации, мультибренда без дублирования, современных цветовых пространств (Display P3, Oklch) и алиасов. Поддержан Figma, Penpot, Sketch, Tokens Studio, Style Dictionary, Supernova, zeroheight и др.
Отраслевой стандарт — трёхуровневая архитектура (Martin Fowler, token-based UI architecture):
Primitive-уровень хранит «сырые» значения, semantic — намерение (переживает ребрендинг), component — контекст. Мост в код обеспечивают Style Dictionary (трансформация JSON → платформенные артефакты) и Tokens Studio (синхронизация Figma ↔ git). Enterprise-вывод: без семантического слоя масштабная система становится неуправляемой при первой же смене темы или бренда.
Тезис Якоба Нильсена: генеративный AI — первая новая UX-парадигма за 60 лет (после пакетной обработки и командного/GUI-взаимодействия). Суть — intent-based outcome specification: пользователь формулирует желаемый результат, а не последовательность команд; это «реверсирует locus of control» (Nielsen, NN/g, 2023). Практический нюанс: побеждает не чистый чат, а гибрид «intent + GUI» — намерение для нечёткого, прямое манипулирование для точного.
Доказательная база паттернов «человек ↔ AI» — 18 руководств Microsoft (Amershi et al., CHI 2019), сгруппированных по фазам взаимодействия: сначала прояснить, что система умеет и насколько хорошо; во время — контекстность и эффективная коррекция; при ошибке — объяснимость и «мягкий отказ»; со временем — обучение на поведении (Guidelines for Human-AI Interaction, основа HAX Toolkit). Дополняют: Google PAIR People + AI Guidebook, Apple HIG (Generative AI), паттерн-библиотека The Shape of AI.
Ключевые прикладные паттерны для enterprise-копайлотов и агентов:
Текущая волна в enterprise — встроенные ассистенты, эволюционирующие в агентов: SAP Joule (2023), Microsoft Copilot в Dynamics 365 (2023), Salesforce Agentforce (2024) — переход от «подсказчика у поля ввода» к исполнителю, которому делегируют задачи (SAP Joule; Salesforce Agentforce). Теоретическая рамка агентного взаимодействия, уровни автономии и риски — в §7.4.
Enterprise-вывод: доступность в SaaS, продаваемом в ЕС, — теперь вопрос юридического риска, а не «доброй воли». Мин. размер интерактивной цели 24 px, видимость фокуса и APG-паттерны сложных виджетов должны быть зашиты в дизайн-токены и компоненты по умолчанию; для AI-функций дорожная карта комплаенса (Art. 50 — уже, Art. 14/high-risk — к декабрю 2027) закладывается в дизайн сейчас.
Термин responsive web design ввёл Ethan Marcotte (A List Apart, 2010): fluid grid + гибкие изображения + media queries. Эволюция 2022–2023 — container queries: компонент реагирует на размер своего контейнера, а не вьюпорта; size-queries достигли baseline-поддержки во всех движках к 2023 (caniuse; web.dev). Это критично для enterprise: один и тот же виджет дашборда живёт и в узкой боковой панели, и в широкой сетке. Adaptive vs responsive: responsive — плавная перекомпоновка одного макета; adaptive — набор фиксированных макетов под брейкпоинты. Многоплатформенность 2026 реализуется через дизайн-систему: единый токен-файл (DTCG) → генерация под web/iOS/Android/Flutter (Style Dictionary).
Четыре сквозных слоя, из которых состоит любой экран; все четыре в 2026 материализуются как токены (§3.2) — поэтому их место здесь, в инфраструктуре.
Типографика. Рабочий интерфейс — это чтение под нагрузкой: типографическая шкала фиксирована (5–7 ступеней от caption до заголовка страницы, заданных токенами), базовый кегль тела — не ниже 14–16 px для плотных данных, межстрочный интервал UI-текста ~1.4–1.5. Длина строки текстовых блоков — 45–90 знаков; классическая норма «около 66» (Bringhurst, The Elements of Typographic Style; практический свод — Butterick, Practical Typography). Для данных — правила §4.2: числа табличными (моноширинными) цифрами, выравнивание по десятичной точке. Иерархия строится размером и насыщенностью, а не «жирным везде»: два уровня выделения на экран — предел, дальше выделение перестаёт выделять (преаттентивный ресурс, §4.5).
Цвет. Палитра в enterprise — семантическая система, а не украшение: нейтральная основа + фиксированные семантические роли (success / warning / danger / info) + 1–2 акцента бренда, все — через semantic-токены (§3.2), что даёт light/dark/high-contrast темы бесплатно. Контрастные пороги — юридическая база: текст AA, не-текст ≥3:1 (§3.4). Цвет никогда не единственный канал кодирования: ~8% мужчин имеют ту или иную форму цветовой слепоты, поэтому статус дублируется иконкой, подписью или паттерном; для категориальных палитр графиков существует проверенное решение — палитра Окабэ–Ито (Wong, 2011, Nature Methods, 8(6)). Красный/зелёный без второго канала — антипаттерн номер один финансовых дашбордов.
Иконография. Иконки — самый переоценённый элемент интерфейса: универсально считываемых почти нет (дом, поиск, корзина — и список быстро заканчивается), поэтому иконка в навигации и действиях сопровождается подписью; «иконка без подписи» допустима только для многократно заученных частотных действий с тултипом (NN/g, Icon Usability). Технические нормы: единый набор (один стиль штриха, одна визуальная плотность), общий пиксельный грид (16/20/24 px), выравнивание по оптическому центру; смысловые иконки — с текстовой альтернативой, декоративные — скрыты от скринридера (§3.4).
Отступы и сетка. Пространственная система — шкала, кратная 4/8 px, заданная spacing-токенами (§3.2): выравнивание становится арифметикой, а не глазомером (Material 3, Layout). Правило близости (§1.2) операционализируется просто: отступ внутри группы всегда меньше отступа между группами — если это не так, группировка врёт. Макро-уровень — модульные сетки (§1.4, §5.3).
Что это. 9 июня 2025 на WWDC Apple представила Liquid Glass — первый за 12 лет смен дизайн-языка и первый единый материал для всех шести ОС сразу (iOS 26, iPadOS 26, macOS Tahoe, watchOS 26, tvOS 26, visionOS 26) (Apple Newsroom, 09.06.2025). Это динамический «мета-материал»: полупрозрачность, отражение и преломление фона (Apple называет эффект lensing), многослойная глубина, отклик на движение устройства, контент и контекст (Apple HIG, Materials; сессии «Meet Liquid Glass» и «Get to know the new design system»). Важно не упростить суть: это не «ещё больше плоского минимализма», а движение в обратную сторону — от flat-эстетики iOS 7 (2013) назад к глубине, слоистости и материальности; генеалогия — скевоморфизм (2007–2012) → flat (2013–2024) → материальная глубина (2025–), с очевидным источником в пространственном интерфейсе visionOS (§7.6). «Упрощение» здесь другого рода: контент первичен, а хром рецессивен — элементы управления и навигации собираются в отдельный «плавающий» функциональный слой из стекла и отступают, уступая место данным; сокращается визуальный мусор; форма контролов согласуется с геометрией устройства (концентричность радиусов, капсульная геометрия).
Свод правил, который диктует материал (по HIG и WWDC-сессиям; Adopting Liquid Glass):
Тренд и его критика. Отраслевой эффект 2025–26 — ренессанс glassmorphism в Figma/Framer-практике и главный экспортируемый урок: «проектируй системы, а не стили» — один материал с параметрами вместо шести платформенных гайдов (прямое родство с §3.1). Но приём был смешанным, и это документированный факт, а не фон: пользователи массово жаловались на читаемость, сравнивая эффект с Windows Vista/Aero (MacRumors, 17.09.2025); независимая экспертиза NN/g зафиксировала снижение юзабилити — «интерфейс тянет внимание на себя вместо поддержки контента» (NN/g, «Liquid Glass Is Cracked», 2025). Реакция Apple — редкий публичный разворот к ясности: осенние сборки снижали прозрачность, а на WWDC 2026 (08.06.2026) добавлен пользовательский слайдер тонировки «от ультрапрозрачного до полностью тонированного» и возвращён цвет иконкам сайдбаров (MacRumors, 08.06.2026; TechCrunch). Урок читается через приоритеты Salesforce (§4.16): при конфликте Clarity › Beauty — рынок заставил даже Apple закрепить это настройкой. Маркетинговые эпитеты («живой», «восхитительный») — вендорские заявления; измеримых независимых свидетельств пользы эффекта нет, издержки — задокументированы (§9).
Enterprise-проекция: заимствуй / не переноси.
| Заимствовать | Почему и как | Не переносить | Почему |
|---|---|---|---|
| Контент-первичность и рецессивный хром | Данные — контент enterprise: сворачиваемый сайдбар (§4.6), плавающий тулбар над таблицей, хром отступает при скролле | Translucency под плотными данными | Переменный фон = негарантируемый контраст текста таблиц/форм; WCAG-порог (§3.4) на динамической подложке недоказуем |
| Материал как система токенов | «Роль поверхности вместо фиксированного цвета» = наша шкала surface/elevation (§3.2, §4.5), доведённая до конца | Рефракция/lensing в data-heavy | Оптический шум = extraneous load (§4.1) и chartjunk (§4.5); искажение фона под KPI недопустимо |
| Режимы доступности как модификаторы материала | Шаблон для DS: каждый surface-токен обязан иметь reduced-transparency/high-contrast вариант (§5.8, DoD виджета) | Прозрачные KPI-тайлы и виджеты | Прямо нарушает норму §4.5: единый непрозрачный surface ряда; «стеклянный» тайл сливается с фоном |
| Motion как подсказка с бюджетом | Происхождение/назначение слоёв (§4.4, §4.12) | Эластичный motion в частотных циклах | Экономика §4.4: сотни операций в день не прощают декоративных 300 мс |
| Концентричность и геометрическая дисциплина | Радиусы — вложенной шкалой токенов, а не на глаз (§3.6) | Glass на рабочих оверлеях с формами | Drawer с вводом данных (§4.12, §4.3) требует непрозрачной подложки; стекло допустимо на эфемерных сигналах (тост) во frost-режиме |
Правило дефолта для enterprise: то, к чему Apple пришла через год критики и слайдер, в рабочих системах ставится дефолтом сразу — максимальная читаемость из коробки (эквивалент Reduced Transparency), украшение — осознанный opt-in пользователя; и любой экран обязан проходить приёмку в режимах Increased Contrast / Reduced Transparency / Reduced Motion, потому что у операторов с 8-часовой сменой эти режимы включены чаще, чем у потребителя (§3.4, §5.8).
«Красиво» в enterprise — не вкусовщина и не картинки: это композиция из трёх слоёв — доказанных механизмов эстетического восприятия, измеримого ремесла и контекста (бренд, домен, культура). Раздел разбирает все три и отделяет воспроизводимое от вопросов вкуса.
Теория: почему красота работает. Четыре опоры. Первая — эстетико-утилитарный эффект: воспринимаемая красота повышает воспринимаемое удобство. Открыт на банкоматных клавиатурах (Kurosu & Kashimura, CHI'95), воспроизведён в другой культуре (Tractinsky, CHI'97; Tractinsky, Katz & Ikar, 2000, «What is beautiful is usable», Interacting with Computers, 13(2)). Важна честная оговорка: эффект — про воспринимаемую юзабилити; в тестах красота работает как гало и маскирует реальные проблемы (NN/g, Aesthetic-Usability Effect; см. §9). Вторая — эмоциональный дизайн Нормана: три уровня отклика — висцеральный (мгновенная реакция на форму), поведенческий (удовольствие от работы, которая получается), рефлексивный (что продукт говорит обо мне); тезис «attractive things work better» опирается на то, что положительный аффект расширяет мышление и повышает толерантность к мелким трудностям (Norman, Emotional Design, Basic Books, 2004). Для enterprise центр тяжести — поведенческий уровень: красота инструмента, которым хорошо работается. Третья — беглость обработки (processing fluency): красивым воспринимается то, что мозг обрабатывает легко; симметрия, контраст, знакомость и ясная структура повышают беглость — и удовольствие (Reber, Schwarz & Winkielman, 2004, PSPR, 8(4)). Это мост, соединяющий красоту с ядром меморандума: снижение extraneous-нагрузки (§4.1) и гештальт-порядок (§1.2) — это и есть производство беглости; в data-heavy интерфейсе ясность не конкурирует с красотой — она её механизм. Четвёртая — скорость суждения: эстетическая оценка страницы формируется за ~50 мс и дальше окрашивает всё взаимодействие (Lindgaard et al., 2006, Behaviour & IT, 25(2)) — «первый экран» продаёт доверие раньше, чем пользователь успел что-то сделать (ср. §4.9: пресейл-демо).
Ремесло: из чего красота складывается измеримо. Проверяемые критерии, каждый — аудируем без разговоров о вкусе:
Эстетика именно 2026 года. Отличия от «красоты 2015–2022»: (а) возврат материальности и глубины — слои, свет, стекло вместо тотальной плоскости (§3.7), в enterprise — в сдержанной форме: глубина только как семантика слоёв; (б) AI-native визуальность — интерфейс, частично собираемый под пользователя и задачу (§7.5), где красота смещается из «нарисованного экрана» в качество системы генерации: сгенерированное красиво тогда, когда собрано из дисциплинированных токенов и компонентов (§5.9); (в) движение как норма, но сдержанное — хореография переходов стала ожидаемой, декоративность — нет (§4.4); (г) доступность как составляющая красоты: контрастные и спокойные темы — не «режим для немногих», а признак зрелого вкуса; инклюзивное = хорошо сделанное (§3.4, §3.7). И главный анти-тренд: усталость от одинаковости. Конвергенция шаблонов, библиотек и генеративных инструментов произвела «эпоху среднего» — продукты, неотличимые друг от друга (Murrell, «The Age of Average», 2023); AI-генерация UI усилила эффект. Следствие 2026 года — рост цены отличимости и характера: узнаваемая типографика, собственный тон текстов, фирменные микродетали. Для enterprise это не вседозволенность: характер добавляется в ненесущие слои (пустые состояния, онбординг, иллюстрации, тон голоса), а не в таблицы и формы.
Красота против удобства: функциональная красота. Норма отношения задана давно: форма следует за функцией (Салливан, §1.4), «хороший дизайн эстетичен» — лишь один из десяти принципов Рамса, и он не первый (§1.4). Красота служит задаче, пока проясняет структуру, и вредит, когда становится декором: chartjunk (§4.5), «эстетичный» серый текст ниже порога контраста (§3.4), тонкие шрифты на плотных данных, стекло под таблицей (§3.7), скрытые ради чистоты элементы управления (обнаружимость, §4.6). Отдельный класс — тёмные паттерны красоты: оформление, маскирующее состояние системы (задизейбленное неотличимо от активного), «спокойные» тона, прячущие ошибку, красивое демо, продающее сломанный поток (гало-эффект + §4.9). Рабочий тезис раздела: самая трудная красота — та, что снижает когнитивную нагрузку; орнамент умеет добавлять каждый.
Субъективность и контекст. Красота не универсальна: эстетические предпочтения измеримо различаются между культурами и демографиями (Reinecke & Gajos, CHI 2014), зависят от бренда и домена — красота consumer-продукта (выразительность, вау-эффект) и красота enterprise (ясность, надёжность, отточенность) — разные целевые функции. Граница измеримого: контраст, выравнивание, консистентность, ритм — аудируемы (чек-лист выше); воспринимаемая эстетика — измерима валидированными шкалами (VisAWI: простота, разнообразие, цветность, мастерство — Moshagen & Thielsch, 2010, IJHCS, 68(10)); неустранимо субъективными остаются вкус, насмотренность и культурный код бренда — их место в дизайн-принципах компании (§4.16), а не в спорах на ревью.
Enterprise-проекция: «скучное, сделанное красиво». Эталоны корпоративной эстетики 2020-х — Stripe, Linear, Notion — красивы не орнаментом, а дисциплиной, и её составляющие воспроизводимы: у Stripe — типографика и документация как продукт (ритм, ширина колонки, код-блоки — §3.6); у Linear — плотность без тесноты, скорость как эстетическое качество (отклик <100 мс читается как «отполировано», §4.4) и монохром с одним акцентом; у Notion — спокойная нейтральность, освобождающая сцену контенту (§3.7, контент-первичность). Правила красоты под давлением данных: красота таблицы — это её сканируемость (выравнивание, табличные цифры, ритм строк — §4.2); красота дашборда — иерархия с одного взгляда (§4.5); один акцентный цвет на экран; глубина — только семантика слоёв (§3.7); характер — в пустых состояниях и текстах, не в гриде. Антипаттерны: градиенты и тени на столбцах диаграмм, «карточка в карточке в карточке», декоративные иллюстрации внутри рабочих экранов, фирменный шрифт с плохими цифрами в финансовых таблицах, анимация появления каждой строки. Итоговая формула для §8-ревью: красиво то, что при равной функциональности читается быстрее, а при равной скорости — вызывает доверие и желание работать именно здесь.
Это класс интерфейсов, где эстетика вторична по отношению к пропускной способности: плотные данные, сложные роли, высокая частота повторяющихся операций, обученные пользователи. Здесь ошибки проектирования масштабируются на тысячи человеко-часов — и десятилетиями воспроизводились системно, потому что рынок enterprise-ПО долго не наказывал за плохой UX: решение о покупке принимал не тот, кто работает в системе (§4.9).
Теория когнитивной нагрузки: рабочая память ограничена, и обучение/работа страдают, когда ресурс уходит не на суть задачи (Sweller, 1988, Cognitive Science, 12(2)). Каноническая триада нагрузки:
(Атрибуционная точность: полная триада intrinsic/extraneous/germane закреплена в поздних работах — Sweller, Ayres & Kalyuga, Cognitive Load Theory, Springer, 2011, — а не в статье 1988 года.)
Парная концепция — закон Теслера (закон сохранения сложности): у всякой системы есть неустранимый минимум сложности; вопрос лишь в том, кто её несёт — система или пользователь (Tesler's Law). Рабочий инструмент управления intrinsic-нагрузкой — прогрессивное раскрытие: ядро сценария видно сразу, редкие и продвинутые функции раскрываются по запросу (Nielsen, Progressive Disclosure). Enterprise-вывод: нельзя «упростить» ERP до трёх кнопок — сложность предметной области реальна. Можно и нужно переложить её максимум на систему (умные дефолты, автоподстановка, валидация), оставив пользователю только неустранимое ядро.
Таблица обслуживает 4 задачи пользователя (Laubheimer, NN/g, «Data Tables: Four Major User Tasks»): (1) найти записи по критерию, (2) сравнить данные, (3) просмотреть/отредактировать одну строку, (4) выполнить действие над записями. Из этого следуют измеримые нормы.
Плотность и высота строк (верифицированные значения дизайн-систем):
| Источник | Уровни плотности | Высоты строк (px) |
|---|---|---|
| Carbon (IBM) | xs / sm / md / lg / xl | 24 / 32 / 40 / 48 / 64 |
| Pencil & Paper | Condensed / Regular / Relaxed | 40 / 48 / 56 |
| Практический консенсус | «компактный» / «комфортный» | ~32–40 / ~48–56 |
Источники: Carbon Data table — Style; Pencil & Paper, «Data Table Design UX Patterns».
Правила, дающие максимальный эффект:
Рендер больших наборов — стратегический выбор:
| Подход | Когда | Плюсы | Минусы |
|---|---|---|---|
| Пагинация | Рабочие данные; нужен контроль поверх фильтров-сортировок | Прогресс, стабильное состояние, deep links | Лишние клики, разрыв потока |
| Infinite scroll | Контентные ленты (не рабочие таблицы) | Вовлечённость, бесшовность | Плох для возврата к записи, ломает footer |
| Виртуализация | Очень большие гриды, нужен плавный скролл | Максимальная производительность | Сложнее; риски для Ctrl+F и доступности |
| Гибрид (пагинация + виртуализация) | Тяжёлые enterprise-таблицы | Производительность + предсказуемость | Наибольшая сложность реализации |
Для рабочих данных NN/g фиксирует предпочтение пагинации бесконечному скроллу — она даёт контроль и ощущение прогресса. Технически большие гриды тянут два зрелых подхода: AG Grid (batteries-included, DOM-виртуализация строк/колонок встроена — офиц. документация) и TanStack Table (headless, виртуализация отдельной библиотекой TanStack Virtual) — оба класса решений эксплуатируются на наборах 100k+ строк; выбирайте по оси «готовые функции vs полный контроль рендера», опираясь на собственный бенчмарк на своих данных, а не на сравнения от вендоров конкурирующих гридов.
Карточная раскладка (card view) как альтернатива таблице. Карточки уместны для просмотра разнородных записей с малым числом атрибутов; для сравнения многих записей по одним полям выигрывает таблица — поэтому переключатель «карточки/список» сохраняется в состоянии пользователя, а вид по умолчанию выбирается по доминирующей задаче роли (NN/g, Cards: UI-Component Definition; Material 3, Cards). Правила, делающие сетку карточек сравнимой, а не «витринной»:
Формы — главная поверхность ввода в CRM/ERP: карточка сделки, приёмка, проводка, заявка. Ошибки здесь дороже, чем в таблицах: они портят данные, на которых потом строятся отчёты. Канон дисциплины — Luke Wroblewski, Web Form Design: Filling in the Blanks (2008) (lukew.com); ключевые эмпирические результаты:
Enterprise-вывод: лучшая форма — та, которую не пришлось показывать: автозахват данных из писем, звонков и документов с подтверждением человеком постепенно замещает ручной ввод (см. Zero UI, §7.1). Пока форма существует — её экономика измерима: время заполнения по KLM и доля ошибок на поле.
Скорость — это функция UX, а не «внутреннее дело бэкенда». Канонические пороги удерживаются в психологии с 1968 года (R. B. Miller, 1968, AFIPS; подтверждены в Card, Robertson & Mackinlay, 1991; популяризованы Nielsen, 1993):
| Порог | Восприятие | Требование к UI |
|---|---|---|
| ≤ 0.1 с | «Мгновенно», прямое манипулирование | Никакой индикации не нужно |
| ≤ 1 с | Заметная пауза, но поток мысли не рвётся | Без спиннера; допустима лёгкая индикация |
| ≤ 10 с | Предел удержания внимания на диалоге | Обязателен индикатор прогресса; дольше — фоновая задача с уведомлением |
Дополнение из индустриальной эмпирики — порог Доэрти: при отклике системы < ~400 мс продуктивность оператора растёт нелинейно — сокращается не только время ожидания, но и число ошибок и «потерь контекста» (Doherty & Thadani, IBM, 1982). Практические паттерны:
Микровзаимодействия. Единица обратной связи — микровзаимодействие: атомарный цикл «триггер → правила → фидбек → циклы/режимы» (Saffer, Microinteractions, O'Reilly, 2013). Практические нормы для enterprise: длительность UI-переходов 150–300 мс (быстрее — незаметно, дольше — тормозит оператора; Material 3, Motion); анимация несёт смысл — откуда пришло и куда делось (появление строки, сворачивание панели), а не «оживляж»; обязательное уважение к настройке prefers-reduced-motion (§3.4); у каждого действия есть немедленный микро-отклик даже при долгой операции (нажатие видно сразу, результат — по порогам таблицы выше). Антипаттерн: декоративная анимация в частотном цикле — 400 мс «красивого» перехода × 300 операций в день = 2 минуты чистого ожидания на оператора.
Enterprise-вывод: для оператора, выполняющего операцию сотни раз в день, разница 300 мс ↔ 2 с — это часы в месяц и измеримая деградация точности; считайте её по KLM (§1.3) вместе с сетевыми задержками.
Классика жанра — Stephen Few, Information Dashboard Design (2006): главная задача — «make the most important data stand out», а дашборд должен считываться «с одного взгляда» (Few, Perceptual Edge). Инструмент выделения — преаттентивные атрибуты (цвет, размер, положение, ориентация), воспринимаемые до осознанного внимания: на них строится иерархия KPI. Фундамент — Edward Tufte, The Visual Display of Quantitative Information (1983): максимизировать data-ink ratio и удалять chartjunk (декор, лишние сетки, 3D, тени), не несущий данных (Tufte, 1983; Data-Ink Ratio). Раскладку диктует паттерн сканирования: важнейшее — в левый верхний угол и вдоль верхней полосы (F-паттерн, Nielsen, 2006, исследование на 232 пользователях).
Выбор типа графика — не вкусовщина. Эксперименты Cleveland & McGill (1984) установили иерархию точности графического восприятия: положение на общей шкале > положение на несовмещённых шкалах > длина/наклон > угол > площадь > насыщенность цвета (Cleveland & McGill, 1984, JASA, 79(387)). Практические следствия: сравнение величин — bar chart, а не pie (углы читаются хуже позиций); динамика — линия; доли — стек или пирог максимум из 3–4 сегментов; кодировать точные значения площадью и цветом — последнее средство.
Алертинг и «усталость от тревог». Дашборды реального времени наследуют проблему индустриальных пультов: при избытке сигналов оператор начинает игнорировать все, включая критические, — эффект alarm fatigue, задокументированный в инженерной психологии (Woods, 1995, Ergonomics, 38(11)). Нормы: явные уровни серьёзности с разными каналами (критично — прерывание; важно — бейдж; информационно — периферия/дайджест), агрегация повторов, обязательная возможность «отложить/подписаться». Теоретическая рамка ненавязчивой сигнализации — calm technology (§7.2).
KPI-виджеты (stat tiles). Ряд виджетов-показателей в шапке экрана — самый частый строительный блок enterprise-дашборда, и у него есть свои нормы:
Каноническая база IA — «polar bear book»: Rosenfeld, Morville & Arango, Information Architecture: For the Web and Beyond (4-е изд., O'Reilly, 2015) — систематизирует четыре системы: организации, маркировки (labeling), навигации и поиска (polar bear book). Паттерны для глубоких enterprise-иерархий:
Две специфически enterprise-надстройки над классической IA. Первая — запись как хаб: в CRM/ERP реальная единица навигации не «страница», а бизнес-объект (сделка, заказ, контрагент); всё связанное — документы, активности, проводки, согласования — должно быть достижимо с карточки объекта за один переход, иначе пользователь строит маршрут через глобальное меню заново для каждого шага (рост general-нагрузки, §4.1). Вторая — сохранённые представления (saved views) как навигационные объекты первого класса: именованная комбинация «фильтры + сортировка + колонки» заменяет глубокую иерархию разделов и разделяется внутри команды (продолжение нормы о сохранении состояния, §4.2). И то и другое дополняет, а не заменяет поиск: навигация и поиск покрывают разные стратегии пользователей и нужны одновременно (Nielsen, «Search and You May Find»; NN/g о синергии поиска и навигации).
Навигационный каркас SaaS: сайдбар, topbar, табы, меню. Де-факто стандартная рама enterprise-приложения — левый сайдбар (глобальная навигация) + верхний бар (глобальные объекты) + локальная навигация внутри раздела:
Permission-aware интерфейс — форма прогрессивного раскрытия «по роли»: каждая персона видит релевантный ей срез (ср. Fiori «role-based»). Ключевой выбор — hide vs disable:
| Подход | Плюс | Минус | Когда |
|---|---|---|---|
| Hide (скрыть) | Чище интерфейс, меньше шума | Убивает discoverability | Функция роли принципиально недоступна |
| Disable (задизейблить + тултип «нет прав») | Сохраняет знание о функции, подсказывает путь к доступу | Визуальный шум | Доступ можно запросить/повысить |
Архитектурная норма (критично): frontend-RBAC — это UX, но НЕ безопасность. Правила прав обязаны проверяться на бэкенде: API отклоняет запрещённое действие, даже если кнопка случайно показана. Предпочтительны декларативные permission-модели, а не россыпь ролевых проверок по компонентам (Permit.io; Oso, RBAC best practices). С 2025 года у RBAC появляется новый субъект: AI-агент, действующий от имени пользователя, обязан наследовать его права, а не иметь собственные расширенные — иначе возникает класс уязвимостей «excessive agency» (OWASP Top 10 for LLM Applications); подробнее §7.4.
Центральный тезис Samuel Hulick (UserOnboard): «People don't want to use your software. They want to be awesome at what it helps them do» (Intercom × Hulick). Отсюда — ключевые понятия: aha moment (осознание ценности), time-to-value / time-to-wow (скорость доставки распознанной ценности), activation event (действие, после которого пользователь «понял»). Механический тур из 20 тултипов ценности не создаёт.
Паттерны (отраслевая практика Pendo / Appcues / Userpilot — вендорские материалы, см. оговорку в §9): empty states с призывом к первому действию, точечные tooltips, product tours, checklists задач, progressive/contextual onboarding (раскрытие just-in-time по мере использования). Эмпирическая поддержка скепсиса к турам есть и у NN/g: пользователи систематически пропускают фронтальные туры и не переносят из них знания в контекст задачи — работает обучение в момент нужды (NN/g, Mobile-App Onboarding). Enterprise-вывод: мерить онбординг не «прошёл ли тур», а time-to-first-value по каждой ключевой роли.
Корневая причина того, почему enterprise-софт десятилетиями был хуже потребительского, — не некомпетентность дизайнеров, а разорванная петля обратной связи: покупку выбирает закупочный комитет (ИТ, безопасность, финансы, руководители функций), который в системе ежедневно не работает; страдания оператора не влияют на продление контракта напрямую. Якоб Нильсен фиксировал это ещё на материале мейнфреймов: когда пользователь и покупатель — разные люди, у индустрии нет стимула вкладываться в качество интерфейса; массовый PC временно замкнул петлю, enterprise — снова разомкнул (Nielsen, Enterprise Usability, NN/g; Nielsen, 100 Years of UX).
Следствия для проектирования. Во-первых, закупка оптимизирует чек-лист функций, а не ежедневный путь: отсюда «demo-driven design» — функции, которые хорошо показываются на пресейле и плохо живут в рутине. Противоядие: проектировать и продавать частотные пути ролей, а не список возможностей; в пилоты включать реальных операторов (3–5 на роль, §6.5), а телеметрию использования — в решения о продлении. Во-вторых, петля частично замкнулась сама: consumerization и product-led growth (триалы, bottom-up-распространение, отзывы пользователей в закупочном цикле) сделали UX коммерческим фактором — это одна из причин, почему вендоры §4.16 публикуют дизайн-принципы как маркетинговый актив.
Отдельный пласт — внедрение и миграция с legacy, классическая enterprise-боль. Теоретическая рамка принятия технологии — TAM: намерение использовать систему предсказывается воспринимаемой полезностью и воспринимаемой лёгкостью использования (Davis, 1989, MIS Quarterly, 13(3)) — обе переменные проектируемы. Практики: поэтапный rollout по ролям (не «большой взрыв»), параллельный период со старой системой для критичных операций, контекстная помощь в интерфейсе вместо PDF-инструкций (§4.8), сеть «чемпионов» внутри команд, и метрика внедрения по ролям (HEART-Adoption, §6.5) как критерий готовности к отключению legacy. Перенос привычных конвенций из старой системы там, где они не вредят, снижает переучивание (закон Джейкоба, §2.5).
CRM/ERP поставляются не как готовые приложения, а как платформы: кастомные поля и сущности, редакторы бизнес-процессов и валидаций, роли и права, интеграции, отчёты. Значит, у продукта есть второй контур UX — администратор/конфигуратор — и его качество мультипликативно: одна ошибка админа тиражируется на всех пользователей тенанта. Это прямое следствие закона Теслера (§4.1): конфигурируемость не убирает сложность, а переносит её с вендора и пользователя на администратора — и интерфейс конфигурирования обязан проектироваться с той же строгостью, что и рабочие экраны.
Различайте два механизма (NN/g, Customization vs. Personalization): кастомизация — явная настройка пользователем/админом; персонализация — адаптация системой (её пределы и риски — §7.5). Отраслевая норма зрелых SaaS: «configure, don't customize» — настройка декларативными средствами переживает обновления, кастомный код — источник urgent-долга при апгрейдах.
Минимальный набор паттернов безопасной конфигурируемости:
Enterprise-вывод: админ — полноценная персона с собственными сценариями, метриками (время на типовое изменение, доля изменений с откатом) и онбордингом. Generative UI (§7.5) — эволюция именно этого контура: сборка воркспейсов из компонентов — это конфигурирование, ускоренное агентом.
Offline и полевые сценарии. Склад, выездной сервис, продажи «в полях» — связь нестабильна, а работа продолжается. Архитектурная рамка — local-first: локальная копия данных как первичная, синхронизация — фоновая (Kleppmann et al., «Local-First Software», Onward!/ACM 2019). UX-обязательства: явный индикатор состояния синхронизации (сохранено локально / синхронизировано / конфликт), очередь отложенных операций с возможностью просмотра, и видимое разрешение конфликтов — конфликтующие правки показываются пользователю, а не «тихо» перезаписываются (это продолжение optimistic UI, §4.4, на длинных интервалах).
Локализация (i18n). Мультинациональный тенант — норма enterprise. Инженерный минимум: текст при переводе расширяется (для немецкого/финского закладывать +30–40% ширины — W3C, Text Size in Translation); зеркалирование RTL-макетов; форматы дат, чисел, валют и правила сортировки — из CLDR, а не самописные (Unicode CLDR); строки не конкатенируются (падежи и порядок слов ломают шаблоны «из кусочков»); псевдолокализация — в CI. Плотные таблицы (§4.2) страдают первыми: колонка, рассчитанная под «Status», не переживает «Bearbeitungsstatus».
Экспорт и отчётность. «Выгрузить в Excel» — не признак провала интерфейса, а легитимная часть workflow: данные принадлежат клиенту, и таблица — лингва франка финансовых и операционных ролей. Норма: экспорт — WYSIWYG-контракт (выгружается ровно то, что отфильтровано и видно: те же колонки, порядок, форматы); плановые отчёты по расписанию; для аналитиков — стабильный путь в BI/API, чтобы экспорт не превращался в теневую интеграцию.
Коллаборация. Над записью работают несколько человек: без явной модели совместности возникают «перезаписанные» правки. Фундамент — исследования CSCW о workspace awareness: участники должны видеть, кто ещё работает с объектом и что меняется (Dourish & Bellotti, CSCW 1992). Практический спектр: presence-индикаторы и «мягкие» блокировки секций для транзакционных форм; полноценное конкурентное редактирование (OT/CRDT) — для документных сущностей; комментарии и @упоминания как рабочие объекты с уведомлениями через уровни §4.5.
Транзакционная отмена: undo ≠ delete. В учётных системах проведённый документ не «отменяется» удалением — он сторнируется: создаётся связанная компенсирующая операция, и след обеих остаётся в журнале (системная рамка — компенсирующие транзакции в длинных процессах: Garcia-Molina & Salem, «Sagas», SIGMOD 1987). UX-паттерны: preview-before-post (черновик → проверка → проведение) как главная линия защиты; «отмена» проведённого — явная операция «сторнировать» с причиной и ссылкой на исходный документ; окно мгновенного undo допустимо только до фактического проведения. Поэтому рекомендация «обязательный undo» (§3.3, §8.6) в транзакционных доменах читается как «обязательная обратимость»: undo для состояния интерфейса, компенсация — для бизнес-операций. Для агентов (§7.4) это условие автономии: агент может исполнять только те действия, для которых определена компенсирующая операция.
Оверлеи — слои поверх основного контента; их объединяет одно правило: слой заимствует внимание в долг, и долг надо возвращать — фокус, контекст и незавершённый ввод пользователя сохраняются при закрытии. Механика фокуса и клавиатуры для всех оверлеев — §5.7 (focus trap, Esc, возврат фокуса).
Три формы коллекций, дополняющие таблицы (§4.2) и карточки:
Настройки — служебный интерфейс с редкими визитами, поэтому их экономика противоположна рабочим экранам: здесь важна находимость, а не скорость. Правила:
Пять ведущих вендоров публикуют свои дизайн-принципы — и они конвергентны вокруг ясности, согласованности и роль-ориентированности:
| Вендор | Система | Принципы |
|---|---|---|
| SAP | Fiori | Role-based · Adaptive · Simple · Coherent · Delightful |
| Salesforce | Lightning (SLDS) | Clarity › Efficiency › Consistency › Beauty (строго по приоритету) |
| Workday | Canvas | Simple · Fast · Clever |
| ServiceNow | Horizon | Этос без фиксированной триады: интуитивность · ясность · бесшовность · эмпауэрмент (см. прим.) |
| Microsoft | Fluent 2 / D365 | Simplicity · Clarity · Consistency · Accessibility |
Два наблюдения. Во-первых, SAP делает «role-based» первым принципом и прямо определяет «Coherent» через нагрузку: «unified design patterns reduce user cognitive load» — это связывает §4.1, §4.7 и §4.16 (SAP Fiori Design Principles). Во-вторых, Salesforce задаёт приоритет: при конфликте Clarity важнее Beauty (Lightning Design System; Villamor, «How We Designed the New Salesforce at Scale»). Первоисточники остальных: Workday, Design Principles («Simple, Fast, and Clever shape the way Workday works»), ServiceNow Horizon, Principles, Microsoft Fluent 2. Примечание: ServiceNow публикует принципы как развёрнутый «этос», а не фиксированную триаду; встречающаяся в обзорах формула «Fluid·Symphonic·Resonant» официальной страницей не подтверждается (см. §9).
Всё, что описано в §4, — таблицы, формы, KPI-тайлы, панели, тосты — на уровне реализации существует как виджеты: автономные, переиспользуемые интерфейсные модули с собственным контрактом (данные на входе, состояния, поведение, события на выходе). Термин пришёл из ранних GUI-тулкитов (X Window System, Athena widgets, 1988), а архитектурная родословная — MVC в Smalltalk-80: уже там интерфейсный элемент стал единицей сборки, разделяющей модель, представление и контроллер, а не рисунком на экране (Krasner & Pope, 1988, JOOP, 1(3)). Для enterprise виджет — ещё и единица поставки и governance: он версионируется в дизайн-системе (§3.1), тестируется в изоляции (§6.6) и потребляется тремя клиентами — человеком, рендерером и, с недавних пор, AI-агентом (§3.1, §7.5). Отсюда правило масштаба: экран проектируется один раз, виджет — один раз на всю систему; дефект виджета — системный, а не локальный (тот же мультипликатор, что у админ-ошибок, §4.10).
Рабочее определение: виджет — минимальный интерфейсный модуль, который можно поставить на экран, не зная его внутренностей, и который сам отвечает за свои данные, состояния и доступность. Типология по решаемой задаче:
| Класс | Виджеты | Ядро требований | Смежный раздел |
|---|---|---|---|
| Коллекции данных | таблица/грид, список, дерево, канбан, карточная сетка | плотность, выравнивание, виртуализация, состояние сортировок | §4.2, §4.14 |
| Агрегаты и визуализация | KPI-тайл, чарт, спарклайн, прогресс | иерархия Cleveland–McGill, data-ink, единый surface | §4.5 |
| Ввод | форма, поле, комбобокс, date-picker, фильтр-панель | валидация on-blur, прощающий ввод, автосохранение | §4.3 |
| Навигация | меню, дерево, табы, breadcrumbs, command palette | глобальная/локальная навигация, saved views | §4.6 |
| Оверлеи | модал, side panel (drawer), popover, тултип | правила слоёв; side panel для правки при таблице; focus trap | §4.12, §5.7 |
| Сигналы | тост, баннер, бейдж, alert | уровни серьёзности, бюджет внимания | §4.5, §4.12, §7.2 |
| Время и планирование | календарь, таймлайн, gantt | форматы из CLDR, локали | §4.11 |
Типология не произвольна: для большинства классов существует нормативный интерфейсный паттерн W3C APG (grid, dialog, tabs, tree, combobox, menu…) с ролями ARIA и клавиатурным поведением (§3.4) — виджет без APG-паттерна — это виджет без спецификации. Виджет переживает и сам WIMP: пост-WIMP интерфейсы (речь, жест, агенты) всё равно рендерят проверяемые визуальные представления (van Dam, 1997, CACM, 40(2)) — что прямо связывает эту главу с §7.
Антипаттерн: «одноразовый виджет» — скопированный грид с локальными правками под модуль. Каждая копия форкает баги, поведение и доступность; через год в продукте четыре разных таблицы с разной сортировкой (нарушение §2.4 «консистентность» на уровне кода).
Формальная рамка — конечный автомат: все состояния и переходы перечислены явно, как в statecharts (Harel, 1987, Science of Computer Programming, 8(3)). Проектирование «только happy path» — главный источник продакшен-дефектов виджетов: состояния, которые не нарисовали, всё равно наступят — их нарисует случайность.
| Состояние | Правило | Антипаттерн |
|---|---|---|
| Loading | Skeleton в габаритах будущего контента (§4.4); размеры зарезервированы — нулевой сдвиг раскладки при загрузке (CLS, web.dev) | Один спиннер на весь дашборд; «прыжок» вёрстки после прихода данных |
| Empty | Различать три пустоты: «данных ещё нет» (CTA первого действия, §4.8), «фильтр ничего не нашёл» (показать активные фильтры + сброс), «нет прав» (матрица §4.7) | Универсальное «Нет данных» без причины и выхода |
| Error | Ошибка локализуется в виджете — дашборд жив; текст по нормам §4.3, действие retry; технические детали — по запросу | Падение всего экрана из-за одного источника; молчаливая пустота вместо ошибки |
| Partial | Явная маркировка: «данные неполные — источник X недоступен» + время последней удачной загрузки | Показывать частичный агрегат как полный — ложь в KPI, по которому примут решение |
| Overflow | Правила усечения заданы заранее: числа не обрезаются никогда; текст — ellipsis с тултипом; списки — «+N ещё» | Перенос строк, ломающий высоту ряда и выравнивание сетки (§4.2) |
| Disabled / нет доступа | По матрице hide vs disable (§4.7) с объяснением | «Мёртвый» виджет без причины |
| Hover / focus / active | Видимый фокус (§3.4); hover-действия продублированы для клавиатуры и тача (§4.2) | Действия, существующие только по hover |
Особый enterprise-акцент — partial: агрегат, собранный из четырёх источников при одном недоступном, обязан заявить о неполноте. Молчаливо неполный KPI хуже ошибки: ошибку видно, а неполноту — нет.
Скрипт поведения дашборда давно сформулирован — мантра визуального поиска информации: «overview first, zoom and filter, then details-on-demand» (Shneiderman, 1996, Proc. IEEE VL'96). В терминах виджетов:
Конкретизация §3.4 на уровне модуля:
Интеллектуальная родословная: язык паттернов Александера — «проблема + контекст + решение» (Alexander et al., A Pattern Language, OUP, 1977) → библиотеки UI-паттернов (Tidwell, Brewer & Valencia, Designing Interfaces, 3rd ed., O'Reilly, 2020) → компонентные дизайн-системы (§3.1). Документация виджета в DS — это паттерн Александера, доведённый до исполняемости.
Definition of Done виджета (дополнение к чек-листу §8.10):
Enterprise-вывод главы: виджет — это контракт из пяти частей: данные (+свежесть), состояния (§5.4), клавиатура и ARIA (§5.7), токены (§5.8), события (§5.6, §5.9). Всё, что описано в §4, собирается из таких контрактов; всё, что описано в §7, будет ими управлять. Команда, у которой виджеты — контракты, получает агентную готовность почти бесплатно; команда с «одноразовыми» виджетами будет переписывать интерфейс дважды.
Ни один из фреймворков не «правильнее» другого — они решают разные задачи и часто комбинируются.
| Фреймворк | Автор / год | Ядро | Когда применять |
|---|---|---|---|
| Double Diamond | UK Design Council, 2004 | Discover → Define → Develop → Deliver (дивергенция/конвергенция ×2) | Структурировать проект целиком; разделить «проблему» и «решение» |
| Design Thinking | IDEO / Stanford d.school; корень — Simon, 1969 | Empathize → Define → Ideate → Prototype → Test | Плохо определённые проблемы, нужна эмпатия к пользователю |
| Lean UX | Gothelf & Seiden, 2013 | Build → Measure → Learn; гипотезы | Стартап-режим, проверка рискованных допущений |
| Design Sprint | Knapp (GV), 2016 | 5 дней: карта → эскизы → выбор → прототип → тест | Быстро провалидировать крупную ставку |
| Dual-Track Agile | Patton / Cagan | Параллельно Discovery + Delivery | Продуктовая команда в непрерывном цикле |
Интеллектуальный корень всей дисциплины — Herbert Simon, The Sciences of the Artificial (1969): «Everyone designs who devises courses of action aimed at changing existing situations into preferred ones». Термин и коммерциализацию design thinking закрепили IDEO и Tim Brown (Change by Design, 2009). Нормативная рамка процесса — ISO 9241-210:2019 (человеко-центрированное проектирование): явное понимание пользователей, задач и среды; вовлечение пользователей на всех этапах; итеративность; мультидисциплинарная команда (ISO 9241-210:2019) — удобна как язык для аудита процесса и корпоративных регламентов. Enterprise-поправка к любому из фреймворков: discovery здесь включает не только пользователей, но и закупщика, администратора и владельца процесса (§4.9–4.10), а delivery — управление изменением при живом legacy (§4.9). Источники: Design Council, Double Diamond; Stanford d.school process guide; Gothelf & Seiden, Lean UX; Knapp, Sprint / GV; Cagan / SVPG, Dual-Track Agile.
Спектр: paper / lo-fi wireframe (схема без стиля) → mid-fi (серые макеты, реальная IA, кликабельность) → high-fidelity (цвет, шрифты, реальные компоненты, микровзаимодействия). Программный текст в защиту дешёвого раннего прототипа — Rettig, «Prototyping for Tiny Fingers», CACM 37(4), 1994: качество есть функция числа итераций, а бумага удешевляет цикл.
Контринтуитивный, но устойчивый результат эмпирики. Факторный эксперимент 2×2 (N=28, think-aloud) показал: число и тяжесть выявленных usability-проблем не зависят ни от fidelity, ни от медиума; значимо различалось только распределение типов найденных проблем между lo-fi и hi-fi условиями (χ²=30.70, p<0.01 — статистика относится именно к типам находок, а не к их числу) (Walker, Takayama & Landay, 2002, HFES Proc. 46). Тот же вывод ранее — у Virzi, Sokolov & Karis, 1996, CHI'96 (обзор: MeasuringU). Практический вывод: для валидации потоков и IA тестируйте на lo-fi как можно раньше; hi-fi нужен для проверки визуальной иерархии, микровзаимодействий и desirability, а не для поиска базовых проблем.
| Инструмент | Тип / платформа | Совместная работа | Fidelity | Токены | Handoff / Dev | AI | Статус 2026 |
|---|---|---|---|---|---|---|---|
| Figma | Web + desktop/mobile | Realtime, cloud | Lo→hi, Make (AI-web-прототипы), Motion | Variables + экспорт DTCG | Dev Mode (CSS/JSON/React) | Make, First Draft, агент | Лидер, активно развивается |
| Sketch | Только macOS (веб = просмотр) | Realtime лишь в Mac-app | Lo→hi | Color variables, экспорт | Веб-инспекция | Точечно | Активен, Mac-only |
| Adobe XD | macOS/Windows | Ограниченно | Lo→hi | Ограниченно | Есть, не развивается | Нет | Maintenance mode / фактически прекращён |
| Framer | Web | Realtime | Hi-fi, code-driven, публикация сайтов | Есть | Публикация в прод | AI-генерация | Активен |
| ProtoPie | Desktop + mobile players | Cloud | Макс. hi-fi, сенсоры, IoT, кросс-девайс | Ограниченно | Handoff-спеки | AI по промпту | Активен |
| Axure RP | macOS/Windows | Axure Cloud | Hi-fi, условная логика, data-driven | Переменные | Функц. документация, ISO 27001 | AI-функции | Активен, enterprise |
| UXPin (Merge) | Web | Cloud | Code-backed (React/Storybook/npm) | Реальные код-токены | Прототип = продакшен-компоненты | AI Component Creator | Активен |
| Penpot | Web, open source / self-host | Realtime | Lo→hi, CSS Grid | DTCG-нативно, MCP | Dev-friendly код | Через MCP | Активен, open source |
| Play | iPhone/Mac (SwiftUI) | — | Hi-fi нативный iOS | Apple-компоненты | Xcode | — | Прекращён: Apple acqui-hire, июнь 2026 |
Две значимые перемены, которые ломают старые методички: Adobe XD фактически заморожен (maintenance mode после срыва сделки Adobe→Figma) и Play куплен Apple (сделка публична 29.06.2026, приложение выведено из App Store). Источники: Figma release notes; официальная позиция Adobe по XD («maintenance mode… not investing in ongoing development»); Sketch web app; UXPin Merge; Penpot; Play → Apple, MacRumors, 29.06.2026. (Строки Framer/ProtoPie/Axure частично опираются на вторичные обзоры — при внедрении стоит сверить с офиц. сайтами.)
Токены — это «контракт данных» между дизайном и разработкой. Практическая связка единого источника правды:
С версии 4 Style Dictionary нативно поддерживает DTCG-формат (styledictionary.com/dtcg); Penpot поддерживает DTCG «из коробки». Результат — одно изменение значения токена автоматически прокатывается на все платформы.
| Метод | Что проверяет | Ключевой факт | Источник |
|---|---|---|---|
| Usability testing (think-aloud) | Где и почему пользователь спотыкается | «The #1 usability tool»; корни — Ericsson & Simon (1980), в UX — Lewis (1982) | NN/g |
| «5 пользователей» | Сколько тестировать за цикл | N·(1−(1−L)ⁿ), L≈31% → ~85% проблем на 5; лучше 3 цикла по 5, чем 1×15 | Nielsen, 2000; Nielsen & Landauer, 1993 |
| RITE | Быстрая итерация | «Find a problem, fix a problem» — правка после каждого участника | Medlock et al., 2002 |
| A/B-тест | Какой вариант выигрывает по метрике | Различие в одном элементе; отвечает «что», не «почему» | NN/g |
| Tree testing | Findability и IA «вслепую» | Проверка иерархии без визуала; термин — Donna Spencer | IxDF |
| First-click | Правильность первого шага | Верный первый клик резко повышает успех задачи | Optimal Workshop |
| Card sorting | Ментальная модель структуры | Open/closed/hybrid; NN/g рекомендует ~15 участников | NN/g |
| SUS | Субъективная оценка | 10 пунктов, 0–100; ~68 = средний; Brooke, 1996 | MeasuringU, SUS |
Важная оговорка про «правило пяти». Модель Нильсена–Ландауэра справедлива для качественного, формативного тестирования одной однородной аудитории. Для количественных/суммативных исследований NN/g сам рекомендует ~20 пользователей, а «правило» критиковалось (Faulkner, 2003, «Beyond the five-user assumption»). Для разнородных ролей enterprise-продукта берите 3–5 из каждой значимой группы.
Метрики на масштабе. Качественные тесты отвечают «почему», но живому SaaS нужны непрерывные продуктовые метрики UX. Рабочий стандарт — HEART (Google): Happiness, Engagement, Adoption, Retention, Task success, разворачиваемые через связку «цели → сигналы → метрики» (Rodden, Hutchinson & Fu, CHI 2010). Для enterprise ключевые проекции: task success и время выполнения по ролям (связка с KLM, §1.3), time-to-first-value по ролям (§4.8), доля операций, завершённых без обращения в поддержку.
Тренд 2024–2026: хендофф перестаёт быть разовым «перебрасыванием через стену» и становится непрерывной синхронизацией. Figma Dev Mode отдаёт CSS/iOS/Android/React-код, значения переменных и статусы «ready for dev». Storybook делает сам компонент спецификацией («the component is the spec») — живая изолированная библиотека UI, единая для дизайна и кода (Storybook; Supernova, Storybook for Designers). Итог — дизайн-система как контракт: токены (DTCG) фиксируют значения, компоненты в Figma и Storybook отражают одни состояния, Code Connect / Merge связывают макет с реальным кодом. Это минимизирует расхождение «дизайн ↔ прод».
Раздел построен на трёх фильтрах. Первый — происхождение идей: почти все «интерфейсы будущего» опираются на исследовательские программы возрастом 30–60 лет (ubiquitous computing — 1991, mixed-initiative — 1999, мультимодальность — 1980, HMD — 1968); новизна 2020-х — не в теории, а в экономике реализации (LLM, дешёвые сенсоры, вычисления на устройстве). Второй — enterprise-проекция: каждое направление оценивается по влиянию на плотные данные, ввод, дашборды и ролевые сценарии CRM/ERP/SaaS. Третий — горизонт зрелости: «уже применимо» (есть внедрения и данные), «ближний горизонт» (2–5 лет, есть работающие прототипы), «спекулятивное» (10+ лет, есть только исследования). Маркетинговые заявления вендоров используются лишь как свидетельства направления инвестиций, не как доказательства эффекта (см. §9).
Программный тезис сформулировал Golden Krishna: «The best interface is no interface» — критика «экранного мышления» (screen-based thinking), при котором любая задача решается добавлением ещё одного экрана; вместо этого — встраивание в естественные процессы, работа компьютера на человека и адаптация к индивидууму (Krishna, The Best Interface Is No Interface, New Riders, 2015). Научный корень старше: Марк Вайзер открывает манифест убиквитарных вычислений фразой «The most profound technologies are those that disappear» (Weiser, 1991, Scientific American, 265(3)). Смежная ветвь пост-WIMP — tangible interfaces, где данными манипулируют через физические объекты (Ishii & Ullmer, CHI 1997).
Критика, которую нельзя опускать: невидимый интерфейс — это интерфейс без сигнификаторов. Норман и Нильсен показали на жестовых UI, что отказ от видимых указателей и обратной связи возвращает старые провалы: необнаружимость функций, невозможность понять состояние системы, отсутствие undo (Norman & Nielsen, 2010, interactions, 17(5)). Оба «залива» Нормана (§2.3) для невидимых систем не исчезают — они расширяются: пользователь не знает ни как попросить, ни что система сделала.
Enterprise-проекция. Zero UI в CRM/ERP — это прежде всего инверсия ввода: не человек заполняет форму, а система захватывает данные из среды (почта, звонки, календарь, документы, IoT-датчики склада) и просит лишь подтверждения. Автологирование активностей в CRM из почты и звонков — уже норма рынка; авто-сверка накладных по фото — ближний горизонт. Правило проектирования: невидимым делают захват данных, но не действие над ними — операции с деньгами, обязательствами и правами остаются видимыми и подтверждаемыми (§7.4). GUI при этом не исчезает, а смещается к роли слоя надзора.
Наследие Вайзера содержит не только «исчезновение», но и позитивную программу: calm technology — технология, которая «engages both the center and the periphery of our attention, and in fact moves back and forth between the two» (Weiser & Brown, «The Coming Age of Calm Technology», 1996; в кн. Beyond Calculation, Springer, 1997). Информация должна жить на периферии внимания и «вступать в центр» только когда это оправдано; ранние воплощения — ambient-дисплеи MIT Media Lab (ambientROOM, Ishii и коллеги). Современную операционализацию дала Amber Case: минимально достаточное внимание, информирование без захвата фокуса, использование периферийных каналов, деградация в полезность при отказе (Case, Calm Technology, O'Reilly, 2015).
Enterprise-проекция. Это направление применимо уже сегодня, потому что решает измеримую боль: перегрузку уведомлениями и alarm fatigue (§4.5). Практика: бюджет внимания как метрика (число прерываний на пользователя в день — предмет проектирования и ревью); трёхуровневая сигнализация (прерывание / бейдж / периферийный статус или дайджест); ambient-индикация состояния процессов (цвет строки, фон виджета) вместо тостов; правило «то, что не требует решения сейчас, не имеет права прерывать». Ближний горизонт — ambient-статусы кросс-системных процессов (заказ→склад→доставка) в рабочих средах команд.
Термин ввёл Aaron Shapiro: anticipatory design — устранение самого шага выбора, «flow, где решения приняты за пользователя» (Shapiro, Fast Company, 2015). Научная основа решает главную проблему проактивности — когда системе уместно вмешиваться: принципы mixed-initiative Эрика Хорвица — действие при неопределённости оценивается через ожидаемую полезность, стоимость внимания пользователя и стоимость ошибки; вмешательство обязано учитывать контекст и допускать эффективную коррекцию (Horvitz, CHI 1999). Инфраструктурная рамка — «proactive computing» (Tennenhouse, 2000, CACM, 43(5)).
Риски задокументированы инженерной психологией: неверные предсказания разрушают доверие нелинейно, а избыточное доверие порождает misuse (некритичное принятие) и disuse (полный отказ после пары ошибок) (Parasuraman & Riley, 1997, Human Factors, 39(2)).
Enterprise-проекция. Лестница проактивности, по которой стоит подниматься только с измеренной точностью предсказаний:
Правило: доля принятых предложений — продуктовая метрика проактивности. Эмпирическое основание — телеметрия кодовых копилотов: доля принятия оказалась лучшим предиктором воспринимаемой продуктивности среди всех измеренных сигналов (Ziegler et al., 2024, CACM, 67(3)). Универсального порога не существует: для дешёвых в проверке предложений (автодополнение) приемлема доля ~20–30%, для транзакционных enterprise-действий стоимость ошибочного принятия много выше стоимости отклонения — порог задаётся локально из соотношения «цена проверки vs цена исправления». Если доля принятия падает и не растёт — возвращайтесь на ступень ниже по лестнице автономии.
Разговорный интерфейс — старейшая мечта HCI, и его главный документированный провал — разрыв ожиданий: пользователи приписывают системе человеческий интеллект, сталкиваются с ограничениями, откатываются к примитивным командам (Luger & Sellen, «Like Having a Really Bad PA», CHI 2016). LLM сократили этот разрыв, но не устранили две структурные проблемы CUI: необнаружимость возможностей (что можно попросить?) и дорогая коррекция ошибок (переформулировать дольше, чем кликнуть). Отсюда практический вывод §3.3: побеждает гибрид «intent + GUI».
Агентность добавляет новое измерение — делегирование с автономией. Здесь не нужно изобретать теорию: она есть. Уровни автоматизации Шеридана (от «человек делает всё» до «система делает всё и не сообщает») и модель типов и стадий автоматизации (сбор информации → анализ → выбор решения → исполнение; автоматизировать стадии можно независимо и на разную глубину) — каноническая рамка проектирования агентов (Parasuraman, Sheridan & Wickens, 2000, IEEE Trans. SMC-A, 30(3)). Расчёт доверия — не «максимизировать», а калибровать: доверие должно соответствовать фактической надёжности системы, иначе misuse/disuse (Lee & See, 2004, Human Factors, 46(1)).
Классику дополняет рецензируемая эмпирика человеко-AI-взаимодействия 2020-х, и она отрезвляет. Разрыв «ожидание ↔ опыт» воспроизвёлся на LLM-инструментах: пользователи кодогенераторов ценят их, но систематически спотыкаются о проверку и починку сгенерированного (Vaithilingam, Zhang & Glassman, CHI EA 2022). Взаимодействие с копилотами распадается на два режима — ускорение (знаю, что делаю, AI печатает быстрее) и исследование (не знаю решения, AI предлагает варианты) — с разными требованиями к UI: в первом критична ненавязчивость, во втором — сравнение альтернатив (Barke, James & Polikarpova, OOPSLA 2023). Объяснения повышают принятие рекомендаций независимо от их правильности — т.е. наивная «объяснимость» усиливает overreliance, а не калибрует его (Bansal et al., CHI 2021); лечат это cognitive forcing functions — паттерны, заставляющие обдумать до принятия (отложенный показ ответа AI, запрос собственного решения сначала), снижающие слепое доверие ценой небольшого трения (Buçinca, Malaya & Gajos, CSCW 2021). Для enterprise-агентов это прямые проектные требования: не «показать объяснение», а спроектировать акт проверки.
«Интерфейс намерений» не отменяет классическое ядро (§2.4) — он его переизобретает. Соответствие прямое:
| Классический принцип (§2.4) | Агентный эквивалент |
|---|---|
| Видимость статуса системы | Видимость плана и текущих действий агента: что делает, почему, что дальше |
| Предотвращение / отмена ошибок | Preview и diff до применения; откат для UI, компенсация/сторно для проведённых операций (§4.11) |
| Узнавание вместо припоминания | Обнаружимость возможностей: примеры запросов, каталог умений |
| Контроль пользователя | Явные уровни автономии, milestone-подтверждения, стоп-кнопка |
| Консистентность | Предсказуемое поведение между сессиями; воспроизводимость по журналу |
| Минимализм | Дозированные вмешательства — бюджет внимания (§7.2) |
| Эффективность для экспертов | Сохраняемые «макросы намерений», параметризуемые запросы |
Enterprise-проекция. Агент в CRM/ERP — это новый тип пользователя: он обязан наследовать RBAC того, от чьего имени действует (§4.7), иметь собственный журнал аудита, границы полномочий и SLA на точность; расширенные права агента — прямой путь к уязвимости «excessive agency» (OWASP LLM Top 10). Уже применимо: Q&A над данными с обязательным цитированием записей-источников, NL-фильтры («сделки без активности 30 дней»), генерация отчётов и черновиков. Ближний горизонт: многошаговые процессы (собрать документы → сверить → подготовить проводки) с подтверждением на вехах — направление, в которое публично инвестируют SAP (Joule), Microsoft (Copilot / D365) и Salesforce (Agentforce). Спекулятивное: автономная оркестрация целых процессов, где GUI становится «диспетчерской» — но именно этот сценарий сильнее всего упирается в иронии автоматизации (§7.9). Правовой контур уже очерчен: EU AI Act, Art. 14 требует проектировать high-risk системы под эффективный человеческий надзор с явной защитой от automation bias, а Art. 50 — раскрывать факт взаимодействия с AI (§3.4); для HR-сценариев CRM/HCM это перестаёт быть выбором дизайнера к декабрю 2027.
Идея интерфейса, генерируемого под пользователя и контекст, имеет строгую академическую родословную: система SUPPLE трактовала рендеринг UI как задачу дискретной оптимизации — минимизировать ожидаемую стоимость действий пользователя при заданных ограничениях устройства и моторики (Gajos & Weld, IUI 2004). В контролируемом эксперименте с участниками с двигательными нарушениями автоматически сгенерированные под способности пользователя интерфейсы значимо сокращали время выполнения задач и число ошибок относительно стандартных UI, приближая результаты к результатам участников без нарушений (Gajos, Wobbrock & Weld, CHI 2008; итоговая система — Gajos, Weld & Wobbrock, 2010, Artificial Intelligence, 174(12–13)).
Та же исследовательская линия дала и главное предостережение: адаптивность конфликтует с пространственной памятью. В контролируемом сравнении статичные меню обыграли адаптивные и по скорости, и по предпочтениям пользователей — перестановка элементов разрушает выученные моторные паттерны (Findlater & McGrenere, CHI 2004). Для enterprise с его экспертами-операторами (§1.1) это предостережение весит больше, чем для консьюмерских продуктов.
Практический синтез 2026 года — generative UI в границах дизайн-системы: агент собирает представление из легитимных компонентов и токенов (DTCG как машиночитаемый контракт, §3.1–3.2), а не рисует произвольные пиксели (CopilotKit, GenUI 2026). Правила: генерация — для новых представлений (отчёт под вопрос, рабочая панель под задачу), а не для перестановки постоянных рабочих экранов; сгенерированное можно закрепить (pin) — тогда оно становится стабильным и версионируемым; ядро навигации и частотные операции не адаптируются.
Enterprise-проекция. Уже применимо: генерация дашборда/отчёта по NL-запросу из готовых виджетов. Ближний горизонт: ролевые воркспейсы, собираемые под конкретный кейс (онбординг клиента, инцидент, аудит) и переиспользуемые как шаблоны. Спекулятивное: полностью персональные интерфейсы — упирается в поддержку, обучение, комплаенс и коллективную работу (у коллег должен быть «тот же экран»).
Родословная: концепт «Ultimate Display» и первый головной дисплей Сазерленда (Sutherland, 1968, AFIPS); таксономия континуума реальность–виртуальность (AR → AV → VR) Милгрэма и Кишино (Milgram & Kishino, 1994, IEICE Trans., E77-D(12)). Массовые попытки платформизации — Meta Quest for Business и Apple Vision Pro / visionOS (2024) с «пространственными» HIG (Apple, Designing for visionOS).
Научное состояние трезвее маркетинга. Immersive analytics — рецензируемая программа исследований о том, когда погружение помогает анализу данных (Marriott et al., Immersive Analytics, Springer LNCS 11190, 2018): выигрыши документированы для внутренне пространственных данных (геология, логистические потоки, цифровые двойники производств) и коллаборативного сенс-мейкинга; для абстрактных бизнес-таблиц преимущества неустойчивы. Попытка перенести офисную работу в VR целиком дала отрицательный результат: неделя работы в VR показала статистически значимый рост нагрузки, фрустрации и жалоб на зрение при снижении субъективной продуктивности (Biener et al., «Quantifying the Effects of Working in VR for One Week», 2022, IEEE TVCG).
Enterprise-проекция. Уже применимо — там, где работник физически находится в данных: vision picking на складе (пилоты DHL с 2015), AR remote assist в полевом сервисе (Microsoft Dynamics 365 Remote Assist), тренажёры опасных операций, цифровые двойники цехов. Ближний горизонт: иммерсивная аналитика пространственных данных (сеть филиалов, склад, логистика) как дополнение к плоским дашбордам. Спекулятивное: XR как основное рабочее место офисного аналитика — текущие данные говорят против.
Каноническое начало — «Put-That-There» Ричарда Болта: голос + указательный жест, где дейксис («вот это — туда») разрешается взглядом на экран (Bolt, SIGGRAPH 1980). Дисциплинирующий корректив — «Десять мифов мультимодальности» Шэрон Овиатт: мультимодальный ≠ «голос поверх всего»; пользователи выбирают модальность под задачу; речь плохо подходит для точных пространственных операций; мультимодальные команды не всегда быстрее (Oviatt, 1999, CACM, 42(11)). Для взгляда как ввода фундаментальна проблема Midas touch: взгляд — орган восприятия, а не команды; наивное «смотрю = нажимаю» превращает каждый взгляд в клик (Jacob, CHI 1990); рабочее решение — взгляд наводит, подтверждает другая модальность (щипок в visionOS — прямой наследник этого паттерна).
Enterprise-проекция. Выбор модальности диктуется средой: шум, приватность (open space!), занятость рук и глаз. Уже применимо десятилетия: голосовой отбор на складе (voice picking), диктовка полевых заметок в мобильный CRM, транскрипция звонков в активности. Ближний горизонт: дейктическая мультимодальность поверх дашбордов — указать на аномалию и спросить «почему здесь спад?» (указание снимает главную слабость чистого языка — ссылку на объект). Спекулятивное: взгляд/жест как повседневные офисные модальности.
Нейроинтерфейсы — строгая клиническая дисциплина с 1970-х: канонический обзор фиксирует архитектуру BCI и её главное назначение — коммуникацию и управление для людей с тяжёлыми двигательными нарушениями (Wolpaw et al., 2002, Clinical Neurophysiology, 113(6)). Инвазивные имплантаты (первые человеческие испытания Neuralink, 2024) остаются ассистивной медициной, а не UX-технологией.
Для enterprise релевантнее пассивные BCI — не «управление мыслью», а измерение когнитивного состояния (нагрузка, утомление) для адаптации системы (Zander & Kothe, 2011, J. Neural Engineering, 8(2)); программа адаптивной автоматизации по состоянию оператора экспериментально развивается в авиадиспетчеризации и на критических постах. Даже этот сценарий упирается в этику: нейроданные — предельно чувствительная категория, вокруг которой формируется правовое поле «нейроправ» (Чили первой закрепила их конституционно в 2021). Честный вердикт: для CRM/ERP-практики горизонт BCI — 10+ лет; единственное осмысленное применение до того — лабораторный инструмент UX-исследований (объективная оценка когнитивной нагрузки прототипов, в дополнение к NASA-TLX).
| Направление | Уже применимо (2026) | Ближний горизонт (~2–5 лет) | Спекулятивное (10+ лет) |
|---|---|---|---|
| Post-GUI / Zero UI | Автозахват данных (почта/звонки → CRM), фоновая автоматизация рутины | «Безэкранные» сценарии узких ролей (склад, выезд) | Полное исчезновение GUI (маловероятно: надзор останется) |
| Calm / ambient | Пересборка алертинга: уровни, периферийные каналы, бюджет внимания | Ambient-статусы кросс-системных процессов | Рабочая среда как интерфейс |
| Anticipatory | Умные дефолты; next-best-action с подтверждением | Автономные низкорисковые действия с журналом | Самонастраивающиеся процессы под аудитом |
| Conversational / agentic | Copilot-Q&A с цитированием; NL-фильтры и отчёты | Многошаговые агенты: вехи, RBAC-наследование, аудит | Оркестрация процессов агентами; GUI как «диспетчерская» |
| Generative UI | Генерация отчётов/дашбордов из компонентов DS | Ролевые воркспейсы под кейс, pin + версионирование | Полностью персональные интерфейсы |
| Spatial / XR | Склад и поле: vision picking, remote assist, тренажёры, двойники | Иммерсивная аналитика пространственных данных | XR как основное офисное рабочее место (данные против) |
| Multimodal | Голос в hands-busy контекстах; диктовка; транскрипция | «Указать + спросить» поверх дашбордов | Взгляд/жест как офисная норма |
| BCI | — (вне практики; лабораторная оценка нагрузки) | Пассивные BCI в исследованиях UX | Нейроввод; жёсткие этико-правовые ограничения |
Три структурных вывода.
Первый: GUI не умирает — меняется его функция. Как GUI не убил командную строку, а вытеснил её в нишу (§1.5), так агентные и невидимые интерфейсы смещают GUI от «места выполнения работы» к «месту постановки задач, надзора и верификации»: планы, diff-предпросмотры, журналы, границы полномочий. Инвестиции в таблицы, формы и дашборды (§4) не обесцениваются — именно в них человек будет проверять работу машин.
Второй: инициатива перераспределяется, и это главный проектировочный сдвиг. Ось «кто инициирует» (пользователь → смешанная инициатива → агент) становится такой же базовой характеристикой интерфейса, как плотность или платформа. Инструменты для работы с этой осью дала не футурология, а классика: расчёт уместности вмешательства (Horvitz), стадии и уровни автоматизации (Parasuraman–Sheridan–Wickens), калибровка доверия (Lee & See).
Третий: «компетенции будущего» — это инженерная психология автоматизации, известная с 1980-х. Иронии автоматизации Лизанны Бейнбридж: автоматизация забирает лёгкую рутину и оставляет человеку самые редкие и трудные вмешательства — как раз тогда, когда его навык атрофировался от неиспользования (Bainbridge, 1983, Automatica, 19(6)). Out-of-the-loop проблема: оператор, выключенный из цикла, теряет ситуационную осведомлённость и не может вовремя перехватить управление (Endsley, 1995, Human Factors, 37(1)). Для агентных CRM/ERP это переводится в конкретные требования: объяснимость действий агента по запросу; «ручной режим» как полноценный, а не деградировавший путь; тренировка редких сценариев; проектирование передачи управления (handoff) человек↔агент как первоклассного сценария, а не исключения.
Организационное следствие: дизайн-система получает агента как потребителя (машиночитаемые токены и контракты, §3.1), метрики UX расширяются агентными (доля принятых предложений, точность, время до обнаружения ошибки агента человеком), а карта ролей продукта пополняется ролью «супервизор агентов».
Рекомендации сгруппированы по областям и отсортированы по соотношению «эффект / усилие». Каждая опирается на тезисы выше. Приоритизация по зрелости: организациям в начале пути — сначала №1–2, 4–5, 8–9 и 18 (инфраструктура, таблицы, формы, отклик); блок №22–26 (агенты) имеет смысл только при живой дизайн-системе, телеметрии и бэкенд-RBAC — иначе он строится на песке.
Figma Variables → Tokens Studio → DTCG → Style Dictionary → платформы. Это единственный масштабируемый способ поддерживать темы, бренды и мультиплатформенность (§3.2, §6.4).Прогоните любой экран по строкам ядра принципов (§2.4) и порогам качества — каждая непокрытая строка есть дефект:
Демонстрация чек-листа §8.10 на типовом экране B2B CRM. Исходное состояние: таблица ~2 000 сделок, 14 колонок, редактирование в модальном окне; 200 менеджеров, у каждого ~50 операций правки в день. Все числа «до» — из аудита условного, но типичного продукта; логика переносима.
| № | Пункт чек-листа | Диагноз «до» | Правка | Основание |
|---|---|---|---|---|
| 1 | Статус системы | Сохранение — молча; смена фильтра гасит всю таблицу спиннером | Optimistic-обновление строки + тост с undo; skeleton только при первой загрузке | §4.4 |
| 2 | Консистентность | Три стиля кнопок, два формата дат на одном экране | Компоненты и форматы из токенов; формат даты — из локали (CLDR) | §3.2, §4.11 |
| 3 | Ошибки | Удаление срабатывает сразу; валидация — только по submit | Подтверждение для пакетных операций; undo-окно для одиночных; валидация on-blur | §4.2, §4.3 |
| 4 | Узнавание vs припоминание | Фильтры сбрасываются при возврате на экран | Состояние в аккаунте + именованные saved views | §4.2, §4.6 |
| 5 | Минимализм | Зебра + рамки ячеек + 6 иконок действий в каждой строке | Тонкие разделители; действия по hover; иконки → 2 частотные + меню | §4.2 |
| 6 | Контроль | Модалка правки перекрывает таблицу-референс | Non-modal side panel, таблица остаётся видимой | §4.2 |
| 7 | Ускорители | Все операции — только мышью | Command palette, hotkeys сохранения, «сохранить и следующая», APG-обход грида | §4.2, §4.6 |
| 8 | Доступность | Интерактивные цели 18 px, фокус не виден | Цели ≥24×24, видимый фокус, контраст AA — через токены | §3.4 |
| 9 | Отзывчивость | Открытие карточки p95 ≈ 2.8 с | Кэш + предзагрузка по hover; SLA p95 ≤ 1 с | §4.4 |
| 10 | Ввод | Черновик гибнет по таймауту SSO-сессии | Автосохранение черновика, восстановление после релогина | §4.3 |
Экономика (KLM-оценка, §1.3). Цикл «найти сделку → открыть → исправить поле → сохранить» до правок ≈ 14 с (поиск фильтром с перезагрузкой, модалка, сохранение с ожиданием), после ≈ 9 с (сохранённый вид, side panel, optimistic-сохранение). Экономия 5 с × 50 операций × 200 человек = 50 000 с ≈ 14 человеко-часов в день (~290 часов в месяц) — не считая снижения ошибок ввода от on-blur-валидации. Оценку такого рода стоит пересчитать на собственных частотах операций до начала работ: она же — язык разговора с закупщиком (§4.9).
Мини-кейс: агентная функция по §7.4. Задача — «сверить 120 входящих счетов с заказами». Проектирование по надзорной модели: (1) агент показывает план и объём до запуска; (2) выполняет партиями с вехами; (3) расхождения выводит таблицей diff «счёт ↔ заказ» со ссылками на записи-источники и индикатором уверенности; (4) проводки применяются только после подтверждения, каждая имеет сторно-пару (§4.11); (5) метрики: точность сопоставлений, доля принятых предложений (§7.3), время проверки одного расхождения. Повышение автономии (автопринятие совпадений с уверенностью выше порога) — только после стабильной измеренной точности, с журналом и стоп-кнопкой (§7.4, §8.9).
Научная честность требует зафиксировать места, где популярные формулировки неточны или где доказательная база слабее. Это укрепляет, а не подрывает выводы.
Первичные и авторитетные вторичные источники, сгруппированные по разделам. Все URL проверялись в ходе исследования (июль 2026).
Конец меморандума. Диаграммы Mermaid и таблицы редактируемы вместе с текстом. При переносе в корпоративную вики или PDF рекомендуется сохранить инлайн-ссылки на первоисточники — они и есть доказательная база каждого тезиса.