User stories are brief statements that describe a functionality of the product, in the form of a single task, from the user's point of view. Typically, each story opens with the words "The user should be able to..."--for example, "The user should be able to access their inbox from any screen on the application."

The stories do not, and should not, attempt to suggest or define how to achieve the function, the user experience, or the technical approach. Their main purpose is to provide a complete inventory of a user-facing functionality, which can be prioritized and aligned with relevant project needs, such as their complexity and cost to develop, their importance from a business perspective, and their importance to the user.

While some tasks can be designed to be performed quickly and smoothly, there are many tasks that are more complex, due to exceptions or conditional logic based on the type of user or context of interaction. That is why, for each task, the optimal smooth flow, often referred to as the Happy Path or Primary Path, is considered the primary story. Then, for most happy paths, the designers should document alternate paths, which are variations caused due to various exceptions.

The product design must be able to handle these variations smoothly, and a great user experience is a result of anticipating many such alternate paths, and resorting disruptions in the flow toward a smooth conclusion.

The preceding figure shows some of the variations possible for the "Reserve a Car" task. The primary flow, or happy path, is the one in which the user interacts with the online reservation system, and is able to complete a reservation satisfactorily. However, the reservation task is initially divided into self-service and assisted categories, and each of these has a number of versions for user stories or scenarios.