Mobile-First E-Commerce Design in Figma

Mobile-first e-commerce design in Figma means starting every screen at your smallest breakpoint, using auto layout and variables so components resize predictably, and only then designing up toward tablet and desktop. Most storefront traffic today arrives on a phone, so a design that looks polished on a 1440px canvas but was never tested at 375px is designing for the wrong device first. This tutorial walks through the actual Figma workflow — file setup, components, breakpoints, and handoff — using patterns we apply across our own Figma theme kits.

If you would rather skip the from-scratch build entirely, our Figma theme kits are already structured mobile-first with the exact component and variable patterns described below, so you can jump straight to customizing content instead of setting up the system.

Why Design Mobile-First At All

Designing mobile-first is not just a philosophy — it changes the order of decisions you make and the constraints you design against. When you start at desktop width, it is easy to add features that only work with generous space: multi-column filters, hover-triggered menus, wide product grids. Squeezing that layout down to a phone later usually means removing things, which feels like a downgrade and often gets rushed. When you start at 375px, every decision is forced to earn its place. What survives the mobile version is usually the actual core of the experience, and expanding it to tablet and desktop is a much easier problem than compressing a desktop design down.

There is also a practical Figma reason to work this way: auto layout and constraints behave more predictably when you build the tightest, most constrained version of a component first, then loosen it for wider viewports. Building desktop-first and retrofitting mobile constraints afterward is where most component systems in Figma start to break down, with elements that resize in unintended ways or overflow their frames.

Step 1: Set Up Your File With Breakpoints as First-Class Citizens

Before drawing anything, set up frames for at least three breakpoints: mobile (around 375–390px), tablet (around 768px), and desktop (1280–1440px). Keep these as separate top-level frames within the same page rather than scattering them across different files — it makes it much easier to compare how a section behaves across widths as you design.

• Mobile frame: 375 or 390px wide, matching common phone viewport widths.
• Tablet frame: 768px wide, useful for checking how two-column layouts start to appear.
• Desktop frame: 1280 or 1440px wide, where multi-column grids and expanded navigation live.
• Name frames consistently (e.g. Home / Mobile, Home / Tablet, Home / Desktop) so your layer panel stays scannable as the file grows.

Design the mobile frame completely first — full page, real content, not lorem ipsum where you can help it. Only once the mobile version feels solid should you duplicate it into the tablet frame and start adjusting.

Step 2: Build Components With Auto Layout, Not Fixed Positioning

Every reusable piece — product card, price tag, button, badge, nav item — should be built with Figma's auto layout rather than manually positioned elements. Auto layout is what lets a component resize gracefully when content length changes (a longer product title, a discounted price with a strikethrough, a badge that only sometimes appears) without you manually nudging elements on every screen that uses it.

• Set padding and item spacing on the auto layout frame itself, not as manual gaps between children.
• Use Hug contents for elements that should shrink to fit their content (buttons, badges) and Fill container for elements that should stretch (a product card inside a grid).
• Nest auto layout frames inside each other — a product card is itself an auto layout frame containing an image, a text stack, and a price row, each of which can also be auto layout.
• Set resizing behavior explicitly on text layers (Auto width, Auto height, or Fixed size) so titles wrap the way they will in the real store rather than overflowing silently in Figma.

This is the single habit that saves the most rework later. A component built with fixed pixel positions has to be rebuilt for every breakpoint. A component built with auto layout and sensible resizing rules often only needs its container width changed.

Step 3: Use Variables for Spacing, Type, and Color — Not Just Color Styles

Figma variables let you define spacing, sizing, and color as reusable tokens, and — critically for mobile-first work — you can define different modes per breakpoint. A spacing variable named "section-padding" might resolve to 16px on mobile and 48px on desktop, and every frame using that variable updates automatically when you switch modes, instead of you manually resizing padding on every section across every breakpoint.

• Define a small spacing scale (e.g. 4, 8, 12, 16, 24, 32, 48, 64) as variables rather than typing raw pixel values into every frame.
• Create breakpoint modes on your spacing and type-size variables so switching a frame's mode updates its internal rhythm automatically.
• Keep color as variables too, aliasing to your brand palette, so a single change propagates through every component instead of requiring a find-and-replace across styles.

This step is optional for a one-off landing page, but for a full store — home, collection, product detail, cart — it is what keeps mobile, tablet, and desktop versions of the same section actually consistent instead of drifting apart as you iterate.

Step 4: Design the Product Grid and Product Card for Thumb-Width Screens First

The product grid is usually the highest-traffic layout in a store, so get it right at mobile width before anywhere else. A single-column or two-column grid is standard for phones; test both with real product images and real title lengths, since a two-column grid on a narrow phone can crush product photography and squeeze prices onto multiple lines.

