Проектирование интерфейсов сложных enterprise-продуктов (CRM / ERP / SaaS)

Проектирование интерфейсов сложных enterprise-продуктов (CRM / ERP / SaaS)

Исследовательский меморандум: фундаментальные принципы, практики 2026 года и теории интерфейса будущего

---

TL;DR (60 секунд)

• •Фундамент HCI не устаревает — устаревают его трактовки. Применяйте законы Фиттса/Хика/Миллера в исходном смысле, а не по фольклору (§1).
• •Инфраструктура решает: трёхуровневые DTCG-токены + зрелая дизайн-система + доступность по умолчанию (§3).
• •Enterprise-ядро — дисциплина с числами: таблицы, формы, отклик ≤1 с, роли, конфигурируемость; корень исторически плохого UX — разрыв «покупатель ≠ пользователь» (§4).
• •Процесс: тестировать на lo-fi рано, 3 цикла × 5 пользователей на роль, на масштабе — HEART (§6).
• •Агенты не убивают GUI: он становится пультом надзора; автономию повышайте только по измеренной точности, права агента = права пользователя (§7).

---

Executive summary

Проектирование enterprise-интерфейсов — это не «искусство вкуса», а инженерная дисциплина с воспроизводимой доказательной базой. Ниже — сжатая выжимка выводов, каждый из которых раскрыт и подкреплён источниками в теле документа.

1. •

   Фундамент устойчив, потому что описывает человека, а не технологию. Законы Фиттса (1954), Хика–Хаймана (1952–53) и ограничения рабочей памяти (Miller 1956; уточнение Cowan 2001) описывают биологию восприятия и моторики — она не устаревает вместе с фреймворками. Их надо применять корректно: половина «народных» трактовок (например, «≤7 пунктов в меню») — методологические ошибки (см. §1.1).

2. •

   Своды принципов сходятся к одному ядру. 10 эвристик Нильсена, 8 правил Шнайдермана, принципы Нормана и Рамса независимо приходят к одному: консистентность, предотвращение ошибок, обратная связь, минимализм, узнавание вместо припоминания. Это ядро — операциональный чек-лист, а не философия; в нормативной форме оно закреплено в ISO 9241-110 (§2). Красота в этой системе — не украшение, а беглость обработки: измеримое ремесло поверх того же ядра (§3.8).

3. •

   Дизайн-системы стали инфраструктурой, а дизайн-токены — её стандартом. В октябре 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).

4. •

   AI сдвигает парадигму взаимодействия. Генеративный AI — «третья UX-парадигма» за 60 лет: переход от «команд» к «спецификации намерения и результата» (Nielsen, NN/g, 2023). Но выигрывают гибриды «intent + GUI», а не чистый чат; ключевые паттерны — прозрачность возможностей, human-in-the-loop, обработка галлюцинаций (Amershi et al., CHI 2019) (§3.3).

5. •

   Правовое давление на интерфейс стало двойным: доступность + 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).

6. •

   Специфика enterprise — это управление сложностью, а не её устранение. Закон Теслера: неустранимый минимум сложности кто-то несёт — либо система, либо пользователь. Задача — снять с пользователя extraneous когнитивную нагрузку (Sweller, 1988), оставив ему только сложность предметной области (§4.1). Экономический корень исторически плохого enterprise-UX — разрыв «покупатель ≠ пользователь»: решение о покупке принимает комитет, который в системе не работает, и обратная связь от боли пользователя до денег вендора рвётся (§4.9).

7. •

   Плотные данные требуют дисциплины, а не «богатого UI». Для таблиц есть измеримые нормы: высоты строк 32–48 px, числа выравниваются вправо табличными цифрами, freeze шапки/первой колонки, пагинация предпочтительнее бесконечного скролла для рабочих данных (NN/g; Carbon) (§4.2).

8. •

   Формы и отклик системы — недооценённые рычаги enterprise-UX. Формы — главная поверхность ввода ERP/CRM: верхние лейблы ускоряют заполнение (Penzo, 2006), валидация — по потере фокуса, ввод никогда не теряется. Пороги отклика 0.1 / 1 / 10 с (Miller 1968; Nielsen 1993) и порог Доэрти ~400 мс (1982) делают скорость продуктовой метрикой, а не «внутренним делом бэкенда» (§4.3–4.4).

9. •

   Ведущие enterprise-вендоры конвергентны. SAP Fiori, Salesforce SLDS, Workday Canvas, ServiceNow Horizon, Microsoft Fluent ставят в ядро ясность, согласованность и роль-ориентированность. SAP делает «role-based» первым принципом (§4.16).

10. •

    Виджет — единица проектирования, поставки и надзора. Enterprise-интерфейс собирается не из экранов, а из виджетов с фиксированным контрактом: обязательные состояния (загрузка/пусто/ошибка/частичные данные — Harel, 1987), один tab-stop с внутренней клавиатурной навигацией (W3C APG), связи drill-down и cross-filtering (Shneiderman, 1996; Becker & Cleveland, 1987), поставка через дизайн-систему с версионированием. Ошибка в виджете — системная, а не локальная (§5).

11. •

    Детализация прототипа почти не влияет на результаты тестов. Эмпирика 1989–2002 гг. (Virzi; Walker, Takayama & Landay 2002): lo-fi и hi-fi выявляют сопоставимое число и тяжесть проблем — различается лишь их тип. Вывод: тестировать раньше и дешевле (§6.2).

12. •

    Тестируйте итеративно, а не «монструозно». Модель Нильсена–Ландауэра N·(1−(1−L)ⁿ) при L≈31% даёт ~85% проблем на 5 пользователях. Три цикла по 5 пользователей ценнее одного теста на 15 — с оговоркой о критике «правила пяти» для количественных исследований. Для продуктовых метрик масштаба — фреймворк HEART (Rodden et al., 2010) (§6.5).

13. •

    Будущее — перераспределение инициативы, а не «смерть 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 подходы, не разрушая первые три опоры.

---

1. Исторический фундамент: почему это до сих пор работает

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

1.1. Психофизические законы

Закон Фиттса. Время наведения на цель растёт логарифмически с отношением дистанции к размеру цели. Формула индекса сложности: 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-вывод: ограничивайте не число видимых опций, а число единиц, которые пользователь обязан держать в голове между шагами (параметры фильтра, контекст мастера, незакоммиченные правки).

1.2. Гештальт-принципы восприятия

Немецкая школа гештальта (Wertheimer, Koffka, Köhler, 1910–20-е) установила: восприятие организует элементы в целостные структуры на уровне мозга, а не сенсора (Wertheimer, 1923, Psychologische Forschung). Ключевые законы группировки и их применение:

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

1.3. Инженерная психология HCI

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 и оптимизировать до внедрения — экономия миллисекунд на операции кратно окупается на объёме.

1.4. Наследие промышленного дизайна: Bauhaus, швейцарский стиль, Rams

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.

1.5. Рождение GUI: Engelbart → Xerox PARC → Apple

Технологический фундамент прямого манипулирования сложился в три шага:

Дуглас Энгельбарт на 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 сам когда-то был «интерфейсом будущего» — и вытеснил командную строку не полностью, а перераспределил её в нишу экспертов. Тот же сценарий сосуществования следует ожидать и от следующих парадигм.

---

2. Правила проектирования: своды принципов и их общее ядро

Четыре канонических свода созданы независимо, в разные десятилетия, разными людьми — и сходятся к одному операциональному ядру. Это сильный аргумент: пересечение — не мода, а инвариант.

2.1. Десять эвристик юзабилити Якоба Нильсена (1994)

Сформулированы в Nielsen, 1994, Proc. CHI'94 (развитие Nielsen & Molich, 1990); актуальные определения — на NN/g. С 1994 года список не менялся — в 2020 уточнены лишь определения.

1. •Visibility of system status — видимость состояния системы.
2. •Match between system and real world — соответствие реальному миру.
3. •User control and freedom — свобода и контроль (undo/redo, «аварийный выход»).
4. •Consistency and standards — консистентность и стандарты.
5. •Error prevention — предотвращение ошибок.
6. •Recognition rather than recall — узнавание вместо припоминания.
7. •Flexibility and efficiency of use — гибкость и ускорители для экспертов.
8. •Aesthetic and minimalist design — эстетичный минимализм.
9. •Help users recognize, diagnose, recover from errors — понятные ошибки.
10. •Help and documentation — справка и документация.

2.2. Восемь золотых правил Шнайдермана (1987)

Из 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».)

2.3. Дон Норман: аффордансы, сигнификаторы, заливы

В 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.

2.4. Сводное ядро: чек-лист, а не философия

Практический смысл таблицы: это готовый heuristic-evaluation чек-лист. Любой экран enterprise-продукта прогоняется по семи строкам — каждая «дыра» в строке есть измеримый дефект, а не «вкусовщина».

2.5. Нормативное закрепление: ISO и «закон Джейкоба»

То же ядро зафиксировано в международном стандарте ISO 9241-110:2020 «Interaction principles» — семь принципов взаимодействия: пригодность для задач пользователя, самоописательность, соответствие ожиданиям, обучаемость, управляемость, устойчивость к ошибкам использования, вовлечённость (ISO 9241-110:2020). Для enterprise это практично вдвойне: на ISO удобно ссылаться в корпоративных требованиях, тендерах и договорах на разработку — «соответствие ISO 9241-110» проверяемо, в отличие от «удобного интерфейса». Дополняющий эмпирический аргумент в пользу консистентности — закон Джейкоба: пользователи бóльшую часть времени проводят в других продуктах и переносят оттуда ожидания, поэтому «стандарты» из эвристики №4 включают и внешние конвенции, а не только внутренний стайлгайд (Nielsen, 2000).

---

3. Актуальное состояние на 2026 год

3.1. Дизайн-системы как инфраструктура

Дизайн-система в 2026 — не «библиотека кнопок», а инфраструктурный слой: токены + компоненты + гайдлайны + код. Сравнение ведущих систем по верифицированным данным их вендоров:

Ключевой сдвиг 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.

3.2. Дизайн-токены: наступивший стандарт

Главное событие инфраструктуры: 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-вывод: без семантического слоя масштабная система становится неуправляемой при первой же смене темы или бренда.

3.3. AI-native UX

Тезис Якоба Нильсена: генеративный 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-копайлотов и агентов:

• •Прозрачность возможностей и границ — заранее показать, что агент умеет и чего не умеет (снимает завышенные ожидания).
• •Human-in-the-loop — accept/reject-диалоги, milestone-контроль, явные точки подтверждения для необратимых действий.
• •Работа с галлюцинациями — re-stating (переформулировать понятое), индикаторы уверенности, подсветка «тентативных» фрагментов, цитирование источников и обязательная обратимость: undo для состояния UI, компенсирующая операция (сторно) для уже проведённых бизнес-транзакций (§4.11).
• •Streaming ответов — базовый паттерн отзывчивости; ожидание без обратной связи воспринимается как «зависание».
• •Generative UI — агент выбирает/генерирует части интерфейса в рантайме, но при сохранении human agency (CopilotKit, GenUI 2026; теоретическая рамка — §7.5).

Текущая волна в enterprise — встроенные ассистенты, эволюционирующие в агентов: SAP Joule (2023), Microsoft Copilot в Dynamics 365 (2023), Salesforce Agentforce (2024) — переход от «подсказчика у поля ввода» к исполнителю, которому делегируют задачи (SAP Joule; Salesforce Agentforce). Теоретическая рамка агентного взаимодействия, уровни автономии и риски — в §7.4.

3.4. Доступность: из «best practice» в правовую норму

• •WCAG 2.1 (2018) — базовый уровень, зашит в EN 301 549.
• •WCAG 2.2 — рекомендация W3C с 5 октября 2023; добавлены 9 критериев, в т.ч. Target Size (Minimum) 24×24 CSS px (2.5.8), Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Accessible Authentication (3.3.8), Consistent Help (3.2.6); удалён 4.1.1 Parsing (W3C, What's New in 2.2).
• •WCAG 3.0 — остаётся рабочим черновиком, финализация не ранее ~2030. Важно: APCA (перцептивный контраст) был исключён из черновика в 2023 и развивается независимо — распространённое заблуждение, что «APCA = WCAG 3» (Roselli, апрель 2026).
• •European Accessibility Act (EAA) — применяется с 28 июня 2025; экстерриториален (любая компания, продающая в ЕС), штрафы вплоть до изъятия продукта; техстандарт — EN 301 549 (Level Access, EAA; DWT, 2025). В США — ADA и Section 508 (привязан к WCAG 2.0 AA).
• •WAI-ARIA Authoring Practices Guide (APG) — практический стандарт клавиатурных и ARIA-паттернов для сложных виджетов: гридов, деревьев, комбобоксов, тулбаров (W3C APG). Для enterprise это критично: data-таблица без APG-паттерна (навигация стрелками по ячейкам, Enter — редактирование, Esc — отмена) недоступна с клавиатуры и для скринридеров — а значит, не пройдёт EN 301 549.
• •EU AI Act (Regulation 2024/1689) — вторая правовая рамка, бьющая прямо по интерфейсу AI-функций. В силе с 1 августа 2024, применяется поэтапно: запреты (в т.ч. распознавание эмоций на рабочем месте, Art. 5) — со 2 февраля 2025; обязательства прозрачности (Art. 50: информировать, что человек взаимодействует с AI; маркировать синтетический контент) — со 2 августа 2026; обязательства для high-risk систем Annex III — куда попадают HR-сценарии CRM/HCM: найм, распределение задач, оценка сотрудников — перенесены пакетом Digital Omnibus (финально одобрен Советом ЕС 29.06.2026) на 2 декабря 2027 (embedded-системы Annex I — на 02.08.2028) (EUR-Lex 2024/1689; Implementation Timeline; Gibson Dunn о Digital Omnibus, 2026). Ключевое для дизайна — Art. 14 Human Oversight: high-risk системы обязаны проектироваться так, чтобы надзор человека был эффективным, включая явную защиту от automation bias — то есть требования §7.4 (видимость плана, подтверждения, калибровка доверия) становятся не «best practice», а юридической обязанностью.

Enterprise-вывод: доступность в SaaS, продаваемом в ЕС, — теперь вопрос юридического риска, а не «доброй воли». Мин. размер интерактивной цели 24 px, видимость фокуса и APG-паттерны сложных виджетов должны быть зашиты в дизайн-токены и компоненты по умолчанию; для AI-функций дорожная карта комплаенса (Art. 50 — уже, Art. 14/high-risk — к декабрю 2027) закладывается в дизайн сейчас.

3.5. Адаптивный и многоплатформенный дизайн

Термин 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).

