From "good to great"of user stories

We all use a vast number of digital products in our daily lives. Some study suggests that a typical working folk uses over 100 products during the span of the day. A digital product here includes a phone, an app on the phone, your smart TV, an app on the smart TV, your gadgets such as smart-watches, your desktops/laptops/tablets/music players, and the various applications installed within them to aid you in the various tasks that you undertake. Even while you are reading this post, you would have already interacted with around 4 such applications. Your platform/device, your browser/application, the website, the page/link to the article.

Have you ever wondered, how do the manufacturers or creators of these products and applications come up with the different functionalities? The functionalities that you undertake and make the most out of the products. The most often provided response to this question is - user/consumer research, and/or - relying on gut feeling to identify the possibilities. As Steve Jobs mentioned, "People don't know what they want?until you show it to them". Such feel for the need of consumers (you and me) and the description of the desire or functionalities is termed as product requirements.

Once these requirements are generated and enlisted, they are refined with the important pieces of information to provide inputs for the team so that they can program the same – “write lines of codes to allow users to take some set of actions to fulfill the desire”. This is where the requirement gets translated to machine language “binary” and you as the user can enjoy the ease of viewing your favorite videos or connect with your friends on the social media app with the help of a few clicks. These requirements for a product development team are known as “user stories”, the human language that helps identify the nuances that are required by the user to be translated into machine language later by the awesome developers.

A user story is the piece of information that defines "who", will be able to do "what", and "why". Who – i.e., who is taking the action, the Persona, What – i.e., the action that the user is going to take, and?Why – i.e., the reason for the existence of the feature.

The persona or the actor is the user whom you expect to be interacting with the product. The role is important, as the same allows or limits the action that they will be able to take on the platform. Think about the time that you were not happy with the color of some application. You couldn’t just go and change the face of the app. Unless there is a user need identified, and functionality added: "a logged-in user should be able to change the theme from light to dark", you wouldn’t be able to do that. Only the developers (the gods) in such a scenario could make that change happen at the product level. Think about some apps in your device, that need explicit admin credentials before you can access them. Admin in such a case is the persona in question.

“What” or the action that this user persona is allowed/required to take is defined as the task. This is the part, that ensures the boundaries or premise within which the user can interact with the product to ensure they can achieve the desired result. Say you want to add a picture to your profile, the ability to click a picture immediately, or choose from your device storage is the action. Another feature can be the ability to crop or add filters to the uploaded photo.

The “why” is the reason for the existence of a requirement or a feature in the product. Think of it as the same question as to “Why are you here? What is the reason for existence?” and all those meta-questions. The "why" defines, the goal the user wants to achieve or the problem for which the feature will provide a solution. Taking the above examples, the changing of the theme allows the user to reduce the strain they feel using the app, and the feature of allowing picture uploads and cropping and filtering ensures the users can personalize their profile and share pictures with their social groups. The motivations around the feature are captured under "why" to help envision the problem the requirement is going to solve.

Various schools of thought identify which part of the matrix, i.e., the persona, action, and reason. And before you read further, just pause for a moment and give it a thought yourself.

Following are the results from a poll I floated. Although it didn't receive many votes, the results still point in the same direction. Out of the 13 respondents, 7, the majority chose “why” as their favorite choice. The others were distributed between “what” and “who”. This illustrates the importance of “why”, the problem that the products are trying to solve for the user, and the product's existence.

It is imperative that “Why” defines the aspirations of “Who” and hence helps achieve the same via “What”. However, there are various ways to achieve the “what”, and during the product decision, the developers would have taken a route that achieves “why” in the most efficient way. The buck doesn’t stop at achieving the “Why” (at least not the first why anyways! - try more like 5).

Another hidden pillar allows all these elements to align together to ensure a product/feature with the best UX. Some really well-thought ideas allowing for a seamless workflow that makes your customer happy. Pre-empting scenarios and fixing them for the users that may face during the “what” or the “action” and can lead them to an unknown place or the “unpleasant” experience. To ensure the story is complete and manages to keep the UX with the product in the black (positive), it is important to include “negations”. These negations can be many for each user story and need to be thought through in-depth. Negations are also something that gets missed quite often, as we don't expect things to go wrong, and lead to bugs in the products.

Negations are the “negative scenarios” that the users may arrive at while acting as a part of the user story. Such negations, if not identified, may lead to incomplete tasks, pointing to unknown pages, or even crashing of the app (in not so many cases thankfully) and ultimately to the dreaded bad UX. Expert developers or coders are aware of such negations at the code level and can manage them adequately. However, when it comes to the overall experience, if the user story is not enhanced with negations, it may not cover all scenarios and ultimately lead to a devastating experience for the user.

Think of the time when the Cowin app was launched, if the OTP receipt took more than 3 minutes to arrive, the system had made the OTP unacceptable by then and essentially the whole process was for no good and made the whole experience of using the app terrible.

A simple example of negations is – Allowing for a non-numeric character in the phone numbers field, starting the build cart process from scratch after sudden closure of the app or browser. When you think about them, these pieces seem logical, but if not thought through during the user-story definition phase, they will lead to problems when users interact with the product. ?

Negations are your typical scenarios/use cases that are negative expectations from the product and are exceptions in the product that are ought to be handled to make the UX of the app so good that the users are elated to use the product and are hooked to them.

No denying the fact, that if a product doesn’t solve the basic need, it has failed to achieve the purpose of existence. However, if your product is not able to check the right boxes such as smooth flow and an awesome UX, there will be competition all around to capture users' attention and take them away from you. Negations are not new, however, they get missed often and become a deterrent of product UX.

Users these days don’t lack options and there is very minimal switching cost that they must bear before taking such decisions. Focus on the why yet don’t overlook the negations in your stories to ensure the UX is top-notch, and your users are extremely satisfied with the product. Negations just need to be given some thoughts in between the plethora of whys, what and, whom your products are serving.

Remember, a happy customer ensures a better future for the product and ensures high CLTV.?