Prototyping in Figma for E-Commerce

Figma prototyping for e-commerce means turning static product, collection, and cart screens into a clickable flow that behaves like a real store, so you can test navigation and purchase logic before any code is written. The core workflow is: build the key screens as frames, wire them together with click-through connections, add overlays for cart and modals, and preview on real devices. This tutorial walks through that process using a merchandising-first structure, and points to our Figma theme kits as a starting point if you would rather adapt an existing store layout than build every screen from a blank canvas.

Prototyping matters more in e-commerce than in most other kinds of design work, because the stakes of getting a flow wrong are direct revenue. A confusing collection filter, a checkout step that feels like a dead end, or a cart drawer that does not make the next action obvious will cost sales in production. Catching those problems in Figma, where a stakeholder or test user can click through a fake but convincing store, is far cheaper than catching them after launch. This guide covers the practical steps: setting up frames for the pages that matter most, connecting them into a flow, using components and variants so your prototype stays maintainable, and testing it like a real shopper would use it.

Before You Start: Map the Flow, Not Just the Screens

A common mistake is designing individual e-commerce screens in isolation and only thinking about how they connect at the end. Start instead with a simple flow map: home or landing page, collection/category page, product detail page, cart (as a drawer or full page), checkout steps, and order confirmation. Sketch this as a short list or a rough diagram before opening Figma in earnest. Knowing the full path in advance means you design each screen with its neighbors in mind — for example, a product page's Add to Cart button needs a clear destination (a drawer overlay, or a jump to the cart page) decided before you start wiring interactions.

It also helps to decide early whether you are prototyping a desktop-first or mobile-first flow, since e-commerce interaction patterns differ meaningfully between the two — a mobile cart is almost always a bottom-anchored drawer or full-screen overlay, while desktop more often uses a slide-in panel from the right. If you are unsure which to start with, check your traffic split assumptions; for most modern storefronts, prototyping mobile first surfaces layout problems (cramped option pickers, buried filters) earlier, when they are cheaper to fix.

Step 1: Set Up Your Frames and Page Structure

Create one Figma page for your prototype and organize frames left to right in the rough order a shopper would encounter them: landing, collection, product detail, cart, checkout, confirmation. Use consistent frame sizes for each device target (for example, a 1440-wide frame for desktop, 390-wide for mobile) so your prototype's transitions feel uniform rather than jumping between mismatched canvas sizes. Name every frame clearly (Product Detail — Sneaker, Cart — Drawer Open) since Figma's prototype connections list frames by name, and vague names make a flow with a dozen screens hard to navigate later.

If you are starting from scratch, expect the product detail page and collection grid to take the most iteration — they carry the most interactive surface area (variant pickers, filters, sort controls). If you would rather start from a working e-commerce layout and focus your time on flow and interaction rather than visual layout from zero, our Optics Figma theme and Wosa Figma theme are built as complete, editable Figma files with the product, collection, and cart screens already laid out — a practical shortcut when the goal is testing a flow rather than designing every screen's visual system yourself.

Step 2: Build Reusable Components First

Before wiring interactions, turn your repeating elements into Figma components: the product card used across collection grids, the buy-box button, the cart line item, the filter chip. This is not just tidiness — it directly affects how much rework a flow change costs you later. If your product card is a component with variants (in stock, sale price, sold out), updating the sale badge once updates every instance across every collection screen in the prototype, instead of requiring you to hunt down and edit a dozen copies by hand.

• Product card: image, title, price, and a sale-price variant, used identically across collection grids and search results.
• Cart line item: thumbnail, title, variant text, quantity stepper, and remove action, reused in both a cart drawer and a full cart page.
• Buy-box button: default, hover, and disabled/sold-out states as variants of one component, not three separate layers.
• Filter/sort control: a single component instance repeated across every collection page so filter behavior stays visually consistent.

Step 3: Wire the Core Purchase Flow

With frames and components in place, switch to Figma's Prototype tab and start connecting the path a shopper actually takes. Click a product card on the collection frame and drag a connection to the product detail frame; set the interaction to On Click, navigation Navigate to, and a subtle transition like Smart Animate or Push so the jump between screens does not feel abrupt. Repeat for the path from product detail to cart, and from cart to each checkout step.