3.6. Визуальные основы: типографика, цвет, иконография, отступы

Четыре сквозных слоя, из которых состоит любой экран; все четыре в 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).

3.7. Liquid Glass и новая волна «рецессивного» интерфейса (2025–2026)

Что это. 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):

• •Два слоя, а не декорация всего. Стекло — материал функционального слоя (панели, тулбары, оверлеи), контентный слой остаётся непрозрачным; glass поверх glass и glass на контенте — антипаттерн самой Apple.
• •Адаптивная оптика. Материал сам меняет светлоту/тонировку от подложки; дизайнер задаёт роль поверхности, а не фиксированный цвет — это мышление semantic-токенов (§3.2), доведённое до физики.
• •Ясность первична. Несмотря на прозрачность, HIG требует читаемости: контраст текста проверяется после размытия и на худшем фоне; независимые аудиты сводят это к правилу «≥4.5:1 после blur» (Infinum, аудит доступности).
• •Движение — функциональная подсказка (откуда выехал слой, куда свернулся), с «эластичностью» материала, но подчинённое тем же порогам, что §4.4.
• •Accessibility-режимы — часть материала, а не патч: Reduced Transparency (матовое «frosted» стекло), Increased Contrast (контрастная обводка, почти чёрно-белые слои), Reduced Motion (отключение эластичности) — три обязательных модификатора (§3.4).
• •Бюджет производительности: рефракция и размытие дороги; glass применяется точечно, деградирует управляемо на слабом железе.
• •Геометрия и словарь фиксированы системой: концентрические радиусы, капсулы, SF Symbols — дисциплина, а не свобода.

Тренд и его критика. Отраслевой эффект 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: то, к чему Apple пришла через год критики и слайдер, в рабочих системах ставится дефолтом сразу — максимальная читаемость из коробки (эквивалент Reduced Transparency), украшение — осознанный opt-in пользователя; и любой экран обязан проходить приёмку в режимах Increased Contrast / Reduced Transparency / Reduced Motion, потому что у операторов с 8-часовой сменой эти режимы включены чаще, чем у потребителя (§3.4, §5.8).

3.8. Красота интерфейса в 2026: теория, ремесло, контекст

«Красиво» в 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: пресейл-демо).

Ремесло: из чего красота складывается измеримо. Проверяемые критерии, каждый — аудируем без разговоров о вкусе:

• •Типографика: одна модульная шкала (§3.6), выдержанный вертикальный ритм (интерлиньяжи кратны базовой сетке), максимум два семейства с явными ролями, оптическое выравнивание (висячая пунктуация, оптические поля), табличные цифры в данных (§4.2). Антипаттерн: пять кеглей «на глаз» и жирный как единственный инструмент иерархии.
• •Цвет: дисциплина палитры — нейтральная тональная шкала (10–12 ступеней) + семантические роли + один акцент (§3.6); света/тени согласованы между light/dark; насыщенный цвет расходуется только на смысл (§4.5). Антипаттерн: «весёлые» разноцветные виджеты без семантики.
• •Пространство и сетка: whitespace как главный разделитель (группировка отступами, а не рамками — §1.2), выравнивание всего со всем по 4/8-шкале (§3.6), оптические коррекции (иконка по оптическому, а не геометрическому центру), сбалансированная плотность (§4.2). Антипаттерн: три разных отступа между одинаковыми по смыслу блоками.
• •Иерархия и ясность: одно главное на экран; прищур-тест — при расфокусе видно, что здесь важно; вторичное действительно выглядит вторичным (§4.13).
• •Системность: одна шкала радиусов (концентричность, §3.7), одна система теней/слоёв, токены вместо локальных значений (§3.2) — когерентность и есть то, что глаз читает как «дорого сделано».
• •Движение: стандартные кривые easing, согласованная хореография слоёв (§4.4, §4.12), 150–300 мс; антипаттерн — эффект ради эффекта в частотном цикле.
• •Невидимые детали: выравнивание до пикселя, состояния наведения/фокуса везде (§5.4), пустые состояния с заботой (§4.8), выверенные тексты ошибок (§4.3). Это ремесло, которое пользователь не называет, но чувствует как качество.
• •Согласованность образов: один стиль иконок (§3.6), один стиль иллюстраций, изображения одной тональности.

Эстетика именно 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-ревью: красиво то, что при равной функциональности читается быстрее, а при равной скорости — вызывает доверие и желание работать именно здесь.

---

4. Специфика CRM / ERP / SaaS

Это класс интерфейсов, где эстетика вторична по отношению к пропускной способности: плотные данные, сложные роли, высокая частота повторяющихся операций, обученные пользователи. Здесь ошибки проектирования масштабируются на тысячи человеко-часов — и десятилетиями воспроизводились системно, потому что рынок enterprise-ПО долго не наказывал за плохой UX: решение о покупке принимал не тот, кто работает в системе (§4.9).

4.1. Когнитивная нагрузка: управлять, а не устранять

Теория когнитивной нагрузки: рабочая память ограничена, и обучение/работа страдают, когда ресурс уходит не на суть задачи (Sweller, 1988, Cognitive Science, 12(2)). Каноническая триада нагрузки:

• •Intrinsic — сложность, присущая самой задаче (в ERP объективно высока: много сущностей, статусов, связей).
• •Extraneous — «паразитная» нагрузка от способа подачи (визуальный шум, дубли, непоследовательность). Именно её обязан вычищать дизайнер.
• •Germane — усилия на построение полезных схем (её поддерживают консистентность и обучаемые паттерны).

(Атрибуционная точность: полная триада intrinsic/extraneous/germane закреплена в поздних работах — Sweller, Ayres & Kalyuga, Cognitive Load Theory, Springer, 2011, — а не в статье 1988 года.)

Парная концепция — закон Теслера (закон сохранения сложности): у всякой системы есть неустранимый минимум сложности; вопрос лишь в том, кто её несёт — система или пользователь (Tesler's Law). Рабочий инструмент управления intrinsic-нагрузкой — прогрессивное раскрытие: ядро сценария видно сразу, редкие и продвинутые функции раскрываются по запросу (Nielsen, Progressive Disclosure). Enterprise-вывод: нельзя «упростить» ERP до трёх кнопок — сложность предметной области реальна. Можно и нужно переложить её максимум на систему (умные дефолты, автоподстановка, валидация), оставив пользователю только неустранимое ядро.

4.2. Плотные данные и таблицы (data grids)

Таблица обслуживает 4 задачи пользователя (Laubheimer, NN/g, «Data Tables: Four Major User Tasks»): (1) найти записи по критерию, (2) сравнить данные, (3) просмотреть/отредактировать одну строку, (4) выполнить действие над записями. Из этого следуют измеримые нормы.

Плотность и высота строк (верифицированные значения дизайн-систем):

Источники: Carbon Data table — Style; Pencil & Paper, «Data Table Design UX Patterns».

Правила, дающие максимальный эффект:

• •Первая колонка — человекочитаемый идентификатор, а не авто-ID; порядок колонок отражает важность, связанные — рядом (NN/g).
• •Выравнивание: текст — влево; количественные числа (суммы, проценты, меры) — вправо, по десятичной точке, табличными (моноширинными) цифрами; даты/индексы/телефоны — можно влево. Центрирование не использовать — ломает вертикальное сканирование (Pencil & Paper).
• •Freeze шапки и первой колонки при выходе за экран; hover-highlight и тонкие (≤1px) разделители против «потери строки».
• •Зебра всё чаще проблемна: конфликтует со стейтами (disabled/hover/selected дают до 5 семантических уровней серого) — часто предпочтительнее простые линии-разделители.
• •Редактирование: предпочтителен non-modal side panel (правишь и видишь таблицу как референс — «recognition over recall»), а не модалка, перекрывающая соседние записи. Для правки 1–2 полей уместно inline-редактирование ячейки (Enter/двойной клик — редактирование, Esc — отмена, валидация on-blur по §4.3); для «высокоставочных» данных намеренно добавляют трение.
• •Действия: одиночные (1–2 inline) против пакетных (чекбоксы + панель действий + Select All). Пакетные операции — с подтверждением, где явно названо число объектов («Удалить 47 записей?»), прогрессом для длительных и итоговым отчётом «N выполнено, M с ошибкой» со списком неудавшихся — частичный провал bulk-операции не имеет права выглядеть как полный успех (та же логика, что partial-состояние виджета, §5.4).
• •Клавиатура: полный обход грида по APG-паттерну «grid» — стрелки по ячейкам, Home/End, PageUp/PageDown, Enter — редактирование, Esc — отмена; пакетные операции доступны без мыши (W3C APG, Grid Pattern). Для операторов с сотнями операций в день клавиатурный путь — это производительность, а не только доступность (ср. KLM, §1.3).
• •Состояние (сортировки, фильтры, набор/порядок колонок) сохранять в сессии/аккаунте; кнопка reset to default обязательна.

Рендер больших наборов — стратегический выбор:

Для рабочих данных 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). Правила, делающие сетку карточек сравнимой, а не «витринной»:

• •Фиксированная анатомия слотов. Каждая карточка собирается из одних и тех же зон в одном порядке: идентификатор (аватар/тип + имя), бейджи статуса, контакты, метрики, действия. Слот без данных не схлопывается, а резервируется (фиксированная высота) или заполняется явным «—»: пустота — тоже информация, и она не должна ломать раскладку соседних зон.
• •Зона метрик закреплена по вертикали — например, прижата к нижнему краю карточки при равной высоте карточек в ряду. Опциональные поля (email, теги, вторая строка контактов) не имеют права смещать метрики: сопоставление значений между карточками — это «положение на общей шкале» (Cleveland & McGill, §4.5), а общая шкала требует общей базовой линии. Выровненные по горизонтали блоки метрик образуют ту же «линию чтения», что колонки таблицы (непрерывность, §1.2); карточка, у которой «Доход» уехал на 40 px вниз из-за строки email, из линии выпадает — глаз ищет значение заново в каждой карточке.
• •Равная высота карточек в ряду (grid-выравнивание со stretch); одинаковое число, порядок и стиль бейджей; один формат телефонов, дат и сумм во всех карточках (нормализация — на стороне системы, §4.3).
• •Метрики — в одинаковых «ячейках»: пара блоков (напр., «Доход» / «Проектов») одной ширины и в одном порядке во всех карточках; значения — табличными цифрами, числа сопоставимых величин — в одном масштабе и формате.
• •Действия — в одном месте на всех карточках без исключений (например, меню в правом верхнем углу); hover-действия дублируются в меню — для клавиатуры и тача.

4.3. Формы и ввод данных

Формы — главная поверхность ввода в CRM/ERP: карточка сделки, приёмка, проводка, заявка. Ошибки здесь дороже, чем в таблицах: они портят данные, на которых потом строятся отчёты. Канон дисциплины — Luke Wroblewski, Web Form Design: Filling in the Blanks (2008) (lukew.com); ключевые эмпирические результаты:

• •Расположение лейблов. Айтрекинг Matteo Penzo (2006): верхние лейблы дают минимальное время заполнения (одна саккада «лейбл+поле»); левые выровненные — самые медленные, но уместны для длинных редко заполняемых анкет, где важно сканировать состав полей (Penzo, UXmatters, 2006). Для частотного экспертного ввода допустимы компактные схемы — но единообразно по всему продукту.
• •Одна колонка полей как правило: многоколоночные формы ломают порядок обхода и Z-сканирование; исключение — логически парные короткие поля (город/индекс).
• •Валидация — по потере фокуса (on blur), а не на каждый символ и не только по submit. Юзабилити-тесты Baymard: преждевременные ошибки («email неверен», пока пользователь ещё печатает) фрустрируют и снижают доверие; поздние — заставляют переделывать всю форму (Baymard, Inline Form Validation). Принцип: «reward early, punish late» — подтверждать успех можно сразу, ругать — только после завершения ввода.
• •Сообщения об ошибках: рядом с полем, конкретные («ИНН должен содержать 10 цифр» вместо «Неверное значение»), вежливые, без кода ошибки в лицо, с сохранением введённого (NN/g, Error-Message Guidelines).
• •Прощающий ввод: принимать телефоны/суммы/даты в любом разумном формате и нормализовать на стороне системы (это перенос сложности по Теслеру, §4.1); маски — только там, где формат действительно один.
• •Умные дефолты и автоподстановка из контекста (роль, история, связанная запись) — главный ускоритель частотных форм; каждое предзаполненное поле — минус единица нагрузки на рабочую память (§1.1).
• •Черновики и автосохранение для длинных форм: потеря введённого — одна из самых дорогих ошибок enterprise-UX; введённое не должно исчезать ни по таймауту сессии, ни по случайной навигации.
• •Клавиатура: порядок Tab строго равен визуальному порядку; сохранение — с клавиатуры (Ctrl/Cmd+S или Enter в последнем поле); для массового ввода — «сохранить и создать следующую».
• •Мастер (wizard) vs длинная форма: пошаговый мастер — для редких сложных задач новичка; единая форма с секциями — для частотного экспертного ввода (дробление экспертного флоу на шаги — та же ошибка, что «дробление ради Хика», §1.1).

