TTKQ · Interface Standards Design tokens, components and screen layout rules

This document turns the public TTKQ desktop and mobile sites into a functional baseline that product, design, engineering and QA can work from together. It is a structured analysis of the reference site plus the target requirements for building it — not a system audit performed with admin access, and not a pixel-level design hand-off.

Evidence was captured on 5 September 2026 from a logged-out desktop browser at 1440 × 1000 and a mobile browser at 390 × 844. Live content and scores were dynamic samples used only to confirm structure; they are not sports facts. The source site routes to www or m by User-Agent — a command-line request landing on the mobile site does not mean the desktop version is absent.

The four evidence tiers

Every screen section below is labelled with one of these. They are used consistently and they mean different things:

Section 01

Design direction and evidence boundary

The source site runs a bright yellow brand navigation, dark text, light grey page ground and white content panels. The home page leads with sports imagery and anchor cover cards; the score and data pages are dense tables built for scanning. Mobile uses two-column live cards, single-column match cards and a five-item bottom navigation.

Values marked measured below come from public CSS or computed styles. Values marked proposed are implementable, consistent design decisions. Sampling colors is not the same as recovering a complete design system: third-party components, campaign artwork and chart legends may still deviate locally. Source-site assets are analysis reference only — the shipped product must use its own marks, artwork and copy.

Section 02

Color and base variables

Use dark text on brand yellow — do not default yellow buttons to white text. Body text against its ground should meet 4.5:1, large text 3:1, and focus rings and meaningful icons 3:1. That is the target accessibility requirement; it does not assert the source site passes today.

Odds movement, errors, scores, cards and live status must each carry text or shape as well as color. Nothing may be distinguished by red-versus-green alone.

Section 03

Type, numerals and text rules

Names, truncation and units

Team names and anchor names must support Chinese, Latin script and emoji. Desktop tables may truncate a team name and reveal the full name on hover; mobile must keep the full name reachable through expansion or the detail page, because hover does not exist there. Cover titles wrap to two lines at most, one line in compact home rows. Dates, scores and status are never truncated.

Heat figures — 1w style and raw counts — must be formatted consistently within one platform, and must be labelled as heat, not as a real concurrent-viewer count.

Times render as HH:mm or MM-DD HH:mm; across a year boundary use YYYY-MM-DD. Label the data-update time and the kick-off time separately. Unknown values show an em dash; no results shows an empty state. A real zero must never be replaced by a placeholder.

Section 04

Layout grid and cross-platform rules

Proposed breakpoints: below 768px mobile, 768–1199px tablet, 1200px and up desktop. This is the target strategy; the source site mainly redirects by device UA. The list region and any overlay scroll independently, and only one primary vertical scroll is allowed at a time. Where a table genuinely must scroll sideways, show a scroll affordance and pin the identity column.

Section 05

Component library

Twenty-four components carry every screen in the product. Each entry lists the size baseline, the states a variant set must include, the interaction rules that are easy to get wrong, and the modules that consume it.

Section 06

Per-screen layout requirements

Section 07

Key page structure

These are structural sketches. They are not source-site screenshots and not pixel-level designs.

DESKTOP — HOME
┌ Brand │ Home  Scores  Live  Fixtures  Data  Video  News  App │ Account ┐
│              Hero carousel · Enter live room            │  Thumbnails  │
├                    Featured matches · horizontal cards                 ┤
├ Now streaming                                              See all →   ┤
│   Live card    Live card    Live card    Live card    Live card        │
├ Popular anchors  →  Football  →  Basketball  →  Other                  ┤
└ About · Terms                             Download banner · dismissible ┘

DESKTOP — LIVE ROOM
┌ Both teams · Time · Score │ Anchor identity and follow                  ┐
│                  Media area                    │  Chat   │   DM        │
│              Status layer and retry            │  Message list         │
│                                                │  Composer             │
├ Live data · 1X2 · Handicap · Over/Under        │  Upcoming fixtures    ┤
├ Recommended streams and source disclosure                              ┤

MOBILE — LIVE ROOM
┌ Back  Home  Match information                        Add to home screen ┐
│                        Media area                                       │
├ Chat │ Data │ Anchor │ Odds │ Analysis │ Streams │ DM   ← scrolls        ┤
│                    Active tab content                                   │
├                Composer / actions + safe area                           ┤

Section 08

Motion, touch and accessibility

• Motion. Ordinary hover and state changes 150–200ms; drawers 200–250ms. A score change highlights briefly, never longer than one second. Respect the system reduce-motion setting.
• Touch targets. Every mobile tap target should be at least 44 × 44px. A close icon that is visually 16px still needs an expanded transparent hit area — do not take the icon size from a screenshot and use it as the touch target.
• Focus. Tab order follows reading order. Opening a dialog moves focus to its title or first field; closing returns focus to the trigger. Escape closes non-destructive transient layers.
• Semantics. Tabs use the tab role and declare selection; inputs have real labels; icon buttons have names. Loading and errors announce through appropriate status regions — do not announce every score tick.
• Carousels. Auto-advance must be pausable, and must stop on hover or when keyboard focus enters. The player must be exitable from every mode and must never trap the system back gesture.
• Tables and chat. Cells associate with their column headers. A chat bubble reads in the order sender, time, content, status. A QR code exposes its target as alternative text.

Section 09

Global states and copy

These are target strings, not a transcription of the source site. Some of its prompts are terse or ambiguous and should be normalised during implementation — particularly the "Crown" alias mode, the suspended-odds marker, profile character limits, and the wording around group actions.

Section 10

Design delivery and acceptance

Organise design files as Foundations, Components, Desktop, Mobile, States and Flows. Every module needs at minimum a default, empty, loading, error, signed-out and signed-in state plus its own specific states. Component variants must cover size, state, permission and content length — duplicated artboards are not a substitute for defined component states.

The hand-off to engineering includes:

• Color, type and spacing variables
• Grid and breakpoints
• Component variants
• Media aspect ratios
• Table column-width strategy
• Exception states
• Permission notes and interaction return paths

Role-specific group management screens must be annotated separately from the ordinary member screens.

Acceptance coverage

Verify at 360, 390, 430, 768, 1024, 1440 and 1920px, and against: long team names, two-digit stoppage time, overtime periods, emoji nicknames, three feedback images, very long messages, mixed Chinese and English, and masked phone numbers. A defect in the source site is not a correct acceptance result for a rebuild.

Section 11

Evidence sources

Captured screens show the real structure of the source interface. Matches, artwork and copy in them are dynamic reference content. Images that failed to load, and content hidden behind an overlay, cannot be reconstructed from these captures.