HIF / Документация / Контроль дизайна

Дизайн-ревью и критика

Статус: нормативный операционный метод

Версия: 0.1

Документ определяет, как команда исследует дизайн, отделяет доказательства от предпочтений, принимает обоснованные и прослеживаемые решения и превращает замечания в проверяемые действия.

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

Дизайн-ревью — не суд вкуса, не презентационный ритуал и не голосование стейкхолдеров. Оно нужно, чтобы:

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

Критика оценивает работу, а не ценность или талант её автора.

2. Четыре класса высказываний

Каждому комментарию СЛЕДУЕТ указывать класс:

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

Пример:

Наблюдение:
Элемент подтверждения и ссылка отмены имеют одинаковые насыщенность и цвет.

Вывод:
При дефиците времени люди могут не различить обязательство и безопасный выход.

Суждение:
Это противоречит требованию показывать последствие до подтверждения.

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

Фраза «что-то не так» может начать исследование, но недостаточна как замечание, блокирующее выпуск.

3. Входные данные

Владелец предоставляет пакет, соответствующий решению:

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

Отсутствие материала само по себе является замечанием, если мешает обоснованному суждению. Комиссия НЕ ДОЛЖНА выдумывать потребности или политику, чтобы заполнить пробел.

4. Роли и независимость

Типичные роли:

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

Докладчику НЕ СЛЕДУЕТ одновременно фасилитировать и вести запись. В последовательных проверках НУЖНЫ участники, не отвечавшие за дизайн. Доступность, содержание, исследования и инженерную оценку нельзя заменять догадкой визуального дизайнера.

Конфликты интересов, включая аудитора, продающего исправление, ДОЛЖНЫ быть раскрыты.

5. Уровни ревью

Уровень	Цель	Подходящий материал	Результат
студийная критика	исследовать направление и улучшить ремесло	эскизы или альтернативы	гипотезы и следующая итерация
дизайн-ревью	проверить связность и требования	реалистичный путь или прототип	замечания и решения
специальное ревью	проверить дисциплину или опасность	доступная реализация или спецификация	специальные доказательства
ревью реализации	сравнить продукт с контрактом	интегрированная сборка	дефекты и отклонения
проверка выпуска	решить готовность и остаточный риск	кандидат на выпуск с доказательствами	решение контрольного этапа
эксплуатационная проверка	учиться на реальном использовании	телеметрия, инциденты, исследования и поддержка	корректирующие изменения

Материал низкой точности НЕЛЬЗЯ использовать для закрытия вопросов о рендеринге, взаимодействии, ассистивной технологии, производительности или эксплуатации.

6. Многопроходный протокол

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

Проход 1: намерение и контекст

Кто действует, с какой целью и в каких условиях?
Какое решение рассматривается?
Какие ограничения зафиксированы, а какие обсуждаемы?
Как выглядят успех, отказ и вред?

Проход 2: смысл и полномочия

Правдиво ли представлены объекты, действия, состояния и владение?
Можно ли проверить область, разрешения, происхождение и последствия?
Обещает ли интерфейс операцию, которую система не гарантирует?
Различимы и управляемы ли автоматические или AI-действия?

Проход 3: содержание и информационная архитектура

Соответствует ли терминология предметной области и аудитории?
Можно ли найти, сравнить и понять нужную информацию?
Конкретны ли подписи, инструкции, ошибки и восстановление?
Связны ли поиск, навигация и история на всём пути?

Проход 4: взаимодействие и состояние

Обнаружимы, предсказуемы и вовремя ли доступны команды?
Заданы ли loading, empty, partial, offline, error, success и stale states?
Определены ли прерывание, back, undo, retry и безопасный выход?
Сохраняют ли функцию клавиатура, указатель, touch и альтернативные способы ввода?

Проход 5: восприятие и выразительность

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

Проход 6: доступность и адаптация

Согласованы ли семантика и порядок чтения с визуальной структурой?
Работает ли продукт при zoom, reflow, text spacing, forced colours, dark и high-contrast modes, reduced motion и пользовательских настройках?
Покрыты ли языки, направления письма и крайние варианты содержания?
Запланированы или получены ли данные ассистивных технологий и людей с инвалидностью?

Проход 7: реализация и эксплуатация

Заданы ли компоненты, токены, состояния и адаптивные правила?
Лицензированы, атрибутированы, производительны и прослеживаемы ли ассеты?
Спроектированы ли безопасность, privacy, отказ, наблюдаемость и support?
Можно ли тестировать, поддерживать, мигрировать и откатывать результат?

Проход 8: доказательства и решение