Enterprise-вывод: лучшая форма — та, которую не пришлось показывать: автозахват данных из писем, звонков и документов с подтверждением человеком постепенно замещает ручной ввод (см. Zero UI, §7.1). Пока форма существует — её экономика измерима: время заполнения по KLM и доля ошибок на поле.

4.4. Отзывчивость и скорость: пороги восприятия

Скорость — это функция UX, а не «внутреннее дело бэкенда». Канонические пороги удерживаются в психологии с 1968 года (R. B. Miller, 1968, AFIPS; подтверждены в Card, Robertson & Mackinlay, 1991; популяризованы Nielsen, 1993):

Дополнение из индустриальной эмпирики — порог Доэрти: при отклике системы < ~400 мс продуктивность оператора растёт нелинейно — сокращается не только время ожидания, но и число ошибок и «потерь контекста» (Doherty & Thadani, IBM, 1982). Практические паттерны:

• •Skeleton-экраны вместо спиннеров для загрузки страниц/таблиц — воспринимаемая скорость выше (Wroblewski, 2013).
• •Optimistic UI для высокочастотных действий с надёжным успехом (отметить задачу, изменить статус): интерфейс отражает результат сразу, откатывается при ошибке — обязателен undo (Mishunov, Smashing Magazine, 2016).
• •Latency budget как продуктовая метрика: p95 времени до интерактивности ключевых операций (открыть карточку, применить фильтр, сохранить строку) фиксируется как SLA и проверяется в дизайн-ревью наравне с макетами.

Микровзаимодействия. Единица обратной связи — микровзаимодействие: атомарный цикл «триггер → правила → фидбек → циклы/режимы» (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) вместе с сетевыми задержками.

4.5. Дашборды и визуализация

Классика жанра — 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-дашборда, и у него есть свои нормы:

• •Единая анатомия: иконка + подпись + значение (+ дельта/спарклайн при наличии динамики); одно число на виджет. Разнобой анатомии внутри ряда читается как разная семантика.
• •Один surface-токен на весь ряд. Поверхность виджета обязана визуально отделяться от фона страницы — через шкалу elevation/surface в токенах (§3.2), а не через случайную заливку. Виджет, слившийся с фоном на фоне «подсвеченных» соседей, — двойной дефект: разрыв сходства (similarity, §1.2) создаёт ложную иерархию («этот показатель второстепенен?»), а отсутствие видимой границы контейнера нарушает и ориентир доступности — для значимых границ и графики действует non-text contrast ≥3:1 (WCAG 2.2, SC 1.4.11).
• •Выделение — только семантическое. Цвет кодирует состояние (рост/падение, порог, статус), а не «каждому виджету свой цвет для красоты»: декоративная разноцветность — это chartjunk (Tufte) и расход преаттентивного ресурса, которым должен управлять дизайнер, а не палитра по кругу (Few). Если все четыре показателя равноправны — у всех одинаковый нейтральный surface и одинаковый вес значений; акцент получает максимум один, и по причине, которую можно назвать словами.
• •Сопоставимость чисел: один формат (разряды, валюта, сокращения тысяч), один кегль значений, единицы измерения — в подписи, а не вперемешку с числом.

4.6. Сложная навигация и информационная архитектура

Каноническая база IA — «polar bear book»: Rosenfeld, Morville & Arango, Information Architecture: For the Web and Beyond (4-е изд., O'Reilly, 2015) — систематизирует четыре системы: организации, маркировки (labeling), навигации и поиска (polar bear book). Паттерны для глубоких enterprise-иерархий:

• •Разделение глобальной (постоянный доступ к разделам) и локальной (внутри раздела) навигации.
• •Хлебные крошки (breadcrumbs) для ориентации в глубине.
• •Поиск как параллельный навигации путь (в больших системах критичен). Два уровня: глобальный (по всем сущностям, вызов с любого экрана — поле в topbar и/или клавиша «/»; результаты сгруппированы по типам сущностей, с недавними и частыми) и контекстный (внутри текущего раздела/таблицы — по видимому набору, мгновенный). Правило: пользователь всегда видит, где ищет — область поиска названа явно, переключение областей — в один клик.
• •Command palette (Cmd/Ctrl+K) — «do things, not just find things»: keyboard-first доступ к командам для power users, показывает частые/недавние; эталоны — VS Code, Figma, Notion, Superhuman (UX Patterns). Прямо снимает нагрузку припоминания расположения функций.

Две специфически enterprise-надстройки над классической IA. Первая — запись как хаб: в CRM/ERP реальная единица навигации не «страница», а бизнес-объект (сделка, заказ, контрагент); всё связанное — документы, активности, проводки, согласования — должно быть достижимо с карточки объекта за один переход, иначе пользователь строит маршрут через глобальное меню заново для каждого шага (рост general-нагрузки, §4.1). Вторая — сохранённые представления (saved views) как навигационные объекты первого класса: именованная комбинация «фильтры + сортировка + колонки» заменяет глубокую иерархию разделов и разделяется внутри команды (продолжение нормы о сохранении состояния, §4.2). И то и другое дополняет, а не заменяет поиск: навигация и поиск покрывают разные стратегии пользователей и нужны одновременно (Nielsen, «Search and You May Find»; NN/g о синергии поиска и навигации).

Навигационный каркас SaaS: сайдбар, topbar, табы, меню. Де-факто стандартная рама enterprise-приложения — левый сайдбар (глобальная навигация) + верхний бар (глобальные объекты) + локальная навигация внутри раздела:

• •Сайдбар. Глубина — максимум два уровня; более глубокие иерархии выносятся в контент (дерево, §4.14) или поиск. Каждый пункт — иконка + подпись (§3.6): «только иконки» допустимы лишь в свёрнутом состоянии. Сворачиваемость в icon-rail — норма для работы с плотными таблицами (ширина экрана — ресурс данных): состояние свёрнутости сохраняется в профиле (§4.2), в свёрнутом виде каждый пункт получает тултип, активный раздел маркирован и в свёрнутом состоянии. Порядок пунктов стабилен и одинаков для всех пользователей роли — сайдбар работает на пространственную память (§7.5, Findlater), поэтому «умные» самоперестраивающиеся меню в глобальной навигации запрещены.
• •Topbar. Место кросс-разделных объектов: глобальный поиск, «создать» (глобальное быстрое создание сущностей), уведомления (уровни §4.5), переключатель организации/окружения (для мультитенантных ролей — с явной индикацией, где ты: правки в проде под видом песочницы — классика дорогих инцидентов), профиль и настройки (§4.15).
• •Табы. Для параллельных видов одного объекта (карточка клиента: обзор / сделки / документы / история) — APG-паттерн tablist со стрелочной навигацией (§3.4). Табы не используются для последовательных шагов — для этого степпер мастера (§4.3) с видимым прогрессом и возвратом к пройденным шагам. Состояние таба — в URL (deep link, §4.2).
• •Меню. Выпадающие (dropdown) — для действий и настроек по кнопке-триггеру; контекстные (правый клик) — ускоритель для экспертов, но каждое действие из контекстного меню обязано существовать и в видимом UI (контекстное меню необнаружимо, это дубль, а не единственный путь); мега-меню — для широких плоских каталогов разделов, раскрываются по клику, а не по hover (NN/g, Mega Menus Work Well); «гамбургер» — мобильный компромисс: на десктопе прятать основную навигацию за гамбургер — антипаттерн, скрытая навигация измеримо снижает обнаружимость и использование функций (NN/g, Hamburger Menus and Hidden Navigation). Во всех меню: группировка разделителями по близости (§1.2), деструктивные пункты — в конце и визуально отделены (§4.13).

4.7. Ролевые модели (RBAC) в UX

Permission-aware интерфейс — форма прогрессивного раскрытия «по роли»: каждая персона видит релевантный ей срез (ср. Fiori «role-based»). Ключевой выбор — hide vs 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.

4.8. Онбординг

Центральный тезис 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 по каждой ключевой роли.

4.9. Покупатель ≠ пользователь: экономика плохого enterprise-UX и внедрение

Корневая причина того, почему 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).

4.10. Конфигурируемость и админ-UX

CRM/ERP поставляются не как готовые приложения, а как платформы: кастомные поля и сущности, редакторы бизнес-процессов и валидаций, роли и права, интеграции, отчёты. Значит, у продукта есть второй контур UX — администратор/конфигуратор — и его качество мультипликативно: одна ошибка админа тиражируется на всех пользователей тенанта. Это прямое следствие закона Теслера (§4.1): конфигурируемость не убирает сложность, а переносит её с вендора и пользователя на администратора — и интерфейс конфигурирования обязан проектироваться с той же строгостью, что и рабочие экраны.

Различайте два механизма (NN/g, Customization vs. Personalization): кастомизация — явная настройка пользователем/админом; персонализация — адаптация системой (её пределы и риски — §7.5). Отраслевая норма зрелых SaaS: «configure, don't customize» — настройка декларативными средствами переживает обновления, кастомный код — источник urgent-долга при апгрейдах.

Минимальный набор паттернов безопасной конфигурируемости:

• •Песочница и предпросмотр: изменения конфигурации проверяются на копии, а не на проде;
• •Версионирование и откат конфигураций (конфиг — такой же артефакт, как код);
• •Анализ влияния перед изменением: «это поле используется в 12 отчётах, 3 интеграциях и 2 процессах»;
• •Ограждения (guardrails): валидация конфигураций, лимиты сложности, безопасные дефолты; шаблоны под отрасль/роль вместо «чистого листа»;
• •Аудит изменений конфигурации — кто, что, когда (та же логика, что журнал агента, §7.4).

Enterprise-вывод: админ — полноценная персона с собственными сценариями, метриками (время на типовое изменение, доля изменений с откатом) и онбордингом. Generative UI (§7.5) — эволюция именно этого контура: сборка воркспейсов из компонентов — это конфигурирование, ускоренное агентом.

4.11. Родовые темы: offline, локализация, экспорт, коллаборация, транзакционная отмена

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) это условие автономии: агент может исполнять только те действия, для которых определена компенсирующая операция.

4.12. Оверлеи и слои: модалки, drawers, popovers, сигналы

Оверлеи — слои поверх основного контента; их объединяет одно правило: слой заимствует внимание в долг, и долг надо возвращать — фокус, контекст и незавершённый ввод пользователя сохраняются при закрытии. Механика фокуса и клавиатуры для всех оверлеев — §5.7 (focus trap, Esc, возврат фокуса).

• •Модальное окно — принудительное прерывание: легитимно только когда продолжение невозможно без решения пользователя (подтверждение деструктива §4.13, обязательный выбор, юридическое согласие). Всё остальное — немодально (NN/g, Modal & Nonmodal Dialogs). Правила: один вопрос на модалку; заголовок — глагол действия, а не «Внимание»; кнопки именуют исход («Удалить 47 записей» / «Отмена»), а не «Да/Нет»; закрытие по Esc и по клику мимо — без потери введённого (черновик, §4.3). Вложенные модалки запрещены: потребность во второй модалке — симптом, что сценарий должен жить на странице или в drawer. Антипаттерн CRM: редактирование сущности в модалке поверх таблицы — правильный паттерн см. §4.2 (side panel).
• •Drawer (выезжающая панель). Боковой — стандарт enterprise для просмотра/правки записи с сохранением контекста списка (§4.2) и для каскада «запись → связанная запись» (последовательные drawers с хлебной крошкой вместо вложенных модалок); ширина — токеном (S/M/L), resize сохраняется в профиле. Нижний drawer (bottom sheet) — мобильный паттерн (§3.5), на десктопе уместен для терминальных касс/планшетных сценариев.
• •Popover и tooltip. Tooltip — только необязательное пояснение (подпись свёрнутой иконки, расшифровка, полное значение усечённого текста §5.4): критичная информация в тултипе — антипаттерн, он недоступен на таче и необнаружим. Показ с задержкой ~300–500 мс, по фокусу — тоже (§3.4). Popover — лёгкий интерактивный слой (фильтр колонки, выбор даты, mini-профиль по hover на имени — фирменный паттерн CRM): закрывается Esc и кликом мимо, вложенность — один уровень.
• •Сигнальные слои. Иерархия по серьёзности и её каналы заданы в §4.5 (прерывание / бейдж / периферия); анатомия: тост/снэкбар — эфемерное подтверждение результата действия (3–7 с, с undo для обратимых операций — §8.11; никогда не единственный носитель критической ошибки — она живёт у места действия, §4.3); баннер — персистентное состояние системы/раздела (деградация, окончание триала, режим песочницы) с явным закрытием или условием исчезновения; бейдж — счётчик/маркер на объекте. Все эфемерные сигналы дублируются в журнале уведомлений (topbar, §4.6): «увидел краем глаза и потерял» — не приемлемо для рабочей системы (ср. §7.2).

