There is one thing I still miss from Adobe XD when designing long web pages in Figma.

It is not a spectacular feature.

It is not a fancy animation tool.

It is simply the way XD showed you where the viewport ends.

And when you are designing a long landing page while simultaneously building and testing a prototype, that small difference makes the workflow noticeably more comfortable.

The problem with Figma

Figma treats the frame as the viewport for scrolling.

If you want vertical scrolling to work in a prototype, the content needs to extend beyond the frame dimensions, and the frame itself defines the area through which that content is viewed. Figma's prototype settings therefore require the scrolling content to be larger than the frame that acts as its viewport.

That makes perfect sense from a prototyping perspective.

But it creates an awkward design workflow.

Imagine designing a landing page that is 4,000 pixels high.

You want to see the entire page while designing it.

You also want the prototype to behave like a 900-pixel-high browser viewport.

In Figma, those two things are tightly connected by the frame structure.

So you end up designing inside a long frame and then dealing with the fact that the scrolling viewport is defined by that same frame.

Figma does offer inline preview, which is useful because the prototype can be viewed directly over the canvas while you continue working on the design.

But inline preview does not solve the underlying problem.

You can preview the prototype.

You can see the scrolling behaviour.

You can zoom the preview.

But while designing the long page, there is no equivalent of XD's persistent viewport marker showing you:

This is the part of the page the user sees before scrolling.

And in my case, it was not just a landing page

This is what made the difference particularly noticeable.

I was not designing a standalone marketing website.

I was designing the whole product flow for Metricon.

The journey started on the landing page and continued through:

Landing page → registration → onboarding → welcome dashboard → SaaS application → validation session → interactive report

So I was moving between two different kinds of design work.

On one side, there was the website — the marketing and acquisition layer.

On the other, there was the web application — the actual SaaS product people would use after signing up.

That distinction matters in Figma because there is now a specialized product for websites: Figma Sites.

Figma Sites is designed specifically for creating responsive websites, including landing pages, and publishing them to the web. It is a separate file type from Figma Design. Figma Sites has its own concepts such as webpages, breakpoints and interactions, while Figma Design has the traditional prototype workflow.

So, technically, Figma now has a dedicated environment for the website part of the problem.

But that is precisely where the workflow becomes interesting.

I was not designing only a website.

I wanted to design and prototype the website and the SaaS application as one continuous user journey.

Could I simply use Figma Sites for everything?

Not really.

Figma Sites and Figma Design are separate environments with different capabilities.

Figma explicitly positions Sites as a place to design and publish websites, while Figma Design remains the environment for traditional prototyping. Sites has interactions, but the two systems are not simply two views of the same file. Figma's documentation lists Webpages and Breakpoints as Sites-specific concepts, while Prototyping belongs to Figma Design.

You can move designs between the two.

Figma supports copying designs from Figma Design into Sites, and copying assets back from Sites into Design. Prototype connections can also be translated into corresponding Sites interactions in supported cases.

But they are still separate file types.

So for a product such as Metricon, where the experience crosses from:

marketing website → authentication → web application

there is still a meaningful boundary between designing the website and designing the product itself.

And that is exactly where the old Adobe XD workflow felt more unified to me.

Adobe XD approached it differently

Adobe XD allowed you to create a scrollable artboard and define a Viewport Height separately from the full artboard height.

That meant you could have a long page and still explicitly define the visible area of the prototype.

That tiny visual cue was surprisingly useful.

You could look at your entire page and immediately understand:

Above this line: initial viewport.

Below this line: content reached through scrolling.

You didn't have to mentally calculate where the first screen ended.

The difference is small. The workflow isn't.

This is where I think the two tools differ philosophically.

Figma's current model is more explicitly separated between its different product surfaces:

Figma Design → design and prototype
Figma Sites → responsive websites and publishing
Figma Make → functional prototypes and web apps

That separation makes sense from a product perspective.

But as a designer, it can also mean more context switching when a project spans the whole experience.

Adobe XD's mental model felt simpler:

Artboard = designed experience
Viewport = visible part of that experience

Both approaches can produce the same final prototype.

But they don't feel the same while designing.

And this matters because designers don't spend their entire day presenting prototypes.

We spend a lot of time building, inspecting, adjusting, comparing and testing them.

A small amount of friction repeated hundreds of times becomes a real workflow problem.

My workaround in Figma

I ended up using a very simple solution.

I created a separate frame:

Viewport — 1440 × 900

and placed the landing page inside it.

No special stroke.

No dashed lines.

No visual marker pretending to be a technical boundary.

Just the default white fill, without a stroke.

That was enough.

The frame itself became my visual reference for the initial viewport.

I could now design the long landing page while keeping a clear understanding of what the user would actually see on the first screen.

It is not a sophisticated workaround.

And that's precisely why I like it.

It also solved a bigger problem

Because I was designing the entire Metricon journey, the viewport frame became a useful boundary between two different contexts.

The landing page had a clear:

1440 × 900 initial viewport

while the rest of the product could continue as a separate application flow.

It gave me the thing I was missing from XD:

a visible answer to “where does the screen end?”

without having to redesign the entire prototype structure.

So which one is better?

For everyday product design, I wouldn't say that Adobe XD is simply "better" than Figma.

Figma now has a much broader ecosystem, including specialized tools for websites and functional web applications. Figma Sites, for example, is specifically designed to take responsive website designs from concept to published site, while Figma Make can turn designs into functional prototypes and web apps.

But for designing long scrollable pages while actively working on the design, I still prefer the mental model of Adobe XD.

XD made the viewport visible as part of the design process.

Figma's model is more modular, but sometimes that means the designer has to create the missing visual context themselves.

That is not a huge feature difference.

It is a workflow difference.

And sometimes those are the differences designers notice the most.

The interesting part

The funny thing is that my Figma workaround does not require another plugin, a complicated component, or some clever prototype trick.

It is just:

Long page → Viewport frame → 1440 × 900

That's it.

And suddenly I have the visual reference I was missing.

Maybe this is a tiny thing.

But if a tool makes me stop thinking about the tool and start thinking about the interface again, that's a pretty good sign that the workaround is doing its job.