Picture this: You run an eCommerce store, and business is booming in your home country. Feeling confident, you decide to expand into new markets. You translate your website into a few languages, but something's amiss. Your sales aren't hitting the expected numbers, and customers seem less engaged. What went wrong?

This is where Cross-Cultural Design comes to the rescue. Cross-Cultural Design (CCD) recognizes that every culture is unique and influenced by its values, traditions, and preferences. Ignoring these cultural nuances can lead to missteps, missed opportunities, and the alienation of potential customers.

In this article, we'll take you on a laid-back journey through the exciting world of CCD, explaining why it's a game-changer and how to navigate it effortlessly.

## The Principles of Cross-Cultural Design

Thinking about how cultural differences can influence users' needs and expectations isn’t an easy task, and we at Nebulab know it very well: we’re not only fully distributed, but we also work with brands from all over the world. Local preferences, navigation, and information hierarchy are just some of the aspects that can be influenced by cultural, behavioral, and economic elements.

In theory, User Research should help designers understand what their audience expects from digital interactions. Unfortunately, most behavioral research studies–which User Research practitioners take a lot of inspiration from–[are based on Western subjects](https://www.youtube.com/watch?v=Ho6OlPrD7sA)). This leads to the majority of design and user experience benchmarks being Western-centric, which creates obvious problems for teams that are designing for a non-Western audience.

In light of these challenges, broadening our perspectives becomes even more difficult: without reliable data and benchmarks, how can designers operate effectively without sacrificing speed?

That’s where Cross-Cultural Design comes to the rescue: rather than providing a set of steps to follow, it offers a set of principles that designers should keep in mind when operating outside their zone of “cultural comfort.” These principles will guide you to approach your work differently, which, in turn, will help you make better choices for your design, content, and technical strategy:

* **Embrace Cultural Immersion**: Dive into the culture you're designing for, immerse yourself in its nuances, and understand its values, traditions, and aesthetics. This deep understanding will help you create designs that resonate with the local audience.
* **Research Creative Communities**: Explore the creative communities within the culture. This involves understanding how artists, designers, and local creators express cultural identity. Drawing inspiration from these communities can enrich your design.
* **Work with Experts**: Collaborate with experts or individuals with in-depth knowledge of the culture. Their insights can provide invaluable guidance and ensure your design is culturally sensitive and authentic.
* **Question Assumptions**: Challenge assumptions and preconceptions about the culture. Be open to reevaluating your design choices based on real-world insights and user feedback rather than relying on stereotypes or biases.
* **Prioritize Flexibility**: Design with flexibility in mind. Recognize that cultures evolve, and your design should adapt to changing norms and preferences. A flexible design can better withstand the test of time and evolving cultural trends.

Now that we've explored these guiding principles, let's dive into two crucial concepts closely related to cross-cultural design: internationalization and localization.

## Internationalization and Localization: You Need Both!

The most fundamental challenge teams face when working on a cross-cultural project is ensuring the content, branding, and design are flexible enough to accommodate multiple languages, nationalities, and cultures. This process is called _internationalization_ (often abbreviated as _i18n_). **Internationalization involves creating digital experiences that work across cultures.**

On the other hand, **localization (_l10n_) involves tailoring a product to a specific culture.** Localization encompasses modifying UIs, adjusting layouts and styles, revising content and language, and tailoring and enhancing the user experience to suit the needs of the particular audience you’re designing for.

In other words, while internationalization is more about having a framework in place to adapt your product to a global audience, localization is about doing the actual work of adapting your product for each audience you want to serve.

Because internationalization mainly falls on the shoulders of your engineering team, we won’t focus on it in this article. Different eCommerce platforms and software libraries have different internationalization capabilities–make sure your engineering team is aware of any cross-cultural requirements and uses that information to inform their technical choices.

Instead, let’s explore the most common aspects that you need to consider when _localizing_ your design systems and digital experiences, particularly when it comes to eCommerce.

### Names and Addresses

It's essential to understand that cultural differences extend to the most basic elements of your user experience, such as how names or addresses should be collected and formatted.

For example, when we designed the checkout form for a Pakistani marketplace, we learned that Pakistani individuals will often have a first name, a middle name (which is typically their father's name), and a last name (family name or surname). With that requirement in mind, we decided to scrap the “First name” and “Last name” fields, typical of Western cultures, in favor of a single “Your name” field instead.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/3cc7341fef23a9a7996314c04bb0f694078be97b-1600x1052.jpg?fit=clip" alt="Unified field for first, middle and last names">
</figure> 

The same applies to addresses: in the form below, you might have noticed that there is no ZIP Code field–that’s because there are no ZIP codes in Pakistan. For our client [Framework](https://frame.work/), on the other hand, we’ve had to adapt the ZIP code field to allow both 3+2 and 3+3 codes in Taiwan.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/9ba2719bc3b73d7a9af55685588fbde123c4fbf8-1600x1052.jpg?fit=clip" alt="Framework's shipping address form for Taiwan">
  <figcaption>Taiwan’s introduced 3+3 ZIP codes in 2020 to improve mail sorting efficiency.</figcaption>
</figure>


### Text Direction

One of the most significant layout challenges encountered while localizing a South Eastern client’s eCommerce experience was supporting right-to-left (RTL) text in Lebanon.

That kind of change doesn’t just involve the actual text but also requires shifting the overall content and “mirroring” certain UI elements:

* **Headers, labels, and text should be oriented from right to left**. In eCommerce, that means displaying the brand’s logo on the right and the cart icon on the left.
* **Navigation buttons** must be mirrored, but icons that do not convey direction should remain unchanged.
* **Checkboxes** should be positioned to the right of their corresponding label.
* **Progress bars** should fill in a right-to-left direction.

Later in this article, we will explore tools to assist designers in this process.

### Linguistic Nuances

Very often, translating your UI and content is just the first step. It’s crucial to remember that each language has its quirks and nuances.

A common problem is that UI elements that look good in English might not be suitable for other languages. As an example, the German language allows stringing together multiple nouns to express complex concepts, which leads to some very long words that cannot be readily displayed in a mobile button.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/0e17cec623f050d16c9a7d4dc23019effd576e6c-1600x1052.jpg?fit=clip" alt="German vs. English UI in Framework">
</figure>

Another consideration is that the formatting of numbers, phone numbers, and currencies varies in each language. Using the same phone number or currency format across different languages is bound to cause confusion and friction for the user.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/b949ccdab489f172ff0e28a913d61c54d49da452-1600x1052.jpg?fit=clip" alt="Framework's checkout flow">
</figure>

### Payment Methods

Credit card usage is widespread in Western countries, while digital wallets and cash-on-delivery are preferred in many Asian markets. Adapting payment options to local preferences can dramatically enhance the customer experience and your conversion rates!

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/b8e24cd97481e4b71bb924ac1b5019328afb9c57-1600x1052.jpg?fit=clip" alt="OLX Mall's payment method selector">
  <figcaption>In some countries, cultural, historical, and socio-economic factors led to a deep-rooted preference for cash payments, even in online transactions.</figcaption>
</figure>

### Sign-In Preferences

Even something as familiar as the sign-in process can vary across cultures. In Western markets, users typically register for websites or online services using their email addresses. However, in Eastern countries, most users prefer to use their phone number.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/2a7306fd9abf204f991c15a7cdfab56224db629c-1600x1052.jpg?fit=clip" alt="Sign-in modal that supports phone numbers">
  <figcaption>In many Eastern countries, phone numbers, not emails, are the preferred method identification for creating online accounts.</figcaption>
</figure>

### Social Proof

In the world of eCommerce, trust is the cornerstone of successful transactions. Yet, how trust is built and perceived can vary significantly across cultures: some cultures prioritize the prominent display of security badges for reassurance, while others emphasize customer reviews and testimonials to instill trust in a website.

Understanding these cultural nuances is pivotal in crafting an effective eCommerce strategy that resonates with diverse audiences worldwide.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/ae4f65150f404d46b77a0fd1f3f6f6ea2d4ef6db-1600x1052.jpg?fit=clip" alt="Shop Safely badge in OLX Mall's checkout flow">
  <figcaption>In OLX Mall, we displayed a “Shop Safely” badge through the entire checkout flow.</figcaption>
</figure>

### We’re Not Even Done

If that wasn’t enough, here are a few more aspects you should consider when designing eCommerce experiences for a global audience:

* **Information Density:** Cultural differences can affect how users expect information to be organized. In some cultures, users may love maximalism and appreciate detailed product descriptions, rich user interfaces, and bright colors, while in others, a more minimalist approach might be preferable.
* **Taxation:** How you apply taxes is dictated by regulatory requirements, but different cultures also have different norms for where and when taxes should be displayed. For specific audiences, showing tax amounts in the wrong place or at the wrong time can increase friction and cart abandonment rates.
* **Imagery:** When picking and displaying images, it’s essential to be mindful of each culture’s sensitivities. You also want to be aware of home and mobile internet speeds in the countries you’re serving: serving a 5MB product image to someone on a 3G connection might not be the best idea!

It would be hard–if not impossible–to provide a comprehensive list of all the elements you should pay attention to. Instead, we recommend constantly referring to the principles of Cross-Cultural Design and using them to inform your day-to-day decisions.

## Sharpening Your Toolkit for Global Design

With localization becoming increasingly important, all the most popular design tools support non-Latin languages and offer features that help in designing for cross-cultural projects.

### Use the Right Figma Plugins

Figma's support for RTL languages is relatively new, having been available for about two years. To change the default [text direction](https://help.figma.com/hc/en-us/articles/4972283635863), select the main menu and go to **Text > Text direction**. Then, when you use the Text tool, the text direction will be set automatically.

There are also several plugins available that let you add your translations quickly and easily. Our favorite ones are:

* [Translator](https://www.figma.com/community/plugin/743218037112142643/translator), which boasts support for 130 languages and translates entire pages very quickly, making it an excellent choice for a quick preview of your layouts in various languages.
* [Cube Translation](https://www.figma.com/community/plugin/1205127328344023071/cube-translator), which uses AI to enhance translation accuracy and provides more robust tooling for real-time collaboration and content synchronization.

As always, your mileage may vary, so we encourage you to experiment with a few different plugins and pick the one most suited for your use case!

### Choose Multilingual Fonts

Selecting the appropriate font for an international project can be a challenging task. It's important to note that not all web fonts support multiple languages, and in some cases, you might encounter unreadable rectangular symbols (referred to as "Tofu").

Multilingual fonts are specifically crafted to solve this problem and accommodate various languages. The most comprehensive open-source, multilingual font family is [Noto](https://fonts.google.com/noto) (its name stands for “no tofu”), and it offers support for more than 1,000 languages.

If you want something more unique, [Google Fonts](https://fonts.google.com) provides a variety of fonts that are either multilingual or designed for specific languages–you can easily find them by applying the language filter to your search.

![Hello is written in different languages with Noto font](https://cdn.sanity.io/images/kqgmf0g2/production/f885f7fee73faf86874c394e4ff0d91df07f1849-1600x1052.jpg?fit=clip)

### Adapt Your Images

As we’ve mentioned, a critical aspect of images is cultural inclusivity. Culturally inclusive images are significant as they portray diversity and support representation. If you have a dedicated creative production team, work with them to develop assets that are suitable for your audience. If you don’t, websites like [Unsplash](https://unsplash.com/) have handy search tools to help you find what you need.

Once you have your images, you also want to ensure they’re optimized for your audience’s internet speeds. [TinyPNG](https://tinypng.com/) is often the go-to choice and, despite the name, also works with JPG and WebP files. We recommend pairing it with a robust CDN for optimizing images on the fly.


## Ready To Take On the World?

As explored in this article, culture plays an immense role in shaping how people interact with and perceive the digital shopping experiences we create for them. As you expand internationally, recognizing these influences is not just a consideration but the key to thriving in an increasingly diverse eCommerce ecosystem. Cross-Cultural Design can help you do just that.

If you have questions on how to make these principles work for your team, or need help designing for a global audience, [feel free to reach out](https://nebulab.com/contact-us)–we’d love to chat!

Expanding Your Brand Globally With Cross-Cultural Design

For an eCommerce brand, replatforms are always exciting projects that hold a lot of promise: a replatform can come with increased flexibility, lower maintenance costs, and a better customer experience that can significantly impact your top-line growth.

However, replatforms are also incredibly stressful and can quickly become a nightmare when they’re not planned or executed appropriately: because they’re large and irreversible projects, it’s easy to miss something important and only realize it too late. Suddenly, what was supposed to be a growth driver for your business turns against you, leaving your board, team, and customers unhappy.

In this article, we will share some strategies we follow when guiding our clients through a replaform, from picking your new eCommerce platform all the way through implementation and launch. Hopefully, we can help make your next replatform a bit less scary!


## 1. Start With the Why

This one should be obvious, but you’d be surprised how many store owners cannot clearly articulate why they are executing a replatform.

A replatform project is a big undertaking from many perspectives:

* **It takes time**: replatforms will take up a lot of your team’s time and energy. In our experience, most re-platforms take anywhere between 2-5 months, depending on the complexity of your online store. Enterprise replatforms can take years!
* **It’s expensive:** replatforms are expensive projects, no matter whether you use your internal team or work with an agency. Trying to cram a replatform into a tight budget is a recipe for disaster, so make sure you can allocate the right resources.
* **It’s risky:** re-platforms are inherently risky. While most software projects can be approached incrementally, re-platforms require a big-bang transition, dramatically increasing the likelihood of something going wrong.
* **It impacts morale:** for some of your team members, the replatform will come with a steep learning curve, considerable disruptions to their existing workflows, and even fears about their career opportunities (“Will this new skillset make me less relevant?”).

With all that is at stake, you want a crystal-clear understanding of why you need to replatform: you owe it to your team, your customers, and yourself. Some of the most common scenarios in which it makes sense to do a replatform are:

* **To increase flexibility.** If your platform is consistently preventing you from executing your digital roadmap, then it’s time to look for more advanced vendor–that is, provided that your roadmap is the result of an [intentional, data-informed product management workflow.](https://nebulab.com/blog/ecommerce-product-management)
* **To support growth.** If your existing platform is having growth pains, then you might want to switch to a more scalable solution that will support your brand’s long-term plans.
* **To reduce maintenance costs.** Some platforms are more expensive than others to keep up and running. Sometimes, this is an acceptable cost to pay for certain benefits (such as additional features), and sometimes it’s a non-justifiable expense.
* **To access a larger ecosystem.** If you can’t find any partners or system integrators willing to work with your current setup, and this is preventing you from reaching your business objectives, then it might be time for a change.

There are also many _bad_ reasons to do a replatform, such as your team only having experience with a specific stack (they can learn a new technology), fear of missing out because everyone else is using a different solution (they are not you), or an investor pushing you hard to make the switch (it’s unlikely they fully understand your business needs).

We suggest writing a [Request for Comments](https://nebulab.com/blog/driving-organizational-change-with-rfcs) about the replatform. This will help you analyze your motivations and assumptions, evaluate potential alternatives, and ensure that a replatform is the right move for your eCommerce store.

RFCs have the added benefit of helping you build commitment and create alignment on the project internally–and believe us, it’s something you will need badly if you move forward.


## 2. Think Brand First, Not Vendor First

So, you wrote an RFC, you discussed it with your team, and you’re all aligned on your motivations. The next question is, how do you compare the capabilities offered by different vendors?

Nowadays, there are tens of eCommerce platforms to choose from. As in most crowded software categories, they all offer a base layer of foundational functionality and a certain number of differentiators that make them stand apart. Some of these differentiators will be useful for your specific needs, while others are just marketing stunts that will lure you in but ultimately prove irrelevant.

When approaching a replatform, we typically categorize business requirements in one of three buckets–Big Rocks, Pebbles, and Sand:

* **Big Rocks:** these are major pieces of functionality. They are highly specific to your brand promise and business model. For membership-based brands, for instance, the #1 Big Rock is their membership billing engine.
* **Pebbles:** these requirements are still important but not unique to your brand. An example would be your average ERP or 3PL integration. For most brands, there’s not a lot of innovation involved in these foundational eCommerce features.
* **Sand:** these are minor requirements that can be taken more or less for granted. Most cosmetic improvements, such as the image carousel on your PDP, fall into this category.

![](https://cdn.sanity.io/images/kqgmf0g2/production/ee19cec17172531bd1e236882c503471ca249262-3200x2104.jpg?fit=clip)

Once you have this mapping, you can understand how the platforms you’re evaluating will solve your requirements, prioritizing each requirement depending on how it’s been categorized. Feel free to ask the vendors you’re considering for help during this phase: after all, they know their own solutions inside out. However, you should always double-check their claims, as they are bound to be biased.

Whatever you do, make sure you base your comparison on your actual requirements–not on the narrative each vendor tries to push, nor on the hype around their product. It is ultimately irrelevant how many features or apps an eCommerce solution offers if you only use a tiny fraction of them. **Technology is just a tool: your platform should fit your brand, not vice versa.**

A platform-agnostic agency is the best partner for this kind of project: they have the expertise to advise you, but they are not married to one specific solution, which gives them the freedom to offer you what they genuinely believe to be the best path forward.


## 3. Account for All the Expenses

Platform and transaction fees are a _significant_ part of any eCommerce brand’s P&L statement. When replatforming, you should clearly understand the costs you’ll incur under the new tech stack if you don’t want any unpleasant surprises.

Unfortunately, many brands jump the gun here and only account for the most apparent and immediate costs, such as their platform’s transaction fees in the first year. As a result, they neglect other variables that are not as visible but equally important, only to get burned by their new vendor once it’s too late to go back.

When approaching a re-platform, we typically categorize the costs as follows:

* **License fees:** this is how much you’ll pay your vendors for access to their services. Most brands only include the cost of their eCommerce platform here, but you should also account for any third-party apps and services you will need.
* **Transaction fees:** these are the fees you pay on your payments, and they typically have fixed and variable components. Some platforms have integrated payment gateways with lower transaction fees, while others will require you to work with a third party.
* **Maintenance fees:** we would all love to use an eCommerce platform that requires zero maintenance, but that is rarely the case. While you can’t calculate precisely how much design and development effort you’ll need with your new platform, you should make an educated guess and understand how that compares with your current setup.
* **Replatform fees:** how much will it cost to execute the replatform? Assuming that your goal is reducing engineering spend, how long will it take you to recoup that initial investment under the new platform?

When evaluating these costs, you also want to understand how they will change as your brand grows: what would they look like at 2X your current scale? Does pricing grow linearly, more than linearly, or less than linearly? Will there be room for negotiation, or are you locked into this commercial structure forever? Does the new vendor have any minimum commitments?

Every platform is unique, but do your best to make an apples-to-apples comparison that clearly outlines the total cost of ownership and any pros/cons associated with each option.

## 4. Approach the Work Incrementally

Switching over to the new platform will require a Big Bang Release, where you switch your brand to your new tech stack almost overnight. This approach is typically frowned upon in software development: the more changes you’re introducing simultaneously, the more you increase the chance that something will go wrong.

The bad news is that Big Bang Releases are somewhat unavoidable with most replatforms. The good news is that there are several approaches to minimize the amount of uncertainty associated with them. In general, if you can do something _before_ you finalize your transition to the new platform, you should.

Here are a few techniques we typically adopt:

* Work closely with your in-house team or external partner to demo and test their work as often as possible. You don’t want the team to work in isolation for three months and then do your testing in one go: you’re bound to miss something or discover significant problems once it’s too late to do anything about them. Better yet, have your entire team do QA: you’ll be surprised how much more stuff you can find as a group!
* If you need to make any changes to integrations or external systems to make them compatible with your replatform, see if you can apply them beforehand in a way compatible with both the old stack and the new one. This typically applies to ERPs, WMSs, and 3PLs, but you can generalize it to other vendors.
* Test your data migrations ahead of time and continue to execute them continuously in the days leading up to the launch. That way, on launch day, you will only need to migrate a small portion of your data rather than all of it.
* Create checklists for what you will do before, during, and after the replatform. Launch day is incredibly stressful, so it’s essential your team doesn’t have to think too much about what they’re going to do.

These are just some ideas, and your mileage may vary depending on your setup and the complexity of your architecture. The rule of thumb is that you want to work in small increments and do the bulk of the work upfront, so you only need to pull the trigger on launch day.

You can also check out [this article](https://nebulab.com/blog/ecommerce-agency-productivity) we published about how to optimize your agency’s or digital team’s productivity. All of those strategies also apply to replatform projects!

## 5. Resist the Urge to Redesign

If there is one thing you take away from this article, let it be this: do NOT do a rebrand or redesign at the same time you’re doing a replatform. After over a decade of working with eCommerce brands of all sizes, we have witnessed so many failed attempts at this that we strongly discourage this practice.

There are several reasons why a redesign might be bundled together with a replaform. In our experience, it’s usually a combination of the following factors:

1. Most brand executives are visual people. During a replatform, they get understandably excited and come up with a million potential improvements to the customer experience, which often turn into a full-blown redesign.
2. The byproduct of #1 is that, in larger companies, the person sponsoring the replatform often feels the need to justify the investment to their boss through a tangible artifact, such as a rebrand/redesign. This gives them a clear “thing” to point to when someone asks them where all that money went.
3. Unfortunately, some eCommerce agencies do redesigns along with replatforms to increase the scope of the engagement, and so that the final result can be more easily turned into a compelling case study.

As we already mentioned, this is almost always a bad idea. Replatforms are complicated and risky, so you want to keep their scope as small and controlled as possible. Redesigning your website while uprooting its tech stack dramatically increases the risk of something going wrong during or after the launch. It also makes it much harder to isolate and measure the business impact of specific changes to the customer experience.

We suggest keeping the new website as similar as possible to what you had before. After you launch the replatform, you’ll have plenty of time to fully leverage the capabilities of your new tech stack, so there’s no reason to rush it.

## 6. Prioritize the Scary Stuff

Remember that Big Rocks, Pebble, Sand categorization we talked about earlier? That’s not just a way to map your business requirements, but it’s also an excellent mental model to keep in mind when prioritizing the different features involved in your replatform:

1. Big Rocks are the most critical problems to solve and carry the highest risk and uncertainty, so you want to get them out of the way as early as possible.
2. Pebbles are essential but less risky–you want to get them done and tested early, but not before you’re done with the Big Rocks.
3. Sand is irrelevant: while some of these features are important to your business, they’re also quick and easy to implement and can be left for last.

Unfortunately, we often see things being approached in the opposite order. Because it’s easier and faster to make progress on Sand than on Big Rocks, they focus on the lowest-hanging fruit while neglecting the big, scary problems screaming at them.

One brand we spoke with in the past, which was heavily subscription-based, reached the last week of their replatform without having done any work on their subscription engine yet. When they finally focused on it, they realized the provider they had picked wouldn’t be able to accommodate their needs, and they had to cancel the launch and go back to the drawing board.

To keep your team focused, it can be helpful to appoint a Product Owner/Project Lead. This person, who ideally has project management experience and understands your brand inside out, will be responsible for keeping track of the project’s progress and ensuring the team is prioritizing the work correctly.

One last word of warning here: remember that perfect is the enemy of good. Just like with the redesign, you’ll have plenty of time to improve your online store after the launch, so don’t get bogged down in pursuing tiny optimizations at the expense of bigger achievements.

## Launch and Celebrate!

If you follow the tips above, launch day should be much less stressful than it could have been. Just follow your checklists on launch day, sit back, and celebrate!

Besides that, now is the time you can fully unleash the true power of your new eCommerce stack. As always, make sure to move intentionally and be data-informed–[establishing a lightweight Product Management practice](https://nebulab.com/blog/ecommerce-product-management) can do wonders in ensuring you’re not getting ahead of yourself, but working on features that will actually move the needle.

We hope we managed to shed some light on what is typically a long and confusing process for any brands that go through it!

If you need additional help with your replatform, [don’t hesitate to reach out!](https://nebulab.com/contact-us) Our team works with a variety of eCommerce platforms. They would be more than happy to advise you on the best choice for your brand and guide you through the entire implementation and launch process.

How To Nail Your eCommerce Replatform

If you have been working with Shopify’s Hydrogen framework for some time, you might still have some scars after the
[migration from Hydrogen v1 to Hydrogen v2](https://nebulab.com/blog/shopify-hydrogen-v2-updates).

One of the major changes in Hydrogen v2 was the transition from a custom-built React framework to
[Remix](https://remix.run/), a relatively new framework that is seeing a lot of traction thanks to its streamlined
developer experience, its reliance on Server-Side Rendering and its deep focus on web standards.

Remix was a significant improvement over Shopify’s in-house React framework, and allowed Hydrogen stores to benefit
from a much larger ecosystem of Remix docs, plugins and system integrators. We’ve discussed the benefits at length in
[our blog post covering the migration](https://nebulab.com/blog/shopify-hydrogen-v2-updates).

Unfortunately, the migration process from Hydrogen v1 to Hydrogen v2 was also incredibly complex. So much so, that many
large brands were better off re-building their storefront from scratch with Hydrogen v2 rather than attempting to port
their existing codebase. This caused a lot of discontent and frustration with Shopify’s decision, which didn’t seem to
fully appreciate the complexity of maintaining a complex headless architecture.

Now, it _feels_ like history might be repeating itself: Remix just announced a new major release. Remix v2 comes with
several new features and improvements to the developer experience that Hydrogen developers will also benefit from.
However, Hydrogen teams are also worried that the transition to Remix v2 might be their latest time-suck and source of
frustration.

But is that really the case, or are things better this time around?

In the past few weeks, we’ve been following the Remix community and trying to unpack the implications of this release
for Hydrogen. Let’s see what this release actually means for you, and how you can make the best of it!

## What’s New in Remix v2 for Hydrogen Devs?

Let’s start by taking a look at the changes and new features in Remix v2 that are most relevant for Hydrogen developers.

Keep in mind that you can always read the [release announcement](https://github.com/remix-run/remix/releases/tag/remix%402.0.0)
if you want to see the complete list of changes!

### New Dev Server with HMR and HDR

If you’ve used a more established React framework such as Next.js, you’re probably familiar with HMR even though you
might not know the acronym. HMR, which stands for Hot Module Replacement, is the feature that allows the page to update
instantaneously and reflect any changes you make to your code. It’s a handy functionality when you’re actively
developing a new page, or making small visual tweaks that you want to preview in real time.

Historically, Remix did not offer support for HMR: that meant you had to manually refresh the page whenever you made
a change to your client-side or server-side code, which was old-school and time-consuming.

Luckily, that’s not the case anymore! Remix v2 ships with a new dev server that supports HMR and Hot Data Reloading
(HDR), the equivalent of HMR for server-side code. Whenever you make a change to your Hydrogen app, it will be
propagated immediately to your browser. Client-side state is also maintained, so that you can continue interacting with
the app without restarting any user flows from scratch (e.g., if you’re in the middle of checkout).

It has support for hot module replacement (HMR) and hot data reloading (HDR). The announcement is available
[on YouTube](https://www.youtube.com/watch?v=79M4vYZi-po).

On earlier versions of Remix, whenever there was a code change, you would have to manually refresh the page to see the
new changes (pretty old-school tech). Now, that is unnecessary and HMR will not reset client-side state between updates.
And HDR can be described as HMR for data loaders. With HDR you can make changes to your server code and see those
updates reflected in your UI immediately without resetting client-side state, just like HMR.

### Native Support for PostCSS and Tailwind and PostCSS

As you probably know, Hydrogen uses [Tailwind](https://tailwindcss.com/) as the default CSS framework.

Unlike more traditional CSS frameworks (such as Bootstrap), Tailwind relies heavily on CSS post-processing to generate
your final CSS build: it scans all your files, understands which Tailwind classes need to be generated, and then
generates just the classes you need. This allows you to minimize the amount of CSS you’re shipping to the client while
also allowing you to do incredible things, like attaching [arbitrary CSS properties](https://tailwindcss.com/docs/adding-custom-styles#arbitrary-properties).

Before Remix v2, you would have to run any CSS transformations in a separate process, e.g. with
[Tailwind’s CLI interface](https://tailwindcss.com/blog/standalone-cli), then import the final CSS file into your Remix
app. This worked, but wasn’t really a smooth development experience.

Remix v2 adds out-of-the-box support for [Tailwind directives and PostCSS](https://remix.run/docs/en/main/start/v2#built-in-postcsstailwind-support),
a popular CSS processor that Tailwind integrates natively with. If you’re using Hydrogen, all the relevant configuration
is generated for you: simply bootstrap your app, and your Tailwind styles will just start compiling automagically!

Check out Remix’s documentation about [PostCSS](https://remix.run/docs/en/main/styling/postcss) and
[Tailwind](https://remix.run/docs/en/main/styling/tailwind) for more details.

### Server-Side Streaming with `defer`

This one is a game-changer. Remix v2 aims to provide first-class support for React 18's SSR streaming capabilities
through the `defer` helper.

When you return a `defer` function call in a route loader, you are initiating a streamed response. This is very
useful when serving lower-priority data that may take longer to load. After all, you don’t want your users to wait on
slow data if more important content is ready to display on the page!

Here’s an example of what streaming looks like on the server:

```javascript
import { defer } from "@remix-run/node";

export async function loader ({ request }) {
  // Product info query is small, cached aggressively, ad
  // high priority for the user. Let’s go ahead and let it
  // resolve since it’s fast!
  let productInfo = await getProductInfo (rewquest);

  // Product reviews query is large and cache is more lax.
  // Let’s initiate the query but not wait for it to resolve.
  let productReviewsPromise = getProductReviews (request);

  // With defer, we initiate a streaming response. This allows
  // the user to access the resolved data (`productInfo`) as
  // soon as it’s available, while the unresolved product
  // reviews are loaded in the background.
  return defer ({
    productInfo,
    productReviewsPromise,
  });
}
```

The corresponding client-side code would then leverage the `Await` component, which is built on top of
[React’s `<Suspense />` API](https://react.dev/reference/react/Suspense):

```javascript
import { Await } from "@remix-run/react";

function ProductRoute () {
  let {
    // Product info has already resolved. Render immediately!
    productInfo,
    // Product reviews might not be ready yet 🤔
    productReviewsPromise,
  } = useLoaderData ();

  return (
    <div>
      <h1>{productInfo.name}</h1>
      <p>{productInfo.description}</p>
      <BuyNowButton productId={productInfo.id} />
      <hr />
      <h2>Reviews</h2>
      <React.Suspense fallback={<p>Loading reviews…</p>}>
        <Await resolve={productReviewsPromise} errorElement={<ReviewsError />}>
          {(productReviews) =>
            productReviews.map ((review) => (
              <div key={review.id}>
                <h3>{review.title}</h3>
                <p>{review.body}</p>
              </div>
            ))
          }
        </Await>
      </React.Suspense>
    </div>
  )
}

// Error fetching the data? Slow connection and timed out?
// Show an error message *only* for reviews. The rest
// of your product UI is still usable!
function ReviewsError () {
  let error = useAsyncError (); // Get the rejected value
  return <p>There was an error loading reviews: {error.message}</p>;
}
```

This was a framework-agnostic example, but Hydrogen is already leveraging `defer`. On the home page, for instance,
recommended products are streamed rather than being loaded immediately:

```typescript
export async function loader ({context}: LoaderArgs) {
  const {storefront} = context;
  const {collections} = await storefront.query (FEATURED_COLLECTION_QUERY);
  const featuredCollection = collection.nodes[0];
  const recommendedProducts = storefront.query (RECOMMENDED_PRODUCTS_QUERY);

  return defer ({featuredCollection, recommendedProducts});
}
```

For more examples of how Hydrogen leverages Remix features to optimize data handling, you can take a look at
[this article](https://hydrogen.shopify.dev/update/improving-data-handling-in-hydrogen-and-remix).

### Flat Routing by Default

Older versions of Remix use subfolders to nest route segments. This leads to a lot of directory nesting, and also makes
it harder to navigate the directory tree.

Remix v2 embraces [flat routing](https://remix.run/docs/en/main/start/v2#file-system-route-convention) instead. With
flat routing, all your routes are in the same directory, which makes it easy to find them at a glance. For example,
here’s the new folder structure in a Hydrogen application based on Remix v2:

![](https://cdn.sanity.io/images/kqgmf0g2/production/59ae846180e55976494ef64fb35b7ee854107044-698x1370.png?fit=clip)

There’s a bit more to it, so we encourage you to check out [Remix’s documentation](https://remix.run/docs/en/main/start/v2#file-system-route-convention)
about the change to fully understand the new folder structure.

Since not everyone will love this change, you can also maintain the current approach by installing the
`@remix-run/v1-route-convention` package and adding the following to your `remix.config.js`:

```javascript
const {
  createRoutesFromFolders,
} = require ("@remix-run/v1-route-convention");

/** @type {import ('@remix-run/dev').AppConfig} */
module.exports = {
  future: {
    // makes the warning go away in v1.15+
    v2_routeConvention: true,
  },

  routes (defineRoutes) {
    // uses the v1 convention, works in v1.15+ and v2
    return createRoutesFromFolders (defineRoutes);
  },
};
```

## How to Upgrade Your Hydrogen Application to Remix v2

Now, this is the part you were all waiting for! How difficult is it to upgrade an existing Hydrogen application to Remix
v2? Luckily for you, not very difficult.

The typical approach for performing major upgrades to your application’s dependencies typically involves creating a
separate, long-lived feature branch, working on the upgrade in isolation, and then releasing it all in one go.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a7da987d49c9126fa8f5bc3dd60f94bbf867eea6-1516x634.png?fit=clip)

This approach, which is still very widespread, has several drawbacks:

- It is time-consuming, because it requires a lot of work and frequent rebases.
- It is prone to error, because you’re releasing a lot of changes in one deployment.
- It is all-or-nothing, because it prevents you from adopting new features before the upgrade.

Remix aims to fix this problem through [Future Flags](https://remix.run/docs/en/main/start/future-flags). Future flags
allow developers to incrementally adopt new features and then seamlessly upgrade their application, eliminating the need
for long feature branches and scary deployments.

Conceptually, the way they work is very simple: the Remix team releases Remix v2 features in Remix v1, but puts them
behind a feature flag that you need to manually enable in your Remix configuration. Then, when Remix v2 is released, the
Remix team simply removes all future flags and turns them into default behavior. This allows you to integrate one
feature at a time as it’s released by Remix, rather than doing it all in one pass.

![](https://cdn.sanity.io/images/kqgmf0g2/production/79ff3d1e16ca4fb2421871fa9cce3b5ba6a56599-1999x441.png?fit=clip)

For instance, here are the future flags for Remix v2:

```javascript
/** @type {import ('@remix-run/dev').AppConfig} */
module.exports = {
  //…
  future: {
    v2_dev: true,
    v2_meta: true,
    v2_headers: true,
    v2_errorBoundary: true,
    v2_routeConvention: true,
    v2_normalizeFormMethod: true,
  },
};
```

If you are on the latest version of Remix v1, your `remix.config.js` looks like the one above, and you’re not getting
any errors, you should be able to safely upgrade to Remix v2 by following the [official upgrade guide](https://remix.run/docs/en/main/start/v2).

If you haven’t enabled those future flags yet, then we strongly recommend doing so in the next few weeks so that you
can have a smooth upgrade path in front of you.

Note that the Hydrogen team still needs to officially release support for Remix v2, but thanks to future flags,
most of Hydrogen’s code is already compatible. All you need to do is upgrade the dependency in `package.json`, remove
the future flags in `remix.config.js`, and you should be good to go!

## What’s Next for Remix and Hydrogen?

In our work so far, we found the developer experience offered by Hydrogen through Remix is miles ahead of what we had in
Hydrogen v1. With a few lines of code, it’s possible to develop rich e-commerce experience while also abiding by web
standards and following modern UX practices. Because of that improvement, we’re very excited for the future of this
synergy!

The Remix team recently [announced](https://remix.run/blog/open-development) that they want to be more transparent about
their plans for the framework, but the [public roadmap](https://github.com/orgs/remix-run/projects/5) doesn’t offer a
lot of information yet. That means it’s still early to tell what other features might be coming up that Hydrogen
developers can benefit from.

One initiative on our radar is the [work](https://remix.run/blog/remix-v2#what-about-rsc) done by the Remix team to
integrate React Server Components (RSC). Unfortunately, this will take some more time, as RSC are still unstable and
won’t be included in Remix just yet as a result.

If you were waiting for more features or stability in order to start using Hydrogen, today is the best time to give it a
try! We’re sure you will be pleasantly surprised.

What Does Remix v2 Mean for Shopify Hydrogen Developers?

In July this year, we [announced Sprout](https://nebulab.com/blog/announcing-sprout), our product gifting app.

Sprout allows brands to efficiently run product gifting campaigns without going crazy: rather than spending days buried in Instagram DMs and spreadsheets, brands can just connect their Shopify store, set up a gift link, and share it with the influencers they want to partner with. Influencers can use the link to select the product(s) they wish to receive and enter their shipping information, and an order appears in the brand’s Shopify dashboard, ready to be fulfilled by the brand’s team. It's as simple as that!

After beta testing our MVP with some customers for a few months, we got to work on our public launch. We had a pretty ambitious goal: we wanted to have a brand and website ready to go in just two weeks so we could start marketing the app to the general public.

In this article, we’ll show you how we met our deadline by following a strict design review process and using the right tools.


## Solid Branding Means Fast Execution

Branding is much more than having a good-looking, distinctive logo. For us, branding is about capturing the identity of a company or product, and then translating that into a visual foundation that can be used across the product’s properties. **A solid brand allows you to move quickly and confidently,** no matter what kind of digital or physical experience you’re working on, and it makes you immediately recognizable by prospective and existing customers.

As always, we started by defining a compelling positioning statement and researching Sprout’s target audience and competitors. Our goal in this phase is to understand what the brand stands for: is it a disruptor, fun and playful? Or is it the real deal, serious and professional? How does the brand relate to consumers? How does it relate to its competitors? Once we had defined and finalized all these elements, we began translating them into a visual identity.

For the visual identity, we vowed not to exceed three iterations–our goal was to have the final version ready in one week, and then move on to designing and implementing the website.

In our first round, we developed four brand directions, exploring different logos and mood boards representing various archetypes or styles.

![](https://cdn.sanity.io/images/kqgmf0g2/production/8b77501dac7372a712734a4fed12462044b4ed42-1600x1052.png?fit=clip)

This was super helpful in defining the visual communication we wanted to adopt, including the color palette and font combinations.

In the second round, we mixed and matched elements from the different proposals, settled on a logo and overall mood, and then started exploring different color palettes and font families.

![](https://cdn.sanity.io/images/kqgmf0g2/production/579f077aec483366d857b9cd0380336eae5ad380-1600x1052.png?fit=clip)

In the final round, the work was nearly complete, and most of the decisions had been made. The rest was a matter of refining a few aspects of the color palette, typography, iconography, and overall visual style so that we could more easily reference them in our subsequent work.

![](https://cdn.sanity.io/images/kqgmf0g2/production/8f86d558e7b993531331a848a5f6ab070a051197-1600x1052.png?fit=clip)

At this point, we had established a brand identity and created a style guide to guide us while implementing the brand. We could finally focus on our website.

## Going From Figma to Finished Website in One Click

Figma has been our design tool of choice since its release, so it’s no surprise we also used it for Sprout. We created a quick landing page showcasing the product’s capabilities and most common use cases and allowing brands to request a demo. **Because we had defined the brand’s visual identity and UI fundamentals in advance, the original website design only underwent minimal modifications before being approved for publication.**

After finalizing the design in Figma, we typically hand it off to the engineers, who build it using whatever frontend stack has been adopted. This process leads to highly polished and sophisticated UIs but also takes more time as the engineers need to translate the designs into code and test and deploy the result.

With our two-week deadline, we needed a radically different approach: ideally, we wanted to go from Figma to the final website in one step. We also needed the ability to quickly make visual and content changes to the website after the initial publication to accommodate whatever feedback we received from existing and prospective customers.

![](https://cdn.sanity.io/images/kqgmf0g2/production/94b7e8f319893dccc16e45d1b2161346fb1b3b5b-1600x1052.png?fit=clip)

We evaluated different [content management](https://nebulab.com/blog/ecommerce-content-management) options and ended up using [Framer](https://www.framer.com/). Here’s why:

* As long-time Figma users, the Framer UI feels very familiar, and the app is incredibly user-friendly.
* Framer allows importing Figma designs by simply copying and pasting the artwork, which is game-changing for a fast-moving team.
* The Publish feature is straightforward and blazing fast: we purchased a domain and were ready in minutes.
* Framer integrates with MailChimp, Formspark, and other tools that we use for marketing and lead generation, which further reduces development time.

After importing our designs into Framer, we only had to make a few adjustments to some elements, add some animations, hit Publish, and _voilà!_ Our website was online and available to the world in one week and with zero lines of code. Not only does it require zero maintenance, but anyone with access to the Framer project can easily make content and visual changes to the website.

Finally, we were impressed with the site's performance: even though we didn’t spend time optimizing it, it got top scores in all areas of Google’s PageSpeed Insights benchmarks–hooray for SEO!

![](https://cdn.sanity.io/images/kqgmf0g2/production/b708b957da1fd024a0ec80ac742a0da740766815-1600x1052.png?fit=clip)

## Use Guidelines and Constraints to Your Advantage

While an established work process improves your team’s long-term productivity, it can sometimes hinder your goals and even impede learning. Setting an arbitrary deadline forced our team to think outside the box and temporarily move away from our typical design-development handoff process. This allowed us to go from zero to a fully established brand and website in under two weeks. 

Of course, none of this would have been possible without a solid brand in place. By establishing a clear visual identity beforehand, we minimized the communication overhead while creating [Sprout’s website](https://getsprout.app), drastically improving our turnaround time.

We will probably re-implement Sprout’s website with a more sophisticated tech stack at some point, but for now, we’re thrilled with Framer’s ease of use and flexibility. In fact, next time we do something like this, we might even try designing the website right into Framer rather than going through Figma–who knows, we might be able to shave a couple more days off the timeline!

If you’re an e-commerce brand and would like to adopt a similar approach for your next landing page or product drop, feel free to [reach out!](https://nebulab.com/contact-us) We’d be happy to help.

How We Branded Our Latest Product in Just Two Weeks

Here’s a story you might have heard before: a brand has a dedicated design team, handling everything from packaging to ad creative to Web design. The design team works closely with the brand’s executive team, constantly asking for feedback and creative direction. Because designers work so closely with the executives, there’s no need to prioritize projects: people can just talk to each other and “figure it out.”

Then, as the brand starts scaling their Web development efforts, all hell breaks loose.

The brand’s development team starts complaining that the mockups they get from the designers are useless: they’re incomplete, contain visual bugs or inconsistencies, neglect to cover obvious error cases… the list goes on and on. On their side, the designers complain that the developers have no consideration for their work and constantly introduce discrepancies between the original mockups and the final implementation. In all of this, the executive team doesn’t know where the problem lies or how to fix it.

If this sounds familiar, it’s because it happens at least once, in some shape or form, to most e-commerce brands that invest a decent amount of time into their DTC store, not to mention brands that have mobile apps or other digital properties.

In the past, I faced this conundrum several times as I designed brand identities and digital experiences for brands across different sizes and industries. **When designers and developers don’t work well together, it slows down everyone’s work and kills team morale.** It’s the kind of technical problem that has a very tangible impact on a brand’s bottom line.

Luckily, there’s a better way to work. It’s an approach I found through a lot of trial and error, and I’m delighted to share it with you today. Through open communication and clear guidelines, you can create peace of mind for executives, designers, and developers peace of mind, increasing the velocity, scale, and quality of your digital team’s output.

Let’s see how exactly!

## The Myth of the Perfect Design Handoff

When I first tried to bridge the gap between designers and developers, I did what every detail-oriented person would do when tasked with a sufficiently complex problem: create a process. My thesis at the time was that if I _just_ included enough detail in my designs to remove even the smallest amount of guesswork, developers could just translate my mockups into code one pixel at a time, and we’d all live happily ever after.

So, I started doing just that: rather than treating every project as unique, I created a thorough process for prioritizing, executing, and delivering my designs. This included elements like annotations in the designs that clearly explained what the UI was supposed to do and in what way, error states, and even Loom recordings of me going through each screen in the flow and explaining it verbally. Every time a developer had a question that I forgot to cover, I made a note and refined my template, all in pursuit of The Perfect Design Handoff™.

![](https://cdn.sanity.io/images/kqgmf0g2/production/df5a6ddad1bd6e9696f714c4c736b42d249ddf0b-1600x1052.jpg?fit=clip)

There was only one problem with this process: **it didn’t work.**

It’s not that it didn’t help: being more detailed in my handoffs made life a bit easier for our development team–at the very least, we now all agreed on the bare minimum that should be included with every new user flow.

However, it didn’t really _solve_ the problem: no matter how detailed my annotations or how long my Looms were, developers still had questions about edge cases I forgot to cover, new components that needed to be implemented, and interactions between different user flows that I couldn’t possibly have foreseen.

Furthermore, after seeing the implemented designs, product managers often provided feedback that required design changes, forcing designers and developers to redo their work. With such a detailed handoff process, this required a lot of time and slowed down delivery.

I knew we needed to try something else, so I went back to the drawing board.

## The Only Path To Order Is Chaos

After deep thought, I realized I was trying to solve the wrong problem: my theory was that designers could single-handedly collect stakeholder requirements, work on them for a week or two, and turn them into pixel-perfect mockups that contained all the information developers needed for implementation. Developers would then use that information to implement a user flow that matched the mockup pixel by pixel.

That sounds very nice in theory, but it’s virtually impossible: product managers, designers, and developers approach projects from different angles and bring different perspectives. **These three stakeholders need to collaborate constantly and provide continuous feedback on each other’s work**–only then will the final product really satisfy their needs, not to mention the needs of the brand’s customers.

With this new collaborative spirit in mind, I worked with our product and development team to completely rearchitect how we delivered new features to our customers. Rather than aiming for the perfect handoff from stakeholders to designers and from designers to developers, we started investing much more heavily in open and constant communication:

* **We established a series of recurring calls** where every member of the team would present what we were working on, no matter whether it was a product requirements document, an initial mockup for a new feature, or a code-complete user flow.
* **We encouraged everyone to offer feedback** at any point in the process and worked hard to foster a sense of psychological safety on the team, so that no one would feel like their work was “under attack.”
* **We asked team members to coach each other** on their respective areas of expertise. Designers showed developers the basics of working with Figma, while developers taught designers about their implementation process.

![](https://cdn.sanity.io/images/kqgmf0g2/production/f69a781f488e3cadaa00f1737c1e7c8143eb6898-1600x1052.jpg?fit=clip)

We kept a light process in place to create consistency in how we worked together, but also empowered everyone on the team to contribute cross-functionally. This led to several situations in which a developer provided insightful feedback on how to handle an edge case, a product leader realized that a flow didn’t feel as smooth in the real world as it did in the mockups, or a designer spotted a visual bug while testing a developer’s work.

Most importantly, **it created a sensitivity and deep appreciation for the work done by our fellow team members**, making us better at our respective jobs: designers understood the importance of component-based design, developers became more mindful of visual discrepancies, and product leaders understood that design and implementation are never going to match perfectly.

The new process didn’t fix all our problems, but it did give us the tools we needed to address them together! **Internally, we called this approach Open Design.**


## Adopting Open Design for Your Brand

As I mentioned in the introduction, it’s not uncommon for an e-commerce brand to be stuck in a sense of constant chaos and urgency or to feel constrained by an overly structured handoff process.

The root cause of the problem often lies in the fact that brand founders are very visual people, and most of their design experience lies in branding, packaging, and product design. As a result, they approach design very rigidly and try to make everything perfect before it’s handed off to their development team for implementation. This approach then cascades to the rest of the team as the company grows.

Unfortunately, the same can be said for agencies: many e-commerce agencies are design-driven and treat development as an afterthought. This leads to a lot of friction in their internal workflows or how they collaborate with their clients or other agencies.

As much as we would like to give you detailed, step-by-step instructions for how you can break out of this jail and implement an open design process for your brand, there’s only one thing you need: **people who are willing and able to set their egos aside and work together.**

As a first step, we always recommend creating stable, recurring ceremonies for cross-functional team members to talk to each other and exchange feedback. We found that **once you establish that baseline for collaboration, people will re-orient themselves around the new way of doing things, and everything else will magically fall into place.**

But if you need any help adjusting your process or are looking for an agency that lives and breathes Open Design, [feel free to reach out](https://nebulab.com/contact-us)–we’d love to help!

Boost Your eCommerce Team’s Productivity with Open Design

Here at Nebulab, we’re privileged to work with tens of brands across different categories, business models, team compositions, and revenue stages, helping them shape, launch, and refine their eCommerce experiences. Some of these brands started with us, while others used to work with different agencies and told us about their experience.

While every agency has its own culture and way of doing things, we’ve identified a few traits that separate successful brand-agency collaborations from the rest. These are not defined processes, but rather a philosophy for working together.

In today’s article, we have distilled this philosophy into five fundamental principles. When implemented, we’ve found that these principles consistently lead to dramatic increases in agency productivity and effectiveness.

If you already have an agency and would like to take your collaboration to the next level, or are looking for an agency and unsure how to evaluate their work methodology, you should dive right in!


## 1. Promote Knowledge Sharing

Many executives provide context to their agency on an as-needed basis: burned by previous experiences or just strapped with time, they create a structure where communication only flows in one direction, and the agency only knows what they absolutely need to do their job.

While this might get you the short-term results you’re looking for, it also means you’re missing out on _a lot_ of value your agency could bring to the table.

Pretty much all eCommerce agencies are verticalized–that means they only work in the eCommerce industry. As a result, they accumulate valuable expertise about industry trends, baseline performance, and best practices, not to mention the networks that they often manage to build up over time.

**If your relationship with your agency resembles an assembly line, it’s very unlikely you will ever benefit from any of their organizational knowledge.**

Instead, aim to remove all communication and knowledge barriers between your team and your agency. Give them free access to your team, and expose them to as many ceremonies and artifacts as possible–all hands, cross-functional meetings, strategy documents, and anything else that might be useful.

Once you do that, you’ll be surprised at all the different ways your agency can help you.

**Recommended read:** [Sense and Respond](https://www.amazon.com/Sense-Respond-Successful-Organizations-Continuously/dp/1633691888/ref=tmm_hrd_swatch_0?_encoding=UTF8&qid=1693399466&sr=8-4)


## 2. Demand Extreme Ownership

Here’s a controversial take: dedicated QA teams are a waste of time and money–at least in the way most brands structure them. If everything your agency does needs to pass a QA check, you’re doing it wrong.

This doesn’t just apply to QA but to any other areas where your agency needs “gatekeepers” or handholding. Instead, **you should aim for a structure where your eCommerce agency is responsible for all stages of execution:**

* Your agency should be responsible for contributing–as much as possible–to the product roadmap, based on their knowledge of your brand.
* Your agency should be responsible for refining your requirements and uncovering edge cases, problems, and needs you might have missed.
* Your agency should be responsible for QA’ing their own work, releasing it, and ensuring it’s working as expected once it’s live.
* Your agency should be responsible for proactively diagnosing and fixing the problem when something goes sideways—as it inevitably will.

If you’re reading this list and thinking, “My agency would never be able to do that,” there’s a fundamental lack of trust that you need to resolve. Perhaps they don’t have the skillset, or you tried giving them more freedom, and they failed. Talk to them openly about what you’re trying to achieve and see if the situation improves.

**Recommended read:** [Turn The Ship Around](https://www.amazon.com/Turn-Ship-Around-Building-Breaking/dp/0241250943/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1693407060&sr=8-1)


## 3. Think in Products, Not in Projects

A structured product management practice is what separates the brands that aimlessly wander from project to project and the brands that are intentionally pursuing a business strategy with their eCommerce website.

Unfortunately, many brands confuse _product_ management–the practice of collecting and leveraging quantitative and qualitative data to inform your product roadmap–with _project_ management–the practice of establishing and following a structured process in the execution of said product roadmap. Let's put it this way:

* Doing product management without project management means moving chaotically in the *right* direction.
* Doing project management without product management means moving meticulously in the *wrong* direction.

A good place to start is how you frame problems and validate solutions: **rather than just writing down business requirements, use quantitative and qualitative data to explain the business need driving a particular initiative.** Then, once a solution is implemented, use data to validate the impact of the solution.

Obviously, there’s much more to product management than just leveraging data: a good product manager is a master storyteller and can craft compelling narratives for why your brand should head in a particular direction, collaborating with different stakeholders and rallying your whole team behind a shared vision.

In the past, we have written extensively about the value of product management and how to establish a product management practice in your eCommerce team, so feel free to check out our previous articles [here](https://nebulab.com/blog/ecommerce-product-management) and [here](https://nebulab.com/blog/product-led-ecommerce-growth).

**Recommended read:** [Escaping the Build Trap](https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X/ref=sr_1_1?keywords=escaping+the+build+trap&qid=1693410820&sprefix=escaping+the+build+trap%2Caps%2C212&sr=8-1)


## 4. Improve Continuously and Systemically

You and your eCommerce agency should be on a path of continuous, systemic improvement of your baseline performance. Rather than shooting for the stars only when the situation requires it and then falling back down to your usual standards, **you should constantly reassess your work together to understand how to take things to the next level.**

If you’re unsure how to do this effectively, try running a retrospective. In a retrospective, all team members can bring and discuss their feedback in a blame-free environment, with the only goal of improving the team’s performance. Retrospectives are most often used by software development teams, but they are a generic tool that can be applied to pretty much any business scenario.

Retrospectives allow you to improve continuously, but you should also ensure you’re improving systemically. By that, we mean that you should strive to maximize the impact of any work you do by considering how the work will affect different areas of your business, now and in the future.

A prime example that we like to use is building a design system for your brand. A design system will allow you to dramatically increase your iteration speed in the long term: you’ll be able to build more in a shorter timespan and reduce the amount of decision-making needed during the design process.

Unfortunately, design systems never seem important in the short term: **you need to make a conscious effort and invest a bit of your time in your future needs**–in a way that’s compatible with your immediate goals, of course.

**Recommended read:** [The Goal](http://amazon.com/Goal-Process-Ongoing-Improvement/dp/0884271951/ref=sr_1_1?crid=291LJ6ND5CVPB&keywords=the+goal&qid=1693411801&sprefix=the+goal%2Caps%2C305&sr=8-1)


## 5. Do What’s Right, Not What’s Popular

The relatively recent commoditization of eCommerce infrastructure is fantastic news for brands: you can now build rich eCommerce experiences with a fraction of the effort that was previously required. Sign up for any modern eCommerce platform, and the amount of functionality available out of the box is mind-boggling.

However, this comes with a side effect: **many brands have stopped thinking about how to properly align their [eCommerce stack](https://nebulab.com/blog/ecommerce-tech-stack) with what their business really needs.** Instead, they just pick whatever’s most popular and stick to that. Unfortunately, agencies are not immune to this pattern–especially those that lack experience or strong R&D capabilities.

The result is a sea of online stores that all look and act the same and a borderline irrational fear of doing anything that deviates from the status quo.

**Best practices should be considered a starting point that you can build upon, not an absolute constraint.** Whenever you’re making a choice, it is your agency’s responsibility to present all your options and then determine what resonates the most with your market, vision, and business requirements.

Don’t get us wrong: there _is_ a cost for deviating from the most traveled road, and you need to be able to quantify it. It all boils down to whether the additional benefits justify it.

**Recommended read:** [The Lean Startup](https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0670921602/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=1693414149&sr=8-1)


## Change Is Hard, Not Impossible

As you’ve seen by now, none of the principles we’ve just outlined are quick wins–in fact, many of them require a significant mindset shift, and we can’t promise that they will deliver results overnight.

What we _can_ promise is that **this way of working is infinitely more powerful than more transactional agency relationships**, where you’re just paying money in exchange for pixels or code.

We’ve also seen first-hand that this kind of change can be implemented–you just need to be patient and accept that there will be slip-ups in the process. When they happen, treat them as your opportunity to practice continuous improvement!

5 Principles for Doing Great Work with Your eCommerce Agency

When it comes to customer loyalty in DTC, two strategies dominate the industry: subscription business models, where a consumer commits to a recurring payment, typically in exchange for a discount, and loyalty programs, where a consumer receives rewards–most often in the form of cashback–in exchange for performing specific actions, such as completing an order, referring a friend, or talking about a brand on social media.

These models, which both have excellent reasons to exist, are often implemented by brand executives desperately looking for a quick win: CPG brand looking for more predictable revenue? Launch a couple of subscription plans and profit. Diverse catalog that can support more frequent or larger purchases? Roll out a cashback scheme and live happily ever after.

And while it all makes sense in theory, the unfortunate news is that it doesn’t quite work like that–not anymore, at least, and most certainly not for everyone. **Both subscriptions and loyalty programs come with two significant drawbacks**, which have gradually reduced their effectiveness over the last few years:

* **Transactionality.** A customer signing up for a subscription service or your loyalty program tells you very little about that customer’s affinity with your brand–it simply means that they saw an opportunity to save some money and took it. You are–almost literally–paying customers to shop with you. There’s little preventing customers from switching brands as soon as they find a better deal–**short-term incentives drive short-term behavior.**
* **Saturation.** If you’ve heard anything about “subscription fatigue,” you’ll know what we’re talking about. Consumers are tired of juggling multiple subscription boxes, and they are instead looking for ways to streamline and consolidate. And while loyalty programs are less susceptible to this–since they’re free to use most of the time–**the fact that every single brand has some form of loyalty program has essentially leveled the playing field.**

So, does that mean that customer loyalty is dead? Not quite–it’s just that you can’t stand out by doing the same things as everyone else. **In the DTC sea of sameness, there’s a massive opportunity for brands to break through the noise and generate organic stickiness,** but the strategies look a bit different than before and require much more intentionality.

Today, we want to tell you about one of these strategies: membership programs.

## What Exactly Is a Membership Program?

Membership programs are an established concept for large brands but are still relatively unexplored in the DTC world. In fact, many brands confuse membership programs with traditional loyalty programs because of their similarities, which contributes to the confusion.

**At its core, a membership program is a loyalty program on steroids.** It is usually sold as a digital subscription rather than being offered for free, and program members get access to various benefits. Some might be monetary rewards (e.g., discounts and cashback), but you’ll also find perks such as early access to new products, exclusive communities, members-only content, and free or discounted services.

If you go back to the two problems we’ve identified with subscription models and loyalty programs, you’ll see how memberships address both:

* **They eschew transactionality and pursue identity.** By going beyond monetary rewards, **memberships provide brands with an escape from transactionality.** A well-rounded membership program elevates brands, enabling them to become a customer’s reference point for running a given aspect of their lives.
* **They eschew saturation and pursue exclusivity.** I can sign up for a thousand free loyalty programs and continue to shop from a thousand different brands, but I can only sign up for so many paid membership programs. No matter how insignificant, **the membership fee forces customers to make a choice and stick to it.**

The mix of identity and exclusivity makes for a robust customer loyalty flywheel: the initial cost of becoming a member motivates me to use my membership. As I use my membership–and barring any breaches of consumer trust–I identify myself more and more with the brand, which increases the perceived value of the brand.

All of this might sound like theoretical mumbo-jumbo, so let’s look at an example.

### How Petco Makes $120M/Year from Memberships

Petco offers a membership program called Petco Vital Care comprised of two tiers: a free tier which is a run-of-the-mill loyalty program, and a paid tier called Vital Care Premier. For $19.99/month, members can benefit from extra discounts and services such as pet sitting, grooming, and vet visits for their dogs.

The results are astonishing: **in Q4 2022, Petco Vital Care counted 500,000 paid members–about $120M/year in incremental revenue for Petco.** That number, by the way, is just the membership fee and doesn’t account for the fact that members have a lifetime value 3.6X higher than casual shoppers.

![](https://cdn.sanity.io/images/kqgmf0g2/production/efd6ac6c17c1fca084bac9df95a87b9a477b4eda-2560x2488.png?fit=clip)

Through Vital Care, Petco is not only diversifying their revenue streams but also creating a compelling unifying force for their products and services. If you’re an Amazon Prime customer, this concept shouldn’t be a surprise. **Just like Amazon wants to be your end-all solution for shopping, Petco wants to be your end-all solution for pet care.**

Of course, Petco is a publicly traded $6B/year retailer that operates thousands of stores across the US, and they have the economies of scale to offer their members an incredible level of convenience. Even for a relatively established DTC contender in their category, replicating Vital Care would be virtually impossible.

However, that doesn’t mean membership programs are inaccessible for small brands–they just need to be structured thoughtfully.

## How to Structure Your Membership Program

If we managed to convince you that rolling out a membership program is the right thing for your online store, awesome! But where do you start? In the following paragraphs, we’ll outline a five-step process you can follow to design, validate and roll out a membership program to your customer base.

### 1. Talk to Your Customers

Seriously, _do_ talk to them.

If you aren’t conducting regular interviews–[which you should](https://nebulab.com/blog/ecommerce-product-management), but just in case–f**ind 30-50 customers from different cohorts to understand whether they would have any use for a brand membership and what it might look like.** Ideally, you’re looking to answer as many as possible of the following questions:

* What problems are your customers solving with your product(s)?
* How do they currently perceive your brand? What do they love about it?
* What adjacent brands do they shop with regularly?
* What adjacent services do they consume regularly?
* Do they already have any memberships? What do they like/dislike about them?

![](https://cdn.sanity.io/images/kqgmf0g2/production/1a2947fe9354c18325c2bc8b9f25cb2d9d41d78c-1200x869.jpg?fit=clip)

Of course, you’ll want to adjust and enrich these based on which category you operate in. For example, if you sell workout apparel, where do your customers work out? If it’s at home, do they subscribe to a separate workout app to track their workouts? Do they also care about nutrition? If yes, where are they getting their educational content from?

**In addition to the interviews, you should look at analytics, primary and secondary competitors, and key market trends.** Your goal should be understanding how your brand fits into your customer’s day-to-day and whether there’s an opportunity to move into adjacent problem spaces.

As a final note, remember that **your membership will not appeal to all your customers–and it shouldn’t.** Memberships require customers to invest a significant amount of financial and social capital into your brand–as a result, they will only work for customers willing to take that leap of faith. Use this initial phase to understand what that ICP looks like, and double down on it when you do additional research about your membership program.

### 2. Design Your Member Benefits

Once you understand the opportunity space, you must decide what to offer as part of your membership. Generally, membership benefits can be put in one of five buckets:

* **Money:** this includes discounts, cashback, free shipping, birthday gifts, and any other monetary reward. These are things your customers could easily purchase themselves or find elsewhere, which makes them more immediate to understand but less likely to generate long-term loyalty.
* **Access:** very often, members have early access to new product releases, or exclusive access to certain pieces of merchandise. Even if you don’t have a large product catalog, you can get creative with partnerships, digital products, and other goodies.
* **Content:** given how valuable good content is, it might seem ridiculous to gate it. But making certain content only available to your members is a fantastic way to foster a sense of exclusivity and identity, as long as you have a unique or particularly valuable perspective to offer.
* **Services:** when you look at Petco Vital Care, the non-monetary part of their paid membership tier is comprised almost exclusively of services. Petco delivers most of their member services in-house, but you can always partner with a third-party service provider.
* **Community:** network effects make communities incredibly sticky. In addition to being an incredible perk, brand communities can become a solid sounding board for your new product ideas and a formidable source of organic marketing.

When it comes to your member benefits, you must balance putting together a package compelling enough that customers will want to sign up, and keeping it small enough for your team to launch and sustain over the long run.

**If you’re just starting out, we recommend starting with monetary benefits (which can be implemented almost for free) and an additional category your members deeply care about.** Once you launch your program, you’ll have plenty of time to adjust and expand it.

### 3. Determine Your Pricing

At this point, you’re ready to start thinking about your membership’s pricing structure.

Our recommendation for most brands is to start with two tiers: a free tier, which is essentially just a traditional loyalty program, and a paid tier, which gives customers access to member perks. **You shouldn’t separate your loyalty and membership programs, as that would most likely confuse customers.**

![](https://cdn.sanity.io/images/kqgmf0g2/production/e90b647471606b469b4141a39710bec2d252defb-2880x2149.png?fit=clip)

As for the exact price point, this will vary greatly depending on your target market, product category, and member benefits. A helpful tool for determining a range of acceptable prices is the [Van Westendorp Price Sensitivity Meter](https://www.forbes.com/sites/rebeccasadwick/2020/06/22/how-to-price-products/) (PSM). With this model, you ask your potential member for questions:

* What price would be so low that you start to question the membership’s quality?
* At what price would the membership begin to seem a bargain?
* At what price would the membership begin to seem expensive?
* At what price would the membership be too expensive?

By plotting your answers, you can determine the range of prices your customers would be willing to pay for your membership.

Obviously, you should still validate whatever numbers you get to ensure they work for your business. This is also where it pays off to offer a membership that is more heavy on non-monetary rewards, as they will typically be less burdensome on your margins at scale.

### 4. Define a Go-to-Market Strategy

You know who you’re selling to, what you’re selling, and for how much. All that’s left to figure out at this point is _how_ you’re going to sell it–that is, your go-to-market strategy.

The first thing to keep in mind here is that **when it comes to memberships, paid social–and other paid channels in general– should be approached with caution:** unless you have an incredibly compelling offering, it is extremely unlikely you will be able to achieve a reasonable CAC. As we’ve mentioned before, selling a membership requires a degree of trust much higher than your typical eCommerce conversion.

As long as you collect the right zero-party and first-party data, you can easily use email and SMS marketing automation platforms to identify and reach potential members. Ideally, **you want to reach out as soon as a customer is identified as a potential fit for your membership program**–what this means exactly will depend on the ICP you’ve outlined in phase #1 and will vary over time.

As for your website, you should design thoughtful touchpoints that remind customers of the value of your membership and provide easy paths to conversion. For instance, if you’re offering free shipping as part of your membership, your checkout flow should clearly indicate that and allow customers to opt into the membership and benefit from the free shipping perk in one smooth click.

Finally, **referrals and gift memberships can be very powerful in driving organic customer acquisition, so you should at least experiment with them.** These channels allow you to bypass the consumer’s initial “trust gate,” leading to higher conversion rates.

### 5. Launch, Track, and Iterate

You’re all set! Now you just need to launch your membership.

Depending on your tech stack and how you’re structuring your program, you will likely need to use a few different tools. On Shopify, our favorite membership apps are [Conjured Memberships](https://apps.shopify.com/membership-program?locale=it)–a solid solution with very accessible pricing–and [Inveterate](https://www.inveterate.com/)–a more modern and flexible platform, well-suited for brands that need custom functionality or use a [headless architecture.](https://nebulab.com/blog/headless-commerce)

If you’re looking to break beyond the walls of your eCommerce site, [Circle](https://circle.so/) is a standalone platform for brands to launch their private communities. It’s an incredibly powerful option if you want to create a dedicated space for members-only content, discussions, and events, and it can easily drive the entire Community aspect of your membership program.

![](https://cdn.sanity.io/images/kqgmf0g2/production/6ef9d98a89f6a19f6faa7cc1bf1ae597a94b263b-2560x2488.png?fit=clip)

**Whatever tools you use, take the time to truly understand their potential and make them yours!** Memberships are only valuable when they deeply resonate with the brands that drive them and the consumers they serve. If you’re just going through the motions, your membership program will be short-lived.

After the launch, use member interviews and exploratory analytics to gauge the effectiveness of your program and adjust course accordingly. Most brands will want to track at least some of the following:

* How many customers are you converting into paid members?
* Are members using all the benefits in their membership? How much?
* What is the customer lifetime value and LTV:CAC ratio of members vs. non-members?
* What are your margins for members vs. non-members?
* What does retention look like for your membership program? Why do members cancel?

Feel free to enrich these as needed to drive your brand’s goals, **but never lose track of the basics:** maintaining a healthy foundation will give you the peace of mind you need to grow your membership program.

## Is It Time to Switch to Memberships?

Many brands have already started to roll out membership programs as part of their offering, and we’re excited to see this trend unfold over the following years: while subscription-based models and loyalty programs will never lose their place, they can rarely foster true customer loyalty.

As you’ve seen, the caveat is that a membership program requires more maintenance than other models, so you should ensure your team has the bandwidth to support it before venturing down this path.

If you’re wondering what a membership program can do for your brand or looking for help rolling out your program, don’t hesitate to reach out!


Why Memberships Are The Future of Customer Loyalty

At Nebulab, we take a lot of pride in our two-pronged approach to creating value for eCommerce brands: on one side, we have our Consulting Services department, working with customers on a one-on-one basis to develop bespoke solutions. On the other, our R&D team is constantly looking for new product opportunities. When the two work together holistically to inform each other’s work, magic happens.

Today, we’re proud to announce [Sprout](https://getsprout.app), our product seeding toolkit born precisely from such a spark of magic. When we found ourselves solving the same problem over and over for different customers, we realized it was time to create a reusable solution that could put an end to brands’ influencer gifting pains once and for all.

## What’s The Big Deal with Influencer Gifting?

After Apple released App Tracking Transparency in iOS 14.5, dramatically increasing the cost of paid social media advertising, most DTC brands began looking for novel marketing channels that could sustain their growth without killing their bottom line.

One of the most promising new channels is influencer marketing: by partnering with like-minded influencers and content creators, brands can access highly engaged audiences, usually at a fraction of the price of paid social. Influencer marketing is being adopted by brands of all sizes to complement and enrich their channel mix.

![](https://cdn.sanity.io/images/kqgmf0g2/production/6ca1956b5ba7812852239ee7c48481df3d1dd597-2560x2496.png?fit=clip)

When partnering with an influencer, brands typically send them a free sample to try the product and generate relevant UGC to share with their audience. These samples may vary depending on how many SKUs the brand has, and they may include handwritten notes, branded merchandise, or other goodies to give the influencer even more firepower to efficiently promote the brand. Large brands also have stringent requirements around budget control, fulfillment, and revenue reporting.

As we worked with customers such as [Cometeer](https://cometeer.com) and [Goodles](https://goodles.com) to develop bespoke solutions to solve these challenges, we realized that there was no product out there to facilitate influencer gifting campaigns at scale. All the gifting toolkits we looked at were either too focused on peer-to-peer gifting or part of larger, incredibly expensive influencer marketing platforms that do way more than the average brand will need.

As a result, most brands are using spreadsheets and manual work to run influencer gifting campaigns: they reach out to influencers individually, collect their shipping address and product preferences, and then ship out the samples manually. The entire process is time-consuming, prone to error, and above all, soul-sucking. We think that there are better uses of a marketer’s time.

So we set out to solve this problem once and for all.

## Enter Sprout, Influencer Gifting Peace of Mind

Sprout is a simple product at its core: you connect it to your Shopify store, set up a gift link, and share it with your influencers. The influencer uses the link to select the product(s) they want to receive and enter their shipping information, and an order magically appears in your eCommerce platform, which you can fulfill like any regular order.

![](https://cdn.sanity.io/images/kqgmf0g2/production/25f5ad60bb46e1ee9349d1fc124742576d0cf1ae-2560x2496.png?fit=clip)

The magic of Sprout lies in the level of integration and control it offers:

* **It supports rich product catalogs.** You can have option selectors for multi-variant products, allow influencers to redeem merchandise and goodies along with the primary SKU, and specify redemption limits for each type of product.
* **It’s on-brand through and through.** The entire redemption experience can be customized from the ground up to match your branding. You can also add custom content blocks and even custom fields to collect additional information.
* **It integrates seamlessly with your stack.** Rather than forcing you to fulfill orders manually or through a separate UI, Sprout simply uses the eCommerce stack you already have: it integrates natively with your eCommerce platform and any apps you might have installed, so that any post-purchase automations will still fire–as long as you want them to, of course.
* **It’s made for data-driven brands.** Serious brands take reporting seriously. All gift orders created by Sprout use a special discount code and are tagged granularly, so you can easily filter them out in your reports and analytics.
* **It gives you the control you need.** If you’re a big player, we have what you need: Sprout allows you to invite multiple team members with different permission levels, assign monthly budgets to each team member, and automatically expire gifts to reclaim unused budgets.

And this is just the beginning: we’re working closely with our first cohort of customers to inform the product roadmap and enable Sprout to automate even more of your influencer gifting campaigns. With the capabilities unlocked by generative and predictive AI technologies, there’s an opportunity for Sprout to become a one-stop solution for your entire influencer funnel–but more on that when the time is ripe.

## Take Sprout for a Spin!

Sprout is currently available to select brands in early access.

**For $400/month, you get unlimited access to all features and a branded redemption page, lovingly crafted by our design team.** In pure SaaS fashion, you can try Sprout for 30 days and cancel at any time if you don't think you're getting your money's worth—although we guarantee you will.

If you want to give it a try, reach out through [Sprout's website](https://getsprout.app?utm_source=nebulab&utm_medium=blog&utm_campaign=sprout_announcement) and we’ll be in touch!

Announcing Sprout, Our Toolkit for Influencer Gifting

If you operate a retail brand today, you should pursue an omnichannel marketing and distribution strategy. And if you’re pursuing an omnichannel strategy, you should at least consider launching a mobile application for your online business. The benefits of eCommerce mobile apps are very alluring:

* **They make it easier to identify return customers,** providing richer, deeper opportunities for personalizing the customer experience.
* **They allow you to send push notifications to your users.** That’s a real-time, high-engagement, fully-owned marketing channel–and it’s free, too.
* **They offer your customers a faster, more convenient online shopping experience,** making for higher conversion rates, better retention, and larger baskets.

However, mobile apps are not for all brands: depending on what type of app you want to build, the financial investment can be significant. T**he more you want your app to act as a customer acquisition driver, the more expensive it will be to build and operate.** And ironically, brands that need acquisition-focused apps are usually the ones with the least money to spend on them, which makes this a complex juggling act.

The goal of this guide is two-fold: we want to provide you with all the context you need to make this decision in the most informed and balanced way possible, and if you decide to move forward, we want to offer practical tips to design and build an eCommerce app that will delight your customers while pursuing your business goals.

## Transactional Apps Drive Lifetime Value

If we asked the average user to picture a mobile app for an eCommerce brand they like, they would probably copy-paste the brand’s online store into a native UI, ending up with a shopping app that simply serves as an additional sales channel. We typically refer to these as “transactional apps” because their only purpose is to facilitate transactions between a brand and their customers.

While there’s nothing wrong with transactional apps per se, you should know that this is not the only type of app you can build–although it’s the easiest. **Transactional apps are incredibly useful if you already have significant brand equity or a high repeat purchase rate and want to get more value from your existing customers.** By providing a better, more user-friendly shopping experience than your other channels and potentially your competitors, you can improve your conversion rate, average order value, and repeat purchase rate.

![](https://cdn.sanity.io/images/kqgmf0g2/production/635f4d681b5cbf832e452b6f69380fc936f3600d-2400x1500.png?fit=clip)

**What a transactional app can’t help you with is customer acquisition.** Anyone who shops through a transactional app should be considered a high-intent customer and would have likely shopped with you anyway, although their orders might have been a bit smaller or less frequent in other channels.

One of the most popular transactional apps is Nespresso’s mobile app: it allows you to place orders, manage your Nespresso subscription, and manage your Nespresso coffee machine, all without opening their website. The app does a great job of eliminating any friction in the shopping experience, increasing repeat purchase rate and average order value for all existing Nespresso customers.

## Experiential Apps Drive Customer Acquisition

We’ve seen that transactional apps boost your customer lifetime value, not your acquisition rates. Does that mean you shouldn’t build a mobile eCommerce app if you’re focused on customer acquisition? Not quite–it just means your goal should be to build an app that’s experiential rather than transactional.

Experiential apps take the concept of an eCommerce app a step further. Rather than simply facilitating a transaction your customers can already complete on your website, **experiential apps provide value in and of themselves.** This can come in the form of exclusive content, a community, or a tool/service that is relevant to your physical product(s). These apps effectively become part of your brand identity rather than being another sales channel.

**The idea behind experiential apps is to build brand awareness and capture low-intent customers** by providing them with free, immediate value, only nurturing and converting them at a later stage. It’s a much longer-term bet than launching a transactional app but it can also pay off huge dividends over time. Experiential mobile apps are one of many ways you can pursue a [Product-Led Growth strategy.](https://nebulab.com/blog/product-led-ecommerce-growth)

![](https://cdn.sanity.io/images/kqgmf0g2/production/68db8d648a056e09c99d04923a473428bdf01c76-2400x1500.png?fit=clip)

Note that **most experiential apps also offer transactional capabilities,** allowing you to kill two birds with one stone: high-intent customers can use your mobile shopping cart to buy from you, while low-intent shoppers can use the experiential features to explore your brand at their own pace–and eventually convert into paying customers.

Personalized vitamin brand [Care/of](https://www.takecareof.com/) recently released an app that is equal parts transactional and experiential: the app sends you reminders and allows you to track your vitamin intake, as well as keep track of your daily habits. By performing these actions, you earn points, which you can redeem for free rewards–the perfect entry point into Care/of’s world. At the same time, existing customers can use the app to manage their Care/of subscription.

## Greenfield Builds vs. App Builders

Once you have a clear idea of what kind of app you want to build, you need to decide how you want to build it. While your tech team or mobile app development agency might have strong opinions over which tech stack they want to use, it’s essential to be aware of the implications of your choices.

**Traditionally, mobile apps have been built from scratch,** using technologies such as Swift (which is specific to iOS) or React Native (which allows you to power cross-platform native apps with a single codebase).

**Building your app from scratch is basically the equivalent of writing your own checkout code,** and it has many of the same advantages and limitations. It gives you tremendous flexibility to build whatever app you have in mind–which is fantastic if you’re launching an experiential app–but it also requires a significant investment and technical know-how.

**A greenfield app will take anywhere between 8 and 12 weeks and cost you $50-100K,** depending on your agency/tech team composition. These apps also tend to be more expensive to operate and maintain over time.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a796fd0d1992c28ec77d4059b627ec951d39201d-2560x1850.png?fit=clip)

**The alternative to a greenfield build is to use an app builder.** Over the last years, several startups have emerged that offer a much cheaper and quicker way to launch a mobile app than building it from scratch: you simply connect them to your Shopify store or other eCommerce platform, customize your app by using a drag-and-drop interface that allows you to reuse predefined templates, and click a button to have your app published in the Apple and Android app stores.

App builders are especially popular in the eCommerce domain, because the user experience of purchasing a product online tends to be very repeatable. **Launching an app with one of these tools can take as little as two weeks, and pricing is usually fairly accessible.** [Tapcart](https://www.tapcart.com/), for example, is the most popular app builder for Shopify and starts from $300/month.

However, these tools have a downside: because you need to operate within the constraints of your app builder, you are much more limited in terms of the functionality you can implement. **This makes app builders a terrible choice for experiential apps, where you want the app to stand out and capture your customers’ attention.**

## What Type of App Should You Build?

Ultimately, there’s no one-size-fits-all answer: whether to build a transactional or experiential app depends on your eCommerce store’s stage, customer profile, business model, tech savviness, and a thousand other factors that are pretty complex to account for.

In general, **if you want to drive customer acquisition and have the resources, you should go with an experiential app.** It’s your best shot at capturing customers that are interested in what you have to offer but might not be ready to shop with you just yet.

However, **if your primary goal is to create a low-friction sales channel for your mobile users, you should likely build a transactional app instead.** It will give you the best bang for your buck, increasing customer satisfaction, repeat purchase rate, and basket size.

## Tracking Your Mobile App’s Performance

What KPIs to track for your mobile app depends on the type of app you’re building: tracking the performance of an experiential app will look very different from monitoring the performance of a transactional app, since the goals are fundamentally different (acquiring customers vs. increasing LTV).

However, you should always track both product metrics and business metrics:

* **Product metrics** measure how well the app itself is performing. How many users are downloading your app? How often are they opening it? What’s the average session length? What are the biggest points of friction?
* **Business metrics** measure how well your app is moving the business forward. How many paying customers is your app generating? What’s the AOV of an app order vs. a mobile/desktop website order?

To answer these questions, you need to make sure your app is instrumented correctly to capture this data. While this will come for free with app builders, you’ll need to be much more intentional about analytics when building an app from scratch.

![](https://cdn.sanity.io/images/kqgmf0g2/production/58a36d4bfc3bc7ff9e4358948a51e89862292ef9-2970x1980.jpg?fit=clip)

Finally, a note of caution: especially when building a transactional app, **you should be mindful that mobile app customers are a unique segment,** and you can’t draw one-to-one comparisons with your general customer population.

For example, you might be tempted to compare your average in-app conversion rate to your average on-site conversion rate, but that’s a pretty useless insight: almost by definition, your mobile app users are much higher-intent than your website users since they went through the pain of finding and downloading your app. The fact that your app’s conversion rate is 2X your website’s conversion rate doesn’t really mean anything.

Ideally, **you want to compare metrics across customer segments that are as similar as possible** (e.g., highly-engaged customers that regularly shop online vs. in-app) to ensure you’re assessing your app’s performance fairly.


## Ready to Launch Your App?

We’ve just provided a high-level overview of what it takes to design and build a mobile app for your eCommerce business. As you’ve seen, it’s a project that can have incredible benefits but also requires a clear, upfront understanding of your motivations.

If you’re unsure whether a mobile app–or what kind of app–is right for you, we’re here for you! Feel free to reach out for a free consultation with our brand strategists, and we’ll help you make the best choice for your brand.

The Honest Guide to Mobile eCommerce Apps

At the end of 2022, the entire frontend community was surprised by an unexpected announcement: [Shopify acquired Remix](https://shopify.engineering/remix-joins-shopify). At first glance, this news offers little information; after all, Shopify is famous for investing many resources into open-source projects. However, after further research, the reason for this merger became clear: Remix is deeply aligned with Shopify’s new framework: Hydrogen.

Shortly after the big news, the dev team behind Hydrogen [made another announcement](https://hydrogen.shopify.dev/roadmap/): the entire framework was being re-created from scratch using Remix, thus giving birth to Hydrogen v2. While the upgrade path will likely be a struggle for existing Hydrogen v1 users, Hydrogen v2 offers several benefits over its predecessor.

In this article, we’ll look at some of the most significant enhancements Hydrogen v2 brings to the developer experience, what they mean for your user experience, and how you can start adopting them in your storefront.

## A Brief Primer on Remix

To fully comprehend Hydrogen’s latest changes, we must first understand Remix.

For those unfamiliar with it, Remix is an up-and-coming Javascript framework based on React. It was developed by Kent C. Dodds, Ryan Florence, and Michael Jackson, all well-known contributors to the Javascript open-source community.

Unlike the previous generation of React frameworks such as Next.js, Remix is full-stack, monolithic, and fully server-side-rendered, and it will feel like a breath of fresh air to all the Ruby on Rails and Laravel lovers. In fact, Remix’s primary goal is to merge the benefits of the “old Web” with the smooth developer experience React offers. This way, developers get higher productivity, simpler code, better SEO, less backend-frontend communication overhead, smaller client bundles, and near-instantaneous page transitions.

![](https://cdn.sanity.io/images/kqgmf0g2/production/030082583dd37bf225378d98322d8b1993cf3e0b-2960x2400.png?fit=clip)

When developing the first version of Hydrogen, Shopify created a framework very similar to Remix in spirit: it was React-based, but it was also rendered on the server. This was a surprising choice back in the early days of Hydrogen, but it did make a lot of sense in retrospect: anyone who has tried to implement an eCommerce storefront quickly found that the dynamic nature of eCommerce doesn’t play well with static site generation and client-side rendering.

In October 2022, Remix announced that Shopify was acquiring it. As part of the deal, Shopify will offer continuous support to Remix’s authors to continue developing the framework, and Remix is becoming the React framework powering Hydrogen. On their side, Hydrogen’s development team can now delegate most of the core framework functionality to Remix, focusing only on Hydrogen-specific functionality.

## The Main Changes in Shopify Hydrogen v2

Even though the Shopify developer community (and Shopify themselves, [in some places](https://github.com/Shopify/hydrogen/blob/2023-04/packages/hydrogen/CHANGELOG.md#202317)) dubbed this release “Hydrogen v2”, this isn’t technically correct: Hydrogen simply follows calendar versioning, with each version number being a combination of the date and month of the release (e.g., v2023.1.0). However, for the sake of simplicity, we will refer to “Hydrogen v2” as the version of Hydrogen that uses Remix.

As you might expect, this release introduces _a lot_ of changes. In fact, pretty much everything in the framework has changed, meaning developers with an existing Hydrogen storefront have a whole bunch of rewriting to do.

### Retrieving Data with Loaders

The most significant change–which will affect pretty much every route in your project–is the introduction of Remix’s `loader` function.

The `loader` function is where all of your data retrieval logic is stored. The `useShopQuery` and `useQuery` hooks from Hydrogen v1, responsible for querying the Shopify Storefront API, have been replaced with `loader` in Hydrogen v2.

For example, imagine building a product detail page with a product options selector. In a typical React storefront, you would need to store the selected options in a state entry:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e553a7b7b1f1e0d77e3cd95a9ecef7a1893b29c9-1200x520.png?fit=clip)

The problem with this implementation is that this component also needs to change the URL whenever a new variant is selected, so that users can easily bookmark or share the URL to the correct product variant. Unfortunately, there is no “native” way of achieving this with React. You would need to create a function that alters the URL when the user changes their selection.

With Remix, just like Ruby on Rails or Laravel, you can solve this by simply taking advantage of Web fundamentals. In this case, whenever the user selects a new product option, you simply direct them to a new URL, and the `loader` function gets executed again, querying the desired product variant from the Storefront API.

![](https://cdn.sanity.io/images/kqgmf0g2/production/3217fe54a31e57a20a6240808dd00e4937c4f7eb-1200x856.png?fit=clip)

The benefits of this new implementation are clear: we achieve the same outcome with less code and fewer abstractions to learn.

This approach was used to refactor all the major components in Hydrogen: the cart, analytics, SEO, and session management were rebuilt from scratch, resulting in a much more straightforward developer experience and a less steep learning curve!

[Learn more about the `loader` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/loader)

### Mutating Data with Actions

While the `loader` is used to _retrieve_ data, the `action` function is to _mutate_ data. As a consequence of segregating business logic into loaders and actions, you can now remove a bunch of code, especially client-side logic and state.

As an example, take a look at what the default `AddToCart` component looks like in the Hydrogen v1 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/253be981f9a0861351e4e2bcba39e77df56fec53-1374x2904.png?fit=clip)

And now, look at the same component in the Hydrogen v2 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/5c38c039f5c5132d9b9ba34c6d19d0b0075b7f0b-1424x1786.png?fit=clip)

As you can see, a lot of state management and querying logic has been removed in favor of a more straightforward implementation that relies on Web fundamentals such as... Web forms! This simplifies your code and makes your online store more resilient to network issues and more accessible to screen readers and old devices.

[Learn more about the `action` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/action)

### Handling Errors with Error Boundaries

A common and annoying problem with React applications is isolating errors. Typically, when you get any error on the frontend, the whole UI breaks, and the website becomes unusable. This is obviously not a desirable experience for our customers.

By taking advantage of Remix’s [nested routes](https://remix.run/docs/en/1.16.1/guides/routing#what-is-nested-routing), you can use [nested error boundaries](https://remix.run/docs/en/v1/guides/errors#nested-error-boundaries). If you export an error boundary function from a nested route and an error occurs, the error will be isolated, and the rest of your application will remain usable. This allows you to offer the best possible UX, even when things go wrong:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e73f3849c1e52c9a44c721ff4b43976455174ab8-1207x1685.png?fit=clip)

[Learn more about error handling in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/errors)

### Speeding Up Page Loads with Streaming

By using Remix’s [defer](https://remix.run/docs/en/1.16.1/guides/streaming#using-defer) function, you can easily decide which parts of your page should be rendered right away and which parts can be streamed after the page has loaded:

![](https://cdn.sanity.io/images/kqgmf0g2/production/d1fc77778b2760be478d391326acc7ede28f1abe-1207x1685.png?fit=clip)

This technique allows you to easily defer the loading of lower-priority parts of your UI, such as a “Related products” section on your PDP, making for a better user experience and faster loading times.

[Learn more about streaming in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/streaming)

### Speeding Up User Interactions with Optimistic UI

Optimistic UI is a powerful technique that lets you completely hide loading states from the end user. For instance, when a user clicks on your Add to Cart button, rather than waiting for the cart to be updated on the server, you might immediately display the new item in the user’s cart. Then, if an error occurs, you can revert the state and display an error to the user:

![](https://cdn.sanity.io/images/kqgmf0g2/production/1cdb09cad49d184358eb840920173250a2061bc1-1250x800.png?fit=clip)

While not available yet, Hydrogen’s development team plans to adopt optimistic UI in all the standard components. Because Hydrogen is powered by Remix, you will also have the opportunity to use the same pattern in any custom user interactions you offer on your storefront.

[Learn more about optimistic UI in the Remix guides.](https://remix.run/docs/en/1.16.1/tutorials/jokes#optimistic-ui)

### Oxygen Is now Available to All Shopify Plans!

Although there was no official announcement, this is massive news for all Shopify developers! Hydrogen’s official deployment platform, [Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen), which was only available to Shopify Plus users, is now available to all Shopify plans.

Oxygen is an excellent tool for engineers who want a seamless deployment and hosting experience. By keeping your storefront within Oxygen, you can not only reduce your infrastructure costs, but also have access to a fantastic developer experience that includes:

* Preview environments for testing changes in isolation.
* Custom environments (e.g., if you want a staging area).
* Version control and GitOps for your storefront.
* A Content Delivery Network (CDN) powered by Shopify.
* Support for both backend and frontend code.
* CI/CD via GitHub Actions and the Hydrogen channel.

If you’re familiar with Vercel, you’ll find that Oxygen offers a very similar development experience, but more accurately tailored to the needs of Shopify developers.

## Migrating from Hydrogen v1 to Hydrogen v2

If you are using Hydrogen v1 today, there’s a [handy migration guide](https://shopify.dev/docs/custom-storefronts/hydrogen/migrate-hydrogen-remix) in the Hydrogen docs that you can follow to upgrade your storefront.

The process takes a lot of effort, but the guide is comprehensive and accurate, so you should be able to upgrade your Hydrogen app by simply following the steps outlined.

## Is Hydrogen Ready for Production Use Yet?

That depends on your risk tolerance!

On a technical level, both Hydrogen and Oxygen are most definitely production-grade products, and they are being used successfully in the wild by large Shopify stores such as [Allbirds](https://hydrogen.shopify.dev/case-studies/allbirds). The developer experience is pleasant and powerful, and Shopify’s hosting infrastructure will easily handle any production load you throw at it.

On the other hand, it’s unclear whether Hydrogen will see any more extensive refactorings, such as the one we’ve just witnessed. As an example, [Remix v2](https://remix.run/docs/en/main/pages/v2) will be released soon, bringing many improvements over its predecessor, but also requiring developers to upgrade to a new API and file naming convention. These changes will most likely affect Hydrogen users as well. It’s also unclear what synergies Shopify will create between Hydrogen and [Commerce Components](https://www.shopify.com/commerce-components), but we expect some movement there.

![](https://cdn.sanity.io/images/kqgmf0g2/production/e038f0246b07a894d83a8ae5cb1d3fe545d2bc6a-2960x2335.png?fit=clip)

Another factor to consider is how long it will take for the Shopify app ecosystem to catch up to Hydrogen’s philosophy. While some Shopify apps don’t need to worry about the frontend at all, others will have to expose an API or JavaScript SDK of some sort to be usable with a headless commerce architecture. We expect the situation to improve over the coming years, but there’s still a long way to go, and many Shopify apps today cannot be used with Hydrogen.

Overall, Hydrogen is well worth a try if you have the engineering firepower. It solves a significant number of problems for Shopify developers and gives brands unmatched flexibility in building a custom storefront, allowing them to create shopping experiences that would be very hard to replicate with Liquid themes.

However, if you’re a small brand and don’t have the resources to invest in experimental technology, you’re probably better off sticking with Liquid themes until Hydrogen becomes a true first-class citizen in the Shopify ecosystem.

The Nebulab