4.13. Действия: кнопки, выбор, деструктивные операции

• •Иерархия кнопок. Три уровня: primary (главное действие экрана/секции — одна на видимую область), secondary (альтернативы), tertiary/ghost (низкочастотные, ссылки-действия). «Две primary рядом» — самый частый дефект форм: иерархия исчезает, выбор замедляется (Хик, §1.1). Канон зафиксирован в DS-гайдах (Carbon, Button usage). Порядок в диалогах и формах — по платформенной конвенции и единый во всём продукте (§2.5); подпись — глагол результата («Сохранить», «Провести»), не «ОК».
• •Состояния кнопки — подмножество контракта §5.4: default / hover / focus / active / loading (кнопка показывает прогресс и блокирует повторный сабмит — двойное проведение платежа лечится именно здесь) / disabled (с объяснением причины — тултип или подпись: «молчаливый disabled» заставляет угадывать, ср. §4.7).
• •Выбор значения: переключение 2–5 взаимоисключающих видимых опций — сегментированный контрол (вид: карточки/список §4.2, период: день/неделя/месяц) (Apple HIG, Segmented Controls); больше опций или опции с поиском — select/combobox (APG, §3.4); множественный выбор с обзором выбранного — чипы с крестиками.
• •Деструктивные операции. Ступени защиты по цене ошибки: обратимое одиночное — мгновенно + тост с undo (§4.12); пакетное — подтверждение с числом объектов (§4.2); необратимое ценное (удаление воронки с историей) — модалка с вводом имени объекта; проведённое в учёте — не удаляется, а сторнируется (§4.11). Подтверждения работают, только пока они редки: подтверждение на каждый чих вырабатывает слепой клик «Да» — и перестаёт защищать именно там, где нужно (NN/g, Confirmation Dialogs Can Prevent User Errors; тот же механизм привыкания, что в alarm fatigue, §4.5).

4.14. Списки, деревья, канбан

Три формы коллекций, дополняющие таблицы (§4.2) и карточки:

• •Список — одноколоночная коллекция для сканирования по одному главному признаку (лента активностей, результаты поиска §4.6, очередь задач): строка = идентификатор + 1–2 вторичных атрибута + время/статус; плотность и клавиатурный обход — по нормам §4.2; сложные сравнения в списке — сигнал, что нужна таблица.
• •Дерево — для истинных иерархий (структура организации, категории каталога, план счетов): APG-паттерн treeview со стрелочной навигацией и ленивой подгрузкой ветвей (W3C APG, Tree View); текущий путь виден (крошки §4.6); поиск по дереву обязателен с глубины 3 — раскрытие «вручную» глубоких ветвей не масштабируется. Антипаттерн — дерево как основная навигация всего продукта (унаследовано десктопными ERP 90-х): глобальные разделы — в сайдбар (§4.6), дерево — в контент.
• •Канбан-доска — процессная проекция коллекции: колонки = статусы workflow, карточка = запись (§4.2, card view). Правила: DnD-перенос с клавиатурной альтернативой (§3.4) и мгновенной валидацией перехода (запрещённый статус-переход отклоняется с причиной — правила workflow, §4.10); WIP-лимиты на колонки с визуальной сигнализацией перегрузки — смысл канбана как метода, а не раскладки (Anderson, Kanban, 2010); свёртывание колонок и «+N» при переполнении (§5.4 overflow); канбан и таблица — два вида одной коллекции с общим состоянием фильтров (§4.2), а не разные экраны.

4.15. Настройки и профиль

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

• •Три области видимости, разделённые явно: личные настройки пользователя (профиль, уведомления, язык/локаль §4.11, плотность §4.2, раскладки §5.3) / настройки организации (админ, §4.10) / системные (интеграции, биллинг). Пользователь всегда понимает, на кого повлияет изменение — «это увидят все» помечается.
• •Поиск по настройкам обязателен с ~двух десятков параметров: пользователь ищет словами своей задачи, а не по вашей таксономии (платформенная конвенция — настройки macOS/iOS/Android ищутся; Apple HIG, Settings).
• •Применение изменений предсказуемо: либо мгновенно с undo, либо явные «Сохранить/Отменить» — одна модель на весь раздел настроек, не вперемешку; деструктивные изменения (смена валюты учёта, часового пояса организации) — с предпросмотром последствий (§4.10, анализ влияния).
• •Профиль и уведомления. Профиль — точка входа в личные данные, безопасность (сессии, 2FA) и настройку каналов уведомлений по уровням §4.5: пользователь управляет своим бюджетом внимания (§7.2) — какие события прерывают, какие идут в дайджест. Дефолты уведомлений — консервативные: право прерывать выдаётся, а не отбирается.

4.16. Принципы enterprise-вендоров: сходимость

Пять ведущих вендоров публикуют свои дизайн-принципы — и они конвергентны вокруг ясности, согласованности и роль-ориентированности:

Два наблюдения. Во-первых, 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).

---

5. Виджеты: строительные блоки enterprise-интерфейса

Всё, что описано в §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).

5.1. Определение и типология

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

Типология не произвольна: для большинства классов существует нормативный интерфейсный паттерн W3C APG (grid, dialog, tabs, tree, combobox, menu…) с ролями ARIA и клавиатурным поведением (§3.4) — виджет без APG-паттерна — это виджет без спецификации. Виджет переживает и сам WIMP: пост-WIMP интерфейсы (речь, жест, агенты) всё равно рендерят проверяемые визуальные представления (van Dam, 1997, CACM, 40(2)) — что прямо связывает эту главу с §7.

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

5.2. Принципы проектирования виджета

• •Консистентность через единственность. Один класс задачи = один виджет: не «три дейтпикера в трёх модулях». Это операционализация «conformity with user expectations» (ISO 9241-110, §2.5) и закона Джейкоба внутри продукта: пользователь переносит навык между экранами.
• •Композируемость. Рамка — atomic design: атомы → молекулы → организмы → шаблоны → страницы (Frost, Atomic Design, 2016). Enterprise-поправка: реальная единица переиспользования — «организм» (грид с тулбаром и пагинацией, фильтр-панель, форма с секциями), а не только атомы-кнопки; библиотека из одних атомов — это конструктор без инструкции.
• •Инкапсуляция состояния. Принцип сокрытия информации Парнаса, применённый к UI: наружу — свойства и события, внутренности скрыты; потребитель не управляет виджетом «через DOM» (Parnas, 1972, CACM, 15(12)). Состояние делится на внутреннее (раскрыт ли попап — умирает с виджетом) и внешнее сохраняемое (сортировка, фильтры, раскладка — живёт в аккаунте, §4.2); граница между ними — проектное решение, а не случайность реализации.
• •Предсказуемость поведения. Одинаковый виджет ведёт себя одинаково везде: если клик по заголовку колонки сортирует в одном модуле — он сортирует во всех. Запрет «магии по месту» — локальных переопределений поведения без изменения облика.
• •Порог создания нового. Новый виджет появляется только после доказательства, что существующий не покрывает задачу конфигурацией (governance-процесс, §5.8). Симметричное правило — вовремя обобщать: третья копия «почти такого же» виджета — сигнал, что в системе не хватает одного настраиваемого.

5.3. Виджеты в дашбордах: компоновка и кастомизация

• •Модульная сетка, а не свободный холст. Дашборд собирается по сетке (12/24 колонок — прямое наследие швейцарской школы, §1.4); виджеты занимают предсказуемые типоразмеры (1×1, 2×1, 2×2…). Пиксельное позиционирование запрещено: оно разрушает выравнивание и «линии чтения» (§1.2) и делает раскладки несравнимыми между пользователями.
• •Приоритизация по сканированию. Важнейшее — в левый верхний угол (F-паттерн, §4.5); один дашборд — один вопрос роли. Тест Фью остаётся главным: дашборд читается «с одного взгляда»; если нужен скролл и вкладки — это уже отчёт или рабочая область, и их надо так и проектировать (§4.5).
• •Плотность — токеном, не кеглем. Уровни compact/comfortable наследуются от системы плотности таблиц (§4.2) и применяются к дашборду целиком, а не к отдельному виджету; минимальные размеры текста и целей (§3.4) не нарушаются ни на одном уровне плотности.
• •Кастомизация пользователем. Перестановка drag-and-drop, resize и выбор виджетов — это кастомизация (§4.10): снап к сетке, автосохранение раскладки в профиль, обязательная кнопка «вернуть раскладку роли». Дефолтные раскладки поставляются по ролям (§4.7), а не «одна на всех»; виджеты комплаенса и обязательных метрик роль удалить не может (RBAC действует и на уровне виджета). Прямая связь с §7.5: генеративная сборка воркспейсов — это та же кастомизация, ускоренная агентом, и она наследует те же ограничения.
• •Адаптивность к контейнеру, а не к экрану. Виджет реагирует на размер своего контейнера (container queries, §3.5) уровнями раскрытия: S — число и дельта; M — плюс спарклайн; L — полный чарт с легендой и фильтрами. Это прогрессивное раскрытие (§4.1) в пространственной форме; «фотографическое сжатие» полного чарта в тайл 200 px — антипаттерн.

5.4. Состояния виджета: контракт, а не украшение

Формальная рамка — конечный автомат: все состояния и переходы перечислены явно, как в statecharts (Harel, 1987, Science of Computer Programming, 8(3)). Проектирование «только happy path» — главный источник продакшен-дефектов виджетов: состояния, которые не нарисовали, всё равно наступят — их нарисует случайность.

Особый enterprise-акцент — partial: агрегат, собранный из четырёх источников при одном недоступном, обязан заявить о неполноте. Молчаливо неполный KPI хуже ошибки: ошибку видно, а неполноту — нет.

5.5. Данные и производительность виджета

• •Ленивая загрузка по приоритету. Виджеты ниже фолда грузятся по мере приближения; порядок загрузки видимых = порядок важности (первым — левый верхний, §4.5). Latency budget задаётся не только экрану, но и виджету (§4.4): p95 до полезного контента приоритетных виджетов ≤ 1 с.
• •Большие данные внутри виджета решаются теми же средствами, что в §4.2 (виртуализация, пагинация), но с поправкой на роль: виджет дашборда — не место для грида на 10 000 строк. Норма — «топ-N + переход»: пять строк и ссылка «все 1 240 →» в полноэкранную таблицу.
• •Real-time без дёрганья. Фоновое обновление не смещает раскладку (CLS), не крадёт фокус и не сбрасывает выделение/скролл (§5.7); изменившееся значение допустимо кратко подсветить — это семантическое использование преаттентивного внимания (§4.5). Частота обновления не выше частоты решения: тикающая каждую секунду месячная выручка — шум, а не сигнал (бюджет внимания, §7.2).
• •Кеш и свежесть. Паттерн stale-while-revalidate: мгновенно показать кешированное, обновить фоном; обязательный индикатор свежести («данные на 10:42») и ручной refresh. Свежесть — часть контракта данных виджета, а не деталь бэкенда: пользователь принимает решение по числу и имеет право знать его возраст.

5.6. Взаимодействие и связи между виджетами

