When you are building your product, how well do you know your customers? Can you visualize who they are? Do you understand their motivations? How do you know you have requirements or user stories for all of the various customer types that you have? By knowing who your personas are for the product or solution you are building, can help you answer these questions.
Personas represent specific users and act as examples of the types of users who would interact with it. Most products have several personas that use the product in different ways. Examples of three personas for a product are the regular user, power user, and administrator.
- The regular user uses only the basic user interface functionality.
- The power user needs more detailed interface functionality to handle more sophisticated work.
- The administrator needs back-end installation and maintenance functionality.
All three use the product differently, and different features are built for their respective needs. Personas are a powerful way to guide your decisions about functionality and ensure that you are, in fact, building functionality for each persona. Personas are a key ingredient in the way that user stories can be presented. Including the persona in a story description provides you the point of view (POV) of a user story and defines who that user story is for.
I recommend that you establish a description for each persona. This description is typically illustrated as a fictitious person that represents a real role. It will include the knowledge, experience, and activities of that role. By writing a persona as a fictitious person with a name, this makes the persona easier to imagine and relate to, as in the following examples.
Consider establishing personas for your products so that the functionality can be better understood and help you build a product that better aligns with your customer needs. Finally, personas offer four distinct advantages.
- The team understands the users better, which helps guide decisions about the functionality they need.
- User stories can be written to include the persona to ensure the personas have requirements suited to them.
- Testers can create acceptance tests and use cases that support personas.
- Based on their personas, the Product Owner knows who can give the best feedback and therefore whom to invite to the reviews or demos.
You can read more about Personas in the book entitled Being Agile in Chapter 17 in relation to customer reviews and demos and Chapter 18 in relation to writing effective user stories.
Important topic as it addresses a few practical aspects of implementing Agile - sharing the team's thinking with stakeholders (executive management, marketing, sales) for validation and alignment, in terms they and everyone can relate to. Its also very important to categorize the feedback on the software so it can be understood well in the right context.ReplyDelete
I agree with placing a face and I strongly believe it is important to have in mind how the interactions between users and your company are. Keeping an eye on this is very important to evaluate and understand how value is created and will help you get a better visualisation of your product.ReplyDelete
I would also include in the equation anyone how does not directly use the software but will get beneficed or will be politically influenced by the application and consider them in a way or another.
I'll second what Erich said. There's a "beneficiary" persona, often in a managerial or executive role. Software product companies also need to think about the buyer, too, who can be completely different.ReplyDelete