If you’re designing serious products in Figma, you’ve probably hit this wall:

• Files take forever to open.

• Prototype playback stutters.

• Publishing the library feels like deploying a monolith.

• Someone quietly starts making “just a few” local components to get work done faster… and now nothing matches anything.

We live in that world every day. Our team works on massive, multi-year cybersecurity platforms where a “single flow” can turn into seven complex tabs, advanced prototyping, and a ridiculous amount of variants. At some point, Figma stops feeling like a design tool and starts feeling like an MMO trying to run on a Chromebook.

This post is how we deal with that in practice: how we structure Figma files, when we split things out, and how we think about design systems vs local components when the project is big enough to hear the CPU fan.

Where Figma Actually Starts To Break

On smaller projects, you can get away with almost anything. One file, a few pages, a simple library, no problem.

On bigger platforms, the bottlenecks are pretty consistent:

• Layer count: Every frame, every hidden layer, every nested component adds up. Figma’s memory usage panel will happily show you which layers are eating the most.

• Heavy prototyping: Smart Animate and complex transitions across large boards can absolutely tank performance, especially on lower-end machines.

• Variables and tokens: Huge variable tables, especially for multi-theme (dark / light) designs, contribute to file weight.

• Giant “everything” files: Wireframes, production UI, prototypes, and concept explorations all living in a single file is how you end up in the yellow/orange memory zone with constant lag.

We’ve watched files creep toward that 60–70% memory usage range, and that’s where Figma starts warning you and degrading the experience long before you hit 100%. At that point, you’re not “fine but a little slow.” You’re paying a tax on every single click.

So the real question is not “how do I avoid this forever,” it is “how do I structure my project so that when, not if, things grow, the system doesn’t collapse.”

Approach 1: One Big File With Pages

This is where most teams start.

Pattern

• One Figma file for a product.

• Separate pages for: wireframes, flows, components, production mocks, and prototypes.

• Stakeholders comment directly in that file. Everyone lives there.

Why people like it

• Everything is in front of you. Easy to see the whole story. Good for early phases where context matters more than structure.

• Simple sharing. One link, one file, nobody wonders “which file is the real one.”

• Centralized comments. PMs and engineers can follow the thread in one place instead of hunting across files.

Where it breaks

• Once you add enough pages, Figma performance drags even if you’re “only” looking at one page.

• Wireframes turn into high fidelity, then those multiply into variants and states, then prototypes get layered on top. The file grows sideways and vertically.

• You end up with “frozen” pages where just zooming or panning feels painful.

We’ve seen flows that started as a single lifecycle screen evolve into multiple tabs, deep interactions, and detailed prototypes. That’s great for the product, but terrible for a single-file setup once it reaches a certain size.

Our take

One big file works fine at the beginning and for smaller apps. The mistake is staying in this model once the product and team grow. If Figma is already warning you about memory, you’re late.

Approach 2: One File, But Split Prototypes Out

When the “big file” gets too slow, the next move we’ve used is to keep the core design in one file but move the heavy prototype into its own.

Pattern

• Primary product file: components + main UI.

• Separate prototype file: same library, but only the screens needed to demo flows.

• Prototype file often has more motion, transitions, and interactions, but fewer total boards.

Why it helps

• Performance improves instantly for prototyping work, because you’re not dragging the entire product’s history into the prototype.

• You can get aggressive with animation without killing the main file. If the prototype becomes heavy, it doesn’t ruin day-to-day design work.

• Cleaner review sessions. Stakeholders see only “demo-ready” screens, not in-progress junk, exploration branches, etc.

We’ve had projects where the main file simply couldn’t handle running the prototype anymore, so moving the prototype into a separate file was the only sane move.

Tradeoffs

• Comments and discussion get fragmented. Some live in the core file, others in the prototype file.

• Designers have to be disciplined about syncing changes and not letting the prototype drift from the source.

• This does not solve the deeper structural issues (component sprawl, library management). It only gives you breathing room on interactions.

Our take

This is a good transitional step, especially when your main pain is “Figma dies when I hit Play.” But for truly large products, we still end up needing a more aggressive re-architecture.

Approach 3: Feature-Based Files Inside One Figma Project

This is where things get serious.

Instead of one giant file with many pages, we split the product into multiple files inside a single Figma project:

• App – Dashboard

• App – Alerts

• App – Investigations

• App – Settings

• App – Wireframes

• App – Prototypes – Rule Builder Demo

• etc.

All of them use the same shared design system library.

Why this works better for big products

• Performance scales with complexity. The “Dashboard” file can be huge and intense, while the “Settings” file stays light. Each file has its own memory budget.

• You can go deep on one area. Want a crazy interactive prototype of just the rule builder? That can live in its own file without dragging the rest of the app down.

• Parallel work is easier. Multiple designers can work in different areas without stomping on each other or bloating a single file with ten in-progress phases.

We landed on this approach after staring at giant files and asking, “why is this all here?” If a feature is complex enough to destroy Figma performance, it probably deserves its own file.

Drawbacks

• You now have “file sprawl.” If you don’t name things clearly, you end up with “copy of” hell and nobody knows which one is canonical.

• More links to manage. You’ll want a simple index, like a “Project Home” file with links to each feature / prototype.

• Prototyping across files is annoying. You can’t natively prototype across files, so major cross-feature flows usually live in a dedicated prototype file that pulls in frames via the shared library.

Our take

For small to medium apps, this might be overkill. For the kind of enterprise platforms we work on, splitting by feature or domain inside a single Figma project is usually the only way to keep Figma usable long-term.