Скрипт поведения дашборда давно сформулирован — мантра визуального поиска информации: «overview first, zoom and filter, then details-on-demand» (Shneiderman, 1996, Proc. IEEE VL'96). В терминах виджетов:

• •Drill-down обязателен. Каждый агрегат проваливается до записей-источников: KPI → отфильтрованная таблица (§4.2) → карточка записи (§4.6, «запись как хаб»). Цифра, в которую нельзя провалиться, непроверяема — тот же принцип, что цитирование источников у AI-ответов (§3.3, §7.4). Переход сохраняет контекст фильтров; путь дриллдауна виден (breadcrumb).
• •Cross-filtering — по модели brushing & linking. Выделение в одном представлении подсвечивает/фильтрует связанные — техника из статистической графики (Becker & Cleveland, 1987, Technometrics, 29(2)), систематизированная в исследованиях координированных представлений (Roberts, 2007, Proc. CMV'07). Правила: глобальный фильтр — видимый объект состояния с чипом «отфильтровано по X» и сбросом в один клик; скрытая связь пары виджетов, о которой знает только разработчик, — антипаттерн (state-невидимка нарушает «узнавание», §2.4).
• •Обратная связь каждого действия — по порогам §4.4; сортировки и фильтры внутри виджета сохраняются между сессиями (§4.2).
• •Антипаттерн «виджет-тупик»: интерактивность есть, но ведёт в никуда — клик перерисовывает сам виджет, не давая пути ни к записям, ни к контексту. Интерактивный виджет обязан отвечать на вопрос «и что дальше?».

5.7. Доступность виджета

Конкретизация §3.4 на уровне модуля:

• •Композитный виджет = один tab-stop. Внутренняя навигация — стрелками (roving tabindex или aria-activedescendant), Tab ведёт к следующему виджету, а не по двумстам ячейкам грида (W3C APG, Keyboard Interface). Для оператора это производительность (§4.2), для незрячего пользователя — проходимость экрана в принципе.
• •Роль, имя, состояние. Каждому виджету — APG-паттерн (grid, dialog, tablist, tree, combobox) и программное имя (aria-labelledby на заголовок). Чарт сопровождается текстовой альтернативой и таблицей данных по запросу — визуализация не единственный канал (§4.5, кодирование не только цветом).
• •Живые обновления. Фоновые изменения значений объявляются через aria-live="polite"; обновление данных никогда не крадёт фокус и не сбрасывает позицию скролла или выделение — сохранение контекста пользователя приоритетнее свежести пикселей (recognition, §2.4).
• •Оверлеи. Модал: focus trap внутри, Esc закрывает, фокус возвращается на вызвавший элемент (APG dialog). Side panel без focus trap — но с теми же правилами возврата фокуса.
• •Контраст. Текст — AA; границы виджета, иконки, сегменты чартов — non-text ≥3:1 (SC 1.4.11, §4.5).

5.8. Виджет в дизайн-системе: поставка и governance

Интеллектуальная родословная: язык паттернов Александера — «проблема + контекст + решение» (Alexander et al., A Pattern Language, OUP, 1977) → библиотеки UI-паттернов (Tidwell, Brewer & Valencia, Designing Interfaces, 3rd ed., O'Reilly, 2020) → компонентные дизайн-системы (§3.1). Документация виджета в DS — это паттерн Александера, доведённый до исполняемости.

• •Токены. Виджет потребляет только semantic- и component-токены (§3.2); хардкод значения в виджете — дефект код-ревью, потому что ломает темизацию и брендирование всей системы.
• •Документация компонента (стандарт зрелых систем — Carbon, Material, Fluent, §3.1): анатомия с именованными зонами, варианты и их назначение, все состояния §5.4, клавиатурное поведение по APG, do/don't-примеры, связка «Figma-компонент ↔ код» (§6.6, «component is the spec», Storybook).
• •Версионирование и вывод из эксплуатации. Semver; deprecation-политика: пометка, миграционный гайд, срок жизни старой версии; телеметрия использования версий по продуктам — иначе «мёртвые» виджеты живут вечно (ср. §4.10, версионирование конфигураций).
• •Контрибуция. Новый виджет проходит порог доказательства (§5.2) и принимается только с полным контрактом: состояния + APG + токены + документация + стенд. Наполовину задокументированный компонент — главный генератор форков.

Definition of Done виджета (дополнение к чек-листу §8.10):

• • Все состояния §5.4 спроектированы и реализованы (не только happy path)?
• • APG-паттерн: роль, имя, клавиатура, один tab-stop?
• • Только системные токены, ноль хардкода?
• • Адаптивность к контейнеру (S/M/L-уровни раскрытия)?
• • Свойства и события задокументированы; Storybook-стенд со всеми состояниями?
• • Телеметрия: ошибки, латентность, использование?

5.9. AI-native виджеты и горизонт

• •Виджет — единица генерации. Generative UI собирает представления из легитимных виджетов дизайн-системы, а не рисует произвольные пиксели (§7.5); машиночитаемость контракта — DTCG-токены плюс формальная схема свойств и событий — и есть то, что делает систему «agentic-ready» (§3.1).
• •AI-содержимое маркируется на уровне виджета: происхождение данных (источник, запрос), индикатор уверенности, drill-down к записям-источникам (§3.3). Прозрачность взаимодействия с AI — уже юридическое требование (Art. 50 EU AI Act, §3.4). Виджет с AI-цифрой без провала к источникам — антипаттерн, умноженный на автоматизационную предвзятость: объяснения без проверяемости лишь повышают слепое принятие (Bansal et al., §7.4).
• •Виджет как инструмент агента. Тот же контракт работает в обратную сторону: агент читает состояние виджета и действует через его события, а не «кликает по пикселям»; журнал действий агента естественно ложится на событийную модель виджетов — это техническая основа надзорного GUI (§7.4).
• •Стабильность против адаптивности. Постоянные рабочие виджеты не переставляются и не «оптимизируются» системой без запроса (эффект разрушения пространственной памяти — Findlater & McGrenere, §7.5); сгенерированные под задачу — явно помечены и закрепляемы (pin) с последующим версионированием как обычная кастомизация (§5.3, §4.10).

Enterprise-вывод главы: виджет — это контракт из пяти частей: данные (+свежесть), состояния (§5.4), клавиатура и ARIA (§5.7), токены (§5.8), события (§5.6, §5.9). Всё, что описано в §4, собирается из таких контрактов; всё, что описано в §7, будет ими управлять. Команда, у которой виджеты — контракты, получает агентную готовность почти бесплатно; команда с «одноразовыми» виджетами будет переписывать интерфейс дважды.

---

6. Прототипирование и процесс

6.1. Фреймворки процесса

Ни один из фреймворков не «правильнее» другого — они решают разные задачи и часто комбинируются.

Интеллектуальный корень всей дисциплины — 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.

6.2. Спектр детализации (fidelity) и что говорит наука

Спектр: 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, а не для поиска базовых проблем.

6.3. Инструменты 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 частично опираются на вторичные обзоры — при внедрении стоит сверить с офиц. сайтами.)

6.4. Дизайн-токены в pipeline (design → code)

Токены — это «контракт данных» между дизайном и разработкой. Практическая связка единого источника правды:

С версии 4 Style Dictionary нативно поддерживает DTCG-формат (styledictionary.com/dtcg); Penpot поддерживает DTCG «из коробки». Результат — одно изменение значения токена автоматически прокатывается на все платформы.

6.5. Тестирование гипотез и метрики

Важная оговорка про «правило пяти». Модель Нильсена–Ландауэра справедлива для качественного, формативного тестирования одной однородной аудитории. Для количественных/суммативных исследований 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), доля операций, завершённых без обращения в поддержку.

6.6. Хендофф и связь с разработкой

Тренд 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 связывают макет с реальным кодом. Это минимизирует расхождение «дизайн ↔ прод».

---

7. Будущее интерфейсов: теории, горизонты и enterprise-проекция

Раздел построен на трёх фильтрах. Первый — происхождение идей: почти все «интерфейсы будущего» опираются на исследовательские программы возрастом 30–60 лет (ubiquitous computing — 1991, mixed-initiative — 1999, мультимодальность — 1980, HMD — 1968); новизна 2020-х — не в теории, а в экономике реализации (LLM, дешёвые сенсоры, вычисления на устройстве). Второй — enterprise-проекция: каждое направление оценивается по влиянию на плотные данные, ввод, дашборды и ролевые сценарии CRM/ERP/SaaS. Третий — горизонт зрелости: «уже применимо» (есть внедрения и данные), «ближний горизонт» (2–5 лет, есть работающие прототипы), «спекулятивное» (10+ лет, есть только исследования). Маркетинговые заявления вендоров используются лишь как свидетельства направления инвестиций, не как доказательства эффекта (см. §9).

7.1. Post-GUI / Zero UI: исчезающий интерфейс

Программный тезис сформулировал 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 при этом не исчезает, а смещается к роли слоя надзора.

7.2. Calm technology и ambient computing

Наследие Вайзера содержит не только «исчезновение», но и позитивную программу: 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-статусы кросс-системных процессов (заказ→склад→доставка) в рабочих средах команд.

7.3. Anticipatory / проактивный дизайн

Термин ввёл 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-проекция. Лестница проактивности, по которой стоит подниматься только с измеренной точностью предсказаний:

1. •Умные дефолты — предзаполнение из контекста (уже норма, §4.3);
2. •Предложения — next-best-action в CRM, черновик ответа, рекомендованный заказ (уже применимо; принятие/отклонение в один клик);
3. •Подтверждаемые действия — система подготовила операцию, человек утверждает (ближний горизонт для средних рисков);
4. •Автономные действия с журналом — только низкорисковые, обратимые, с прозрачным аудитом (ближний горизонт; см. §7.4).

Правило: доля принятых предложений — продуктовая метрика проактивности. Эмпирическое основание — телеметрия кодовых копилотов: доля принятия оказалась лучшим предиктором воспринимаемой продуктивности среди всех измеренных сигналов (Ziegler et al., 2024, CACM, 67(3)). Универсального порога не существует: для дешёвых в проверке предложений (автодополнение) приемлема доля ~20–30%, для транзакционных enterprise-действий стоимость ошибочного принятия много выше стоимости отклонения — порог задаётся локально из соотношения «цена проверки vs цена исправления». Если доля принятия падает и не растёт — возвращайтесь на ступень ниже по лестнице автономии.

7.4. Conversational и agentic UX: от интерфейса кнопок к интерфейсу намерений

Разговорный интерфейс — старейшая мечта 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) — он его переизобретает. Соответствие прямое:

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.

7.5. Generative / adaptive UI: интерфейс, собираемый под задачу

Идея интерфейса, генерируемого под пользователя и контекст, имеет строгую академическую родословную: система 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-запросу из готовых виджетов. Ближний горизонт: ролевые воркспейсы, собираемые под конкретный кейс (онбординг клиента, инцидент, аудит) и переиспользуемые как шаблоны. Спекулятивное: полностью персональные интерфейсы — упирается в поддержку, обучение, комплаенс и коллективную работу (у коллег должен быть «тот же экран»).

7.6. Spatial computing и XR

Родословная: концепт «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 как основное рабочее место офисного аналитика — текущие данные говорят против.

7.7. Мультимодальное взаимодействие: голос, жест, взгляд

Каноническое начало — «Put-That-There» Ричарда Болта: голос + указательный жест, где дейксис («вот это — туда») разрешается взглядом на экран (Bolt, SIGGRAPH 1980). Дисциплинирующий корректив — «Десять мифов мультимодальности» Шэрон Овиатт: мультимодальный ≠ «голос поверх всего»; пользователи выбирают модальность под задачу; речь плохо подходит для точных пространственных операций; мультимодальные команды не всегда быстрее (Oviatt, 1999, CACM, 42(11)). Для взгляда как ввода фундаментальна проблема Midas touch: взгляд — орган восприятия, а не команды; наивное «смотрю = нажимаю» превращает каждый взгляд в клик (Jacob, CHI 1990); рабочее решение — взгляд наводит, подтверждает другая модальность (щипок в visionOS — прямой наследник этого паттерна).

Enterprise-проекция. Выбор модальности диктуется средой: шум, приватность (open space!), занятость рук и глаз. Уже применимо десятилетия: голосовой отбор на складе (voice picking), диктовка полевых заметок в мобильный CRM, транскрипция звонков в активности. Ближний горизонт: дейктическая мультимодальность поверх дашбордов — указать на аномалию и спросить «почему здесь спад?» (указание снимает главную слабость чистого языка — ссылку на объект). Спекулятивное: взгляд/жест как повседневные офисные модальности.

7.8. BCI и спекулятивные горизонты

Нейроинтерфейсы — строгая клиническая дисциплина с 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).

7.9. Синтез: три горизонта и что это значит для enterprise-дизайна

Три структурных вывода.

Первый: 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 расширяются агентными (доля принятых предложений, точность, время до обнаружения ошибки агента человеком), а карта ролей продукта пополняется ролью «супервизор агентов».

---

8. Практические рекомендации (actionable)

Рекомендации сгруппированы по областям и отсортированы по соотношению «эффект / усилие». Каждая опирается на тезисы выше. Приоритизация по зрелости: организациям в начале пути — сначала №1–2, 4–5, 8–9 и 18 (инфраструктура, таблицы, формы, отклик); блок №22–26 (агенты) имеет смысл только при живой дизайн-системе, телеметрии и бэкенд-RBAC — иначе он строится на песке.

8.1. Инфраструктура: дизайн-система и токены

1. •Введите трёхуровневые токены (primitive → semantic → component) в формате W3C DTCG 2025.10; настройте pipeline Figma Variables → Tokens Studio → DTCG → Style Dictionary → платформы. Это единственный масштабируемый способ поддерживать темы, бренды и мультиплатформенность (§3.2, §6.4).
2. •Зашейте доступность в токены и компоненты по умолчанию: мин. размер интерактивной цели 24×24 px (WCAG 2.2 SC 2.5.8), видимый фокус, контраст AA, APG-паттерны сложных виджетов. Дешевле встроить, чем чинить постфактум (§3.4).
3. •Не изобретайте систему с нуля — возьмите зрелую базу (Carbon для data-heavy, Fluent/Material для кросс-платформы) и кастомизируйте через токены (§3.1).

8.2. Плотные данные и таблицы

1. •Стандартизируйте плотность: compact ~32–40 px, comfortable ~48–56 px, переключатель плотности вне таблицы (§4.2).
2. •Числа — вправо, табличными цифрами; текст — влево; центрирование запретить. Первая колонка — человекочитаемый ID; freeze шапки и первой колонки (§4.2).
3. •Редактирование — в side-panel, не в модалке (сохраняет контекст соседних записей). Сохраняйте состояние сортировок/фильтров/колонок в аккаунте + кнопка reset; полный клавиатурный обход по APG (§4.2).
4. •Для рабочих данных — пагинация (или гибрид с виртуализацией), не бесконечный скролл (§4.2).

8.3. Формы и ввод