Какие наблюдения являются фактами, а какие гипотезами?
Какие пороги достигнуты?
Что неизвестно и насколько решение чувствительно к этому?
Каковы действие, владелец, срок и метод проверки?

7. Структура замечания

Каждое замечание, по которому можно действовать, содержит:

FINDING-ID
область и затронутое состояние
наблюдение и воспроизведение
ожидаемый критерий
последствие для человека или системы
доказательства и уверенность
тяжесть и обоснование
желаемый результат, а не обязательное косметическое решение
ответственный и срок
метод проверки
связанное требование, компонент или токен

Снимки экрана МОГУТ подкреплять замечание, но НЕ ДОЛЖНЫ заменять воспроизведение, состояние взаимодействия или доступные доказательства.

8. Тяжесть — не предпочтение

Тяжесть складывается из:

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

Визуальная новизна, должность стейкхолдера, стоимость реализации и ожидаемая выручка от исправления НЕ ДОЛЖНЫ повышать тяжесть. Усилие и коммерческая ценность — отдельные измерения приоритета.

Предлагаемые классы результата:

блокирующий — недопустимый отказ безопасности, прав, доступности или основной задачи;
major — существенный отказ с серьёзным последствием или без разумного восстановления;
moderate — повторяющееся трение, ошибка или потеря понимания с восстановлением;
minor — ограниченная несогласованность или ремесленный дефект с малым последствием;
hypothesis — правдоподобная проблема, требующая различающего доказательства;
preference — необязательный эстетический выбор внутри допустимого пространства.

9. Язык критики

Полезная форма:

Для [человека/задачи/контекста]
текущее [наблюдаемое свойство]
может вызвать [последствие],
потому что [механизм/доказательство].
Это противоречит [критерию].
Следует [желаемый результат или тест],
проверенный [методом и порогом].

Рецензентам СЛЕДУЕТ:

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

Рецензентам НЕЛЬЗЯ:

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

10. Сравнительное ревью

Существенное направление СЛЕДУЕТ сравнить хотя бы с одной правдоподобной альтернативой. Нужно использовать одинаковые:

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

Таблица сравнения МОЖЕТ содержать:

Критерий	Вес или приоритет	Вариант A	Вариант B	Доказательство	Неопределённость

Веса НЕЛЬЗЯ менять после получения результата. Оценка раскрывает компромисс, но не автоматизирует решение и не отменяет жёсткое ограничение.

11. Вопросы red team

Перед одобрением:

Как представление можно понять неверно?
Что будет с самым длинным, коротким, отсутствующим, устаревшим или враждебным содержанием?
Что будет при медленном, частичном, offline или противоречивом состоянии?
Кого исключает предполагаемое устройство, возможность, язык или опыт?
Может ли убеждающая иерархия подтолкнуть к нежелательному выбору?
Могут ли цвет, изображение, движение или звук создать ложные статус или срочность?
Что теряет эксперт? Что должен запомнить новый человек?
Что будет после прерывания, undo, истечения срока или передачи другому?
Ложность какого утверждения изменила бы решение?
Как эксплуатация покажет, что решение не работает?

12. Результаты решения

Лицо, принимающее решение, записывает один результат:

approve — пороги выполнены в указанной области;
approve with actions — у неблокирующих действий есть владельцы и проверка;
iterate — до нового ревью нужно изменение;
test — неопределённость слишком важна; получить заданные доказательства;
escalate — полномочие, политика или риск принадлежат другому уровню;
reject — направление не способно выполнить ограничение или результат;
exception — названное требование не выполнено; указаны владелец, доказательство, компенсация, срок и дата ревью.

«Выглядит хорошо» не является записью одобрения.

13. Запись ревью

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

Запись СЛЕДУЕТ хранить в истории решений продукта и связывать с требованиями, реализацией и тестами.

14. Передача на проверку качества дизайна

До реализации:

названы контракты компонентов и токенов;
заданы состояния, способы ввода, breakpoints и предпочтения;
доступны контентные правила и случаи локализации;
явны семантика доступности и ожидаемое клавиатурное поведение;
записаны источники, лицензии, преобразования и резервные варианты ресурсов;
к рабочим задачам прикреплены измеримые критерии приёмки.

До релиза:

реализация сравнена с одобренным артефактом;
отклонения явно приняты или исправлены;
проверены настоящее содержание и сочетания состояний;
visual regression дополнен семантическими и интерактивными тестами;
существуют нужные ручные, AT- и пользовательские доказательства;
у остаточного риска есть владелец и условие пересмотра.

15. Показатели качества ревью

Нужно измерять саму систему ревью:

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

Нельзя награждать рецензентов за объём комментариев. Цель — более качественные и безопасные решения с меньшим повторным расходом.