Design System Library vs Local Components

File structure alone doesn’t save you if your component strategy is a mess.

Local components feel fast… until they don’t

Every designer has done this:

“I just need this one variation, I’ll make a local component and clean it up later.”

That’s fine if you are literally the only person touching that file.

It breaks as soon as:

• Another designer spins up a prototype in a different file.

• Someone tries to reuse that pattern elsewhere.

• You need to change that pattern across multiple flows.

Now you’re stuck:

• Local component lives in File A.

• Prototype is in File B.

• Design system is in File C.

• You want that component updated everywhere.

We’ve had designers describe the pain of updating a single icon: open the design system file, update the icon, publish, wait for 1,700 components to republish, then sync everything in the main app file, let all the boards redraw, then finally grab the updated asset. Doing that for every small tweak is brutal.

So people fall back to local components to “go faster.” And now you have divergence.

Single source of truth hurts now, saves you later

The approach we keep coming back to:

• One primary design system library per product.

• Design inside the system file as much as possible. Build complex blocks and flows there first, then consume them in feature files.

• Local components only for truly app-specific, non-reusable stuff.

We treat this like we do on the dev side:

• ~80% of components are generic enough to share across many projects and live in a central library.

• The other ~20% are custom, app-specific pieces that are fine to keep local.

That same philosophy works inside Figma:

• Buttons, inputs, cards, navigation, modals, tags, table patterns, etc → go in the design system.

• One-off Frankenstein compositions for a single screen → local component in that file is fine.

The key is to avoid “library sprawl.” We’ve seen clients end up with three competing libraries for the same product: one old, one half-updated, one brand-only. That’s how you get eight versions of a button and nobody knows which one is “real.”

Performance Tuning That Actually Helps

Regardless of structure, there are some practical things that improve Figma performance on big projects:

• Split wireframes into their own file once they explode. Early on, it’s fine to keep them next to high-fidelity. Later, copy them into App – Wireframes and archive them out of the production UI files.

• Use Figma’s memory usage panel. It will show which layers/frames are hogging memory, including hidden ones. Clean up unused variants, old frames, and massive “backup” boards you’ll never use again.

• Trim hidden junk inside components. All those “just in case” layers inside a master component still cost memory, even when hidden.

• Be smart with Smart Animate. On big flows, replace long chains of Smart Animate with Instant transitions where you can. Save Smart Animate for the stuff that really matters in the demo.

• Batch your library publishes. Adding one icon at a time and publishing the whole library every time is a great way to waste your afternoon. Queue up a set of changes and publish them together.

• Make your token system flexible, not “perfect.” Instead of trying to force one token to behave the same in dark and light modes, create extra intermediate tokens where needed (for example: brand.blue.darkToBlue, brand.blue.darkToBlack, etc). That gives you control without hacking local overrides all over the place.

None of this is glamorous, but it adds up. You’re basically fighting entropy.

Our Default Setup For Large Products

At Good Code, this is what we usually end up with on bigger clients:

1. One core design system library per product

   • Built on our Unify Design System.

   • All common components, typography, colors, tokens, and interaction patterns live here.

   • Icons are either a separate library or tightly managed section, not random local assets.

2. Feature-based app files

   • App – Dashboard

   • App – Investigations

   • App – Analytics

   • App – Settings

     Each file pulls from the same design system library.

3. Separate wireframe and exploration files

   • App – Wireframes

   • App – Explorations

     These can be messy and large, but they don’t bog down production UI files.

4. Dedicated prototype files for hero flows

   • Prototype – Onboarding Flow

   • Prototype – Rule Builder Demo

     These exist purely to demo end-to-end flows with high-fidelity interactions.

5. Strict rules around components

   • If it could reasonably be reused elsewhere, it goes into the design system.

   • Local components are allowed only for truly one-off things in that file.

   • No shadow libraries, no “personal component collections” living in random files.

Is this more front-loaded work? Yes.

Is it less painful than trying to refactor a 2-year-old monster file while Figma screams about memory and your clients are asking for light mode? Also yes.

So… What Should You Do?

It depends on your situation:

• Small product, small team, early stage

  One file with sensible pages and a lightweight library is totally fine. Just keep an eye on growth and don’t let local components become the default.

• Growing product, more designers, more complexity

  Start breaking your Figma project down: separate wireframes, pull prototypes into their own file when they get heavy, formalize a real design system library.

• Enterprise-scale platform, long-term roadmap

  You almost certainly need:

  • A robust design system library,

  • Feature-based files,

  • Dedicated prototype files for key flows,

  • Clear rules about where components live and how they get updated.

That’s exactly where we spend most of our time: helping teams climb out of Figma chaos and into something structured that designers, engineers, and PMs can actually live with.

Need Help Untangling Your Figma Setup?

If you’re staring at a sluggish Figma file and dreading the next “we need light mode” request, this is the kind of mess we deal with every day.

At Good Code, we’re not just making pretty screens. We’re designing and implementing full design systems for complex, security-heavy products and wiring them into real applications.

Our Unify Design System (unifydesignsystem.com) is the foundation we use to keep these huge projects maintainable: tokens, components, and patterns that are built to survive dark mode, product pivots, and multi-year roadmaps.

If you want help:

• Restructuring your Figma files so they don’t collapse under their own weight,

• Setting up a sane design system and token architecture,

• Or getting your design system aligned with how your dev team actually ships,

reach out and we’ll take a look at your setup and show you how we’d approach it.