Компоненты · Средняя
Описать матрицу состояний компонента
Зафиксировать, как компонент выглядит и ведет себя в состояниях default, hover, focus, loading, disabled, empty, error и success.
Быстро понять за 2 минуты
Зафиксировать, как компонент выглядит и ведет себя в состояниях default, hover, focus, loading, disabled, empty, error и success. На выходе: критичные состояния компонента описаны и реализованы.
Контекст
Пункт относится к этапу «Компоненты». Его задача — превратить рабочее действие в проверяемый результат. Он нужен до передачи результата QA, дизайнеру и владельцу продукта: иначе команда рискует реализовать только красивое default-состояние.
Что это дает
Матрица состояний делает компонент предсказуемым. Дизайнер, разработчик и QA одинаково понимают, что проверять, а пользователь не сталкивается с “мертвыми” кнопками или непонятными ошибками.
Как выполнить
- Перечислите состояния компонента и условия перехода между ними.
- Проверьте текст, иконки, доступность, aria-атрибуты и поведение клавиатуры.
- Добавьте примеры состояний в Storybook или локальную страницу компонентов.
Критерии приемки
- Критичные состояния компонента описаны и реализованы.
- Disabled, loading и error не выглядят как обычное активное состояние.
- QA может проверить компонент без догадок.
Типичные ошибки
- Реализовать только красивое default-состояние.
- Не показывать пользователю причину ошибки.
- Ломать размер компонента при loading или длинном тексте.
Инструменты
Рабочий артефакт
UI inventory
Матрица состояний компонента
Пример для разработки пользовательского интерфейса: специалист начинает с действия «Перечислите состояния компонента и условия перехода между ними». Затем фиксирует результат в рабочем артефакте и передает его команде. Пункт считается выполненным только когда выполнено условие: «Критичные состояния компонента описаны и реализованы».
- Components
- Variants
- Duplication
- Design tokens
Контроль качества
Карта компонентов
Критичные состояния компонента описаны и реализованы.
После изменения пользовательского сценария, дизайна, API-контрактов, релизов и замечаний по доступности.
Сценарий, состояние интерфейса, источник данных, критерии доступности, тесты и ограничения адаптива.
Перед отметкой выполнено: Критичные состояния компонента описаны и реализованы.
Как применять
Начинайте с пользовательского действия и состояния интерфейса. Затем проверьте данные, адаптивность, доступность, ошибки и производительность. Хороший frontend-пункт помогает понять, что увидит пользователь, как интерфейс поведет себя в крайних состояниях и чем подтверждается качество реализации.
Режим обучения
Тест по теме
Проверка понимания
Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.