Live-score и матчевые карточки

Счёт должен читаться за секунду: анатомия хорошей live-score карточки

Макет с пятью уровнями визуального веса. Задача — передать текущий результат за одно фиксирование взгляда. Компонент — live-score карточка.

Большой экран стадиона с сообщением о голе

Карточка матча работает как информационный интерфейс, а не как иллюстрация. Apple HIG определяет Live Activities как компактный слой с изменяющимися данными. Material Design 3 задаёт карточкам чёткую иерархию: контейнер разделяет контент на уровни значимости. Обе системы сходятся в одном — первичный сигнал не конкурирует с вторичным.

Счёт — самый громкий слой

Цифры счёта — единственный элемент, который получает максимальный контраст по весу. Кегль в 3–4 раза больше основного текста. Начертание — только жирное или экстра-жирное.

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

Расположение счёта — по центру или с отступом от названий команд. Горизонтальная компоновка «команда — счёт — команда» требует выравнивания названий по базовой линии цифр. Вертикальная компоновка «команда над командой, счёт между ними» экономит ширину, но увеличивает высоту.

Ошибка: счёт набран тем же кеглем, что и название команды. Глаз сканирует строку целиком и не фиксирует результат. Улучшение: увеличить кегль счёта до доминирующего значения в карточке.

Статус матча не должен спорить с цифрами

Статус — «LIVE», «Перерыв», «Завершён» — работает как флаг состояния. По спецификации Material Design 3 такие метки относятся к вспомогательным элементам карточки.

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

Ошибка: статус «LIVE» занимает всю ширину карточки и визуально давит на счёт. Улучшение: перенести статус в угол или надписать над счётом мелким кеглем с фоновым пятном.

Период — «1-й тайм», «3-я четверть» — присоединяется к статусу или выносится отдельной строкой. Не объединяйте период и время в одну строку без разделителя.

Время требует собственного ритма

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

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

Ошибка: время набрано тем же кеглем, что и счёт. При быстром сканировании пользователь путает 45:00 с результатом 4:5. Улучшение: чёткое разделение по кеглю и расположению.

Тикер времени обновляется дискретно. Плавная анимация цифр уместна только при переходе между состояниями, а не внутри одной секунды.

Вторичные данные уходят в раскрытие

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

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

Статистика матча, авторы голов, фолы — скрыты за тапом или свайпом. Material Design 3 определяет такой паттерн как «расширенная карточка». Свернутая форма показывает только счёт, статус и время.

Ошибка: в свернутой карточке видны авторы голов и possession. Плотность данных мешает считывать результат. Улучшение: убрать всё, кроме счёта, статуса, времени и названий.

Какие элементы являются первичными?

Первичный набор: score, team name, clock, status, period. Пять элементов. Всё остальное — второй уровень.

Иерархия по визуальному весу: счёт — время — статус — название — период. Именно в таком порядке глаз фиксирует информацию при первом взгляде.

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

На малом экране эффект меняется. Горизонтальная компоновка может не поместиться. Вертикальная — вытянуть карточку за пределы экрана. Адаптация требует отдельного разбора, который мы даём в материале про responsive live score design. Состояния интерфейса — загрузка, ошибка данных, задержка трансляции — описаны в статье про состояния live score интерфейса.

Ошибка: полагаться только на цвет для передачи статуса. Красная точка вместо надписи «LIVE» теряется при монохромном режиме. Улучшение: дублировать статус текстовой меткой.

Три правила для макета

Первое: счёт получает максимальный кегль и жирное начертание. Ни один элемент карточки не конкурирует с ним по весу.

Второе: время, статус и период занимают фиксированные позиции с заданной шириной блока. Обновление значений не сдвигает соседние элементы.

Третье: вторичные данные скрыты по умолчанию. Свернутая карточка содержит только пять первичных элементов.

Для продолжения этого маршрута есть материал: «клубная айдентика в цифровом интерфейсе».

Отдельно полезно сверить материал: «доступность спортивной инфографики цвет».

Проверьте макет одним критерием: закройте названия команд рукой. Если по оставшимся цифрам и меткам понятно, кто ведёт и идёт ли матч — иерархия выстроена верно.

Проверка компонента в системе

