HIF / Документация / Доказательства

Оценка и соответствие HIF

1. Основной принцип

Интерфейс оценивается не по количеству реализованных компонентов и не по сходству с макетом. Оценка отвечает на вопросы:

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

2. Лестница доказательств

Методы дают разные виды доказательств.

E0. Декларация

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

E1. Проверка дизайна

Проверены модель, flows, states и макеты.

E2. Static/automated verification

Проверены types, schema, lint, semantics, contrast, builds и contract tests.

E3. Интерактивная экспертная проверка

Эксперт выполняет реальные задачи, проверяет клавиатурные сценарии и доступность.

E4. Representative user evaluation

Люди из целевой аудитории выполняют задачи в близком контексте.

E5. Эксплуатационные доказательства

Используются production signals, support data, incidents и longitudinal research.

Высокорисковая функция требует более высокого уровня доказательств.

3. Метрики

3.1. Effectiveness

task success;
корректность результата;
критические ошибки;
recovery rate;
сохранность данных.

3.2. Efficiency

время;
число содержательных действий;
ожидание;
повторная работа;
expert throughput.

3.3. Understanding

prediction результата;
различение объектов и состояний;
понимание сохраняемости;
понимание границ и прав;
точная ментальная модель.

3.4. Learnability

first-attempt success;
improvement;
retention;
transfer между представлениями;
discoverability shortcuts.

3.5. Доступность

выполнение с клавиатуры;
выполнение с программой экранного доступа;
масштабирование и перекомпоновка;
forced colors;
reduced motion;
non-drag alternative;
error recovery с assistive technology.

3.6. Trust and agency

perceived control;
соответствие ожиданий фактическому эффекту;
понимание automation;
ability to refuse;
absence of coercion;
confidence calibrated to actual system reliability.

4. Task corpus

Каждый продукт создаёт набор задач:

TASK-ID
goal
starting state
actor and permissions
context/devices
success state
critical errors
применимые требования Конституции интерфейса
необходимые доказательства

Тестируется задача, а не экскурсия по экрану.

Обязательные классы:

ориентация;
создание;
изменение;
поиск;
сравнение;
сохранение;
удаление;
восстановление;
permission boundary;
error;
interruption;
cross-device/context;
automation.

5. Методы

5.1. Проверка модели

Проверяются:

object model;
commands;
state machine;
permissions;
persistence;
failure modes;
audit.

5.2. Эвристическая проверка

Используется Конституция, применимый профиль и доменные критерии. Общий список эвристик не заменяет проверку предметной области.

5.3. Predictive modeling

Fitts, Hick—Hyman, KLM/GOMS и другие модели применяются только при соблюдении их предпосылок.

5.4. Prototype evaluation

Точность прототипа должна соответствовать вопросу. Бумажный прототип не доказывает производительность, поведение фокуса или программы экранного доступа.

5.5. Usability study

Определяются участники, задачи, success criteria, neutral moderation и способ анализа. Малое исследование обнаруживает проблемы, но не доказывает статистическое превосходство.

5.6. Оценка доступности

Automated, manual, AT и disabled-user research объединяются.

5.7. Field and telemetry

Telemetry собирается только при законном основании, минимально и прозрачно. Behavioral metric не интерпретируется без контекста.

6. Severity

S0 Blocker — задача невозможна, потеря контроля/данных, критический риск.
S1 Critical — высокая вероятность существенного вреда или исключения.
S2 Major — задача выполнима с серьёзным затруднением.
S3 Moderate — заметная проблема понимания или эффективности.
S4 Minor — локальная несогласованность.
Observation — гипотеза, не подтверждённый defect.

Барьер доступности оценивается по исключённой функции и аудитории, а не по визуальной заметности.

7. Уровни соответствия

HIF-Declared

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

Это начало процесса, не знак качества.

HIF-Conformant

все применимые MUST выполнены;
SHOULD exceptions обоснованы;
пройдены автоматические и экспертные проверки;
исходный уровень доступности подтверждён.

HIF-Validated

выполнено HIF-Conformant;
ключевые задачи проверены с репрезентативными пользователями;
сценарии высокого риска имеют достаточные доказательства;
эксплуатационный мониторинг определён.

Продукт MUST указывать версию HIF и профиль, к которым относится заявление.

8. Матрица трассировки

UIC requirement
→ product requirement
→ object/command/component
→ automated check
→ manual scenario
→ исследовательская задача
→ текущие доказательства
→ исключения

Требование без способа проверки считается неполным.

9. Контрольный этап перед выпуском

Перед выпуском:

область изменения определена;
затронутые задачи перечислены;
states и failure modes реализованы;
применимые MUST пройдены;
проверки типов, сборки, контрактов и сквозных сценариев пройдены;
клавиатурное управление и доступность проверены вручную;
команды высокого риска проверены отдельно;
содержание и документация актуальны;
исключения имеют ответственного и срок;
откат и восстановление определены.

Визуальное утверждение не заменяет контрольный этап перед выпуском.

10. Design exception

Исключение содержит:

ID
HIF version and requirement
product/profile
reason
affected users/tasks
risk
альтернатива
ответственный
срок действия/дата пересмотра
доказательства

Expired exception блокирует новое заявление о соответствии, пока не пересмотрено.

11. Изменение стандарта

Если продукт не может выполнить HIF:

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

Популярность локального workaround не является доказательством правильности общего правила.