Prospective clients often look a little shocked when I tell them that I don’t design Shopify stores.

I choose not to produce static page designs. I don’t run a separate Figma phase. I don’t spend weeks moving mockups through rounds of approval before anyone sees the store working.

I build directly in Shopify.

Once clients experience the process, that initial surprise usually disappears. They see functioning progress sooner, spend less time reviewing abstract designs and launch with flexible sections they can continue using after the project is complete.

This isn’t because visual presentation doesn’t matter. Many of my clients operate in premium markets and are understandably protective of how their brands appear.

It is because functionality, customers and the realities of the business should shape the store from the beginning, as opposed to being introduced after a visual design has already been approved.

A static design isn’t a functioning Shopify store

The traditional website process normally follows three distinct stages:

1. Design the pages
2. Build what was approved
3. Test whether it works

That might appear logical, but it separates decisions that are closely connected.

A page can look beautiful in a static design while leaving important questions unanswered:

• How will it respond across different screen sizes?
• Can the Ecommerce team change it without a developer?
• Does it work with the catalogue structure?
• What happens when the content is translated?
• Can it support different markets or business requirements?
• How does it affect navigation, accessibility, performance and SEO?
• Is the proposed functionality already available within the theme?
• Will the component be reusable or hardcoded for one page?
• How flexible and reusable with this be?

Those questions shouldn’t wait until development or testing.

Shopify themes are structured around configurable templates, sections and blocks that merchants can add, remove and rearrange. That flexibility is a deliberate part of the platform. Shopify’s guidance explains how sections and blocks support merchant customisation.

When the process begins with static page designs, the build can become an exercise in reproducing approved mockups rather than creating a flexible Shopify store.

UX and CRO aren’t the same as making something look pretty

Visual appearance matters, but it isn’t a substitute for user experience or conversion thinking.

UX considers whether customers can understand where they are, find what they need, evaluate their options and complete a task without unnecessary friction.

CRO considers what customers need to make a decision, where they hesitate, what evidence is available and how the store supports the commercial objectives of the business.

Both are influenced by far more than visual design:

• Product and catalogue structure
• Navigation and search
• Content hierarchy
• Product information
• Pricing and promotions
• Customer intent
• Mobile behaviour
• Marketing channels
• Operational constraints
• Technology and integrations
• Trust and reassurance
• Site performance

A visually impressive page can still create a poor customer experience. Equally, a store can be attractive, on-brand and commercially effective without first existing as a set of static mockups.

What I do instead

LANDS Ecommerce handles the complete Shopify delivery, including theme selection, store structure, content hierarchy, configuration, technical specification and custom code.

For a new build, retheme or migration project, I begin by understanding the business:

• What do customers need to find and understand?
• How is the product catalogue structured?
• How do customers currently navigate?
• Which marketing and sales channels must the store support?
• What operational requirements affect the experience?
• Which markets and languages are involved?
• What does the available data tell us?
• What must be protected or improved from an SEO, UX or CRO perspective?
• What does the internal team need to manage after launch?

I then shortlist two or three appropriate off-the-shelf Shopify themes.

A well-chosen theme will normally take us around halfway (sometimes more) towards the required solution. I assess what it already does well, what can be configured and what genuinely needs to be adapted or built.

The gaps might exist because of the client’s operations, marketing channels, catalogue complexity or business model. Customers may navigate in a particular way, or the store may need functionality that isn’t available out of the box.

Only then do I define the additions and customisations required.

Documentation still matters

Working without static designs doesn’t mean working without definition or documentation.

Before developing bespoke functionality, I document:

• The purpose of the feature
• Customer and business requirements
• Product and catalogue implications
• Structured data and data models
• Relevant live examples and inspiration
• Expected behaviour across devices
• Localisation and market requirements
• SEO considerations
• What the feature must support now and in the future

Based on the evidence available, I also define content hierarchy, keywords and content direction.

The difference is that these decisions don’t disappear into a long document that the client then has to imagine as a finished store.

I build them into the development theme.

My clients review a fully functioning Shopify store

When the client receives the work for review, it already contains imagery, content, hierarchy and functioning features.

They can assess how everything works together rather than reviewing isolated mockups, content documents and technical specifications.