Когда «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» переносится между широким экраном и телефоном, «Вторичные данные уходят в раскрытие» нельзя просто уменьшить вместе с «Какие элементы являются первичными?». У компонентов разные задачи и разные минимальные размеры для чтения. Один может уйти во второй уровень, другой должен остаться видимым постоянно. Поэтому ответ на «Какие элементы являются первичными?» начинается с определения обязательного сигнала, после чего второстепенные подписи, иконки и декоративные элементы сокращаются без потери смысла.

Для спортивной графики пара «Какие элементы являются первичными?» и «Счёт — самый громкий слой» задаёт полезный стресс-тест. В статье «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» макет должен сохранять смысл при длинных фамилиях, локализации, увеличенном шрифте, отсутствии цвета и узкой ширине. Если компонент работает только в идеальном примере, это демонстрация, а не система. Вопрос «Что можно спрятать во второй уровень?» поэтому связан не с украшением, а с тем, какую информацию пользователь сможет распознать первой и без дополнительного объяснения.

В интерфейсе из материала «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» элементы «Счёт — самый громкий слой» и «Статус матча не должен спорить с цифрами» конкурируют за одно и то же внимание. Если оба получают одинаковый визуальный вес, пользователь медленнее считывает главный спортивный сигнал. Поэтому сначала определяется приоритет данных, затем размер, контраст и положение компонента, а декоративные признаки подстраиваются под эту иерархию. Вопрос «Какие элементы являются первичными?» здесь решается через скорость чтения и устойчивость макета на самом тесном экране.

Раздел «Статус матча не должен спорить с цифрами» полезно сопоставить с «Время требует собственного ритма» именно как две части одной дизайн-системы. Для темы «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» хороший результат означает, что изменение одного компонента не разрушает соседний: длинное имя не выталкивает счёт, новый статус не маскирует время, а фирменный цвет не становится единственным носителем смысла. Такая проверка сильнее красивого desktop-макета, потому что показывает поведение компонента при реальных ограничениях.

Когда «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» переносится между широким экраном и телефоном, «Время требует собственного ритма» нельзя просто уменьшить вместе с «Вторичные данные уходят в раскрытие».

Для спортивной графики пара «Вторичные данные уходят в раскрытие» и «Какие элементы являются первичными?» задаёт полезный стресс-тест.

В интерфейсе из материала «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» элементы «Какие элементы являются первичными?» и «Счёт — самый громкий слой» конкурируют за одно и то же внимание.

Раздел «Счёт — самый громкий слой» полезно сопоставить с «Статус матча не должен спорить с цифрами» именно как две части одной дизайн-системы.

Когда «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» переносится между широким экраном и телефоном, «Статус матча не должен спорить с цифрами» нельзя просто уменьшить вместе с «Время требует собственного ритма».

Поведение системы в реальных данных

Для интерфейса из «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» раздел «Статус матча не должен спорить с цифрами» задаёт визуальный приоритет, а «Вторичные данные уходят в раскрытие» показывает, выдерживает ли его компонент при реальных данных. «Время требует собственного ритма» добавляет вторую проверку: пользователь должен отличать изменение состояния от постоянной характеристики команды или игрока. Вопрос «Что можно спрятать во второй уровень?» поэтому связан с порядком чтения. Сначала взгляд получает основное значение, затем контекст и только потом украшение. Если логотип, цвет или анимация перехватывают внимание раньше данных, иерархия нарушена. На мобильном экране это проявляется особенно быстро, потому что места для параллельных акцентов почти нет.

Дизайн-система в статье «Счёт должен читаться за секунду: анатомия хорошей live-score карточки» должна одинаково объяснять «Время требует собственного ритма», «Вторичные данные уходят в раскрытие» и «Какие элементы являются первичными?», но не делать эти элементы визуально одинаковыми. У каждого своя роль: один сообщает состояние, другой идентифицирует объект, третий помогает сравнить значения. Вопрос «Какие элементы являются первичными?» полезно решать через тест без декоративного слоя. Если после отключения фирменных цветов и второстепенных иконок смысл остаётся понятным, структура сильная. Если исчезает различие между статусами или невозможно понять, к какой команде относится число, компонент слишком зависит от оформления и требует переработки.

Читайте также