Why should Product Architects obsessively think from the User’s Point of View?

Why should Product Architects obsessively think from the User’s point of view?

The problem

My most common advice to architects and aspiring architects is that they should “think from the User’s perspective.” This article highlights the importance of this approach.

Consider, for example, the “GreenProduce mobile app,” which helps users find and order fresh produce for delivery. The app’s delivery capability depends on the user’s location and the product’s shelf life, making it challenging to display only the available items. For instance, when you search for tomatoes on the app, only a subset of the results can actually be delivered due to the user’s location and the remaining shelf life of each product. Therefore, it’s complicated to show users only the produce that can be delivered to them, factoring in distance and product lifespan.

The optimal solution is to subdivide the service area into smaller zones, precalculate which items are deliverable in each zone, and use this information to determine what can be delivered to the users. This approach requires significant backend changes. Alternatively, showing all items and notifying users of unavailability at checkout might seem easier, but it results in a poor user experience.

In similar situations, we often choose what is easy for us (the development team) over what is easy for the user. Architects understand the system’s workings and might simplify implementation at the expense of user satisfaction, sometimes even without realizing it. This is a common error among emerging architects.

Why does the user perspective is important?

Architecture decisions in a software product are shaped by the following forces (in order):

• User experience — what will make users happy
• Business consideration — development cost, cloud cost, expected revenue, etc
• Product company’s strategy
• Technology considerations

When we design, these forces can conflict. We either need to trade off (compromise) or find a more creative solution that can achieve both. Design is about when to trade off vs. when to look for creative solutions and what to prioritize among different considerations.

Among the above four, user experience is critical due to the domino effect it carries. For example, a happy customer tells his friends who can tell their friends, and so on, leading to a chain reaction of positive feedback. On the other hand, unhappy customers have the same effects the other way around, recursively killing momentum. Great user experience compounds positive effects, while bad user experience compounds negative effects.

Hence, a good user experience has many advantages.

• New customers — easy to find new customers
• Less churn — easy to keep existing customers
• Happy customers tell friends, which can create viral effects.
• Less support cost due to fewer change requests and trust

On the other hand, substandard user experience creates many costs costs.

• It takes time to detect the problems. ( Most unhappy users will not complain and just go away, and the system continues to create unhappy users, spreading negative vibes.)
• We need the context when we fix problems. Fixing takes about 30X the effort compared to developing it in the first place because it requires one to understand and fix it.
• Fixing problems distracts us from creating new experiences and slows us down — we spend about 30% of our time fixing bugs, and often more.

Hence, user experience needs to take precedence among the four forces when designing software architecture. Compromise on user experience rarely works well, while compromise on other fronts can often be tolerated.

Approach to design?

This brings us to the main point of this article. When designing, we need to do the following.

1. As architects who understand the system’s work, we can often make implementation easier by morphing the requirements at the cost of user experience. Sometimes, this happens unconsciously. This is one of the common mistakes good upcoming architects make. We need to actively resist this.
2. We should seek creative solutions that do not require compromises among different considerations. The extra effort we put in during the design phase can save us a lot of trouble later. Technology considerations are not set in stone. They are flexible. As with the Green Produce app we discussed, if we look hard, we can often find better solutions that make customers happier and handle business and technical considerations. However, if we are content with the easiest way to implement the feature, we will never uncover those better solutions.
3. If #2 is not possible, we must start with what makes the User happy and keep striving for the perfect user experience while meeting business considerations. 80–90% of the time, we find it if we look hard enough. Spending even three to four times more effort (development time) for doing is often justified as it costs more than 30 later. This is not just a suggestion but a principle that should guide our decisions. In very few cases, we may have to compromise and change user experience to match technical limitations. However, that compromise MUST happen after we have tried hard.

In summary, sacrificing user experience for technical convenience is a critical mistake. Poor user experiences can have a domino effect of negativity. Maintaining a user-centric approach and questioning if decisions are based on user needs versus implementation ease is critical. While technical limitations may necessitate adjustments, these should only occur after thoroughly exploring alternatives. This mindset is essential for developing products that users will love and remember.

If you enjoyed this post, you might also like my new Book: Software Architecture and Decision-Making. You can find more examples from the book.

Get the Book, or find more details from the Blog.

Please note that as an Amazon Associate, I earn from qualifying purchases.