For the cart specifically, decide whether Add to Cart should open an overlay or navigate to a new page, and be consistent about it across every product screen in the prototype — inconsistent cart behavior is one of the fastest ways to make a Figma prototype feel unconvincing to a test user. If you are using an overlay, set the interaction type to Open Overlay rather than Navigate to, position it (commonly Manual with the cart drawer's own anchor, or Bottom Right for a desktop panel), and give it a background dim so it visually reads as sitting on top of the current page rather than replacing it.

Using overlays for cart drawers and modals

Overlays are the right tool any time an interaction should feel like it is layering on top of the current screen instead of replacing it: cart drawers, quick-view product modals, size guides, and filter panels on mobile. Build the overlay as its own small frame, set its interaction trigger from the button that opens it (typically On Click → Open Overlay), and add a close interaction on its own close button or background scrim (On Click → Close Overlay) so testers are not stuck once they open it. A cart drawer overlay in particular should include its own Checkout button wired forward into your checkout frames, since that is the natural next click for anyone testing the flow.

Handling variant and option selection

Product option pickers (color, size, lens type, and similar) are one of the trickier parts of an e-commerce prototype, because a fully functional variant system is more state-machine than static screen. For a prototype, you rarely need to simulate every combination — instead, use Figma's interactive components or simple variant swaps tied to a couple of representative option states (for example, one state showing the option selected and price/stock updated, and one showing an out-of-stock state). This keeps the prototype honest about what a shopper will see without requiring you to build every permutation by hand.

Step 4: Prototype the Checkout Steps Deliberately

Checkout is where e-commerce prototypes most often get rushed, and it is also where real friction costs the most in production. Even a lightweight prototype should walk through shipping information, a payment step, and an order review/confirmation step as distinct frames, connected in sequence with a clear Back path at each stage. Include obvious visual states for form validation — an error state on a required field, a disabled Continue button until required fields are filled — even if you are only mocking the state rather than wiring live validation logic. Test users notice immediately when a prototype's checkout has no visible response to an empty field, and it undermines confidence in the rest of the flow.

Keep the number of checkout steps honest to what you actually plan to build. If your real storefront will use a single-page checkout, prototype it as one scrollable frame with sections rather than three separate frames — mismatches between the prototype's step count and the eventual build create confusion later when developers or stakeholders compare the two.

Step 5: Test the Prototype Like a Shopper Would

Once your flow is wired, use Figma's Present mode and actually click through it the way a shopper would — start from the landing frame, browse a collection, pick a product with a couple of option changes, add it to cart, and complete checkout. Do this on both desktop presentation and the Figma mobile app (scan the present-mode QR code with a phone) since touch-target sizing and drawer behavior often reveal problems on a real device screen that are invisible on a laptop. It's worth walking a colleague or a real potential customer through the same path without narrating what to click — where they hesitate or tap the wrong element is exactly the friction a production storefront will also produce.

• Can a new visitor find a specific product using only the collection filters, without being told which filter to use?
• Is it obvious what happened after tapping Add to Cart — does the cart drawer's appearance clearly confirm the action?
• Does the checkout flow show a visible reaction to an empty required field, rather than silently doing nothing?
• On mobile, are buttons and option pickers large enough to tap accurately in Present mode?
• Does the flow match what you actually intend to build, or does the prototype secretly assume features that will not exist at launch?

From Prototype to Storefront

A Figma prototype's real value is in reducing rework before development starts, but it only pays off if the handoff to a build is close to what was tested. If you are prototyping a general storefront redesign rather than a single niche, our multi-niche Figma bundle gives you several complete store layouts to prototype against and compare, which is a fast way to validate a flow across different catalog types (fashion, electronics, courses) before committing to one direction. For teams working in a specific vertical, starting from a matching kit — like our Course Whiz Figma theme for cohort-based or on-demand course sales — means your prototype's product and cart screens are already shaped around that catalog's real structure, so the click-through testing you do is closer to what production will actually need to support.

Whichever route you take, browse the full Figma themes catalog before you commit to building every screen from a blank frame — starting from a store layout close to your niche typically saves more prototyping time than it costs in customization, and it keeps your click-through tests grounded in a realistic e-commerce structure from the first frame.

Frequently Asked Questions

Do I need to prototype every page of my store, or just the core flow?

Focus on the core purchase path first — landing, collection, product detail, cart, and checkout — since that is where flow problems most directly cost conversions. Secondary pages like About or a blog index are worth mocking up visually, but they rarely need the same level of interactive wiring.

Should cart be an overlay or a full page in Figma?

Either can work well; the right choice usually mirrors what you intend to build in production. An overlay/drawer keeps shoppers in context and is common for stores that want to encourage continued browsing, while a full cart page suits stores with more complex cart contents (bundles, subscriptions) that benefit from more space.

Can I test a Figma prototype with real users, not just stakeholders?

Yes, and it is one of the most useful things you can do with it. Share the Present-mode link with a handful of people who match your target shopper, give them a task like "find and add a product to your cart" without further instructions, and watch where they hesitate.

How much of the visual design should be finished before prototyping?

Enough that testers are not distracted by obviously unfinished elements, but it does not need to be pixel-final. Many teams prototype with a near-final layout using a real theme kit's components, then refine details like color and type after the flow itself has been validated through testing.