For one of my recent client projects, I wanted to create a proper multi-page interactive prototype — something that actually feels like a website. I had animations in mind, like subtle reveal-on-scroll effects where elements slide in from the bottom as you move through the page. It’s a small detail, but it really helps the client understand how the final site will look and feel.

I could have built the prototype directly in my Figma design file, but doing all those scroll-triggered animations across 8+ pages would’ve taken forever. So I decided to use Figma Sites, because it’s just much faster for that kind of interactivity.

Before that, I even tried Figma Make. I copied my homepage section by section and asked it to recreate it. But it turned into a long back-and-forth: styles didn’t translate properly, hover states showed up as defaults, and the layout needed a lot of manual fixing. After spending too much time on just one page, I gave up on that route.

So I went with Figma Sites instead. I already had my full design ready — all components cleanly set up in a Figma file — and decided to copy everything over and connect the pages there. And while that made sense at first, it quickly led me into a whole new problem I didn’t expect.

The Setup: What I Was Trying to Do

I had all my pages already set up in my main Figma design file — desktop and mobile versions for Home, About, Solutions, Products and so on. That file also contained all the components, variables, and styles, which I shared as a library so I could reuse them elsewhere.

Once that was ready, I copied the pages into Figma Sites to turn everything into an interactive prototype. The idea was to bring those designs to life — with scroll animations, transitions, and clickable links between pages — without rebuilding everything from scratch.

So far, everything worked nicely. The layouts came through, the styles matched, and I could use all my shared components inside the Sites file. The navbar (which I had as a component in my design library) was there, and I could see the dropdown MegaMenu animation working when I previewed it.

But then, when I started setting up page links — for example, opening the dropdown and clicking on “Retail” to go to the Retail page — things didn’t behave as expected.

The Problem: When Interactions Start Breaking

I spent quite a bit of time trying to make the MegaMenu work the way I expected. My idea was simple: open the menu in the component, link each item to the correct page, and it should work. So I went through every single page, setting up links for “Industries → Retail,” “Industries → Healthcare,” and so on.

At first, I thought I just had to tweak it a little — but no matter how many times I tried, the links only worked when the menu was manually set to the open state on the canvas. The moment I closed and reopened it in Preview mode, the links stopped working entirely. It was confusing and frustrating, because visually everything seemed fine, but functionally, nothing behaved as intended.

Part of the difficulty was that I was still relying on components from my design file. The actual pages I wanted to link to were in Figma Sites, so the links I set up inside the design file couldn’t point to anything real. I kept thinking there must be a workaround — maybe I was missing some trick — but after a lot of trial and error, it became clear what was really happening: the problem wasn’t my setup or linking logic, it was how Figma Sites handles components imported from other files.

This also explained why the image cards in my industry sections were resetting to the default image. Nested components and variant overrides simply don’t carry over properly when the master component lives in another file. Once I realized that, I knew I needed a different approach to make everything actually work.

The Root Cause: How Figma Sites Treats Cross-File Components

Once I dug into it, I realized the issue wasn’t a random glitch — it’s just how Figma Sites handles components imported from other files.

When you bring a component from a Figma design file into Sites, it essentially becomes a linked reference. That means:

• Default variant only: During prototype playback, Figma Sites loads the component in its default state. Any overrides or swapped variants you applied in the design file — like different images for cards or hover states — often don’t carry over.
• Nested components get tricky: If a component contains another component (like a card with an image subcomponent), Figma Sites sometimes ignores the internal overrides entirely. That’s why all your cards reverted to one default image.

In other words, imported components are treated a bit like black boxes: visually they look correct on the canvas, but underneath, the prototype engine can’t always preserve overrides or nested variants.

Once I understood this, the path forward became clear: to have reliable interactions and variant overrides, the components need to live directly in the Figma Sites file.

The Fix: What Actually Worked

With the root cause clear, I needed a practical solution for the navbar and card components:

Copy components directly into the Figma Sites file

• I pasted the navbar component from my design file into Sites.
• I did the same for the card components, including their nested image variants.

Rebuild interactions locally

• For the navbar, I set up all dropdown links inside the Sites file, so clicking “Industries → Retail” or other items worked correctly in Preview mode.
• For the cards, I swapped images and text per instance, ensuring each hover state displayed correctly.

Replace component instances across pages

• I swapped out the old library-linked components on every page with the new local versions.
• This ensured consistent behavior across all pages and both desktop and mobile layouts.

After these steps, the prototype finally behaved reliably: dropdown links worked, hover states displayed correctly, and cards showed the right images per instance — all without relying on components from another file.

Lessons Learned & Best Practices

After going through this process, here’s what I’d recommend for anyone building multi-page prototypes in Figma Sites:

• Keep interactive components local: If a component has variants, hover states, or nested elements, copy it into the Sites file instead of relying on a linked library.
• Rebuild interactions in the same file: Set up links, hover states, and other interactive behaviors inside the Sites file so they work reliably in Preview mode.
• Swap instances consistently: Once the local components are ready, replace all library-linked instances across pages to avoid inconsistencies.
• Use libraries for static assets only: Colors, text styles, icons, or other reusable elements are fine to keep in a shared library, but interactive components work best when local.
• Check your version: Some issues with missing variables or styles can come from using the desktop app vs. the online version. If styles or variables aren’t showing correctly, try refreshing or updating the library in the web version — it usually reflects changes faster than the desktop app.
• Test Preview early and often: Canvas mode can be misleading — always check the prototype in Preview to catch variant or interaction issues.

Conclusion

Working with Figma Sites can be a huge time-saver for multi-page, interactive prototypes — especially when you want animations, scroll effects, and realistic interactions. But the key takeaway from my experience is this: interactive components and variants need to live directly in the Sites file.

Cross-file components can look perfect on the canvas, but Preview mode will often ignore overrides, nested variants, or hover states. Copying components locally and rebuilding interactions may feel like extra work upfront, but it saves a lot of frustration and ensures your prototype actually behaves the way you intend.