How to Design a Product Page in Figma

Designing a product page in Figma comes down to three things done in order: decide what the page has to accomplish before you place a single frame, build the layout with real (or realistic) product content instead of lorem ipsum, and turn the repeating pieces — gallery, variant picker, buy box, trust content — into components you can reuse across every product in the catalog. Skipping straight to visuals is the most common way teams end up with a page that looks polished in one screenshot and falls apart the moment it meets a real catalog. This tutorial walks through the process step by step, and shows where a ready-made kit like our Optics Figma theme can save you the structural decisions so you can spend your time on the details that actually differentiate your store.

Whether you are designing from a blank canvas or adapting an existing kit, the workflow below applies to any product category. Where it helps to be concrete, this guide uses an eyewear store as a running example, but the same steps hold for fashion, electronics, or any other niche.

Step 1: Define the Page's Job Before Opening Figma

A product page has one primary job: get a visitor who already has some interest in the product to a confident add-to-cart decision. Everything on the page should serve that job or get cut. Before you draw anything, write down — even just in a Figma sticky note or a doc — the specific questions your product page needs to answer for your category. For most ecommerce products that list looks something like: what does this look like from multiple angles, what are my size/color/variant options, how much does it cost and is it in stock, what do other buyers say about it, and what happens if I need to return it.

This step matters because it prevents the most common Figma mistake: designing a beautiful hero section and image gallery, then treating the variant picker, shipping info, and reviews as an afterthought crammed below the fold. If your product has several option groups — say, frame color, lens type, and coating for eyewear — that reality needs to shape the layout from the start, not get patched in after the visual design is "done."

Step 2: Set Up Your File Structure and Grid

Start with a clean structure so the file stays manageable as it grows. A typical setup uses separate pages for Cover, Design System (color, type, spacing, icons), Components, and then one page per template (Home, Collection, Product, Cart). Keep the product page template on its own page with clearly named frames for desktop and mobile — do not bury both breakpoints in the same messy frame.

Set up a grid before you place anything. A 12-column grid at common desktop breakpoints (1440px is a safe default) with consistent gutters gives you a system to align the gallery, buy box, and content sections against, rather than eyeballing spacing frame by frame. Define spacing as a scale — 4/8/16/24/32/48/64px is a common base-8 system — and stick to it. This single habit is what makes a Figma file feel intentional rather than assembled ad hoc, and it is exactly the kind of foundational work a pre-built kit like our Ecommerce Figma bundle has already done for you across multiple niches.

Step 3: Block Out the Layout With Real Content

Resist the urge to drop in lorem ipsum and gray placeholder boxes. Pull real (or realistic) product names, actual price formatting, a believable variant list, and genuine review snippets before you start arranging the page. Real content reveals problems that placeholder content hides: a product title that wraps to three lines and breaks your header spacing, a variant list with six colors that a two-column swatch grid can't handle gracefully, or a price plus a "was" price plus a discount badge that needs more horizontal room than you budgeted.

Start with the above-the-fold layout, which typically splits into a two-column arrangement on desktop: gallery on one side, everything the shopper needs to make a purchase decision (title, price, variants, add-to-cart, trust badges) on the other. On mobile, this collapses to a single column with the gallery first and the buy box directly beneath it — do not make a mobile shopper scroll past a long description before reaching the add-to-cart button.

Step 4: Design the Gallery as a Reusable Component

The product gallery is one of the highest-leverage components on the page, and it needs to work for both a product with one photo and a product with ten. Build it as a component with variants: a primary image area, a thumbnail strip (horizontal on mobile, vertical or horizontal on desktop depending on your layout), and clear states for hover and active thumbnail. Design it so that adding a fourth or fifth image doesn't require redesigning the layout — the thumbnail strip should scroll or wrap rather than force the frame taller.

If your category benefits from zoom or lightbox interaction — which most visually detailed products do — mock up that state too, even as a simple full-screen frame, so developers know what to build. Leave visible space in the component for a future addition like a 360-degree spin viewer or an embedded video, even if you don't design that state fully now. A gallery component that can only ever show exactly four square images will need a rebuild the first time a merchant wants to add something different.

Step 5: Design the Variant Picker for Your Worst Case, Not Your Best Case

Design your variant picker against the product with the most option groups in your catalog, not the simplest one. A single dropdown for "Size" looks clean, but if some products in the catalog also need color, material, and a bundle add-on, that same layout will collapse into a stack of look-alike dropdowns that's hard to scan. Group options visually — color as swatches, size as a button row, anything else as clearly labeled dropdowns — and give each group its own label and enough spacing that a shopper can tell at a glance which choice affects which part of the product.

Design explicit states for each option: available, selected, and out-of-stock/disabled. It's tempting to skip the disabled state in a mockup, but it's one of the most common places a build goes wrong without a spec — developers need to know whether an out-of-stock variant should be hidden, grayed out, or shown with a "notify me" affordance.

