How We Design E-Commerce: From Objects to Experience

A digital product can contain excellent design, modern technology, and dozens of carefully documented features and still fail to solve the problem it was built to solve.

The reason is often surprisingly simple: the project started with the website rather than the business.

At Peretz, we approach e-commerce differently. Before discussing Shopify or Laravel, React or Vue, wireframes or design systems, we try to understand the system behind the interface: the business model, customer journey, sales process, content, logistics, and the decisions that move a customer toward a purchase.

Only then do we decide what the digital product should actually be.

This approach is closely related to several established product-design methodologies, including Jobs to Be Done, Double Diamond, Object-Oriented UX (OOUX), and Atomic Design. We don't treat these as isolated frameworks. Together, they provide useful ways of formalizing a process we have applied across digital products for years.

The starting point is always the same:

What does this business actually need its digital experience to do?

NOT TECH FIRST

We Don't Start With Technology

Technology is important. It is simply not the first decision.

Whether a project should use Shopify, WordPress, Laravel, a headless architecture, React, Vue, or another stack depends on what the product needs to accomplish, how it will grow, and how it will be maintained.

Those decisions become much easier once the underlying requirements are understood.

Our process therefore starts with questions such as:

• Who is the customer?

• What are they trying to accomplish?

• How does the business actually sell?

• How long does the purchasing decision take?

• What role does the website play in the sales process?

• Which parts of the journey happen online and which happen through people?

• How do marketing, sales, logistics, and customer support interact?

• What happens after launch?

These questions determine the architecture far more reliably than a preferred technology stack.

Before proposing a solution, we also examine the market and direct competitors. This includes the visible structure of competing websites, navigation patterns, content, customer journeys, and recurring interaction models.

The objective is not to copy what competitors do.

It is to distinguish between a genuine category pattern and an arbitrary decision made by one particular brand.

That distinction matters.

A competitor may have a particular page, interaction, or purchasing flow because of its brand recognition, operational structure, audience, or sales model. Reproducing the interface without reproducing the conditions that made it effective does not reproduce the result.

We've written more about designing around real business conditions rather than assumed ones in We Design for Reality, Not for Ideal Scenarios.

SPECIFICATION

A Specification Is Useful Only When We Understand What Is Behind It

Clients often arrive with a complete specification.

Thirty pages. Sometimes more.

A sitemap, feature list, references, technical requirements, and a detailed description of what the new website should contain.

We don’t automatically reject this work. In fact, a strong specification can significantly accelerate a project.

There are clients, particularly larger companies and mature product organizations, that have already invested in market research, competitor analysis, customer journey mapping, product strategy, and business analysis. Their specification is the result of that work.

That is an excellent starting point.

In such cases, our role is not to repeat research that has already been done. We can use the existing work and move more efficiently toward product architecture, UX, design, and development.

The problem is not having a specification.

The problem is treating a list of assumptions as if it were research.

A document that says “we need 30 pages” does not tell us why those pages are necessary.

A requirement that says “users need personalized recommendations” does not tell us what should be personalized, based on which data, or what business problem personalization is supposed to solve.

And a competitor’s website does not automatically provide a blueprint for another business.

This is why we develop our own initial structure after understanding the business and customer journey. The result may confirm the client’s original specification, or it may show that the product needs to be organized differently.

That is not an additional layer of bureaucracy.

It is part of product design.

RESEARCH TO JOURNEY

From Competitive Research to Customer Journey

A successful e-commerce website rarely has one universal customer journey.

Consider two visitors to the same premium product website.

One arrives through a search engine already knowing exactly what they want.

Another discovers the brand for the first time and spends several weeks learning about the company, its products, materials, people, and philosophy before making a decision.

They may eventually purchase the same product.

Their journeys are completely different.

This becomes particularly important for considered purchases: luxury goods, jewelry, high-end furniture, real estate, B2B products, professional services, and other purchases where trust and evaluation matter.

