ApiumhubWe often confuse the User Experience (UX) with the User Interface (UI), this is associated only with the most visual part of a web or application.
In this article, we will briefly clarify what user experience refers to, and we will discuss the experience of my colleagues and myself providing solutions and improvements in this aspect for our application. We will also see how this has a direct impact on what is known as the Conversion Funnel. In short, we will understand how we can add value to our users, so we can get a better experience using our application and also, incidentally, end up improving our e-commerce sales.
First of all, I would like to briefly clarify these two concepts I mentioned above.
What is User Experience (UX)?
According to Wikipedia, user experience is the set of factors and elements related to the user’s interaction with a specific environment or device, resulting in a positive or negative perception of that service, product or device. This perception depends not only on factors related to design (hardware, software, usability, interaction design, accessibility, graphic and visual design, content quality, searchability or findability, usefulness, etc.), but also on aspects related to emotions, feelings, brand construction and transmission, product reliability, among others.
In other words, when we talk about user experience we refer to everything our customers experience when they open our application or website. If they like or are excited by what they see, if they find what they are looking for and feel satisfied, or simply if our marketplace does not work well and we cause them frustration, causing them to drop off our website or app.
What is the Conversion Funnel?
The conversion funnel is a Digital Marketing term used within e-commerce, which defines the marketplace sales process. To understand it better, it would be the definition of the flow of all the steps that a user follows from the moment a user enters our website until making a purchase. It is known as a funnel, due to the fact that in each step of this flow, a percentage of users drop out, leave your website or do not continue with the conversion process. The study of this process is used to minimize the drop of users at each step, and thus improve sales in our e-commerce.
How can the backend help to improve these two concepts?
Now that we have both concepts a little clearer, we can conclude that both concepts are related. User Experience directly impacts the conversion funnel, in fact, it is a fundamental part of it. If a user does not understand the application, does not feel attracted to it or does not find what he is looking for quickly and easily, he will simply leave and drop out of the conversion funnel, thus sales will be directly affected. Without being a marketing expert myself, I could say that there are two ways to improve sales: either by attracting more people to our marketplace, through online ads, advertising or by improving the conversion funnel avoiding that the highest possible percentage of our users lose interest in continuing in our e-commerce. In this article we are going to focus on the retention rate of those users who visit our marketplace.
Now that we have a slight idea of what these concepts of UX and conversion funnel are, maybe you are wondering, how backend development can help to improve these two important business pieces, if we only process data, right? We only store and serve information or we dedicate ourselves to “make four CRUDS”, right?
Well, in this article, I will relate my experience in a project, and how with a few architectural decisions, we managed to help improve both the user experience and the conversion funnel of our e-commerce platform.
To add some background, without going into too much detail, my colleagues and I were working on a backend service that served content to e-commerce apps. This service had just been migrated to Kubernetes, and we had set up the Java application with a tomcat embedded in the spring boot itself. This change, already improved our performance a lot, since it scaled in a third of the time it did before the change. Some of you may already suspect that this change has already improved the user experience, since the backend service did not collapse and scaled quickly and smoothly, without affecting the consumers.
You are right, but in this article I want to highlight a couple of simpler changes that brought us a lot of value and might be helpful to you, the readers of this article. In our example, we took two initiatives: improving response times and improving content dynamically.
Improving Response Times
One of the biggest problems, and the one that causes the most frustration to users, that we can solve from the server side, is response times. Infinite loaders cause user frustration, causing them to close our application or website. First of all, I would encourage you to study your business and your backend service. No one should understand the business sales flow more than yourself. This is fundamental to being able to design an action plan. Once we understand this, we will be able to make better decisions, such as deciding how to group data into calls. You have to know how to choose when to get the data in one or more calls, finding the balance between the volume of data and the latency of each request, which penalizes the user experience if we exceed in both cases. As any good consultant, I will tell you that “it depends”. Each of us is responsible for understanding our application, our business, and making decisions accordingly.
In our case, we conducted a study to find the calls that had the worst load time. They were the call to the homepage, the call to the main page, it seems reasonable, it brings information from many different domains that are orchestrated from our backend service. With this premise, it seems simple to say: “Well, we separate it into N endpoints and the requests are made in parallel”. It could be a solution, but not in our case, we see it right away.
The other page that had a high response time was the navigation to the sections of our site, also very important for those users who know what they are looking for and want to go directly to the product they need. It is also fundamental to close those quick sales, without causing frustration, due to too long loading times, which can cause the loss of sales that a priori were almost closed. For reasons of the project, most of this information is related, so we had to post-process the data on the client side, increasing the loading time of the application, which was not in our interest either. Analyzing this data, we realized that the content was mostly static, and changed a few times per week.
This last information was key to take the right alternative: put a cache in front of our service inside the CDN. This has 2 improvements, one direct and one indirect:
The first one is that it was served almost instantly, in the case of the homepage, the most significant improvement, the response time went from about 5-6 seconds to less than 100ms. As you can guess, the impact on the user journey is very important. This initiative helps impulsive buying, since we don’t make the user wait, we give him what he wants instantly, reducing the frustration when entering our marketplace in a radical way.
On the other hand, there is an indirect improvement impact. Most of our users consulted at the beginning of the purchase flow those two pages on which we were able to make improvements. By attacking against a cache most of the requests to our application did not reach the server, the cache responded to those requests, thus relieving the load of our service, significantly improving performance and reducing the need to have many pods up in Kubernetes (thus also improving our monthly billing), as we see in the image.
With this we experienced a very significant improvement in our business, but still, we went for the extra bonus. An app partner told me about the possibility of including in the server/cache response a header that defined ttl of the local cache of the devices. With that information, the client’s own devices would store the information in their own caches during that time. This implies that the requests for these calls did not leave the client device, thus avoiding the latency for making the call to our servers, either to the service or to the cache, and once again relieving the load on them.
Improving Content Dynamically
Another possibility for improvement that we detected was the time it took to change the content of our app. At the initial moment, we needed to redeploy the server with the configurations in static files. As you can guess, this limited us a lot, it required some planning, it was deployed on certain days at certain hours and so on. This limited us a lot to experiment and improve our conversion funnel. The best technical solution was to set up an administration panel that would allow the business to make changes to images, sections, etc. on its own, without the need of the technical team. This solution requires effort and time, which due to the needs of the project, was not possible at that time.
The impossibility of applying the best solution does not imply that we can not look for intermediate solutions that give us much value and does not require more dedication than we can give at the time we were. So we decided to make a first iteration: outsource the configurations. The files that we reloaded in the deployments became externalized in an Amazon Web Services S3, and our service would consult and store them in an internal cache (again, to reduce latency), every so often. This allows us to change the configuration at any time, independently of the service, giving us a lot of flexibility to vary our content, make experiments, disable them, reorder sections, etc.. to improve the user experience in a fast, agile, flexible and service-independent way.
Obviously, we know that this is an intermediate solution, before reaching the optimum, so we made this development, based on hexagonal architecture, so that tomorrow, we only have to modify the implementation of how we get the data, respecting the interface defined in our domain. Thus, the day of tomorrow, either by an http request, a database call or any other solution of how we want to collect that data that will be specified from business through an administration panel, we can take advantage of the rest of the implementation that we have done now in this configuration files externalization.
This intermediate solution may seem silly, but it has given us a lot at the business level. We can change the content at any time, at any moment, without having to redeploy the entire service, thus avoiding the risks that this can entail. In addition to being able to change the content or rectify possible errors in a much faster and simpler way. This makes it easier for our application to change on a more regular basis, giving the user the feeling that they always have something new to see, improving engagement and loyalty with our business, causing, once again, an increase in the conversion funnel.
Conclusions
In this article, we have seen how with two small changes, with little technical difficulty, we have greatly improved our business from the backend itself. The key is to understand the need we have as developers to understand our business and work as close as possible to it, in order to understand its needs and discover its points of improvement. Personally, I think this is something fundamental that can make a lot of differences, beyond the search for excellence that sometimes we cannot achieve at the code level. Not everything is black and white, if you are not allowed to apply the best solution now, you can always think about how to cover that need with an intermediate solution that provides value, as we have seen in this last case, but for this, it is essential to understand your business to be able to provide value.
