User stories are meant to be written in this format:
As a [role], I want to [goal], so that [benefit].
Role indicates the type of user or actor that will engage with the application. Goal describes what that user wants to achieve with his or her interaction, and benefit indicates why they want to perform that action. It’s just another way of stating ‘Who, What, Why.’ The idea is that a product owner speaks in business terms and phrasing requirements in this way helps the entire team look at the product from the business user’s perspective, not a technical perspective. It’s the basis for user-centered design. There is a pitfall that I see with this approach, though, and it lies in viewing users too broadly.
Most teams will be successful identifying a variety of types of users when the roles of those users are well-defined and distinct from one another. For example, many software systems require administrators to set up accounts or manage internal settings that aren’t exposed to the everyday user of the system. In this case, some user stores will begin with “As a user, I want to . . . ,” and others will begin with “As an admin, I want to . . . ” This kind of delineation between roles is obvious, but when you consider the everyday user of the system, there may well be value in differentiating even further.
For instance, in designing an e-commerce website, you may end up with a better design if you consider that male and female shoppers have different behaviors, and high frequency purchasers will behave differently than shoppers that only visit the site once or twice. Consumers that log in with an established account should have a more personalized experience than “guests” that don’t identify themselves by logging in. Some people like to take their time and browse through many items, while others know exactly what they want and don’t want to have to navigate many levels deep. For them, a strong search function might be all they care about.
There are a number of ways to leverage this kind of detailed breakdown of users. Different UIs can be designed for different types of users, or you may instead decide to design for the least tech-savvy user you can imagine in the ecosystem of your application. Whatever approach you take in the end, you will benefit from dedicating a session or two to defining all types of users you can think of. It can also be useful to create a profile for each type of user as you identify them. Some companies even give their “users” names. A profile, which should be kept to a single page or less, can describe demographics, primary and secondary goals that user might have as they interact with the system as a whole, and a description of what you project they would like and dislike about interacting with applications in general.