For these categories, the familiar:

catalog → product page → cart → checkout

may describe only one part of the experience.

A customer might instead move through:

brand → collection → story → product → expert → consultation → purchase

or:

search → product → comparison → research → return visit → purchase

The interface should accommodate these journeys rather than force every visitor into one predefined sequence.

This is why customer journey mapping is not simply a UX deliverable for us. It is one of the inputs that determines the architecture of the product itself.

The industry matters too.

Some businesses benefit from removing friction and shortening the path to purchase. Others need to create space for discovery, trust, education, or emotional engagement.

Sometimes the best experience is faster.

Sometimes the experience itself is part of what the customer is buying.

WEBSITE NOT PRODUCT

The Website Is Not the Product

This distinction leads to a broader question:

What exactly are we designing?

If we think only in terms of pages, the answer is obvious:

Home page.
Category page.
Product page.
About page.
Blog.
Contact.
Checkout.

But businesses do not actually consist of pages.

They consist of objects and relationships.

A product belongs to a collection.

A collection may have a story.

A product may have a material, designer, origin, certification, expert, service, or consultation associated with it.

A store may be connected to a location.

An expert may be connected to a service.

A customer may interact with several of these objects before making a decision.

Once we start thinking this way, the architecture of the digital product changes.

Instead of asking:

“How many pages do we need?”

we can ask:

“What are the fundamental entities of this business, and how should they interact?”

This is where Object-Oriented UX (OOUX) becomes particularly relevant to e-commerce.

OOUX proposes designing around the real objects of a system rather than starting with screens or user actions. For an e-commerce product, those objects might include products, collections, materials, designers, stories, experts, locations, or services.

The value is not in using the acronym.

The value is in creating a system that can represent the business accurately and then reuse those objects across different experiences.

A product does not need to exist only on a product page.

It can appear inside a collection, a story, a comparison, a recommendation, a campaign, or a personalized experience, while remaining the same underlying object.

That is a fundamentally different way of thinking about e-commerce architecture.

OOUX ATOMIC

OOUX and Atomic Design: Two Layers of the Same System

OOUX helps define the objects and relationships that make up a digital product. Atomic Design addresses a different layer: how the interface itself is constructed from reusable components.

Atomic Design, introduced by Brad Frost, describes an interface as a hierarchy of atoms, molecules, organisms, templates, and pages. A button, form field, or typographic element can become part of a larger reusable component, which can then be assembled into increasingly complex interface structures.

The important idea for e-commerce is not the terminology itself.

It is that the page is not the primary unit of the interface.

A new campaign, product category, market, or customer journey should not automatically require designing an entirely new interface from scratch. A well-structured system can recombine existing components around different content and business objects.

This is where OOUX and Atomic Design complement each other.

OOUX describes what the business consists of.

Atomic Design describes how the interface presents it.

One operates primarily at the level of the product’s conceptual model; the other at the level of its visual and interaction system.

Together, they provide a useful foundation for a modular e-commerce architecture.

ORGANISM NOT ATOMS

We Start With the Organism, Not the Atoms

There is an important nuance in how we apply these ideas.

We like Atomic Design, but we don’t begin by drawing atoms.

We begin with the living organism.

We study real businesses, real websites, real customer journeys, and recurring patterns across a category. We look at how different parts of the experience interact and how the system changes depending on the user’s intent.

Only then do we break that system down into reusable components.

This matters because designing from the smallest elements upward does not automatically produce the right product.

You can create a beautifully constructed design system and still build the wrong experience.

A perfectly consistent button does not tell you whether the customer should see a button at that moment.

A technically elegant component does not tell you whether a customer needs a product comparison, a conversation with an expert, a material story, or simply a faster path to checkout.

Consistency is valuable. Context determines whether the component belongs there at all.

This is why our process moves between different levels of abstraction rather than following a purely linear design sequence.

We look at the business as a whole, identify its objects and journeys, and then determine which interface components can express those relationships consistently.

