SPEAKER_1: Alright, so last time we established that Figma's real-time architecture — the CRDTs, the cloud sync — is what makes it structurally superior for cross-border teams. That foundation makes sense. Now I want to get into what actually lives inside that environment: frames and components. SPEAKER_2: Good place to pick up. And honestly, frames are where most designers either build something solid or quietly create a mess they'll regret in week three of a project. SPEAKER_1: So what even is a frame in Figma? Our listener might be picturing just... a rectangle. SPEAKER_2: It's much more than that. A frame is a structured container — it holds child elements, enforces constraints, and defines how content behaves when the screen size changes. Think of it like a knowledge structure in AI: it has slots for attributes, and those slots have values. A frame for a WeChat mini-program screen might hold a navigation bar, a content area, a footer — each with defined properties and relationships to each other. SPEAKER_1: So the hierarchy matters. It's not just nesting for organization — the parent frame actually governs the children? SPEAKER_2: Exactly. Frames are organized hierarchically, like a tree. A top-level frame might represent the full phone screen. Inside it, sub-frames handle sections. Each level inherits context from the level above — positioning, clipping, scroll behavior. That inheritance is what makes complex Chinese app layouts manageable. Douyin's home feed, for instance, has deeply nested interactive zones, and frames are what keep that structure coherent. SPEAKER_1: That inheritance idea is interesting. How does that actually work mechanically — does a child frame automatically pick up properties from the parent? SPEAKER_2: It picks up constraints and clipping by default, yes. If the parent frame clips content, children won't bleed outside it. If you set a fill on the parent, children sit on top of it. The key insight is that frames don't just group things visually — they encode relationships. That's why Figma treats frames as the heart of layout, not groups. Groups are passive. Frames are structural. SPEAKER_1: Okay, so frames handle structure. Where do components come in? SPEAKER_2: Components solve the repetition problem. In a large-scale app — say, a super-app like Meituan with dozens of screen types — you'll reuse the same button, the same card, the same input field hundreds of times. A component lets you define that element once as a Main Component, then deploy Instances everywhere. Change the Main Component, and every Instance updates globally. That's the mechanism. SPEAKER_1: And the time savings on that are real? Or is that one of those claims that sounds good in theory? SPEAKER_2: It's documented. Teams using component-based workflows on large projects report cutting repetitive update work by around 40 to 50 percent. When Gong's team needs to update a button style across 80 screens, that's the difference between a two-minute Main Component edit and a two-hour manual sweep. SPEAKER_1: So what types of components does Figma actually support? I want to make sure our listener understands the full picture. SPEAKER_2: There are two primary types. Main Components — the source of truth, usually stored in a shared library. And Instances — the deployed copies. But within that, you have Variants, which let you bundle multiple states of a component — default, hover, pressed, disabled — into one organized set. So a button isn't four separate components; it's one component with four variants. SPEAKER_1: That variant system sounds like it maps directly to how developers think about component states in code. SPEAKER_2: It does, and that's intentional. The design mirrors the logic a frontend developer would write. Which is why Dev Mode reads component variants cleanly — the handoff becomes a conversation, not a translation exercise. SPEAKER_1: Now, here's something I want to push on. Is there a scenario where leaning too hard on components actually slows a team down? SPEAKER_2: Absolutely. Over-componentizing early is a real trap. If every micro-element becomes a component before the design direction is settled, you end up maintaining a library that's constantly breaking. The discipline is knowing what to componentize — stable, reused elements — and what to leave as raw frames during exploration. Components are a commitment. Use them when the design has earned that stability. SPEAKER_1: So for a team building a WeChat mini-program, how would a shared library actually be structured to support multiple designers working simultaneously? SPEAKER_2: The library lives in a dedicated Figma file — separate from any product file. It publishes components that all product files subscribe to. Multiple designers can work in their own product files, pulling from the same library. When the library updates, subscribers get a notification and can accept changes. It's a clean separation of source and consumption, and it scales without collision. SPEAKER_1: So the library file is almost like a contract the whole team signs. SPEAKER_2: That's exactly the right framing. It's a shared agreement about what the design system is. And because Figma's real-time sync — which we covered last time — underpins all of this, the library update propagates instantly. No one is working from a stale version. SPEAKER_1: So for our listener, what's the single thing they should hold onto from this? SPEAKER_2: Master the hierarchy of frames first — understand that they're structural, not decorative — and then build components only for what's stable and repeated. For someone like Gong working on complex Chinese application layouts, that combination is what turns a chaotic file into a system that scales. Frames give you the architecture; components give you the efficiency. Together, they're how professional teams iterate rapidly without breaking what already works.