World-building on the web
Alice Ching, an engineering manager at Figma, spent much of her pre-Figma career building game engines for consoles. The leap to a collaborative design tool wasn’t as large as it might sound: Figma’s canvas relies on the same foundational graphics and rendering principles that game developers use to construct digital worlds. Minecraft, Ching notes, is a good comparison—it’s a multiplayer sandbox powered by systems for rendering, physics, animation, and user-generated content. Figma and FigJam operate on a similar model, layering specialized systems on top of a core rendering engine.
Rather than a traditional web stack, Figma’s architecture leans toward gaming conventions. The graphical canvas is written in C++ and compiled to WebAssembly, a language choice common in game engines because it affords the memory management flexibility needed for real-time, high-performance work. The UI layer, by contrast, is built with React and TypeScript since C++ lacks the library ecosystem for polished interactive interfaces. On the server side, Figma’s multiplayer service is written in Rust, chosen for its performance and developer ergonomics.
The system of systems
Figma’s rendering layer is only one of several interconnected systems running simultaneously in a file. Drawing inspiration from cooperative gaming, the company named its real-time collaboration engine "multiplayer." Just as two players in a shared world can place objects in the same spot, two Figma users can add or edit design elements concurrently, requiring the engine to resolve actions without collisions.
Beyond multiplayer, the "digital world" of Figma includes an animation system for spring physics, a collision engine that detects cursor hover states and connection points, and chat and audio tools for real-time communication. Additional systems serve more specific functions: an auto layout system for visual organization, components and variants for reusable asset libraries that closely map to code, and an open platform for community-built plugins and widgets for FigJam. Some of these systems run only in a browser or mobile app, where memory and performance constraints require tight integration across all layers.
When systems collide
The interdependence of these systems becomes apparent when interactions go sideways. In well-designed games, systems work together to create emergent player experiences with countless possible outcomes. The same is true, positively and negatively, in Figma.
Ching traces one strange bug: a file with apparent autosave failures. Investigation by engineers Katie Jiang and Jonas Sicking revealed that connectors in a FigJam file—arrows that intelligently link objects—were oscillating continuously. Every user in the file was subtly modifying the connectors, sending differing data indefinitely and generating so many multiplayer messages that the autosave system got overwhelmed. A code audit found nothing until engineer Isaac Goldberg added debugging messages that traced the behavior to a six-month-old pull request in a part of the codebase entirely unrelated to connectors.
The culprit: Connector state depends on whatever they connect to. If a sticky note moves or resizes, the connector must recompute its attachment points to keep the visual link intact. A small change in the layout system driving those objects created a loop that propagated up through multiplayer and ultimately caused the autosave failure—a textbook example of one subsystem triggering a bug in an entirely separate one.
We’ve called our collaboration engine: → “multiplayer.”
This systemic complexity is why Figma’s engineering culture mirrors a game studio’s. Engineers there don't work only with other engineers; they collaborate directly with artists and game designers to polish a character's glow or a boss fight's timing. That same cross-functional collaboration happens every day at Figma across teams. As Ching puts it, the thrill is not just bringing users' ideas to life but pushing interdependent systems to their limits to deliver an experience.
For design teams, this architecture means Figma lags and feels less responsive when it features deep interaction models: It’s not just a web app—it’s an engineered simulation running in a browser environment.
Why collaborative features are the hardest part
It’s tempting to treat multiplayer as a rendering problem: make the canvas fast enough and everything else will follow. In practice, the hard parts are interaction design and conflict resolution. When two people edit the same object simultaneously, the system needs a consistent answer for what the final state should be — and that answer needs to feel predictable to both users.
This is where game development thinking applies most directly. A polished game doesn’t just render well; its animation, physics, and input systems are designed together so the player always understands what is happening. The same principle guided the team during the development of tables in FigJam. The product team focused on single-user polish such as copy-and-paste, undo and redo, and drag-to-resize. Meanwhile, the engineering team worked with the platform team to handle concurrency, testing scenarios like typing in a cell while another user deletes it, or adding a row while a third person recolors an intersecting column. Locking a table during edits would have simplified the work, but it would have undermined the collaborative feel of the product, so the team kept tables fully editable and worked through each edge case.
Animation as a communication tool
Once the underlying multiplayer logic was stable, a second problem appeared: observing someone else’s changes was hard to follow. If you are editing a cell and a teammate rearranges rows, your cell may move two rows down — correct in data terms, but disorienting in practice. Designer Jakub Świadek prototyped a better interaction, and engineer Tim Babb built a new animation framework for it.
The team started with “live feedback” that reflected edits in real time, synchronizing every revision to the internal testing environment. That gave the editing user a snappy feel and showed exactly where rows and columns moved as they dragged. But since the feedback was tied to the initiating user's pointer movement, it appeared jarring to everyone else watching. The team added more animation layers so observers could clearly track when and where a row or column landed.
They also added a rubber-band effect when dragging rows and columns — a visual cue borrowed from game design where invisible boundaries guide players. The effect communicates the limits of the drag area without resorting to explicit messages.
Input flexibility as an accessibility feature
Supporting different control schemes is standard in games, where players can choose between keyboard and mouse, standard gamepads, or adaptive controllers — and it’s an accessibility consideration in Figma as well. The team partnered with Figma’s accessibility group to make tables navigable with keyboard shortcuts, giving users who can’t rely on a mouse or trackpad a full alternative. The author of this post recalls that on the game Wattam, adding support for the Xbox Adaptive Controller drew direct feedback from the community expressing gratitude — a reminder that broad input support isn't a niche concern. That same mindset is driving continued investment in accessible controls across Figma’s products.