CONSIDERED PURCHASE

Why This Matters for Considered Purchase

The distinction becomes particularly important when designing e-commerce for a considered purchase, the same territory we cover in Why Luxury E-commerce Breaks Every Rule of Conversion Optimization.

A customer purchasing an inexpensive, familiar product may arrive with high intent and very little need for exploration.

A customer considering a piece of jewelry, a luxury product, a property, an expensive piece of furniture, or a complex B2B solution may have a completely different decision process.

They may need:

• product information;

• comparison;

• provenance;

• expert guidance;

• social proof;

• technical documentation;

• a story behind the product;

• a consultation;

• time to return and reconsider.

These aren’t necessarily steps in a fixed funnel.

They are independent parts of the experience that can become relevant at different moments.

That distinction is important.

If all of these elements are hard-coded into one linear journey, the interface becomes rigid. It may work well for one type of customer while creating unnecessary friction for another.

A modular architecture allows the same underlying objects to appear in different contexts.

A product can be presented alongside its story.

A collection can be connected to its designer.

A material can become an entry point into a group of products.

An expert can become part of a purchasing journey rather than an isolated “Contact Us” page.

The system becomes capable of reflecting how people actually make decisions.

PAGES TO MODULAR

From Pages to a Modular Experience

This is also why we don’t see the future of e-commerce as necessarily “page-less.”

The page is still useful.

People need URLs. Search engines need crawlable documents. Content needs context. Users still navigate between meaningful destinations.

The important shift is that pages no longer have to be the fundamental building blocks of the product.

A page can be a composition of reusable business objects and interface modules.

The same product might appear on a category page, a collection, a campaign, a recommendation module, a comparison experience, or a personalized landing page without becoming a separate version of the product every time.

This creates a more flexible e-commerce information architecture.

It also makes the product easier to evolve.

A new market may require a different combination of existing components.

A new campaign may require a different composition.

A new customer journey may expose a missing relationship between two objects.

Instead of rebuilding the entire website, the system can evolve by recombining and extending what already exists.

That is the practical value of modularity.

It is not about making architecture fashionable.

It is about preserving the ability to change your mind.

And that becomes increasingly important as digital products become more intelligent.

AI AND STRUCTURE

AI Needs a Structured Product to Work With

AI is changing how digital experiences can be personalized, but personalization does not begin with an AI model.

It begins with the structure of the product.

If an e-commerce website is essentially a collection of isolated pages, there is relatively little for an intelligent system to recombine beyond text, images, or predefined recommendations.

But if the product has structured relationships between:

products → collections → materials → stories → experts → services → customer intent

then those relationships become usable by a personalization layer.

AI can help determine which objects, information, or actions are most relevant to a particular visitor and assemble an experience around them.

This is one reason the architectural decisions we make today can affect what becomes possible several years from now.

We don’t believe every e-commerce business needs AI orchestration today.

It doesn’t.

But a business should avoid making future personalization unnecessarily expensive by hard-coding every experience into isolated pages.

The more modular the underlying system, the more options remain available.

This is also where our thinking connects with the ideas we explored in What Happens to E-Commerce When a Website Stops Being a Website?, our piece on Callimacus and AI-driven interface orchestration. The idea is not that AI should replace the architecture of the product. Rather, AI can eventually operate on top of a structured system of reusable objects and modules, dynamically composing an experience according to context.

In other words:

OOUX defines the objects. Atomic Design defines reusable interface components. AI can eventually decide how those components and objects should be combined for a particular context.

That is a much more interesting future than simply putting a chatbot on a product page.

AI Is a Mirror of the People Using It

There is another AI-related change we see much earlier in the process.

Increasingly, clients arrive with specifications created with ChatGPT, Claude, Perplexity, Copilot, or other AI tools.

We use these tools ourselves, extensively.

In development, research, writing, analysis, documentation, and many routine parts of our workflow, AI can save enormous amounts of time.

