База знаний HIF

Версия: 0.2

1. Назначение

База знаний HIF — поддерживаемый корпус знаний для проектирования, реализации, оценки и управления пользовательскими интерфейсами. Она охватывает операционные системы, приложения, сайты, сервисы, документацию, административные инструменты, киоски, разговорные системы, AI-взаимодействие и будущие формы интерфейсов.

Это не галерея модных решений. HIF разделяет:

1. возможности и ограничения человека;
2. нормативные права и гарантии;
3. модели взаимодействия и информации;
4. визуальное, содержательное и поведенческое выражение;
5. платформенные и доменные соглашения;
6. системы реализации;
7. доказательства качества;
8. правовой governance, права и платформенные референсы;
9. операционную и коммерческую практику.

2. Архитектура знаний

Слой A — Основания

• философия и модель человека;
• HCI, эргономика и human-centred design;
• восприятие, познание, память, внимание и моторное действие;
• situated action, distributed cognition и activity theory;
• этика исследований и качество доказательств.

Слой B — Универсальный контракт

• Конституция интерфейса;
• доступность и инклюзивность;
• приватность, безопасность, человеческая агентность и доверие;
• требования к автоматизации и AI;
• нормативный словарь и порядок исключений.

Слой C — Модели

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

Слой D — Выражение

• типографика, цвет, пространство, изображения, звук, haptics и motion;
• responsive- и adaptive-композиция;
• компоненты, паттерны и дизайн-токены;
• локализация и двунаправленное содержание.

Слой E — Профили

• оболочка операционной системы;
• desktop- и mobile-приложение;
• web-продукт и транзакционный сервис;
• документация, builder, installer, recovery и kiosk;
• terminal, conversational, AI, spatial, retro и white-label.

Слой F — Инженерия

• архитектура и governance дизайн-системы;
• семантические API и контракты компонентов;
• content- и token-конвейеры;
• платформенные соглашения и совместимость;
• контрольные этапы качества и управление выпусками.

Слой G — Доказательства

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

Слой H — Профессиональная практика

• аудит клиентского сайта;
• воспроизводимые результаты проверки и приоритизация;
• проектирование и реализация исправлений;
• приёмка, повторная и регрессионная проверка;
• ответственные заявления, параметры цены и конфликт интересов.

Слой I — Право и управление правами

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

3. Политика источников

Источник HIF MUST быть прослеживаем до англоязычного оригинала. Приоритет:

1. действующий стандарт или спецификация выпускающего органа;
2. оригинальная рецензируемая статья или авторская монография;
3. официальная документация платформы, браузера или дизайн-системы;
4. официальное руководство публичного сервиса с описанной исследовательской практикой;
5. оригинальный технический отчёт или набор данных ответственной организации.

Вторичная статья, перевод, поисковая выдача или чек-лист без источников MAY помочь найти первоисточник, но MUST NOT служить доказательной основой нормативного требования HIF.

Наличие источника не делает утверждение универсальным. Для переносимого утверждения MUST учитываться популяция, задача, контекст, дата, метод и ограничения исследования.

4. Классы утверждений

Числа MUST NOT объявляться универсальными порогами, если стандарт не определяет их для заявленной области. Результаты эвристической проверки MUST NOT выдаваться за нарушения соответствия.

5. Навигация по корпусу

Начните с Философии и Конституции. Выберите профиль продукта, опишите продукт через модель взаимодействия, затем определите информацию, содержание, основания дизайна, визуальный язык и компоненты системы. Для выразительных решений применяйте отдельные документы о цвете, типографике, компоновке, адаптации, изображениях, движении, визуализации данных и бренде, затем проведите дизайн-ревью. До реализации примените правила права, IP и платформенных референсов и создайте требуемые записи очистки прав и выпуска. Планируйте обеспечение доступности по документу Доступность и инклюзивность, а доказательства выпуска сохраняйте в Реестре обеспечения доступности и соответствия. Планируйте оценку до реализации и поддерживайте трассировку от пользовательской потребности к требованию, решению, реализации, тесту и эксплуатационным данным.

Для существующего клиентского сайта начните с методики веб-аудита, примените тест-дизайн, оформите результат через шаблон отчёта, заполните реестр обеспечения доступности, если доступность входит в область проверки, и проверьте исправления тем же корпусом задач и критериями приёмки.

6. Поддержка

Каждый документ MUST указывать версию или наследовать версию корпуса. Существенное изменение требует:

• изменяемое утверждение или требование;
• причину и доказательства;
• затронутые профили и тесты;
• влияние на миграцию и совместимость;
• проверившего и дату пересмотра.

Живые и версионируемые источники MUST пересматриваться не реже раза в год. Платформенные правила и пороги качества веб-интерфейсов SHOULD проверяться перед каждым аудитом.

Источники

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C — Website Accessibility Conformance Evaluation Methodology
• ISO — ISO 9241-210: Human-centred design for interactive systems
• Google Research — HEART: user-centred metrics for web applications
• NIST — Human-Centered Cybersecurity