Clients review through a Shopify development theme. We also have calls to walk through the reasoning, answer questions and agree iterations. I use tools such as Loom where helpful, particularly when I need to demonstrate functionality or show the team where controls and settings live.

This means feedback is based on a real user experience.

Clients can see:

• How the store behaves on desktop and mobile
• How navigation opens and responds
• How sections work with genuine content
• Whether the imagery and hierarchy feel right
• What the internal team can edit
• How reusable components behave across different pages
• How the store adapts across languages and markets

Instead of approving a design and discovering its limitations later, they review the functioning implementation as it develops.

What this can mean for delivery time

I have completed Shopify rethemes and migrations in four weeks that could easily have moved towards four months through a separate design, build and test process.

That doesn’t mean every Shopify project can or should launch in four weeks. Complexity, integrations, content readiness, data and decision-making all affect delivery.

But removing an unnecessary design stage can significantly reduce elapsed time.

It also reduces the amount of time the client spends:

• Reviewing multiple static page designs
• Consolidating subjective visual feedback
• Reapproving decisions during development
• Comparing the finished build against mockups
• Discovering technical constraints late in the project

More of the time and investment reaches the functioning store.

Complex functionality doesn’t require a static design first

One recent project involved a highly configurable new navigation system.

This wasn’t a standard dropdown menu. We had a large catalogue that needed to support:

• Four levels of navigation
• Labels specific to mobile or desktop
• Shoppable and editorial presentation styles
• Buttons and promotional banners
• Different content and behaviour across menu types
• Translation by language
• Content tailored to individual markets
• Long-term flexibility for the Product and Marketing teams

I began by defining the functionality, catalogue implications, data structure, behaviour and localisation requirements. Relevant live examples helped establish what worked, while the technical specification documented what the finished system needed to achieve.

The complete work, including scoping, documentation, development, testing and deliver, took approximately 90 hours.

The result wasn’t a fixed interpretation of one menu design. It was a reusable system capable of supporting different commercial, editorial and international requirements.

Part of the Liquid implementation behind a configurable, four-level Shopify navigation system.

Being on-brand doesn’t require a Figma phase

Most LANDS clients operate in premium markets. Protecting the visual identity and customer perception of the brand is essential.

I work from the established brand direction, including:

• Logo usage
• Colour palette
• Typography
• Photography and imagery
• Tone of voice
• Existing visual assets

Where appropriate, I can suggest practical additions, for example, extending an existing colour palette when the interface requires additional states.

However, LANDS does not provide branding or visual-identity services. Ideally, the core fonts, colours, imagery and tone of voice have been defined and agreed before the Shopify project begins.

I apply that identity within the functioning theme: its typography, spacing, sections, navigation, buttons, cards, imagery and responsive behaviour.

Clients still make visual decisions. They simply make them while reviewing a fully functioning store.

The finished store should belong to the client

A Shopify project shouldn’t leave an Ecommerce team dependent on a developer every time it needs to change a banner, rearrange a page or create a new campaign landing page.

The purpose of building reusable sections is to give the team useful control after launch.

That doesn’t mean making every element configurable as too many settings can create inconsistency and make a theme harder to manage.

It means creating the right flexibility around the things the business will genuinely need to change.

The finished store should feel like a coherent system, not a series of pages hardcoded to reproduce static designs.

Is this approach right for everyone?

No.

It works best for businesses that:

• Already have an established brand identity
• Are willing to review a functioning store rather than static designs
• Value functionality and customer needs alongside visual presentation
• Want to move quickly and make decisions collaboratively
• Need reusable sections and greater control after launch
• Trust an experienced Shopify specialist to lead the implementation
• If a business needs a new brand identity, exploratory art direction or a standalone visual-design process, that work should happen before the Shopify build.

LANDS is not a branding or web-design studio.

That clarity matters. Clients choose LANDS because they want a different delivery model, more agile and with a lot less overheads. Not because I’m trying to replicate a traditional agency process with fewer stages.

Bypassing design is a conscious choice I made

Shopify has evolved and I have seen first hand what strict waterfall ways of working add to both time and costs.

I choose to start with the business, its customers and what the technology needs to achieve.

I select the right foundation, document the requirements and build the experience directly in Shopify. Clients review real functionality, real content and real responsive behaviour as the work develops.

The process is faster, more connected and focused on producing a store the client can continue using, not simply approving.