Step 6: Build the Buy Box and Sticky Mobile Bar

The buy box — price, variant picker, quantity selector, and add-to-cart button — is the conversion-critical zone of the page, so give it deliberate hierarchy. Price should be the most visually prominent element after the product title, the add-to-cart button should have clear visual weight (don't let it get lost next to a same-styled "buy now" or "wishlist" button), and stock/shipping information should sit close enough to the button that a hesitant shopper doesn't have to hunt for it.

On mobile, design a sticky add-to-cart bar that appears once the shopper scrolls past the primary buy box. This is one of the highest-impact patterns for mobile ecommerce because it keeps the purchase action reachable no matter how far the shopper scrolls into descriptions or reviews. Mock up both the collapsed sticky bar and how it expands if you're including an inline quantity or variant selector in it.

Step 7: Design the Trust and Content Sections Below the Fold

Below the primary buy box, design the sections that answer the shopper's remaining doubts: a detailed description, specifications or a size/fit guide, shipping and returns information, and reviews. Treat these as their own components too, not one-off frames, since they'll repeat across every product page in the catalog. A collapsible accordion works well for specs and shipping policy — it keeps the page scannable while still making the information available a click away.

Reviews deserve real design attention rather than a placeholder box, since social proof is one of the strongest levers on a product page. Design a summary state (average rating, count, a distribution bar) plus an individual review card, and think about how it looks with zero reviews so new products don't ship with an empty, awkward-looking module.

Step 8: Turn Everything Into a Documented Component Library

Once the layout is solid, go back through and convert every repeating piece — buttons, badges, the gallery, the variant picker, the review card, the accordion — into a Figma component with clearly named variants and properties. This is the difference between a one-off mockup and a design system a team can actually build from and extend. Name layers and components consistently (a component called "Button/Primary/Default" is far more useful six months later than one called "Rectangle 47").

This is also the point where handoff to development gets dramatically easier. A developer working from a well-componentized file with defined states (default, hover, disabled, error) can build the real page far faster than one reverse-engineering intent from a single static frame. If you'd rather start from a system where this component work is already done — including the gallery, variant, and buy-box patterns described above — our Optics Figma theme ships as a fully componentized kit built specifically around this kind of product-detail structure, and our broader Figma themes catalog covers the same approach across other niches.

Step 9: Test the Layout Against Edge Cases

Before calling the design done, stress-test it against the edge cases your real catalog will produce: the longest realistic product title, a product with only one image, a product with the maximum number of variants you support, a very long or very short description, and a price with a discount badge. A layout that only looks good with a five-word title and three neat variants is not actually finished — it's finished for the one example you designed it around.

• Longest title: does it wrap gracefully without pushing the buy box down awkwardly?
• Single image: does the gallery still look intentional with just one photo, or does it look broken without a thumbnail strip?
• Maximum variants: does the option picker stay legible with every group your catalog actually uses?
• No reviews yet: does the review section have a sensible empty state instead of showing a hollow module?
• Out of stock: is there a clear, designed state for a sold-out variant or product?

Step 10: Prepare the File for Developer Handoff

Finish by making the file legible to whoever builds it, whether that's your own team or an outside developer. Use Figma's Dev Mode (or the classic Inspect panel) to make sure spacing, color, and type values are readable directly off the layers rather than requiring a conversation. Annotate any interaction that isn't obvious from a static frame — how the sticky bar behaves, what happens when a variant is disabled, how the gallery lightbox opens — either as sticky notes on the canvas or a short accompanying doc.

If you're designing directly against a theme you plan to launch on, it's worth working from the actual product structure of that theme rather than an idealized one. Our Optics Shopify theme and its matching Optics Figma file are built to the same underlying product template, so a design produced this way maps to a real, buildable page rather than requiring translation at handoff.

Frequently Asked Questions

Do I need to design a product page from scratch, or should I start from a kit?

Starting from a proven Figma kit is usually the faster and lower-risk path, especially for the structural decisions covered in this guide — grid, gallery behavior, variant layout, component states. A kit like our Optics Figma theme lets you spend your design time on brand-specific details rather than re-solving problems that have already been solved well.

What's the biggest mistake designers make on Figma product pages?

Designing against the best-case product — one photo, two simple variants, a short title — rather than the worst case in the actual catalog. The layout that looks clean in a single polished mockup often breaks the first time it meets a real product with six variants and a long title, because that scenario was never designed for.

Should the mobile layout be a separate design or an adaptation?

Design mobile as its own frame with the same components, not an afterthought squeezed from the desktop layout. The single-column stacking order (gallery, then buy box, then content) and the sticky add-to-cart bar are mobile-specific patterns that deserve their own explicit design.

How detailed should component states be before handoff?

At minimum, design default, hover, disabled, and any error or empty state for every interactive component — buttons, variant options, and form fields especially. Skipping these states is one of the most common causes of back-and-forth during development, since a developer has to guess or ask rather than build directly from the file.