SPEAKER_1: Alright, so last time we landed on auto-layout as the internationalization infrastructure — the thing that keeps a design from breaking the moment a translator touches it. That felt like a natural bridge into today, because now I want to talk about the system that holds all of that together: the design system itself. SPEAKER_2: Right, and that's exactly the right sequence. Auto-layout handles the resizing logic, but a design system is what ensures every designer on the team is pulling from the same source of truth — same tokens, same color variables, same type scale. Without that layer, auto-layout just saves one person time. SPEAKER_1: So for someone building a large-scale Chinese app — think Meituan, think a super-app with dozens of screen types — what does a localized design system actually need to contain? SPEAKER_2: The essentials are: semantic design tokens for color and typography, a grid system calibrated for mobile-first Chinese screens, component documentation that includes localization notes, and a clear separation between content and structure. That last one is critical — text strings should live in external resource files or token layers, not hardcoded into components. SPEAKER_1: Why does that separation matter so much? Because it sounds like an extra step that slows things down early. SPEAKER_2: It feels like overhead until the first localization sprint hits. If text is hardcoded, every translation requires a designer to manually update components. If strings are tokenized or stored externally — in a headless CMS or a translation management system — translators can update content without touching the design file at all. POEditor, for instance, integrates directly with Figma for exactly this workflow. SPEAKER_1: That's the i18n-first argument, right? Prioritize internationalization early so you're not retrofitting later. SPEAKER_2: Exactly. Smashing Magazine's 2025 localization research is direct on this: designing for localization from the start avoids costly fixes later. The teams that skip it pay three to five times more to retrofit a system that was never built to flex. SPEAKER_1: Let's get into color variables specifically. How many are we typically talking about for a large-scale Chinese app, and how does dark mode factor in? SPEAKER_2: A mature system usually carries 60 to 120 color variables — not arbitrary hex values, but semantic tokens: primary, secondary, surface, on-surface, error, success. Dark mode is handled by aliasing: a token like 'color/background/primary' points to a light value in one mode and a dark value in another. The component never changes — only the token's resolved value switches. That's the mechanism. SPEAKER_1: So the component is mode-agnostic. It just reads whatever the token resolves to. SPEAKER_2: Precisely. And Figma Variables support this aliasing natively now, which is a significant step forward. The caveat — and we touched on this in lecture three — is that Figma still lacks percentage-based line-heights, so CJK typography tokens need manual workarounds for complex scripts. SPEAKER_1: What about the grid system? Our listener might assume a 12-column grid is universal, but is that actually true for Chinese mobile-first design? SPEAKER_2: It's not. Chinese mobile-first environments typically use 4 or 8-column grids on 375-pixel base widths, with tighter gutters — often 16px rather than the 24 or 32px common in Western desktop-first systems. The density of Chinese app interfaces, where more information is surfaced per screen, demands that tighter spatial logic. SPEAKER_1: And consistency across that grid — is there actual evidence it moves the needle for users, or is that a designer's assumption? SPEAKER_2: There's documented impact. Consistent design systems correlate with measurable increases in user trust — some studies put it at 20 to 30 percent improvement in perceived reliability. When every screen follows the same spatial logic and color language, users build a mental model faster. Inconsistency reads as instability, even subconsciously. SPEAKER_1: Here's something I want to push on: why do design systems go stale? Because Gong's team might build something solid and then find it's outdated six months later. SPEAKER_2: Documentation debt. The system gets built, but the reasoning behind decisions — why a token is named a certain way, why a component has a specific constraint — lives only in someone's head. When that person leaves or the team scales, the system becomes a black box. A living design system requires changelog entries, decision logs, and a feedback loop with both developers and local stakeholders who can flag cultural missteps. SPEAKER_1: Cultural missteps — that's interesting. Can you give a concrete example of what that looks like in a Chinese context? SPEAKER_2: Color is the obvious one. Red signals danger in Western interfaces but signals celebration and success in Chinese culture. An error state using red needs careful semantic labeling so it doesn't get misread. Similarly, avoid embedding text in images — a localization team can't extract that without a full redesign. And icons need research: a thumbs-up reads positively in most markets but carries negative connotations in parts of the Middle East. SPEAKER_1: So the system has to encode cultural knowledge, not just visual rules. SPEAKER_2: That's the right framing. And the way to operationalize it is through a scalable testing framework with native speakers — not just QA testers, but people who can catch the difference between technically correct and culturally appropriate. Good localization is invisible. Users shouldn't notice they're using a localized version. That's the benchmark. SPEAKER_1: So for our listener building their first serious design system for a Chinese product — what's the single thing they should hold onto from this? SPEAKER_2: Build the token layer before the components. Semantic color variables, a mobile-first grid, and externalized text strings aren't refinements you add later — they're the foundation everything else sits on. For someone like Gong working across Chinese and international markets, that token architecture is what makes one system serve multiple languages and modes without a rebuild. Organize styles and assets for scale from day one, and the system stays alive instead of becoming a liability.