Great Product Design is Also About Avoiding Bad User Experiences

This is the story of Willy, a friend of mine who has been looking for a new bicycle for months. While observing his experiences with the buying process, I started to think of the different ways that we need to think about customers.

Willy saw a "Trek fuel EX9 29" on sale on the website thebikeofmydreams.com. The original price of that model was around $4000, but on that day the site was selling it for $3200. He had never bought a product on that website before, but the price was so attractive that he decided to give it a try.

During the purchase process, he struggled at the payment step. He thought it was his fault, that he was doing something wrong. It was unclear to him as to why the payment attempt was not successful. However, he wanted that bike for that price so badly that he decided to repeat the entire purchase process. This time, he successfully completed the purchase. The bad experience was forgotten, and he now very happily awaited the new bike to start racing in competitions.

However, three days later, he checked his credit card balance and found out he was double-charged for that purchase. He was upset and was now regretting buying it online.

Do Not Underestimate the Power of Memory

Feelings of frustration with a product/service can be exaggerated or amplified by the memory of a previous bad experience. Now let's imagine that one week before Willy purchased his new bike, he was wrongly charged on his utility bill (say his mobile) and had to make a claim for a refund via a customer service number. He went through an exhausting process. He was redirected multiple times to different people until someone finally managed to fix his problem. It took an extremely long time for his problem to get sorted out.

Now, back to his current problem. He will have to call customer service to make a claim for a refund on his credit card. He is now stressed and feels anxious. He imagines that he will have to undergo the same time-consuming and tiring process that he went through before. He was only trying to get a good deal, but is now feeling sad and regretful of his decision. All these bad feelings, triggered by the memory of a bad experience, are now associated with the experience of buying a product at thebikeofmydreams.com. He is already inclined to never buy again on this website, even before knowing how the the refund process will turn out.

That is an example, of how a current experience can be amplified by previous bad experiences. Worst case scenario, your service will be associated with the terrible experience and your brand will be put in the same category of other brands that don't take good care of their customers.

How the Back-End Works Has an Impact on End Users

A common mistake I've seen some teams make is to ignore the overall impact of what they do on the end users' experience. This is more common when the team is working on backend services with no direct interface with the end user. In these cases, a common thought is: "our impact on the user experience is little or none, because what we are doing is several layers away from the user interface". That is a wrong assumption to make.

Now let's take a look at the development team that is working on a new backend service for thebikeofmydreams.com.

The team is working on a payment solution to process payments for thebikeofmydreams.com's shopping cart. This service integrates the website with a variety of different payment gateways. It gets purchase orders from the site, and routes the payment requests to the Payment Service Provider (PSP), which will then provide the authorization for each transaction from the acquiring bank. At the end of this process, the completed transaction is communicated to the user through the same communication chain. The payment solution will also provide information to other internal systems of the company, such as revenue accounting and others. In other words, the payment solution being developed has no direct interface with the end user consumer.

The main concern for the team is the one related to the system's performance and scalability, and most of the discussions are from the perspective of third party systems consuming the service. The mindset of the team is: "we are developing a service to be consumed by internal systems, we should not be spending much time talking user experience, as we have no influence on the user interface".

Great Product Design Puts the User at the Heart of Every Decision

The impact on user experience doesn't come just from the interface.

Let us come back to Willy's problem on thebikeofmydreams.com. After Willy submits his credit card information, the acquirer authorizes the payment, and for some reason, the final response shown to him (interface layer) is that the transaction could not be completed. So he makes a new payment.

Let us now look at this from a different perspective. In the backend system, the payment solution considered the transaction to be valid, but due to a problem in the chain of communication, Willy is wrongly informed that the transaction is not successful. Long story short: to the system, his payment is valid, but to him his payment has been denied. Therefore he makes a new payment, which the system also considered valid. So to the system, he has made two purchases, and to him, he has made a single one.

What exactly went wrong? Could the problem be in the final response from the PSP to the payment solution, or in the PSP itself, or maybe even, in the connection between the PSP and the acquiring network (usually banks that authorize credit card transactions) that was failing? To Willy, this is not important. He only wants to buy his new bike and pay for it.

Now the team decides to map a potential user journey and identifies where they can improve the user experience.

At the end of this work, they decide to implement the following improvements:

• Minimize the chain of communication or integration points, thereby significantly reducing the risk of downtime or miscommunication between third party systems. They will also create a contingency plan for the cases when downtime happens in one of the payment providers (example: fallback connection).
• Design a feature that will keep track of inconsistent cases (such as Willy's). With that in place, they will be able to validate the response received from third party systems, and also ensure that the message is displayed to the user before the end of the process. If the pieces of information don't match, the system will trigger an alert to customer service. This will allow them to contact the customer to solve problems proactively.
• Implement a mechanism to automatically retry sending payment confirmation when the last mile of communication flow fails.

Happy Path: When Comparison Pays Off

Now let us imagine how Willy's experience would have been if a user centered solution had already been in place.

Willy sees a nice bicycle on sale on thebikeofmydreams.com. For some reason, when he pays, he is unable to work out why his payment attempt is not successful. However, he wants that bike so badly, he decides to repeat the entire purchase process. This time he successfully completes the purchase. Now, forgetting his earlier bad experience, he is very happy to have his new bike to start using in his competitions. Three days later, he receives a call. It is someone from thebikeofmydreams.com asking him to confirm if he bought two units of the same product on the same day. He reports that he had a problem paying and because of that, he repeated the purchase. The attendant apologizes for the inconvenience and informs him that he will receive a refund for the second transaction mistakenly credited to his credit card. Willy feels pleasantly surprised about how the situation is handled before it became a bigger problem. He hadn’t checked his credit card balance yet, but is impressed with the good service.  Now he thinks thebikeofmydreams.com is a reliable company for online purchases. He will definitely search for products on thebikeofmydreams.com whenever he feels like buying bicycle parts online.

(*) The thebikeofmydream.com is not a real site and was created with the purpose of illustrating the idea of the post. This post was created in September 2016, and at the time of writing, the site and brand did not exist.