In our previous post on creating user centered design flows, we saw how you can build a user centered design strategy for your clients and why it’s so impactful. A lot of what we covered in that article comes down on common sense: it makes sense to design user flows in a way that helps the user in their purchase journey.
But if it’s so logical, why then is this not the standard way of doing things? Why aren't all brands doing it? The answer lies in how software has evolved and how brands use technology. In this post, we will dive deeper into the technical challenges involved in putting the end customer at the center of design. Given how critical it is to the shopper purchase journey, we will also discuss building the mobile experience, from the perspective of the new technologies that are now at your disposal for implementing user centered design: PWA and AMP.
The technical challenges of a user centered design strategy
As important as it is, the challenges of building a user centered design strategy can deter brands and the designers, developers, and marketers who work with them. There are two main technical roadblocks they come up against.
1. Understanding the user
As we’ve said previously, the best brands have a deep understanding of how their customers interact with them, down to the last detail. In an ideal world, a brand wanting to implement user centered design would have all their customer data in one place, to better inform their design decisions. All their data from retail stores and online storefronts would feed a single data source. All business activities such as logistics, inventory management, fulfillment, customer support, and post-delivery experience would be controlled by a single source of truth. That way, building a coherent picture of the user journey would be straightforward. This, however, is far from what businesses really get, and the reason is quite fundamental.
"In an ideal world, a brand wanting to implement user centered design would have all their customer data in one place."
Software is hard to build, and software companies consequently spend a large amount of time developing expertise in just one area. There are dozens of software providers each solving a unique problem. A business owner looking to understand their user now has to work with all these different providers for their data. Data is the new gold, and so software providers try to find all the ways possible to lock people into their ecosystem. This makes bringing data together a nightmare for business owners.
Thankfully, things have changed significantly now. Software providers have realized that integration is a fundamental software need. Excellent silos are silos nonetheless.
2. Finding the right solution for the problem
Once a potential point of friction is discovered in the user journey, the next step is to identify potential solutions. For example, if you find out that shoppers are dropping off during the checkout flow, you then need to think of ways in which that flow can be smoothed out.
Given how ubiquitous software is today, it's generally not hard to find solutions to a problem. The challenge instead is often in getting the new solution to play well with the rest of the infrastructure. The new solution has to push relevant data into the existing CMS, has to ingest data and events from the rest of the system, has to maintain the overall branding and positioning of the business, and has to abide by the legal requirements. Finding solutions that do all of these is hard.
You might also like: Creating User Centered Flows in Ecommerce Design.
The main principles of support user centered design
Now that we understand why implementing user centered design is hard for brands, let's go over the principles that you should follow while designing technical solutions to help change that.
1. Build a headless/API-first product
Competitive advantage is necessary for businesses. However, if natural forces demand a different approach to building software, you should be willing to tweak what constitutes your competitive advantage. More and more, it makes sense to give the business owner complete control over their data. This means that right from the beginning, there should be an emphasis on building a generic layer of software that allows third-party software to consume your data, given that's what merchants want today.
At Swym, we call this our eventstream. As events such as adding products to a wishlist, adding products to a cart, or purchasing products happen on a store, we push these events to the eventstream. Now, other pieces of software can subscribe to this eventstream and consume the data that they are interested in. This generic implementation allows us to extend our integrations with several different providers effortlessly. Whenever a merchant request comes in, all we need to do is subscribe to our eventstream and push the data that the merchant is interested in into the provider's APIs.
The UI layer should also build on the same guidelines. Merchants using your software should have complete control over the UI manifestation of the software. When a merchant is implementing a user centered design strategy, they will have a very clear picture of the user flows they need. Like we discussed in the last post, these flows are unique. Software we build should have the flexibility to accommodate these custom flows. At Swym, we have an extensive JavaScript API that allows merchants to dictate the complete user experience of our apps. Additionally, our UI layer is built using modular components, each of which can be overridden both with respect to the look and feel and with respect to the business logic.
2. Surface usable data
To help merchants build a user centered design strategy, it's important for you to think about what data points the merchant might need to get the complete picture of what the user did. For example, whenever we push data about a wishlist event on the eventstream, we also add baseline product data to the event. This is important because the merchant might want to know what price the customer saw when they wishlisted a product.
"The best way to surface usable data is to understand what the merchant intends to do with the data downstream."
We have iterated with merchants several times on the data they need, and we have seen that the best way to surface usable data is to understand what the merchant intends to do with the data downstream. We have seen some very interesting use-cases come up during such discussions.
You might also like: Research 101: How to Conduct Market Research for Your App.
3. Document your API
An undocumented API is as good as no API at all. For a third party software provider, your software should be easy to integrate into. We have seen time and again that APIs that are well documented and that are available to go look at and play with tend to be loved by developers.
4. Aid with buyer education
In our experience, helping buyers understand how to use your product is very important if your product is buyer-facing. At Swym, we saw this first hand when we built a feature that allows buyers to create collections in wishlists. With this feature, buyers can create sublists within the wishlist and organize their wishlisted items in whichever way they like.
Most of the merchants who used this product wrote help text or sent an email to their shoppers to tell them that this new feature had come up. Our educational material helps buyers better understand how to take advantage of this feature.
Without thinking deliberately about shopper education, even great features can underperform. There are several ways of tackling this problem, including creating short onboarding flows, adding help text to icons, providing helpful error messages, creating short video tutorials, etc.
You might also like: 10 Ecommerce Trends That Will Set Your Client’s Brand Apart in 2020.
Technical implementation of user centered design
Now that we have talked about the general challenges of implementing a user centered design strategy and how you can help merchants create one, let's look at a specific example: building a mobile experience for a merchant through the lens of user centered design. This example will highlight the methodology and the technical details of how technologies need to interplay to give that wow experience to shoppers.
Understanding the problems today
Let's start with the extremely overused but the most accurate representation of any ecommerce business's audience: a typical sales funnel.
The sales funnel follows this path:
- Acquisition: Users discover a site from a Facebook or Instagram ad, or a blog post the merchant published, or a video the merchant uploaded on YouTube.
- Conversion: If they like what they see, they make a purchase or agree to give the merchant their contact information. Once they do, we know they are interested in the offering, so we try to market more products to them.
- Retention: If the buyer had a positive experience, they might even become the brand's ambassadors and talk about it on social media. They might suggest products the merchant should add to the inventory, features they should add to the site, or report bugs that they encounter.
Let's dissect what the shopper expects at each of these phases with respect to user experience.
1. When the shopper is just jumping in
When the user is just jumping off from social media, the top priorities are the following:
-
Show the landing page quickly. This is a user who was interrupted in the midst of a social media session and might be interacting up-close with your client’s brand for the first time. First impressions matter. Making sure that first page loads fast is critical. If it doesn’t, it is highly likely that you’ll lose the shopper even before they saw the merchant’s offerings.
- Show them what they came for. It’s important to match the shopper’s intent based on what they clicked on with what you show them when they land on the site. This is easier said than done. You might be running several different campaigns concurrently, targeted at different audiences and with different CTAs. One campaign might be to help the merchant’s email contact list, another to promote a new product, and some other might be trying to drive traffic to a recently published blog. With such diversity of campaigns being run, it's very difficult to present the right copy to the right user, especially when the merchant is running on a tight performance budget. Despite these challenges, it’s important. Landing site copy that matches the shopper’s intent is shown to convert much better than general landing pages.
2. When the shopper is learning more
This is the stage when the user returns to your client’s site to view more products. Sometimes they are pulled back to the site through an email marketing campaign, Google search, or direct lookup. In these situations, the following are top priorities:
-
Show the page fast. This remains a priority, given that 53 percent of traffic will bounce if nothing shows up for 3 seconds. This time though, the loading challenge is quite different from the last time. As the user is flowing deeper into the sales funnel, they are looking to explore everything on offer, including all the collections, offers, rewards programs, shipping times, etc.
-
Make shopping easy. What this means to the user comes in two forms:
- Extensive personalization: Repeat visitors to a site expect extensive personalization: they want shipping address autofills on their future purchases, they would like recommendations based on their browsing activity, they want to be notified when an out-of-stock product back in stock, and they would like this context to flow into whichever medium they are on.
- Make browsing easy: Users expect tools that aid their exploration, such as search, wishlists, recently-viewed, social feeds (eg. Instagram), reviews, and even Q&A widgets.
Now that we have seen what the user’s expectations are, the next question is to determine how far along we are, and whether shoppers are getting the experience they expect.
The danger of a one size fits all approach
We have been working with ecommerce merchants for more than four years now, and time and again, we have seen one single culprit for lousy user experiences.
"From a user centered design perspective, user experience should be dictated by where the user is in the sales funnel."
All too often, sites are optimized for a single type of user. Most commonly, for a repeat visitor. Ad campaigns drive traffic to a product page that has all the features available on the site. This leads to unnecessary loading of assets that the user is just not ready for. Users are left struggling through pages that take forever to respond, when all they really wanted was see the product images real quick. There is no gatekeeper that dictates what should load and what shouldn't, and the result is a user experience that suffers from bloat. From a user centered design perspective, user experience should be dictated by where the user is in the sales funnel.
AMP and PWA: A path forward
In the front end development stack, two technologies are making the rounds for revolutionizing user experience. They are Accelerated Mobile Pages (AMP) and Progessive Web Apps (PWA).
AMP was written off when it came out as "mostly static" and was adopted mainly by media outlets, while PWA was crowned as the next leap in the pursuit of a better UX for interactive experiences. However, PWA wasn't seen as a replacement for a mobile app. Many wrote it off as a Google thing that would only work on Android and even then, only with limited use-cases.
Over time, it has emerged that both these technologies have a lot more personality to them than anticipated and their boundaries aren't written in stone. When they were originally launched, each had a specific purpose that it was intended for. The understanding of the use cases that they each help address has evolved, and these technologies have refined themselves to adapt to those needs. The initial judgements passed on their inadequacy for certain types of applications are therefore no longer accurate. Let's take a fresh look at both AMP and PWA and ask ourselves how they can help us build that ideal experience we talked about in the first part of this blog series.
AMP thought experiment
Assume we were tasked with making an ecommerce site fast for a first-time visitor. What would we do?
We would probably start stripping things down. We'll ask "do we really need this" for every script on the site, every stylesheet, every image, and every API call. We might even throw everything away and start from scratch to try and build the same facade as before, with as little as possible. We will try to optimize along two dimensions:
- Minimize time taken to perform the first contentful paint
- Minimize time to interactive by reducing the JavaScript evaluation that needs to happen on page load
To keep the process focused, we might set a budget and set the threshold time-to-load to 3 seconds or less. This budgeting will force us to make some tough calls—our fancy animations might have to go, all the analytics widgets we had added to the site might have to go, and most of our script tags might have to go.
This is exactly what AMP does. The optimizations we stated above are in line with the two biggest architectural decisions AMP takes:
- Custom CSS has to be below 50 kilobytes. This allows AMP to quickly calculate the position and size of elements to be rendered on the page, leading to a faster first contentful paint.
- AMP pages can have no script tags. Script tags lead to slower page loads since the browser has to spend a lot of time evaluating the JavaScript. Also, if the rendering of DOM elements is controlled by JavaScript, the user has to wait until all the script tags are fetched and evaluated. This is the primary contributor to lousy experiences.
It's funny that this is where the web started—mostly static pages with very little or no JavaScript. As the web began to unravel interaction, JavaScript began to do more and more work until we got to where we are today, where most websites simply fall flat in the absence of JavaScript.
Coming back to AMP, coupled with a Google-backed cache, AMP helps websites gain near-instant load times (<1 second). In less than a year, you will find almost all media publications running an AMP site. Why then, has ecommerce not jumped on AMP?
You might also like: Indexable PWAs: Making Progressive Web Apps Perform for Users and Search Engines.
Reconsidering AMP for ecommerce
Some of ecommerce's core scenarios depend largely on interaction. For example, a user will want to scroll through product images, pick a variant, add it to cart, etc. Also, ecommerce relies heavily on analytics—merchants measure every aspect of the user experience. This data is then used to fine tune the audience, build a personalization suite, and ultimately sell more.
When AMP came out, pulling off these use-cases was simply not possible. Over time, AMP has added a thin layer of interaction controlled by the core library that allows developers to build image carousels and variant selectors, load data from remote sources, maintain application state, and add analytics. The rules are still quite stringent—building a truly interactive experience is well out of reach, and that's exactly the point. It is a tool optimized for first-time visitors. As of today, all the use-cases that make sense for first-time visitors are supported by AMP.
PWA thought experiment
A shopper using a mobile app to browse a shopping site is three times as likely to convert as a shopper using the mobile website.
![User centered design: conversions for mobile versus app](http://cdn.shopify.com/s/files/1/0533/2089/files/User-centered-design-conversion-mobile-vs-app.jpg?v=1585595974)
Clearly, mobile apps are able to provide an experience that's superior to mobile sites. This can be credited to the following features of mobile apps:
- Superior performance supported by smart caching
- Offline browsing
- Notifications support
- Ability to create richer experiences, such as an augmented-reality based try-on tool for glasses
Unfortunately, apps as we know them suffer from three major shortcomings:
- User has to download it from an app store. Apps live in their own ecosystem, which has very little to do with your mobile site. Even if a user lands on the mobile site, you are forced to redirect them to the app store to download the app. This is friction that many of your users won't tolerate.
- Users have a threshold for the number of apps on their phone. An average smartphone user installs close to 40 apps on their phone. This means thousands of apps compete to be one of those 40 spots. With apps like Uber and WhatsApp that have become a part of the daily lives of users, even fewer spots remain.
- Making apps is expensive. Building apps is fraught with platform-specific details and quirks. Supportability and version updates are a nightmare. For an ecommerce business to build and maintain a native app is a huge investment.
Let us take a step back and ask an important question: What is there today that ONLY mobile apps can do, and sites cannot?
Truth is, very little remains in that category. There are two advancements in the state-of-affairs of web development that has bridged the gap between native apps and websites. Firstly, with the service workers API, sites can run scripts in the background that are independent of a web page. This means push notifications, background data syncing, and offline support are all possible with the web today. Secondly, the Web App Manifest file provides one place for developers to add metadata about a web application. Pulling a few lines from the W3 spec:
"Using this metadata, user agents can provide developers with means to create user experiences that are more comparable to that of a native application."
This means websites have everything they need to become installable, offline-friendly, fast, and interactive. If that's the case, why can't mobile sites become the new apps? Why can't they unravel the rich experiences we until now have associated only with native apps?
As you might have guessed, that is exactly what a Progressive Web App is. With a PWA, you can write native app-like user experiences with web technologies. No platform specific code, no browser quirks. Additionally, PWAs don't have to go through an app store review process. Users can discover your PWA right from your site.
![User centered design: how PWA's are installed](http://cdn.shopify.com/s/files/1/0533/2089/files/User-centered-design-how-PWAs-are-installed.jpg?v=1585596019)
PWAs for ecommerce
PWAs aim to make repeat visits great. They are optimized for engagement and interaction. This fits nicely with any ecommerce business's most loyal user-base: the users who have interacted with your client’s business before and are looking for more. From the lens of giving the best experience to the user wherever they are in the funnel, PWAs open the doors to everything you might need to create wow experiences for repeat visitors. You can allow users to discover your client’s site right on their home screen, browse offline, receive notifications about products of interest, and even interact in the next generation of experiences such as trying out products in augmented reality.
PWAs and AMPs as the future
I hope this exercise brought some clarity around the thought process that goes into implementing a user centered design strategy. In the context of an entire ecommerce business operating across various channels, this becomes a far more complicated exercise with many more variables and technology options. With the next generation of software solutions that are API-first, it should become a lot easier to bring data together and build custom experiences for audiences.
In the near future, user centered design is going to become the default way of building user experiences and when that happens, technology solutions have to reach a state where they are like Lego blocks: modular and flexible.
What are your thoughts on using these technologies to build user centered design experiences? Share your thoughts below.