Designing for Online Store 2.0 and the build that follows
A store design is only as good as the theme it becomes. These are the habits that keep our designs buildable, fast and easy for your team to run.
A design system made of sections and blocks
Online Store 2.0 themes are built from sections, and sections are built from blocks. Merchants can add, remove and reorder both in the theme editor on almost any template. We design with that structure in mind from the first wireframe. Instead of drawing a homepage as one long picture, we draw it as a stack of named sections, such as an image banner, a featured collection, a text with image row and a review strip, each with the settings it needs.
This changes how the design is reviewed. Each section gets a short list of variations: with or without a heading, image on the left or right, light or dark background, two to four columns. Those variations become theme settings, so your team can build a new landing page from existing parts instead of briefing a designer every time. Fewer, well-defined sections usually beat dozens of near-duplicates that nobody remembers how to use.
Real content and structured product data
Designs that only work with perfect placeholder text break the week after launch. We design with your real product names, longest titles, shortest descriptions, missing images and awkward variant combinations. A product card has to cope with a sale price, a sold-out badge and a two-line title at the same time, and a hero banner has to survive a translated headline that runs longer than the English one.
Where a page shows repeating details such as ingredients, materials, care instructions, size charts or feature lists, we plan them as metafields or metaobjects rather than free text in the description. Shopify can connect these to theme sections through dynamic sources, so one product template can show different details for different products. It keeps pages consistent and makes later changes a data edit rather than a design job.
Speed is a design decision
Many slow stores were slow on paper before a line of code was written. Autoplay video in the first screen, three font families, a carousel in every section and an app widget on every product page all add weight. We make performance part of design review, so the visual direction and the speed budget are agreed together, not traded off in a panic after launch.
In practice that means one type family in a small set of weights, images sized for the space they fill, a static first screen rather than a slider, and native theme sections where an app would add extra scripts. Core Web Vitals depend on the build as much as the design, but a design that respects these limits gives developers a fair chance of passing them.
Design informed by conversion evidence
We treat every redesign as a set of hypotheses. If session recordings show shoppers scrolling past the size guide, we move it next to the size selector and note why. If support tickets keep asking about delivery times, the estimate goes near add to cart. Writing down the reason for each change makes it easier to judge the result later and to decide what to test next.
For stores with enough traffic, the riskiest changes can be tested before they are rolled out to everyone. For smaller stores, we rely on research and established patterns, then review analytics after launch. Either way, the design file records what we expected to happen, so the follow-up conversation is about evidence. Our Shopify CRO audit goes deeper when conversion is the main goal.
A handoff developers do not have to decode
Handoff is where good designs often lose detail. We reduce the guesswork by delivering a section map that names every section and block, notes which settings each one needs and links it to the Figma frames. Spacing, type styles and colors are defined as tokens that map onto theme settings, so a developer is not measuring pixels by hand.
We also design the states people forget: empty cart, no search results, out of stock, form errors, loading filters and long menus on small screens. During the build we review preview themes against the design and log differences in one shared list, so fixes happen before launch rather than as a stream of messages afterwards.