There is nothing inherently wrong with an AI-assisted specification.

In many cases, it can make the process significantly faster.

The important question is what thinking sits behind the document.

AI can produce an exceptionally polished specification from a shallow research process just as easily as it can help an experienced team produce a very strong one.

The difference is not necessarily the model.

It is the expertise guiding the work.

A founder understands things about the business that an external consultant may never see.

A marketer understands acquisition and positioning.

A business analyst sees processes, dependencies, and requirements.

A UX specialist studies behavior and interaction.

A project manager understands resources, delivery constraints, and implementation.

A sales team sees objections and decision-making that may never appear in analytics.

None of these perspectives is complete on its own.

AI is a mirror of the person using it.

When several complementary specialists bring their expertise together and use AI to accelerate their respective work, the result can be significantly stronger, and much faster, than traditional research and documentation alone.

The goal is not to avoid AI.

The goal is to make sure that AI is accelerating good thinking rather than simply accelerating assumptions.

TECH FOLLOWS PRODUCT

Technology Should Follow the Product

Once the business model, customer journey, objects, and experience have been understood, the technology decision becomes much more straightforward.

This is where we often see another common mistake: choosing the technology first and then trying to make the product fit it.

A team knows Laravel particularly well, so the project becomes Laravel.

Another team specializes in Shopify, so everything becomes Shopify.

Someone prefers React.

Someone else argues that Symfony is better for large teams.

These can all be technically reasonable choices.

They can also be completely irrelevant to the actual business problem.

There is no universally correct e-commerce platform or framework.

For one business, WordPress may be more than sufficient. Another may be perfectly served by Shopify. A different product may genuinely require a custom application, a Laravel-based headless architecture, or a more sophisticated backend. Getting this decision wrong is expensive to fix later, we cover that risk directly in The Hidden Cost of Choosing the Wrong Architecture.

The decision depends on factors such as:

• product complexity;

• number and type of products;

• integrations;

• internal workflows;

• expected growth;

• personalization requirements;

• content architecture;

• team capabilities;

• security and compliance requirements;

• maintenance model;

• and the expected life of the product.

Technology is an implementation decision.

It should be the consequence of understanding the product, not the starting point for defining it.

This also changes how we think about cost.

A technically impressive architecture is not automatically a better investment. The right question is whether the additional complexity creates measurable value for the business.

Sometimes the most sophisticated solution is exactly what the project needs.

Sometimes it is an expensive way of solving a problem the business doesn’t actually have.

LAUNCH AND RESEARCH

A Digital Product Has to Work After Launch

A website is not finished when the development team deploys it.

That is particularly true for e-commerce.

Once real customers start using the product, we finally have something that no amount of theoretical research can completely reproduce: real behavior.

Analytics reveal where people enter.

Search data reveals what they are looking for.

User behavior shows where they hesitate.

A/B testing can challenge assumptions.

Sales teams hear objections that never appear in analytics.

Customer support discovers questions that the original information architecture never anticipated.

And suddenly the product starts teaching us something.

This is why we often treat launch as the beginning of an iterative process rather than the end of development.

The first version gives us evidence.

That evidence informs the next version.

The next version produces more evidence.

Over time, the product becomes increasingly aligned with the business and its customers.

This is also where the logic of an MVP can be useful, a topic we've covered in more depth in MVP Isn't a Minimal Product. It's the Cost of Entry., but MVP should not mean unfinished or carelessly designed.

A well-designed MVP can be visually polished, technically sound, and completely professional.

What makes it an MVP is not poor quality.

It is the scope of what we choose to validate before committing to the next level of investment.

This distinction can save businesses enormous amounts of money.

A company can spend a large budget building a sophisticated platform and only discover afterwards that customers do not behave as expected.

Or it can launch a smaller but carefully designed product, test the assumptions, learn from real users, and then invest in what the evidence supports.