• Keep the tap target for Add to cart and any quick-add buttons at a minimum of roughly 44x44px, per standard mobile accessibility guidance.
• Design the price and any discount/badge treatment with auto layout so a sale price with a strikethrough original doesn't awkwardly reflow when it appears.
• Test the grid at both two and four product-title lengths (short, medium, long) so you catch wrapping issues before they show up in the live store.
• Design the sticky mobile filter and sort bar as its own component early — it behaves differently from a desktop sidebar and deserves separate attention rather than being a squeezed-down version of it.

Product detail page: stack, don't shrink

On desktop, product detail pages typically run gallery and details side by side. On mobile, resist the urge to just shrink that layout — stack it instead: image gallery first, then title and price, then a sticky add-to-cart bar, then options, then description. This is a genuinely different composition, not a smaller version of the same one, and it is worth designing as its own frame from scratch rather than resizing the desktop version down.

Step 5: Expand Upward to Tablet and Desktop

Once the mobile frame is solid, duplicate it and start widening. With auto layout in place, a lot of this step is simply changing container widths and letting content reflow — a single-column product grid becomes a three or four-column grid by changing the grid's wrap and item width, not by rebuilding the card.

• Watch for elements designed for thumbs that don't need to persist at desktop width — a sticky mobile add-to-cart bar, for instance, is often unnecessary once the buy button is already visible without scrolling.
• Expand navigation last. Mobile nav is usually a hamburger or bottom bar; desktop nav often introduces dropdown mega-menus that have no mobile equivalent and need their own design pass.
• Re-check spacing variables at each breakpoint mode rather than eyeballing new values — this is where the variable-mode setup from Step 3 pays off.

Step 6: Prototype and Test at Real Phone Width

Figma's prototyping mode lets you link frames together and preview them at actual device dimensions, either in the desktop app or the Figma mobile app on a real phone. Before calling a mobile design done, walk through the actual flow — home to collection to product to cart — on a physical device or at least in the accurate-width preview, not just by eyeballing the artboard at a zoomed-out canvas view where everything looks smaller and more forgiving than it will in a real browser.

Pay particular attention to anything that depends on hover, since phones don't have it: dropdown menus, tooltip-style size guides, and hover-to-reveal quick-add buttons all need a tap-based equivalent designed explicitly, not assumed to "just work" on touch.

Step 7: Prepare the File for Handoff

A mobile-first Figma file is only useful if a developer (or a theme like ours) can read it clearly. Name layers meaningfully, group breakpoint frames under clearly labeled sections, and make sure components are actual Figma components (not just visually similar groups) so instances stay linked to a single source of truth. If you are building toward a Shopify launch rather than a custom build, our Shopify theme catalog is worth a look — a well-structured Figma file translates fastest into a store when the target theme already shares similar component patterns and breakpoint logic.

For teams that want the system already built rather than assembling it component by component, our e-commerce Figma bundle ships with mobile-first components, spacing variables, and breakpoint frames already structured this way across multiple store templates, so the setup work in Steps 1 through 3 is already done.

Common Mistakes to Avoid

• Designing desktop first "because it's easier to see." It is easier to see, but it produces layouts that need to be un-built for mobile rather than built up from it.
• Using fixed pixel positions instead of auto layout. This is the single biggest source of rework when moving between breakpoints.
• Skipping real content. Lorem ipsum text is always a tidy, uniform length. Real product titles, prices, and badges are not, and mismatched text lengths are exactly what breaks a design at mobile width.
• Forgetting hover-dependent interactions. Anything that only works on hover needs an explicit tap-based design for mobile.
• Not testing at real width. A zoomed-out canvas view of a 375px frame looks very different from that same frame filling an actual phone screen.

Frequently Asked Questions

Do I need to design every breakpoint, or can I skip tablet?

If your build process (or theme) handles tablet as an automatic in-between state of mobile and desktop, you can often skip a dedicated tablet frame for simple pages. For anything with a layout that changes shape at tablet width — grids moving from two to three columns, navigation changing structure — it is worth at least a rough tablet frame to catch awkward in-between states.

Should I use Figma variables or styles for a mobile-first project?

Styles are fine for a simple, single-breakpoint project. Variables are worth the setup time specifically because they support per-breakpoint modes — that is what lets a spacing or type-size value change automatically when you switch a frame from mobile to desktop mode, which is central to an efficient mobile-first workflow.

How closely should the Figma file match the final coded store?

As closely as practical, especially in component structure and spacing logic. A Figma file that mirrors how components will actually be built (cards, buttons, and sections as clean, resizable units) hands off faster and with fewer surprises than one that merely looks right without the underlying structure matching.

Can I adapt an existing desktop design to be mobile-first, or do I need to start over?

You don't need to throw away the visual language — colors, type, imagery style can carry over directly. But the layout and component structure usually benefit from being rebuilt with auto layout and mobile-width constraints first, then expanded, rather than retrofitting mobile behavior onto frames that were built assuming desktop space from the start.