3D UX/UI mockups that scroll inside a laptop and a phone

You send the file link and the client opens a canvas with forty frames. They cannot tell which one is the homepage. They click something, someone else's cursor drifts past, and they close the tab. They arrive at the call having seen nothing, and the first ten minutes go to explaining the tool instead of the design.

The design file is where the work lives, not where it gets looked at. Someone who does not open it every day needs a page that behaves like a page. That is what a website mockup is in i3Dify: your screenshots sitting on the screen of a 3D laptop, at one URL, with nothing to install.

A full page screenshot scrolls inside the laptop screen

Flat renders crop. A 6000 pixel landing page pasted into a device frame is either cut off at the fold or shrunk until the body copy stops being readable. Here the image is fitted to the width of the display and scrolled vertically, the way the page scrolls in a browser, so the whole design reads top to bottom at full width.

The controls are split on purpose. Drag the screen or use the wheel and the page scrolls. Drag the backdrop and the laptop turns. The arrow keys and the dock move between screens, and the counter above the dock carries the title you gave each one, so Home, Pricing and Checkout are where the client expects them when you are driving a walkthrough live on a call.

A hotspot rides the screenshot instead of floating over it

An app screens mockup is the same idea on a 3D phone, and it is where hotspots do the most work. You click a spot on the screen, the checkout button say, and attach a link to it: the next screen, the live build, the spec, a recorded flow. The hotspot is anchored to the image, so it travels with the pixel it belongs to as the visitor scrolls rather than sitting in a fixed layer on top.

Opened on a real phone, which is where a forwarded link usually gets read, those hotspots are tappable. A folder of loose exports turns into a flow somebody runs with their own thumb. Two limits are worth saying out loud. There are no form fields and no state, so this is a guided walkthrough and not a prototype. And a scroll stops at the end of the current screen: moving to the next one is the dock or the arrow keys, never an accident halfway down a feed.

The capture is the only step with a trick in it

Upload one image per screen, drag them into the order you want to walk somebody through, title each one, publish. That is the build. The part people get wrong is the export, because what the viewer needs is the full page height and not what fit in the window when you pressed the key.

In Chrome it lives in the DevTools command menu, under Capture full size screenshot. In Figma, export the frame at its real height. A PDF works too and each page becomes one screen, although on the phone a page fitted to the width of the display no longer fills its height, so it sits centred with bands above and below instead of scrolling.

Capture at 1x, not 2x. The viewer rescales the image before it becomes a texture, so the retina pixels buy nothing and only make the person who opened the link wait for them. They also eat into the 50 MB the free plan gives you, and a set of long dashboard screens gets there faster than you would think.

The share URL outlives the round of feedback

Replace the screens in the editor after a review round and the link does not change. The one in the client's inbox and the one pasted into a doc three weeks ago both keep working, and both show the current version, so nobody comes back with notes on a design you already threw away. While the work is under review the project can stay unlisted or sit behind a password, on any plan, the free one included.

Your design file is where you work. The link is for the meeting, for the forward, and for the decision that gets made three days later without you in the room.

Put your next round of screens on a laptop and a phone.