The latter approach doesn’t eliminate risk.

It makes the risk visible earlier, when changing direction is still affordable.

Research Is Not a One-Time Phase

This is another reason we don’t think of research as something that happens only at the beginning of a project.

The initial research establishes hypotheses.

The market tests them.

The product generates new information.

That information changes our understanding.

The process becomes iterative:

Research → Hypothesis → Design → Launch → Measurement → Learning → Refinement

Sometimes the result confirms the original architecture.

Sometimes it doesn’t.

Both outcomes are useful.

In practice, this is one of the biggest advantages of treating a digital product as a system rather than as a finished collection of pages.

A modular system can evolve.

A rigid one tends to accumulate patches.

BUSINESS BEFORE INTERFACE

The Business Comes Before the Interface

After working across different industries and digital products, this has become one of our strongest principles:

We don’t design websites independently from the businesses they represent.

We design digital products as part of a larger business system.

That means understanding how marketing creates demand, how sales converts it, how operations fulfill it, how content supports it, and how customers move through the entire experience.

Only then does UX become meaningful.

Only then does information architecture become meaningful.

Only then can we make a sensible decision about technology.

And only then does a design system become more than a collection of beautiful components.

This is also why we don’t simply execute every requirement exactly as it arrives.

Sometimes the best thing we can do for a client is build precisely what they asked for.

Sometimes the best thing we can do is challenge the requirement before anyone writes a line of code.

The distinction is not about being difficult.

It is about understanding what we are responsible for.

If we know that a proposed solution is unlikely to work, simply implementing it because it appears in the specification is not expertise.

It is execution.

And there is a difference.

FIRST QUESTION

The First Question Is Not “What Should We Build?”

The most useful way we have found to think about e-commerce is therefore not as a set of pages, and not even as a collection of screens.

It is a system of objects, relationships, journeys, and decisions.

The objects give the business structure.

Customer journeys give that structure context.

UX determines how people interact with it.

Atomic Design gives the interface a reusable visual language.

Technology provides the infrastructure required to operate the system.

Analytics and testing show us how it behaves in reality.

And AI increasingly gives us the possibility of adapting parts of that experience to individual users.

Each layer has a different job.

Confusing them is what creates many of the problems we see in digital projects.

Starting with technology can lead to unnecessary complexity.

Starting with pages can create rigid information architecture.

Starting with UI can produce beautiful interfaces that don’t solve the right problem.

Starting with AI can produce impressive features without a meaningful role in the customer journey.

Starting with the business gives us a different path.

The First Question Is Not “What Should We Build?”

When a new e-commerce project begins, there are hundreds of questions we could ask about design, technology, functionality, content, and performance.

But there is one question that comes first:

What is this business actually made of, and what experience does the customer need in order to move through it?

Once we can answer that, the rest becomes a design problem.

We can identify the objects.

Map the journeys.

Study the market.

Define the architecture.

Choose the appropriate technology.

Build the design system.

Launch the first version.

Measure what happens.

And continue evolving the product.

That is the reason we don’t see e-commerce UX design as simply designing an online store.

We see it as designing the digital layer of a business.

And that layer needs to be flexible enough to work today while remaining capable of changing tomorrow.

Because the strongest e-commerce products are not the ones that were designed to remain exactly as they are.

They are the ones designed to evolve.

Related reading

The ideas in this article connect directly with several areas of our work, including considered purchase and luxury e-commerce, modular digital experiences, OOUX and Atomic Design, and AI-driven interface orchestration. The modular approach described here is also the architectural foundation behind what we explored in What Happens to E-Commerce When a Website Stops Being a Website?: an AI system can dynamically assemble an experience only when the underlying product has already been structured into meaningful, reusable objects and modules.

The page is not the product. The interface is not the business. And technology is not the strategy.

The strategy begins with understanding what the business, and the experience around it, actually consists of.

Author: Yevhen Borovoi, Founder at Peretz Agency.