Personas And Attributes For Your User Roles

If you have ever had the desire to write fiction, creating a persona for your actors could be your gateway. Adding background stories, motivations, attitudes and other personality attributes to your actors can help flavor how they are documented in your requirements package. Although there is a natural desire to detailed information about the actors job description, these really isn't the focus of persona creation. The content is focused on a more personal level, after all jobs represented by actors are performed by people. Keeping the whole thing fictional in nature will help mitigate the risk that anyone will take this documentation as an insult or swipe at them personally. 

Let's face it, you probably have more than one typical user that will be wanting or needing the benefits provided by the software product you want to produce. By creating a list of user types, let's say 10 different ones, you can create a more encompassing experience for your software requirements package. Later on matching these user types to defined scenarios, can give you a better idea of some of the intended and perhaps not intended interactions they may have with your software system.

I find that adding a persona to a user role makes leveraging it more interesting and more helpful in the long term. A persona is a imaginary representation of a particular user role. Many times it takes the form of a resume that will state the different attributes appropriate to the software project that your building. 

If there are defined personas are embraced by the team, you may find that it drives a lot of your conversations. You may encounter something like a team member saying, "Bob wouldn't use it that way and I'll tell you why ...". You will then look around the room, and see that the entire team "gets it ". They understand what that team member was talking about in reference to Bob's persona.

In many instances you can get more mileage out of comparing personas then you can with two typically written user roles. This may sound silly but I have seen examples where the person documenting the persona goes out and does a Google search for a different faces. They find a face that looks adventurous and then apply that phase to the persona that they've written for the software project. So the idea is to humanize the persona that as much as possible. This can help in the visualization techniques for the accompanying scenarios.

Knowing the subtle and not-so-subtle differences between two roles, can go a long way to see how the scenarios will differ when those personas are applied to them.

©2015 Dwayne Wright