1. •Верхние лейблы, одна колонка, валидация on-blur, ошибки — у поля и конкретные; прощающий ввод с нормализацией на стороне системы; маски — только для действительно единственного формата (§4.3).
2. •Ввод никогда не теряется: автосохранение черновиков, восстановление после таймаута сессии; Tab-порядок равен визуальному; «сохранить и создать следующую» для массового ввода (§4.3).

8.4. Дашборды, навигация, роли

1. •Максимизируйте data-ink ratio, удалите chartjunk; важнейший KPI — в левый верхний угол, выделен преаттентивно. Тип графика — по иерархии Cleveland–McGill: сравнения — позицией/длиной (bar), динамика — линией; площадь и цвет — последнее средство (§4.5).
2. •Введите бюджет прерываний и уровни алертов (прерывание / бейдж / периферия-дайджест) — против alarm fatigue; добавьте command palette (Cmd/Ctrl+K), хлебные крошки и поиск для глубокой навигации (§4.5, §4.6, §7.2).
3. •RBAC: hide — для принципиально недоступного, disable+тултип — для «можно запросить». Обязательно дублируйте проверку прав на бэкенде (§4.7).

8.5. Когнитивная нагрузка и онбординг

1. •Снимайте extraneous-нагрузку, а не предметную сложность: умные дефолты, автоподстановка, валидация на вводе, прогрессивное раскрытие редких функций (§4.1).
2. •Проектируйте онбординг под time-to-first-value каждой роли, а не под «прохождение тура»; начните с продуктивного empty state и одного activation event (§4.8).
3. •Ограничивайте не число видимых опций, а число единиц, которые пользователь держит в голове между шагами (правильное прочтение Миллера) (§1.1).

8.6. AI-функции

1. •Стройте гибрид «intent + GUI», а не чистый чат: намерение — для нечёткого, прямое манипулирование — для точного (§3.3).
2. •Обязательные паттерны доверия: заранее показать возможности и границы агента; human-in-the-loop с подтверждением необратимых действий; индикаторы уверенности; цитирование источников; обратимость всегда — undo для UI, сторно-компенсация для проведённых операций (§4.11); streaming вместо «немого» ожидания (§3.3, по Amershi et al., 2019).

8.7. Отзывчивость

1. •Зафиксируйте latency budget как SLA: фидбек ≤100 мс, ключевые операции ≤1 с (цель — порог Доэрти ~400 мс), дольше 1 с — прогресс, дольше 10 с — фоновая задача с уведомлением; skeleton вместо спиннеров, optimistic UI (с undo) для частотных действий (§4.4).

8.8. Процесс и тестирование

1. •Тестируйте рано на lo-fi (fidelity не влияет на число/тяжесть находок) — не откладывайте до hi-fi (§6.2).
2. •Итерируйте: 3 цикла по 5 пользователей вместо одного на 15; для разных ролей — по 3–5 на роль; RITE для быстрых правок; на масштабе — метрики HEART по ролям (§6.5).
3. •Формулируйте гипотезы явно («We believe… We'll know we're right when…») и проверяйте сначала самое рискованное допущение (Lean UX) (§6.1).

8.9. Горизонт: агентные и пост-GUI сценарии

1. •Проектируйте агента как supervisory control, а не как чат: видимый план → выполнение с вехами → отчёт с diff и откатом; уровни автономии — явная настройка (§7.4).
2. •Поднимайтесь по лестнице проактивности только с измеренной точностью: дефолты → предложения → подтверждаемые действия → автономия с журналом; доля принятых предложений — продуктовая метрика (§7.3).
3. •Generative UI — только в границах дизайн-системы: сборка из легитимных компонентов и токенов; сгенерированное можно закрепить и версионировать; постоянные рабочие экраны не «адаптируются» без запроса (§7.5, Findlater & McGrenere).
4. •Голос и XR — по контексту среды, не по моде: hands-busy/eyes-busy сценарии (склад, выезд) — да; офисное ядро — нет, пока данные не изменятся (§7.6–6.7).
5. •Агент = новый тип пользователя: наследование RBAC, собственный журнал аудита, границы полномочий, SLA точности; никогда не давайте агенту прав больше, чем у инициатора (§4.7, §7.4).

8.10. Чек-лист экспресс-аудита экрана

Прогоните любой экран по строкам ядра принципов (§2.4) и порогам качества — каждая непокрытая строка есть дефект:

• • Статус системы виден (загрузка, сохранение, ошибки, прогресс)?
• • Консистентность с остальным продуктом и платформенными стандартами?
• • Ошибки предотвращаются, а действия обратимы (undo)?
• • Узнавание вместо припоминания (контекст не теряется между шагами)?
• • Минимализм (нет chartjunk и визуального шума — extraneous load)?
• • Контроль у пользователя (нет «ловушек», есть выход)?
• • Ускорители для экспертов (хоткеи, command palette, bulk actions)?
• • Доступность (цель ≥24px, фокус виден, контраст AA, клавиатурный путь)?
• • Отзывчивость (фидбек ≤100 мс; операции ≤1 с или прогресс/skeleton)?
• • Ввод не теряется (автосохранение, валидация on-blur, конкретные ошибки)?

8.11. Сквозной кейс: аудит экрана «Реестр сделок» по чек-листу

Демонстрация чек-листа §8.10 на типовом экране B2B CRM. Исходное состояние: таблица ~2 000 сделок, 14 колонок, редактирование в модальном окне; 200 менеджеров, у каждого ~50 операций правки в день. Все числа «до» — из аудита условного, но типичного продукта; логика переносима.

Экономика (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).

---

9. Спорные атрибуции и методологические ограничения

Научная честность требует зафиксировать места, где популярные формулировки неточны или где доказательная база слабее. Это укрепляет, а не подрывает выводы.

• •«Form follows function» принадлежит Луису Салливану (1896), а не Баухаусу; Баухаус лишь развил идею. «Less is more» — атрибуция Мису ван дер Роэ по традиции (восходит к Петеру Беренсу) (§1.4).
• •Закон Миллера ≠ «7 пунктов меню». Это про удержание в рабочей памяти, а не про число видимых опций; реальный предел ближе к 4±1 (Cowan, 2001) (§1.1).
• •Формула Фиттса в оригинале — log₂(2D/W); используемая в HCI шенноновская форма log₂(D/W+1) — уточнение MacKenzie (1992), а не сам Фиттс (§1.1).
• •Триада когнитивной нагрузки (intrinsic/extraneous/germane) — из работ Sweller/Ayres/Kalyuga (2011), а не из статьи 1988 года (§4.1).
• •APCA не входит в текущий WCAG 3.0 — исключён из черновика в 2023; WCAG 3.0 не будет финализирован ранее ~2030 (§3.4).
• •2-е правило Шнайдермана («seek universal usability») — из поздних изданий; в оригинале 1987 г. — «enable frequent users to use shortcuts» (§2.2).
• •«Правило пяти пользователей» валидно для формативного качественного теста одной аудитории; для количественных исследований нужно ~20; критиковалось (Faulkner, 2003) (§6.5).
• •Fidelity-исследования: вывод «fidelity не влияет» касается числа и тяжести проблем; тип находок различается — это не то же самое, что «hi-fi бесполезен» (§6.2).
• •Порог Доэрти — индустриальный отчёт IBM (1982), а не рецензируемая работа; направление эффекта согласуется с академическими порогами Миллера–Нильсена, но конкретные цифры продуктивности переносить дословно не стоит (§4.4).
• •RBAC-UX и AI-паттерны 2026 частично опираются на отраслевые (не рецензируемые) источники — их вес ниже, чем у стандартов и первичных работ; при высоких ставках верифицируйте на месте. То же относится к паттернам онбординга (§4.8): Pendo/Appcues/Userpilot — вендоры этих инструментов; независимая эмпирика — NN/g.
• •Принципы вендоров (§4.16) — самоописание, а не проверяемые свойства продуктов. Формулировка Workday «Simple · Fast · Clever» подтверждается официальной страницей принципов; ServiceNow публикует принципы как развёрнутый «этос» без фиксированной триады — встречающаяся в сторонних обзорах формула «Fluid·Symphonic·Resonant» официальной страницей не подтверждается и в таблице не используется.
• •Эстетико-утилитарный эффект (§3.8) доказан для воспринимаемой юзабилити (Kurosu & Kashimura; Tractinsky), а не для объективной производительности: в юзабилити-тестах красота действует как гало и маскирует реальные проблемы — красивые прототипы тестируйте строже, а не мягче (NN/g). Эталоны «enterprise-красоты» (Stripe, Linear, Notion) — аналитический разбор публичных продуктов, а не рецензируемое сравнение.
• •Liquid Glass (§3.7): свойства материала и его «пользы» — заявления вендора (Apple Newsroom, WWDC-сессии); независимая экспертиза зафиксировала издержки юзабилити (NN/g, 2025), а коррекция WWDC 2026 подтвердила проблему де-факто. Enterprise-проекция «заимствуй/не переноси» — аналитический перенос принципов, а не результат опубликованных исследований в data-heavy контексте.
• •Статус EU AI Act подвижен: сроки high-risk обязательств уже переносились Digital Omnibus (май–июнь 2026); указанные даты (Art. 50 — 02.08.2026; Annex III — 02.12.2027) сверяйте с официальным трекером внедрения перед принятием комплаенс-решений.
• •KLM-оценки кейса §8.11 — расчётные, на условных частотах операций; это метод демонстрации, а не бенчмарк. Пересчитывайте на телеметрии собственного продукта.
• •Раздел §7 намеренно разделяет доказательные слои. Инженерная психология автоматизации (Bainbridge; Parasuraman & Riley; Parasuraman–Sheridan–Wickens; Lee & See; Endsley) — рецензируемая классика из авиации и АСУ ТП; её перенос на LLM-агентов — обоснованная экстраполяция, но прямой эмпирики по enterprise-агентам пока мало. Продуктовые заявления вендоров (Agentforce, Joule, Copilot) — маркетинговые свидетельства направления, а не доказательства эффекта. Данные о продуктивности офисной работы в XR противоречивы, ближе к негативным (Biener et al., 2022). Уровни автоматизации и континуум Милгрэма–Кишино — полезные таксономии, а не эмпирические законы.

---

10. Источники

Первичные и авторитетные вторичные источники, сгруппированные по разделам. Все URL проверялись в ходе исследования (июль 2026).

Исторический фундамент и правила проектирования (§1–2)

• •Fitts, P. M. (1954). The Information Capacity of the Human Motor System in Controlling the Amplitude of Movement. Journal of Experimental Psychology, 47(6), 381–391. — https://psychclassics.yorku.ca/Fitts/
• •MacKenzie, I. S. (1992). Fitts' Law as a Research and Design Tool in Human-Computer Interaction. Human-Computer Interaction, 7(1), 91–139. — https://www.yorku.ca/mack/hci1992.pdf
• •Tognazzini, B. First Principles of Interaction Design. askTog. — https://asktog.com/atc/principles-of-interaction-design/
• •Hick, W. E. (1952). On the Rate of Gain of Information. QJEP, 4(1), 11–26. — https://doi.org/10.1080/17470215208416600
• •Hyman, R. (1953). Stimulus information as a determinant of reaction time. JEP, 45(3), 188–196. — https://doi.org/10.1037/h0056940
• •Proctor, R. W. & Schneider, D. W. (2018). Hick's law for choice reaction time: A review. QJEP. — https://web.ics.purdue.edu/~dws/pubs/ProctorSchneider_2018_QJEP.pdf
• •Miller, G. A. (1956). The Magical Number Seven, Plus or Minus Two. Psychological Review, 63(2), 81–97. — https://psychclassics.yorku.ca/Miller/
• •Cowan, N. (2001). The magical number 4 in short-term memory. Behavioral and Brain Sciences, 24(1), 87–114. — https://doi.org/10.1017/S0140525X01003922
• •Wertheimer, M. (1923); обзор: A Century of Gestalt Psychology in Visual Perception. — https://pmc.ncbi.nlm.nih.gov/articles/PMC3482144/
• •Nielsen, J. (1994). Enhancing the Explanatory Power of Usability Heuristics. Proc. CHI'94. — https://dl.acm.org/doi/10.1145/191666.191729 · актуальные определения: https://www.nngroup.com/articles/ten-usability-heuristics/
• •Shneiderman, B. (1987). Designing the User Interface (Eight Golden Rules). Авторская формулировка: — https://www.cs.umd.edu/users/ben/goldenrules.html
• •Norman, D. A. (2013). The Design of Everyday Things. Revised & Expanded. Basic Books. (1-е изд. — 1988, The Psychology of Everyday Things.)
• •ISO 9241-110:2020. Ergonomics of human-system interaction — Part 110: Interaction principles. — https://www.iso.org/standard/75258.html
• •Jakob's Law (Nielsen, 2000). Laws of UX. — https://lawsofux.com/jakobs-law/
• •Card, Moran & Newell (1983). The Psychology of Human-Computer Interaction. — https://archive.org/details/psychologyofhuma0000card
• •MoMA. Bauhaus. — https://www.moma.org/collection/terms/bauhaus
• •Müller-Brockmann, J. (1981). Grid Systems in Graphic Design / Raster­systeme für die visuelle Gestaltung. Niggli. (Печатное издание; устойчивого официального URL нет.)
• •Dieter Rams: Ten Principles of Good Design. Design Museum. — https://designmuseum.org/discover-design/all-stories/what-is-good-design-a-quick-look-at-dieter-rams-ten-principles
• •The Mother of All Demos (Engelbart, 1968). — https://www.dougengelbart.org/content/view/209/
• •Johnson, J. et al. (1989). The Xerox Star: A Retrospective. IEEE Computer, 22(9), 11–26. — https://ieeexplore.ieee.org/document/35211
• •Apple Computer (1987). Human Interface Guidelines: The Apple Desktop Interface. Addison-Wesley.

Актуальное состояние 2026 (§3)

• •Google (2025). Material 3 Expressive. — https://blog.google/products-and-platforms/platforms/android/material-3-expressive-android-wearos-launch/ · https://m3.material.io/
• •Salesforce. What is SLDS 2. — https://www.salesforce.com/blog/what-is-slds-2/
• •IBM Carbon Design System. — https://carbondesignsystem.com/
• •Microsoft Fluent 2. — https://fluent2.microsoft.design/
• •Shopify Polaris (2025). — https://www.shopify.com/partners/blog/polaris-goes-stable-the-future-of-shopify-app-development-is-here
• •Ant Design v6 (2025). — https://ant.design/
• •W3C DTCG (2025-10-28). Design Tokens specification reaches first stable version. — https://www.w3.org/community/design-tokens/2025/10/28/design-tokens-specification-reaches-first-stable-version/ · спека: https://www.designtokens.org/tr/2025.10/
• •Fowler, M. Design Token-Based UI Architecture. — https://martinfowler.com/articles/design-token-based-ui-architecture.html
• •Nielsen, J. (2023). AI: First New UI Paradigm in 60 Years. NN/g. — https://www.nngroup.com/articles/ai-paradigm/
• •Amershi, S. et al. (2019). Guidelines for Human-AI Interaction. Proc. CHI'19. — https://dl.acm.org/doi/10.1145/3290605.3300233 · HAX Toolkit: https://www.microsoft.com/en-us/haxtoolkit/
• •Google PAIR. People + AI Guidebook. — https://pair.withgoogle.com/guidebook/ · The Shape of AI: https://www.shapeof.ai/
• •SAP Joule. — https://www.sap.com/products/artificial-intelligence/ai-assistant.html · Salesforce Agentforce. — https://www.salesforce.com/agentforce/
• •W3C (2023). What's New in WCAG 2.2. — https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/ · спека: https://www.w3.org/TR/WCAG22/
• •W3C. WAI-ARIA Authoring Practices Guide (APG). — https://www.w3.org/WAI/ARIA/apg/ · Grid Pattern: https://www.w3.org/WAI/ARIA/apg/patterns/grid/
• •Roselli, A. (2026). WCAG 3 Contrast as of April 2026. — https://adrianroselli.com/2026/04/wcag3-contrast-as-of-april-2026.html
• •Level Access. European Accessibility Act. — https://www.levelaccess.com/compliance-overview/european-accessibility-act-eaa/ · https://www.dwt.com/insights/2025/07/european-accessibility-act-digital-products
• •EU AI Act — Regulation (EU) 2024/1689. — https://eur-lex.europa.eu/eli/reg/2024/1689/oj · трекер внедрения: https://artificialintelligenceact.eu/implementation-timeline/ · Digital Omnibus (перенос high-risk сроков, 2026): https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
• •Marcotte, E. (2010). Responsive Web Design. A List Apart. — https://alistapart.com/article/responsive-web-design/ · Container queries: https://web.dev/blog/cq-stable
• •Apple (2025). Apple introduces a delightful and elegant new software design (Liquid Glass). — https://www.apple.com/newsroom/2025/06/apple-introduces-a-delightful-and-elegant-new-software-design/
• •Apple Developer. HIG — Materials — https://developer.apple.com/design/human-interface-guidelines/materials · Adopting Liquid Glass — https://developer.apple.com/documentation/technologyoverviews/adopting-liquid-glass · WWDC25: Meet Liquid Glass — https://developer.apple.com/videos/play/wwdc2025/219/ · Get to know the new design system — https://developer.apple.com/videos/play/wwdc2025/356/
• •NN/g (2025). Liquid Glass Is Cracked, and Usability Suffers in iOS 26. — https://www.nngroup.com/articles/liquid-glass/
• •MacRumors. iOS 26's Liquid Glass Design Draws Criticism (17.09.2025) — https://www.macrumors.com/2025/09/17/ios-26-liquid-glass-critiques/ · Apple Announces Liquid Glass Improvements and Transparency Slider (08.06.2026) — https://www.macrumors.com/2026/06/08/apple-announces-liquid-glass-improvements/ · TechCrunch (08.06.2026) — https://techcrunch.com/2026/06/08/apple-is-tweaking-its-controversial-liquid-glass-design/
• •Infinum (2025). Apple's iOS 26 Liquid Glass: Sleek, Shiny, and Questionably Accessible. — https://infinum.com/blog/apples-ios-26-liquid-glass-sleek-shiny-and-questionably-accessible/
• •Kurosu, M. & Kashimura, K. (1995). Apparent Usability vs. Inherent Usability. CHI'95. — https://dl.acm.org/doi/10.1145/223355.223680
• •Tractinsky, N., Katz, A. S. & Ikar, D. (2000). What is Beautiful is Usable. Interacting with Computers, 13(2), 127–145. — https://doi.org/10.1016/S0953-5438(00)00031-X
• •Norman, D. A. (2004). Emotional Design: Why We Love (or Hate) Everyday Things. Basic Books.
• •Reber, R., Schwarz, N. & Winkielman, P. (2004). Processing Fluency and Aesthetic Pleasure. Personality and Social Psychology Review, 8(4), 364–382. — https://doi.org/10.1207/s15327957pspr0804_3
• •Lindgaard, G. et al. (2006). Attention Web Designers: You Have 50 Milliseconds to Make a Good First Impression! Behaviour & IT, 25(2), 115–126. — https://doi.org/10.1080/01449290500330448
• •Moshagen, M. & Thielsch, M. T. (2010). Facets of Visual Aesthetics (VisAWI). Int. J. Human-Computer Studies, 68(10), 689–709. — https://doi.org/10.1016/j.ijhcs.2010.05.006
• •Reinecke, K. & Gajos, K. (2014). Quantifying Visual Preferences Around the World. Proc. CHI'14. — https://dl.acm.org/doi/10.1145/2556288.2557052
• •NN/g. The Aesthetic-Usability Effect. — https://www.nngroup.com/articles/aesthetic-usability-effect/
• •Murrell, A. (2023). The Age of Average. — https://www.alexmurrell.co.uk/articles/the-age-of-average

Специфика CRM/ERP/SaaS (§4)

• •Sweller, J. (1988). Cognitive load during problem solving. Cognitive Science, 12(2). — https://onlinelibrary.wiley.com/doi/10.1207/s15516709cog1202_4 · триада: Sweller, Ayres & Kalyuga (2011), Cognitive Load Theory, Springer — https://link.springer.com/book/10.1007/978-1-4419-8126-4
• •Tesler's Law. Laws of UX. — https://lawsofux.com/teslers-law/
• •Nielsen, J. Progressive Disclosure. NN/g. — https://www.nngroup.com/articles/progressive-disclosure/
• •Laubheimer, P. NN/g. Data Tables: Four Major User Tasks. — https://www.nngroup.com/articles/data-tables/
• •IBM Carbon. Data table — Style. — https://carbondesignsystem.com/components/data-table/style/
• •Pencil & Paper. Data Table Design UX Patterns. — https://www.pencilandpaper.io/articles/ux-pattern-analysis-enterprise-data-tables
• •AG Grid. DOM Virtualisation (офиц. документация). — https://www.ag-grid.com/javascript-data-grid/dom-virtualisation/ · TanStack Virtual (офиц. документация). — https://tanstack.com/virtual/latest
• •NN/g. Cards: UI-Component Definition. — https://www.nngroup.com/articles/cards-component/ · Material 3, Cards — Guidelines: https://m3.material.io/components/cards/guidelines
• •W3C. Understanding SC 1.4.11: Non-text Contrast (WCAG 2.2). — https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html
• •NN/g. Modal & Nonmodal Dialogs. — https://www.nngroup.com/articles/modal-nonmodal-dialog/ · Confirmation Dialogs Can Prevent User Errors: https://www.nngroup.com/articles/confirmation-dialog/
• •NN/g. Hamburger Menus and Hidden Navigation. — https://www.nngroup.com/articles/hamburger-menus/ · Mega Menus Work Well: https://www.nngroup.com/articles/mega-menus-work-well/ · Icon Usability: https://www.nngroup.com/articles/icon-usability/
• •Saffer, D. (2013). Microinteractions: Designing with Details. O'Reilly. — https://www.oreilly.com/library/view/microinteractions/9781449342807/
• •Wong, B. (2011). Points of View: Color Blindness. Nature Methods, 8(6), 441 (палитра Окабэ–Ито). — https://www.nature.com/articles/nmeth.1618
• •Bringhurst, R. The Elements of Typographic Style. Hartley & Marks. · Butterick, M. Practical Typography (line length): https://practicaltypography.com/line-length.html
• •Material 3. Layout — https://m3.material.io/foundations/layout/understanding-layout/overview · Motion — https://m3.material.io/styles/motion/overview
• •W3C APG. Tree View Pattern. — https://www.w3.org/WAI/ARIA/apg/patterns/treeview/
• •IBM Carbon. Button — Usage. — https://carbondesignsystem.com/components/button/usage/
• •Apple HIG. Segmented Controls — https://developer.apple.com/design/human-interface-guidelines/segmented-controls · Settings — https://developer.apple.com/design/human-interface-guidelines/settings
• •Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. — https://www.oreilly.com/library/view/kanban/9780984521401/
• •Wroblewski, L. (2008). Web Form Design: Filling in the Blanks. Rosenfeld Media. — https://www.lukew.com/resources/web_form_design.asp
• •Penzo, M. (2006). Label Placement in Forms. UXmatters. — https://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php
• •Baymard Institute. Usability Testing of Inline Form Validation. — https://baymard.com/blog/inline-form-validation
• •Nielsen, J. Error-Message Guidelines. NN/g. — https://www.nngroup.com/articles/error-message-guidelines/
• •Miller, R. B. (1968). Response time in man-computer conversational transactions. AFIPS FJCC. — https://dl.acm.org/doi/10.1145/1476589.1476628
• •Card, S., Robertson, G. & Mackinlay, J. (1991). The Information Visualizer, an Information Workspace. CHI'91. — https://dl.acm.org/doi/10.1145/108844.108874
• •Nielsen, J. (1993). Response Times: The 3 Important Limits. NN/g. — https://www.nngroup.com/articles/response-times-3-important-limits/
• •Doherty, W. J. & Thadani, A. J. (1982). The Economic Value of Rapid Response Time. IBM. — обзор: https://lawsofux.com/doherty-threshold/
• •Wroblewski, L. (2013). Mobile Design Details: Avoid The Spinner. — https://www.lukew.com/ff/entry.asp?1797
• •Mishunov, D. (2016). True Lies of Optimistic User Interfaces. Smashing Magazine. — https://www.smashingmagazine.com/2016/11/true-lies-of-optimistic-user-interfaces/
• •Few, S. (2006). Information Dashboard Design. — https://www.perceptualedge.com/files/Dashboard_Design_Course.pdf
• •Tufte, E. (1983). The Visual Display of Quantitative Information. — https://www.edwardtufte.com/book/the-visual-display-of-quantitative-information/ · Data-Ink Ratio: https://infovis-wiki.net/wiki/Data-Ink_Ratio
• •Cleveland, W. S. & McGill, R. (1984). Graphical Perception: Theory, Experimentation, and Application. JASA, 79(387), 531–554. — https://www.jstor.org/stable/2288400
• •Woods, D. D. (1995). The alarm problem and directed attention in dynamic fault management. Ergonomics, 38(11). — https://www.tandfonline.com/doi/abs/10.1080/00140139508925274
• •Nielsen, J. (2006). F-Shaped Pattern For Reading Web Content. NN/g. — https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content-discovered/
• •Rosenfeld, Morville & Arango (2015). Information Architecture: For the Web and Beyond. — https://intertwingled.org/the-polar-bear-book/
• •Command Palette pattern. — https://uxpatterns.dev/patterns/advanced/command-palette
• •RBAC UX: Permit.io — https://www.permit.io/blog/implementing-react-rbac-authorization · Oso — https://www.osohq.com/learn/rbac-best-practices
• •OWASP. Top 10 for Large Language Model Applications. — https://owasp.org/www-project-top-10-for-large-language-model-applications/
• •Hulick, S. (UserOnboard) via Intercom. — https://www.intercom.com/blog/podcasts/useronboards-samuel-hulick-on-designing-paths-not-products/
• •NN/g. Mobile-App Onboarding (эмпирика по турам). — https://www.nngroup.com/articles/mobile-app-onboarding/
• •Nielsen, J. Enterprise Usability. NN/g. — https://www.nngroup.com/articles/enterprise-usability/ · A 100-Year View of UX (покупатель ≠ пользователь у мейнфреймов): https://www.nngroup.com/articles/100-years-ux/
• •Davis, F. D. (1989). Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology (TAM). MIS Quarterly, 13(3), 319–340. — https://doi.org/10.2307/249008
• •NN/g. Customization vs. Personalization. — https://www.nngroup.com/articles/customization-personalization/
• •Nielsen, J. Search and You May Find / синергия поиска и навигации. NN/g. — https://www.nngroup.com/articles/search-not-enough/
• •Kleppmann, M., Wiggins, A., van Hardenberg, P. & McGranaghan, M. (2019). Local-First Software: You Own Your Data, in Spite of the Cloud. Onward!/ACM. — https://dl.acm.org/doi/10.1145/3359591.3359737
• •W3C Internationalization. Text Size in Translation. — https://www.w3.org/International/articles/article-text-size · Unicode CLDR: https://cldr.unicode.org/
• •Dourish, P. & Bellotti, V. (1992). Awareness and Coordination in Shared Workspaces. Proc. CSCW'92. — https://dl.acm.org/doi/10.1145/143457.143468
• •Garcia-Molina, H. & Salem, K. (1987). Sagas. Proc. SIGMOD'87 (компенсирующие транзакции). — https://dl.acm.org/doi/10.1145/38713.38742
• •SAP Fiori Design Principles. — https://www.sap.com/design-system/fiori-design-ios/discover/sap-design-system/vision-and-mission/sap-fiori-design-principles
• •Salesforce Lightning Design System (принципы). — https://www.lightningdesignsystem.com/ · Villamor, C. — https://medium.com/salesforce-ux/how-we-designed-the-new-salesforce-at-scale-6d3607fd92e5
• •Workday Canvas — https://canvas.workday.com/ · ServiceNow Horizon — https://horizon.servicenow.com/ · Microsoft Fluent 2 — https://fluent2.microsoft.design/

Виджеты (§5)

• •Krasner, G. E. & Pope, S. T. (1988). A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80. JOOP, 1(3), 26–49. — https://dl.acm.org/doi/10.5555/50757.50759
• •Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. CACM, 15(12), 1053–1058. — https://dl.acm.org/doi/10.1145/361598.361623
• •van Dam, A. (1997). Post-WIMP User Interfaces. CACM, 40(2), 63–67. — https://dl.acm.org/doi/10.1145/253671.253708
• •Frost, B. (2016). Atomic Design. — https://atomicdesign.bradfrost.com/
• •Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8(3), 231–274. — https://www.sciencedirect.com/science/article/pii/0167642387900359
• •Shneiderman, B. (1996). The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations. Proc. IEEE VL'96. — https://ieeexplore.ieee.org/document/545307
• •Becker, R. A. & Cleveland, W. S. (1987). Brushing Scatterplots. Technometrics, 29(2), 127–142. — https://doi.org/10.1080/00401706.1987.10488204
• •Roberts, J. C. (2007). State of the Art: Coordinated & Multiple Views in Exploratory Visualization. Proc. CMV'07 (IEEE). — https://doi.org/10.1109/CMV.2007.20
• •Alexander, C., Ishikawa, S. & Silverstein, M. (1977). A Pattern Language. Oxford University Press. — https://global.oup.com/academic/product/a-pattern-language-9780195019193
• •Tidwell, J., Brewer, C. & Valencia, A. (2020). Designing Interfaces (3rd ed.). O'Reilly. — https://www.oreilly.com/library/view/designing-interfaces-3rd/9781492051954/
• •web.dev. Cumulative Layout Shift (CLS). — https://web.dev/articles/cls
• •W3C APG. Developing a Keyboard Interface. — https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/

Прототипирование, процесс, метрики (§6)

• •Design Council. The Double Diamond. — https://www.designcouncil.org.uk/our-resources/the-double-diamond/
• •Stanford d.school. Design Thinking Process Guide. — https://web.stanford.edu/~mshanks/MichaelShanks/files/509554.pdf
• •ISO 9241-210:2019. Human-centred design for interactive systems. — https://www.iso.org/standard/77520.html
• •Gothelf, J. & Seiden, J. (2013). Lean UX. O'Reilly. — https://www.oreilly.com/library/view/lean-ux/9781449366834/
• •Knapp, J. et al. (2016). Sprint. GV. — https://www.gv.com/sprint/
• •Cagan, M. / SVPG. Dual-Track Agile. — https://www.svpg.com/dual-track-agile/
• •Rettig, M. (1994). Prototyping for Tiny Fingers. CACM 37(4), 21–27. — https://cacm.acm.org/opinion/prototyping-for-tiny-fingers/
• •Walker, M., Takayama, L. & Landay, J. (2002). High-Fidelity or Low-Fidelity, Paper or Computer? HFES Proc. 46, 661–665. — https://www.leilatakayama.org/downloads/Takayama.Prototypes_HFES2002_prepress.pdf
• •Virzi, R. A., Sokolov, J. L. & Karis, D. (1996). Usability Problem Identification Using Both Low- and High-Fidelity Prototypes. Proc. CHI'96. — https://dl.acm.org/doi/10.1145/238386.238516 · обзор: https://measuringu.com/prototype-fidelity/
• •Figma release notes — https://www.figma.com/release-notes/ · Play → Apple (2026) — https://www.macrumors.com/2026/06/29/apple-acquires-award-winning-app-play/ · Adobe XD, официальная позиция Adobe (maintenance mode) — https://community.adobe.com/t5/adobe-xd-discussions/xd-is-in-maintenance-mode-does-that-mean-adobe-is-discontinuing-the-app/m-p/14668530 · UXPin Merge — https://www.uxpin.com/merge/developers · Penpot — https://penpot.app/
• •Style Dictionary (DTCG) — https://styledictionary.com/info/dtcg/
• •Nielsen, J. (2000). Why You Only Need to Test with 5 Users; Nielsen & Landauer (1993), INTERCHI'93. — https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ · https://dl.acm.org/doi/10.1145/169059.169166
• •Faulkner, L. (2003). Beyond the five-user assumption. Behavior Research Methods, 35(3). — https://link.springer.com/article/10.3758/BF03195514
• •Medlock, M. et al. (2002). Using the RITE method. UPA. — https://www.jpattonassociates.com/wp-content/uploads/2015/04/rite_method.pdf
• •Brooke, J. (1996). SUS: A quick and dirty usability scale. — https://measuringu.com/sus/
• •Rodden, K., Hutchinson, H. & Fu, X. (2010). Measuring the User Experience on a Large Scale (HEART). CHI'10. — https://dl.acm.org/doi/10.1145/1753326.1753687
• •Nielsen, J. Thinking Aloud: The #1 Usability Tool. — https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/
• •Storybook — https://storybook.js.org/ · Supernova — https://www.supernova.io/blog/storybook-for-designers-why-its-more-than-just-a-dev-tool

Будущее интерфейсов (§7)

• •Weiser, M. (1991). The Computer for the 21st Century. Scientific American, 265(3), 94–104. — https://dl.acm.org/doi/10.1145/329124.329126
• •Weiser, M. & Brown, J. S. (1996/1997). The Coming Age of Calm Technology. В кн. Beyond Calculation. Springer. — https://link.springer.com/chapter/10.1007/978-1-4612-0685-9_6
• •Case, A. (2015). Calm Technology: Principles and Patterns for Non-Intrusive Design. O'Reilly. — https://calmtech.com/
• •Krishna, G. (2015). The Best Interface Is No Interface. New Riders. — https://www.nointerface.com/
• •Ishii, H. & Ullmer, B. (1997). Tangible Bits. CHI'97. — https://dl.acm.org/doi/10.1145/258549.258715
• •Norman, D. & Nielsen, J. (2010). Gestural Interfaces: A Step Backward in Usability. interactions, 17(5). — https://dl.acm.org/doi/10.1145/1836216.1836228
• •Shapiro, A. (2015). The Next Big Thing in Design? Fewer Choices. Fast Company. — https://www.fastcompany.com/3045039/the-next-big-thing-in-design-fewer-choices
• •Horvitz, E. (1999). Principles of Mixed-Initiative User Interfaces. CHI'99. — https://dl.acm.org/doi/10.1145/302979.303030
• •Tennenhouse, D. (2000). Proactive Computing. CACM, 43(5). — https://dl.acm.org/doi/10.1145/332833.332837
• •Luger, E. & Sellen, A. (2016). «Like Having a Really Bad PA»: The Gulf between User Expectation and Experience of Conversational Agents. CHI'16. — https://dl.acm.org/doi/10.1145/2858036.2858288
• •Parasuraman, R., Sheridan, T. & Wickens, C. (2000). A Model for Types and Levels of Human Interaction with Automation. IEEE Trans. SMC-A, 30(3), 286–297. — https://ieeexplore.ieee.org/document/844354
• •Parasuraman, R. & Riley, V. (1997). Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 39(2), 230–253. — https://journals.sagepub.com/doi/10.1518/001872097778543886
• •Lee, J. D. & See, K. A. (2004). Trust in Automation: Designing for Appropriate Reliance. Human Factors, 46(1), 50–80. — https://journals.sagepub.com/doi/10.1518/hfes.46.1.50_30392
• •Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775–779. — https://www.sciencedirect.com/science/article/abs/pii/0005109883900468
• •Endsley, M. R. (1995). Toward a Theory of Situation Awareness in Dynamic Systems. Human Factors, 37(1), 32–64. — https://journals.sagepub.com/doi/10.1518/001872095779049543
• •Gajos, K. & Weld, D. (2004). SUPPLE: Automatically Generating User Interfaces. IUI'04. — https://dl.acm.org/doi/10.1145/964442.964461
• •Gajos, K., Wobbrock, J. & Weld, D. (2008). Improving the Performance of Motor-Impaired Users with Automatically-Generated, Ability-Based Interfaces. Proc. CHI'08. — https://dl.acm.org/doi/10.1145/1357054.1357250
• •Gajos, K., Weld, D. & Wobbrock, J. (2010). Automatically Generating Personalized User Interfaces with Supple. Artificial Intelligence, 174(12–13). — https://www.sciencedirect.com/science/article/pii/S0004370210000822
• •Bansal, G. et al. (2021). Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance. Proc. CHI'21. — https://dl.acm.org/doi/10.1145/3411764.3445717
• •Buçinca, Z., Malaya, M. & Gajos, K. (2021). To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI. PACM HCI 5(CSCW1). — https://dl.acm.org/doi/10.1145/3449287
• •Vaithilingam, P., Zhang, T. & Glassman, E. (2022). Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by LLMs. CHI EA'22. — https://dl.acm.org/doi/10.1145/3491101.3519665
• •Barke, S., James, M. B. & Polikarpova, N. (2023). Grounded Copilot: How Programmers Interact with Code-Generating Models. PACMPL 7(OOPSLA1). — https://dl.acm.org/doi/10.1145/3586030
• •Ziegler, A. et al. (2024). Measuring GitHub Copilot's Impact on Productivity. CACM, 67(3), 54–63. — https://dl.acm.org/doi/10.1145/3633453
• •Findlater, L. & McGrenere, J. (2004). A Comparison of Static, Adaptive, and Adaptable Menus. CHI'04. — https://dl.acm.org/doi/10.1145/985692.985704
• •Sutherland, I. (1968). A Head-Mounted Three Dimensional Display. AFIPS FJCC. — https://dl.acm.org/doi/10.1145/1476589.1476686
• •Milgram, P. & Kishino, F. (1994). A Taxonomy of Mixed Reality Visual Displays. IEICE Trans., E77-D(12). — https://search.ieice.org/bin/summary.php?id=e77-d_12_1321
• •Marriott, K. et al. (eds.) (2018). Immersive Analytics. Springer LNCS 11190. — https://link.springer.com/book/10.1007/978-3-030-01388-2
• •Biener, V. et al. (2022). Quantifying the Effects of Working in VR for One Week. IEEE TVCG. — https://arxiv.org/abs/2206.03189
• •Apple. Designing for visionOS. HIG. — https://developer.apple.com/design/human-interface-guidelines/designing-for-visionos
• •Microsoft. Dynamics 365 Remote Assist. — https://dynamics.microsoft.com/en-us/mixed-reality/remote-assist/
• •Bolt, R. (1980). «Put-That-There»: Voice and Gesture at the Graphics Interface. SIGGRAPH'80. — https://dl.acm.org/doi/10.1145/800250.807503
• •Oviatt, S. (1999). Ten Myths of Multimodal Interaction. CACM, 42(11), 74–81. — https://dl.acm.org/doi/10.1145/319382.319398
• •Jacob, R. J. K. (1990). What You Look at Is What You Get: Eye Movement-Based Interaction Techniques. CHI'90. — https://dl.acm.org/doi/10.1145/97243.97246
• •Wolpaw, J. R. et al. (2002). Brain–Computer Interfaces for Communication and Control. Clinical Neurophysiology, 113(6), 767–791. — https://www.sciencedirect.com/science/article/abs/pii/S1388245702000573
• •Zander, T. O. & Kothe, C. (2011). Towards Passive Brain–Computer Interfaces. Journal of Neural Engineering, 8(2). — https://iopscience.iop.org/article/10.1088/1741-2560/8/2/025005
• •CopilotKit (2026). The Developer's Guide to Generative UI. — https://www.copilotkit.ai/blog/the-developer-s-guide-to-generative-ui-in-2026

---

Конец меморандума. Диаграммы Mermaid и таблицы редактируемы вместе с текстом. При переносе в корпоративную вики или PDF рекомендуется сохранить инлайн-ссылки на первоисточники — они и есть доказательная база каждого тезиса.